From ltru-bounces@ietf.org Wed Mar 01 00:40:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEK4g-0000p3-88; Wed, 01 Mar 2006 00:40:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEK4f-0000f4-2P for ltru@ietf.org; Wed, 01 Mar 2006 00:40:33 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEK4d-00062U-C9 for ltru@ietf.org; Wed, 01 Mar 2006 00:40:33 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k215dld26301; Wed, 1 Mar 2006 14:39:47 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 597d_cb844ae6_a8e5_11da_88f7_0014221fa3c9; Wed, 01 Mar 2006 14:39: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 k215cW7R021483; Wed, 1 Mar 2006 14:38:59 +0900 Message-Id: <6.0.0.20.2.20060301133957.0538ec50@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 01 Mar 2006 13:42:30 +0900 To: "Addison Phillips" , "'Mark Davis'" From: Martin Duerst Subject: RE: [Ltru] Could we suggest RFC 4466 ? In-Reply-To: <000101c63ce3$0442b080$660a0a0a@ds.corp.yahoo.com> References: <44050FDF.3000408@icu-project.org> <000101c63ce3$0442b080$660a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 12:48 06/03/01, Addison Phillips wrote: >Actually, might I propose... > >We need to file a draft-11 anyway. Why don't we (oh co-chairs) set a date >by which comments need to be in? Let's say a week from today. That would be fine with me, but the deadline for submissions before the next IETF is Monday (morning, US eastern). So I think a deadline of Friday would be more appropriate (depends mainly on how much work Addison wants to do over the weekend). I'm trying to get my comments in today or tomorrow, and I'm also working on the issues list to make sure the discussion is documented. Regards, Martin. >The results >would be filed as draft-11, which would be the WG LC draft (unless a >compelling thread to the contrary develops during the week--rather >unlikely, since we've expunged everything remotely experimental). > >That would be a measured approach that would allow us to get any nits >removed and give everyone ample opportunity for final tuning and comments >before we finish off. At the same time, it would do away with this >interminable waiting to see if we might someday contemplate doing something >about a last call. > >Addison > >Addison Phillips >Internationalization Architect - Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. > >> -----Original Message----- >> From: Mark Davis [mailto:mark.davis@icu-project.org] >> Sent: 2006$Bj;%((B2$Bk|/(B8$Bkw!&(B 19:07 >> To: Addison Phillips >> Cc: 'Randy Presuhn'; 'LTRU Working Group' >> Subject: Re: [Ltru] Could we suggest RFC 4466 ? >> >> Agreed. I think we are ready for WG Last Call, and as far as I can see >> we have rough consensus for that. Anyone disagree? >> >> Randy, Martin? >> >> Mark >> >> Addison Phillips wrote: >> > The only number that matters any more is BCP 47. All else is mysticism. >> > >> > We shan't get a published as a replacement for BCP 47 until we finish >> > draft-matching. To get there we need a WG Last Call, which means that >> any >> > more "close reading" comments of draft-10 need to be submitted and >> > processed. I have two minor fixes in my editor's copy right now since >> > draft-10. Any more? >> > >> > Addison >> > >> > Addison Phillips >> > Internationalization Architect - Yahoo! Inc. >> > >> > Internationalization is an architecture. >> > It is not a feature. >> > >> > >> >> -----Original Message----- >> >> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >> >> Sent: 2006?2?28? 11:55 >> >> To: LTRU Working Group >> >> Subject: Re: [Ltru] Could we suggest RFC 4466 ? >> >> >> >> Hi - >> >> >> >> Assignment of RFC numbers is the job of the RFC editor, not the WG. >> >> >> >> If there is a desire for consecutive numbers for a group of related >> >> documents, such requests have been accommodated in the past, >> >> and both as co-chair and as a technical contributor I think such a >> >> request would be reasonable to make through our AD. >> >> >> >> If you really believe there is technical value to assigning a >> particular >> >> number to a particular RFC, then a hallway conversation with the >> >> RFC editor in Dallas would make sense. However, both as a technical >> >> contributor and as a co-chair I believe that asking for (and getting) a >> >> particular number would be a bad thing. These are my reasons: >> >> (1) it perpetuates the myth that there is any particular significance >> >> to an RFC's number, other than perhaps the editor's sense of humor >> >> or irony. (E.g., the assignment of 2257 to AgentX.) >> >> (2) it violates the long-standing practice of not pre-assigning. See >> 2.6 >> >> in ftp://ftp.rfc-editor.org/in-notes/rfc- >> editor/instructions2authors.txt >> >> >> >> Randy >> >> >> >> >> >> _______________________________________________ >> >> Ltru mailing list >> >> Ltru@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/ltru >> >> >> > >> > >> > >> > _______________________________________________ >> > Ltru mailing list >> > Ltru@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ltru >> > >> > >> > > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 01 01:00:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEKOG-0001wv-QS; Wed, 01 Mar 2006 01:00:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEKOG-0001wq-Ah for ltru@ietf.org; Wed, 01 Mar 2006 01:00:48 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEKOE-0006JN-W8 for ltru@ietf.org; Wed, 01 Mar 2006 01:00:48 -0500 Received: from duringpersonlx (snvvpn-c184.corp.yahoo.com [172.21.169.184]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k2160M7t097164; Tue, 28 Feb 2006 22:00:22 -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: thread-index:x-mimeole; b=2UUzq+UINum3rS5VN9vG6HZ6uPkJC+6rctOyXVz3vwFWOHKatlpZKofGqdygTdaX From: "Addison Phillips" To: "'Martin Duerst'" , "'Mark Davis'" Subject: RE: [Ltru] Could we suggest RFC 4466 ? Date: Tue, 28 Feb 2006 22:02:12 -0800 Message-ID: <000201c63cf5$af85e680$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6.0.0.20.2.20060301133957.0538ec50@localhost> Thread-Index: AcY88pNw9VYfsdpWS6ezJgU8XzyM5gAAvrnw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Friday is fine with me. Next week is Unicode week and I'd be hard pressed to do both anyway. I'd rather have draft-11 under wraps Monday anyway. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 2006$BG/(B2$B7n(B28$BF|(B 20:43 > To: Addison Phillips; 'Mark Davis' > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] Could we suggest RFC 4466 ? > > At 12:48 06/03/01, Addison Phillips wrote: > >Actually, might I propose... > > > >We need to file a draft-11 anyway. Why don't we (oh co-chairs) set a > date > >by which comments need to be in? Let's say a week from today. > > That would be fine with me, but the deadline for submissions before > the next IETF is Monday (morning, US eastern). So I think a deadline > of Friday would be more appropriate (depends mainly on how much work > Addison wants to do over the weekend). I'm trying to get my comments > in today or tomorrow, and I'm also working on the issues > list to make sure the discussion is documented. > > Regards, Martin. > > >The results > >would be filed as draft-11, which would be the WG LC draft (unless a > >compelling thread to the contrary develops during the week--rather > >unlikely, since we've expunged everything remotely experimental). > > > >That would be a measured approach that would allow us to get any nits > >removed and give everyone ample opportunity for final tuning and > comments > >before we finish off. At the same time, it would do away with this > >interminable waiting to see if we might someday contemplate doing > something > >about a last call. > > > >Addison > > > >Addison Phillips > >Internationalization Architect - Yahoo! Inc. > > > >Internationalization is an architecture. > >It is not a feature. > > > >> -----Original Message----- > >> From: Mark Davis [mailto:mark.davis@icu-project.org] > >> Sent: 2006$Bj;%((B2$Bk|!&(B8$Bkw!&(B 19:07 > >> To: Addison Phillips > >> Cc: 'Randy Presuhn'; 'LTRU Working Group' > >> Subject: Re: [Ltru] Could we suggest RFC 4466 ? > >> > >> Agreed. I think we are ready for WG Last Call, and as far as I can see > >> we have rough consensus for that. Anyone disagree? > >> > >> Randy, Martin? > >> > >> Mark > >> > >> Addison Phillips wrote: > >> > The only number that matters any more is BCP 47. All else is > mysticism. > >> > > >> > We shan't get a published as a replacement for BCP 47 until we > finish > >> > draft-matching. To get there we need a WG Last Call, which means > that > >> any > >> > more "close reading" comments of draft-10 need to be submitted and > >> > processed. I have two minor fixes in my editor's copy right now > since > >> > draft-10. Any more? > >> > > >> > Addison > >> > > >> > Addison Phillips > >> > Internationalization Architect - Yahoo! Inc. > >> > > >> > Internationalization is an architecture. > >> > It is not a feature. > >> > > >> > > >> >> -----Original Message----- > >> >> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > >> >> Sent: 2006?2?28? 11:55 > >> >> To: LTRU Working Group > >> >> Subject: Re: [Ltru] Could we suggest RFC 4466 ? > >> >> > >> >> Hi - > >> >> > >> >> Assignment of RFC numbers is the job of the RFC editor, not the WG. > >> >> > >> >> If there is a desire for consecutive numbers for a group of related > >> >> documents, such requests have been accommodated in the past, > >> >> and both as co-chair and as a technical contributor I think such a > >> >> request would be reasonable to make through our AD. > >> >> > >> >> If you really believe there is technical value to assigning a > >> particular > >> >> number to a particular RFC, then a hallway conversation with the > >> >> RFC editor in Dallas would make sense. However, both as a > technical > >> >> contributor and as a co-chair I believe that asking for (and > getting) a > >> >> particular number would be a bad thing. These are my reasons: > >> >> (1) it perpetuates the myth that there is any particular > significance > >> >> to an RFC's number, other than perhaps the editor's sense of humor > >> >> or irony. (E.g., the assignment of 2257 to AgentX.) > >> >> (2) it violates the long-standing practice of not pre-assigning. > See > >> 2.6 > >> >> in ftp://ftp.rfc-editor.org/in-notes/rfc- > >> editor/instructions2authors.txt > >> >> > >> >> Randy > >> >> > >> >> > >> >> _______________________________________________ > >> >> Ltru mailing list > >> >> Ltru@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/ltru > >> >> > >> > > >> > > >> > > >> > _______________________________________________ > >> > Ltru mailing list > >> > Ltru@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/ltru > >> > > >> > > >> > > > > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 01 02:26:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FELj2-0007Dm-88; Wed, 01 Mar 2006 02:26:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FELj0-00077e-Sx for ltru@ietf.org; Wed, 01 Mar 2006 02:26:18 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FELdW-0000uo-Cl for ltru@ietf.org; Wed, 01 Mar 2006 02:20:39 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k217JEu18462; Wed, 1 Mar 2006 16:19:14 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 61dd_afc63022_a8f3_11da_810c_0014221f2a2d; Wed, 01 Mar 2006 16:19:13 +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 k217Hfai022512; Wed, 1 Mar 2006 16:18:27 +0900 Message-Id: <6.0.0.20.2.20060301160953.03d33840@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 01 Mar 2006 16:16:21 +0900 To: "'LTRU Working Group'" From: Martin Duerst In-Reply-To: <000201c63cf5$af85e680$660a0a0a@ds.corp.yahoo.com> References: <6.0.0.20.2.20060301133957.0538ec50@localhost> <000201c63cf5$af85e680$660a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Ltru] Schedule for draft-matching X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 15:02 06/03/01, Addison Phillips wrote: >Friday is fine with me. Next week is Unicode week and I'd be hard pressed to >do both anyway. I'd rather have draft-11 under wraps Monday anyway. > >Addison Okay, so let's make it Friday: Any comments on the matching draft (version -10) should be sent in by Friday. If no issues that require detailled discussion are brought up by Friday, the editors will submit another draft and we will move to the usual two-week WG Last Call. If the Last Call does not bring up any issues that require substantive fixes, the chairs will submit the draft to the AD/IESG for further processing, approval, and publication. If issues are brought up that require substantive fixes, we will recicle (i.e. go through another WG Last Call at a later stage). Minor, in particular editorial, changes in WG Last Call will not result in another WG Last Call. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 01 02:56:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEMBi-0007dv-Ax; Wed, 01 Mar 2006 02:55:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEMBg-0007ck-2Y for ltru@ietf.org; Wed, 01 Mar 2006 02:55:56 -0500 Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEMBe-0001yM-Qo for ltru@ietf.org; Wed, 01 Mar 2006 02:55:55 -0500 Received: from h-68-165-4-111.snvacaid.dynamic.covad.net ([68.165.4.111] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FEMBd-0007EP-00 for ltru@ietf.org; Wed, 01 Mar 2006 02:55:53 -0500 Message-ID: <000a01c63d05$d05ca0a0$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <000201c63cf5$af85e680$660a0a0a@ds.corp.yahoo.com> Subject: Re: [Ltru] Could we suggest RFC 4466 ? Date: Tue, 28 Feb 2006 23:57:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Just a reminder -- the deadline for submission on Monday, March 6, is 09:00 ET (14:00 GMT). Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 01 03:23:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEMbk-0001WJ-H1; Wed, 01 Mar 2006 03:22:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEMbj-0001WE-B9 for ltru@ietf.org; Wed, 01 Mar 2006 03:22:51 -0500 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEMbh-0002mq-W1 for ltru@ietf.org; Wed, 01 Mar 2006 03:22:51 -0500 Received: from tex (smcvpn-c194.santamonica.corp.yahoo.com [172.21.163.194]) by mrout1.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k218KngZ026390; Wed, 1 Mar 2006 00:20:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:x-mimeole:in-reply-to:importance; b=0mgTMCaozyaSV8DgWtX7Uc9ceOcS+mhBSECuK++Nnwlp3A4qFFjmIFBrukxBcCqE From: "Tex Texin" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Schedule for draft-matching Date: Wed, 1 Mar 2006 00:22:39 -0800 Message-ID: <002d01c63d09$4e763ed0$979911ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6.0.0.20.2.20060301160953.03d33840@localhost> Importance: Normal X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Friday 6pm PT? (Just to be clear) Tex Texin Internationalization Architect, Yahoo! Inc. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: Tuesday, February 28, 2006 11:16 PM > To: 'LTRU Working Group' > Subject: [Ltru] Schedule for draft-matching > > > At 15:02 06/03/01, Addison Phillips wrote: > >Friday is fine with me. Next week is Unicode week and I'd > be hard pressed to >do both anyway. I'd rather have draft-11 > under wraps Monday anyway. > >Addison > > Okay, so let's make it Friday: Any comments on the matching > draft (version -10) should be sent in by Friday. If no issues > that require detailled discussion are brought up by Friday, > the editors will submit another draft and we will move to the > usual two-week WG Last Call. > > If the Last Call does not bring up any issues that require > substantive fixes, the chairs will submit the draft to the > AD/IESG for further processing, approval, and publication. If > issues are brought up that require substantive fixes, we will > recicle (i.e. go through another WG Last Call at a later > stage). Minor, in particular editorial, changes in WG Last > Call will not result in another WG Last Call. > > Regards, Martin. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 01 04:55:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEO3f-0007DI-Re; Wed, 01 Mar 2006 04:55:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEO3e-0007DD-Or for ltru@ietf.org; Wed, 01 Mar 2006 04:55:46 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEO3d-0006HA-3w for ltru@ietf.org; Wed, 01 Mar 2006 04:55:46 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k219sld14814; Wed, 1 Mar 2006 18:54:48 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 597e_6b35feb8_a909_11da_9a73_0014221fa3c9; Wed, 01 Mar 2006 18:54: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 k219rOGC024081; Wed, 1 Mar 2006 18:54:10 +0900 Message-Id: <6.0.0.20.2.20060301174738.03d41d80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 01 Mar 2006 17:48:35 +0900 To: "Tex Texin" , "'LTRU Working Group'" From: Martin Duerst Subject: RE: [Ltru] Schedule for draft-matching In-Reply-To: <002d01c63d09$4e763ed0$979911ac@ds.corp.yahoo.com> References: <6.0.0.20.2.20060301160953.03d33840@localhost> <002d01c63d09$4e763ed0$979911ac@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 17:22 06/03/01, Tex Texin wrote: >+1 > >Friday 6pm PT? (Just to be clear) If that's fine with Addison, that's fine with me. But I'm very sure that Addison will appreciate if whatever comments you still have come in earlier. Regards, Martin. >Tex Texin >Internationalization Architect, Yahoo! Inc. > > > > >> -----Original Message----- >> From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] >> Sent: Tuesday, February 28, 2006 11:16 PM >> To: 'LTRU Working Group' >> Subject: [Ltru] Schedule for draft-matching >> >> >> At 15:02 06/03/01, Addison Phillips wrote: >> >Friday is fine with me. Next week is Unicode week and I'd >> be hard pressed to >do both anyway. I'd rather have draft-11 >> under wraps Monday anyway. > >Addison >> >> Okay, so let's make it Friday: Any comments on the matching >> draft (version -10) should be sent in by Friday. If no issues >> that require detailled discussion are brought up by Friday, >> the editors will submit another draft and we will move to the >> usual two-week WG Last Call. >> >> If the Last Call does not bring up any issues that require >> substantive fixes, the chairs will submit the draft to the >> AD/IESG for further processing, approval, and publication. If >> issues are brought up that require substantive fixes, we will >> recicle (i.e. go through another WG Last Call at a later >> stage). Minor, in particular editorial, changes in WG Last >> Call will not result in another WG Last Call. >> >> Regards, Martin. >> >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> >> _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 01 13:09:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEVky-0007Of-JX; Wed, 01 Mar 2006 13:09:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEVky-0007Oa-7J for ltru@lists.ietf.org; Wed, 01 Mar 2006 13:09:00 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEVkw-0000ZW-VR for ltru@lists.ietf.org; Wed, 01 Mar 2006 13:09:00 -0500 Received: from duringpersonlx (snvvpn-c184.corp.yahoo.com [172.21.169.184]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k21I8XhL061224 for ; Wed, 1 Mar 2006 10:08:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:thread-index:x-mimeole; b=utdLqFf8tBZLGfNtvDoiJbtm4TqrW8KkhQRomix8jdOAe6RJF50W1Q9j7Zd/El1s From: "Addison Phillips" To: Date: Wed, 1 Mar 2006 10:10:07 -0800 Message-ID: <001101c63d5b$5fd12c60$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcY9W18orZDRPAd/QA2nXsovrpEBFA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [Ltru] comments on draft-10 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I have just a few substantive observations: 1. For some reason the formulation "applications, protocols, and = specifications" was rendered as "applications, protocols, and = implementations" in a few places. I fixed this. 2. In the penultimate paragraph in Section 3.1 (choosing types of = matching), I think we should include this normative text directly after = stating that the schemes don't require the registry or validation: -- An implementation MAY choose to check if either the language ranges or = language tags being matched are "well-formed" or "valid" (see , Section 2.2.9) and MAY choose not to process = invalid ranges. -- This will make it clear that, while checking is not required, it is = permitted. 3. I think we need to change one aspect of extended range matching: I = don't think the match should proceed past singletons unless the = singleton is "named" in the range. Currently the range "de-DE" would = match "de-x-DE", which I find problematic. Thus I'd propose changing the = third paragraph in Section 3.2.2 from: -- Take each non-wildcard subtag in the language range and compare it to = the next subtag in the language tag in turn until a matching subtag is = found or the langauge tag is exhausted. If the end of the language tag = is found first, the match fails. If a match is found, this step is = repeated with the next non-wildcard subtag in the language range (and = beginning with the next subtag in the language tag) until the list of = subtags in the language range is exhausted or the match fails. -- To read: Take each non-wildcard subtag in the language range and compare it in = a case-insensitive manner to the next subtag in the language tag. If the = range's subtag exactly matches the tag's subtag, proceed to the next = non-wildcard subtag in the language range (and beginning with the next = subtag in the language tag) until the list of subtags in the language = range is exhausted or the match fails. If the tag's subtag is a = "singleton" (a single letter or digit, which, in this case, includes the = private-use subtag 'x') and the range's subtag does not match or if the = language tag's list of subtags is exhausted, the match fails. If the = language range's list of subtags is exhausted, the match succeeds. 3a. I think we should include counter examples to the ones that match: -- The same range does not match any of the following tags for the = reasons shown: de (missing 'DE') de-x-DE (singleton 'x' occurs before 'DE') de-Deva ('Deva' not equal to 'DE') -- 4. I think it would also be useful to point out in this same section the = fact that 3066bis tag structure makes ranges quite specific: Note: The structure of language tags defined by defines each subtag according to position, = size, and content. This means that the subtags in a language range can = only match specific types of subtags in a language tag. For example, a = subtag such as 'Latn' is always a script subtag (unless it follows a = singleton) while a subtag such as 'nedis' can only match the equivalent = variant subtag (unless it follows a singleton). 5. In Section 3.3 (lookup) we show but say nothing about removing = singletons along with their just-following subtag, but we demonstrate = it. I.e.: Zh-Hant-CN-x-private Zh-Hant-CN It doesn't actually matter whether one does this or not, but should we = say anything? 6. Section 4.1 (Choosing language ranges). Should we mention that users = SHOULD choose well-formed, valid, canonicalized ranges? Also, should we = again mention the ability for implementations to check for any of those = three attributes? Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 01 15:21:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEXoi-0003v2-5l; Wed, 01 Mar 2006 15:21:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEXog-0003r8-BC for ltru@lists.ietf.org; Wed, 01 Mar 2006 15:20:58 -0500 Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEXod-0006r9-S0 for ltru@lists.ietf.org; Wed, 01 Mar 2006 15:20:58 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k21KKrMJ005711; Wed, 1 Mar 2006 12:20:53 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Mar 2006 12:20:54 -0800 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , ltru@lists.ietf.org Subject: RE: [Ltru] comments on draft-10 Date: Wed, 1 Mar 2006 12:20:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 And yes to the questions at item (6) below. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: Wednesday, March 01, 2006 1:10 PM > To: ltru@lists.ietf.org > Subject: [Ltru] comments on draft-10 > > > I have just a few substantive observations: > > 1. For some reason the formulation "applications, protocols, > and specifications" was rendered as "applications, protocols, > and implementations" in a few places. I fixed this. > > 2. In the penultimate paragraph in Section 3.1 (choosing > types of matching), I think we should include this normative > text directly after stating that the schemes don't require > the registry or validation: > > -- > An implementation MAY choose to check if either the language > ranges or language tags being matched are "well-formed" or > "valid" (see , Section 2.2.9) and > MAY choose not to process invalid ranges. > -- > > This will make it clear that, while checking is not required, > it is permitted. > > 3. I think we need to change one aspect of extended range > matching: I don't think the match should proceed past > singletons unless the singleton is "named" in the range. > Currently the range "de-DE" would match "de-x-DE", which I > find problematic. Thus I'd propose changing the third > paragraph in Section 3.2.2 from: > > -- > Take each non-wildcard subtag in the language range and > compare it to the next subtag in the language tag in turn > until a matching subtag is found or the langauge tag is > exhausted. If the end of the language tag is found first, the > match fails. If a match is found, this step is repeated with > the next non-wildcard subtag in the language range (and > beginning with the next subtag in the language tag) until the > list of subtags in the language range is exhausted or the match fails. > -- > > To read: > > Take each non-wildcard subtag in the language range and > compare it in a case-insensitive manner to the next subtag in > the language tag. If the range's subtag exactly matches the > tag's subtag, proceed to the next non-wildcard subtag in the > language range (and beginning with the next subtag in the > language tag) until the list of subtags in the language range > is exhausted or the match fails. If the tag's subtag is a > "singleton" (a single letter or digit, which, in this case, > includes the private-use subtag 'x') and the range's subtag > does not match or if the language tag's list of subtags is > exhausted, the match fails. If the language range's list of > subtags is exhausted, the match succeeds. > > 3a. I think we should include counter examples to the ones that match: > > -- > The same range does not match any of the following tags > for the reasons shown: > de (missing 'DE') > de-x-DE (singleton 'x' occurs before 'DE') > de-Deva ('Deva' not equal to 'DE') > > > -- > > 4. I think it would also be useful to point out in this same > section the fact that 3066bis tag structure makes ranges > quite specific: > > Note: The structure of language tags defined by target="RFC3066bis" /> defines each subtag according to > position, size, and content. This means that the subtags in a > language range can only match specific types of subtags in a > language tag. For example, a subtag such as 'Latn' is always > a script subtag (unless it follows a singleton) while a > subtag such as 'nedis' can only match the equivalent variant > subtag (unless it follows a singleton). > > 5. In Section 3.3 (lookup) we show but say nothing about > removing singletons along with their just-following subtag, > but we demonstrate it. I.e.: > > Zh-Hant-CN-x-private > Zh-Hant-CN > > It doesn't actually matter whether one does this or not, but > should we say anything? > > 6. Section 4.1 (Choosing language ranges). Should we mention > that users SHOULD choose well-formed, valid, canonicalized > ranges? Also, should we again mention the ability for > implementations to check for any of those three attributes? > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 01 17:26:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZmT-0001t6-Qg; Wed, 01 Mar 2006 17:26:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZmS-0001sv-Vs for ltru@lists.ietf.org; Wed, 01 Mar 2006 17:26:48 -0500 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEZmS-0001Ja-LC for ltru@lists.ietf.org; Wed, 01 Mar 2006 17:26:48 -0500 Received: (qmail 41226 invoked from network); 1 Mar 2006 22:26:48 -0000 Received: from unknown (HELO ?172.24.101.50?) (unknown) by unknown with SMTP; 1 Mar 2006 22:26:48 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <44061FA2.9060702@icu-project.org> Date: Wed, 01 Mar 2006 14:26:42 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] comments on draft-10 References: <001101c63d5b$5fd12c60$660a0a0a@ds.corp.yahoo.com> In-Reply-To: <001101c63d5b$5fd12c60$660a0a0a@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I have just a few substantive observations: > > 1. For some reason the formulation "applications, protocols, and specifications" was rendered as "applications, protocols, and implementations" in a few places. I fixed this. > good > 2. In the penultimate paragraph in Section 3.1 (choosing types of matching), I think we should include this normative text directly after stating that the schemes don't require the registry or validation: > > -- > An implementation MAY choose to check if either the language ranges or language tags being matched are "well-formed" or "valid" (see , Section 2.2.9) and MAY choose not to process invalid ranges. > good > -- > > This will make it clear that, while checking is not required, it is permitted. > > 3. I think we need to change one aspect of extended range matching: I don't think the match should proceed past singletons unless the singleton is "named" in the range. Currently the range "de-DE" would match "de-x-DE", which I find problematic. Thus I'd propose changing the third paragraph in Section 3.2.2 from: > > -- > Take each non-wildcard subtag in the language range and compare it to the next subtag in the language tag in turn until a matching subtag is found or the langauge tag is exhausted. If the end of the language tag is found first, the match fails. If a match is found, this step is repeated with the next non-wildcard subtag in the language range (and beginning with the next subtag in the language tag) until the list of subtags in the language range is exhausted or the match fails. > -- > > To read: > > Take each non-wildcard subtag in the language range and compare it in a case-insensitive manner to the next subtag in the language tag. If the range's subtag exactly matches the tag's subtag, proceed to the next non-wildcard subtag in the language range (and beginning with the next subtag in the language tag) until the list of subtags in the language range is exhausted or the match fails. If the tag's subtag is a "singleton" (a single letter or digit, which, in this case, includes the private-use subtag 'x') and the range's subtag does not match or if the language tag's list of subtags is exhausted, the match fails. If the language range's list of subtags is exhausted, the match succeeds. > > 3a. I think we should include counter examples to the ones that match: > > -- > The same range does not match any of the following tags for the reasons shown: > de (missing 'DE') > de-x-DE (singleton 'x' occurs before 'DE') > de-Deva ('Deva' not equal to 'DE') > > > I don't think this quite works, since that would have de-x-DE not matching de-x-DE. What I suggest is instead changing it to add instead: Extension and private use subtag sequences are treated as a single unit for the purpose of matching. Thus in matching de-DE against de-x-DE, the x-DE is treated as treated as a single unit, which does not match DE. > -- > > 4. I think it would also be useful to point out in this same section the fact that 3066bis tag structure makes ranges quite specific: > > Note: The structure of language tags defined by defines each subtag according to position, size, and content. This means that the subtags in a language range can only match specific types of subtags in a language tag. For example, a subtag such as 'Latn' is always a script subtag (unless it follows a singleton) while a subtag such as 'nedis' can only match the equivalent variant subtag (unless it follows a singleton). > agreed > 5. In Section 3.3 (lookup) we show but say nothing about removing singletons along with their just-following subtag, but we demonstrate it. I.e.: > > Zh-Hant-CN-x-private > Zh-Hant-CN > > It doesn't actually matter whether one does this or not, but should we say anything? > see above > 6. Section 4.1 (Choosing language ranges). Should we mention that users SHOULD choose well-formed, valid, canonicalized ranges? Also, should we again mention the ability for implementations to check for any of those three attributes? > Not necessary, but doesn't hurt. > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 01 18:43:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEayr-00023Z-Ti; Wed, 01 Mar 2006 18:43:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEayq-00020B-Tu for ltru@lists.ietf.org; Wed, 01 Mar 2006 18:43:40 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEayp-0004qN-N2 for ltru@lists.ietf.org; Wed, 01 Mar 2006 18:43:40 -0500 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k21Nh4n7096702; Wed, 1 Mar 2006 15:43:05 -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:x-mimeole:thread-index:in-reply-to; b=HnycsQX4xpatdCF9upUq5Zt4NpKnGYmoxZgXshX6rG1vJGM+r1ygtlGycrLJ9YEe From: "Addison Phillips" To: "'Mark Davis'" Subject: RE: [Ltru] comments on draft-10 Date: Wed, 1 Mar 2006 15:44:53 -0800 Message-ID: <000301c63d8a$240bc490$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcY9fz4uuUJSwYmmQ6yjf/5jG899NAAARHvg In-Reply-To: <44061FA2.9060702@icu-project.org> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark wrote: > I don't think this quite works, since that would have de-x-DE not > matching de-x-DE. What I suggest is instead changing it to add = instead: >=20 > Extension and private use subtag sequences are treated as a single = unit > for the purpose of matching. Thus in matching de-DE against de-x-DE, = the > x-DE is treated as treated as a single unit, which does not match DE. No, because that prevents doing matching of private use or extension = sequences. There is no reason to break those matches. All my text means = is that you must EITHER: a. Specify the private use or extension in the range b. Run out of range subtags before you get to the private use or = extension singleton.=20 Maybe my text wasn't clear enough? Here is some perl code that = implements the algorithm proposed (not pretty, but I wrote it in five = minutes): sub match { @range =3D split(/-/, shift); @tag =3D split(/-/, shift); my $count =3D 0; =20 RANGE: foreach my $rsubtag (@range) { # skip wildcards, if initial, increment tag's subtag count if ($rsubtag eq "*") { if ($count =3D=3D 0) { $count++; } next RANGE; } while ($count <=3D $#tag) { # look for matching subtag if (uc($rsubtag) eq uc($tag[$count])) { $count++; next RANGE; } # subtags don't match, check for singleton if (length($tag[$count++]) =3D=3D 1) { return 0; } } # ran out of tag subtags before finding last range subtag # note: "next RANGE" in perl is not like 'break' in C and=20 # skips this line! return 0; } # exhausted the range first return 1; } This correctly returns a "match" result for "de-x-DE" with = "de-Latn-x-DE" and a "non-match" for range "de-DE" with "de-x-DE". Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 01 21:39:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEdjS-0001J1-QV; Wed, 01 Mar 2006 21:39:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEdjS-0001Iw-EB for ltru@ietf.org; Wed, 01 Mar 2006 21:39:58 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEdjR-0004dx-3q for ltru@ietf.org; Wed, 01 Mar 2006 21:39:58 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FEdjQ-0006XS-Ng for ltru@ietf.org; Wed, 01 Mar 2006 21:39:56 -0500 Date: Wed, 1 Mar 2006 21:39:56 -0500 To: ltru@ietf.org Message-ID: <20060302023956.GA21870@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Ltru] John Cowan's comments on matching-10 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org My comments, mostly purely editorial: Section 1, graf 4, just replicates the TOC and should be removed. Or if you want to keep it, make it explicitly refer to "Section 2", "Section 3", and "Section 4". Section 2, graf 3: for "vary to match their application" read "vary in accordance with their application". This avoids confusion with the technical sense of "match". Section 2.1, first sentence, is true only of filtering, not of lookup, and is "semantic" anyhow. Just drop it. Section 2.2, first sentences, is about basic LRs but is in the section on extended LRs. It doesn't add anything: drop it. Section 2.2 after ABNF: the MAY there should just be "can"; it's not a RFC 2119 MAY. Section 2.2, following graf: remove "(which matches the default content)" which is true only in lookup. Section 2.3, last sentence: for "remain" read "remaining". Section 3, graf 3: for "different ... than" read "different ... from". Section 3.2, graf 2: for "the language range" read "each language range in the language priority list". Section 3.2, graf 3: merge the last graf with this one, and put "unordered" before "ordered". Section 3.2.2, graf 4: for "Extended filtering works, therefore, much like basic filtering" read "Extended filtering applied to basic ranges is therefore equivalent to basic filtering." This is a much stronger and more definite claim. Section 3.3, second graf after Fig. 3: proposed rewrite as follows (using a bulleted list): The default content returned when no tag matches the language priority list is implementation-defined. An implementation might, for example, return content: o with no language tag; o of a non-linguistic nature, such as an image or sound; o in a particular language designated for the bit of content being selected; or o content tagged "i-default" (see [RFC2277]). When performing lookup using a language priority list, the implementation MUST process each language range in the list before returning the default content. This removes the reference to XML 1.0 and empty xml:lang attributes (there is no such thing as an empty language tag) in favor of what an empty xml:lang signals: non-linguistic content. Section 3.3, second graf after Fig. 4: The last two sentences do not handle the case where the range "*" appears as the last range in a language priority list. I suggest the following replacement for them: If the language range "*" is followed by other language ranges, it SHOULD be skipped; if no other language ranges follow, the default content SHOULD be returned. Section 3.3, last graf: for "example" read "possibility". Section 4.1, graf 3: this applies only to filtering, and should be preceded with the words "When filtering,". Section 4.1, graf 7: for "filtering ... filtered" read "altering ... altered", as this is not the technical sense of "filter" used here. Section 4.1, last graf: for "matching or filtering" read "matching". Appendix A, last graf: remove first sentence (about scoring). -- All Gaul is divided into three parts: the part John Cowan that cooks with lard and goose fat, the part www.ccil.org/~cowan that cooks with olive oil, and the part that www.ap.org cooks with butter. -- David Chessler cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 01 23:49:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEfkS-00037j-TT; Wed, 01 Mar 2006 23:49:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEfkR-00035q-Il for ltru@ietf.org; Wed, 01 Mar 2006 23:49:07 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEfkR-0002LU-80 for ltru@ietf.org; Wed, 01 Mar 2006 23:49:07 -0500 Received: from duringpersonlx (snvvpn-c241.corp.yahoo.com [172.21.169.241]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k224mjAf025350; Wed, 1 Mar 2006 20:48:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:thread-index:x-mimeole; b=OKuE5q6h5XmDuUanO/1K0iLbGMCuXLhlMTCpMtX81OW9RXFpDqMxVhH35QYCUQNR From: "Addison Phillips" To: "'John Cowan'" , Subject: RE: [Ltru] John Cowan's comments on matching-10 Date: Wed, 1 Mar 2006 20:50:37 -0800 Message-ID: <000101c63db4$d9892810$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060302023956.GA21870@ccil.org> Thread-Index: AcY9oqgMjAn2LlBBRdm91OfzTft/rAACrBTg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Responses follow. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 2006?3?1? 18:40 > To: ltru@ietf.org > Subject: [Ltru] John Cowan's comments on matching-10 > > My comments, mostly purely editorial: > > Section 1, graf 4, just replicates the TOC and should be removed. > Or if you want to keep it, make it explicitly refer to "Section 2", > "Section 3", and "Section 4". This was added previously at Martin's behest. I can add references, although that seems equally pointless. I'll expunge if there are some "+1" for it. > > Section 2, graf 3: for "vary to match their application" read "vary > in accordance with their application". This avoids confusion with the > technical sense of "match". Changed to "vary according to their application" > > Section 2.1, first sentence, is true only of filtering, not of lookup, > and is "semantic" anyhow. Just drop it. The fundamental point of a basic language range (BLR) is that it is a prefix. I think we need to identify the fact that a BLR is a prefix to all tags that match (rather than what an "XLR" does, identifying those subtags which must be present without regard for interstitial subtags). But you are right about the tie to filtering, so I changed the sentence to: -- A "basic language range" describes a user's language preference as a specific, uninterrupted, sequence of subtags. -- > > Section 2.2, first sentences, is about basic LRs but is in the section > on extended LRs. It doesn't add anything: drop it. The point was to spell out the difference. I've struggled with the dissonance here to. Thus I'd suggest we use instead this sentence that matches the above: -- Occasionally users will wish to select a set of language tags based on the presence of specific subtags. An "extended language range" describes a user's language preference as an ordered sequence of subtags. -- > > Section 2.2 after ABNF: the MAY there should just be "can"; it's not a > RFC 2119 MAY. Done. > > Section 2.2, following graf: remove "(which matches the default content)" > which is true only in lookup. Done. > > Section 2.3, last sentence: for "remain" read "remaining". Already corrected in my copy :-). > > Section 3, graf 3: for "different ... than" read "different ... from". Done. > > Section 3.2, graf 2: for "the language range" read "each language range > in the language priority list". That would be good, but a bit wordy. I elected to make it merely "each language range". > > Section 3.2, graf 3: merge the last graf with this one, and put > "unordered" before "ordered". I merged the sentences to read: -- If the language priority list (see ) contains more than one range, the content returned is typically ordered in descending level of preference, but it MAY be unordered, according to the needs of the application or protocol. -- > > Section 3.2.2, graf 4: for "Extended filtering works, therefore, much > like basic filtering" read "Extended filtering applied to basic ranges > is therefore equivalent to basic filtering." This is a much stronger > and more definite claim. But one that, alas, isn't true. Extended filtering only works with extended ranges. "de-de" is a basic range (it is also an extended range). In extended matching, it matches "de-latn-de". In basic matching it does NOT match that tag. What is similar is that extended matching works as a prefix matcher. Your larger meta-comment is correct: the sentence is not correct enough to live. I changed it to: -- Much like basic filtering, extended filtering selects content with arbitrarily long tags that share the same initial subtags as the language range. In addition extended filtering selects content with any intermediate subtags unspecified in the language range. -- > > Section 3.3, second graf after Fig. 3: proposed rewrite as follows > (using a bulleted list): > > The default content returned when no tag matches the language > priority list is implementation-defined. An implementation might, > for example, return content: > > o with no language tag; > > o of a non-linguistic nature, such as an image or sound; > > o in a particular language designated for the bit of > content being selected; or > > o content tagged "i-default" (see [RFC2277]). Done, with minor mods: -- The default behavior when no tag matches the language priority list is implementation-defined. An implementation might, for example, return content: with no language tag; of a non-linguistic nature, such as an image or sound; with an empty language tag value, in cases where the protocol permits the empty value (see, for example, "xml:lang" in , which indicates that the element contains non-linguistic content) in a particular language designated for the bit of content being selected; or it might select the tag "i-default" (see ) -- > > When performing lookup using a language priority list, the > implementation MUST process each language range in the list > before returning the default content. Done. > > This removes the reference to XML 1.0 and empty xml:lang attributes > (there is no such thing as an empty language tag) in favor of what an > empty xml:lang signals: non-linguistic content. Not mentioning the empty value in XML is a problem, though. It ignores the problem that not many people know this (see: I point it out above) or that it is used as the Ultimate Default. And other protocols may wish to designate the empty value as meaning "root" or "default". Xml:lang is merely a convenient example. > > Section 3.3, second graf after Fig. 4: The last two sentences do not > handle the case where the range "*" appears as the last range in a > language priority list. I suggest the following replacement for them: > > If the language range "*" is followed by other language ranges, > it SHOULD be skipped; if no other language ranges follow, the > default content SHOULD be returned. Pretty close. I exchanged sentence order and expanded (others: please note that "should" has morphed to "SHOULD": -- If the language range "*" is followed by other language ranges, it SHOULD be skipped. If the language range "*" is the only one in the language priority list or if no other language range follows, the default content SHOULD be returned. -- > > Section 3.3, last graf: for "example" read "possibility". Done. > > Section 4.1, graf 3: this applies only to filtering, and should be > preceded with the words "When filtering,". Yes, although there is a similar point is necessary for lookup. Thus I rewrote and expanded to: -- When filtering, the fewer the number of subtags that appear in the language range, the more content the range will probably match, while in lookup unnecessary subtags might cause "better", more-specific content to be skipped in favor of less specific content. For example, the range "de-Latn-DE" would return content tagged "de" instead of content tagged "de-DE", even though the latter is probably a better match. -- > > Section 4.1, graf 7: for "filtering ... filtered" read "altering > ... altered", as this is not the technical sense of "filter" used here. I used "altered" and "alterations", fixing the grammer to match. > > Section 4.1, last graf: for "matching or filtering" read "matching". Done. > > Appendix A, last graf: remove first sentence (about scoring). It was removed from my copy per Mark's comments previously. Thanks for these excellent comments. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 01 23:59:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEfuH-0008SP-I9; Wed, 01 Mar 2006 23:59:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEfuH-0008RD-6q for ltru@ietf.org; Wed, 01 Mar 2006 23:59:17 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEfuG-0002Zi-Qi for ltru@ietf.org; Wed, 01 Mar 2006 23:59:17 -0500 Received: from duringpersonlx (snvvpn-c241.corp.yahoo.com [172.21.169.241]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k224wrpr025887; Wed, 1 Mar 2006 20:58:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:thread-index:x-mimeole; b=iwq0T5qZPSl97v6bprXQTptWrliSdncNs/eXofju3vl/0jubiUoOhySBDJVvwI3a From: "Addison Phillips" To: "'Addison Phillips'" , "'John Cowan'" , Subject: RE: [Ltru] John Cowan's comments on matching-10 Date: Wed, 1 Mar 2006 21:00:47 -0800 Message-ID: <000201c63db6$45609ea0$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000101c63db4$d9892810$660a0a0a@ds.corp.yahoo.com> Thread-Index: AcY9oqgMjAn2LlBBRdm91OfzTft/rAACrBTgAAI0EUA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org BTW> Editor's copy online is up-to-date. http://www.inter-locale.com/ID/draft-ietf-ltru-matching-11.txt http://www.inter-locale.com/ID/draft-ietf-ltru-matching-11.html http://www.inter-locale.com/ID/draft-ietf-ltru-matching-11.xml Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 2006?3?1? 20:51 > To: 'John Cowan'; ltru@ietf.org > Subject: RE: [Ltru] John Cowan's comments on matching-10 > > Responses follow. > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > -----Original Message----- > > From: John Cowan [mailto:cowan@ccil.org] > > Sent: 2006?3?1? 18:40 > > To: ltru@ietf.org > > Subject: [Ltru] John Cowan's comments on matching-10 > > > > My comments, mostly purely editorial: > > > > Section 1, graf 4, just replicates the TOC and should be removed. > > Or if you want to keep it, make it explicitly refer to "Section 2", > > "Section 3", and "Section 4". > > This was added previously at Martin's behest. I can add references, > although > that seems equally pointless. I'll expunge if there are some "+1" for it. > > > > Section 2, graf 3: for "vary to match their application" read "vary > > in accordance with their application". This avoids confusion with the > > technical sense of "match". > > Changed to "vary according to their application" > > > > Section 2.1, first sentence, is true only of filtering, not of lookup, > > and is "semantic" anyhow. Just drop it. > > The fundamental point of a basic language range (BLR) is that it is a > prefix. I think we need to identify the fact that a BLR is a prefix to all > tags that match (rather than what an "XLR" does, identifying those subtags > which must be present without regard for interstitial subtags). > > But you are right about the tie to filtering, so I changed the sentence to: > > -- > A "basic language range" describes a user's language preference as a > specific, uninterrupted, sequence of subtags. > -- > > > > Section 2.2, first sentences, is about basic LRs but is in the section > > on extended LRs. It doesn't add anything: drop it. > > The point was to spell out the difference. I've struggled with the > dissonance here to. Thus I'd suggest we use instead this sentence that > matches the above: > > -- > Occasionally users will wish to select a set of language tags based on the > presence of specific subtags. An "extended language range" describes a > user's language preference as an ordered sequence of subtags. > -- > > > > Section 2.2 after ABNF: the MAY there should just be "can"; it's not a > > RFC 2119 MAY. > > Done. > > > > Section 2.2, following graf: remove "(which matches the default > content)" > > which is true only in lookup. > > Done. > > > > Section 2.3, last sentence: for "remain" read "remaining". > > Already corrected in my copy :-). > > > > Section 3, graf 3: for "different ... than" read "different ... from". > > Done. > > > > Section 3.2, graf 2: for "the language range" read "each language range > > in the language priority list". > > That would be good, but a bit wordy. I elected to make it merely "each > language range". > > > > Section 3.2, graf 3: merge the last graf with this one, and put > > "unordered" before "ordered". > > I merged the sentences to read: > > -- > If the language priority list (see ) > contains > more than one range, the content returned is typically ordered in > descending > level of preference, but it MAY be unordered, according to the needs of > the > application or protocol. > -- > > > > Section 3.2.2, graf 4: for "Extended filtering works, therefore, much > > like basic filtering" read "Extended filtering applied to basic ranges > > is therefore equivalent to basic filtering." This is a much stronger > > and more definite claim. > > But one that, alas, isn't true. Extended filtering only works with > extended > ranges. "de-de" is a basic range (it is also an extended range). In > extended > matching, it matches "de-latn-de". In basic matching it does NOT match > that > tag. What is similar is that extended matching works as a prefix matcher. > > Your larger meta-comment is correct: the sentence is not correct enough to > live. I changed it to: > > -- > Much like basic filtering, extended filtering selects content with > arbitrarily long tags that share the same initial subtags as the language > range. In addition extended filtering selects content with any > intermediate > subtags unspecified in the language range. > -- > > > > Section 3.3, second graf after Fig. 3: proposed rewrite as follows > > (using a bulleted list): > > > > The default content returned when no tag matches the language > > priority list is implementation-defined. An implementation might, > > for example, return content: > > > > o with no language tag; > > > > o of a non-linguistic nature, such as an image or sound; > > > > o in a particular language designated for the bit of > > content being selected; or > > > > o content tagged "i-default" (see [RFC2277]). > > Done, with minor mods: > > -- > The default behavior when no tag matches the language priority list is > implementation-defined. An implementation might, for example, return > content: > > with no language tag; > > of a non-linguistic nature, such as an image or sound; > > with an empty language tag value, in cases where the protocol > permits > the empty value (see, for example, "xml:lang" in , > which indicates that the element contains non-linguistic content) > > in a particular language designated for the bit of > content being selected; or > > it might select the tag "i-default" (see />) > > > -- > > > > When performing lookup using a language priority list, the > > implementation MUST process each language range in the list > > before returning the default content. > > Done. > > > > This removes the reference to XML 1.0 and empty xml:lang attributes > > (there is no such thing as an empty language tag) in favor of what an > > empty xml:lang signals: non-linguistic content. > > Not mentioning the empty value in XML is a problem, though. It ignores the > problem that not many people know this (see: I point it out above) or that > it is used as the Ultimate Default. And other protocols may wish to > designate the empty value as meaning "root" or "default". Xml:lang is > merely > a convenient example. > > > > Section 3.3, second graf after Fig. 4: The last two sentences do not > > handle the case where the range "*" appears as the last range in a > > language priority list. I suggest the following replacement for them: > > > > If the language range "*" is followed by other language ranges, > > it SHOULD be skipped; if no other language ranges follow, the > > default content SHOULD be returned. > > Pretty close. I exchanged sentence order and expanded (others: please note > that "should" has morphed to "SHOULD": > > -- > If the language range "*" is followed by other language ranges, it SHOULD > be > skipped. If the language range "*" is the only one in the language > priority > list or if no other language range follows, the default content SHOULD be > returned. > -- > > > > Section 3.3, last graf: for "example" read "possibility". > > Done. > > > > Section 4.1, graf 3: this applies only to filtering, and should be > > preceded with the words "When filtering,". > > Yes, although there is a similar point is necessary for lookup. Thus I > rewrote and expanded to: > > -- > When filtering, the fewer the number of subtags that appear in the > language > range, the more content the range will probably match, while in lookup > unnecessary subtags might cause "better", more-specific content to be > skipped in favor of less specific content. For example, the range > "de-Latn-DE" would return content tagged "de" instead of content tagged > "de-DE", even though the latter is probably a better match. > -- > > > > Section 4.1, graf 7: for "filtering ... filtered" read "altering > > ... altered", as this is not the technical sense of "filter" used here. > > I used "altered" and "alterations", fixing the grammer to match. > > > > Section 4.1, last graf: for "matching or filtering" read "matching". > > Done. > > > > Appendix A, last graf: remove first sentence (about scoring). > > It was removed from my copy per Mark's comments previously. > > > Thanks for these excellent comments. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 00:00:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEfv2-0000qW-PO; Thu, 02 Mar 2006 00:00:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEfv1-0000qR-Ub for ltru@ietf.org; Thu, 02 Mar 2006 00:00:03 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEfuz-0002aq-MS for ltru@ietf.org; Thu, 02 Mar 2006 00:00:03 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FEfuz-0003Ws-9D; Thu, 02 Mar 2006 00:00:01 -0500 Date: Thu, 2 Mar 2006 00:00:01 -0500 To: Addison Phillips Subject: Re: [Ltru] John Cowan's comments on matching-10 Message-ID: <20060302050001.GC21870@ccil.org> References: <20060302023956.GA21870@ccil.org> <000101c63db4$d9892810$660a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000101c63db4$d9892810$660a0a0a@ds.corp.yahoo.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Responses follow. +1 to everything not in this reply. > The default behavior when no tag matches the language priority list is > implementation-defined. An implementation might, for example, return > content: > > with no language tag; > > of a non-linguistic nature, such as an image or sound; > > with an empty language tag value, in cases where the protocol permits > the empty value (see, for example, "xml:lang" in , > which indicates that the element contains non-linguistic content) > > in a particular language designated for the bit of > content being selected; or > > it might select the tag "i-default" (see />) This is good, except that the fifth point does not follow grammatically from the lead-off. Change to 'labeled with the language tag with "i-default"' etc. -- Using RELAX NG compact syntax to John Cowan develop schemas is one of the simple http://www.ap.org pleasures in life.... http://www.ccil.org/~cowan --Jeni Tennison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 04:33:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkC7-0001lI-3s; Thu, 02 Mar 2006 04:33:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkC6-0001eF-2h for ltru@ietf.org; Thu, 02 Mar 2006 04:33:58 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEkC3-0005j2-C6 for ltru@ietf.org; Thu, 02 Mar 2006 04:33:58 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k229XDd09833 for ; Thu, 2 Mar 2006 18:33:14 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 7d83_923dd9a6_a9cf_11da_9036_0014221f2a2d; Thu, 02 Mar 2006 18:33:13 +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 k229URsJ006311 for ; Thu, 2 Mar 2006 18:32:48 +0900 Message-Id: <6.0.0.20.2.20060302172527.091a9e50@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 02 Mar 2006 18:30:05 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Subject: [Ltru] Martin's comments on draft-10 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Here are my technical comments on draft-ietf-ltru-matching-10: Abstract, first sentence: Remove "evaluating", no idea what that means or where the matching draft makes this possible. 2.2, first para: "all language tags that constrains" -> "all language tags that constrain" 2.2, second-to-last para: "However wildcards" -> "However, wildcards" 2.3, last para: A complicated dance between things with weight and without weight is going on. It is unclear why. My guess is that this description was choosen because it is a reasonably simple way of describing the results we want. If that's the case, please add a sentence or so saying something like "The following procedure describes a way to do things, any other procedure that achieves the same results is okay, too." Low-level editorial: "with language ranges ... remain" -> "with language ranges ... remaining" 3.1, first para: "Sometimes, different styles of matching might be suited" -> "Sometimes, different styles of matching are suited" General: There are way too many "might"s, "would"s, "could"s, and so on in the document. If something is labeled as an example, it's clear that it's just an example, so no need for these. Similar if there is a qualifier such as "Sometimes". Please go through the document and eliminate these as much as possible. (changing "might" to "may" is somewhat problematic, but often "can" works well) 3.1, nubered list item 3: "language tags find the _exactly_" -> "language tags to find _exactly_" following para: "They might also be used" -> "Documents can also be used" following para: "no content's lanugage tag" -> "no language tag" (simpler to read) following para: "and speeds the performance" -> "and speeds up the performance" (or "and improves the performance") following para: "into modern equivalents" -> "into their newer equivalents" ('modern' may sound very outdated in a little while) last para: I was expecting something (e.g. an example) using suppress-script here. Can you add one? 3.2, first para: "large number of matching items: as many items" -> "large number of matching items, as many items" (I'd be fine with the colon if there wasn't another comma later) following para: "In filtering, the language range represents the _least_ specific (that is, the fewest number of subtags) language tag" -> "In filtering, the language range represents the _least_ specific language tag (that is, language tag with the fewest number of subtags)" following para: This paragraph says virtually the same as the para following the bullet list. Please move them together and merge them as appropriate. Maybe we should also say that even if an item matches two language ranges in the language priority list, it is still only returned once (for the language range with the higher priority). 3.2.1: This doesn't mention case-insensitivity, whereas 3.2.2 does. Please make very sure that case-insensitivity is either mentioned always or never (except for the very general principle), otherwise some careful readers will get confused. 3.2.2: This seems underspecified or unclear. For example, does de-DE also match de-Latn-DE, or not? The way I read the description, it does, but then the wildcard is somewhat pointless. (I have seen that Addison started to discuss this, so I'll try to follow that discussion and chime in there). 3.3: The sentences in the following para are just too long. Please try to split. If you can't, please ask for help. This scheme allows some flexibility in finding a match. For example, lookup provides better results for cases in which content is not available that exactly matches the user request than if the default language for the system or content were returned immediately. Not every specific level of tag granularity is usually available or language content may be sparsely populated, so "falling back" through the subtag sequence provides more opportunity to find a match between available language tags and the user's request. 3.3, example "fr-FR; zh-Hant": I don't see the reason for having a sublist in point 5. Either have sublists for fr-FR and zh-Hant, too, or just a single list (preferred). Btw, I thought that at some point, we adopted the policy of writing what all these abbreviations mean. In many places, that information is now missing. two paras later: What if the "*" is not the only one, but the last one? following 2 paras: Too much could and might. I'd propose that we just say "This document doesn't describe how to do lookup with extended language ranges. If a protocol thinks it needs to use that, it has to define it on its own." 4.1., first para: "for a given user" -> "for a user" 4.1., 2nd para: "is usually compared" -> "is compared" (there is already the qualifier "Most" at the start of the para) 4.1., 3rd para: Yes for filtering, NO for lookup, please say so (a lot of 4.1 reads as if there were no lookup at all) 4.1., 4th para: "Thus the language range "en-Latn" is probably inappropriate in most cases" -> "Thus the language range "en-Latn" is inappropriate in most cases" ('in most cases' already qualifies) same para: please don't assume too much knowledge of the registry stuff, and explain that the suppress-script field means that english using Latin is tagged en, not en-Latn. next para, "When used in language tags (as opposed to ranges) ..." Again, true for filtering, but reverse for lookup! next para: "filtering (Section 3.2) matching schemes described below" leftover from previous edit? last sentence: again, Yes for filtering, but NO for lookup next para, last sentence: "on the other end of the protocol that would make use of that information." -> "on the other end of the protocol." 4.4 Change title to "Length Considerations for Language Ranges" or so. "The same types of restrictions ... could also apply" Well, do they, or do they not? Better to reword as follows: "Some of the length restrictions for language ranges described in Section 4.3 (Length Considerations) of [RFC3066bis] also apply to language ranges. Please check [RFC3066bis] to understand the restrictions and implications. (I think that some of the thoughest restrictions on language tags DO NOT apply to language ranges, in particular those in the case of adding language information to email headers (which I always considered overengineering, but that's a separate issue).) General: There was a matching scheme in RFC 3066. Our document should say which of our schemes corresponds (or comes closest) to that. 5. IANA Considerations: Should we add a notice to the RFC Editor to remove this section for the final publication? 6.: Completely out of date, please remove. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 04:47:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkPa-0000Z2-U9; Thu, 02 Mar 2006 04:47:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEkPa-0000WF-1i for ltru@lists.ietf.org; Thu, 02 Mar 2006 04:47:54 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEkPZ-0006GU-Db for ltru@lists.ietf.org; Thu, 02 Mar 2006 04:47:54 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k229lou15839; Thu, 2 Mar 2006 18:47:50 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 71c4_9c816d68_a9d1_11da_9b8b_0014221fa3c9; Thu, 02 Mar 2006 18:47:49 +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 k229kTDb006476; Thu, 2 Mar 2006 18:47:12 +0900 Message-Id: <6.0.0.20.2.20060302183815.0918d190@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 02 Mar 2006 18:44:52 +0900 To: "Addison Phillips" , From: Martin Duerst Subject: Re: [Ltru] comments on draft-10 In-Reply-To: <001101c63d5b$5fd12c60$660a0a0a@ds.corp.yahoo.com> References: <001101c63d5b$5fd12c60$660a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 03:10 06/03/02, Addison Phillips wrote: >I have just a few substantive observations: > >1. For some reason the formulation "applications, protocols, and >specifications" was rendered as "applications, protocols, and >implementations" in a few places. I fixed this. > >2. In the penultimate paragraph in Section 3.1 (choosing types of >matching), I think we should include this normative text directly after >stating that the schemes don't require the registry or validation: > >-- >An implementation MAY choose to check if either the language ranges or >language tags being matched are "well-formed" or "valid" (see target="RFC3066bis" />, Section 2.2.9) and MAY choose not to process >invalid ranges. >-- > >This will make it clear that, while checking is not required, it is permitted. > >3. I think we need to change one aspect of extended range matching: I don't >think the match should proceed past singletons unless the singleton is >"named" in the range. Currently the range "de-DE" would match "de-x-DE", >which I find problematic. Thus I'd propose changing the third paragraph in >Section 3.2.2 from: > >-- >Take each non-wildcard subtag in the language range and compare it to the >next subtag in the language tag in turn until a matching subtag is found or >the langauge tag is exhausted. If the end of the language tag is found >first, the match fails. If a match is found, this step is repeated with the >next non-wildcard subtag in the language range (and beginning with the next >subtag in the language tag) until the list of subtags in the language range >is exhausted or the match fails. >-- > >To read: > >Take each non-wildcard subtag in the language range and compare it in a >case-insensitive manner to the next subtag in the language tag. If the >range's subtag exactly matches the tag's subtag, proceed to the next >non-wildcard subtag in the language range (and beginning with the next >subtag in the language tag) until the list of subtags in the language range >is exhausted or the match fails. If the tag's subtag is a "singleton" (a >single letter or digit, which, in this case, includes the private-use >subtag 'x') and the range's subtag does not match or if the language tag's >list of subtags is exhausted, the match fails. If the language range's list >of subtags is exhausted, the match succeeds. This text looks like it's way too complex. I'm not yet sure whether that's a problem of the wording, or of the thing we are trying to describe. >3a. I think we should include counter examples to the ones that match: > >-- >The same range does not match any of the following tags for the reasons >shown: > de (missing 'DE') > de-x-DE (singleton 'x' occurs before 'DE') > de-Deva ('Deva' not equal to 'DE') > > >-- Yes. But I'm also confused about de-DE. Would it match the same stuff as de-*-DE? If yes, why do we have wildcards (except in first place)? If this is indeed what we want (which I'm not sure about), please at least say so. >4. I think it would also be useful to point out in this same section the >fact that 3066bis tag structure makes ranges quite specific: > >Note: The structure of language tags defined by target="RFC3066bis" /> defines each subtag according to position, size, and >content. This means that the subtags in a language range can only match >specific types of subtags in a language tag. For example, a subtag such as >'Latn' is always a script subtag (unless it follows a singleton) while a >subtag such as 'nedis' can only match the equivalent variant subtag (unless >it follows a singleton). makes sense >5. In Section 3.3 (lookup) we show but say nothing about removing >singletons along with their just-following subtag, but we demonstrate it. I.e.: > >Zh-Hant-CN-x-private >Zh-Hant-CN > >It doesn't actually matter whether one does this or not, but should we say >anything? Probably yes. >6. Section 4.1 (Choosing language ranges). Should we mention that users >SHOULD choose well-formed, valid, canonicalized ranges? Yes. >Also, should we >again mention the ability for implementations to check for any of those >three attributes? Probably no. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 05:28:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEl2a-0000og-GD; Thu, 02 Mar 2006 05:28:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEl2Y-0000nV-OV for ltru@lists.ietf.org; Thu, 02 Mar 2006 05:28:10 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEl2X-0007kE-4k for ltru@lists.ietf.org; Thu, 02 Mar 2006 05:28:10 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k22ARtd14140; Thu, 2 Mar 2006 19:27:55 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 7deb_3636dbb4_a9d7_11da_8806_0014221f2a2d; Thu, 02 Mar 2006 19:27:55 +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 k22AQe2i006878; Thu, 2 Mar 2006 19:27:06 +0900 Message-Id: <6.0.0.20.2.20060302184951.091c9ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 02 Mar 2006 19:25:50 +0900 To: "Addison Phillips" , "'Mark Davis'" From: Martin Duerst Subject: RE: [Ltru] comments on draft-10 In-Reply-To: <000301c63d8a$240bc490$9fcd15ac@ds.corp.yahoo.com> References: <44061FA2.9060702@icu-project.org> <000301c63d8a$240bc490$9fcd15ac@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 08:44 06/03/02, Addison Phillips wrote: >Mark wrote: > >> I don't think this quite works, since that would have de-x-DE not >> matching de-x-DE. What I suggest is instead changing it to add instead: >> >> Extension and private use subtag sequences are treated as a single unit >> for the purpose of matching. Thus in matching de-DE against de-x-DE, the >> x-DE is treated as treated as a single unit, which does not match DE. > >No, because that prevents doing matching of private use or extension >sequences. There is no reason to break those matches. All my text means is >that you must EITHER: > >a. Specify the private use or extension in the range >b. Run out of range subtags before you get to the private use or extension >singleton. > >Maybe my text wasn't clear enough? Here is some perl code that implements >the algorithm proposed (not pretty, but I wrote it in five minutes): I'm rewriting this, to try to get a better understanding (and get rid of the double loop). [This code is removing subtags from the arrays of subtags (@range, @tag) with shift, and making use of the fact that if there is nothing to remove anymore, the 'undef' value (false) is returned.] sub match { @range = split(/-/, shift); @tag = split(/-/, shift); $rsubtag = shift @range; $subtag = shift @tag; if ($rsubtag eq "*") { # '*' in first position is special $rsubtag = shift @range; $subtag = shift @tag; } while ($rsubtag) { if ($rsubtag eq "*") { # ingnore non-initial '*'s $rsubtag = shift @range; } else if (!$subtag) { # ran out of subtags return 0; } else if (uc($rsubtag) eq uc($subtag)) { # check for equality $rsubtag = shift @range; $subtag = shift @tag; } else if (length($subtag) == 1) { # check for singletons return 0; } } return 1; # exhausted range first, match found >This correctly returns a "match" result for "de-x-DE" with "de-Latn-x-DE" >and a "non-match" for range "de-DE" with "de-x-DE". It's very asymetric, but that seems to be a result of the fact that singleton-started extensions always are at the end, yes? Regards, Martin. >Addison Phillips >Internationalization Architect - Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 10:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpjl-0007cD-5j; Thu, 02 Mar 2006 10:29:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEpjj-0007c8-Ub for ltru@ietf.org; Thu, 02 Mar 2006 10:29:03 -0500 Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEpji-0002Nn-NY for ltru@ietf.org; Thu, 02 Mar 2006 10:29:03 -0500 Received: (qmail 19936 invoked from network); 2 Mar 2006 15:29:01 -0000 Received: from unknown (HELO ?192.168.1.104?) (unknown) by unknown with SMTP; 2 Mar 2006 15:29:01 -0000 X-pair-Authenticated: 24.23.194.196 Message-ID: <44070F35.4060902@icu-project.org> Date: Thu, 02 Mar 2006 07:28:53 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] John Cowan's comments on matching-10 References: <20060302023956.GA21870@ccil.org> <000101c63db4$d9892810$660a0a0a@ds.corp.yahoo.com> <20060302050001.GC21870@ccil.org> In-Reply-To: <20060302050001.GC21870@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I like the changes. One more nit: needs semicolons either on all the non-final list elements or none. return content: with no language tag; of a non-linguistic nature, such as an image or sound; with an empty language tag value, in cases where the protocol permits the empty value (see, for example, "xml:lang" in [XML10] (Bray (et al), T., “Extensible Markup Language (XML) 1.0,” 02 2004.) , which indicates that the element contains non-linguistic content) in a particular language designated for the bit of content being selected; or it might select the tag "i-default" (see [RFC2277] (Alvestrand, H., “IETF Policy on Character Sets and Languages,” January 1998.) ) And it would look better bulleting, IMO. Mark John Cowan wrote: > Addison Phillips scripsit: > > >> Responses follow. >> > > +1 to everything not in this reply. > > >> The default behavior when no tag matches the language priority list is >> implementation-defined. An implementation might, for example, return >> content: >> >> with no language tag; >> >> of a non-linguistic nature, such as an image or sound; >> >> with an empty language tag value, in cases where the protocol permits >> the empty value (see, for example, "xml:lang" in , >> which indicates that the element contains non-linguistic content) >> >> in a particular language designated for the bit of >> content being selected; or >> >> it might select the tag "i-default" (see > />) >> > > This is good, except that the fifth point does not follow grammatically from > the lead-off. Change to 'labeled with the language tag with "i-default"' etc. > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 11:00:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqEJ-0001Vh-TO; Thu, 02 Mar 2006 11:00:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEqEI-0001Sv-TX for ltru@ietf.org; Thu, 02 Mar 2006 11:00:38 -0500 Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEqEI-0003vX-MF for ltru@ietf.org; Thu, 02 Mar 2006 11:00:38 -0500 Received: (qmail 32327 invoked from network); 2 Mar 2006 16:00:36 -0000 Received: from unknown (HELO ?192.168.1.104?) (unknown) by unknown with SMTP; 2 Mar 2006 16:00:36 -0000 X-pair-Authenticated: 24.23.194.196 Message-ID: <4407168E.9050807@icu-project.org> Date: Thu, 02 Mar 2006 08:00:14 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Martin's comments on draft-10 References: <6.0.0.20.2.20060302172527.091a9e50@localhost> In-Reply-To: <6.0.0.20.2.20060302172527.091a9e50@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: > ... > 2.3, last para: A complicated dance between things with weight and > without weight is going on. It is unclear why. My guess is that > this description was choosen because it is a reasonably simple > way of describing the results we want. If that's the case, > please add a sentence or so saying something like "The following > procedure describes a way to do things, any other procedure that > achieves the same results is okay, too." I suggest the following, using a bulleted list, and changing the order to be more logical. Where a language priority list provides "quality weights" for the language ranges, such as the use of Q weights in the syntax of the "Accept-Language" header (defined in [RFC2616]) , Section 14.4, and [RFC3282] ), they are handled in the following way. This is a logical description of the process -- implementations may provide the same results in different ways. Each example shows progressively what happens to the following initial example: Example: "fr, ar;q=0.0, en;q=0.5, fr, de, it;q=0.8". * If the first language range has no weight, it is given a weight of 1.0. Example: "fr;q=1.0, ar;q=0.0, en;q=0.5, fr, de, it;q=0.8". * Language ranges without a weight are given weights equal to the weights of the previous language range (processing from first to last). Example: "fr;q=1.0, ar;q=0.0, en;q=0.5, fr;q=0.5, de;q=0.5, it;q=0.8". * The language priority list is then sorted from highest priority to lowest, with language ranges that share the same weights remaining in the same order as in the original language priority list. Example: "fr;q=1.0, it;q=0.8, en;q=0.5, fr;q=0.5, de;q=0.5, ar;q=0.0". * Finally, language ranges are removed if they have zero weights or are duplicates of previous language ranges. Example: "fr;q=1.0, it;q=0.8, en;q=0.5, de;q=0.5". [ed note: didn't show the strikeout; that probably wouldn't show in the text version.] _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 12:47:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEru6-0004li-JB; Thu, 02 Mar 2006 12:47:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEru5-0004la-34 for ltru@ietf.org; Thu, 02 Mar 2006 12:47:53 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEru4-0008Rr-HB for ltru@ietf.org; Thu, 02 Mar 2006 12:47:53 -0500 Received: from duringpersonlx (nvvpn-c110.corp.yahoo.com [172.21.169.110]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k22Hlbvx090317; Thu, 2 Mar 2006 09:47:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:thread-index:x-mimeole; b=brgRpCftPe4bJf+6tlvf/Fer6pEvcG1uVftJ4QnZ7SA0TWhwC9paKigwmAmQxDJy From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Martin's comments on draft-10 Date: Thu, 2 Mar 2006 09:49:36 -0800 Message-ID: <000301c63e21$ac97cbf0$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6.0.0.20.2.20060302172527.091a9e50@localhost> Thread-Index: AcY93Hh6Fb2a6yl8RzOoFbpjJjbT+QANfBpQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: dfc64cf6e4c6efdbf6b8f4c995df04df Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Comments follow, some substantive. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 2006?3?2? 1:30 > To: LTRU Working Group > Subject: [Ltru] Martin's comments on draft-10 > > Here are my technical comments on draft-ietf-ltru-matching-10: > > Abstract, first sentence: Remove "evaluating", no idea what that > means or where the matching draft makes this possible. Done. > > 2.2, first para: "all language tags that constrains" -> > "all language tags that constrain" Done. > > 2.2, second-to-last para: "However wildcards" -> > "However, wildcards" Done. > > 2.3, last para: A complicated dance between things with weight and > without weight is going on. It is unclear why. My guess is that > this description was choosen because it is a reasonably simple > way of describing the results we want. If that's the case, > please add a sentence or so saying something like "The following > procedure describes a way to do things, any other procedure that > achieves the same results is okay, too." First, an observation: this text was necessary for scoring and has no bearing on any of the remaining matching schemes (although we might mention it in lookup). As such, it is now too specific. Instead I propose this deeper rewrite: -- Some language priority lists provide "quality weights" for the language ranges in order to specify the relative priority of the user's language preferences. An example of this would be the use of "q" values in the syntax of the "Accept-Language" header (defined in , Section 14.4, and ). If a protocol, application, or specification needs to assign a weight to a language range which lacks one in a list, one possible process for assigning the weight might be to assign the range the same value as that of the preceeding language range. If the first language range has no weight, it is given the highest possible value (which would, for example, be "1.0" for Accept-Language). Language ranges with zero weights might be removed or they might be treated as meaning "do not return any tags that match this range". 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 SHOULD be sorted from highest priority to lowest. If weight values have been assigned to items in the list, language ranges that share the same weights SHOULD remain in the same order as in the original language priority list. -- > > Low-level editorial: > "with language ranges ... remain" -> > "with language ranges ... remaining" Text changed. > > 3.1, first para: "Sometimes, different styles of matching might be suited" > -> "Sometimes, different styles of matching are suited" "are suited to" Done. > > General: There are way too many "might"s, "would"s, "could"s, and so on > in the document. If something is labeled as an example, it's > clear that it's just an example, so no need for these. > Similar if there is a qualifier such as "Sometimes". > Please go through the document and eliminate these as much > as possible. (changing "might" to "may" is somewhat problematic, > but often "can" works well) I don't have time right now. I might get to that this weekend. The use of fudge words was to avoid 2119 keywords in another massive edit in the past. > > 3.1, nubered list item 3: "language tags find the _exactly_" -> > "language tags to find _exactly_" "language tags to find the one exact language tag" > > following para: "They might also be used" -> > "Documents can also be used" I don't see this sentence? > > following para: "no content's lanugage tag" -> > "no language tag" > (simpler to read) It is simpler to read, but it is reminder readers of a subtle point: there is a difference between the tag and content. I modified slightly to read: -- Since the process can return only one item, it must choose a single item and it must return some item, even if none of the content's language tags match the language priority list supplied by the user. -- > > following para: "and speeds the performance" -> > "and speeds up the performance" > (or "and improves the performance") "Speeds" is already removed, since performance enhancement has never been measured and this claim is merely "advertising". > > following para: "into modern equivalents" -> > "into their newer equivalents" > ('modern' may sound very outdated in a little while) No. "Modern" is an ever-changing target. We could add the weasel word "more modern". > > last para: I was expecting something (e.g. an example) using > suppress-script here. Can you add one? Arg. No. We deal with that at length in section 4.1 and I feel it is out of place here. We *permit* an implementation to use the registry for whatever nefarious purposes but an example would just clutter up the text. If we needed to have one, I suppose we could take one of the grandfathered-and-obsolete tags: For example, an implementation might replace the range "art-lojban" with its Preferred-Value "jbo". > > 3.2, first para: "large number of matching items: as many items" > -> "large number of matching items, as many items" > (I'd be fine with the colon if there wasn't > another comma later) No, this is proper use of a colon: it points to an important point, not merely another phrase. It could be split into two sentences, but that would reduce the impact. > > following para: "In filtering, the language range represents the _least_ > specific (that is, the fewest number of subtags) > language tag" -> > "In filtering, the language range represents the _least_ > specific language tag (that is, language tag with > the fewest number of subtags)" Done. > > following para: This paragraph says virtually the same as the para > following the bullet list. Please move them together > and merge them as appropriate. > > Maybe we should also say that even if an item matches > two language ranges in the language priority list, it > is still only returned once (for the language range > with the higher priority). They were merged and rewritten in last night's edit for John Cowan's comments. > > 3.2.1: This doesn't mention case-insensitivity, whereas 3.2.2 does. > Please make very sure that case-insensitivity is either mentioned > always or never (except for the very general principle), otherwise > some careful readers will get confused. Agreed. Changed the main sentence to read: -- A particular language tag matches a language range if, in a case-insensitive comparison, it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first character following the prefix is "-". -- > > 3.2.2: This seems underspecified or unclear. For example, does > de-DE also match de-Latn-DE, or not? The way I read the > description, it does, but then the wildcard is somewhat > pointless. (I have seen that Addison started to discuss > this, so I'll try to follow that discussion and chime in > there). Already dealt with in draft-11. See other thread as noted. > > 3.3: The sentences in the following para are just too long. > Please try to split. If you can't, please ask for help. > > This scheme allows some flexibility in finding a match. For example, > lookup provides better results for cases in which content is not > available that exactly matches the user request than if the default > language for the system or content were returned immediately. Not > every specific level of tag granularity is usually available or > language content may be sparsely populated, so "falling back" through > the subtag sequence provides more opportunity to find a match between > available language tags and the user's request. I'm not a big fan of this para, but the thoughts it contains are somewhat difficult to do very much with. I was able to split one sentence: -- This scheme allows some flexibility in finding a match. For example, lookup provides better results for cases in which content is not available that exactly matches the user request than if the default language for the system or content were returned immediately. Not every specific level of tag granularity is usually available or language content may be sparsely populated. "Falling back" through the subtag sequence provides more opportunity to find a match between available language tags and the user's request. -- > > 3.3, example "fr-FR; zh-Hant": I don't see the reason for having > a sublist in point 5. Either have sublists for fr-FR and > zh-Hant, too, or just a single list (preferred). The point is that number five is the implementation inserting the range "ja-JP" into the search sequence and the finding its implementation defined default. It calls out the fact that you are switching modes and where you do it (*after* the user's list is exhausted). > > Btw, I thought that at some point, we adopted the policy of > writing what all these abbreviations mean. In many places, > that information is now missing. Point them out, although I note that in these examples the meaning of the tags adds little to the understanding of the reader. > > two paras later: What if the "*" is not the only one, but the last one? Also fixed last night: -- If the language range "*" is the only one in the language priority list or if no other language range follows, the default content SHOULD be returned. -- > > following 2 paras: Too much could and might. I'd propose that we just > say "This document doesn't describe how to do lookup with > extended language ranges. If a protocol thinks it needs > to use that, it has to define it on its own." We could do that. But this is only here because someone else felt it important and I don't see an overriding reason to remove it at the moment. > > 4.1., first para: "for a given user" -> "for a user" Done. > > 4.1., 2nd para: "is usually compared" -> "is compared" > (there is already the qualifier "Most" at the start of the para) Done, although this para also has picked up a normative statement in response to my previous question: -- Most matching schemes make no attempt to process the semantic meaning of the subtags and the language range is compared, in a case-insensitive manner, to each language tag being matched, using basic string processing. Users SHOULD select language ranges that are well-formed, valid language tags according to (substituting wildcards as appropriate in extended language ranges). -- I also followed it with this para: -- Users SHOULD replace tags or subtags which have been deprecated with the Preferred-Value from the IANA Language Subtag Registry. If the user is working with content that might use the older form, the user might include both the new and old forms in a language priority list. For example, the tag "art-lojban" is deprecated. The subtag "jbo" is supposed to be used instead or the user might include both in a language priority list: "jbo; art-lojban". -- > > 4.1., 3rd para: Yes for filtering, NO for lookup, please say so > (a lot of 4.1 reads as if there were no lookup at all) Already done. > > 4.1., 4th para: "Thus the language range "en-Latn" is probably > inappropriate in most cases" -> "Thus the language range "en-Latn" > is > inappropriate in most cases" > ('in most cases' already qualifies) Done. > > same para: please don't assume too much knowledge of the registry stuff, > and explain that the suppress-script field means that english using > Latin is tagged en, not en-Latn. Para read: -- Most notably, script subtags SHOULD NOT be used to form a language range in combination with language subtags that have a matching Suppress-Script field in their registry entry. Thus the language range "en-Latn" is probably inappropriate in most cases (because the vast majority of English documents are written in the Latin script and thus the 'en' language subtag has a Suppress-Script field for 'Latn' in the registry). -- Para changed to: -- Many languages are written predominantly in a single script. This is usually recorded in the Suppress-Script field in that language subtag's registry entry. For these languages, script subtags SHOULD NOT be used to form a language range. Thus the language range "en-Latn" is inappropriate in most cases (because the vast majority of English documents are written in the Latin script and thus the 'en' language subtag has a Suppress-Script field for 'Latn' in the registry). -- > > next para, "When used in language tags (as opposed to ranges) ..." > Again, true for filtering, but reverse for lookup! It says this. -- When used in language tags (as opposed to ranges), these subtags normally do not interfere with filtering, since they appear at the end of the tag and will match all prefixes. -- > > next para: "filtering (Section 3.2) matching schemes described below" > leftover from previous edit? Since we have essentially the same requirement twice, I merged paras to read: -- When working with tags and ranges, note that extensions and most private-use subtags are orthogonal to language tag matching, in that they specify additional attributes of the text not related to the goals of most matching schemes. Users SHOULD avoid using these subtags in language ranges, since they interfere with the selection of available content. When used in language tags (as opposed to ranges), these subtags normally do not interfere with filtering, since they appear at the end of the tag and will match all prefixes. Lookup implementations often ignore unrecognized private-use and extension subtags when performing language tag fallback. -- > > last sentence: again, Yes for filtering, but NO for lookup All gone in merge above. > > next para, last sentence: "on the other end of the protocol that > would make use of that information." -> "on the other end of > the protocol." Changed " to services on the other end of the protocol" to "elsewhere" > > 4.4 Change title to "Length Considerations for Language Ranges" > or so. Done. > > "The same types of restrictions ... could also apply" Changed "could" => "can" > Well, do they, or do they not? Better to reword as follows: > "Some of the length restrictions for language ranges described > in Section 4.3 (Length Considerations) of [RFC3066bis] also apply > to language ranges. Please check [RFC3066bis] to understand > the restrictions and implications. They might apply: it depends on the context (the protocol, application, or specification). Changed para to: -- Language ranges are very similar to language tags in terms of content and usage. The same types of restrictions on length that apply to language tags can also apply to language ranges. See Section 4.3 (Length Considerations). -- > > (I think that some of the thoughest restrictions on language > tags DO NOT apply to language ranges, in particular those > in the case of adding language information to email headers > (which I always considered overengineering, but that's a > separate issue).) Yes, which is why we dumped all this text in favor of a reference to the Sternly Worded section 4.3 in 3066bis. > > General: There was a matching scheme in RFC 3066. Our document > should say which of our schemes corresponds (or comes closest) > to that. Done. Added this to the end of 3.2.1 (Basic Filtering): Basic filtering is identical to the type of matching described in , Section 2.5 (Language-range). > > 5. IANA Considerations: Should we add a notice to the RFC Editor > to remove this section for the final publication? Currently this is a placeholder. > > 6.: Completely out of date, please remove. Placeholding for now. > > > Regards, Martin. > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 12:50:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FErwY-0000ie-VE; Thu, 02 Mar 2006 12:50:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FErwX-0000iY-2Y for ltru@ietf.org; Thu, 02 Mar 2006 12:50:25 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FErwW-0000Ao-QR for ltru@ietf.org; Thu, 02 Mar 2006 12:50:25 -0500 Received: from duringpersonlx (nvvpn-c110.corp.yahoo.com [172.21.169.110]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k22Ho79S090504; Thu, 2 Mar 2006 09:50:07 -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: thread-index:x-mimeole; b=O9PvZF+Q9YGGl5AUybnV/xEqKHqOI41kNPfTnHpwqS0/7aZuVqeAdIcwt2H6uqEE From: "Addison Phillips" To: "'Mark Davis'" , "'Martin Duerst'" Subject: RE: [Ltru] Martin's comments on draft-10 Date: Thu, 2 Mar 2006 09:51:58 -0800 Message-ID: <000401c63e22$013f8cb0$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4407168E.9050807@icu-project.org> Thread-Index: AcY+EoGFd3RUNE7qSmuHLId0QT6XDQADz2lw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I'd rather have *less* text about this process than more. This mostly = fed and cared for scoring (where the weight values themselves were = important). It's only importance in this document is the last = step--reordering the list for the convenience of lookup implementers. Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006=E5=B9=B43=E6=9C=882=E6=97=A5 8:00 > To: Martin Duerst > Cc: LTRU Working Group > Subject: Re: [Ltru] Martin's comments on draft-10 >=20 >=20 >=20 > Martin Duerst wrote: > > ... > > 2.3, last para: A complicated dance between things with weight and > > without weight is going on. It is unclear why. My guess is that > > this description was choosen because it is a reasonably simple > > way of describing the results we want. If that's the case, > > please add a sentence or so saying something like "The = following > > procedure describes a way to do things, any other procedure = that > > achieves the same results is okay, too." > I suggest the following, using a bulleted list, and changing the order > to be more logical. >=20 > Where a language priority list provides "quality weights" for the > language ranges, such as the use of Q weights in the syntax of the > "Accept-Language" header (defined in [RFC2616]) > = = , > Section 14.4, and [RFC3282] > = = ), > they are handled in the following way. This is a logical description = of > the process -- implementations may provide the same results in = different > ways. Each example shows progressively what happens to the following > initial example: >=20 > Example: "fr, ar;q=3D0.0, en;q=3D0.5, fr, de, it;q=3D0.8". >=20 > * If the first language range has no weight, it is given a weight of = 1.0. >=20 > Example: "fr;q=3D1.0, ar;q=3D0.0, en;q=3D0.5, fr, de, = it;q=3D0.8". >=20 > * Language ranges without a weight are given weights equal to the > weights of the previous language range (processing from first to = last). >=20 > Example: "fr;q=3D1.0, ar;q=3D0.0, en;q=3D0.5, fr;q=3D0.5, > de;q=3D0.5, it;q=3D0.8". >=20 > * The language priority list is then sorted from highest priority to > lowest, with language ranges that share the same weights remaining in > the same order as in the original language priority list. >=20 > Example: "fr;q=3D1.0, it;q=3D0.8, en;q=3D0.5, fr;q=3D0.5, > de;q=3D0.5, ar;q=3D0.0". >=20 > * Finally, language ranges are removed if they have zero weights or = are > duplicates of previous language ranges. >=20 > Example: "fr;q=3D1.0, it;q=3D0.8, en;q=3D0.5, de;q=3D0.5". >=20 > [ed note: didn't show the strikeout; that probably wouldn't show in = the > text version.] >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 12:56:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEs23-0001Os-VY; Thu, 02 Mar 2006 12:56:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEs22-0001M7-OG for ltru@lists.ietf.org; Thu, 02 Mar 2006 12:56:06 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEs21-0000PC-IP for ltru@lists.ietf.org; Thu, 02 Mar 2006 12:56:06 -0500 Received: from duringpersonlx (nvvpn-c110.corp.yahoo.com [172.21.169.110]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k22Htkwl091037; Thu, 2 Mar 2006 09:55:47 -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: thread-index:x-mimeole; b=wGVJb4Rglufm17S4X0yTQ/sW6u8dyKFfeO1DjltxNRImN9zfIsSp3EUS8iKGdV0+ From: "Addison Phillips" To: "'Martin Duerst'" , "'Mark Davis'" Subject: RE: [Ltru] comments on draft-10 Date: Thu, 2 Mar 2006 09:57:29 -0800 Message-ID: <000501c63e22$c6575460$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6.0.0.20.2.20060302184951.091c9ec0@localhost> Thread-Index: AcY94/9+zbY2rmVwRROokRuo4ByZfQAPlMfw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Much nicer code. I can tell you spent at least 6 minutes on it. :-) > It's very asymetric, but that seems to be a result of the fact that > singleton-started extensions always are at the end, yes? Yes. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 13:06:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsC2-0004Rk-LN; Thu, 02 Mar 2006 13:06:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsC2-0004Rf-1n for ltru@lists.ietf.org; Thu, 02 Mar 2006 13:06:26 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEsC1-0000lT-RG for ltru@lists.ietf.org; Thu, 02 Mar 2006 13:06:26 -0500 Received: from duringpersonlx (nvvpn-c110.corp.yahoo.com [172.21.169.110]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k22I6Auc092052; Thu, 2 Mar 2006 10:06:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:thread-index:x-mimeole; b=yc0pe7u5KWXqmN9YgJe6xpfw5KYAf1rT0jskchrz/75MR5s8POPQq/Q+uxk0x9ma From: "Addison Phillips" To: "'Martin Duerst'" , Subject: RE: [Ltru] comments on draft-10 Date: Thu, 2 Mar 2006 10:07:48 -0800 Message-ID: <000601c63e24$37753210$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6.0.0.20.2.20060302183815.0918d190@localhost> Thread-Index: AcY93nWAMVDycoIITLy3V4U33q+UcgARGEAQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > > >To read: > > > >Take each non-wildcard subtag in the language range and compare it in > a > >case-insensitive manner to the next subtag in the language tag. If the > >range's subtag exactly matches the tag's subtag, proceed to the next > >non-wildcard subtag in the language range (and beginning with the next > >subtag in the language tag) until the list of subtags in the language > range > >is exhausted or the match fails. If the tag's subtag is a "singleton" (a > >single letter or digit, which, in this case, includes the private-use > >subtag 'x') and the range's subtag does not match or if the language > tag's > >list of subtags is exhausted, the match fails. If the language range's > list > >of subtags is exhausted, the match succeeds. > > This text looks like it's way too complex. I'm not yet sure whether that's > a problem of the wording, or of the thing we are trying to describe. The wording most likely. Ideally this would be broken up into steps. > > >3a. I think we should include counter examples to the ones that match: > > > >-- > >The same range does not match any of the following tags for the > reasons > >shown: > > de (missing 'DE') > > de-x-DE (singleton 'x' occurs before 'DE') > > de-Deva ('Deva' not equal to 'DE') > > > > > >-- > > Yes. > > But I'm also confused about de-DE. Would it match the same stuff as > de-*-DE? If yes, why do we have wildcards (except in first place)? > If this is indeed what we want (which I'm not sure about), please > at least say so. "de-DE" and "de-*-DE" both match the same stuff. This is what we want. The subtle bit is: we define the extended language range (XLR) separately from the algorithm. Other schemes that people come up with in the future (such as scoring) might assign different semantics to "de-DE" and "de-*-DE". Thus the XLR syntax allows them even though extended filtering makes no use of them. > > >5. In Section 3.3 (lookup) we show but say nothing about removing > >singletons along with their just-following subtag, but we demonstrate it. > I.e.: > > > >Zh-Hant-CN-x-private > >Zh-Hant-CN > > > >It doesn't actually matter whether one does this or not, but should we > say > >anything? > > Probably yes. Okay. Done. > > >6. Section 4.1 (Choosing language ranges). Should we mention that users > >SHOULD choose well-formed, valid, canonicalized ranges? > > Yes. Done per last mail. > > >Also, should we > >again mention the ability for implementations to check for any of those > >three attributes? > > Probably no. > > > Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 13:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsZP-0000Zj-Vo; Thu, 02 Mar 2006 13:30:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEsZP-0000WV-8M for ltru@ietf.org; Thu, 02 Mar 2006 13:30:35 -0500 Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FEsZN-0001Tw-UY for ltru@ietf.org; Thu, 02 Mar 2006 13:30:35 -0500 Received: (qmail 82853 invoked from network); 2 Mar 2006 18:30:33 -0000 Received: from unknown (HELO ?172.19.9.252?) (unknown) by unknown with SMTP; 2 Mar 2006 18:30:33 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <440739C7.9080109@icu-project.org> Date: Thu, 02 Mar 2006 10:30:31 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Martin's comments on draft-10 References: <000401c63e22$013f8cb0$660a0a0a@ds.corp.yahoo.com> In-Reply-To: <000401c63e22$013f8cb0$660a0a0a@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org That's not true; if you are using it for plain lookup, the items have to be in the right order; and this is what tells you what that order *is*, when there are weights, since otherwise it is completely underspecified. Mark Addison Phillips wrote: > I'd rather have *less* text about this process than more. This mostly fed and cared for scoring (where the weight values themselves were important). It's only importance in this document is the last step--reordering the list for the convenience of lookup implementers. > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > >> -----Original Message----- >> From: Mark Davis [mailto:mark.davis@icu-project.org] >> Sent: 2006年3月2日 8:00 >> To: Martin Duerst >> Cc: LTRU Working Group >> Subject: Re: [Ltru] Martin's comments on draft-10 >> >> >> >> Martin Duerst wrote: >> >>> ... >>> 2.3, last para: A complicated dance between things with weight and >>> without weight is going on. It is unclear why. My guess is that >>> this description was choosen because it is a reasonably simple >>> way of describing the results we want. If that's the case, >>> please add a sentence or so saying something like "The following >>> procedure describes a way to do things, any other procedure that >>> achieves the same results is okay, too." >>> >> I suggest the following, using a bulleted list, and changing the order >> to be more logical. >> >> Where a language priority list provides "quality weights" for the >> language ranges, such as the use of Q weights in the syntax of the >> "Accept-Language" header (defined in [RFC2616]) >> , >> Section 14.4, and [RFC3282] >> ), >> they are handled in the following way. This is a logical description of >> the process -- implementations may provide the same results in different >> ways. Each example shows progressively what happens to the following >> initial example: >> >> Example: "fr, ar;q=0.0, en;q=0.5, fr, de, it;q=0.8". >> >> * If the first language range has no weight, it is given a weight of 1.0. >> >> Example: "fr;q=1.0, ar;q=0.0, en;q=0.5, fr, de, it;q=0.8". >> >> * Language ranges without a weight are given weights equal to the >> weights of the previous language range (processing from first to last). >> >> Example: "fr;q=1.0, ar;q=0.0, en;q=0.5, fr;q=0.5, >> de;q=0.5, it;q=0.8". >> >> * The language priority list is then sorted from highest priority to >> lowest, with language ranges that share the same weights remaining in >> the same order as in the original language priority list. >> >> Example: "fr;q=1.0, it;q=0.8, en;q=0.5, fr;q=0.5, >> de;q=0.5, ar;q=0.0". >> >> * Finally, language ranges are removed if they have zero weights or are >> duplicates of previous language ranges. >> >> Example: "fr;q=1.0, it;q=0.8, en;q=0.5, de;q=0.5". >> >> [ed note: didn't show the strikeout; that probably wouldn't show in the >> text version.] >> >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 14:21:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtMk-0000eZ-G8; Thu, 02 Mar 2006 14:21:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEtMi-0000YV-67 for ltru@ietf.org; Thu, 02 Mar 2006 14:21:33 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEtMf-0003dm-Pv for ltru@ietf.org; Thu, 02 Mar 2006 14:21:32 -0500 Received: from duringpersonlx (nvvpn-c110.corp.yahoo.com [172.21.169.110]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k22JKtJi099791; Thu, 2 Mar 2006 11:20:56 -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: thread-index:x-mimeole; b=JdombsMX4Ifjwo1qcHZxJi9onxB/MlAsNkyjkdLYd/5OkEKhzS0dCVnbpfSz0oYI From: "Addison Phillips" To: "'Mark Davis'" Subject: RE: [Ltru] Martin's comments on draft-10 Date: Thu, 2 Mar 2006 11:22:46 -0800 Message-ID: <000701c63e2e$b0c4c0e0$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <440739C7.9080109@icu-project.org> Thread-Index: AcY+J3XwByOzbankSoueRE/Qdr6m8QABNfkw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org You're right that lookup relies on the list being ordered. But the = assignment of weights isn't strictly necessary: only the ordering of the = list is strictly necessary. A list with no weights but in priority order = (hence, one suspects "language PRIORITY list") serves just as well. I agree that the current text does a good job and I'm not in favor or = removing it. But I'm also not in favor of scads more text about it, = since we don't use the weights for anything and we don't say anything = normative about weighting lists. For that matter, we don't even define = q-weighting here. It is an artifact of RFC 2616. If we prescribed weight = values we might run afoul of existing implementations that assign = weights... to no good purpose. All that said, I agree that the current bulky paragraphs leave a lot to = be desired. I've split them up like this: -- The various matching operations described in this document include = considerations for using a language priority list. This document does = not define the syntax for a language priority list; defining such a = syntax is the responsibility of the protocol, application, or = specification that uses it. When given as examples in this document, = language priority lists will be shown as a quoted sequence of ranges = separated by commas, like this: "en, fr, zh-Hant" (which would be read = as "English before French before Chinese as written in the Traditional = script"). Some language priority lists provide "quality weights" for the = language ranges in order to specify the relative priority of the user's = language preferences. An example of this would be the use of "q" values = in the syntax of the "Accept-Language" header (defined in , Section 14.4, and ). If a protocol, application, or specification needs to assign a weight = to a language range which lacks one in a list, a good strategy would be = to assign the range the same value as that of the preceding language = range. If the first language range has no weight, it is given the = highest possible value (which would, for example, be "1.0" for = Accept-Language). Language ranges with zero weights might be removed or = they might be treated as meaning "do not return content for any tags = that match this range". For example, the list "fr, en;q=3D0.5, de, it" = might become "fr;q=3D1.0, en;q=3D0.5, de;q=3D0.5, it;q=3D0.5". Regardless of whether weights are assigned or not, the language = priority list SHOULD be sorted from highest priority to lowest. If = weight values have been assigned to some items in the list, language = ranges that share the same weights SHOULD remain in the same order as in = the original language priority list, since the order of the list carries = meaning for some matching schemes (such as lookup). -- I've dithered about saying "the language priority list SHOULD always be = sorted" (i.e. insert "always"). NB> I've changed the language priority list examples in the text to use = comma separators, since that's what accept-language actually uses. This = allowed me to keep the Accept-language example just quoted above intact = without immediately following the statement "all examples of LPLs in = this document...use semi-colon" with something else! Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006=E5=B9=B43=E6=9C=882=E6=97=A5 10:31 > To: Addison Phillips > Cc: 'Martin Duerst'; 'LTRU Working Group' > Subject: Re: [Ltru] Martin's comments on draft-10 >=20 > That's not true; if you are using it for plain lookup, the items have = to > be in the right order; and this is what tells you what that order = *is*, > when there are weights, since otherwise it is completely = underspecified. >=20 > Mark >=20 > Addison Phillips wrote: > > I'd rather have *less* text about this process than more. This = mostly > fed and cared for scoring (where the weight values themselves were > important). It's only importance in this document is the last step-- > reordering the list for the convenience of lookup implementers. > > > > Addison Phillips > > Internationalization Architect - Yahoo! Inc. > > > > Internationalization is an architecture. > > It is not a feature. > > > > > >> -----Original Message----- > >> From: Mark Davis [mailto:mark.davis@icu-project.org] > >> Sent: 2006=E5=B9=B43=E6=9C=882=E6=97=A5 8:00 > >> To: Martin Duerst > >> Cc: LTRU Working Group > >> Subject: Re: [Ltru] Martin's comments on draft-10 > >> > >> > >> > >> Martin Duerst wrote: > >> > >>> ... > >>> 2.3, last para: A complicated dance between things with weight and > >>> without weight is going on. It is unclear why. My guess is = that > >>> this description was choosen because it is a reasonably = simple > >>> way of describing the results we want. If that's the case, > >>> please add a sentence or so saying something like "The = following > >>> procedure describes a way to do things, any other procedure = that > >>> achieves the same results is okay, too." > >>> > >> I suggest the following, using a bulleted list, and changing the = order > >> to be more logical. > >> > >> Where a language priority list provides "quality weights" for the > >> language ranges, such as the use of Q weights in the syntax of the > >> "Accept-Language" header (defined in [RFC2616]) > >> 11.html#RFC2616>, > >> Section 14.4, and [RFC3282] > >> 11.html#RFC3282>), > >> they are handled in the following way. This is a logical = description > of > >> the process -- implementations may provide the same results in > different > >> ways. Each example shows progressively what happens to the = following > >> initial example: > >> > >> Example: "fr, ar;q=3D0.0, en;q=3D0.5, fr, de, it;q=3D0.8". > >> > >> * If the first language range has no weight, it is given a weight = of > 1.0. > >> > >> Example: "fr;q=3D1.0, ar;q=3D0.0, en;q=3D0.5, fr, de, = it;q=3D0.8". > >> > >> * Language ranges without a weight are given weights equal to the > >> weights of the previous language range (processing from first to = last). > >> > >> Example: "fr;q=3D1.0, ar;q=3D0.0, en;q=3D0.5, = fr;q=3D0.5, > >> de;q=3D0.5, it;q=3D0.8". > >> > >> * The language priority list is then sorted from highest priority = to > >> lowest, with language ranges that share the same weights remaining = in > >> the same order as in the original language priority list. > >> > >> Example: "fr;q=3D1.0, it;q=3D0.8, en;q=3D0.5, = fr;q=3D0.5, > >> de;q=3D0.5, ar;q=3D0.0". > >> > >> * Finally, language ranges are removed if they have zero weights or = are > >> duplicates of previous language ranges. > >> > >> Example: "fr;q=3D1.0, it;q=3D0.8, en;q=3D0.5, de;q=3D0.5". > >> > >> [ed note: didn't show the strikeout; that probably wouldn't show in = the > >> text version.] > >> > >> > >> _______________________________________________ > >> Ltru mailing list > >> Ltru@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ltru > >> > > > > > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 15:06:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEu3x-0004Tk-WE; Thu, 02 Mar 2006 15:06:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEu3x-0004Tf-Kj for ltru@ietf.org; Thu, 02 Mar 2006 15:06:13 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEu3w-0005JG-Cc for ltru@ietf.org; Thu, 02 Mar 2006 15:06:13 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FEu3v-0005Mu-7m; Thu, 02 Mar 2006 15:06:11 -0500 Date: Thu, 2 Mar 2006 15:06:11 -0500 To: Addison Phillips Subject: Re: [Ltru] Martin's comments on draft-10 Message-ID: <20060302200611.GC3464@ccil.org> References: <440739C7.9080109@icu-project.org> <000701c63e2e$b0c4c0e0$660a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701c63e2e$b0c4c0e0$660a0a0a@ds.corp.yahoo.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > If a protocol, application, or specification needs to assign a > weight to a language range which lacks one in a list, a good strategy > would be to assign the range the same value as that of the preceding > language range. If the first language range has no weight, it is given > the highest possible value (which would, for example, be "1.0" for > Accept-Language). Language ranges with zero weights might be removed > or they might be treated as meaning "do not return content for any > tags that match this range". For example, the list "fr, en;q=0.5, de, > it" might become "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". I think all these "might"s could legitimately become RFC 2119 MAYs; they say what the implementation is free to do or not do. -- I don't know half of you half as well John Cowan as I should like, and I like less than half cowan@ccil.org of you half as well as you deserve. http://www.ccil.org/~cowan --Bilbo http://www.ap.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 15:21:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuIr-0002Jt-1y; Thu, 02 Mar 2006 15:21:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuIp-0002G6-QO for ltru@ietf.org; Thu, 02 Mar 2006 15:21:35 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEuIm-00060y-IR for ltru@ietf.org; Thu, 02 Mar 2006 15:21:35 -0500 Received: from duringpersonlx (nvvpn-c110.corp.yahoo.com [172.21.169.110]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k22KL1f5005874; Thu, 2 Mar 2006 12:21:01 -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: thread-index:x-mimeole; b=SKXILNEwozIXxk28c3WTKYhd5tdNEY5ewt9qwXVpvmLAwtQpFCC18IccE0DW3+Lo From: "Addison Phillips" To: "'John Cowan'" Subject: RE: [Ltru] Martin's comments on draft-10 Date: Thu, 2 Mar 2006 12:22:52 -0800 Message-ID: <000b01c63e37$15a3fd70$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060302200611.GC3464@ccil.org> Thread-Index: AcY+NMYiMGr2uD5JQPCLLG/AgOixxAAAkzCA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Done. Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 2006?3?2? 12:06 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] Martin's comments on draft-10 > > Addison Phillips scripsit: > > > If a protocol, application, or specification needs to assign a > > weight to a language range which lacks one in a list, a good strategy > > would be to assign the range the same value as that of the preceding > > language range. If the first language range has no weight, it is given > > the highest possible value (which would, for example, be "1.0" for > > Accept-Language). Language ranges with zero weights might be removed > > or they might be treated as meaning "do not return content for any > > tags that match this range". For example, the list "fr, en;q=0.5, de, > > it" might become "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". > > I think all these "might"s could legitimately become RFC 2119 MAYs; they > say > what the implementation is free to do or not do. > > -- > I don't know half of you half as well John Cowan > as I should like, and I like less than half cowan@ccil.org > of you half as well as you deserve. http://www.ccil.org/~cowan > --Bilbo http://www.ap.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 02 15:25:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuMr-0007mM-0u; Thu, 02 Mar 2006 15:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEuMp-0007gO-LX for ltru@ietf.org; Thu, 02 Mar 2006 15:25:43 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEuMo-00066M-Ck for ltru@ietf.org; Thu, 02 Mar 2006 15:25:43 -0500 Received: from duringpersonlx (nvvpn-c110.corp.yahoo.com [172.21.169.110]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k22KP8Lg006134; Thu, 2 Mar 2006 12:25:08 -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: thread-index:x-mimeole; b=w6/R/a4iz4KkQYGUK5140LmMwiBkLq80SSnKJdgwO4LRIMn5+SrotqlA249dVAs9 From: "Addison Phillips" To: "'Addison Phillips'" , "'John Cowan'" Subject: RE: [Ltru] Martin's comments on draft-10 Date: Thu, 2 Mar 2006 12:26:59 -0800 Message-ID: <000c01c63e37$a8970230$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcY+NMYiMGr2uD5JQPCLLG/AgOixxAAAkzCAAAAaIKA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org BTW> On-line editor copies of draft-11 are now updated with all changes from John, Mark, Martin, and my comments incorporated. http://www.inter-locale.com/ID/draft-ietf-ltru-matching-11.txt http://www.inter-locale.com/ID/draft-ietf-ltru-matching-11.html http://www.inter-locale.com/ID/draft-ietf-ltru-matching-11.xml Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 2006?3?2? 12:23 > To: 'John Cowan' > Cc: 'ltru@ietf.org' > Subject: RE: [Ltru] Martin's comments on draft-10 > > Done. > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > -----Original Message----- > > From: John Cowan [mailto:cowan@ccil.org] > > Sent: 2006?3?2? 12:06 > > To: Addison Phillips > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Martin's comments on draft-10 > > > > Addison Phillips scripsit: > > > > > If a protocol, application, or specification needs to assign a > > > weight to a language range which lacks one in a list, a good strategy > > > would be to assign the range the same value as that of the preceding > > > language range. If the first language range has no weight, it is given > > > the highest possible value (which would, for example, be "1.0" for > > > Accept-Language). Language ranges with zero weights might be removed > > > or they might be treated as meaning "do not return content for any > > > tags that match this range". For example, the list "fr, en;q=0.5, de, > > > it" might become "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". > > > > I think all these "might"s could legitimately become RFC 2119 MAYs; they > > say > > what the implementation is free to do or not do. > > > > -- > > I don't know half of you half as well John Cowan > > as I should like, and I like less than half cowan@ccil.org > > of you half as well as you deserve. > http://www.ccil.org/~cowan > > --Bilbo http://www.ap.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 03 00:28:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF2pg-0001kw-9M; Fri, 03 Mar 2006 00:28:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF2pe-0001km-RB for ltru@lists.ietf.org; Fri, 03 Mar 2006 00:28:02 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF2pd-0003uw-9f for ltru@lists.ietf.org; Fri, 03 Mar 2006 00:28:02 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k235Rtd18039; Fri, 3 Mar 2006 14:27:55 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1779_77abf71a_aa76_11da_9e5b_0014221f2a2d; Fri, 03 Mar 2006 14:27:54 +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 k235P4BP018742; Fri, 3 Mar 2006 14:27:19 +0900 Message-Id: <6.0.0.20.2.20060303114916.08740970@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 03 Mar 2006 11:50:46 +0900 To: "Addison Phillips" , "'Mark Davis'" From: Martin Duerst Subject: RE: [Ltru] comments on draft-10 In-Reply-To: <000501c63e22$c6575460$660a0a0a@ds.corp.yahoo.com> References: <6.0.0.20.2.20060302184951.091c9ec0@localhost> <000501c63e22$c6575460$660a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 02:57 06/03/03, Addison Phillips wrote: >Much nicer code. I can tell you spent at least 6 minutes on it. :-) I spent at least 20 or 30 minutes on it, but most of it was to try and figure out what your code did, or what the draft said (or both). Regards, Martin. >> It's very asymetric, but that seems to be a result of the fact that >> singleton-started extensions always are at the end, yes? > >Yes. > >Addison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 03 04:44:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6q4-0004i8-5J; Fri, 03 Mar 2006 04:44:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6q2-0004e4-IU for ltru@ietf.org; Fri, 03 Mar 2006 04:44:42 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF6px-00056n-RR for ltru@ietf.org; Fri, 03 Mar 2006 04:44:42 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k239iTd07946; Fri, 3 Mar 2006 18:44:29 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 0a67_4f6b633e_aa9a_11da_8200_0014221fa3c9; Fri, 03 Mar 2006 18:44:28 +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 k239gxbA021303; Fri, 3 Mar 2006 18:43:49 +0900 Message-Id: <6.0.0.20.2.20060303143358.0873e050@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 03 Mar 2006 14:58:54 +0900 To: "Addison Phillips" , "'Mark Davis'" From: Martin Duerst Subject: RE: [Ltru] Martin's comments on draft-10 In-Reply-To: <000701c63e2e$b0c4c0e0$660a0a0a@ds.corp.yahoo.com> References: <440739C7.9080109@icu-project.org> <000701c63e2e$b0c4c0e0$660a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Addison, At 04:22 06/03/03, Addison Phillips wrote: >You're right that lookup relies on the list being ordered. But the >assignment of weights isn't strictly necessary: only the ordering of the >list is strictly necessary. Yes, that's the point that was confusing when I read that part: There is a dance with q-values, and in the end, they aren't used. Therefore, I'd a priory prefer a description that gets rid of the weights as early as possible. But I have to admit that it's difficult to improve on the current description. >A list with no weights but in priority order >(hence, one suspects "language PRIORITY list") serves just as well. > >I agree that the current text does a good job and I'm not in favor or >removing it. Well, except that it's one of these paragaphs with a lot of if's and would's. In this sense, things actually became worse. >But I'm also not in favor of scads more text about it, Agreed. >since >we don't use the weights for anything and we don't say anything normative >about weighting lists. For that matter, we don't even define q-weighting >here. It is an artifact of RFC 2616. If we prescribed weight values we >might run afoul of existing implementations that assign weights... to no >good purpose. Yes. HTTP says that the default weight is 1.0, which would mean that "fr, en;q=0.5, de, it" becomes "fr;q=1.0, de;q=1.0, it;q=1.0, en;q=0.5", rather than "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". As far as I understand, at least Apache implements that correctly. This would also make the algorithm easier to describe :-). >All that said, I agree that the current bulky paragraphs leave a lot to be >desired. I've split them up like this: > >-- >The various matching operations described in this document include >considerations for using a language priority list. This document does not >define the syntax for a language priority list; defining such a syntax is >the responsibility of the protocol, application, or specification that uses >it. When given as examples in this document, language priority lists will >be shown as a quoted sequence of ranges separated by commas, like this: >"en, fr, zh-Hant" (which would be read as "English before French before >Chinese as written in the Traditional script"). > >Some language priority lists provide "quality weights" for the language >ranges in order to specify the relative priority of the user's language >preferences. An example of this would be the use of "q" values in the >syntax of the "Accept-Language" header (defined in target="RFC2616">, Section 14.4, and ). > >If a protocol, application, or specification needs to assign a weight to >a language range which lacks one in a list, a good strategy would be to >assign the range the same value as that of the preceding language range. If >the first language range has no weight, it is given the highest possible >value (which would, for example, be "1.0" for Accept-Language). Language >ranges with zero weights might be removed or they might be treated as >meaning "do not return content for any tags that match this range". For >example, the list "fr, en;q=0.5, de, it" might become "fr;q=1.0, en;q=0.5, >de;q=0.5, it;q=0.5". > >Regardless of whether weights are assigned or not, the language priority >list SHOULD be sorted from highest priority to lowest. If weight values >have been assigned to some items in the list, language ranges that share >the same weights SHOULD remain in the same order as in the original >language priority list, since the order of the list carries meaning for >some matching schemes (such as lookup). >-- > >I've dithered about saying "the language priority list SHOULD always be >sorted" (i.e. insert "always"). > >NB> I've changed the language priority list examples in the text to use >comma separators, since that's what accept-language actually uses. This >allowed me to keep the Accept-language example just quoted above intact >without immediately following the statement "all examples of LPLs in this >document...use semi-colon" with something else! Good. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 03 04:44:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6q5-0004mP-Ox; Fri, 03 Mar 2006 04:44:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF6q2-0004ef-L1 for ltru@ietf.org; Fri, 03 Mar 2006 04:44:42 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF6py-00056m-1Q for ltru@ietf.org; Fri, 03 Mar 2006 04:44:42 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k239iEd07937; Fri, 3 Mar 2006 18:44:14 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 179a_467ab284_aa9a_11da_9a12_0014221f2a2d; Fri, 03 Mar 2006 18:44:14 +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 k239gxb8021303; Fri, 3 Mar 2006 18:43:25 +0900 Message-Id: <6.0.0.20.2.20060303144829.086fcb20@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 03 Mar 2006 14:51:27 +0900 To: John Cowan , Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Martin's comments on draft-10 In-Reply-To: <20060302200611.GC3464@ccil.org> References: <440739C7.9080109@icu-project.org> <000701c63e2e$b0c4c0e0$660a0a0a@ds.corp.yahoo.com> <20060302200611.GC3464@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 05:06 06/03/03, John Cowan wrote: >Addison Phillips scripsit: > >> If a protocol, application, or specification needs to assign a >> weight to a language range which lacks one in a list, a good strategy >> would be to assign the range the same value as that of the preceding >> language range. If the first language range has no weight, it is given >> the highest possible value (which would, for example, be "1.0" for >> Accept-Language). Language ranges with zero weights might be removed >> or they might be treated as meaning "do not return content for any >> tags that match this range". For example, the list "fr, en;q=0.5, de, >> it" might become "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". > >I think all these "might"s could legitimately become RFC 2119 MAYs; they say >what the implementation is free to do or not do. I'm quite a bit wary of too many MAYs in the spec (not the words are the problem, the problem is the content). The previous wording actually was much more direct. I'm saying this both as a technical contributor (immagining myself being in a position to write a spec for a specific protocol) as well as in my position as a co-chair (where I think it will be easier to move this spec forward if it is clearer and simpler). Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 03 12:59:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFEZ1-0002dr-D4; Fri, 03 Mar 2006 12:59:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFEZ0-0002c9-SV for ltru@ietf.org; Fri, 03 Mar 2006 12:59:38 -0500 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFEYy-0006td-Hm for ltru@ietf.org; Fri, 03 Mar 2006 12:59:38 -0500 Received: (qmail 31587 invoked from network); 3 Mar 2006 17:59:36 -0000 Received: from unknown (HELO ?172.19.8.188?) (unknown) by unknown with SMTP; 3 Mar 2006 17:59:36 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <44088405.10002@icu-project.org> Date: Fri, 03 Mar 2006 09:59:33 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Martin's comments on draft-10 References: <440739C7.9080109@icu-project.org> <000701c63e2e$b0c4c0e0$660a0a0a@ds.corp.yahoo.com> <20060302200611.GC3464@ccil.org> <6.0.0.20.2.20060303144829.086fcb20@localhost> In-Reply-To: <6.0.0.20.2.20060303144829.086fcb20@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I'm ok with simplifying the text, but the current proposal is a bit broken. It says "Regardless of whether weights are assigned or not, the language priority list SHOULD be sorted from highest priority to lowest." But that CAN'T be done unless it is known what the weights are. So unless the previous strategy is followed, there is no determinate weighting that can be applied in the SHOULD. One would have to do something really gummy like say that the language ranges that had explicit weights SHOULD be ... Also, this neglects the duplicate issue. Not a big issue, but some people always wonder what you do when you have fr;q=0.5 ... fr;q=0.8. Maximum? Geometric mean? And saying "MAY be treated as meaning "do not return content for any tags that match this range"" is not relevant for this document, since the only thing that matters in any of the descriptions herein just care about the ordering. And it doesn't need to be so tentative and qualified everywhere, we already say " Implementations or protocols MAY use different matching schemes from the ones described in this document, as long as those mechanisms are clearly specified." So we don't have to have so many qualifications. We can just say that the mechanism used to handle weights is X, since we *already* say that anyone can use different schemes. We can just use one qualification on the entire description. My resulting suggested changes are now even more consise: If a protocol, application, or specification needs to assign a weight to a language range which lacks one in a list, a good strategy would be to assign the range the same value as that of the preceding language range. If the first language range has no weight, it is given the highest possible value (which would, for example, be "1.0" for Accept-Language). Language ranges with zero weights MAY be removed or they MAY be treated as meaning "do not return content for any tags that match this range". For example, the list "fr, en;q=0.5, de, it" might become "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". Regardless of whether weights are assigned or not, the language priority list SHOULD be sorted from highest priority to lowest. If weight values have been assigned to some items in the list, language ranges that share the same weights SHOULD remain in the same order as in the original language priority list, since the order of the list carries meaning for some matching schemes (such as lookup (Lookup) ). The matching mechanisms specified in this document use the following strategy for resolving weights into an ordered list. If the first language range has no weight, it is given the highest possible value (e.g, "1.0" for Accept-Language). Language ranges with no weights are given the same value as that of the preceding language range (successively). The language priority list is then sorted from highest priority to lowest, where language ranges that share the same weights remain in the same order as in the original language priority list. Language ranges are removed if they have zero weights, or occur previously in the list. For example, the list "fr, de, es;q=0.0, en;q=0.5, de, it;q=0.8, fr" would become "fr;q=1.0, it;q=0.8, en;q=0.5, de;q=0.5". This strategy MAY be modified as per Section 3. Martin Duerst wrote: > At 05:06 06/03/03, John Cowan wrote: > >Addison Phillips scripsit: > > > >> If a protocol, application, or specification needs to assign a > >> weight to a language range which lacks one in a list, a good strategy > >> would be to assign the range the same value as that of the preceding > >> language range. If the first language range has no weight, it is given > >> the highest possible value (which would, for example, be "1.0" for > >> Accept-Language). Language ranges with zero weights might be removed > >> or they might be treated as meaning "do not return content for any > >> tags that match this range". For example, the list "fr, en;q=0.5, de, > >> it" might become "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". > > > >I think all these "might"s could legitimately become RFC 2119 MAYs; > they say > >what the implementation is free to do or not do. > > I'm quite a bit wary of too many MAYs in the spec (not the words are > the problem, the problem is the content). The previous wording actually > was much more direct. > > I'm saying this both as a technical contributor (immagining myself > being in a position to write a spec for a specific protocol) as well > as in my position as a co-chair (where I think it will be easier > to move this spec forward if it is clearer and simpler). > > Regards, Martin. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 04 12:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFaGp-0008Dk-0K; Sat, 04 Mar 2006 12:10:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFaGn-0008DS-H4; Sat, 04 Mar 2006 12:10:17 -0500 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFaGl-000706-0U; Sat, 04 Mar 2006 12:10:17 -0500 Received: from duringpersonlx (snvvpn-c210.corp.yahoo.com [172.21.169.210]) by mrout1.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k24H8AiJ098378; Sat, 4 Mar 2006 09:08:10 -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:x-mailer:x-mimeole:thread-index; b=GvOE51JDcSlSS6cCqW99WGhFQAnDqSF8fI8kCjGUtgfUfsqQR31v7oDV10Jr/0kX From: "Addison Phillips" To: Date: Sat, 4 Mar 2006 09:10:00 -0800 Message-ID: <000101c63fae$78d1c2b0$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_01C63F6B.6AAE82B0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcY/rnh26dLFJOWXR2ekw10iP2GFjA== X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 61a319605c9b07a0c159a92472359379 Cc: ltru@lists.ietf.org Subject: [Ltru] submission: draft-ietf-ltru-matching-11 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C63F6B.6AAE82B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Editor, Please find attached draft-11 of the LTRU matching document = (draft-ietf-ltru-matching). Best Regards, Addison (for the editors) Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 ------=_NextPart_000_0002_01C63F6B.6AAE82B0 Content-Type: text/plain; name="draft-ietf-ltru-matching-11.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ltru-matching-11.txt" =0A= =0A= =0A= Network Working Group A. Phillips, Ed.=0A= Internet-Draft Yahoo! Inc=0A= Obsoletes: 3066 (if approved) M. Davis, Ed.=0A= Expires: September 5, 2006 Google=0A= March 4, 2006=0A= =0A= =0A= Matching of Language Tags=0A= draft-ietf-ltru-matching-11=0A= =0A= Status of this Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on September 5, 2006.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2006).=0A= =0A= Abstract=0A= =0A= This document describes different mechanisms for comparing and=0A= matching language tags. Possible algorithms for language negotiation=0A= or content selection, filtering, and lookup are described. This=0A= document, in combination with RFC 3066bis (Ed.: replace "3066bis"=0A= with the RFC number assigned to draft-ietf-ltru-registry-14),=0A= replaces RFC 3066, which replaced RFC 1766.=0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 1]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. The Language Range . . . . . . . . . . . . . . . . . . . . . . 4=0A= 2.1. Basic Language Range . . . . . . . . . . . . . . . . . . . 4=0A= 2.2. Extended Language Range . . . . . . . . . . . . . . . . . 5=0A= 2.3. The Language Priority List . . . . . . . . . . . . . . . . 5=0A= 3. Types of Matching . . . . . . . . . . . . . . . . . . . . . . 7=0A= 3.1. Choosing a Type of Matching . . . . . . . . . . . . . . . 7=0A= 3.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 3.2.1. Basic Filtering . . . . . . . . . . . . . . . . . . . 9=0A= 3.2.2. Extended Filtering . . . . . . . . . . . . . . . . . . 10=0A= 3.3. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 11=0A= 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 15=0A= 4.1. Choosing Language Ranges . . . . . . . . . . . . . . . . . 15=0A= 4.2. Meaning of Language Tags and Ranges . . . . . . . . . . . 16=0A= 4.3. Considerations for Private Use Subtags . . . . . . . . . . 16=0A= 4.4. Length Considerations for Language Ranges . . . . . . . . 17=0A= 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18=0A= 6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 19=0A= 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20=0A= 8. Character Set Considerations . . . . . . . . . . . . . . . . . 21=0A= 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22=0A= 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22=0A= 9.2. Informative References . . . . . . . . . . . . . . . . . . 22=0A= Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 23=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24=0A= Intellectual Property and Copyright Statements . . . . . . . . . . 25=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 2]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= 1. Introduction=0A= =0A= Human beings on our planet have, past and present, used a number of=0A= languages. There are many reasons why one would want to identify the=0A= language used when presenting or requesting information or in some=0A= specific set of information items or "content".=0A= =0A= One use for language identifiers, such as those defined in=0A= [RFC3066bis], is to select content by matching the associated=0A= language tags to a user's language preferences.=0A= =0A= This document defines a syntax (called a language range (Section 2))=0A= for specifying items in the user's list of language preferences=0A= (called a language priority list (Section 2.3)), as well as several=0A= schemes for selecting or filtering sets of content by comparing the=0A= content's language tags to the user's preferences. Applications,=0A= protocols, or specifications will have varying needs and requirements=0A= that affect the choice of a suitable matching scheme. Depending on=0A= the choice of scheme, there are various options left to the=0A= implementation. Protocols that implement a matching scheme either=0A= need to specify each particular choice or indicate the options that=0A= are left to the implementation to decide.=0A= =0A= This document is divided into three main sections. One describes how=0A= to indicate a user's preferences using language ranges. Then a=0A= section describes various schemes for matching these ranges to a set=0A= of language tags. There is also a section that deals with various=0A= practical considerations that apply to implementing and using these=0A= schemes.=0A= =0A= This document, in combination with [RFC3066bis] (Ed.: replace=0A= "3066bis" globally in this document with the RFC number assigned to=0A= draft-ietf-ltru-registry-14), replaces [RFC3066], which replaced=0A= [RFC1766].=0A= =0A= The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 3]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= 2. The Language Range=0A= =0A= Language Tags [RFC3066bis] are used to identify the language of some=0A= information item or "content". Applications or protocols that use=0A= language tags are often faced with the problem of identifying sets of=0A= content that share certain language attributes. For example,=0A= HTTP/1.1 [RFC2616] describes one such mechanism in its discussion of=0A= the Accept-Language header (Section 14.4), which is used when=0A= selecting content from servers based on the language of that content.=0A= =0A= When selecting content according to its language, it is useful to=0A= have a mechanism for identifying sets of language tags that share=0A= specific attributes. This allows users to select or filter content=0A= based on specific requirements. Such an identifier is called a=0A= "language range".=0A= =0A= There are different types of language range, whose specific=0A= attributes vary according to their application. Language ranges are=0A= similar to language tags: they consist of a sequence of subtags=0A= separated by hyphens. In a language range, each subtag MUST either=0A= be a sequence of ASCII alphanumeric characters or the single=0A= character '*' (%2A, ASTERISK). The character '*' is a "wildcard"=0A= that matches any sequence of subtags. The meaning and uses of=0A= wildcards vary according to the type of language range.=0A= =0A= Language tags and thus language ranges are to be treated as case-=0A= insensitive: there exist conventions for the capitalization of some=0A= of the subtags, but these MUST NOT be taken to carry meaning.=0A= Matching of language tags to language ranges MUST be done in a case-=0A= insensitive manner.=0A= =0A= 2.1. Basic Language Range=0A= =0A= A "basic language range" describes a user's language preference as a=0A= specific, uninterrupted, sequence of subtags. Each range consists of=0A= a sequence of alphanumeric subtags separated by hyphens. The basic=0A= language range is defined by the following ABNF [RFC4234]:=0A= =0A= language-range =3D (1*8ALPHA *("-" 1*8alphanum)) / "*"=0A= alphanum =3D ALPHA / DIGIT=0A= =0A= Basic language ranges (originally described by HTTP/1.1 [RFC2616] and=0A= later [RFC3066]) have the same syntax as an [RFC3066] language tag or=0A= are the single character "*". They differ from the language tags=0A= defined in [RFC3066bis] only in that there is no requirement that=0A= they be "well-formed" or be validated against the IANA Language=0A= Subtag Registry (although such ill-formed ranges will probably not=0A= match anything). (Note that the ABNF [RFC4234] in [RFC2616] is=0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 4]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= incorrect, since it disallows the use of digits anywhere in the=0A= 'language-range': this is mentioned in the errata)=0A= =0A= Use of a basic language range seems to imply that there is a semantic=0A= relationship between language tags that share the same prefix. While=0A= this is often the case, it is not always true and users should note=0A= that the set of language tags that match a specific language range=0A= may not represent mutually intelligible languages.=0A= =0A= 2.2. Extended Language Range=0A= =0A= Occasionally users will wish to select a set of language tags based=0A= on the presence of specific subtags. An "extended language range"=0A= describes a user's language preference as an ordered sequence of=0A= subtags. For example, a user might wish to select all language tags=0A= that contain the region subtag 'CH' (Switzerland). Extended language=0A= ranges are useful in specifying a particular sequence of subtags that=0A= appear in the set of matching tags without having to specify all of=0A= the intervening subtags.=0A= =0A= An extended language range can be represented by the following ABNF:=0A= =0A= extended-language-range =3D (1*8ALPHA / "*")=0A= *("-" (1*8alphanum / "*"))=0A= =0A= Figure 2: Extended Language Range=0A= =0A= The wildcard subtag '*' can occur in any position in the extended=0A= language range, where it matches any sequence of subtags that might=0A= occur in that position in a language tag. However, wildcards outside=0A= the first position in an extended language range are ignored by most=0A= matching schemes. Use of one or more wildcards SHOULD NOT be taken=0A= to imply that a certain number of subtags will appear in the matching=0A= set of language tags.=0A= =0A= Implementations that specify basic ranges MAY map extended language=0A= ranges to basic language ranges: if the first subtag is a "*" then=0A= the entire range is treated as "*", otherwise each wildcard subtag is=0A= removed. For example, if the language range were "en-*-US", then the=0A= range would be mapped to "en-US".=0A= =0A= 2.3. The Language Priority List=0A= =0A= A user's language preferences will often need to specify more than=0A= one language range and thus users often need to specify a prioritized=0A= list of language ranges in order to best reflect their language=0A= preferences. This is especially true for speakers of minority=0A= languages. A speaker of Breton in France, for example, may specify=0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 5]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= "be" followed by "fr", meaning that if Breton is available, it is=0A= preferred, but otherwise French is the best alternative. It can get=0A= more complex: a user may wish to fall back from Skolt Sami to=0A= Northern Sami to Finnish.=0A= =0A= A "language priority list" is a prioritized or weighted list of=0A= language ranges. One well known example of such a list is the=0A= "Accept-Language" header defined in RFC 2616 [RFC2616] (see Section=0A= 14.4) and RFC 3282 [RFC3282].=0A= =0A= The various matching operations described in this document include=0A= considerations for using a language priority list. This document=0A= does not define the syntax for a language priority list; defining=0A= such a syntax is the responsibility of the protocol, application, or=0A= specification that uses it. When given as examples in this document,=0A= language priority lists will be shown as a quoted sequence of ranges=0A= separated by commas, like this: "en, fr, zh-Hant" (which would be=0A= read as "English before French before Chinese as written in the=0A= Traditional script").=0A= =0A= A simple list of ranges is considered to be in descending order of=0A= priority. Other language priority lists provide "quality weights"=0A= for the language ranges in order to specify the relative priority of=0A= the user's language preferences. An example of this would be the use=0A= of "q" values in the syntax of the "Accept-Language" header (defined=0A= in [RFC2616], Section 14.4, and [RFC3282]).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 6]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= 3. Types of Matching=0A= =0A= Matching language ranges to language tags can be done in a number of=0A= different ways. This section describes several different matching=0A= schemes, as well as the considerations for choosing between them.=0A= Protocols and specifications SHOULD clearly indicate the particular=0A= mechanism used in selecting or matching language tags.=0A= =0A= There are several types of matching scheme. This document presents=0A= two types: those that produce zero or more information items (called=0A= "filtering") and those that produce a single information item for a=0A= given request (called "lookup").=0A= =0A= Implementations or protocols MAY use different matching schemes from=0A= the ones described in this document, as long as those mechanisms are=0A= clearly specified.=0A= =0A= 3.1. Choosing a Type of Matching=0A= =0A= Applications, protocols, and specifications are faced with the=0A= decision of what type of matching to use. Sometimes, different=0A= styles of matching are suited to different kinds of processing within=0A= a particular application or protocol.=0A= =0A= Language tag matching is a tool, and does not by itself specify a=0A= complete procedure for the use of language tags. Such procedures are=0A= intimately tied to the application protocol in which they occur.=0A= When specifying a protocol operation using matching, the protocol=0A= MUST specify:=0A= =0A= o Which type(s) of language tag matching it uses=0A= =0A= o Whether the operation returns a single result (lookup) or a=0A= possibly empty set of results (filtering)=0A= =0A= o For lookup, what the result is when no matching tag is found. For=0A= instance, a protocol might define the result as failure of the=0A= operation, an empty value, returning some protocol defined or=0A= implementation defined default, or returning i-default [RFC2277].=0A= =0A= This document describes three types of matching:=0A= =0A= 1. Basic Filtering (Section 3.2.1) matches a language priority list=0A= consisting of basic language ranges (Section 2.1) to sets of=0A= language tags.=0A= =0A= 2. Extended Filtering (Section 3.2.2) matches a language priority=0A= list consisting of extended language ranges (Section 2.2) to sets=0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 7]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= of language tags.=0A= =0A= 3. Lookup (Section 3.3) matches a language priority list consisting=0A= of basic language ranges to sets of language tags to find the one=0A= _exact_ language tag that best matches the range.=0A= =0A= Filtering can be used to produce a set of results (such as a=0A= collection of documents) by comparing the user's preferences to=0A= language tags associated with the set of content. For example, when=0A= performing a search, one might use filtering to limit the results to=0A= items tagged as being in the French language. Filtering can also be=0A= used when deciding whether to perform a language-sensitive process on=0A= some content. For example, a process might cause paragraphs whose=0A= language tag matched the language range "nl" to be displayed in=0A= italics within a document.=0A= =0A= Lookup produces the single result that best matches the user's=0A= preferences, so it is useful in cases in which only a single item can=0A= be returned. For example, if a process were to insert a human=0A= readable error message into a protocol header, it might select the=0A= text based on the user's language priority list. Since the process=0A= can return only one item, it must choose a single item and it must=0A= return some item, even if none of the content's language tags match=0A= the language priority list supplied by the user.=0A= =0A= The types of matching in this document are designed so that=0A= implementations are not required to validate or understand any of the=0A= semantics of the language tags or ranges or of the subtags in them.=0A= None of them require access to the IANA Language Subtag Registry (see=0A= Section 3 in [RFC3066bis]). This simplifies implementation of these=0A= schemes. An implementation MAY choose to check if either the=0A= language ranges or language tags being matched are "well-formed" or=0A= "valid" (see [RFC3066bis], Section 2.2.9) and MAY choose not to=0A= process invalid ranges.=0A= =0A= Regardless of the matching scheme chosen, protocols and=0A= implementations MAY canonicalize language tags and ranges by mapping=0A= grandfathered and obsolete tags or subtags into modern equivalents.=0A= If an implementation canonicalizes either ranges or tags, then the=0A= implementation will require the IANA Language Subtag Registry=0A= information for that purpose. Implementations MAY also use semantic=0A= information external to the registry when matching tags. For=0A= example, the primary language subtags 'nn' (Nynorsk Norwegian) and=0A= 'nb' (Bokmal Norwegian) might both be usefully matched to the more=0A= general subtag 'no' (Norwegian). Or an implementation might infer=0A= that content labeled "zh-Hans" (Chinese as written in the Simplified=0A= script) is more likely to match the range "zh-CN" (Chinese as used in=0A= China, where the Simplified script is predominant) than equivalent=0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 8]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= content labeled "zh-TW" (Chinese as used in Taiwan, where the=0A= Traditional script is predominant).=0A= =0A= 3.2. Filtering=0A= =0A= Filtering is used to select the set of language tags that matches a=0A= given language priority list and return the associated content. It=0A= is called "filtering" because this set might contain no items at all=0A= or it might return an arbitrarily large number of matching items: as=0A= many items as match the language priority list, thus "filtering out"=0A= the non-matching items.=0A= =0A= In filtering, each language range represents the _least_ specific=0A= language tag (that is, the language tag with fewest number of=0A= subtags) which is an acceptable match. All of the language tags in=0A= the matching set of tags will have an equal or greater number of=0A= subtags than the language range. Every non-wildcard subtag in the=0A= language range will appear in every one of the matching language=0A= tags. For example, if the language priority list consists of the=0A= range "de-CH", one might see tags such as "de-CH-1996" but one will=0A= never see a tag such as "de" (because the 'CH' subtag is missing).=0A= =0A= If the language priority list (see Section 2.3) contains more than=0A= one range, the content returned is typically ordered in descending=0A= level of preference, but it MAY be unordered, according to the needs=0A= of the application or protocol.=0A= =0A= Some examples of applications where filtering might be appropriate=0A= include:=0A= =0A= o Applying a style to sections of a document in a particular set of=0A= languages.=0A= =0A= o Displaying the set of documents containing a particular set of=0A= keywords written in a specific set of languages.=0A= =0A= o Selecting all email items written in a specific set of languages.=0A= =0A= o Selecting audio files spoken in a particular language.=0A= =0A= 3.2.1. Basic Filtering=0A= =0A= When filtering using basic language ranges, each basic language range=0A= in the language priority list is considered in turn, according to=0A= priority. A particular language tag matches a language range if, in=0A= a case-insensitive comparison, it exactly equals the tag, or if it=0A= exactly equals a prefix of the tag such that the first character=0A= following the prefix is "-". For example, the language-range "de-de"=0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 9]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= matches the language tag "de-DE-1996", but not the language tags "de-=0A= Deva" or "de-Latn-DE".=0A= =0A= The special range "*" in a language priority list matches any tag. A=0A= protocol which uses language ranges MAY specify additional rules=0A= about the semantics of "*"; for instance, HTTP/1.1 [RFC2616]=0A= specifies that the range "*" matches only languages not matched by=0A= any other range within an "Accept-Language" header.=0A= =0A= Basic filtering is identical to the type of matching described in=0A= [RFC3066], Section 2.5 (Language-range).=0A= =0A= 3.2.2. Extended Filtering=0A= =0A= When filtering using extended language ranges, each extended language=0A= range in the language priority list is considered in turn, according=0A= to priority. A particular language range is compared to each=0A= language tag using the following process:=0A= =0A= Compare the first subtag in the extended language tag to the first=0A= subtag in the language tag in a case insensitive manner. If the=0A= first subtag in the range is "*", it matches any value. Otherwise=0A= the two values must match or the overall match fails.=0A= =0A= Take each non-wildcard subtag in the language range and compare it in=0A= a case-insensitive manner to the next subtag in the language tag. If=0A= the range's subtag exactly matches the tag's subtag, proceed to the=0A= next non-wildcard subtag in the language range (and beginning with=0A= the next subtag in the language tag) until the list of subtags in the=0A= language range is exhausted or the match fails. If the tag's subtag=0A= is a "singleton" (a single letter or digit, which, in this case,=0A= includes the private-use subtag 'x') and the range's subtag does not=0A= match or if the language tag's list of subtags is exhausted, the=0A= match fails. If the language range's list of subtags is exhausted,=0A= the match succeeds.=0A= =0A= Subtags not specified, including those at the end of the language=0A= range, are thus treated as if assigned the wildcard value "*". Much=0A= like basic filtering, extended filtering selects content with=0A= arbitrarily long tags that share the same initial subtags as the=0A= language range. In addition extended filtering selects content with=0A= any intermediate subtags unspecified in the language range. For=0A= example, the extended language range "de-*-DE" matches all of the=0A= following tags:=0A= =0A= de-DE=0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 10]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= de-Latn-DE=0A= =0A= de-Latf-DE=0A= =0A= de-de=0A= =0A= de-DE-x-goethe=0A= =0A= de-Latn-DE-1996=0A= =0A= The same range does not match any of the following tags for the=0A= reasons shown:=0A= =0A= de (missing 'DE')=0A= =0A= de-x-DE (singleton 'x' occurs before 'DE')=0A= =0A= de-Deva ('Deva' not equal to 'DE')=0A= =0A= Note: The structure of language tags defined by [RFC3066bis] defines=0A= each type of subtag (language, script, region, and so forth)=0A= according to position, size, and content. This means that subtags in=0A= a language range can only match specific types of subtags in a=0A= language tag. For example, a subtag such as 'Latn' is always a=0A= script subtag (unless it follows a singleton) while a subtag such as=0A= 'nedis' can only match the equivalent variant subtag.=0A= =0A= 3.3. Lookup=0A= =0A= Lookup is used to select the single language tag that best matches=0A= the language priority list for a given request and return the=0A= associated content. When performing lookup, each language range in=0A= the language priority list is considered in turn, according to=0A= priority. By contrast with filtering, each language range represents=0A= the _most_ specific tag which is an acceptable match. The first=0A= content found with a matching tag, according to the user's priority,=0A= is considered the closest match and is the content returned. For=0A= example, if the language range is "de-ch", a lookup operation might=0A= produce content with the tags "de" or "de-CH" but never one with the=0A= tag "de-CH-1996". Usually if no content matches the request, the=0A= "default" content is returned.=0A= =0A= For example, if an application inserts some dynamic content into a=0A= document, returning an empty string if there is no exact match is not=0A= an option. Instead, the application "falls back" until it finds a=0A= matching language tag associated with a suitable piece of content to=0A= insert. Examples of lookup might include:=0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 11]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= o Selection of a template containing the text for an automated email=0A= response.=0A= =0A= o Selection of a item containing some text for inclusion in a=0A= particular Web page.=0A= =0A= o Selection of a string of text for inclusion in an error log.=0A= =0A= o Selection of an audio file to play as a prompt in a phone system.=0A= =0A= In the lookup scheme, the language range is progressively truncated=0A= from the end until a matching piece of content is located. Single=0A= letter or digit subtags (including both the letter 'x' which=0A= introduces private-use sequences, and the subtags that introduce=0A= extensions) are removed at the same time as their closest trailing=0A= subtag. For example, starting with the range "zh-Hant-CN-x-private1-=0A= private2", the lookup progressively searches for content as shown=0A= below:=0A= =0A= Range to match: zh-Hant-CN-x-private1-private2=0A= 1. zh-Hant-CN-x-private1-private2=0A= 2. zh-Hant-CN-x-private1=0A= 3. zh-Hant-CN=0A= 4. zh-Hant=0A= 5. zh=0A= 6. (default content)=0A= =0A= Figure 3: Example of a Lookup Fallback Pattern=0A= =0A= This allows some flexibility in finding a match. For example, lookup=0A= provides better results for cases in which content is not available=0A= that exactly matches the user request than if the default language=0A= for the system or content were returned immediately. Not every=0A= specific level of tag granularity is usually available or language=0A= content may be sparsely populated. "Falling back" through the subtag=0A= sequence provides more opportunity to find a match between available=0A= language tags and the user's request.=0A= =0A= The default behavior when no tag matches the language priority list=0A= is implementation defined. An implementation might, for example,=0A= return content:=0A= =0A= o with no language tag=0A= =0A= o of a non-linguistic nature, such as an image or sound=0A= =0A= o with an empty language tag value, in cases where the protocol=0A= permits the empty value (see, for example, "xml:lang" in [XML10],=0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 12]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= which indicates that the element contains non-linguistic content)=0A= =0A= o in a particular language designated for the bit of content being=0A= selected=0A= =0A= o labelled with the tag "i-default" (see [RFC2277])=0A= =0A= When performing lookup using a language priority list, the=0A= progressive search MUST process each language range in the list=0A= before finding the default content or empty tag.=0A= =0A= One common way for an application or implementation to provide for a=0A= default is to allow a specific language range to be set as the=0A= default for a specific type of request. This language range is then=0A= treated as if it were appended to the end of the language priority=0A= list as a whole, rather than after each item in the language priority=0A= list.=0A= =0A= For example, if a particular user's language priority list were=0A= "fr-FR, zh-Hant" and the program doing the matching had a default=0A= language range of "ja-JP", the program would search for content as=0A= follows:=0A= 1. fr-FR=0A= 2. fr=0A= 3. zh-Hant // next language=0A= 4. zh=0A= 5. (search for the default content)=0A= a. ja-JP=0A= b. ja=0A= c. (implementation defined default)=0A= =0A= Figure 4: Lookup Using a Language Priority List=0A= =0A= Implementations SHOULD ignore extensions and unrecognized private-use=0A= subtags when performing lookup, since these subtags are usually=0A= orthogonal to the user's request.=0A= =0A= The special language range "*" matches any language tag. In the=0A= lookup scheme, this range does not convey enough information by=0A= itself to determine which content is most appropriate, since it=0A= matches everything. If the language range "*" is followed by other=0A= language ranges, it SHOULD be skipped. If the language range "*" is=0A= the only one in the language priority list or if no other language=0A= range follows, the default content SHOULD be returned.=0A= =0A= In some cases, the language priority list might contain one or more=0A= extended language ranges (as, for example, when the same language=0A= priority list is used as input for both lookup and filtering=0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 13]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= operations). Wildcard values in an extended language range normally=0A= match any value that occurs in that position in a language tag.=0A= Since only one item can be returned for any given lookup request,=0A= wildcards in a language range have to be processed in a consistent=0A= manner or the same request will produce widely varying results.=0A= Implementations that accept extended language ranges MUST define=0A= which content is returned when more than one item matches the=0A= extended language range.=0A= =0A= For example, an implementation could return the matching tag that is=0A= first in ASCII-order. If the language range were "*-CH" and the set=0A= of tags included "de-CH", "fr-CH", and "it-CH", then the tag "de-CH"=0A= would be returned. Another possibility would be for an=0A= implementation to map the extended language ranges to basic ranges.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 14]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= 4. Other Considerations=0A= =0A= When working with language ranges and matching schemes, there are=0A= some additional points that may influence the choice of either.=0A= =0A= 4.1. Choosing Language Ranges=0A= =0A= Users indicate their language preferences via the choice of a=0A= language range or the list of language ranges in a language priority=0A= list. The type of matching affects what the best choice is for a=0A= user.=0A= =0A= Most matching schemes make no attempt to process the semantic meaning=0A= of the subtags and the language range is compared, in a case-=0A= insensitive manner, to each language tag being matched, using basic=0A= string processing. Users SHOULD select language ranges that are=0A= well-formed, valid language tags according to [RFC3066bis]=0A= (substituting wildcards as appropriate in extended language ranges).=0A= =0A= Users SHOULD replace tags or subtags which have been deprecated with=0A= the Preferred-Value from the IANA Language Subtag Registry. If the=0A= user is working with content that might use the older form, the user=0A= might include both the new and old forms in a language priority list.=0A= For example, the tag "art-lojban" is deprecated. The subtag 'jbo' is=0A= supposed to be used instead, so the user might use it to form the=0A= language range. Or the user might include both in a language=0A= priority list: "jbo, art-lojban".=0A= =0A= Users SHOULD avoid subtags that add no distinguishing value to a=0A= language range. When filtering, the fewer the number of subtags that=0A= appear in the language range, the more content the range will=0A= probably match, while in lookup unnecessary subtags might cause=0A= "better", more-specific content to be skipped in favor of less=0A= specific content. For example, the range "de-Latn-DE" would return=0A= content tagged "de" instead of content tagged "de-DE", even though=0A= the latter is probably a better match.=0A= =0A= Many languages are written predominantly in a single script. This is=0A= usually recorded in the Suppress-Script field in that language=0A= subtag's registry entry. For these languages, script subtags SHOULD=0A= NOT be used to form a language range. Thus the language range "en-=0A= Latn" is inappropriate in most cases (because the vast majority of=0A= English documents are written in the Latin script and thus the 'en'=0A= language subtag has a Suppress-Script field for 'Latn' in the=0A= registry).=0A= =0A= When working with tags and ranges, note that extensions and most=0A= private-use subtags are orthogonal to language tag matching, in that=0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 15]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= they specify additional attributes of the text not related to the=0A= goals of most matching schemes. Users SHOULD avoid using these=0A= subtags in language ranges, since they interfere with the selection=0A= of available content. When used in language tags (as opposed to=0A= ranges), these subtags normally do not interfere with filtering=0A= (Section 3), since they appear at the end of the tag and will match=0A= all prefixes. Lookup (Section 3.3) implementations often ignore=0A= unrecognized private-use and extension subtags when performing=0A= language tag fallback.=0A= =0A= Applications, specifications, or protocols that choose not to=0A= interpret one or more private-use or extension subtags SHOULD NOT=0A= remove or modify these extensions in content that they are=0A= processing. When a language tag instance is to be used in a=0A= specific, known protocol, and is not being passed through to other=0A= protocols, language tags MAY be altered to remove subtags and=0A= extensions that are not supported by that protocol. Such alterations=0A= SHOULD be avoided, if possible, since they remove information that=0A= might be relevant elsewhere that would make use of that information.=0A= =0A= Some applications of language tags might want or need to consider=0A= extensions and private-use subtags when matching tags. If extensions=0A= and private-use subtags are included in a matching process that=0A= utilizes one of the schemes described in this document, then the=0A= implementation SHOULD canonicalize the language tags and/or ranges=0A= before performing the matching. Note that language tag processors=0A= that claim to be "well-formed" processors as defined in [RFC3066bis]=0A= generally fall into this category.=0A= =0A= 4.2. Meaning of Language Tags and Ranges=0A= =0A= Selecting content using language ranges requires some understanding=0A= by users of what they are selecting. The meaning of the various=0A= subtags in a language range are identical to their meaning in a=0A= language tag (see Section 4.2 in [RFC3066bis]), with the addition=0A= that the wildcard "*" represents any matching sequence of values.=0A= =0A= 4.3. Considerations for Private Use Subtags=0A= =0A= Private-use subtags require private agreement between the parties=0A= that intend to use or exchange language tags that use them and great=0A= caution SHOULD be used in employing them in content or protocols=0A= intended for general use. Private-use subtags are simply useless for=0A= information exchange without prior arrangement.=0A= =0A= The value and semantic meaning of private-use tags and of the subtags=0A= used within such a language tag are not defined. Matching private-=0A= use tags using language ranges or extended language ranges can result=0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 16]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= in unpredictable content being returned.=0A= =0A= 4.4. Length Considerations for Language Ranges=0A= =0A= Language ranges are very similar to language tags in terms of content=0A= and usage. The same types of restrictions on length that apply to=0A= language tags can also apply to language ranges. See [RFC3066bis]=0A= Section 4.3 (Length Considerations).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 17]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= 5. IANA Considerations=0A= =0A= This document presents no new or existing considerations for IANA.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 18]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= 6. Changes=0A= =0A= This is the first version of this document.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 19]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= 7. Security Considerations=0A= =0A= Language ranges used in content negotiation might be used to infer=0A= the nationality of the sender, and thus identify potential targets=0A= for surveillance. In addition, unique or highly unusual language=0A= ranges or combinations of language ranges might be used to track a=0A= specific individual's activities.=0A= =0A= This is a special case of the general problem that anything you send=0A= is visible to the receiving party. It is useful to be aware that=0A= such concerns can exist in some cases.=0A= =0A= The evaluation of the exact magnitude of the threat, and any possible=0A= countermeasures, is left to each application or protocol.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 20]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= 8. Character Set Considerations=0A= =0A= Language tags permit only the characters A-Z, a-z, 0-9, and HYPHEN-=0A= MINUS (%x2D). Language ranges also use the character ASTERISK=0A= (%x2A). These characters are present in most character sets, so=0A= presentation or exchange of language tags or ranges should not be=0A= constrained by character set issues.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 21]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= 9. References=0A= =0A= 9.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and=0A= Languages", BCP 18, RFC 2277, January 1998.=0A= =0A= [RFC3066bis]=0A= Phillips, A., Ed. and M. Davis, Ed., "Tags for the=0A= Identification of Languages", October 2005, .=0A= =0A= [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax=0A= Specifications: ABNF", RFC 4234, October 2005.=0A= =0A= 9.2. Informative References=0A= =0A= [RFC1766] Alvestrand, H., "Tags for the Identification of=0A= Languages", RFC 1766, March 1995.=0A= =0A= [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,=0A= Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext=0A= Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.=0A= =0A= [RFC2616errata]=0A= IETF, "HTTP/1.1 Specification Errata", 10 2004,=0A= .=0A= =0A= [RFC3066] Alvestrand, H., "Tags for the Identification of=0A= Languages", BCP 47, RFC 3066, January 2001.=0A= =0A= [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,=0A= May 2002.=0A= =0A= [XML10] Bray (et al), T., "Extensible Markup Language (XML) 1.0",=0A= 02 2004.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 22]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= Appendix A. Acknowledgements=0A= =0A= Any list of contributors is bound to be incomplete; please regard the=0A= following as only a selection from the group of people who have=0A= contributed to make this document what it is today.=0A= =0A= The contributors to [RFC3066bis], [RFC3066] and [RFC1766], each of=0A= which is a precursor to this document, made enormous contributions=0A= directly or indirectly to this document and are generally responsible=0A= for the success of language tags.=0A= =0A= The following people (in alphabetical order by family name)=0A= contributed to this document:=0A= =0A= Harald Alvestrand, Jeremy Carroll, John Cowan, Martin Duerst, Frank=0A= Ellermann, Doug Ewell, Marion Gunn, Kent Karlsson, Ira McDonald, M.=0A= Patton, Randy Presuhn, Eric van der Poel, Markus Scherer, and many,=0A= many others.=0A= =0A= Very special thanks must go to Harald Tveit Alvestrand, who=0A= originated RFCs 1766 and 3066, and without whom this document would=0A= not have been possible.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 23]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= Authors' Addresses=0A= =0A= Addison Phillips (editor)=0A= Yahoo! Inc=0A= =0A= Email: addison at inter dash locale dot com=0A= =0A= =0A= Mark Davis (editor)=0A= Google=0A= =0A= Email: mark dot davis at macchiato dot com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 24]=0A= =0C=0A= Internet-Draft ltru-matching March 2006=0A= =0A= =0A= Intellectual Property Statement=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= Disclaimer of Validity=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=0A= ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A= INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0A= INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2006). This document is subject=0A= to the rights, licenses and restrictions contained in BCP 78, and=0A= except as set forth therein, the authors retain all their rights.=0A= =0A= =0A= Acknowledgment=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires September 5, 2006 [Page 25]=0A= =0C=0A= ------=_NextPart_000_0002_01C63F6B.6AAE82B0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------=_NextPart_000_0002_01C63F6B.6AAE82B0-- From ltru-bounces@ietf.org Sat Mar 04 12:17:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFaO4-0002fo-CV; Sat, 04 Mar 2006 12:17:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFaO2-0002bS-Oe for ltru@lists.ietf.org; Sat, 04 Mar 2006 12:17:46 -0500 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFaO1-0007MQ-EU for ltru@lists.ietf.org; Sat, 04 Mar 2006 12:17:46 -0500 Received: from duringpersonlx (snvvpn-c210.corp.yahoo.com [172.21.169.210]) by mrout1.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k24HFL7k099302 for ; Sat, 4 Mar 2006 09:15:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=vY7zSlJYdn0KeS5wva9+tnMYoGurX9k7IWup4oCkuDgiZpR1fecykPVtzkAAeurm From: "Addison Phillips" To: Subject: RE: [Ltru] submission: draft-ietf-ltru-matching-11 Date: Sat, 4 Mar 2006 09:17:12 -0800 Message-ID: <000b01c63faf$7a194160$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000101c63fae$78d1c2b0$660a0a0a@ds.corp.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcY/rnh26dLFJOWXR2ekw10iP2GFjAAAMAEQ X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Per "the plan" I have submitted draft-11 with all of the edits agreed to = date. With regard to the discussion Mark and I were having, I removed = the text describing how to weight items in a list. A Last Call comment = could, of course, restore the text. Version 11 is on-line, along with a diff: http://www.inter-locale.com/ID/matching-diff-10-11.html Best Regards, Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 2006=E5=B9=B43=E6=9C=884=E6=97=A5 9:10 > To: internet-drafts@ietf.org > Cc: ltru@lists.ietf.org > Subject: [Ltru] submission: draft-ietf-ltru-matching-11 >=20 > Dear Editor, >=20 > Please find attached draft-11 of the LTRU matching document = (draft-ietf- > ltru-matching). >=20 > Best Regards, >=20 > Addison (for the editors) >=20 > Addison Phillips > Internationalization Architect - Yahoo! Inc. >=20 > Internationalization is an architecture. > It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 04 14:28:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFcQN-00088C-2m; Sat, 04 Mar 2006 14:28:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFcQM-000887-EC for ltru@lists.ietf.org; Sat, 04 Mar 2006 14:28:18 -0500 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFcQL-0003Is-51 for ltru@lists.ietf.org; Sat, 04 Mar 2006 14:28:18 -0500 Received: (qmail 34732 invoked from network); 4 Mar 2006 19:28:16 -0000 Received: from unknown (HELO ?192.168.1.102?) (unknown) by unknown with SMTP; 4 Mar 2006 19:28:16 -0000 X-pair-Authenticated: 24.23.194.196 Message-ID: <4409EA4E.1040806@icu-project.org> Date: Sat, 04 Mar 2006 11:28:14 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] submission: draft-ietf-ltru-matching-11 References: <000b01c63faf$7a194160$660a0a0a@ds.corp.yahoo.com> In-Reply-To: <000b01c63faf$7a194160$660a0a0a@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > With regard to the discussion Mark and I were having, I removed the text describing how to weight items in a list. Yes, we agreed that that would be the best course (Addison having convinced me). Mark Addison Phillips wrote: > Per "the plan" I have submitted draft-11 with all of the edits agreed to date. With regard to the discussion Mark and I were having, I removed the text describing how to weight items in a list. A Last Call comment could, of course, restore the text. > > Version 11 is on-line, along with a diff: > > http://www.inter-locale.com/ID/matching-diff-10-11.html > > Best Regards, > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > >> -----Original Message----- >> From: Addison Phillips [mailto:addison@yahoo-inc.com] >> Sent: 2006年3月4日 9:10 >> To: internet-drafts@ietf.org >> Cc: ltru@lists.ietf.org >> Subject: [Ltru] submission: draft-ietf-ltru-matching-11 >> >> Dear Editor, >> >> Please find attached draft-11 of the LTRU matching document (draft-ietf- >> ltru-matching). >> >> Best Regards, >> >> Addison (for the editors) >> >> Addison Phillips >> Internationalization Architect - Yahoo! Inc. >> >> Internationalization is an architecture. >> It is not a feature. >> > > > > _______________________________________________ > 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 Mar 06 04:18:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGBrP-0000Bq-6m; Mon, 06 Mar 2006 04:18:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGBrN-00008G-Oz; Mon, 06 Mar 2006 04:18:33 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGAj4-0004RT-VG; Mon, 06 Mar 2006 03:05:54 -0500 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGATi-0004oq-70; Mon, 06 Mar 2006 02:50:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k267o10e004167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 07:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGATh-0008Lf-Pe; Mon, 06 Mar 2006 02:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 06 Mar 2006 02:50:01 -0500 X-Spam-Score: -2.6 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-matching-11.txt X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Matching of Language Tags Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-matching-11.txt Pages : 25 Date : 2006-3-5 This document describes different mechanisms for comparing and matching language tags. Possible algorithms for language negotiation or content selection, filtering, and lookup are described. This document, in combination with RFC 3066bis (Ed.: replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-matching-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-matching-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-5194137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-matching-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-matching-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-5194137.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@ietf.org Wed Mar 08 13:38:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3YT-0001R5-0g; Wed, 08 Mar 2006 13:38:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH3YR-0001Iq-80 for ltru@ietf.org; Wed, 08 Mar 2006 13:38:35 -0500 Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH3YN-0003eV-SY for ltru@ietf.org; Wed, 08 Mar 2006 13:38:35 -0500 Received: from uknsprd1 (unverified [129.1.30.40]) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.19) with ESMTP id for ; Wed, 8 Mar 2006 18:38:28 +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 <0IVT0093HNS453@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 08 Mar 2006 18:38:28 +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, 08 Mar 2006 18:38:28 +0000 Date: Wed, 08 Mar 2006 18:38:46 +0000 From: Misha Wolf To: LTRU Working Group Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: Exceptionally Reserved Two-letter ISO 3166 Codes Thread-Index: AcZC1rFKDgOLpAeRSgWawP37kygjOwACC9UA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 08 Mar 2006 18:38:28.0452 (UTC) FILETIME=[7DEDE240:01C642DF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Exceptionally Reserved Two-letter ISO 3166 Codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org In another place, Jon Hanna wrote: > Exceptionally Reserved Two-letter ISO 3166 Codes aren't used. Have we done this? If so, why have we done it? EU | European Union | | ISO 4217/MA. In March 1998, extension of=20 | | | scope to ISO 6166 "Securities -=20 | | | International securities identification=20 | | | numbering system (ISIN)". In August 1999,=20 | | | extension of scope to any application=20 | | | needing to represent the name European Union. 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 Thu Mar 09 17:45:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTtA-000464-K2; Thu, 09 Mar 2006 17:45:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHTt9-000440-IH for ltru@ietf.org; Thu, 09 Mar 2006 17:45:43 -0500 Received: from [133.2.251.194] (helo=scmailgw1.scop.aoyama.ac.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHTsh-0003td-TN for ltru@ietf.org; Thu, 09 Mar 2006 17:45:20 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k29MhWu11977 for ; Fri, 10 Mar 2006 07:43:32 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 64be_229cf6fa_afbe_11da_8b74_0014221f2a2d; Fri, 10 Mar 2006 07:43:31 +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 k29MgZPT023801 for ; Fri, 10 Mar 2006 07:43:02 +0900 Message-Id: <6.0.0.20.2.20060310060842.0649d470@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 10 Mar 2006 07:41:55 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ltru] WG last call for draft-ietf-ltru-matching X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The editors have submitted draft-11, which is now available at http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-11.txt. There have been no comments since that submission, which I hope is an indication that we can go to the next stage. I'm therefore starting a Working Group Last Call. The duration of the Last Call is three (3) weeks to take into account the upcomming IETF meeting, where many people may be busy. The Last Call will therefore end on Thursday, March 30, 23:00 UTC (Friday, March 31st, 08:00 Japan time, Thursday, March 30, 3pm US Pacific, and so on). Please read the above draft carefully and send in your comments. Please mark each issue clearly, and indicate whether you think it is editorial, substantive, or whatever. Please concentrate on those points that you think are relevant for moving the document forward (from typos to substantial oversights in case you find any), rather than e.g. proposing yet another complicated new matching scheme. Also, if there is any issue that you have found earlier and that you think has not been appropriately addressed, and you think it is still relevant for moving the document forward, please mention this, too. If you read the document and did not find any issues, please send a mail to say so! If as a result of WG Last Call, the document does not change significantly, the document will be submitted to the Area Director and the IESG for further processing. If the document changes significantly, we will have another WG Last Call. Significantly is defined as any change that reasonably may create significant new comments/issues from somebody who reviewed the document in this Last Call. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 09 18:06:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHUD0-0005ka-9S; Thu, 09 Mar 2006 18:06:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHUCz-0005iE-Pn for ltru@ietf.org; Thu, 09 Mar 2006 18:06:13 -0500 Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHUCy-0004zj-IH for ltru@ietf.org; Thu, 09 Mar 2006 18:06:13 -0500 Received: (qmail 44654 invoked from network); 9 Mar 2006 23:06:11 -0000 Received: from unknown (HELO ?172.24.101.50?) (unknown) by unknown with SMTP; 9 Mar 2006 23:06:11 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <4410B4DF.30507@icu-project.org> Date: Thu, 09 Mar 2006 15:06:07 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] WG last call for draft-ietf-ltru-matching References: <6.0.0.20.2.20060310060842.0649d470@localhost> In-Reply-To: <6.0.0.20.2.20060310060842.0649d470@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I did not find any issues, and am happy with the document as it is. Mark Martin Duerst wrote: > The editors have submitted draft-11, which is now available at > http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-11.txt. > > There have been no comments since that submission, which I hope is > an indication that we can go to the next stage. > > I'm therefore starting a Working Group Last Call. The duration of the > Last Call is three (3) weeks to take into account the upcomming IETF > meeting, where many people may be busy. The Last Call will therefore > end on Thursday, March 30, 23:00 UTC (Friday, March 31st, 08:00 > Japan time, Thursday, March 30, 3pm US Pacific, and so on). > > Please read the above draft carefully and send in your comments. > Please mark each issue clearly, and indicate whether you think it > is editorial, substantive, or whatever. Please concentrate on > those points that you think are relevant for moving the document > forward (from typos to substantial oversights in case you find > any), rather than e.g. proposing yet another complicated new > matching scheme. Also, if there is any issue that you have found > earlier and that you think has not been appropriately addressed, > and you think it is still relevant for moving the document forward, > please mention this, too. > > If you read the document and did not find any issues, please > send a mail to say so! > > If as a result of WG Last Call, the document does not change > significantly, the document will be submitted to the Area > Director and the IESG for further processing. If the document > changes significantly, we will have another WG Last Call. > Significantly is defined as any change that reasonably may > create significant new comments/issues from somebody who > reviewed the document in this Last Call. > > Regards, Martin. > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 10 10:20:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHjPt-0008Uy-Dz; Fri, 10 Mar 2006 10:20:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHjPs-0008Ut-HE for ltru@ietf.org; Fri, 10 Mar 2006 10:20:32 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHjPr-0001Se-8e for ltru@ietf.org; Fri, 10 Mar 2006 10:20:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 7331226C081; Fri, 10 Mar 2006 16:20:30 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 8982F26C06A; Fri, 10 Mar 2006 16:20:29 +0100 (CET) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 8661B58ED5D; Fri, 10 Mar 2006 16:20:29 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id 7160316A9F2; Fri, 10 Mar 2006 16:20:29 +0100 (CET) Date: Fri, 10 Mar 2006 16:20:29 +0100 From: Stephane Bortzmeyer To: Martin Duerst Message-ID: <20060310152029.GA29036@nic.fr> References: <6.0.0.20.2.20060310060842.0649d470@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060310060842.0649d470@localhost> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: LTRU Working Group Subject: [Ltru] Re: WG last call for draft-ietf-ltru-matching X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Mar 10, 2006 at 07:41:55AM +0900, Martin Duerst wrote a message of 42 lines which said: > There have been no comments since that submission, which I hope is > an indication that we can go to the next stage. I've read it and study it and I have no objections. (Warning: I'm not an expert in languages and I'm a member of LTRU for only a small time.) A small typo: A speaker of Breton in France, for example, may specify "be" followed by "fr", No, it may not. Breton is "br" ("be" is Belorusian). _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 10 10:35:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHjeF-0007JZ-Mr; Fri, 10 Mar 2006 10:35:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHjeD-0007JU-Uj for ltru@ietf.org; Fri, 10 Mar 2006 10:35:21 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHjeB-0001wS-Ik for ltru@ietf.org; Fri, 10 Mar 2006 10:35:21 -0500 Received: from duringpersonlx (snvvpn-10-72-66-c242.corp.yahoo.com [10.72.66.242]) by mrout2.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k2AFVKnf034365; Fri, 10 Mar 2006 07:31:20 -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:x-mimeole:in-reply-to:thread-index; b=aIEoIgQ7H8U6UEg7srrhjTZwb5FKJw2TFgoDOBYW8SSUpmnjdy8syuAL/rHVu6vX From: "Addison Phillips" To: "'Stephane Bortzmeyer'" , "'Martin Duerst'" Subject: RE: [Ltru] Re: WG last call for draft-ietf-ltru-matching Date: Fri, 10 Mar 2006 07:33:39 -0800 Message-ID: <000401c64458$011bae80$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <20060310152029.GA29036@nic.fr> Thread-Index: AcZEVjvu+2wpj2R2RuO7ExzzY/bY0QAAampg X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Thanks for the comments. I've updated draft-12 with the change to Breton. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] > Sent: 2006?3?10? 7:20 > To: Martin Duerst > Cc: LTRU Working Group > Subject: [Ltru] Re: WG last call for draft-ietf-ltru-matching > > On Fri, Mar 10, 2006 at 07:41:55AM +0900, > Martin Duerst wrote > a message of 42 lines which said: > > > There have been no comments since that submission, which I hope is > > an indication that we can go to the next stage. > > I've read it and study it and I have no objections. (Warning: I'm not > an expert in languages and I'm a member of LTRU for only a small > time.) > > A small typo: > > A speaker of Breton in France, for example, may specify "be" followed > by "fr", > > No, it may not. Breton is "br" ("be" is Belorusian). > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 11 10:28:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI60b-0002VP-Fs; Sat, 11 Mar 2006 10:27:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI60a-0002VK-Is for ltru@ietf.org; Sat, 11 Mar 2006 10:27:56 -0500 Received: from outmail1.freedom2surf.net ([194.106.33.237] helo=outmail.freedom2surf.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FI60a-0008Pe-4Z for ltru@ietf.org; Sat, 11 Mar 2006 10:27:56 -0500 Received: from DEBHOME (i-83-67-121-192.freedom2surf.net [83.67.121.192]) by outmail.freedom2surf.net (8.12.10/8.12.10) with ESMTP id k2BFRr5K018573; Sat, 11 Mar 2006 15:27:54 GMT Message-Id: <200603111527.k2BFRr5K018573@outmail.freedom2surf.net> From: "Debbie Garside" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching Date: Sat, 11 Mar 2006 15:27:58 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <6.0.0.20.2.20060310060842.0649d470@localhost> Thread-index: AcZDyzcwjqjwd4VwRXifA/2PNP9SNwBUQ0Sw X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Editorial comment: Just a couple of paragraphs that do not read terribly well IMHO! Section 3.3 (paragraph under figure 3) 3rd sentence reads: "Not every specific level of tag granularity is usually available or language content may be sparsely populated." Proposed change to: "Language content may be sparsely populated and not every specific level of tag granularity is necessarily available". Section 4.1 paragraph 7 "Such alterations SHOULD be avoided, if possible, since they remove information that might be relevant elsewhere that would make use of that information." Proposed change to: "Such alterations SHOULD be avoided, if possible, since they remove information that might be relevant to other applications, specifications or protocols. Regards Debbie Garside > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 09 March 2006 22:42 > To: LTRU Working Group > Subject: [Ltru] WG last call for draft-ietf-ltru-matching > > The editors have submitted draft-11, which is now available at > http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-11.txt. > > There have been no comments since that submission, which I hope is > an indication that we can go to the next stage. > > I'm therefore starting a Working Group Last Call. The duration of the > Last Call is three (3) weeks to take into account the upcomming IETF > meeting, where many people may be busy. The Last Call will therefore > end on Thursday, March 30, 23:00 UTC (Friday, March 31st, 08:00 > Japan time, Thursday, March 30, 3pm US Pacific, and so on). > > Please read the above draft carefully and send in your comments. > Please mark each issue clearly, and indicate whether you think it > is editorial, substantive, or whatever. Please concentrate on > those points that you think are relevant for moving the document > forward (from typos to substantial oversights in case you find > any), rather than e.g. proposing yet another complicated new > matching scheme. Also, if there is any issue that you have found > earlier and that you think has not been appropriately addressed, > and you think it is still relevant for moving the document forward, > please mention this, too. > > If you read the document and did not find any issues, please > send a mail to say so! > > If as a result of WG Last Call, the document does not change > significantly, the document will be submitted to the Area > Director and the IESG for further processing. If the document > changes significantly, we will have another WG Last Call. > Significantly is defined as any change that reasonably may > create significant new comments/issues from somebody who > reviewed the document in this Last Call. > > Regards, Martin. > > > > _______________________________________________ > 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 Mar 13 04:01:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIivM-0002eE-1U; Mon, 13 Mar 2006 04:01:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIivK-0001z9-Mh for ltru@ietf.org; Mon, 13 Mar 2006 04:01:06 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIiuN-0006Oh-2M for ltru@ietf.org; Mon, 13 Mar 2006 04:00:08 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k2D8xGd13647; Mon, 13 Mar 2006 17:59:16 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1caf_a69729a4_b26f_11da_935f_0014221f2a2d; Mon, 13 Mar 2006 17:59:15 +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 k2D8tlOk011620; Mon, 13 Mar 2006 17:58:41 +0900 Message-Id: <6.0.0.20.2.20060313175230.07704d90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 13 Mar 2006 17:54:57 +0900 To: "Debbie Garside" , "'LTRU Working Group'" From: Martin Duerst Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching In-Reply-To: <200603111527.k2BFRr5K018573@outmail.freedom2surf.net> References: <6.0.0.20.2.20060310060842.0649d470@localhost> <200603111527.k2BFRr5K018573@outmail.freedom2surf.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [co-chair hat off] At 00:27 06/03/12, Debbie Garside wrote: >Editorial comment: > >Just a couple of paragraphs that do not read terribly well IMHO! > >Section 3.3 (paragraph under figure 3) 3rd sentence reads: > >"Not every specific level of tag granularity is usually available or >language content may be sparsely populated." > >Proposed change to: >"Language content may be sparsely populated and not every specific level of >tag granularity is necessarily available". +1 >Section 4.1 paragraph 7 > >"Such alterations SHOULD be avoided, if possible, since they remove >information that might be relevant elsewhere that would make use of that >information." > >Proposed change to: >"Such alterations SHOULD be avoided, if possible, since they remove >information that might be relevant to other applications, specifications or >protocols. Good, except that I'd exclude specifications, because in my view of the world, specifications are mere documents, which don't consume data. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 13 05:46:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIkZL-0003vq-5B; Mon, 13 Mar 2006 05:46:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIkZJ-0003vl-9Q for ltru@ietf.org; Mon, 13 Mar 2006 05:46:29 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIjLY-0007OQ-Na for ltru@ietf.org; Mon, 13 Mar 2006 04:28:12 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FIj5B-00008d-Fb for ltru@ietf.org; Mon, 13 Mar 2006 04:11:21 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k2D9BDu17869 for ; Mon, 13 Mar 2006 18:11:13 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1cb9_51cf26a4_b271_11da_99d2_0014221f2a2d; Mon, 13 Mar 2006 18:11:13 +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 k2D9AM6f011830 for ; Mon, 13 Mar 2006 18:10:47 +0900 Message-Id: <6.0.0.20.2.20060313180157.07770b80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 13 Mar 2006 18:10:13 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ltru] Issues list for WG Last Call for draft-ietf-ltru-matching X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I have started an issues list for the current WG Last Call. It can be found at http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. It doesn't use an (over)sophisticated system, just simple HTML (and Amaya and subversion for editing and publishing in the background). So if there is anything that should be fixed, please just tell me. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 13 06:04:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIkqy-0007G8-3l; Mon, 13 Mar 2006 06:04:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIkqw-0007G3-Qn for ltru@ietf.org; Mon, 13 Mar 2006 06:04:42 -0500 Received: from mta6.iomartmail.com ([62.128.193.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIkqv-0002AE-EA for ltru@ietf.org; Mon, 13 Mar 2006 06:04:42 -0500 Received: from mta6.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta6.iomartmail.com (8.12.11/8.12.8) with ESMTP id k2DB3CTh011144; Mon, 13 Mar 2006 11:03:12 GMT Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) (authenticated bits=0) by mta6.iomartmail.com (8.12.11/8.12.8) with ESMTP id k2DB3Bmu011124; Mon, 13 Mar 2006 11:03:12 GMT From: "Debbie Garside" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching Date: Mon, 13 Mar 2006 11:02:33 -0000 Message-ID: <027f01c6468d$a188d4b0$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: AcZGfGyv9vDhPQLuSdiWPPCKwuVJTQAEOQoQ In-Reply-To: <6.0.0.20.2.20060313175230.07704d90@localhost> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin wrote: > Good, except that I'd exclude specifications, because in my view of the world, specifications are mere documents, which don't consume data. In which case perhaps "specifications" needs to be taken out at the beginning of the paragraph? (from memory) Regards Debbie -----Original Message----- From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] Sent: 13 March 2006 08:55 To: Debbie Garside; 'LTRU Working Group' Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching [co-chair hat off] At 00:27 06/03/12, Debbie Garside wrote: >Editorial comment: > >Just a couple of paragraphs that do not read terribly well IMHO! > >Section 3.3 (paragraph under figure 3) 3rd sentence reads: > >"Not every specific level of tag granularity is usually available or >language content may be sparsely populated." > >Proposed change to: >"Language content may be sparsely populated and not every specific level of >tag granularity is necessarily available". +1 >Section 4.1 paragraph 7 > >"Such alterations SHOULD be avoided, if possible, since they remove >information that might be relevant elsewhere that would make use of that >information." > >Proposed change to: >"Such alterations SHOULD be avoided, if possible, since they remove >information that might be relevant to other applications, specifications or >protocols. Good, except that I'd exclude specifications, because in my view of the world, specifications are mere documents, which don't consume data. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 13 10:39:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIp8r-0007w2-47; Mon, 13 Mar 2006 10:39:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIp8p-0007rZ-Lb for ltru@ietf.org; Mon, 13 Mar 2006 10:39:27 -0500 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FIp8j-000254-Bd for ltru@ietf.org; Mon, 13 Mar 2006 10:39:27 -0500 Received: (qmail 22621 invoked from network); 13 Mar 2006 15:39:21 -0000 Received: from unknown (HELO ?192.168.1.102?) (unknown) by unknown with SMTP; 13 Mar 2006 15:39:21 -0000 X-pair-Authenticated: 24.23.194.196 Message-ID: <4415922A.3040300@icu-project.org> Date: Mon, 13 Mar 2006 07:39:22 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Issues list for WG Last Call for draft-ietf-ltru-matching References: <6.0.0.20.2.20060313180157.07770b80@localhost> In-Reply-To: <6.0.0.20.2.20060313180157.07770b80@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Thanks. And I agree with your take on improved language (Sections 3.3 and 4.1) . Mark Very minor, but could you add a title, so that it's distinguished in the Quick Launch bar? Martin Duerst wrote: > I have started an issues list for the current WG Last Call. > It can be found at http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. > > It doesn't use an (over)sophisticated system, just simple HTML > (and Amaya and subversion for editing and publishing in the background). > So if there is anything that should be fixed, please just tell me. > > Regards, Martin. > > _______________________________________________ > 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 Mar 13 11:43:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIq8y-00074r-02; Mon, 13 Mar 2006 11:43:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIq8x-00074m-Dw for ltru@ietf.org; Mon, 13 Mar 2006 11:43:39 -0500 Received: from mrout3.yahoo.com ([216.145.54.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIq8v-00049r-1N for ltru@ietf.org; Mon, 13 Mar 2006 11:43:39 -0500 Received: from duringpersonlx (nyvpn-c66.corp.yahoo.com [172.21.169.66]) by mrout3.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k2DGg0VQ098352; Mon, 13 Mar 2006 08:42:00 -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=hK7zJahovgKOlFNuENMX14V6T28+nXmqrucuvpJ70cCVl8tN8po1ti965iDcpi3W From: "Addison Phillips" To: "'Mark Davis'" , "'Martin Duerst'" Subject: RE: [Ltru] Issues list for WG Last Call for draft-ietf-ltru-matching Date: Mon, 13 Mar 2006 08:43:50 -0800 Message-ID: <002301c646bd$4ebcff10$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4415922A.3040300@icu-project.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-index: AcZGtFkg4Su+9Dn5RHmcN4+W40U9wAACLBzw X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1. Also, please number the issues (use an immutable number) so we can = reference as needed. Sotto voce: was it just too hard to use the same issue tracker we've = been using? Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006=E5=B9=B43=E6=9C=8813=E6=97=A5 7:39 > To: Martin Duerst > Cc: LTRU Working Group > Subject: Re: [Ltru] Issues list for WG Last Call for draft-ietf-ltru- > matching >=20 > Thanks. And I agree with your take on improved language (Sections 3.3 > and 4.1) archive/web/ltru/current/msg04691.html>. >=20 > Mark >=20 > Very minor, but could you add a title, so that it's distinguished in = the > Quick Launch bar? >=20 > Martin Duerst wrote: > > I have started an issues list for the current WG Last Call. > > It can be found at http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. > > > > It doesn't use an (over)sophisticated system, just simple HTML > > (and Amaya and subversion for editing and publishing in the = background). > > So if there is anything that should be fixed, please just tell me. > > > > Regards, Martin. > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 13 15:15:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FItRh-0007f2-2V; Mon, 13 Mar 2006 15:15:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FItRf-0007eO-VS for ltru@ietf.org; Mon, 13 Mar 2006 15:15:11 -0500 Received: from mrout2-b.corp.dcn.yahoo.com ([216.109.112.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FItRe-0003PR-Jx for ltru@ietf.org; Mon, 13 Mar 2006 15:15:11 -0500 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k2DKEYSd041401; Mon, 13 Mar 2006 12:14:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; b=S34jsb3tmUB5vkRxN0uoBf7MfBTZcGJu8d4QACdxN+lS+J/76oF0j7dXVR7qvVKQ From: "Addison Phillips" To: "'Martin Duerst'" , "'Debbie Garside'" , "'LTRU Working Group'" Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching Date: Mon, 13 Mar 2006 12:16:28 -0800 Message-ID: <000f01c646db$03514e00$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <6.0.0.20.2.20060313175230.07704d90@localhost> Thread-Index: AcZGfMMdphshsBAmRvOfogfNW5g/vQAXHzlw X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > >Section 3.3 (paragraph under figure 3) 3rd sentence reads: > > > >"Not every specific level of tag granularity is usually available or > >language content may be sparsely populated." > > > >Proposed change to: > >"Language content may be sparsely populated and not every specific level > of > >tag granularity is necessarily available". > I modified this proposal slightly to say: -- Language content is sometimes sparsely populated and content on every level of tag granularity might not be available. -- This not only eliminates the use of 2119 keywords, but eliminates the kind-of-chewy dependent clause. > > >Section 4.1 paragraph 7 > > > >"Such alterations SHOULD be avoided, if possible, since they remove > >information that might be relevant elsewhere that would make use of that > >information." > > > >Proposed change to: > >"Such alterations SHOULD be avoided, if possible, since they remove > >information that might be relevant to other applications, specifications > or > >protocols. > > Good, except that I'd exclude specifications, because in my > view of the world, specifications are mere documents, which don't > consume data. > Yuck. The existing text is clumsy and redundant. I'd rather go in the other direction and say less. I'd propose: -- Applications, specifications, or protocols that choose not to interpret one or more private-use or extension subtags SHOULD NOT remove or modify these extensions in content that they are processing, because this removes information which might be used elsewhere. When a language tag instance is to be used in a specific, known protocol, and is not being passed through to other protocols, language tags MAY be altered to remove subtags and extensions that are not supported by that protocol. -- Specifying what uses a language tag is not necessary. The point is that removing subtags alters meaning and might remove something of interest to someone else. Best Regards, Addison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 13 15:28:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIte9-00069h-Hp; Mon, 13 Mar 2006 15:28:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIte7-000693-Sa for ltru@ietf.org; Mon, 13 Mar 2006 15:28:03 -0500 Received: from outmail1.freedom2surf.net ([194.106.33.237] helo=outmail.freedom2surf.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIte7-00040r-GU for ltru@ietf.org; Mon, 13 Mar 2006 15:28:03 -0500 Received: from DEBHOME (i-83-67-121-192.freedom2surf.net [83.67.121.192]) by outmail.freedom2surf.net (8.12.10/8.12.10) with ESMTP id k2DKS25K009105; Mon, 13 Mar 2006 20:28:02 GMT Message-Id: <200603132028.k2DKS25K009105@outmail.freedom2surf.net> From: "Debbie Garside" To: "'Addison Phillips'" , "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching Date: Mon, 13 Mar 2006 20:28:08 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <000f01c646db$03514e00$9fcd15ac@ds.corp.yahoo.com> Thread-index: AcZGfMMdphshsBAmRvOfogfNW5g/vQAXHzlwAADTecA= X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison wrote: > When a language tag instance is > to be used in a specific, known protocol, and is not being passed > through to other protocols, language tags MAY be altered to remove > subtags and extensions that are not supported by that protocol. Don't like this... it encourages truncation and assumes foresight. If anything I would cut this bit out altogether and just have the active part as the 'SHOULD NOT' of the first sentence (yours updated). Best regards Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 13 March 2006 20:16 > To: 'Martin Duerst'; 'Debbie Garside'; 'LTRU Working Group' > Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching > > > > >Section 3.3 (paragraph under figure 3) 3rd sentence reads: > > > > > >"Not every specific level of tag granularity is usually available or > > >language content may be sparsely populated." > > > > > >Proposed change to: > > >"Language content may be sparsely populated and not every specific > level > > of > > >tag granularity is necessarily available". > > > I modified this proposal slightly to say: > > -- > Language content is sometimes sparsely populated and content on every > level > of tag granularity might not be available. > -- > > This not only eliminates the use of 2119 keywords, but eliminates the > kind-of-chewy dependent clause. > > > > >Section 4.1 paragraph 7 > > > > > >"Such alterations SHOULD be avoided, if possible, since they remove > > >information that might be relevant elsewhere that would make use of > that > > >information." > > > > > >Proposed change to: > > >"Such alterations SHOULD be avoided, if possible, since they remove > > >information that might be relevant to other applications, > specifications > > or > > >protocols. > > > > Good, except that I'd exclude specifications, because in my > > view of the world, specifications are mere documents, which don't > > consume data. > > > Yuck. The existing text is clumsy and redundant. I'd rather go in the > other > direction and say less. I'd propose: > > -- > Applications, specifications, or protocols that choose not to interpret > one or more private-use or extension subtags SHOULD NOT remove or modify > these extensions in content that they are processing, because this removes > information which might be used elsewhere. When a language tag instance is > to be used in a specific, known protocol, and is not being passed through > to > other protocols, language tags MAY be altered to remove subtags and > extensions that are not supported by that protocol. > -- > > Specifying what uses a language tag is not necessary. The point is that > removing subtags alters meaning and might remove something of interest to > someone else. > > Best Regards, > > Addison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 13 16:53:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIuzB-0004gE-OC; Mon, 13 Mar 2006 16:53:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIuzB-0004g9-3g for ltru@ietf.org; Mon, 13 Mar 2006 16:53:53 -0500 Received: from mrout2-b.corp.dcn.yahoo.com ([216.109.112.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIuz8-0006fm-Qb for ltru@ietf.org; Mon, 13 Mar 2006 16:53:53 -0500 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k2DLrRwC052181; Mon, 13 Mar 2006 13:53:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; b=eQ3wrlitiUX2OCbCWsKjkfHyy08DgUVy6jQaqnI+I/xvvtO+xn2gZOdDIYn9ufwa From: "Addison Phillips" To: "'Debbie Garside'" , "'Martin Duerst'" , "'Debbie Garside'" , "'LTRU Working Group'" Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching Date: Mon, 13 Mar 2006 13:55:19 -0800 Message-ID: <001301c646e8$d2e81560$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <200603132024.k2DKOt5K005602@outmail.freedom2surf.net> Thread-Index: AcZGfMMdphshsBAmRvOfogfNW5g/vQAXHzlwAACEiBAAAshqcA== X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I don't disagree... in fact, the sentence merely repeats the opposite of the preceding "MAY". Removing it, though, leaves behind the original reason for this sentence... How about: -- A protocol or application that consumes language tags MAY remove unsupported extensions or subtags to make processing more efficient, as long as the truncated tag is not forwarded to other processes. -- Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Debbie Garside [mailto:debbiegarside@ictmarketing.co.uk] > Sent: 2006?3?13? 12:25 > To: 'Addison Phillips'; 'Martin Duerst'; 'Debbie Garside'; 'LTRU Working > Group' > Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching > > Addison wrote: > > When a language tag instance is > > to be used in a specific, known protocol, and is not being passed > through > > to other protocols, language tags MAY be altered to remove subtags and > > extensions that are not supported by that protocol. > > Don't like this... it encourages truncation and assumes foresight. If > anything I would cut this bit out altogether and just have the active part > as the 'SHOULD NOT' of the first sentence (yours updated). > > Best regards > > > Debbie > > > -----Original Message----- > > From: Addison Phillips [mailto:addison@yahoo-inc.com] > > Sent: 13 March 2006 20:16 > > To: 'Martin Duerst'; 'Debbie Garside'; 'LTRU Working Group' > > Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching > > > > > > > >Section 3.3 (paragraph under figure 3) 3rd sentence reads: > > > > > > > >"Not every specific level of tag granularity is usually available or > > > >language content may be sparsely populated." > > > > > > > >Proposed change to: > > > >"Language content may be sparsely populated and not every specific > > level > > > of > > > >tag granularity is necessarily available". > > > > > I modified this proposal slightly to say: > > > > -- > > Language content is sometimes sparsely populated and content on every > > level > > of tag granularity might not be available. > > -- > > > > This not only eliminates the use of 2119 keywords, but eliminates the > > kind-of-chewy dependent clause. > > > > > > >Section 4.1 paragraph 7 > > > > > > > >"Such alterations SHOULD be avoided, if possible, since they remove > > > >information that might be relevant elsewhere that would make use of > > that > > > >information." > > > > > > > >Proposed change to: > > > >"Such alterations SHOULD be avoided, if possible, since they remove > > > >information that might be relevant to other applications, > > specifications > > > or > > > >protocols. > > > > > > Good, except that I'd exclude specifications, because in my > > > view of the world, specifications are mere documents, which don't > > > consume data. > > > > > Yuck. The existing text is clumsy and redundant. I'd rather go in the > > other > > direction and say less. I'd propose: > > > > -- > > Applications, specifications, or protocols that choose not to > interpret > > one or more private-use or extension subtags SHOULD NOT remove or modify > > these extensions in content that they are processing, because this > removes > > information which might be used elsewhere. When a language tag instance > is > > to be used in a specific, known protocol, and is not being passed > through > > to > > other protocols, language tags MAY be altered to remove subtags and > > extensions that are not supported by that protocol. > > -- > > > > Specifying what uses a language tag is not necessary. The point is that > > removing subtags alters meaning and might remove something of interest > to > > someone else. > > > > Best Regards, > > > > Addison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 13 16:57:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIv2x-0005cL-Cx; Mon, 13 Mar 2006 16:57:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIv2w-0005cG-Gv for ltru@ietf.org; Mon, 13 Mar 2006 16:57:46 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIv2u-0006mw-7K for ltru@ietf.org; Mon, 13 Mar 2006 16:57:46 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FIv2q-0005cp-LO; Mon, 13 Mar 2006 16:57:40 -0500 Date: Mon, 13 Mar 2006 16:57:40 -0500 To: Addison Phillips Subject: Re: [Ltru] WG last call for draft-ietf-ltru-matching Message-ID: <20060313215740.GB6813@ccil.org> References: <200603132024.k2DKOt5K005602@outmail.freedom2surf.net> <001301c646e8$d2e81560$9fcd15ac@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001301c646e8$d2e81560$9fcd15ac@ds.corp.yahoo.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'Debbie Garside' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > A protocol or application that consumes language tags MAY remove unsupported > extensions or subtags to make processing more efficient, as long as the > truncated tag is not forwarded to other processes. "outside the scope of the protocol or application". The whole point of this hooraw is that IPP clients shouldn't send script subtags to IPP servers. -- John Cowan cowan@ccil.org www.ccil.org/~cowan www.ap.org The penguin geeks is happy / As under the waves they lark The closed-source geeks ain't happy / They sad cause they in the dark But geeks in the dark is lucky / They in for a worser treat One day when the Borg go belly-up / Guess who wind up on the street. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 13 17:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvoX-0001Xg-88; Mon, 13 Mar 2006 17:46:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIvoV-0001Xb-Kr for ltru@ietf.org; Mon, 13 Mar 2006 17:46:55 -0500 Received: from outmail1.freedom2surf.net ([194.106.33.237] helo=outmail.freedom2surf.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIvoV-0008Bw-6z for ltru@ietf.org; Mon, 13 Mar 2006 17:46:55 -0500 Received: from DEBHOME (i-83-67-121-192.freedom2surf.net [83.67.121.192]) by outmail.freedom2surf.net (8.12.10/8.12.10) with ESMTP id k2DMkq5K029104; Mon, 13 Mar 2006 22:46:52 GMT Message-Id: <200603132246.k2DMkq5K029104@outmail.freedom2surf.net> From: "Debbie Garside" To: "'Addison Phillips'" , "'Debbie Garside'" , "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching Date: Mon, 13 Mar 2006 22:46:58 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <001301c646e8$d2e81560$9fcd15ac@ds.corp.yahoo.com> Thread-index: AcZGfMMdphshsBAmRvOfogfNW5g/vQAXHzlwAACEiBAAAshqcAACIcfw X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org YUCK! Consumes...!!! How about: Unsupported extensions or subtags MAY be removed by applications or protocols during processing but MUST remain intact when forwarded. Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 13 March 2006 21:55 > To: 'Debbie Garside'; 'Martin Duerst'; 'Debbie Garside'; 'LTRU Working > Group' > Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching > > I don't disagree... in fact, the sentence merely repeats the opposite of > the > preceding "MAY". Removing it, though, leaves behind the original reason > for > this sentence... > > How about: > > -- > A protocol or application that consumes language tags MAY remove > unsupported > extensions or subtags to make processing more efficient, as long as the > truncated tag is not forwarded to other processes. > -- > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > -----Original Message----- > > From: Debbie Garside [mailto:debbiegarside@ictmarketing.co.uk] > > Sent: 2006?3?13? 12:25 > > To: 'Addison Phillips'; 'Martin Duerst'; 'Debbie Garside'; 'LTRU Working > > Group' > > Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching > > > > Addison wrote: > > > > When a language tag instance is > > > to be used in a specific, known protocol, and is not being passed > > through > > > to other protocols, language tags MAY be altered to remove subtags and > > > extensions that are not supported by that protocol. > > > > Don't like this... it encourages truncation and assumes foresight. If > > anything I would cut this bit out altogether and just have the active > part > > as the 'SHOULD NOT' of the first sentence (yours updated). > > > > Best regards > > > > > > Debbie > > > > > -----Original Message----- > > > From: Addison Phillips [mailto:addison@yahoo-inc.com] > > > Sent: 13 March 2006 20:16 > > > To: 'Martin Duerst'; 'Debbie Garside'; 'LTRU Working Group' > > > Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching > > > > > > > > > > >Section 3.3 (paragraph under figure 3) 3rd sentence reads: > > > > > > > > > >"Not every specific level of tag granularity is usually available > or > > > > >language content may be sparsely populated." > > > > > > > > > >Proposed change to: > > > > >"Language content may be sparsely populated and not every specific > > > level > > > > of > > > > >tag granularity is necessarily available". > > > > > > > I modified this proposal slightly to say: > > > > > > -- > > > Language content is sometimes sparsely populated and content on every > > > level > > > of tag granularity might not be available. > > > -- > > > > > > This not only eliminates the use of 2119 keywords, but eliminates the > > > kind-of-chewy dependent clause. > > > > > > > > >Section 4.1 paragraph 7 > > > > > > > > > >"Such alterations SHOULD be avoided, if possible, since they > remove > > > > >information that might be relevant elsewhere that would make use > of > > > that > > > > >information." > > > > > > > > > >Proposed change to: > > > > >"Such alterations SHOULD be avoided, if possible, since they > remove > > > > >information that might be relevant to other applications, > > > specifications > > > > or > > > > >protocols. > > > > > > > > Good, except that I'd exclude specifications, because in my > > > > view of the world, specifications are mere documents, which don't > > > > consume data. > > > > > > > Yuck. The existing text is clumsy and redundant. I'd rather go in the > > > other > > > direction and say less. I'd propose: > > > > > > -- > > > Applications, specifications, or protocols that choose not to > > interpret > > > one or more private-use or extension subtags SHOULD NOT remove or > modify > > > these extensions in content that they are processing, because this > > removes > > > information which might be used elsewhere. When a language tag > instance > > is > > > to be used in a specific, known protocol, and is not being passed > > through > > > to > > > other protocols, language tags MAY be altered to remove subtags and > > > extensions that are not supported by that protocol. > > > -- > > > > > > Specifying what uses a language tag is not necessary. The point is > that > > > removing subtags alters meaning and might remove something of interest > > to > > > someone else. > > > > > > Best Regards, > > > > > > Addison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 13 18:01:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIw33-0000x8-CE; Mon, 13 Mar 2006 18:01:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FItbD-0005Nn-H4 for ltru@ietf.org; Mon, 13 Mar 2006 15:25:03 -0500 Received: from outmail1.freedom2surf.net ([194.106.33.237] helo=outmail.freedom2surf.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FItbC-0003wH-3R for ltru@ietf.org; Mon, 13 Mar 2006 15:25:03 -0500 Received: from DEBHOME (i-83-67-121-192.freedom2surf.net [83.67.121.192]) by outmail.freedom2surf.net (8.12.10/8.12.10) with ESMTP id k2DKOt5K005602; Mon, 13 Mar 2006 20:24:55 GMT Message-Id: <200603132024.k2DKOt5K005602@outmail.freedom2surf.net> From: "Debbie Garside" To: "'Addison Phillips'" , "'Martin Duerst'" , "'Debbie Garside'" , "'LTRU Working Group'" Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching Date: Mon, 13 Mar 2006 20:25:00 -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 In-reply-to: <000f01c646db$03514e00$9fcd15ac@ds.corp.yahoo.com> Thread-index: AcZGfMMdphshsBAmRvOfogfNW5g/vQAXHzlwAACEiBA= X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-Mailman-Approved-At: Mon, 13 Mar 2006 18:01:56 -0500 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison wrote: When a language tag instance is > to be used in a specific, known protocol, and is not being passed through > to other protocols, language tags MAY be altered to remove subtags and > extensions that are not supported by that protocol. Don't like this... it encourages truncation and assumes foresight. If anything I would cut this bit out altogether and just have the active part as the 'SHOULD NOT' of the first sentence (yours updated). Best regards Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 13 March 2006 20:16 > To: 'Martin Duerst'; 'Debbie Garside'; 'LTRU Working Group' > Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching > > > > >Section 3.3 (paragraph under figure 3) 3rd sentence reads: > > > > > >"Not every specific level of tag granularity is usually available or > > >language content may be sparsely populated." > > > > > >Proposed change to: > > >"Language content may be sparsely populated and not every specific > level > > of > > >tag granularity is necessarily available". > > > I modified this proposal slightly to say: > > -- > Language content is sometimes sparsely populated and content on every > level > of tag granularity might not be available. > -- > > This not only eliminates the use of 2119 keywords, but eliminates the > kind-of-chewy dependent clause. > > > > >Section 4.1 paragraph 7 > > > > > >"Such alterations SHOULD be avoided, if possible, since they remove > > >information that might be relevant elsewhere that would make use of > that > > >information." > > > > > >Proposed change to: > > >"Such alterations SHOULD be avoided, if possible, since they remove > > >information that might be relevant to other applications, > specifications > > or > > >protocols. > > > > Good, except that I'd exclude specifications, because in my > > view of the world, specifications are mere documents, which don't > > consume data. > > > Yuck. The existing text is clumsy and redundant. I'd rather go in the > other > direction and say less. I'd propose: > > -- > Applications, specifications, or protocols that choose not to interpret > one or more private-use or extension subtags SHOULD NOT remove or modify > these extensions in content that they are processing, because this removes > information which might be used elsewhere. When a language tag instance is > to be used in a specific, known protocol, and is not being passed through > to > other protocols, language tags MAY be altered to remove subtags and > extensions that are not supported by that protocol. > -- > > Specifying what uses a language tag is not necessary. The point is that > removing subtags alters meaning and might remove something of interest to > someone else. > > Best Regards, > > Addison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 13 18:34:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIwYR-0004EX-5x; Mon, 13 Mar 2006 18:34:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIwYP-0004ES-FK for ltru@ietf.org; Mon, 13 Mar 2006 18:34:21 -0500 Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIwYN-0001g7-VV for ltru@ietf.org; Mon, 13 Mar 2006 18:34:21 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged)) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2DNY89G004989; Mon, 13 Mar 2006 15:34:08 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Mar 2006 15:34:08 -0800 Message-ID: From: "McDonald, Ira" To: "'John Cowan'" , Addison Phillips Subject: RE: [Ltru] WG last call for draft-ietf-ltru-matching Date: Mon, 13 Mar 2006 15:34:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'Debbie Garside' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi John, On the contrary, the whole point is that ALL applications SHOULD NOT send unnecessary subtags to other applications, protocols, or systems. And language about not stripping unsupported subtags when "forwarding" them will be (thank goodness) ignored by sensible implementors. The first doctor who finds the cancer cuts it out. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Monday, March 13, 2006 4:58 PM > To: Addison Phillips > Cc: 'Debbie Garside'; 'LTRU Working Group' > Subject: Re: [Ltru] WG last call for draft-ietf-ltru-matching > > > Addison Phillips scripsit: > > > A protocol or application that consumes language tags MAY > remove unsupported > > extensions or subtags to make processing more efficient, as > long as the > > truncated tag is not forwarded to other processes. > > "outside the scope of the protocol or application". > > The whole point of this hooraw is that IPP clients shouldn't > send script > subtags to IPP servers. > > -- > John Cowan cowan@ccil.org www.ccil.org/~cowan www.ap.org > The penguin geeks is happy / As under the waves they lark > The closed-source geeks ain't happy / They sad cause they in the dark > But geeks in the dark is lucky / They in for a worser treat > One day when the Borg go belly-up / Guess who wind up on the street. > > _______________________________________________ > 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 Mar 14 00:57:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ2Xc-0003qs-6W; Tue, 14 Mar 2006 00:57:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ2Xb-0003qk-Ey for ltru@ietf.org; Tue, 14 Mar 2006 00:57:55 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ2XY-0005Mo-Sq for ltru@ietf.org; Tue, 14 Mar 2006 00:57:55 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k2E5vgu21903; Tue, 14 Mar 2006 14:57:42 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 5092_734bb488_b31f_11da_9293_0014221f2a2d; Tue, 14 Mar 2006 14:57:41 +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 k2E5ucsG024725; Tue, 14 Mar 2006 14:57:04 +0900 Message-Id: <6.0.0.20.2.20060314120104.08a374c0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 14 Mar 2006 12:01:39 +0900 To: Mark Davis From: Martin Duerst Subject: Re: [Ltru] Issues list for WG Last Call for draft-ietf-ltru-matching In-Reply-To: <4415922A.3040300@icu-project.org> References: <6.0.0.20.2.20060313180157.07770b80@localhost> <4415922A.3040300@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 00:39 06/03/14, Mark Davis wrote: >Very minor, but could you add a title, so that it's distinguished in the Quick Launch bar? Sorry, fixed. Martin. >Martin Duerst wrote: >> I have started an issues list for the current WG Last Call. >> It can be found at http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 14 00:58:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ2Xi-0003tv-D3; Tue, 14 Mar 2006 00:58:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ2Xg-0003tq-U3 for ltru@ietf.org; Tue, 14 Mar 2006 00:58:00 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ2Xf-0005O9-Ci for ltru@ietf.org; Tue, 14 Mar 2006 00:58:00 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k2E5vrd29068; Tue, 14 Mar 2006 14:57:53 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 50de_7a104f72_b31f_11da_8ab1_0014221f2a2d; Tue, 14 Mar 2006 14:57:52 +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 k2E5ucsI024725; Tue, 14 Mar 2006 14:57:27 +0900 Message-Id: <6.0.0.20.2.20060314121349.05f75940@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 14 Mar 2006 12:15:19 +0900 To: "Addison Phillips" , "'Mark Davis'" From: Martin Duerst Subject: RE: [Ltru] Issues list for WG Last Call for draft-ietf-ltru-matching In-Reply-To: <002301c646bd$4ebcff10$660a0a0a@ds.corp.yahoo.com> References: <4415922A.3040300@icu-project.org> <002301c646bd$4ebcff10$660a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 01:43 06/03/14, Addison Phillips wrote: >+1. Also, please number the issues (use an immutable number) so we can >reference as needed. Done. >Sotto voce: was it just too hard to use the same issue tracker we've been using? Well, yes. I had difficulties getting to understand how it worked, and I didn't terribly like what I saw. But that may be just me. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 14 10:00:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJB0h-0004xy-Ve; Tue, 14 Mar 2006 10:00:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJB0g-0004uZ-2D for ltru@ietf.org; Tue, 14 Mar 2006 10:00:30 -0500 Received: from [63.247.75.140] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJB0e-0003ju-SR for ltru@ietf.org; Tue, 14 Mar 2006 10:00:30 -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 1FJB0Z-0000wr-3I; Tue, 14 Mar 2006 07:00:23 -0800 Message-Id: <6.2.3.4.2.20060314142757.04f1a6f0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Tue, 14 Mar 2006 14:30:14 +0100 To: Martin Duerst , "Addison Phillips" , "'Mark Davis'" From: r&d afrac Subject: RE: [Ltru] Issues list for WG Last Call for draft-ietf-ltru-matching In-Reply-To: <6.0.0.20.2.20060314121349.05f75940@localhost> References: <4415922A.3040300@icu-project.org> <002301c646bd$4ebcff10$660a0a0a@ds.corp.yahoo.com> <6.0.0.20.2.20060314121349.05f75940@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-58A47272 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 04:15 14/03/2006, Martin Duerst wrote: > >Sotto voce: was it just too hard to use the same issue tracker > we've been using? > >Well, yes. I had difficulties getting to understand how it worked, >and I didn't terribly like what I saw. But that may be just me. Was it not just something to change my remarks, burry them, refuse them and pretend they had already been addressed, etc. :-) I am sorry I cannot contribute to this debate as I would like - for pressing personal family reasons. I will issue a global review in the coming days. I wish you good luck with all this. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 14 10:13:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJBDW-0004Kg-1O; Tue, 14 Mar 2006 10:13:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJBDU-0004Kb-2C for ltru@ietf.org; Tue, 14 Mar 2006 10:13:44 -0500 Received: from relay02.pair.com ([209.68.5.16]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJBDS-0004JI-RO for ltru@ietf.org; Tue, 14 Mar 2006 10:13:44 -0500 Received: (qmail 72980 invoked from network); 14 Mar 2006 15:13:42 -0000 Received: from unknown (HELO ?192.168.1.104?) (unknown) by unknown with SMTP; 14 Mar 2006 15:13:42 -0000 X-pair-Authenticated: 24.23.194.196 Message-ID: <4416DD8C.8040101@icu-project.org> Date: Tue, 14 Mar 2006 07:13:16 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Issues list for WG Last Call for draft-ietf-ltru-matching References: <4415922A.3040300@icu-project.org> <002301c646bd$4ebcff10$660a0a0a@ds.corp.yahoo.com> <6.0.0.20.2.20060314121349.05f75940@localhost> In-Reply-To: <6.0.0.20.2.20060314121349.05f75940@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I prefer a simple list, like what Martin has set up. We shouldn't need any more than that for this. Mark Martin Duerst wrote: > At 01:43 06/03/14, Addison Phillips wrote: > >+1. Also, please number the issues (use an immutable number) so we can > >reference as needed. > > Done. > > >Sotto voce: was it just too hard to use the same issue tracker we've > been using? > > Well, yes. I had difficulties getting to understand how it worked, > and I didn't terribly like what I saw. But that may be just me. > > Regards, Martin. > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 16 19:04:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK2SQ-0001mT-92; Thu, 16 Mar 2006 19:04:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK2SO-0001hw-NO for ltru@ietf.org; Thu, 16 Mar 2006 19:04:40 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK2SN-00082J-G0 for ltru@ietf.org; Thu, 16 Mar 2006 19:04:40 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FK2SL-0006z5-V2 for ltru@ietf.org; Thu, 16 Mar 2006 16:04:38 -0800 Message-Id: <6.2.3.4.2.20060316221118.04dc73a0@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Thu, 16 Mar 2006 22:36:47 +0100 To: ltru@ietf.org From: r&d afrac Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-64DCF6 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ltru] ltru-matching draft review X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I reviewed the ltru-matching draft. 1. the term "matching" is improper for the whole document.The purpose if filtering, even if pattern matching techniques are used. The purpose is not to list all the possible langtags matching the documented pattern, but to okay or not a langtag for a given usage. This is documented in 3.1.1- 3.1.3, 3.1.3 is not matching the pattern but the priorities (i.e. first filtered). The last paragraph of the very very long part 3.3. without sub-part numbers, document the uncertain results of a matching while filtering is respected. 2. figure 3 is in violation with 4.3. as it seems to presume that the x-private1-private2 can be neuronally abbreviated as x-private1. This obligation is not documented in RFC 3066 Bis. 3. Part 4.1 is particularly laborious and indigestible. It seems to introduce a lot semi-constraints with uncertain results to RFC 3066 Bis. 4. security considerations are as inappropriate as the security considerations of RFC 3066 Bis. This whole system introduces and uses an unusual pattern easily searched/filtered which is usually not visible to the receiving party. That receiving party when responding send it back and discloses its positive filtering (retro-meta-spam). As such the proposed filtering is a most efficient source of cultural, racial and religious intelligence leaks. Together with the dissemination of RFC 3066 Bis langtags, search engines queries using the proposed rules should be efficient in terms of mass profiling. This risk should be documented in Security Considerations. I would suggest that parts 3.3 and 4.1 be structured in several separate blocks. To make them easier to read and to refer to. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 17 05:00:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBkX-0000xG-Rv; Fri, 17 Mar 2006 05:00:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKBkX-0000wH-DU for ltru@ietf.org; Fri, 17 Mar 2006 05:00:01 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKBN3-00084P-EE for ltru@ietf.org; Fri, 17 Mar 2006 04:35:45 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FKBBQ-0006JR-Cl for ltru@ietf.org; Fri, 17 Mar 2006 04:23:47 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k2H9NVd19710; Fri, 17 Mar 2006 18:23:32 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 32e4_b3511760_b597_11da_9577_0014221f2a2d; Fri, 17 Mar 2006 18:23:31 +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 k2H9LA6x009790; Fri, 17 Mar 2006 18:22:55 +0900 Message-Id: <6.0.0.20.2.20060317181153.07f8bec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 17 Mar 2006 18:14:57 +0900 To: r&d afrac , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] ltru-matching draft review In-Reply-To: <6.2.3.4.2.20060316221118.04dc73a0@pop.online.fr> References: <6.2.3.4.2.20060316221118.04dc73a0@pop.online.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Thanks for reviewing the draft. I have added your issues to the issues list. Please check whether I got things right. Some more comments from a co-chair's viewpoint below. At 06:36 06/03/17, r&d afrac wrote: >I reviewed the ltru-matching draft. > >1. the term "matching" is improper for the whole document.The purpose if filtering, even if pattern matching techniques are used. The purpose is not to list all the possible langtags matching the documented pattern, but to okay or not a langtag for a given usage. This is documented in 3.1.1- 3.1.3, 3.1.3 is not matching the pattern but the priorities (i.e. first filtered). The last paragraph of the very very long part 3.3. without sub-part numbers, document the uncertain results of a matching while filtering is respected. > >2. figure 3 is in violation with 4.3. as it seems to presume that the x-private1-private2 can be neuronally abbreviated as x-private1. This obligation is not documented in RFC 3066 Bis. > >3. Part 4.1 is particularly laborious and indigestible. It seems to introduce a lot semi-constraints with uncertain results to RFC 3066 Bis. > >4. security considerations are as inappropriate as the security considerations of RFC 3066 Bis. As a co-chair, I have to work under the assumption that the WG thinks that the security considerations of RFC 3066bis are adequate. I do not see any reason why to reopen this issue that we have discussed when we actually worked on RFC 3066bis. Regards, Martin. >This whole system introduces and uses an unusual pattern easily searched/filtered which is usually not visible to the receiving party. That receiving party when responding send it back and discloses its positive filtering (retro-meta-spam). As such the proposed filtering is a most efficient source of cultural, racial and religious intelligence leaks. Together with the dissemination of RFC 3066 Bis langtags, search engines queries using the proposed rules should be efficient in terms of mass profiling. This risk should be documented in Security Considerations. > >I would suggest that parts 3.3 and 4.1 be structured in several separate blocks. To make them easier to read and to refer to. > >jfc > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 17 05:24:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKC7r-0004Vx-09; Fri, 17 Mar 2006 05:24:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKC7p-0004Vk-L9 for ltru@ietf.org; Fri, 17 Mar 2006 05:24:05 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKC7p-0001LD-Bq for ltru@ietf.org; Fri, 17 Mar 2006 05:24:05 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FKC7n-0003te-1e; Fri, 17 Mar 2006 02:24:03 -0800 Message-Id: <6.2.3.4.2.20060317111538.0712e540@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 17 Mar 2006 11:20:02 +0100 To: Martin Duerst ,ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] ltru-matching draft review In-Reply-To: <6.0.0.20.2.20060317181153.07f8bec0@localhost> References: <6.2.3.4.2.20060316221118.04dc73a0@pop.online.fr> <6.0.0.20.2.20060317181153.07f8bec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-9932967 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 10:14 17/03/2006, Martin Duerst wrote: >Thanks for reviewing the draft. > >I have added your issues to the issues list. >Please check whether I got things right. > >Some more comments from a co-chair's viewpoint below. > >At 06:36 06/03/17, r&d afrac wrote: > >I reviewed the ltru-matching draft. > > > >1. the term "matching" is improper for the whole document.The > purpose if filtering, even if pattern matching techniques are used. > The purpose is not to list all the possible langtags matching the > documented pattern, but to okay or not a langtag for a given usage. > This is documented in 3.1.1- 3.1.3, 3.1.3 is not matching the > pattern but the priorities (i.e. first filtered). The last > paragraph of the very very long part 3.3. without sub-part numbers, > document the uncertain results of a matching while filtering is respected. > > > >2. figure 3 is in violation with 4.3. as it seems to presume that > the x-private1-private2 can be neuronally abbreviated as > x-private1. This obligation is not documented in RFC 3066 Bis. > > > >3. Part 4.1 is particularly laborious and indigestible. It seems > to introduce a lot semi-constraints with uncertain results to RFC 3066 Bis. > > > >4. security considerations are as inappropriate as the security > considerations of RFC 3066 Bis. > >As a co-chair, I have to work under the assumption that the WG >thinks that the security considerations of RFC 3066bis are >adequate. I do not see any reason why to reopen this issue that >we have discussed when we actually worked on RFC 3066bis. > >Regards, Martin. There are two distinct issues. - the lack of warning about the RFC 3066 Bis pattern, which is an RFC 3066 Bis issue and will be documented as dangerous in a document we will publish. The risk there is against privacy.. - the lack of warning about the added risks by this document which explains how langtags are filtered and which will be used in other standards. The added risks comes from the generalisation of this method. The risk is now mass profiling. Security considerations should be neutral and list all the reasonably raised risks. Not listing risks isnot a way to defend a document. On the contrary it is a way to raise suspicions about the document. Everyone will know and assess these risks. Not listing them as for RFC 3066 bis does no good for the use of the document. We will document this not to hurt the system, but to make credible that we refer to it. jfc > >This whole system introduces and uses an unusual pattern easily > searched/filtered which is usually not visible to the receiving > party. That receiving party when responding send it back and > discloses its positive filtering (retro-meta-spam). As such the > proposed filtering is a most efficient source of cultural, racial > and religious intelligence leaks. Together with the dissemination > of RFC 3066 Bis langtags, search engines queries using the proposed > rules should be efficient in terms of mass profiling. This risk > should be documented in Security Considerations. > > > >I would suggest that parts 3.3 and 4.1 be structured in several > separate blocks. To make them easier to read and to refer to. > > > >jfc > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 17 13:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJhK-000780-Be; Fri, 17 Mar 2006 13:29:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKJhJ-00077n-6o for ltru@ietf.org; Fri, 17 Mar 2006 13:29:13 -0500 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FKJhI-0000Vf-VO for ltru@ietf.org; Fri, 17 Mar 2006 13:29:13 -0500 Received: (qmail 54051 invoked from network); 17 Mar 2006 18:29:12 -0000 Received: from unknown (HELO ?172.24.99.232?) (unknown) by unknown with SMTP; 17 Mar 2006 18:29:12 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <441AFFF1.1050101@icu-project.org> Date: Fri, 17 Mar 2006 10:29:05 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] ltru-matching draft review References: <6.2.3.4.2.20060316221118.04dc73a0@pop.online.fr> <6.0.0.20.2.20060317181153.07f8bec0@localhost> In-Reply-To: <6.0.0.20.2.20060317181153.07f8bec0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > As a co-chair, I have to work under the assumption that the WG > thinks that the security considerations of RFC 3066bis are > adequate. I do not see any reason why to reopen this issue that > we have discussed when we actually worked on RFC 3066bis. I agree. Mark Martin Duerst wrote: > Thanks for reviewing the draft. > > I have added your issues to the issues list. > Please check whether I got things right. > > Some more comments from a co-chair's viewpoint below. > > At 06:36 06/03/17, r&d afrac wrote: > >I reviewed the ltru-matching draft. > > > >1. the term "matching" is improper for the whole document.The purpose > if filtering, even if pattern matching techniques are used. The > purpose is not to list all the possible langtags matching the > documented pattern, but to okay or not a langtag for a given usage. > This is documented in 3.1.1- 3.1.3, 3.1.3 is not matching the pattern > but the priorities (i.e. first filtered). The last paragraph of the > very very long part 3.3. without sub-part numbers, document the > uncertain results of a matching while filtering is respected. > > > >2. figure 3 is in violation with 4.3. as it seems to presume that the > x-private1-private2 can be neuronally abbreviated as x-private1. This > obligation is not documented in RFC 3066 Bis. > > > >3. Part 4.1 is particularly laborious and indigestible. It seems to > introduce a lot semi-constraints with uncertain results to RFC 3066 Bis. > > > >4. security considerations are as inappropriate as the security > considerations of RFC 3066 Bis. > > As a co-chair, I have to work under the assumption that the WG > thinks that the security considerations of RFC 3066bis are > adequate. I do not see any reason why to reopen this issue that > we have discussed when we actually worked on RFC 3066bis. > > Regards, Martin. > > >This whole system introduces and uses an unusual pattern easily > searched/filtered which is usually not visible to the receiving party. > That receiving party when responding send it back and discloses its > positive filtering (retro-meta-spam). As such the proposed filtering > is a most efficient source of cultural, racial and religious > intelligence leaks. Together with the dissemination of RFC 3066 Bis > langtags, search engines queries using the proposed rules should be > efficient in terms of mass profiling. This risk should be documented > in Security Considerations. > > > >I would suggest that parts 3.3 and 4.1 be structured in several > separate blocks. To make them easier to read and to refer to. > > > >jfc > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 18 22:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKoZv-0002PO-Bd; Sat, 18 Mar 2006 22:27:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKoZu-0002OF-3g for ltru@ietf.org; Sat, 18 Mar 2006 22:27:38 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKoZs-000302-TK for ltru@ietf.org; Sat, 18 Mar 2006 22:27:38 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FKoZp-0003Oa-KM; Sat, 18 Mar 2006 19:27:34 -0800 Message-Id: <6.2.3.4.2.20060319040937.06d49b20@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 19 Mar 2006 04:16:57 +0100 To: Mark Davis , Martin Duerst From: r&d afrac Subject: Re: [Ltru] ltru-matching draft review In-Reply-To: <441AFFF1.1050101@icu-project.org> References: <6.2.3.4.2.20060316221118.04dc73a0@pop.online.fr> <6.0.0.20.2.20060317181153.07f8bec0@localhost> <441AFFF1.1050101@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-7F0216F4 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 04:34 18/03/2006, Mark Davis wrote: >>As a co-chair, I have to work under the assumption that the WG >>thinks that the security considerations of RFC 3066bis are >>adequate. I do not see any reason why to reopen this issue that >>we have discussed when we actually worked on RFC 3066bis. >I agree. > >Mark Then, I will appeal this. An US disregard for privacy laws may suit the Internationalised US Internet. It does not the Multilingual Internet, I think the IETF propositions should be kept interoperable with. If not, we will need to document non-US users that before warning them, as we will, we tried our best to protect them. jfc _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 19 04:29:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKuDh-0005yB-Jr; Sun, 19 Mar 2006 04:29:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKuDg-0005wk-80 for ltru@ietf.org; Sun, 19 Mar 2006 04:29:04 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKuDe-000366-Ke for ltru@ietf.org; Sun, 19 Mar 2006 04:29:04 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k2J9Srd29832; Sun, 19 Mar 2006 18:28:53 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 6009_c7ed91f0_b72a_11da_8119_0014221fa3c9; Sun, 19 Mar 2006 18:28:52 +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 k2J9QpYH009188; Sun, 19 Mar 2006 18:28:06 +0900 Message-Id: <6.0.0.20.2.20060319160737.07f8a080@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 19 Mar 2006 18:24:09 +0900 To: r&d afrac , Mark Davis From: Martin Duerst Subject: Re: [Ltru] ltru-matching draft review In-Reply-To: <6.2.3.4.2.20060319040937.06d49b20@mail.afrac.org> References: <6.2.3.4.2.20060316221118.04dc73a0@pop.online.fr> <6.0.0.20.2.20060317181153.07f8bec0@localhost> <441AFFF1.1050101@icu-project.org> <6.2.3.4.2.20060319040937.06d49b20@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 12:16 06/03/19, r&d afrac wrote: >At 04:34 18/03/2006, Mark Davis wrote: > >>>As a co-chair, I have to work under the assumption that the WG >>>thinks that the security considerations of RFC 3066bis are >>>adequate. I do not see any reason why to reopen this issue that >>>we have discussed when we actually worked on RFC 3066bis. >>I agree. >> >>Mark > >Then, I will appeal this. Sorry, but there's no need to appeal WG/chair/IESG decisions for RFC 3066bis (the registry draft) anymore. To some extent you have already done so, for the rest, the appeals period is over. Also, there is no need to appeal any decisions re. the matching draft, because these haven't yet been made. The only thing I was trying to say above is that if you think that the security section of the matching draft needs to be changed, then propose how to do it and explain why you think it is needed. But leave RFC 3066bis out of the discussion; the WG has finished its work on that document and is now concentrating on the matching draft. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 19 04:54:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKucM-0003mM-Oa; Sun, 19 Mar 2006 04:54:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FKucM-0003mH-4B for ltru@ietf.org; Sun, 19 Mar 2006 04:54:34 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FKucL-0003lI-Hz for ltru@ietf.org; Sun, 19 Mar 2006 04:54:34 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k2J9sQu18486; Sun, 19 Mar 2006 18:54:26 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 6060_59c4efe4_b72e_11da_94f9_0014221fa3c9; Sun, 19 Mar 2006 18:54:25 +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 k2J9rOmW009449; Sun, 19 Mar 2006 18:53:49 +0900 Message-Id: <6.0.0.20.2.20060319183847.09eefd80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 19 Mar 2006 18:53:07 +0900 To: r&d afrac , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] ltru-matching draft review In-Reply-To: <6.2.3.4.2.20060317111538.0712e540@mail.afrac.org> References: <6.2.3.4.2.20060316221118.04dc73a0@pop.online.fr> <6.0.0.20.2.20060317181153.07f8bec0@localhost> <6.2.3.4.2.20060317111538.0712e540@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [chair hat on] At 19:20 06/03/17, r&d afrac wrote: >At 10:14 17/03/2006, Martin Duerst wrote: >>At 06:36 06/03/17, r&d afrac wrote: >> >4. security considerations are as inappropriate as the security considerations of RFC 3066 Bis. >> >>As a co-chair, I have to work under the assumption that the WG >>thinks that the security considerations of RFC 3066bis are >>adequate. I do not see any reason why to reopen this issue that >>we have discussed when we actually worked on RFC 3066bis. >> >>Regards, Martin. > >There are two distinct issues. > >- the lack of warning about the RFC 3066 Bis pattern, which is an RFC 3066 Bis issue and will be documented as dangerous in a document we will publish. The risk there is against privacy.. For this issue, as far as it relates to RFC 3066bis, it is out of discussion. As for "will be documented", issues should make proposals, not try to guess the future. So I currently don't know what this issue is about, and therefore am not able to add it to the issues list. >- the lack of warning about the added risks by this document which explains how langtags are filtered and which will be used in other standards. The added risks comes from the generalisation of this method. The risk is now mass profiling. Assuming that "this document" means the matching draft, I have added this issue to the issues list, as issue number 8. If possible, please provide actual language that addesses this issue, so that the WG has a better base for discussion. I have noted issue 6 as 'split up'. Currently, issue 8 is the only successor (result of the split) to issue 6, but this current state does not preclude adding other issues as sucessors to issue 6, if and when they are stated in a way that I as a chair am confident enough I know what the issue is about. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 19 12:39:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL1s0-0006ey-HK; Sun, 19 Mar 2006 12:39:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL1s0-0006et-45 for ltru@lists.ietf.org; Sun, 19 Mar 2006 12:39:12 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL1ry-0002qi-NS for ltru@lists.ietf.org; Sun, 19 Mar 2006 12:39:12 -0500 Received: from duringpersonlx (snvvpn-10-72-66-c21.corp.yahoo.com [10.72.66.21]) by mrout2.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k2JHcek7004424 for ; Sun, 19 Mar 2006 09:38:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index; b=Dk0CjC3K2faIxRtHcj/xrNrw+15v9yn56lmAEWTUH6qj3L6tBY1fVlkqZMlmcOhU From: "Addison Phillips" To: Date: Sun, 19 Mar 2006 09:40:30 -0800 Message-ID: <001201c64b7c$37cabfe0$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZLfDdTeTkIeVPwRySjTlj1dj8Zbw== X-Spam-Score: -14.9 (--------------) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [Ltru] responses to JFC's issues... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I note some new issues in the issues list at = http://133.2.210.1/2006/IETF/ltru/. Here are my reactions: Issue #3: while "filtering" does describe some aspects of what the = matching draft does, it does so no better than the word "matching" and = it doesn't cover what the document is about as clearly. -1 Issue #4: Figure 3 shows remove-from-right truncation. While Section 4.3 = suggests that users can use private use subtags however they want, both = 3066bis and this document make quite clear that matching schemes do not = consider the semantics of the subtags. Users are strongly cautioned not = to create private use subtags that depend on relationships in the = sequence of subtags as a result. See Section 4.1. -1 Issue #5: The qualitative observations are impossible to address. = Personally, I think the text of section 4.1 is quite clear and = relatively clean. This section consists of guidelines for users choosing = language tags and ranges. As such, these are (I guess) semi-constraints, = but they are appropriate IMO. -1 Issues #6, #8: I believe that the security considerations section = already documents what JFC is asking for. It quite clearly states that = language priority lists might be used to track user requests and user's = activities. I don't see what additional warning needs to be made about = "mass profiling" (what applies to individuals applies to groups of = individuals). I must admit that I don't follow any of this argument and, = lacking a concrete proposal, can't really address it. I mean, if I = understand this at all, JFC is suggesting that identifying languages or = language preferences should be banned as a violation of privacy? -1 Issue #7: I addressed Section 4.1 already (issue 5). Section 3.3 = (Lookup) is just over three pages long. It is more involved than the = sections on filtering, but then the algorithm is more involved. I'm = tempted to reject it out of hand, but if there were a concrete proposal = on how better to organize the text or modifications to the text, I'd = consider those. For now: -1 Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 19 13:09:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL2LM-00029m-Bo; Sun, 19 Mar 2006 13:09:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL2LL-00029h-3G for ltru@lists.ietf.org; Sun, 19 Mar 2006 13:09:31 -0500 Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL2LJ-0003hX-Px for ltru@lists.ietf.org; Sun, 19 Mar 2006 13:09:31 -0500 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=JFCM.afrac.org) by montage.altserver.com with esmtpa (Exim 4.52) id 1FL2LH-00037J-BU; Sun, 19 Mar 2006 10:09:29 -0800 Message-Id: <6.2.3.4.2.20060319185253.076fceb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sun, 19 Mar 2006 19:09:16 +0100 To: "Addison Phillips" , From: r&d afrac Subject: Re: [Ltru] responses to JFC's issues... In-Reply-To: <001201c64b7c$37cabfe0$660a0a0a@ds.corp.yahoo.com> References: <001201c64b7c$37cabfe0$660a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-789F320C 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 - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear Addison, you do what you want with your proposition. My concern is only interoperability. My next steps will be as for RFC 3066 bis : an appeal to the IESG. IESG has shown they do not want a leadership in networked languages area. But they will have to decide is they care or not about interoperability. If they do not care, as for RFC 3066 bis, we will proceed as for RFC 3066 Bis : we will document the risks of using your proposition you do not document (and document that we tried to make you correct them); and we will try to maintain interoperability from our side. Even if our approach is inclusive, there may always be conflicts when a system has not be designed to avoid them. jfc At 18:40 19/03/2006, Addison Phillips wrote: >I note some new issues in the issues list at >http://133.2.210.1/2006/IETF/ltru/. Here are my reactions: > >Issue #3: while "filtering" does describe some aspects of what the >matching draft does, it does so no better than the word "matching" >and it doesn't cover what the document is about as clearly. > >-1 > >Issue #4: Figure 3 shows remove-from-right truncation. While Section >4.3 suggests that users can use private use subtags however they >want, both 3066bis and this document make quite clear that matching >schemes do not consider the semantics of the subtags. Users are >strongly cautioned not to create private use subtags that depend on >relationships in the sequence of subtags as a result. See Section 4.1. > >-1 > >Issue #5: The qualitative observations are impossible to address. >Personally, I think the text of section 4.1 is quite clear and >relatively clean. This section consists of guidelines for users >choosing language tags and ranges. As such, these are (I guess) >semi-constraints, but they are appropriate IMO. > >-1 > >Issues #6, #8: I believe that the security considerations section >already documents what JFC is asking for. It quite clearly states >that language priority lists might be used to track user requests >and user's activities. I don't see what additional warning needs to >be made about "mass profiling" (what applies to individuals applies >to groups of individuals). I must admit that I don't follow any of >this argument and, lacking a concrete proposal, can't really address >it. I mean, if I understand this at all, JFC is suggesting that >identifying languages or language preferences should be banned as a >violation of privacy? > >-1 > >Issue #7: I addressed Section 4.1 already (issue 5). Section 3.3 >(Lookup) is just over three pages long. It is more involved than the >sections on filtering, but then the algorithm is more involved. I'm >tempted to reject it out of hand, but if there were a concrete >proposal on how better to organize the text or modifications to the >text, I'd consider those. For now: > >-1 > >Addison > >Addison Phillips >Internationalization Architect - Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 19 13:38:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL2nb-00053R-JO; Sun, 19 Mar 2006 13:38:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL2na-00052W-Mq for ltru@ietf.org; Sun, 19 Mar 2006 13:38:42 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL2nZ-0004xv-DK for ltru@ietf.org; Sun, 19 Mar 2006 13:38:42 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id C311A26C13E for ; Sun, 19 Mar 2006 19:38:40 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id D364626C14E for ; Sun, 19 Mar 2006 19:38:39 +0100 (CET) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id BB90658ED21 for ; Sun, 19 Mar 2006 19:38:39 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id A278916AAFB; Sun, 19 Mar 2006 19:38:39 +0100 (CET) Date: Sun, 19 Mar 2006 19:38:39 +0100 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20060319183839.GA28477@nic.fr> References: <6.2.3.4.2.20060316221118.04dc73a0@pop.online.fr> <6.0.0.20.2.20060317181153.07f8bec0@localhost> <441AFFF1.1050101@icu-project.org> <6.2.3.4.2.20060319040937.06d49b20@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.3.4.2.20060319040937.06d49b20@mail.afrac.org> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ltru] Re: ltru-matching draft review X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sun, Mar 19, 2006 at 04:16:57AM +0100, r&d afrac wrote a message of 22 lines which said: > An US disregard for privacy laws may suit the Internationalised US > Internet. It does not the Multilingual Internet, I think the IETF > propositions should be kept interoperable with. If not, we will need > to document non-US users that before warning them, as we will, we > tried our best to protect them. Just for the record, I want to emphasize that the
troll
known as "r&d afrac" does *not* represent the Internet users outside of the US. There are real privacy issues on the Internet but it is certainly not a "us vs. then" issue (the european governments agreed to transfer the airplane passenger data to the US, including the meal choices which allow, unlike the language, to infer the religion.) The whole issue is a
non sequitur
. The language in 3066bis is perfect ("Language tags used in content negotiation, like any other information exchanged on the Internet, might be a source of concern because they might be used to infer the nationality of the sender, and thus identify potential targets for surveillance.") and I don't think the IETF could say more. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 19 13:41:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL2q0-0000BX-V1; Sun, 19 Mar 2006 13:41:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL2pz-0000Aa-M3 for ltru@lists.ietf.org; Sun, 19 Mar 2006 13:41:11 -0500 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL2pz-0004zd-Dr for ltru@lists.ietf.org; Sun, 19 Mar 2006 13:41:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 0F13426C14E for ; Sun, 19 Mar 2006 19:41:11 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 2BD1626C13E for ; Sun, 19 Mar 2006 19:41:10 +0100 (CET) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 13EFA58ED21 for ; Sun, 19 Mar 2006 19:41:10 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id EC08016AAFB; Sun, 19 Mar 2006 19:41:09 +0100 (CET) Date: Sun, 19 Mar 2006 19:41:09 +0100 From: Stephane Bortzmeyer To: ltru@lists.ietf.org Message-ID: <20060319184109.GB28477@nic.fr> References: <001201c64b7c$37cabfe0$660a0a0a@ds.corp.yahoo.com> <6.2.3.4.2.20060319185253.076fceb0@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.3.4.2.20060319185253.076fceb0@mail.afrac.org> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] Re: responses to JFC's issues... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Sun, Mar 19, 2006 at 07:09:16PM +0100, r&d afrac wrote a message of 89 lines which said: > we will document the risks of using your proposition you do not > document (and document that we tried to make you correct them); and > we will try to maintain interoperability from our side. Since "our" is just an isolated troll in his home, I believe we can safely ignore it completely. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 19 21:26:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLA6S-0005Xv-VY; Sun, 19 Mar 2006 21:26:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLA6S-0005Rl-2F for ltru@lists.ietf.org; Sun, 19 Mar 2006 21:26:40 -0500 Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLA6P-0005PQ-UC for ltru@lists.ietf.org; Sun, 19 Mar 2006 21:26:39 -0500 Received: from h-68-165-7-197.snvacaid.dynamic.covad.net ([68.165.7.197] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FLA6M-0003nZ-00 for ltru@lists.ietf.org; Sun, 19 Mar 2006 21:26:35 -0500 Message-ID: <00c701c64bc6$1975dbc0$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <001201c64b7c$37cabfe0$660a0a0a@ds.corp.yahoo.com><6.2.3.4.2.20060319185253.076fceb0@mail.afrac.org> <20060319184109.GB28477@nic.fr> Date: Sun, 19 Mar 2006 18:29:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Mailing list behaviour X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Stephane Bortzmeyer" > To: > Sent: Sunday, March 19, 2006 10:41 AM > Subject: [Ltru] Re: responses to JFC's issues... ... > Since "our" is just an isolated troll in his home, I believe we can > safely ignore it completely. ... Everyone: Please limit your comments here to the technical work of this working group, and avoid personal attacks and insults, no matter how tempting the target might seem. This world has enough problems as it is. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 19 21:44:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLANw-0007p5-25; Sun, 19 Mar 2006 21:44:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLANu-0007oq-Q7 for ltru@lists.ietf.org; Sun, 19 Mar 2006 21:44:42 -0500 Received: from relay01.pair.com ([209.68.5.15]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLANt-0005bt-6k for ltru@lists.ietf.org; Sun, 19 Mar 2006 21:44:42 -0500 Received: (qmail 33170 invoked from network); 20 Mar 2006 02:44:40 -0000 Received: from unknown (HELO ?192.168.1.102?) (unknown) by unknown with SMTP; 20 Mar 2006 02:44:40 -0000 X-pair-Authenticated: 24.23.194.196 Message-ID: <441E1704.7060007@icu-project.org> Date: Sun, 19 Mar 2006 18:44:20 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] responses to JFC's issues... References: <001201c64b7c$37cabfe0$660a0a0a@ds.corp.yahoo.com> In-Reply-To: <001201c64b7c$37cabfe0$660a0a0a@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I agree: -1 for all of the supposed issues. Mark Addison Phillips wrote: > I note some new issues in the issues list at http://133.2.210.1/2006/IETF/ltru/. Here are my reactions: > > Issue #3: while "filtering" does describe some aspects of what the matching draft does, it does so no better than the word "matching" and it doesn't cover what the document is about as clearly. > > -1 > > Issue #4: Figure 3 shows remove-from-right truncation. While Section 4.3 suggests that users can use private use subtags however they want, both 3066bis and this document make quite clear that matching schemes do not consider the semantics of the subtags. Users are strongly cautioned not to create private use subtags that depend on relationships in the sequence of subtags as a result. See Section 4.1. > > -1 > > Issue #5: The qualitative observations are impossible to address. Personally, I think the text of section 4.1 is quite clear and relatively clean. This section consists of guidelines for users choosing language tags and ranges. As such, these are (I guess) semi-constraints, but they are appropriate IMO. > > -1 > > Issues #6, #8: I believe that the security considerations section already documents what JFC is asking for. It quite clearly states that language priority lists might be used to track user requests and user's activities. I don't see what additional warning needs to be made about "mass profiling" (what applies to individuals applies to groups of individuals). I must admit that I don't follow any of this argument and, lacking a concrete proposal, can't really address it. I mean, if I understand this at all, JFC is suggesting that identifying languages or language preferences should be banned as a violation of privacy? > > -1 > > Issue #7: I addressed Section 4.1 already (issue 5). Section 3.3 (Lookup) is just over three pages long. It is more involved than the sections on filtering, but then the algorithm is more involved. I'm tempted to reject it out of hand, but if there were a concrete proposal on how better to organize the text or modifications to the text, I'd consider those. For now: > > -1 > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 19 21:49:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLASw-0002ns-FT; Sun, 19 Mar 2006 21:49:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLASv-0002lo-6w; Sun, 19 Mar 2006 21:49:53 -0500 Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLASu-0005fZ-Ju; Sun, 19 Mar 2006 21:49:52 -0500 Received: from h-68-165-7-197.snvacaid.dynamic.covad.net ([68.165.7.197] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FLASt-00002G-00; Sun, 19 Mar 2006 21:49:51 -0500 Message-ID: <00d201c64bc9$59b9db20$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Sun, 19 Mar 2006 18:52:35 -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.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: iesg@ietf.org Subject: [Ltru] Fw: IESG evaluation of RFC 3683 PR-Action for 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: , Errors-To: ltru-bounces@ietf.org Hi - Pursuant to the recent announcement from the IESG regarding the PR-Action, and section 2 of RFC 3683, I shall suspend JFC (Jefsey) Morfin's posting privileges on the ltru WG mailing list. He will, of course, still be able to receive postings from the working group mailing list. Unless I am instructed otherwise by the IESG, March 19, 2007 will be the date for restoration of his posting privileges. Randy, as ltru WG mailing list administrator > From: "IESG Secretary" > To: > Cc: ; > Sent: Saturday, March 18, 2006 9:17 PM > Subject: IESG evaluation of RFC 3683 PR-Action for JFC (Jefsey) Morfin > > The IESG has evaluated a request for an RFC 3683 PR-Action for JFC (Jefsey) > Morfin. Please see the following URL for the corresponding Last Call message > and associated information: > > http://www1.ietf.org/mail-archive/web/ietf/current/msg40011.html > > There was extensive discussion on the IETF list, and the IESG received > additional feedback directly. After a careful evaluation of the feedback, mail > archives, IESG minutes, and RFC 3683, the IESG has concluded that there is > sufficient evidence that Mr. Morfin has engaged in behavior that is not > acceptable on IETF mailing lists. > > Therefore, the IESG has decided to approve the request for an RFC 3683 > PR-Action for JFC (Jefsey) Morfin. The administrators of the LTRU working group > and ietf-languages mailing lists are authorized to suspend his posting > privileges under the terms described in Section 2 of RFC 3683. The > administrators of other IETF mailing lists may suspend his posting privileges > under the same terms at their discretion. > > The IESG. > > _______________________________________________ > 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 Sun Mar 19 23:01:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLBZq-0003oG-UR; Sun, 19 Mar 2006 23:01:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLBZp-0003o8-Nc for ltru@lists.ietf.org; Sun, 19 Mar 2006 23:01:05 -0500 Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLBZp-0007pK-9f for ltru@lists.ietf.org; Sun, 19 Mar 2006 23:01:05 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged)) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2K40x8j014054; Sun, 19 Mar 2006 20:01:01 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sun, 19 Mar 2006 20:01:00 -0800 Message-ID: From: "McDonald, Ira" To: "'Mark Davis'" , Addison Phillips Subject: RE: [Ltru] responses to JFC's issues... Date: Sun, 19 Mar 2006 20:00:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi, I agree as well --> -1 for all the listed issues. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: Sunday, March 19, 2006 9:44 PM > To: Addison Phillips > Cc: ltru@lists.ietf.org > Subject: Re: [Ltru] responses to JFC's issues... > > > I agree: -1 for all of the supposed issues. > > Mark > > Addison Phillips wrote: > > I note some new issues in the issues list at > http://133.2.210.1/2006/IETF/ltru/. Here are my reactions: > > > > Issue #3: while "filtering" does describe some aspects of > what the matching draft does, it does so no better than the > word "matching" and it doesn't cover what the document is > about as clearly. > > > > -1 > > > > Issue #4: Figure 3 shows remove-from-right truncation. > While Section 4.3 suggests that users can use private use > subtags however they want, both 3066bis and this document > make quite clear that matching schemes do not consider the > semantics of the subtags. Users are strongly cautioned not to > create private use subtags that depend on relationships in > the sequence of subtags as a result. See Section 4.1. > > > > -1 > > > > Issue #5: The qualitative observations are impossible to > address. Personally, I think the text of section 4.1 is quite > clear and relatively clean. This section consists of > guidelines for users choosing language tags and ranges. As > such, these are (I guess) semi-constraints, but they are > appropriate IMO. > > > > -1 > > > > Issues #6, #8: I believe that the security considerations > section already documents what JFC is asking for. It quite > clearly states that language priority lists might be used to > track user requests and user's activities. I don't see what > additional warning needs to be made about "mass profiling" > (what applies to individuals applies to groups of > individuals). I must admit that I don't follow any of this > argument and, lacking a concrete proposal, can't really > address it. I mean, if I understand this at all, JFC is > suggesting that identifying languages or language preferences > should be banned as a violation of privacy? > > > > -1 > > > > Issue #7: I addressed Section 4.1 already (issue 5). > Section 3.3 (Lookup) is just over three pages long. It is > more involved than the sections on filtering, but then the > algorithm is more involved. I'm tempted to reject it out of > hand, but if there were a concrete proposal on how better to > organize the text or modifications to the text, I'd consider > those. For now: > > > > -1 > > > > Addison > > > > Addison Phillips > > Internationalization Architect - Yahoo! Inc. > > > > Internationalization is an architecture. > > It is not a feature. > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.2.5/284 - Release > Date: 3/17/2006 > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 3/17/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 20 12:49:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOVG-0003Fr-Ms; Mon, 20 Mar 2006 12:49:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOVF-0003DY-Sk for ltru@ietf.org; Mon, 20 Mar 2006 12:49:13 -0500 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLOVE-0003fu-Jh for ltru@ietf.org; Mon, 20 Mar 2006 12:49:13 -0500 Received: (qmail 88196 invoked from network); 20 Mar 2006 17:49:12 -0000 Received: from unknown (HELO ?172.24.101.50?) (unknown) by unknown with SMTP; 20 Mar 2006 17:49:12 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <441EEB19.2@icu-project.org> Date: Mon, 20 Mar 2006 09:49:13 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ietf-languages@iana.org References: <006801c64c42$d71f40e0$040aa8c0@DGBP7M81> In-Reply-To: <006801c64c42$d71f40e0$040aa8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: iana@iana.org, ltru@ietf.org Subject: [Ltru] Process Enhancement X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I suggest that we discuss with iana an enhancement of the process used for registration. I believe that this is consonant with the current rules, although it could be formalized in the 3066ter revision eventually. Problem. Once a code appears in the registry, we are committed to it. However, there are various points of possible failure; either the reviewer or the iana staff could make a mistake in transcription. Proposal. To help prevent that, I suggest the following: 1. All changes to the language subtag registry are first made in a trial version of the registry, located at http://www.iana.org/assignments/language-subtag-registry-beta. 2. Any time this beta file is changed, a notice is sent out to the ietf-languages@iana.org list. This starts a 1 week review period for of those changes. 3. At the end of the period, if nobody on the list raises an objection, the reviewer notifies iana to release the beta: the contents are copied to http://www.iana.org/assignments/language-subtag-registry. 4. If an objection is raised, then an additional week will be allowed for discussion. At the end of that period, the reviewer will either request iana that 4a. the release is to proceed or 4b. the beta file is to be modified, which returns to Step 2. (these are numbered for reference). Mark _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 20 12:57:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOct-00062V-Sx; Mon, 20 Mar 2006 12:57:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOcs-00062Q-Vj for ltru@ietf.org; Mon, 20 Mar 2006 12:57:06 -0500 Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLOcs-0003u4-HU for ltru@ietf.org; Mon, 20 Mar 2006 12:57:06 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged)) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2KHuxaU011408; Mon, 20 Mar 2006 09:56:59 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 20 Mar 2006 09:56:59 -0800 Message-ID: From: "McDonald, Ira" To: "'Mark Davis'" , ietf-languages@iana.org Subject: RE: [Ltru] Process Enhancement Date: Mon, 20 Mar 2006 09:56:59 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: iana@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: Monday, March 20, 2006 12:49 PM > To: ietf-languages@iana.org > Cc: iana@iana.org; ltru@ietf.org > Subject: [Ltru] Process Enhancement > > > I suggest that we discuss with iana an enhancement of the > process used > for registration. I believe that this is consonant with the current > rules, although it could be formalized in the 3066ter > revision eventually. > > Problem. > Once a code appears in the registry, we are committed to it. However, > there are various points of possible failure; either the > reviewer or the > iana staff could make a mistake in transcription. > > Proposal. > To help prevent that, I suggest the following: > > 1. All changes to the language subtag registry are first made > in a trial > version of the registry, located at > http://www.iana.org/assignments/language-subtag-registry-beta. > 2. Any time this beta file is changed, a notice is sent out to the > ietf-languages@iana.org list. This starts a 1 week review > period for of > those changes. > 3. At the end of the period, if nobody on the list raises an > objection, > the reviewer notifies iana to release the beta: the contents > are copied > to http://www.iana.org/assignments/language-subtag-registry. > 4. If an objection is raised, then an additional week will be allowed > for discussion. At the end of that period, the reviewer will either > request iana that > 4a. the release is to proceed or > 4b. the beta file is to be modified, which returns to Step 2. > > (these are numbered for reference). > > Mark -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.2.5/284 - Release Date: 3/17/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 20 17:27:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSqm-0003TZ-16; Mon, 20 Mar 2006 17:27:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLSqk-0003TS-7E for ltru@ietf.org; Mon, 20 Mar 2006 17:27:42 -0500 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLSqi-0006so-FI for ltru@ietf.org; Mon, 20 Mar 2006 17:27:41 -0500 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id k2KMQqXs031025; Mon, 20 Mar 2006 14:26:52 -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=HCgCow3Md+F0Z+TyThAN+AMnyF8Nkq+QMOWnv+hsi/7saomxX2BdFPWas78tEJfw From: "Addison Phillips" To: "'Mark Davis'" , Subject: RE: [Ltru] Process Enhancement Date: Mon, 20 Mar 2006 14:28:43 -0800 Message-ID: <001101c64c6d$a53f8eb0$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <441EEB19.2@icu-project.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZMRq/ztgsOmdjFTLuz9W1fNS3o0AAJU/pQ X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: iana@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org -1 This proposed process strikes me as overkill. IANA has done a good job, = as far as I can tell, historically. I think if we were going to change = things it would be to make their job easier and simpler. This we could = do as follows: 1. Provide the ability to fix clerical errors explicitly in 3066ter. I = note that this is already provided for by allowing for changes to most = fields via repeated registration and record replacement anyway, but = explicitly calling it out would be good. 2. Changing from the LSR providing records to the LSR providing the = updated file (this is much easier for IANA to validate and verify; the = "subtag-registry-beta" mentioned below can be hosted on a mirror site = such as evertype or inter-locale or alvestrand for easy access and = incorporated into the existing review process without having a separate = clock and separate approval to muck about with). 3. Ensuring that we provide IANA and LSR with formatting and validation = tools (I've already offered the LSR such tools privately, since I have a = record-jar processor and tools for creating and validating registration = forms). A "langtag-nits" tool would help ensure prompt registrations. = Right now IANA has to insert the fields and then check the file--a = manual process. The proposed process adds several layers of complexity = to what should be as simple as possible. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006=E5=B9=B43=E6=9C=8820=E6=97=A5 9:49 > To: ietf-languages@iana.org > Cc: iana@iana.org; ltru@ietf.org > Subject: [Ltru] Process Enhancement >=20 > I suggest that we discuss with iana an enhancement of the process used > for registration. I believe that this is consonant with the current > rules, although it could be formalized in the 3066ter revision = eventually. >=20 > Problem. > Once a code appears in the registry, we are committed to it. However, > there are various points of possible failure; either the reviewer or = the > iana staff could make a mistake in transcription. >=20 > Proposal. > To help prevent that, I suggest the following: >=20 > 1. All changes to the language subtag registry are first made in a = trial > version of the registry, located at > http://www.iana.org/assignments/language-subtag-registry-beta. > 2. Any time this beta file is changed, a notice is sent out to the > ietf-languages@iana.org list. This starts a 1 week review period for = of > those changes. > 3. At the end of the period, if nobody on the list raises an = objection, > the reviewer notifies iana to release the beta: the contents are = copied > to http://www.iana.org/assignments/language-subtag-registry. > 4. If an objection is raised, then an additional week will be allowed > for discussion. At the end of that period, the reviewer will either > request iana that > 4a. the release is to proceed or > 4b. the beta file is to be modified, which returns to Step 2. >=20 > (these are numbered for reference). >=20 > Mark >=20 > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 20 17:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLTLv-0003N0-1t; Mon, 20 Mar 2006 17:59:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLTLr-0003IA-KT for ltru@ietf.org; Mon, 20 Mar 2006 17:59:51 -0500 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLTCs-0007Za-JV for ltru@ietf.org; Mon, 20 Mar 2006 17:50:35 -0500 Received: (qmail 1766 invoked from network); 20 Mar 2006 22:50:34 -0000 Received: from unknown (HELO ?172.24.101.50?) (unknown) by unknown with SMTP; 20 Mar 2006 22:50:34 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <441F31B9.2060204@icu-project.org> Date: Mon, 20 Mar 2006 14:50:33 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Process Enhancement References: <001101c64c6d$a53f8eb0$9fcd15ac@ds.corp.yahoo.com> In-Reply-To: <001101c64c6d$a53f8eb0$9fcd15ac@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ietf-languages@iana.org, iana@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think our maintaining the beta file, and then sending the entire file to IANA would solve the main issue, AND probably speed up the registration process on the IANA side, since it is more work to find the place in the file where an entry should go, check that mistakes weren't introduced, etc. So if we did the work of maintaining the beta AND validating, that would both fix the process issues I am worried about and speed things up. So I'm in favor of Addison's revision. Mark Addison Phillips wrote: > -1 > > This proposed process strikes me as overkill. IANA has done a good job, as far as I can tell, historically. I think if we were going to change things it would be to make their job easier and simpler. This we could do as follows: > > 1. Provide the ability to fix clerical errors explicitly in 3066ter. I note that this is already provided for by allowing for changes to most fields via repeated registration and record replacement anyway, but explicitly calling it out would be good. > > 2. Changing from the LSR providing records to the LSR providing the updated file (this is much easier for IANA to validate and verify; the "subtag-registry-beta" mentioned below can be hosted on a mirror site such as evertype or inter-locale or alvestrand for easy access and incorporated into the existing review process without having a separate clock and separate approval to muck about with). > > 3. Ensuring that we provide IANA and LSR with formatting and validation tools (I've already offered the LSR such tools privately, since I have a record-jar processor and tools for creating and validating registration forms). A "langtag-nits" tool would help ensure prompt registrations. Right now IANA has to insert the fields and then check the file--a manual process. The proposed process adds several layers of complexity to what should be as simple as possible. > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > >> -----Original Message----- >> From: Mark Davis [mailto:mark.davis@icu-project.org] >> Sent: 2006年3月20日 9:49 >> To: ietf-languages@iana.org >> Cc: iana@iana.org; ltru@ietf.org >> Subject: [Ltru] Process Enhancement >> >> I suggest that we discuss with iana an enhancement of the process used >> for registration. I believe that this is consonant with the current >> rules, although it could be formalized in the 3066ter revision eventually. >> >> Problem. >> Once a code appears in the registry, we are committed to it. However, >> there are various points of possible failure; either the reviewer or the >> iana staff could make a mistake in transcription. >> >> Proposal. >> To help prevent that, I suggest the following: >> >> 1. All changes to the language subtag registry are first made in a trial >> version of the registry, located at >> http://www.iana.org/assignments/language-subtag-registry-beta. >> 2. Any time this beta file is changed, a notice is sent out to the >> ietf-languages@iana.org list. This starts a 1 week review period for of >> those changes. >> 3. At the end of the period, if nobody on the list raises an objection, >> the reviewer notifies iana to release the beta: the contents are copied >> to http://www.iana.org/assignments/language-subtag-registry. >> 4. If an objection is raised, then an additional week will be allowed >> for discussion. At the end of that period, the reviewer will either >> request iana that >> 4a. the release is to proceed or >> 4b. the beta file is to be modified, which returns to Step 2. >> >> (these are numbered for reference). >> >> Mark >> >> _______________________________________________ >> 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 Mar 20 19:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUk4-00079R-6x; Mon, 20 Mar 2006 19:28:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUk2-000794-VJ for ltru@ietf.org; Mon, 20 Mar 2006 19:28:54 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLUk1-0004FA-Ls for ltru@ietf.org; Mon, 20 Mar 2006 19:28:54 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M0A7GDZ0PS000078@mauve.mrochek.com> for ltru@ietf.org; Mon, 20 Mar 2006 16:28:52 -0800 (PST) To: Mark Davis Message-id: <01M0A8Y2H4CG000078@mauve.mrochek.com> Date: Mon, 20 Mar 2006 16:18:54 -0800 (PST) From: Ned Freed Subject: Re: [Ltru] Process Enhancement In-reply-to: "Your message dated Mon, 20 Mar 2006 14:50:33 -0800" <441F31B9.2060204@icu-project.org> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=UTF-8; format=flowed References: <001101c64c6d$a53f8eb0$9fcd15ac@ds.corp.yahoo.com> <441F31B9.2060204@icu-project.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ietf-languages@iana.org, iana@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > I think our maintaining the beta file, and then sending the entire file > to IANA would solve the main issue, AND probably speed up the > registration process on the IANA side, since it is more work to find the > place in the file where an entry should go, check that mistakes weren't > introduced, etc. So if we did the work of maintaining the beta AND > validating, that would both fix the process issues I am worried about > and speed things up. So I'm in favor of Addison's revision. The charsets registory continues to be a huge mess in no small part because we tried using this approach. I still don't know why it was such a spectacular failure, but that's where it ended up. The running code we have therefore indicates this is not the good idea it appears to be on first inspection. Ned _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 20 19:44:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUz5-0000LO-Rp; Mon, 20 Mar 2006 19:44:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLUz5-0000LJ-0M for ltru@ietf.org; Mon, 20 Mar 2006 19:44:27 -0500 Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLUz2-0004pv-Pc for ltru@ietf.org; Mon, 20 Mar 2006 19:44:26 -0500 Received: from h-64-105-34-62.snvacaid.dynamic.covad.net ([64.105.34.62] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FLUz2-0003hW-00 for ltru@ietf.org; Mon, 20 Mar 2006 19:44:24 -0500 Message-ID: <002301c64c80$fdac7320$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 20 Mar 2006 16:47:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ltru] getting to the issues list X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - If you've had trouble getting to the issues list due to DNS troubles, (for some of us, http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/ isn't working at the moment) here's another address that is working: http://133.2.210.1/2006/IETF/ltru/ Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 21 02:40:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLbTF-0005eL-Dx; Tue, 21 Mar 2006 02:40:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLbTD-0005Rl-J6 for ltru@ietf.org; Tue, 21 Mar 2006 02:39:59 -0500 Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLbT7-0002DF-8J for ltru@ietf.org; Tue, 21 Mar 2006 02:39:59 -0500 Received: from h-68-166-37-185.snvacaid.dynamic.covad.net ([68.166.37.185] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FLbT4-0000Aw-00 for ltru@ietf.org; Tue, 21 Mar 2006 02:39:50 -0500 Message-ID: <051301c64cbb$02158d40$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] Exceptionally Reserved Two-letter ISO 3166 Codes Date: Mon, 20 Mar 2006 23:42:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Misha Wolf" > To: "LTRU Working Group" > Sent: Wednesday, March 08, 2006 10:38 AM > Subject: [Ltru] Exceptionally Reserved Two-letter ISO 3166 Codes > > In another place, Jon Hanna wrote: > > > Exceptionally Reserved Two-letter ISO 3166 Codes aren't used. > > Have we done this? If so, why have we done it? ... Not having a copy of ISO 3166 handy, I respond with another question: is this covered by the text of point four on page twelve of http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt? It states: | 4. Note: The alphanumeric codes in Appendix X of the UN document | MUST NOT be entered into the registry and MUST NOT be used to | form language tags. (At the time this document was created these | values match the ISO 3166 alpha-2 codes.) The "exceptionally reserved codes" were mentioned in discussion in March of 2005, according to a search of my mailbox. Randy, as a technical contributor _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 21 08:00:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLgSu-0005hK-7Y; Tue, 21 Mar 2006 08:00:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLgSs-0005fV-Qn for ltru@ietf.org; Tue, 21 Mar 2006 07:59:58 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLgSr-0006Vx-JC for ltru@ietf.org; Tue, 21 Mar 2006 07:59:58 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FLgSq-0002i2-Dl; Tue, 21 Mar 2006 07:59:56 -0500 Date: Tue, 21 Mar 2006 07:59:56 -0500 To: Randy Presuhn Subject: Re: [Ltru] Exceptionally Reserved Two-letter ISO 3166 Codes Message-ID: <20060321125956.GH11849@ccil.org> References: <051301c64cbb$02158d40$6401a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <051301c64cbb$02158d40$6401a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > > In another place, Jon Hanna wrote: > > > > > Exceptionally Reserved Two-letter ISO 3166 Codes aren't used. > > > > Have we done this? If so, why have we done it? We have done it, and we have done it because they aren't regularly assigned ISO 3166 codes, which are the only kind we support. Exceptionally reserved codes are ones that are used for something else, and ISO 3166 doesn't want to step on them. > Not having a copy of ISO 3166 handy, I respond with another question: > is this covered by the text of point four on page twelve of > http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-14.txt? > It states: > > | 4. Note: The alphanumeric codes in Appendix X of the UN document > | MUST NOT be entered into the registry and MUST NOT be used to > | form language tags. (At the time this document was created these > | values match the ISO 3166 alpha-2 codes.) No, that's another thing altogether: it refers to UN M.42 codes, and clarifies that UN M.42 is not the authoritative source of 2-letter codes. -- MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS John Cowan http://www.ap.org cowan@ccil.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 22 11:58:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6fA-0001MD-NN; Wed, 22 Mar 2006 11:58:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6f9-0001Ly-A1 for ltru@ietf.org; Wed, 22 Mar 2006 11:58:23 -0500 Received: from outmail1.freedom2surf.net ([194.106.33.237] helo=outmail.freedom2surf.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6f7-00088f-TW for ltru@ietf.org; Wed, 22 Mar 2006 11:58:23 -0500 Received: from DEBHOME (i-83-67-121-192.freedom2surf.net [83.67.121.192]) by outmail.freedom2surf.net (8.12.10/8.12.10) with ESMTP id k2MGwG5K025774; Wed, 22 Mar 2006 16:58:17 GMT Message-Id: <200603221658.k2MGwG5K025774@outmail.freedom2surf.net> From: "Debbie Garside" To: , "'LTRU Working Group'" Date: Wed, 22 Mar 2006 16:58:25 -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: AcZN0c4N33s/JBTzQrCKt4i5HmuaDQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [Ltru] Guernsey Jersey and Isle of Man ISO 3166-1 Codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org FYI The following is an extract of the result of voting received on ISO 3166/MA N 518 Draft ISO 3166-1 Newsletter V-11 "JERSEY, GUERNSEY and ISLE OF MAN" It should be noted that this will only become official on the 29th March 2006 when it is published on the ISO web site. -------- Background of the Vote On 2005-12-22 the Secretariat of the ISO 3166/MA circulated draft ISO 3166-1 Newsletter V-11 "Jersey, Guernsey and Isle of Man". The proposal was submitted by the BSI. The vote closed on 2005-01-27. Result of the Vote The vote yielded the following outcome: 0 NO vote, 2 ABSTENTIONS 8 YES votes In accordance with the Guidelines for the Maintenance of ISO 3166 the changes proposed in the draft ISO 3166-1 Newsletter V-11 are accepted by the ISO 3166/MA. The Newsletter will be published on the ISO 3166/MA Web site on 2006-03-29. ---------- Best regards Debbie Garside Managing Director ICT Marketing Ltd Corner House Barn Street Haverfordwest Pembrokeshire SA61 1BW Wales UK Tel 0044 1437 766441 Fax 0044 1437 766173 Web: www.ictmarketing.co.uk _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 22 12:03:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6jy-00058w-8g; Wed, 22 Mar 2006 12:03:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6jx-00057I-Cp for ltru@ietf.org; Wed, 22 Mar 2006 12:03:21 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6jw-0008PW-61 for ltru@ietf.org; Wed, 22 Mar 2006 12:03:21 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FM6jt-0005vZ-9L; Wed, 22 Mar 2006 12:03:17 -0500 Date: Wed, 22 Mar 2006 12:03:17 -0500 To: Debbie Garside Subject: Re: [Ltru] Guernsey Jersey and Isle of Man ISO 3166-1 Codes Message-ID: <20060322170317.GD8688@ccil.org> References: <200603221658.k2MGwG5K025774@outmail.freedom2surf.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603221658.k2MGwG5K025774@outmail.freedom2surf.net> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside scripsit: > The following is an extract of the result of voting received on ISO 3166/MA > N 518 Draft ISO 3166-1 Newsletter V-11 "JERSEY, GUERNSEY and ISLE OF MAN" You don't actually say so, but I suppose that what has happened is that IM, GG, and JE are now going to be ordinary ISO 3166-1 codes. > It should be noted that this will only become official on the 29th March > 2006 when it is published on the ISO web site. Excellent. -- But you, Wormtongue, you have done what you could for your true master. Some reward you have earned at least. Yet Saruman is apt to overlook his bargains. I should advise you to go quickly and remind him, lest he forget your faithful service. --Gandalf John Cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Mar 22 12:06:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6nC-000701-2s; Wed, 22 Mar 2006 12:06:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6nA-0006zj-MF for ltru@ietf.org; Wed, 22 Mar 2006 12:06:40 -0500 Received: from outmail1.freedom2surf.net ([194.106.33.237] helo=outmail.freedom2surf.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6n9-000055-A9 for ltru@ietf.org; Wed, 22 Mar 2006 12:06:40 -0500 Received: from DEBHOME (i-83-67-121-192.freedom2surf.net [83.67.121.192]) by outmail.freedom2surf.net (8.12.10/8.12.10) with ESMTP id k2MH6P5K030593; Wed, 22 Mar 2006 17:06:25 GMT Message-Id: <200603221706.k2MH6P5K030593@outmail.freedom2surf.net> From: "Debbie Garside" To: "'John Cowan'" Subject: RE: [Ltru] Guernsey Jersey and Isle of Man ISO 3166-1 Codes Date: Wed, 22 Mar 2006 17:06:33 -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 In-reply-to: <20060322170317.GD8688@ccil.org> Thread-index: AcZN0oeY2Fe/kzMgQGiFTn7UxnRavQAABa1A X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Yes that's right... happy coding! :-) > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 22 March 2006 17:03 > To: Debbie Garside > Cc: ltru@ietf.org; ietf-languages@iana.org > Subject: Re: [Ltru] Guernsey Jersey and Isle of Man ISO 3166-1 Codes > > Debbie Garside scripsit: > > > The following is an extract of the result of voting received on ISO > 3166/MA > > N 518 Draft ISO 3166-1 Newsletter V-11 "JERSEY, GUERNSEY and ISLE OF > MAN" > > You don't actually say so, but I suppose that what has happened is that > IM, GG, and JE are now going to be ordinary ISO 3166-1 codes. > > > It should be noted that this will only become official on the 29th March > > 2006 when it is published on the ISO web site. > > Excellent. > > -- > But you, Wormtongue, you have done what you could for your true master. > Some > reward you have earned at least. Yet Saruman is apt to overlook his > bargains. > I should advise you to go quickly and remind him, lest he forget your > faithful > service. --Gandalf John Cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 05:06:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMMiS-0005S4-EG; Thu, 23 Mar 2006 05:06:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMMiQ-0005N6-Ll for ltru@lists.ietf.org; Thu, 23 Mar 2006 05:06:50 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMMiP-000203-6P for ltru@lists.ietf.org; Thu, 23 Mar 2006 05:06:50 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FMMi8-0006De-KL for ltru@lists.ietf.org; Thu, 23 Mar 2006 11:06:32 +0100 Received: from pd9fbad8e.dip0.t-ipconnect.de ([217.251.173.142]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Mar 2006 11:06:32 +0100 Received: from nobody by pd9fbad8e.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Mar 2006 11:06:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 23 Mar 2006 11:06:06 +0100 Organization: Lines: 8 Message-ID: <4422730E.2E73@xyzzy.claranet.de> References: <200603221658.k2MGwG5K025774@outmail.freedom2surf.net> 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: pd9fbad8e.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ietf-languages@alvestrand.no Subject: [Ltru] Re: Guernsey Jersey and Isle of Man ISO 3166-1 Codes X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > FYI Thank you, maybe only a minor problem, but I'm glad that you knew how to fix this. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 06:48:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMOIk-0007qu-O5; Thu, 23 Mar 2006 06:48:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMOIj-0007pw-Kr for ltru@lists.ietf.org; Thu, 23 Mar 2006 06:48:25 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMOIi-0006T2-48 for ltru@lists.ietf.org; Thu, 23 Mar 2006 06:48:25 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FMOIX-0001M7-LP for ltru@lists.ietf.org; Thu, 23 Mar 2006 12:48:13 +0100 Received: from pd9fbad8e.dip0.t-ipconnect.de ([217.251.173.142]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Mar 2006 12:48:13 +0100 Received: from nobody by pd9fbad8e.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Mar 2006 12:48:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 23 Mar 2006 12:46:58 +0100 Organization: Lines: 10 Message-ID: <44228AB2.63C@xyzzy.claranet.de> References: <001301c646e8$d2e81560$9fcd15ac@ds.corp.yahoo.com> <200603132246.k2DMkq5K029104@outmail.freedom2surf.net> 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: pd9fbad8e.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [Ltru] less MUSTard? (was: WG last call for draft-ietf-ltru-matching) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > Unsupported extensions or subtags MAY be removed by > applications or protocols during processing but MUST > remain intact when forwarded. The intention is clear, but it sounds like an attempt to enforce common sense. Maybe the application or protocol has reasons to forward only what it understood. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 06:58:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMOS8-0000GS-Pb; Thu, 23 Mar 2006 06:58:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMOS7-0000Ew-E3 for ltru@lists.ietf.org; Thu, 23 Mar 2006 06:58:07 -0500 Received: from postie1.hosting365.ie ([82.195.128.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMOS5-0006vZ-VW for ltru@lists.ietf.org; Thu, 23 Mar 2006 06:58:07 -0500 Received: from [192.168.100.14] (unknown [83.70.80.115]) by postie1.hosting365.ie (Postfix) with ESMTP id DE7F85ABFAFDB for ; Thu, 23 Mar 2006 11:58:04 +0000 (GMT) Message-ID: <44228E1E.5060807@hackcraft.net> Date: Thu, 23 Mar 2006 12:01:34 +0000 From: Jon Hanna User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ltru@lists.ietf.org Subject: Re: [Ltru] less MUSTard? References: <001301c646e8$d2e81560$9fcd15ac@ds.corp.yahoo.com> <200603132246.k2DMkq5K029104@outmail.freedom2surf.net> <44228AB2.63C@xyzzy.claranet.de> In-Reply-To: <44228AB2.63C@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > Debbie Garside wrote: > > >>Unsupported extensions or subtags MAY be removed by >>applications or protocols during processing but MUST >>remain intact when forwarded. > > > The intention is clear, but it sounds like an attempt to > enforce common sense. Maybe the application or protocol > has reasons to forward only what it understood. Bye, Frank That's reasonable if what the application does is considered a transformation, not if it's considered to leave the source data intact, or transformed only in a well-defined manner which doesn't affect this. Is it really "forwarding" if it alters the data in such a manner? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 10:15:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRWu-0004vK-5v; Thu, 23 Mar 2006 10:15:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRWt-0004rz-6Q for ltru@lists.ietf.org; Thu, 23 Mar 2006 10:15:15 -0500 Received: from outmail1.freedom2surf.net ([194.106.33.237] helo=outmail.freedom2surf.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMRWr-00079j-Pf for ltru@lists.ietf.org; Thu, 23 Mar 2006 10:15:15 -0500 Received: from DEBHOME (i-83-67-121-192.freedom2surf.net [83.67.121.192]) by outmail.freedom2surf.net (8.12.10/8.12.10) with ESMTP id k2NFFB5K022260; Thu, 23 Mar 2006 15:15:11 GMT Message-Id: <200603231515.k2NFFB5K022260@outmail.freedom2surf.net> From: "Debbie Garside" To: "'Jon Hanna'" , Subject: RE: [Ltru] less MUSTard? Date: Thu, 23 Mar 2006 15:15:21 -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 In-reply-to: <44228E1E.5060807@hackcraft.net> Thread-index: AcZOcQ4DI4XQpmU6QmGoHMUN3uCshQAG1Lzw X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I think Addison may have deleted the original paragraph entirely...in which case issue resolved. Regards Debbie > -----Original Message----- > From: Jon Hanna [mailto:jon@hackcraft.net] > Sent: 23 March 2006 12:02 > To: ltru@lists.ietf.org > Subject: Re: [Ltru] less MUSTard? > > Frank Ellermann wrote: > > Debbie Garside wrote: > > > > > >>Unsupported extensions or subtags MAY be removed by > >>applications or protocols during processing but MUST > >>remain intact when forwarded. > > > > > > The intention is clear, but it sounds like an attempt to > > enforce common sense. Maybe the application or protocol > > has reasons to forward only what it understood. Bye, Frank > > That's reasonable if what the application does is considered a > transformation, not if it's considered to leave the source data intact, > or transformed only in a well-defined manner which doesn't affect this. > > Is it really "forwarding" if it alters the data in such a manner? > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 11:27:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSfG-000880-DO; Thu, 23 Mar 2006 11:27:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSfF-00087o-7I for ltru@lists.ietf.org; Thu, 23 Mar 2006 11:27:57 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMSfD-00024G-T3 for ltru@lists.ietf.org; Thu, 23 Mar 2006 11:27:57 -0500 Received: from duringpersonlx (snvvpn1-10-72-72-c197.corp.yahoo.com [10.72.72.197]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2NGR18U060692; Thu, 23 Mar 2006 08:27:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=FTODm1Xhm08E/2OMOMACIYS3IC21nBqHvwPLlhlgjihCSiXXNVdWwp3uqWFnxHx1 From: "Addison Phillips" To: "'Frank Ellermann'" , Subject: RE: [Ltru] less MUSTard? (was: WG last call fordraft-ietf-ltru-matching) Date: Thu, 23 Mar 2006 08:28:55 -0800 Message-ID: <000601c64e96$e200c500$660a0a0a@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44228AB2.63C@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZOb7pEtkrHZR70S82k9+t+jFoHwgAHPFbA X-Spam-Score: -15.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: , Errors-To: ltru-bounces@ietf.org Frank Ellermann wrote: > > > Unsupported extensions or subtags MAY be removed by > > applications or protocols during processing but MUST > > remain intact when forwarded. > > The intention is clear, but it sounds like an attempt to > enforce common sense. Maybe the application or protocol > has reasons to forward only what it understood. Bye, Frank > As a reminder, the editor's copy says: -- Applications, specifications, or protocols that choose not to interpret one or more private-use or extension subtags SHOULD NOT remove or modify these extensions in content that they are processing, because this removes information which might be used elsewhere. When a language tag instance is to be used in a specific, known protocol, and is not being passed through to other protocols, language tags MAY be altered to remove subtags and extensions that are not supported by that protocol. -- I'm not much in love with that para. I note, for example, that it is embedded in a section of advice to end users on choosing language ranges and thus is somewhat out of place. Why don't we move this to the end of Section 3.1 (with other general implementation information) and change it to read something like: -- Although an application, specification, or protocol can alter language tags internally (to remove unsupported extensions, for example), other users or processes might derive value from the original tag's information. If an application, specification, or protocol alters a language tag internally, it SHOULD NOT replace the original language tag in the content or protocol. -- Addison _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 12:31:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTeY-0000Kh-Kf; Thu, 23 Mar 2006 12:31:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTeW-0000Jw-Q3 for ltru@lists.ietf.org; Thu, 23 Mar 2006 12:31:16 -0500 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMTeO-00051i-H6 for ltru@lists.ietf.org; Thu, 23 Mar 2006 12:31:09 -0500 Received: (qmail 45909 invoked from network); 23 Mar 2006 17:31:08 -0000 Received: from unknown (HELO ?172.24.101.50?) (unknown) by unknown with SMTP; 23 Mar 2006 17:31:08 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <4422DB57.5070300@icu-project.org> Date: Thu, 23 Mar 2006 09:31:03 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] less MUSTard? (was: WG last call fordraft-ietf-ltru-matching) References: <000601c64e96$e200c500$660a0a0a@ds.corp.yahoo.com> In-Reply-To: <000601c64e96$e200c500$660a0a0a@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: 'Frank Ellermann' , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I like that a bit better, but there is still a problem in the last statement. Suppose that I have a process that is designed to return the language subtag. I have a protocol that pipes through it, because I want to extract that tag. The last sentence says I shouldn't do this, when I have a perfectly good reason for doing so. It is hard to express what we want without being tautological, but here is an attempt: An application, specification, or protocol can alter language tags internally. For example, it may remove unsupported extensions, or suppress other subtags that may be irrelevant to the particular processing involved, or replace subtags in transient processing such as matching. However, such alteration does remove information from the language tag that may be important to other users or processes, and SHOULD NOT be done where the original information content is expected to remain unaltered. Mark Addison Phillips wrote: > Frank Ellermann wrote: > >>> Unsupported extensions or subtags MAY be removed by >>> applications or protocols during processing but MUST >>> remain intact when forwarded. >>> >> The intention is clear, but it sounds like an attempt to >> enforce common sense. Maybe the application or protocol >> has reasons to forward only what it understood. Bye, Frank >> >> > As a reminder, the editor's copy says: > > -- > Applications, specifications, or protocols that choose not to interpret one > or more private-use or extension subtags SHOULD NOT remove or modify these > extensions in content that they are processing, because this removes > information which might be used elsewhere. When a language tag instance is > to be used in a specific, known protocol, and is not being passed through to > other protocols, language tags MAY be altered to remove subtags and > extensions that are not supported by that protocol. > -- > > I'm not much in love with that para. I note, for example, that it is > embedded in a section of advice to end users on choosing language ranges and > thus is somewhat out of place. Why don't we move this to the end of Section > 3.1 (with other general implementation information) and change it to read > something like: > > -- > Although an application, specification, or protocol can alter language tags > internally (to remove unsupported extensions, for example), other users or > processes might derive value from the original tag's information. If an > application, specification, or protocol alters a language tag internally, it > SHOULD NOT replace the original language tag in the content or protocol. > -- > > Addison > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 12:32:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTfg-0001Wz-DU; Thu, 23 Mar 2006 12:32:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTff-0001Wk-B4 for ltru@lists.ietf.org; Thu, 23 Mar 2006 12:32:27 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMTfd-0005Ac-0D for ltru@lists.ietf.org; Thu, 23 Mar 2006 12:32:27 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FMTfW-00078t-GD; Thu, 23 Mar 2006 12:32:18 -0500 Date: Thu, 23 Mar 2006 12:32:18 -0500 To: Mark Davis Subject: Re: [Ltru] less MUSTard? (was: WG last call fordraft-ietf-ltru-matching) Message-ID: <20060323173218.GG24362@ccil.org> References: <000601c64e96$e200c500$660a0a0a@ds.corp.yahoo.com> <4422DB57.5070300@icu-project.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4422DB57.5070300@icu-project.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'Frank Ellermann' , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > An application, specification, or protocol can alter language tags > internally. For example, it may remove unsupported extensions, or suppress > other subtags that may be irrelevant to the particular processing involved, > or replace subtags in transient processing such as matching. However, such > alteration does remove information from the language tag that may be > important to other users or processes, and SHOULD NOT be done where the > original information content is expected to remain unaltered. +1 -- John Cowan http://www.ccil.org/~cowan http://www.ap.org Charles li reis, nostre emperesdre magnes, Set anz totz pleinz ad ested in Espagnes. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 12:38:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTlD-0006RZ-KC; Thu, 23 Mar 2006 12:38:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMTlD-0006RU-0t for ltru@lists.ietf.org; Thu, 23 Mar 2006 12:38:11 -0500 Received: from outmail1.freedom2surf.net ([194.106.33.237] helo=outmail.freedom2surf.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMTlB-0005L5-J0 for ltru@lists.ietf.org; Thu, 23 Mar 2006 12:38:11 -0500 Received: from DEBHOME (i-83-67-121-192.freedom2surf.net [83.67.121.192]) by outmail.freedom2surf.net (8.12.10/8.12.10) with ESMTP id k2NHc55K004060; Thu, 23 Mar 2006 17:38:05 GMT Message-Id: <200603231738.k2NHc55K004060@outmail.freedom2surf.net> From: "Debbie Garside" To: "'Mark Davis'" , "'Addison Phillips'" Subject: RE: [Ltru] less MUSTard? (was: WG lastcall fordraft-ietf-ltru-matching) Date: Thu, 23 Mar 2006 17:38:15 -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 In-reply-to: <4422DB57.5070300@icu-project.org> Thread-index: AcZOn5+JEuOoCo4gQ9CuAt8T6dm18AAALWkw X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: 'Frank Ellermann' , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I would change this: > An application, specification, or protocol can alter language tags > internally. To this: > An application, specification, or protocol can alter language tags > during internal processing procedures. Debbie > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 23 March 2006 17:31 > To: Addison Phillips > Cc: 'Frank Ellermann'; ltru@lists.ietf.org > Subject: Re: [Ltru] less MUSTard? (was: WG lastcall fordraft-ietf-ltru- > matching) > > I like that a bit better, but there is still a problem in the last > statement. Suppose that I have a process that is designed to return the > language subtag. I have a protocol that pipes through it, because I want > to extract that tag. The last sentence says I shouldn't do this, when I > have a perfectly good reason for doing so. It is hard to express what we > want without being tautological, but here is an attempt: > > An application, specification, or protocol can alter language tags > internally. For example, it may remove unsupported extensions, or suppress > other subtags that may be irrelevant to the particular processing > involved, or replace subtags in transient processing such as matching. > However, such alteration does remove information from the language tag > that may be important to other users or processes, and SHOULD NOT be done > where the original information content is expected to remain unaltered. > > Mark > > > Addison Phillips wrote: > > Frank Ellermann wrote: > > > >>> Unsupported extensions or subtags MAY be removed by > >>> applications or protocols during processing but MUST > >>> remain intact when forwarded. > >>> > >> The intention is clear, but it sounds like an attempt to > >> enforce common sense. Maybe the application or protocol > >> has reasons to forward only what it understood. Bye, Frank > >> > >> > > As a reminder, the editor's copy says: > > > > -- > > Applications, specifications, or protocols that choose not to interpret > one > > or more private-use or extension subtags SHOULD NOT remove or modify > these > > extensions in content that they are processing, because this removes > > information which might be used elsewhere. When a language tag instance > is > > to be used in a specific, known protocol, and is not being passed > through to > > other protocols, language tags MAY be altered to remove subtags and > > extensions that are not supported by that protocol. > > -- > > > > I'm not much in love with that para. I note, for example, that it is > > embedded in a section of advice to end users on choosing language ranges > and > > thus is somewhat out of place. Why don't we move this to the end of > Section > > 3.1 (with other general implementation information) and change it to > read > > something like: > > > > -- > > Although an application, specification, or protocol can alter language > tags > > internally (to remove unsupported extensions, for example), other users > or > > processes might derive value from the original tag's information. If an > > application, specification, or protocol alters a language tag > internally, it > > SHOULD NOT replace the original language tag in the content or protocol. > > -- > > > > Addison > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 13:39:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMUis-0005SK-BZ; Thu, 23 Mar 2006 13:39:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMUir-0005S1-SP for ltru@lists.ietf.org; Thu, 23 Mar 2006 13:39:49 -0500 Received: from mrout2-b.corp.dcn.yahoo.com ([216.109.112.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMUir-0007WO-KF for ltru@lists.ietf.org; Thu, 23 Mar 2006 13:39:49 -0500 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2NIdM2d001918; Thu, 23 Mar 2006 10:39:22 -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:x-mimeole:in-reply-to:thread-index; b=qaOdslpsbm81bK01TM4QKwcelZCRAlCydedV7qrIo/5zVUSgB7ntNKLk2vFTcXwJ From: "Addison Phillips" To: "'Mark Davis'" Subject: RE: [Ltru] less MUSTard? (was: WG last call fordraft-ietf-ltru-matching) Date: Thu, 23 Mar 2006 10:41:16 -0800 Message-ID: <000901c64ea9$5eb46cc0$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-reply-to: <4422DB57.5070300@icu-project.org> Thread-index: AcZOn5osVW8balJUT02/HXeLi4vXPAACcDYw X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 'Frank Ellermann' , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006=E5=B9=B43=E6=9C=8823=E6=97=A5 9:31 > To: Addison Phillips > Cc: 'Frank Ellermann'; ltru@lists.ietf.org > Subject: Re: [Ltru] less MUSTard? (was: WG last call = fordraft-ietf-ltru- > matching) >=20 > I like that a bit better, but there is still a problem in the last > statement. Suppose that I have a process that is designed to return = the > language subtag. I have a protocol that pipes through it, because I = want > to extract that tag. The last sentence says I shouldn't do this, when = I > have a perfectly good reason for doing so. It is hard to express what = we > want without being tautological, but here is an attempt: >=20 > An application, specification, or protocol can alter language tags > internally. For example, it may remove unsupported extensions, or = suppress > other subtags that may be irrelevant to the particular processing = involved, > or replace subtags in transient processing such as matching. However, = such > alteration does remove information from the language tag that may be > important to other users or processes, and SHOULD NOT be done where = the > original information content is expected to remain unaltered. >=20 > Mark >=20 >=20 > Addison Phillips wrote: > > Frank Ellermann wrote: > > > >>> Unsupported extensions or subtags MAY be removed by > >>> applications or protocols during processing but MUST > >>> remain intact when forwarded. > >>> > >> The intention is clear, but it sounds like an attempt to > >> enforce common sense. Maybe the application or protocol > >> has reasons to forward only what it understood. Bye, Frank > >> > >> > > As a reminder, the editor's copy says: > > > > -- > > Applications, specifications, or protocols that choose not to = interpret > one > > or more private-use or extension subtags SHOULD NOT remove or modify > these > > extensions in content that they are processing, because this removes > > information which might be used elsewhere. When a language tag = instance > is > > to be used in a specific, known protocol, and is not being passed > through to > > other protocols, language tags MAY be altered to remove subtags and > > extensions that are not supported by that protocol. > > -- > > > > I'm not much in love with that para. I note, for example, that it is > > embedded in a section of advice to end users on choosing language = ranges > and > > thus is somewhat out of place. Why don't we move this to the end of > Section > > 3.1 (with other general implementation information) and change it to > read > > something like: > > > > -- > > Although an application, specification, or protocol can alter = language > tags > > internally (to remove unsupported extensions, for example), other = users > or > > processes might derive value from the original tag's information. If = an > > application, specification, or protocol alters a language tag = internally, > it > > SHOULD NOT replace the original language tag in the content or = protocol. > > -- > > > > Addison > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 14:41:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVgS-0005XT-Ky; Thu, 23 Mar 2006 14:41:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVgR-0005Uj-K2 for ltru@lists.ietf.org; Thu, 23 Mar 2006 14:41:23 -0500 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMVgR-0001l8-A1 for ltru@lists.ietf.org; Thu, 23 Mar 2006 14:41:23 -0500 Received: (qmail 456 invoked from network); 23 Mar 2006 19:41:22 -0000 Received: from unknown (HELO ?172.24.101.50?) (unknown) by unknown with SMTP; 23 Mar 2006 19:41:22 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <4422F9CE.4020104@icu-project.org> Date: Thu, 23 Mar 2006 11:41:02 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Debbie Garside Subject: Re: [Ltru] less MUSTard? (was: WG lastcall fordraft-ietf-ltru-matching) References: <200603231738.k2NHc55K004060@outmail.freedom2surf.net> In-Reply-To: <200603231738.k2NHc55K004060@outmail.freedom2surf.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: 'Frank Ellermann' , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org "processing procedures" doesn't make sense to me. Can you explain why "internal processing" doesn't work? Mark Debbie Garside wrote: > I would change this: > > >> An application, specification, or protocol can alter language tags >> internally. >> > > To this: > > >> An application, specification, or protocol can alter language tags >> during internal processing procedures. >> > > Debbie > > >> -----Original Message----- >> From: Mark Davis [mailto:mark.davis@icu-project.org] >> Sent: 23 March 2006 17:31 >> To: Addison Phillips >> Cc: 'Frank Ellermann'; ltru@lists.ietf.org >> Subject: Re: [Ltru] less MUSTard? (was: WG lastcall fordraft-ietf-ltru- >> matching) >> >> I like that a bit better, but there is still a problem in the last >> statement. Suppose that I have a process that is designed to return the >> language subtag. I have a protocol that pipes through it, because I want >> to extract that tag. The last sentence says I shouldn't do this, when I >> have a perfectly good reason for doing so. It is hard to express what we >> want without being tautological, but here is an attempt: >> >> An application, specification, or protocol can alter language tags >> internally. For example, it may remove unsupported extensions, or suppress >> other subtags that may be irrelevant to the particular processing >> involved, or replace subtags in transient processing such as matching. >> However, such alteration does remove information from the language tag >> that may be important to other users or processes, and SHOULD NOT be done >> where the original information content is expected to remain unaltered. >> >> Mark >> >> >> Addison Phillips wrote: >> >>> Frank Ellermann wrote: >>> >>> >>>>> Unsupported extensions or subtags MAY be removed by >>>>> applications or protocols during processing but MUST >>>>> remain intact when forwarded. >>>>> >>>>> >>>> The intention is clear, but it sounds like an attempt to >>>> enforce common sense. Maybe the application or protocol >>>> has reasons to forward only what it understood. Bye, Frank >>>> >>>> >>>> >>> As a reminder, the editor's copy says: >>> >>> -- >>> Applications, specifications, or protocols that choose not to interpret >>> >> one >> >>> or more private-use or extension subtags SHOULD NOT remove or modify >>> >> these >> >>> extensions in content that they are processing, because this removes >>> information which might be used elsewhere. When a language tag instance >>> >> is >> >>> to be used in a specific, known protocol, and is not being passed >>> >> through to >> >>> other protocols, language tags MAY be altered to remove subtags and >>> extensions that are not supported by that protocol. >>> -- >>> >>> I'm not much in love with that para. I note, for example, that it is >>> embedded in a section of advice to end users on choosing language ranges >>> >> and >> >>> thus is somewhat out of place. Why don't we move this to the end of >>> >> Section >> >>> 3.1 (with other general implementation information) and change it to >>> >> read >> >>> something like: >>> >>> -- >>> Although an application, specification, or protocol can alter language >>> >> tags >> >>> internally (to remove unsupported extensions, for example), other users >>> >> or >> >>> processes might derive value from the original tag's information. If an >>> application, specification, or protocol alters a language tag >>> >> internally, it >> >>> SHOULD NOT replace the original language tag in the content or protocol. >>> -- >>> >>> Addison >>> >>> >>> _______________________________________________ >>> Ltru mailing list >>> Ltru@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ltru >>> >>> >>> >>> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru >> > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 14:48:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVmx-0002Vf-RE; Thu, 23 Mar 2006 14:48:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMVmw-0002Va-DL for ltru@lists.ietf.org; Thu, 23 Mar 2006 14:48:06 -0500 Received: from mrout2-b.corp.dcn.yahoo.com ([216.109.112.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMVmu-00024e-2U for ltru@lists.ietf.org; Thu, 23 Mar 2006 14:48:06 -0500 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2NJlplU010162; Thu, 23 Mar 2006 11:47:52 -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:x-mimeole:in-reply-to:thread-index; b=N4ol7EApgd0IpX/vTPYrfPwd36UK5vuTorCxS/KQkxgxdWpVOj65jE3XCHDd4Rya From: "Addison Phillips" To: "'Mark Davis'" , "'Debbie Garside'" Subject: RE: [Ltru] less MUSTard? (was: WG lastcall fordraft-ietf-ltru-matching) Date: Thu, 23 Mar 2006 11:49:45 -0800 Message-ID: <000a01c64eb2$f07ac240$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-reply-to: <4422F9CE.4020104@icu-project.org> Thread-index: AcZOsdEL+eaiqMLiRzKbMosq27cLCQAAMoUA X-Spam-Score: -15.0 (---------------) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: 'Frank Ellermann' , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Actually, the phrase is redundant. The sentence can read: "An application, specification, or protocol can alter language tags." Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 2006=E5=B9=B43=E6=9C=8823=E6=97=A5 11:41 > To: Debbie Garside > Cc: 'Addison Phillips'; 'Frank Ellermann'; ltru@lists.ietf.org > Subject: Re: [Ltru] less MUSTard? (was: WG lastcall = fordraft-ietf-ltru- > matching) >=20 > "processing procedures" doesn't make sense to me. Can you explain why > "internal processing" doesn't work? >=20 > Mark >=20 > Debbie Garside wrote: > > I would change this: > > > > > >> An application, specification, or protocol can alter language tags > >> internally. > >> > > > > To this: > > > > > >> An application, specification, or protocol can alter language tags > >> during internal processing procedures. > >> > > > > Debbie > > > > > >> -----Original Message----- > >> From: Mark Davis [mailto:mark.davis@icu-project.org] > >> Sent: 23 March 2006 17:31 > >> To: Addison Phillips > >> Cc: 'Frank Ellermann'; ltru@lists.ietf.org > >> Subject: Re: [Ltru] less MUSTard? (was: WG lastcall = fordraft-ietf-ltru- > >> matching) > >> > >> I like that a bit better, but there is still a problem in the last > >> statement. Suppose that I have a process that is designed to return = the > >> language subtag. I have a protocol that pipes through it, because I > want > >> to extract that tag. The last sentence says I shouldn't do this, = when I > >> have a perfectly good reason for doing so. It is hard to express = what > we > >> want without being tautological, but here is an attempt: > >> > >> An application, specification, or protocol can alter language tags > >> internally. For example, it may remove unsupported extensions, or > suppress > >> other subtags that may be irrelevant to the particular processing > >> involved, or replace subtags in transient processing such as = matching. > >> However, such alteration does remove information from the language = tag > >> that may be important to other users or processes, and SHOULD NOT = be > done > >> where the original information content is expected to remain = unaltered. > >> > >> Mark > >> > >> > >> Addison Phillips wrote: > >> > >>> Frank Ellermann wrote: > >>> > >>> > >>>>> Unsupported extensions or subtags MAY be removed by > >>>>> applications or protocols during processing but MUST > >>>>> remain intact when forwarded. > >>>>> > >>>>> > >>>> The intention is clear, but it sounds like an attempt to > >>>> enforce common sense. Maybe the application or protocol > >>>> has reasons to forward only what it understood. Bye, Frank > >>>> > >>>> > >>>> > >>> As a reminder, the editor's copy says: > >>> > >>> -- > >>> Applications, specifications, or protocols that choose not to > interpret > >>> > >> one > >> > >>> or more private-use or extension subtags SHOULD NOT remove or = modify > >>> > >> these > >> > >>> extensions in content that they are processing, because this = removes > >>> information which might be used elsewhere. When a language tag > instance > >>> > >> is > >> > >>> to be used in a specific, known protocol, and is not being passed > >>> > >> through to > >> > >>> other protocols, language tags MAY be altered to remove subtags = and > >>> extensions that are not supported by that protocol. > >>> -- > >>> > >>> I'm not much in love with that para. I note, for example, that it = is > >>> embedded in a section of advice to end users on choosing language > ranges > >>> > >> and > >> > >>> thus is somewhat out of place. Why don't we move this to the end = of > >>> > >> Section > >> > >>> 3.1 (with other general implementation information) and change it = to > >>> > >> read > >> > >>> something like: > >>> > >>> -- > >>> Although an application, specification, or protocol can alter = language > >>> > >> tags > >> > >>> internally (to remove unsupported extensions, for example), other > users > >>> > >> or > >> > >>> processes might derive value from the original tag's information. = If > an > >>> application, specification, or protocol alters a language tag > >>> > >> internally, it > >> > >>> SHOULD NOT replace the original language tag in the content or > protocol. > >>> -- > >>> > >>> Addison > >>> > >>> > >>> _______________________________________________ > >>> Ltru mailing list > >>> Ltru@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ltru > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> Ltru mailing list > >> Ltru@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ltru > >> > > > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 15:04:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMW2Q-0007tB-L2; Thu, 23 Mar 2006 15:04:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMW2P-0007t2-6o for ltru@lists.ietf.org; Thu, 23 Mar 2006 15:04:05 -0500 Received: from outmail1.freedom2surf.net ([194.106.33.237] helo=outmail.freedom2surf.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMW2O-00039P-NH for ltru@lists.ietf.org; Thu, 23 Mar 2006 15:04:05 -0500 Received: from DEBHOME (i-83-67-121-192.freedom2surf.net [83.67.121.192]) by outmail.freedom2surf.net (8.12.10/8.12.10) with ESMTP id k2NK405K018950; Thu, 23 Mar 2006 20:04:00 GMT Message-Id: <200603232004.k2NK405K018950@outmail.freedom2surf.net> From: "Debbie Garside" To: "'Addison Phillips'" , "'Mark Davis'" Subject: RE: [Ltru] less MUSTard? (was: WG lastcall fordraft-ietf-ltru-matching) Date: Thu, 23 Mar 2006 20:04:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <000a01c64eb2$f07ac240$9fcd15ac@ds.corp.yahoo.com> Thread-index: AcZOsdEL+eaiqMLiRzKbMosq27cLCQAAMoUAAACNZSA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: 'Frank Ellermann' , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 23 March 2006 19:50 > To: 'Mark Davis'; 'Debbie Garside' > Cc: 'Frank Ellermann'; ltru@lists.ietf.org > Subject: RE: [Ltru] less MUSTard? (was: WG lastcall = fordraft-ietf-ltru- > matching) >=20 > Actually, the phrase is redundant. The sentence can read: >=20 > "An application, specification, or protocol can alter language tags." >=20 > Addison >=20 > Addison Phillips > Internationalization Architect - Yahoo! Inc. >=20 > Internationalization is an architecture. > It is not a feature. >=20 > > -----Original Message----- > > From: Mark Davis [mailto:mark.davis@icu-project.org] > > Sent: 2006=E5=B9=B43=E6=9C=8823=E6=97=A5 11:41 > > To: Debbie Garside > > Cc: 'Addison Phillips'; 'Frank Ellermann'; ltru@lists.ietf.org > > Subject: Re: [Ltru] less MUSTard? (was: WG lastcall = fordraft-ietf-ltru- > > matching) > > > > "processing procedures" doesn't make sense to me. Can you explain = why > > "internal processing" doesn't work? > > > > Mark > > > > Debbie Garside wrote: > > > I would change this: > > > > > > > > >> An application, specification, or protocol can alter language = tags > > >> internally. > > >> > > > > > > To this: > > > > > > > > >> An application, specification, or protocol can alter language = tags > > >> during internal processing procedures. > > >> > > > > > > Debbie > > > > > > > > >> -----Original Message----- > > >> From: Mark Davis [mailto:mark.davis@icu-project.org] > > >> Sent: 23 March 2006 17:31 > > >> To: Addison Phillips > > >> Cc: 'Frank Ellermann'; ltru@lists.ietf.org > > >> Subject: Re: [Ltru] less MUSTard? (was: WG lastcall = fordraft-ietf- > ltru- > > >> matching) > > >> > > >> I like that a bit better, but there is still a problem in the = last > > >> statement. Suppose that I have a process that is designed to = return > the > > >> language subtag. I have a protocol that pipes through it, because = I > > want > > >> to extract that tag. The last sentence says I shouldn't do this, = when > I > > >> have a perfectly good reason for doing so. It is hard to express = what > > we > > >> want without being tautological, but here is an attempt: > > >> > > >> An application, specification, or protocol can alter language = tags > > >> internally. For example, it may remove unsupported extensions, or > > suppress > > >> other subtags that may be irrelevant to the particular processing > > >> involved, or replace subtags in transient processing such as > matching. > > >> However, such alteration does remove information from the = language > tag > > >> that may be important to other users or processes, and SHOULD NOT = be > > done > > >> where the original information content is expected to remain > unaltered. > > >> > > >> Mark > > >> > > >> > > >> Addison Phillips wrote: > > >> > > >>> Frank Ellermann wrote: > > >>> > > >>> > > >>>>> Unsupported extensions or subtags MAY be removed by > > >>>>> applications or protocols during processing but MUST > > >>>>> remain intact when forwarded. > > >>>>> > > >>>>> > > >>>> The intention is clear, but it sounds like an attempt to > > >>>> enforce common sense. Maybe the application or protocol > > >>>> has reasons to forward only what it understood. Bye, Frank > > >>>> > > >>>> > > >>>> > > >>> As a reminder, the editor's copy says: > > >>> > > >>> -- > > >>> Applications, specifications, or protocols that choose not to > > interpret > > >>> > > >> one > > >> > > >>> or more private-use or extension subtags SHOULD NOT remove or = modify > > >>> > > >> these > > >> > > >>> extensions in content that they are processing, because this = removes > > >>> information which might be used elsewhere. When a language tag > > instance > > >>> > > >> is > > >> > > >>> to be used in a specific, known protocol, and is not being = passed > > >>> > > >> through to > > >> > > >>> other protocols, language tags MAY be altered to remove subtags = and > > >>> extensions that are not supported by that protocol. > > >>> -- > > >>> > > >>> I'm not much in love with that para. I note, for example, that = it is > > >>> embedded in a section of advice to end users on choosing = language > > ranges > > >>> > > >> and > > >> > > >>> thus is somewhat out of place. Why don't we move this to the end = of > > >>> > > >> Section > > >> > > >>> 3.1 (with other general implementation information) and change = it to > > >>> > > >> read > > >> > > >>> something like: > > >>> > > >>> -- > > >>> Although an application, specification, or protocol can alter > language > > >>> > > >> tags > > >> > > >>> internally (to remove unsupported extensions, for example), = other > > users > > >>> > > >> or > > >> > > >>> processes might derive value from the original tag's = information. If > > an > > >>> application, specification, or protocol alters a language tag > > >>> > > >> internally, it > > >> > > >>> SHOULD NOT replace the original language tag in the content or > > protocol. > > >>> -- > > >>> > > >>> Addison > > >>> > > >>> > > >>> _______________________________________________ > > >>> Ltru mailing list > > >>> Ltru@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/ltru > > >>> > > >>> > > >>> > > >>> > > >> _______________________________________________ > > >> Ltru mailing list > > >> Ltru@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/ltru > > >> > > > > > > > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 15:04:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMW2Q-0007tZ-Nt; Thu, 23 Mar 2006 15:04:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMW2P-0007t1-6o for ltru@lists.ietf.org; Thu, 23 Mar 2006 15:04:05 -0500 Received: from outmail1.freedom2surf.net ([194.106.33.237] helo=outmail.freedom2surf.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMW2O-00039Q-NH for ltru@lists.ietf.org; Thu, 23 Mar 2006 15:04:05 -0500 Received: from DEBHOME (i-83-67-121-192.freedom2surf.net [83.67.121.192]) by outmail.freedom2surf.net (8.12.10/8.12.10) with ESMTP id k2NK405L018950; Thu, 23 Mar 2006 20:04:01 GMT Message-Id: <200603232004.k2NK405L018950@outmail.freedom2surf.net> From: "Debbie Garside" To: "'Mark Davis'" Subject: RE: [Ltru] less MUSTard? (was: WG lastcall fordraft-ietf-ltru-matching) Date: Thu, 23 Mar 2006 20:04:10 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-reply-to: <4422F9CE.4020104@icu-project.org> Thread-index: AcZOscW4MaZadOlURNSIVgFrvkAeSgAAsipw X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: 'Frank Ellermann' , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I just thought "internally" didn't really make sense... are we talking internal to the language tag or internal processes (applications,protocols) But if you are happy with it... fine by me Debbie > -----Original Message----- > From: Mark Davis [mailto:mark.davis@icu-project.org] > Sent: 23 March 2006 19:41 > To: Debbie Garside > Cc: 'Addison Phillips'; 'Frank Ellermann'; ltru@lists.ietf.org > Subject: Re: [Ltru] less MUSTard? (was: WG lastcall fordraft-ietf-ltru- > matching) > > "processing procedures" doesn't make sense to me. Can you explain why > "internal processing" doesn't work? > > Mark > > Debbie Garside wrote: > > I would change this: > > > > > >> An application, specification, or protocol can alter language tags > >> internally. > >> > > > > To this: > > > > > >> An application, specification, or protocol can alter language tags > >> during internal processing procedures. > >> > > > > Debbie > > > > > >> -----Original Message----- > >> From: Mark Davis [mailto:mark.davis@icu-project.org] > >> Sent: 23 March 2006 17:31 > >> To: Addison Phillips > >> Cc: 'Frank Ellermann'; ltru@lists.ietf.org > >> Subject: Re: [Ltru] less MUSTard? (was: WG lastcall fordraft-ietf-ltru- > >> matching) > >> > >> I like that a bit better, but there is still a problem in the last > >> statement. Suppose that I have a process that is designed to return the > >> language subtag. I have a protocol that pipes through it, because I > want > >> to extract that tag. The last sentence says I shouldn't do this, when I > >> have a perfectly good reason for doing so. It is hard to express what > we > >> want without being tautological, but here is an attempt: > >> > >> An application, specification, or protocol can alter language tags > >> internally. For example, it may remove unsupported extensions, or > suppress > >> other subtags that may be irrelevant to the particular processing > >> involved, or replace subtags in transient processing such as matching. > >> However, such alteration does remove information from the language tag > >> that may be important to other users or processes, and SHOULD NOT be > done > >> where the original information content is expected to remain unaltered. > >> > >> Mark > >> > >> > >> Addison Phillips wrote: > >> > >>> Frank Ellermann wrote: > >>> > >>> > >>>>> Unsupported extensions or subtags MAY be removed by > >>>>> applications or protocols during processing but MUST > >>>>> remain intact when forwarded. > >>>>> > >>>>> > >>>> The intention is clear, but it sounds like an attempt to > >>>> enforce common sense. Maybe the application or protocol > >>>> has reasons to forward only what it understood. Bye, Frank > >>>> > >>>> > >>>> > >>> As a reminder, the editor's copy says: > >>> > >>> -- > >>> Applications, specifications, or protocols that choose not to > interpret > >>> > >> one > >> > >>> or more private-use or extension subtags SHOULD NOT remove or modify > >>> > >> these > >> > >>> extensions in content that they are processing, because this removes > >>> information which might be used elsewhere. When a language tag > instance > >>> > >> is > >> > >>> to be used in a specific, known protocol, and is not being passed > >>> > >> through to > >> > >>> other protocols, language tags MAY be altered to remove subtags and > >>> extensions that are not supported by that protocol. > >>> -- > >>> > >>> I'm not much in love with that para. I note, for example, that it is > >>> embedded in a section of advice to end users on choosing language > ranges > >>> > >> and > >> > >>> thus is somewhat out of place. Why don't we move this to the end of > >>> > >> Section > >> > >>> 3.1 (with other general implementation information) and change it to > >>> > >> read > >> > >>> something like: > >>> > >>> -- > >>> Although an application, specification, or protocol can alter language > >>> > >> tags > >> > >>> internally (to remove unsupported extensions, for example), other > users > >>> > >> or > >> > >>> processes might derive value from the original tag's information. If > an > >>> application, specification, or protocol alters a language tag > >>> > >> internally, it > >> > >>> SHOULD NOT replace the original language tag in the content or > protocol. > >>> -- > >>> > >>> Addison > >>> > >>> > >>> _______________________________________________ > >>> Ltru mailing list > >>> Ltru@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/ltru > >>> > >>> > >>> > >>> > >> _______________________________________________ > >> Ltru mailing list > >> Ltru@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ltru > >> > > > > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 23 20:46:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMbNz-0006Y1-2l; Thu, 23 Mar 2006 20:46:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMbNx-0006Xr-7C for ltru@ietf.org; Thu, 23 Mar 2006 20:46:41 -0500 Received: from mailc.microsoft.com ([205.248.102.79] helo=mail6.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMbNv-0005Xj-Px for ltru@ietf.org; Thu, 23 Mar 2006 20:46:41 -0500 Received: from mailout3.microsoft.com ([157.57.217.10]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 23 Mar 2006 17:46:38 -0800 Received: from mailout6.microsoft.com ([157.54.69.150]) by mailout3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 17:45:45 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.150]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 17:36:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Mar 2006 17:36:08 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language Thread-Index: AcZO41L2sVfpJ2dlQPOcvwFRBpfzbA== From: "Peter Constable" To: , X-OriginalArrivalTime: 24 Mar 2006 01:36:23.0115 (UTC) FILETIME=[5BCA11B0:01C64EE3] X-Spam-Score: 0.2 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: Subject: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1863627867==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============1863627867== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C64EE3.53A29F94" This is a multi-part message in MIME format. ------_=_NextPart_001_01C64EE3.53A29F94 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC 2616 (HTTP 1.1) makes reference to RFC 1766 for use in Accept-Language. Of course, 1766 was obsoleted by 3066; it was also obsoleted by RFC 3282 "Content Language Headers", which discussed both Content-language and Accept-Language. =20 It's not clear to me how versioning is handled in IETF specs: since RFC 1766 is obsoleted by these other docs, is RFC 2616 effectively updated so that every reference to RFC 1766 is now treated as a reference to RFCs 3066 and 3282 (or, rather, 3066bis in the former case)? =20 =20 =20 Thanks. =20 Peter Constable GIFT | GPTS | MICROSOFT =20 ------_=_NextPart_001_01C64EE3.53A29F94 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

RFC 2616 (HTTP 1.1) makes reference to RFC = 1766 for use in Accept-Language. Of course, 1766 was obsoleted by 3066; it was also obsoleted by RFC 3282 = “Content Language Headers”, which discussed both Content-language and Accept-Language.

 

It’s not clear to me how versioning is handled in IETF specs: since RFC 1766 is obsoleted by these other docs, is RFC 2616 effectively updated so that every = reference to RFC 1766 is now treated as a reference to RFCs 3066 and 3282 (or, rather, 3066bis in the former = case)?

 

 

 

Thanks.

 

Peter = Constable

GIFT | GPTS = | MICROSOFT

 

------_=_NextPart_001_01C64EE3.53A29F94-- --===============1863627867== 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 --===============1863627867==-- From ltru-bounces@ietf.org Thu Mar 23 20:49:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMbQp-0008CU-PI; Thu, 23 Mar 2006 20:49:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMbQo-00085V-Lv for ltru@ietf.org; Thu, 23 Mar 2006 20:49:38 -0500 Received: from relay00.pair.com ([209.68.5.9]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMbQn-0005cg-Du for ltru@ietf.org; Thu, 23 Mar 2006 20:49:38 -0500 Received: (qmail 18557 invoked from network); 24 Mar 2006 01:49:37 -0000 Received: from unknown (HELO ?172.24.101.50?) (unknown) by unknown with SMTP; 24 Mar 2006 01:49:37 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <4423500B.7080205@icu-project.org> Date: Thu, 23 Mar 2006 17:48:59 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Debbie Garside Subject: Re: [Ltru] Guernsey Jersey and Isle of Man ISO 3166-1 Codes References: <200603221658.k2MGwG5K025774@outmail.freedom2surf.net> In-Reply-To: <200603221658.k2MGwG5K025774@outmail.freedom2surf.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'LTRU Working Group' , ietf-languages@alvestrand.no X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On http://unstats.un.org/unsd/methods/m49/m49alpha.htm, I see 4 missing codes, not three. 830 Channel Islands 831 Guernsey 833 Isle of Man 832 Jersey That is, they still haven't changed 830 into a regional code. Any word on that? Also, what will the alpha-3 codes for these be? Mark Debbie Garside wrote: > FYI > > The following is an extract of the result of voting received on ISO 3166/MA > N 518 Draft ISO 3166-1 Newsletter V-11 "JERSEY, GUERNSEY and ISLE OF MAN" > > It should be noted that this will only become official on the 29th March > 2006 when it is published on the ISO web site. > > -------- > > Background of the Vote > > On 2005-12-22 the Secretariat of the ISO 3166/MA circulated draft ISO 3166-1 > Newsletter V-11 "Jersey, Guernsey and Isle of Man". The proposal was > submitted by the BSI. The vote closed on 2005-01-27. > > > Result of the Vote > > The vote yielded the following outcome: > > 0 NO vote, > 2 ABSTENTIONS > 8 YES votes > > In accordance with the Guidelines for the Maintenance of ISO 3166 the > changes proposed in the draft ISO 3166-1 Newsletter V-11 are accepted by the > ISO 3166/MA. The Newsletter will be published on the ISO 3166/MA Web site on > 2006-03-29. > > ---------- > > Best regards > > > Debbie Garside > Managing Director > > ICT Marketing Ltd > Corner House > Barn Street > Haverfordwest > Pembrokeshire SA61 1BW > Wales UK > > Tel 0044 1437 766441 > Fax 0044 1437 766173 > > Web: www.ictmarketing.co.uk > > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 24 04:28:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMib7-0005se-0k; Fri, 24 Mar 2006 04:28:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMib5-0005p4-Gt for ltru@ietf.org; Fri, 24 Mar 2006 04:28:43 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMib1-0006pU-Tw for ltru@ietf.org; Fri, 24 Mar 2006 04:28:43 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k2O9SYu25496 for ; Fri, 24 Mar 2006 18:28:34 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 761c_90bd1e48_bb18_11da_953d_0014221f2a2d; Fri, 24 Mar 2006 18:28:33 +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 k2O9RhJa019132 for ; Fri, 24 Mar 2006 18:28:09 +0900 Message-Id: <6.0.0.20.2.20060324182351.07ab3230@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 24 Mar 2006 18:27:16 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ltru] Reminder: Only one week to go for WG Last Call on 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: , Errors-To: ltru-bounces@ietf.org Dear LTRU WG members, This is a reminder that we have only (a little less than) a week to go for the WG Last Call on the matching draft. The exact deadline is Thursday, March 30, 23:00 UTC (Friday, March 31st, 08:00 Japan time, Thursday, March 30, 3pm US Pacific, and so on). If you haven't read the -11 draft yet, please do so, even if you have read a previous draft. If you have read the -11 draft, please report your findings to the list, even if it is just that you haven't found any issues. Many thanks in advance, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 24 10:28:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoDi-0003DU-H4; Fri, 24 Mar 2006 10:28:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMoDh-0003DP-HL for ltru@ietf.org; Fri, 24 Mar 2006 10:28:57 -0500 Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMoDg-0004PD-5A for ltru@ietf.org; Fri, 24 Mar 2006 10:28:57 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged)) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2OFSkA6003061; Fri, 24 Mar 2006 07:28:46 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Mar 2006 07:28:46 -0800 Message-ID: <789E617C880666438EDEE30C2A3E8D10ED87@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'Peter Constable'" , ietf-languages@iana.org, ltru@ietf.org Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language Date: Fri, 24 Mar 2006 07:28:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Peter, You may take this answer about "IETF versioning" with a grain of salt, but... When I complained awhile back to Roy Fielding that RFC 3986 renamed many ABNF productions from RFC 2396 and left others out entirely, Roy told me that it did no harm, because all those pre-existing RFCs that already normatively referenced RFC 2396 still did so (in perpetuity), because the IETF does not follow the ISO, ITU-T, and IEEE style that a newer version of a given standard is automatically the normative reference intended. I thought at the time that this was sophistry - I still do! Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: Peter Constable [mailto:petercon@microsoft.com] Sent: Thursday, March 23, 2006 8:36 PM To: ietf-languages@iana.org; ltru@ietf.org Subject: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language RFC 2616 (HTTP 1.1) makes reference to RFC 1766 for use in Accept-Language. Of course, 1766 was obsoleted by 3066; it was also obsoleted by RFC 3282 "Content Language Headers", which discussed both Content-language and Accept-Language. It's not clear to me how versioning is handled in IETF specs: since RFC 1766 is obsoleted by these other docs, is RFC 2616 effectively updated so that every reference to RFC 1766 is now treated as a reference to RFCs 3066 and 3282 (or, rather, 3066bis in the former case)? Thanks. Peter Constable GIFT | GPTS | MICROSOFT -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.3.1/291 - Release Date: 3/24/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.3.1/291 - Release Date: 3/24/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 24 12:18:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpvu-0007h0-MN; Fri, 24 Mar 2006 12:18:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpvt-0007gv-KB for ltru@ietf.org; Fri, 24 Mar 2006 12:18:41 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMpvr-0002eq-94 for ltru@ietf.org; Fri, 24 Mar 2006 12:18:41 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M0FENUS5R4000078@mauve.mrochek.com> for ltru@ietf.org; Fri, 24 Mar 2006 09:18:36 -0800 (PST) To: Mark Crispin Message-id: <01M0FF301UVI000078@mauve.mrochek.com> Date: Fri, 24 Mar 2006 09:18:10 -0800 (PST) From: Ned Freed Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language In-reply-to: "Your message dated Fri, 24 Mar 2006 09:11:58 -0800 (PST)" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <789E617C880666438EDEE30C2A3E8D10ED87@mailsrvnt05.enet.sharplabs.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > As a long-time IETFer: > Typically, these matters are handled on an ad-hoc case-by-case basis in > which common sense prevails. > The razor in this case is "does something break?" Most updates to IETF > documents expand upon, or clarify, what was in the older document; they do > not introduce an incompatibility. If something is removed, that is > generally because there is community concensus that it is bad juju. > So, given RFC abcd that normatively references RFC efgh that has been > obsoleted by RFC ijkl: > . can two RFC abcd implementations communicate with each other, and the > desired behavior happen, even though one uses RFC efgh and the other > uses RFC ijkl? > If the answer is yes, then the question is effectively academic in nature. > Sometime in the future, RFC abcd will have to be updated to reflect the > change to RFC ijkl, but as it doesn't break interoperability it isn't > urgent. One might expect that old implementations will use RFC efgh and > new implementations will use RFC ijkl. > If the answer is no, then someone was not doing their job; RFC ijkl should > not have been approved without that working group taking on the needed > update to RFC abcd. An important purpose of the IETF/IESG bureaucracy is > to prevent something like this from happening. > Hence the answer that since RFC abcd normatively refers to RFC efgh, it is > RFC efgh that is used by an RFC abcd implementator. It is, however, > expected that people would tend to use RFC ijkl instead (if only because > it has clearer wording and represents more modern understanding) -- and > sooner or later, RFC abcd will be obsoleted by a RFC mnop that makes this > change official. > Equally important is that RFC ijkl should not have been approved for > publication if it creates an incompatibility problem in RFC abcd, without > also updating/obsoleting RFC abcd. Full agreement on all points. Ned _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 24 13:09:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMqiy-0005CB-E6; Fri, 24 Mar 2006 13:09:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMqix-0005C6-Sv for ltru@ietf.org; Fri, 24 Mar 2006 13:09:23 -0500 Received: from mailb.microsoft.com ([205.248.102.77] helo=mail4.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMqiw-0004V1-JB for ltru@ietf.org; Fri, 24 Mar 2006 13:09:23 -0500 Received: from mailout4.microsoft.com ([157.57.217.12]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 24 Mar 2006 10:09:21 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.150]) by mailout4.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 09:57:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTPAccept-Language Date: Fri, 24 Mar 2006 09:56:57 -0800 Message-ID: In-Reply-To: <01M0FF301UVI000078@mauve.mrochek.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTPAccept-Language Thread-Index: AcZPZwP/ijpDk5fDTgKnh1LiXORu8gABFVFw From: "Peter Constable" To: , X-OriginalArrivalTime: 24 Mar 2006 17:57:10.0120 (UTC) FILETIME=[5F566E80:01C64F6C] X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Ned Freed [mailto:ned.freed@mrochek.com] MC> > Typically, these matters are handled on an ad-hoc case-by-case basis in > > which common sense prevails. >=20 > > The razor in this case is "does something break?" =20 ... > > Hence the answer that since RFC abcd normatively refers to RFC efgh, it is > > RFC efgh that is used by an RFC abcd implementator. It is, however, > > expected that people would tend to use RFC ijkl instead (if only because > > it has clearer wording and represents more modern understanding) -- and > > sooner or later, RFC abcd will be obsoleted by a RFC mnop that makes this > > change official. >=20 > > Equally important is that RFC ijkl should not have been approved for > > publication if it creates an incompatibility problem in RFC abcd, without > > also updating/obsoleting RFC abcd. >=20 > Full agreement on all points. This still leaves things somewhat vague wrt the specific question I asked. You're saying that technically RFC 1766 is still the spec for Accept-Language, but it's expected that people will actually use 3066bis -- and as for "sooner or later", RFC 2616 was published in 1999, and RFC 3066 was published in 2001, so we've already had five years go by during which 2616 could have been obsoleted by another doc that normatively referenced 3066 but that hasn't happened. If I needed to give a recommendation to a team that has to deal with Accept-Language, it's really unclear to me which Language-Tag RFC I should point them to. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 24 16:35:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMtwO-00074o-Qk; Fri, 24 Mar 2006 16:35:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMtwN-0006xw-MH for ltru@ietf.org; Fri, 24 Mar 2006 16:35:27 -0500 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMtwN-0004Hw-CA for ltru@ietf.org; Fri, 24 Mar 2006 16:35:27 -0500 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M0FGU4NJ5C000078@mauve.mrochek.com> for ltru@ietf.org; Fri, 24 Mar 2006 13:35:24 -0800 (PST) To: Peter Constable Message-id: <01M0FO2DJJRG000078@mauve.mrochek.com> Date: Fri, 24 Mar 2006 13:33:21 -0800 (PST) From: Ned Freed Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTPAccept-Language In-reply-to: "Your message dated Fri, 24 Mar 2006 09:56:57 -0800" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01M0FF301UVI000078@mauve.mrochek.com> X-Spam-Score: 1.2 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > From: Ned Freed [mailto:ned.freed@mrochek.com] > MC> > Typically, these matters are handled on an ad-hoc case-by-case > basis in > > > which common sense prevails. > > > > > The razor in this case is "does something break?" > ... > > > Hence the answer that since RFC abcd normatively refers to RFC efgh, > it is > > > RFC efgh that is used by an RFC abcd implementator. It is, however, > > > expected that people would tend to use RFC ijkl instead (if only > because > > > it has clearer wording and represents more modern understanding) -- > and > > > sooner or later, RFC abcd will be obsoleted by a RFC mnop that makes > this > > > change official. > > > > > Equally important is that RFC ijkl should not have been approved for > > > publication if it creates an incompatibility problem in RFC abcd, > without > > > also updating/obsoleting RFC abcd. > > > > Full agreement on all points. > This still leaves things somewhat vague wrt the specific question I > asked. Indeed it does. > You're saying that technically RFC 1766 is still the spec for > Accept-Language, Well, actually I was simply agreeing with something Mark said. > but it's expected that people will actually use 3066bis > -- and as for "sooner or later", RFC 2616 was published in 1999, and RFC > 3066 was published in 2001, so we've already had five years go by during > which 2616 could have been obsoleted by another doc that normatively > referenced 3066 but that hasn't happened. Yes, more or less. > If I needed to give a recommendation to a team that has to deal with > Accept-Language, it's really unclear to me which Language-Tag RFC I > should point them to. My recommendation would be to refer them to the one that makes the most sense for them to use. Sorry it doesn't get more precise than that, but that's the eay it is. Ned _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 24 17:30:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMunK-0004jT-II; Fri, 24 Mar 2006 17:30:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMunJ-0004a1-3c for ltru@ietf.org; Fri, 24 Mar 2006 17:30:09 -0500 Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMunI-0006fk-O1 for ltru@ietf.org; Fri, 24 Mar 2006 17:30:09 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged)) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2OMTtqJ007620; Fri, 24 Mar 2006 14:29:55 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Mar 2006 14:29:56 -0800 Message-ID: <789E617C880666438EDEE30C2A3E8D10ED8B@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'Mark Crispin'" Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language Date: Fri, 24 Mar 2006 14:29:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Crispin wrote: > > As a long-time IETFer: > > Typically, these matters are handled on an ad-hoc > case-by-case basis in > which common sense prevails. > > The razor in this case is "does something break?" > > > <...snip...> > > Equally important is that RFC ijkl should not have been approved for > publication if it creates an incompatibility problem in RFC > abcd, without > also updating/obsoleting RFC abcd. > Precisely my point about RFC 2396 (Generic URI Syntax) and its successor RFC 3986. Dozens of IETF and other standards specs were broken by RFC 3986 doing away with some ABNF productions and renaming others. And Roy Fielding wasn't terribly polite about squashing my complaint. And the IESG blithely approved this core spec with this glaring deficiency. Peter - I think you're on your own - and note that RFC 1766 doesn't exactly gracefully prepare programmers for 'script' subtags in the second position followed by 'region' subtags in the third position - quoting from page 2 of RFC 1766: The syntax of this tag in RFC-822 EBNF is: Language-Tag = Primary-tag *( "-" Subtag ) Primary-tag = 1*8ALPHA Subtag = 1*8ALPHA <...snip...> In the first subtag: - All 2-letter codes are interpreted as ISO 3166 alpha-2 country codes denoting the area in which the language is used. - Codes of 3 to 8 letters may be registered with the IANA by anyone who feels a need for it, according to the rules in chapter 5 of this document. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.3.1/291 - Release Date: 3/24/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 24 17:46:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMv3X-000716-6i; Fri, 24 Mar 2006 17:46:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMv3W-0006yI-4q for ltru@ietf.org; Fri, 24 Mar 2006 17:46:54 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMv3U-0006yQ-Sm for ltru@ietf.org; Fri, 24 Mar 2006 17:46:54 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FMv3S-000175-0R; Fri, 24 Mar 2006 17:46:50 -0500 Date: Fri, 24 Mar 2006 17:46:49 -0500 To: "McDonald, Ira" Subject: Re: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language Message-ID: <20060324224649.GG30394@ccil.org> References: <789E617C880666438EDEE30C2A3E8D10ED8B@mailsrvnt05.enet.sharplabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <789E617C880666438EDEE30C2A3E8D10ED8B@mailsrvnt05.enet.sharplabs.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ietf-languages@iana.org, 'Mark Crispin' , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org McDonald, Ira scripsit: > Precisely my point about RFC 2396 (Generic URI Syntax) and its > successor RFC 3986. Dozens of IETF and other standards specs > were broken by RFC 3986 doing away with some ABNF productions > and renaming others. And Roy Fielding wasn't terribly polite > about squashing my complaint. And the IESG blithely approved > this core spec with this glaring deficiency. How did section D.2 of RFC 3986 fail to satisfy you? > Peter - I think you're on your own - and note that RFC 1766 > doesn't exactly gracefully prepare programmers for 'script' > subtags in the second position followed by 'region' subtags > in the third position - quoting from page 2 of RFC 1766: It prepares programmers for tags like zh-yue-taishan-us-ny-nyc, or should if they read it. > The syntax of this tag in RFC-822 EBNF is: > > Language-Tag = Primary-tag *( "-" Subtag ) > Primary-tag = 1*8ALPHA > Subtag = 1*8ALPHA > > <...snip...> Which is to say, there may be any number of subtags. > In the first subtag: > > - All 2-letter codes are interpreted as ISO 3166 alpha-2 > country codes denoting the area in which the language is > used. > > - Codes of 3 to 8 letters may be registered with the IANA by > anyone who feels a need for it, according to the rules in > chapter 5 of this document. This does not say that country codes MUST NOT appear elsewhere, only that when a 2-letter code appears in the first (nowadays the second) subtag, it MUST be a country code. -- I don't know half of you half as well John Cowan as I should like, and I like less than half cowan@ccil.org of you half as well as you deserve. http://www.ccil.org/~cowan --Bilbo http://www.ap.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 24 18:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMvGf-00089j-OO; Fri, 24 Mar 2006 18:00:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMvGf-00089G-Fq for ltru@ietf.org; Fri, 24 Mar 2006 18:00:29 -0500 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMvGe-0007N0-5K for ltru@ietf.org; Fri, 24 Mar 2006 18:00:29 -0500 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2OMxMdx058421; Fri, 24 Mar 2006 14:59:22 -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:x-mimeole:in-reply-to:thread-index; b=dcAjT5KAUvdp1M/Tsfml9J0Umhdg8coJ6QfSAD8cPac4JL33hazrb/1WyrxiWNfX From: "Addison Phillips" To: "'John Cowan'" , "'McDonald, Ira'" Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTPAccept-Language Date: Fri, 24 Mar 2006 15:01:06 -0800 Message-ID: <002401c64f96$d56fa3f0$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: <20060324224649.GG30394@ccil.org> Thread-Index: AcZPlOmgbsKqdl3KSC2vG0mHroQp0AAAbrSA X-Spam-Score: -13.9 (-------------) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ietf-languages@iana.org, 'Mark Crispin' , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > > > - Codes of 3 to 8 letters may be registered with the IANA by > > anyone who feels a need for it, according to the rules in > > chapter 5 of this document. > > This does not say that country codes MUST NOT appear elsewhere, only > that when a 2-letter code appears in the first (nowadays the second) > subtag, it MUST be a country code. ... which is still true. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 24 18:30:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMvk8-0000Lz-Cd; Fri, 24 Mar 2006 18:30:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMvk7-0000Lu-OG for ltru@ietf.org; Fri, 24 Mar 2006 18:30:55 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMvk6-0008Tu-6n for ltru@ietf.org; Fri, 24 Mar 2006 18:30:55 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0106C25975B; Sat, 25 Mar 2006 00:29: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 30517-10; Sat, 25 Mar 2006 00:29:00 +0100 (CET) Received: from [192.168.2.202] (unknown [63.172.63.149]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9A73F25975A; Sat, 25 Mar 2006 00:28:57 +0100 (CET) Message-ID: <44248121.3030307@alvestrand.no> Date: Fri, 24 Mar 2006 17:30:41 -0600 From: Harald Alvestrand User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "McDonald, Ira" Subject: Re: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language References: <789E617C880666438EDEE30C2A3E8D10ED8B@mailsrvnt05.enet.sharplabs.com> In-Reply-To: <789E617C880666438EDEE30C2A3E8D10ED8B@mailsrvnt05.enet.sharplabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 1.8 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ietf-languages@iana.org, 'Mark Crispin' , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org McDonald, Ira wrote: > Mark Crispin wrote: > >> As a long-time IETFer: >> >> Typically, these matters are handled on an ad-hoc >> case-by-case basis in >> which common sense prevails. >> >> The razor in this case is "does something break?" >> >> >> <...snip...> >> >> Equally important is that RFC ijkl should not have been approved for >> publication if it creates an incompatibility problem in RFC >> abcd, without >> also updating/obsoleting RFC abcd. >> >> > > Precisely my point about RFC 2396 (Generic URI Syntax) and its > successor RFC 3986. Dozens of IETF and other standards specs > were broken by RFC 3986 doing away with some ABNF productions > and renaming others. And Roy Fielding wasn't terribly polite > about squashing my complaint. And the IESG blithely approved > this core spec with this glaring deficiency. > > Peter - I think you're on your own - and note that RFC 1766 > doesn't exactly gracefully prepare programmers for 'script' > subtags in the second position followed by 'region' subtags > in the third position - quoting from page 2 of RFC 1766: > > The syntax of this tag in RFC-822 EBNF is: > > Language-Tag = Primary-tag *( "-" Subtag ) > Primary-tag = 1*8ALPHA > Subtag = 1*8ALPHA > > <...snip...> > > In the first subtag: > > - All 2-letter codes are interpreted as ISO 3166 alpha-2 > country codes denoting the area in which the language is > used. > > - Codes of 3 to 8 letters may be registered with the IANA by > anyone who feels a need for it, according to the rules in > chapter 5 of this document. > > > Cheers, As author, I must beg to disagree..... a sensible interpretation of the above is "if you want a meaning for something that doesn't have 2 letters in the first subtag, look at the registry to figure out what it means". A person who looks at the registry will find (once he discovers the right registry) a registry full of script subtags. The only person who's affected by 1766->3066bis is the person who wants to register something with 4 letters in the first subtag. He can't, because that's reserved for scripts - and will be told so immediately when he tries to follow the 1766 registration procedure. What's not to like? Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 24 19:40:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMwpY-0006kV-11; Fri, 24 Mar 2006 19:40:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMwpX-0006kQ-1D for ltru@ietf.org; Fri, 24 Mar 2006 19:40:35 -0500 Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMwpV-00038v-Kp for ltru@ietf.org; Fri, 24 Mar 2006 19:40:34 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged)) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2P0eFs0009471; Fri, 24 Mar 2006 16:40:15 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Mar 2006 16:40:16 -0800 Message-ID: <789E617C880666438EDEE30C2A3E8D10ED8E@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'John Cowan'" Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language Date: Fri, 24 Mar 2006 16:40:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ietf-languages@iana.org, 'Mark Crispin' , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > > McDonald, Ira scripsit: > > > Precisely my point about RFC 2396 (Generic URI Syntax) and its > > successor RFC 3986. Dozens of IETF and other standards specs > > were broken by RFC 3986 doing away with some ABNF productions > > and renaming others. And Roy Fielding wasn't terribly polite > > about squashing my complaint. And the IESG blithely approved > > this core spec with this glaring deficiency. > > How did section D.2 of RFC 3986 fail to satisfy you? > Sorry - I wasn't aware that section D.2 was added - Roy never saw fit to point it out in response to my questions. Although, presumably (being an Appendix), section D.2 (which maps from 'obsolete' RFC2396 BNF rules to RFC 3986 BNF rules) is merely Informative and so this still makes me queazy. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.3.1/291 - Release Date: 3/24/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 24 21:02:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMy6s-0006HF-0N; Fri, 24 Mar 2006 21:02:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMy6q-0006HA-Vp for ltru@ietf.org; Fri, 24 Mar 2006 21:02:32 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMy6p-0005zM-KH for ltru@ietf.org; Fri, 24 Mar 2006 21:02:32 -0500 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 24 Mar 2006 18:02:30 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.150]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 18:02:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language Date: Fri, 24 Mar 2006 18:02:01 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language Thread-Index: AcZPlOrDDmWWanNYTyOAobt/Bf2OHQAFn25w From: "Peter Constable" To: , X-OriginalArrivalTime: 25 Mar 2006 02:02:30.0546 (UTC) FILETIME=[2C76CF20:01C64FB0] 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: , Errors-To: ltru-bounces@ietf.org > From: mrc@pangtzu.panda.com [mailto:mrc@pangtzu.panda.com] On Behalf Of Mark > Crispin > > Peter - I think you're on your own - and note that RFC 1766 > > doesn't exactly gracefully prepare programmers for 'script' > > subtags in the second position followed by 'region' subtags > > in the third position >=20 > Sounds like a good argument to abolish script subtags, and to tell the > people who want script identity that they are screwed, now and forever, > and will just have to live with it because someone may be excessively > pedantic about RFC 1766. One more time... If anyone is to be excessively pedantic about RFC 1766, then *far, far* more is allowed in a 1766 tag than is allowed under 3066bis -- under 1766, there is *very little* that can be assumed about the internal structure of tags. That doesn't in any way suggest abolishing subtags; it just means that if all you know is RFC 1766 then you don't know very much. RFC 1766 allowed tags like az-Cyrl-AZ; it just didn't call that out as a specific scenario. I guess I've figured out the answer to my own question: if you only care about 1766, you can test for a few possible cases and must fail gracefully for a very large set of other cases. But if it's of any interest to you, then you can anticipate that an Accept-Language header can contain any of the tags permitted by 3066bis and you can parse them assuming that 3066bis is applying rather than the wild-west-anything-goes rules of 1766. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 24 21:22:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMyPk-0005HF-Uu; Fri, 24 Mar 2006 21:22:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMyPi-0005Dr-H1 for ltru@ietf.org; Fri, 24 Mar 2006 21:22:02 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMyPh-0006v2-8X for ltru@ietf.org; Fri, 24 Mar 2006 21:22:02 -0500 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 24 Mar 2006 18:22:00 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.150]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Mar 2006 18:21:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language Date: Fri, 24 Mar 2006 18:21:36 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language Thread-Index: AcZPsLy0eJE4uaC9QMO78sef4H5uPgAAPzoA From: "Peter Constable" To: , X-OriginalArrivalTime: 25 Mar 2006 02:21:59.0896 (UTC) FILETIME=[E5737580:01C64FB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: mrc@pangtzu.panda.com [mailto:mrc@pangtzu.panda.com] On Behalf Of Mark > Crispin > Peter, I think that you and I are loudly agreeing. The point is that > 3066bis, which creates specifics, doesn't break 1766 software which did > not (could not) know about such specifics. >=20 > Therefore there is no problem. Yes. I had a generic question about versioning for IETF specs, for which I got a somewhat vague answer; but I was also concerned about a specific instance of versioning, and for that I figured out an appropriate answer. I've got someone asking me about Accept-Language, and when writing my prior response, I realized that probably underlying their question was a concern based on a wrong understanding of RFC 1766 -- thinking that Accept-Language can't pass (e.g.) az-Cyrl-AZ because (in their mistaken understanding) RFC 1766 doesn't allow such a tag because of the script subtag. So, my response to them is, even though 2616 references 1766, Accept-Language most certainly can -- and likely will -- past a tag like az-Cyrl-AZ. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Mar 25 18:06:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNHpq-0006q9-QE; Sat, 25 Mar 2006 18:06:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNHpp-0006gb-PV for ltru@ietf.org; Sat, 25 Mar 2006 18:06:17 -0500 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNHpo-0004b8-Hh for ltru@ietf.org; Sat, 25 Mar 2006 18:06:17 -0500 Received: from DGBP7M81 ([69.162.95.23]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060325230615.NJZQ19976.mta9.adelphia.net@DGBP7M81> for ; Sat, 25 Mar 2006 18:06:15 -0500 Message-ID: <00de01c65060$b6c3b700$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 25 Mar 2006 15:06:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: WG last call for draft-ietf-ltru-matching X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I have read through draft-ietf-ltru-matching-11 and the minor changes proposed in draft-12, and have no substantial objections to any of it. I note that proposals are still on the board to "pretty up" the text. There are more than 4,400 RFCs and I don't believe I have seen a single one with what I would consider "perfect" wording of every sentence. I would like to suggest that we have reached the point of diminishing returns, and that unless the meaning or expected interpretation of a passage is in doubt, getting this work finished should take precedence over further text beautification. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ Editor, draft-ietf-ltru-initial _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 26 00:06:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNNSQ-0003VN-VN; Sun, 26 Mar 2006 00:06:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNNRA-0003Js-1m for ltru@ietf.org; Sun, 26 Mar 2006 00:05:12 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNNMl-0001cn-Ri for ltru@ietf.org; Sun, 26 Mar 2006 00:00:43 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FNNMh-0001zP-CZ; Sun, 26 Mar 2006 00:00:35 -0500 Date: Sun, 26 Mar 2006 00:00:35 -0500 To: Doug Ewell Subject: Re: [Ltru] Re: WG last call for draft-ietf-ltru-matching Message-ID: <20060326050035.GY15284@ccil.org> References: <00de01c65060$b6c3b700$040aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00de01c65060$b6c3b700$040aa8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > I note that proposals are still on the board to "pretty up" the text. > There are more than 4,400 RFCs and I don't believe I have seen a single > one with what I would consider "perfect" wording of every sentence. I > would like to suggest that we have reached the point of diminishing > returns, and that unless the meaning or expected interpretation of a > passage is in doubt, getting this work finished should take precedence > over further text beautification. Well, okay, then. I'll omit, as too trivial to mention, the ugly sequence of two parenthesized clauses in the penultimate paragraph of Section 2.1. But I think the SHOULD NOT in 2.2 just after Figure 2 ought not to be capitalized (and maybe changed to "cannot"). And the claim in 3.3 that an empty xml:lang attribute indicates that the element it's on contains non-linguistic content is flat wrong. And yes, I said that myself on this list. But it's still wrong. It simply indicates that that element makes no declaration of language, and is needed because a document without xml:lang may wind up embedded inside a document that has xml:lang. And in Section 4.1, the example in the 4th graf doesn't say whether it's about filtering or lookup, though it needs to. And in the 6th graf, the claim "Lookup implementations often ignore ..." is a factual one, and needs to be changed unless it can be proved. And that's really, really all I have to say. -- "But I am the real Strider, fortunately," John Cowan he said, looking down at them with his face cowan@ccil.org softened by a sudden smile. "I am Aragorn son http://www.ccil.org/~cowan of Arathorn, and if by life or death I can http://www.ap.org save you, I will." --LotR Book I Chapter 10 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 26 00:54:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNOCx-0000cy-W3; Sun, 26 Mar 2006 00:54:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNOCw-0000ct-P1 for ltru@ietf.org; Sun, 26 Mar 2006 00:54:34 -0500 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNOCv-0003Tz-Fz for ltru@ietf.org; Sun, 26 Mar 2006 00:54:34 -0500 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 <20060326055432.NZKG3381.mta13.adelphia.net@DGBP7M81>; Sun, 26 Mar 2006 00:54:32 -0500 Message-ID: <011c01c65099$bfb44a80$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <00de01c65060$b6c3b700$040aa8c0@DGBP7M81> <20060326050035.GY15284@ccil.org> Subject: Re: [Ltru] Re: WG last call for draft-ietf-ltru-matching Date: Sat, 25 Mar 2006 21:54:29 -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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org If there are errors in the draft, or things missing from the draft that need to be present, then of course those should be fixed. That's not what I mean by "prettying up" the text. -- 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 Mar 26 02:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNPHy-0000r8-3A; Sun, 26 Mar 2006 02:03:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMppe-0003Yl-PF for ltru@ietf.org; Fri, 24 Mar 2006 12:12:14 -0500 Received: from mxout4.cac.washington.edu ([140.142.33.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMppd-0002L9-Ay for ltru@ietf.org; Fri, 24 Mar 2006 12:12:14 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout4.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OHC6fe029057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Mar 2006 09:12:06 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OHBwTR002917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Mar 2006 09:12:06 -0800 Date: Fri, 24 Mar 2006 09:11:58 -0800 (PST) From: Mark Crispin To: "McDonald, Ira" Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language In-Reply-To: <789E617C880666438EDEE30C2A3E8D10ED87@mailsrvnt05.enet.sharplabs.com> Message-ID: References: <789E617C880666438EDEE30C2A3E8D10ED87@mailsrvnt05.enet.sharplabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Sun, 26 Mar 2006 02:03:48 -0500 Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As a long-time IETFer: Typically, these matters are handled on an ad-hoc case-by-case basis in which common sense prevails. The razor in this case is "does something break?" Most updates to IETF documents expand upon, or clarify, what was in the older document; they do not introduce an incompatibility. If something is removed, that is generally because there is community concensus that it is bad juju. So, given RFC abcd that normatively references RFC efgh that has been obsoleted by RFC ijkl: . can two RFC abcd implementations communicate with each other, and the desired behavior happen, even though one uses RFC efgh and the other uses RFC ijkl? If the answer is yes, then the question is effectively academic in nature. Sometime in the future, RFC abcd will have to be updated to reflect the change to RFC ijkl, but as it doesn't break interoperability it isn't urgent. One might expect that old implementations will use RFC efgh and new implementations will use RFC ijkl. If the answer is no, then someone was not doing their job; RFC ijkl should not have been approved without that working group taking on the needed update to RFC abcd. An important purpose of the IETF/IESG bureaucracy is to prevent something like this from happening. Hence the answer that since RFC abcd normatively refers to RFC efgh, it is RFC efgh that is used by an RFC abcd implementator. It is, however, expected that people would tend to use RFC ijkl instead (if only because it has clearer wording and represents more modern understanding) -- and sooner or later, RFC abcd will be obsoleted by a RFC mnop that makes this change official. Equally important is that RFC ijkl should not have been approved for publication if it creates an incompatibility problem in RFC abcd, without also updating/obsoleting RFC abcd. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 26 02:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNPHy-0000ru-D2; Sun, 26 Mar 2006 02:03:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMyAS-0007rP-2g for ltru@ietf.org; Fri, 24 Mar 2006 21:06:16 -0500 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMyAQ-00064Y-Nj for ltru@ietf.org; Fri, 24 Mar 2006 21:06:16 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout7.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2P267T5009787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Mar 2006 18:06:08 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2P266a9026217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Mar 2006 18:06:07 -0800 Date: Fri, 24 Mar 2006 18:06:05 -0800 (PST) From: Mark Crispin To: Peter Constable Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Sun, 26 Mar 2006 02:03:48 -0500 Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, 24 Mar 2006, Peter Constable wrote: > One more time... If anyone is to be excessively pedantic about RFC 1766, > then *far, far* more is allowed in a 1766 tag than is allowed under > 3066bis -- under 1766, there is *very little* that can be assumed about > the internal structure of tags. That doesn't in any way suggest > abolishing subtags; it just means that if all you know is RFC 1766 then > you don't know very much. Peter, I think that you and I are loudly agreeing. The point is that 3066bis, which creates specifics, doesn't break 1766 software which did not (could not) know about such specifics. Therefore there is no problem. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 26 02:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNPHy-0000rm-6q; Sun, 26 Mar 2006 02:03:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMqwR-0006lS-5E for ltru@ietf.org; Fri, 24 Mar 2006 13:23:19 -0500 Received: from mxout7.cac.washington.edu ([140.142.32.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMqwP-000502-Pv for ltru@ietf.org; Fri, 24 Mar 2006 13:23:19 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OIN7RZ010508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Mar 2006 10:23:08 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OIN6EN021574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Mar 2006 10:23:07 -0800 Date: Fri, 24 Mar 2006 10:23:05 -0800 (PST) From: Mark Crispin To: Peter Constable Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTPAccept-Language In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Sun, 26 Mar 2006 02:03:48 -0500 Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org The best answer to your question is "does it matter?" Suppose there are three RFC 2616 implementations: . implementation A uses RFC 1766 . implementation B uses RFC 3066 . implementation C uses RFC 3066bis Do these three implementation interoperate with each other? Does the expected behavior happen? If YES, then it doesn't matter. Someday, an update to RFC 2616 will be published that uses RFC 3066bis (or whatever replaces it). If NO, then RFC 1766 rules. You have identified an urgent need for RFC 2616 to be updated immediately. If YES, then when you give a recommendation to a team, say "use RFC 3066bis since that's the way of the future. An RFC 1766 based version will work just fine against your code." If NO, then say "don't implement RFC 2616. It's broken." Quite frankly, if 1766 -> 3066 -> 3066bis causes a NO, then the WG did not do its job. Nor did the IESG. On Fri, 24 Mar 2006, Peter Constable wrote: > This still leaves things somewhat vague wrt the specific question I > asked. You're saying that technically RFC 1766 is still the spec for > Accept-Language, but it's expected that people will actually use 3066bis > -- and as for "sooner or later", RFC 2616 was published in 1999, and RFC > 3066 was published in 2001, so we've already had five years go by during > which 2616 could have been obsoleted by another doc that normatively > referenced 3066 but that hasn't happened. > > If I needed to give a recommendation to a team that has to deal with > Accept-Language, it's really unclear to me which Language-Tag RFC I > should point them to. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 26 02:03:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNPHy-0000rq-Ae; Sun, 26 Mar 2006 02:03:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMv3v-0007Lo-DB for ltru@ietf.org; Fri, 24 Mar 2006 17:47:19 -0500 Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMv3u-0006yv-28 for ltru@ietf.org; Fri, 24 Mar 2006 17:47:19 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout1.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OMlB8q023199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Mar 2006 14:47:11 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW06.03) with ESMTP id k2OMl9TL020169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Mar 2006 14:47:10 -0800 Date: Fri, 24 Mar 2006 14:47:09 -0800 (PST) From: Mark Crispin To: "McDonald, Ira" Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language In-Reply-To: <789E617C880666438EDEE30C2A3E8D10ED8B@mailsrvnt05.enet.sharplabs.com> Message-ID: References: <789E617C880666438EDEE30C2A3E8D10ED8B@mailsrvnt05.enet.sharplabs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Sun, 26 Mar 2006 02:03:48 -0500 Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, 24 Mar 2006, McDonald, Ira wrote: > Precisely my point about RFC 2396 (Generic URI Syntax) and its > successor RFC 3986. Dozens of IETF and other standards specs > were broken by RFC 3986 doing away with some ABNF productions > and renaming others. A change in names in ABNF rules doesn't change the protocol in other documents. It may create a need to update the other documents, but it doesn't break anything. If some document inherited syntax rules from RFC 2396 and RFC 2986 changed some of the names, then you have to refer to RFC 2396 to see which rule was intended. A little bit of common sense goes a long way. > Peter - I think you're on your own - and note that RFC 1766 > doesn't exactly gracefully prepare programmers for 'script' > subtags in the second position followed by 'region' subtags > in the third position Sounds like a good argument to abolish script subtags, and to tell the people who want script identity that they are screwed, now and forever, and will just have to live with it because someone may be excessively pedantic about RFC 1766. Or. OR!!!! An attempt can be made to use common sense. There is usually both a harmful interpretation and one which is either harmless (or causes less harm). Common sense would sem to. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 26 15:09:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNbXt-000813-As; Sun, 26 Mar 2006 15:09:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNbXs-00080y-N7 for ltru@ietf.org; Sun, 26 Mar 2006 15:09:04 -0500 Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNbXr-0006Ym-Aj for ltru@ietf.org; Sun, 26 Mar 2006 15:09:04 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253] (may be forged)) by sharplabs.com (8.13.1/8.13.1) with ESMTP id k2QK91l2029711; Sun, 26 Mar 2006 12:09:01 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sun, 26 Mar 2006 12:09:01 -0800 Message-ID: <789E617C880666438EDEE30C2A3E8D10ED93@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: "'Peter Constable'" , ltru@ietf.org Subject: RE: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language Date: Sun, 26 Mar 2006 12:08:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > > Yes. I had a generic question about versioning for IETF > specs, for which > I got a somewhat vague answer; but I was also concerned about > a specific > instance of versioning, and for that I figured out an appropriate > answer. > > I've got someone asking me about Accept-Language, and when writing my > prior response, I realized that probably underlying their > question was a > concern based on a wrong understanding of RFC 1766 -- thinking that > Accept-Language can't pass (e.g.) az-Cyrl-AZ because (in > their mistaken > understanding) RFC 1766 doesn't allow such a tag because of the script > subtag. So, my response to them is, even though 2616 references 1766, > Accept-Language most certainly can -- and likely will -- past > a tag like > az-Cyrl-AZ. What RFC 1766 (or 3066) allowed or disallowed is only _part_ of the answer to your question about Accept-Language. RFC 1766 and RFC 3066 point normatively at the (now defunct) IANA Language Tag registry. If you tell your developers to conform to RFC 1766 (or RFC 3066), then they'll write code to check that IANA registry. On the other hand, if you tell your developers to conform to RFC3066bis, then they'll write code to check the _different_ IANA Language Subtag registry, and to enforce quite different rules of usage (e.g., no whole language tag is ever listed in the new registry). The LTRU WG has (perhaps precipitately?) encourage IANA to mothball the old registry - newly registered script subtags for specific languages will NOT also be registered into the defunct old registry - which means that running code that checks that registry will NOT explicitly understand that those _specific_ subtags are now valid script subtags. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.3.1/292 - Release Date: 3/24/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Mar 26 17:18:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNdZ6-0003BK-8B; Sun, 26 Mar 2006 17:18:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNdZ4-0003BF-A9 for ltru@ietf.org; Sun, 26 Mar 2006 17:18:26 -0500 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNdZ3-0003J3-3J for ltru@ietf.org; Sun, 26 Mar 2006 17:18:26 -0500 Received: from DGBP7M81 ([69.162.95.23]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060326221824.BUQY8301.mta10.adelphia.net@DGBP7M81> for ; Sun, 26 Mar 2006 17:18:24 -0500 Message-ID: <001d01c65123$31c50ae0$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 26 Mar 2006 14:18:21 -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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Re: status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org McDonald, Ira wrote: > The LTRU WG has (perhaps precipitately?) encourage IANA to > mothball the old registry - newly registered script subtags > for specific languages will NOT also be registered into the > defunct old registry - which means that running code that > checks that registry will NOT explicitly understand that > those _specific_ subtags are now valid script subtags. Isn't that exactly what we were chartered to do? Replace the old with the new? -- 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 Mon Mar 27 01:52:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNlat-0000GR-S9; Mon, 27 Mar 2006 01:52:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNlas-0000Ex-7K for ltru@ietf.org; Mon, 27 Mar 2006 01:52:50 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNlaq-0005HW-Km for ltru@ietf.org; Mon, 27 Mar 2006 01:52:50 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k2R6qad05159; Mon, 27 Mar 2006 15:52:36 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 12d1_461d4276_bd5e_11da_9bbb_0014221f2a2d; Mon, 27 Mar 2006 15:52:35 +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 k2R6oiMD031699; Mon, 27 Mar 2006 15:51:57 +0900 Message-Id: <6.0.0.20.2.20060327153825.05da6ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 27 Mar 2006 15:40:55 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: status of RFC 3066 or RFC 3066bis in relation to HTTPAccept-Language In-Reply-To: <001d01c65123$31c50ae0$040aa8c0@DGBP7M81> References: <001d01c65123$31c50ae0$040aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 07:18 06/03/27, Doug Ewell wrote: >McDonald, Ira wrote: > >> The LTRU WG has (perhaps precipitately?) encourage IANA to >> mothball the old registry - newly registered script subtags >> for specific languages will NOT also be registered into the >> defunct old registry - which means that running code that >> checks that registry will NOT explicitly understand that >> those _specific_ subtags are now valid script subtags. > >Isn't that exactly what we were chartered to do? Replace the old with the new? Well, the "U" in the name of our group reads "Update", which some people may argue is different from "Replace". But another important point is that the old registry really wasn't intended or designed for automatic lookup, so I think recommending to somebody that they use the old registry for checking tags is a rather doubtful idea. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 27 01:53:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNlb1-0000Lb-VE; Mon, 27 Mar 2006 01:52:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNlav-0000HN-1U for ltru@ietf.org; Mon, 27 Mar 2006 01:52:53 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNlaq-0005HX-EW for ltru@ietf.org; Mon, 27 Mar 2006 01:52:53 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k2R6qad05161; Mon, 27 Mar 2006 15:52:36 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 1eda_462892ac_bd5e_11da_80e9_0014221fa3c9; Mon, 27 Mar 2006 15:52:35 +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 k2R6oiMF031699; Mon, 27 Mar 2006 15:52:11 +0900 Message-Id: <6.0.0.20.2.20060327154130.05d37d70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 27 Mar 2006 15:43:01 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: WG last call for draft-ietf-ltru-matching In-Reply-To: <00de01c65060$b6c3b700$040aa8c0@DGBP7M81> References: <00de01c65060$b6c3b700$040aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [chair hat on] Hello Doug, Many thanks for your reading of the draft. I fully agree that we should concentrate on issues that may avoid misunderstandings, rather than on pure wordsmithing. Regards, Martin. At 08:06 06/03/26, Doug Ewell wrote: >I have read through draft-ietf-ltru-matching-11 and the minor changes proposed in draft-12, and have no substantial objections to any of it. > >I note that proposals are still on the board to "pretty up" the text. There are more than 4,400 RFCs and I don't believe I have seen a single one with what I would consider "perfect" wording of every sentence. I would like to suggest that we have reached the point of diminishing returns, and that unless the meaning or expected interpretation of a passage is in doubt, getting this work finished should take precedence over further text beautification. > >-- >Doug Ewell >Fullerton, California, USA >http://users.adelphia.net/~dewell/ >Editor, draft-ietf-ltru-initial > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 27 02:21:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNm2M-0006gS-BU; Mon, 27 Mar 2006 02:21:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNm2K-0006dw-8N for ltru@ietf.org; Mon, 27 Mar 2006 02:21:12 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNm2I-0006mu-UB for ltru@ietf.org; Mon, 27 Mar 2006 02:21:12 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C4ED8259766; Mon, 27 Mar 2006 09:19:19 +0200 (CEST) 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 17845-06; Mon, 27 Mar 2006 09:19:15 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 20433259764; Mon, 27 Mar 2006 09:19:15 +0200 (CEST) Message-ID: <4427926C.3070006@alvestrand.no> Date: Mon, 27 Mar 2006 09:21:16 +0200 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0.6-7.4.20060mdk (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "McDonald, Ira" Subject: Re: [Ltru] status of RFC 3066 or RFC 3066bis in relation to HTTP Accept-Language References: <789E617C880666438EDEE30C2A3E8D10ED93@mailsrvnt05.enet.sharplabs.com> In-Reply-To: <789E617C880666438EDEE30C2A3E8D10ED93@mailsrvnt05.enet.sharplabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org McDonald, Ira wrote: > >RFC 1766 and RFC 3066 point normatively at the (now defunct) >IANA Language Tag registry. If you tell your developers to >conform to RFC 1766 (or RFC 3066), then they'll write code >to check that IANA registry. > >On the other hand, if you tell your developers to conform to >RFC3066bis, then they'll write code to check the _different_ >IANA Language Subtag registry, and to enforce quite different >rules of usage (e.g., no whole language tag is ever listed >in the new registry). > >The LTRU WG has (perhaps precipitately?) encourage IANA to >mothball the old registry - newly registered script subtags >for specific languages will NOT also be registered into the >defunct old registry - which means that running code that >checks that registry will NOT explicitly understand that >those _specific_ subtags are now valid script subtags. > Reality checkpoint: Does anyone know of any production code that parses the old tag registry? (one-off scripts that generate simplified files that are later updated by hand doesn't count) Unless such code is shown to exist, I'm pretty sure it doesn't make sense to bend over backwards to be compatible with it - and even if it exists, it's a tradeoff, not a sure thing. Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Mar 27 13:39:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwd8-00036U-Vp; Mon, 27 Mar 2006 13:39:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwd7-00036P-Qb for ltru@ietf.org; Mon, 27 Mar 2006 13:39:53 -0500 Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNwd7-0003Ca-9M for ltru@ietf.org; Mon, 27 Mar 2006 13:39:53 -0500 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 27 Mar 2006 10:39:52 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.150]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 10:39:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Mar 2006 10:39:49 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: zh-min-nan, zh-xiang Thread-Index: AcZRzdPWWOj0ANWsRhm6k+8B5CjdCg== From: "Peter Constable" To: , X-OriginalArrivalTime: 27 Mar 2006 18:39:52.0049 (UTC) FILETIME=[D59B0610:01C651CD] X-Spam-Score: 0.2 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Cc: Subject: [Ltru] zh-min-nan, zh-xiang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0704381342==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0704381342== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C651CD.D506C437" This is a multi-part message in MIME format. ------_=_NextPart_001_01C651CD.D506C437 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Before 3066bis was completed, we added some entries in the 3066 tag registry to bring consistency with our plan for extlang and 639-3. Specifically, we added zh-cmn to supersede zh-guoyu. =20 I thought that we had done something similar to deal with zh-min-nan and zh-xiang: =20 zh-min-nan superseded by zh-nan zh-xiang superseded by zh-hsn =20 (Note: in 639-2/639-3, min is the ID for a Philippine language completely unrelated to Chinese.) =20 I don't see this reflected in the sub-tag registry, however. Did we not make those changes in the 3066 registry? =20 =20 =20 Thanks. =20 Peter Constable GIFT | GPTS | MICROSOFT =20 ------_=_NextPart_001_01C651CD.D506C437 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Before 3066bis was completed, we added some = entries in the 3066 tag registry to bring consistency with our plan for extlang and 639-3. Specifically, we added zh-cmn to supersede zh-guoyu.

 

I thought that we had done something similar = to deal with zh-min-nan and zh-xiang:

 

zh-min-nan superseded by zh-nan

zh-xiang superseded by zh-hsn

 

(Note: in 639-2/639-3, min is the ID for a = Philippine language completely unrelated to Chinese.)

 

I don’t see this reflected in the = sub-tag registry, however. Did we not make those changes in the 3066 = registry?

 

 

 

Thanks.

 

Peter = Constable

GIFT | GPTS = | MICROSOFT

 

------_=_NextPart_001_01C651CD.D506C437-- --===============0704381342== 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 --===============0704381342==-- From ltru-bounces@ietf.org Mon Mar 27 13:46:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwjJ-0007zJ-Rm; Mon, 27 Mar 2006 13:46:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwjI-0007zD-Gm for ltru@ietf.org; Mon, 27 Mar 2006 13:46:16 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNwjI-0003Nd-04 for ltru@ietf.org; Mon, 27 Mar 2006 13:46:16 -0500 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2RIiSmS001151; Mon, 27 Mar 2006 10:44:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: x-mailer:in-reply-to:x-mimeole:thread-index; b=bUPcHEn0Z/HLT/eA4JxToDQrlKQgmaRb2Fgz3cxXHvoLy8mX1BEcNc+gPd3YkiFz From: "Addison Phillips" To: "'Peter Constable'" , , Date: Mon, 27 Mar 2006 10:46:23 -0800 Message-ID: <001801c651ce$beb2cea0$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZRzdPWWOj0ANWsRhm6k+8B5CjdCgAAK/0g X-Spam-Score: -15.0 (---------------) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 Cc: Subject: [Ltru] RE: zh-min-nan, zh-xiang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0460432539==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0460432539== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C6518B.B08F8EA0" This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C6518B.B08F8EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I never saw registration requests to that effect, so I would guess the answer is "no". Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. _____ From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Peter Constable Sent: 2006?3?27? 10:40 To: ietf-languages@iana.org; ltru@ietf.org Subject: zh-min-nan, zh-xiang Before 3066bis was completed, we added some entries in the 3066 tag registry to bring consistency with our plan for extlang and 639-3. Specifically, we added zh-cmn to supersede zh-guoyu. I thought that we had done something similar to deal with zh-min-nan and zh-xiang: zh-min-nan superseded by zh-nan zh-xiang superseded by zh-hsn (Note: in 639-2/639-3, min is the ID for a Philippine language completely unrelated to Chinese.) I don't see this reflected in the sub-tag registry, however. Did we not make those changes in the 3066 registry? Thanks. Peter Constable GIFT | GPTS | MICROSOFT ------=_NextPart_000_0019_01C6518B.B08F8EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I never saw = registration requests to that effect, so I would guess the answer is = “no”.

 =

Addison

Addison = Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Peter Constable
Sent: = 2006年3月27日 10:40
To: = ietf-languages@iana.org; ltru@ietf.org
Subject: zh-min-nan, = zh-xiang

 

Before 3066bis was completed, we added some = entries in the 3066 tag registry to bring consistency with our plan for extlang = and 639-3. Specifically, we added zh-cmn to supersede = zh-guoyu.

 

I thought that we had done something similar = to deal with zh-min-nan and zh-xiang:

 

zh-min-nan superseded by = zh-nan

zh-xiang superseded by = zh-hsn

 

(Note: in 639-2/639-3, min is the ID for a Philippine language completely unrelated to = Chinese.)

 

I don’t see this reflected in the = sub-tag registry, however. Did we not make those changes in the 3066 = registry?

 

 

 

Thanks.

 

Peter = Constable

GIFT | GPTS | MICROSOFT

 

------=_NextPart_000_0019_01C6518B.B08F8EA0-- --===============0460432539== 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 --===============0460432539==-- From ltru-bounces@ietf.org Mon Mar 27 13:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwng-0000mF-Fh; Mon, 27 Mar 2006 13:50:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwnf-0000mA-0i for ltru@ietf.org; Mon, 27 Mar 2006 13:50:47 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNwne-0003Sq-FJ for ltru@ietf.org; Mon, 27 Mar 2006 13:50:46 -0500 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 27 Mar 2006 10:50:45 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.150]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Mar 2006 10:50:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Mar 2006 10:50:48 -0800 Message-ID: In-Reply-To: <001801c651ce$beb2cea0$9fcd15ac@ds.corp.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: zh-min-nan, zh-xiang Thread-Index: AcZRzdPWWOj0ANWsRhm6k+8B5CjdCgAAK/0gAAAvfWA= From: "Peter Constable" To: "Addison Phillips" , , X-OriginalArrivalTime: 27 Mar 2006 18:50:45.0142 (UTC) FILETIME=[5AE11B60:01C651CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 Cc: Subject: [Ltru] RE: zh-min-nan, zh-xiang X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0735787391==" Errors-To: ltru-bounces@ietf.org This is a multi-part message in MIME format. --===============0735787391== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C651CF.5A619DC7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C651CF.5A619DC7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Oh, well. We can deprecate those two after 3066ter is done. =20 ________________________________ From: Addison Phillips [mailto:addison@yahoo-inc.com]=20 Sent: Monday, March 27, 2006 10:46 AM To: Peter Constable; ietf-languages@iana.org; ltru@ietf.org Subject: RE: zh-min-nan, zh-xiang =20 I never saw registration requests to that effect, so I would guess the = answer is "no". =20 Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 ________________________________ From: ietf-languages-bounces@alvestrand.no = [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Peter = Constable Sent: 2006?3?27? 10:40 To: ietf-languages@iana.org; ltru@ietf.org Subject: zh-min-nan, zh-xiang =20 Before 3066bis was completed, we added some entries in the 3066 tag = registry to bring consistency with our plan for extlang and 639-3. = Specifically, we added zh-cmn to supersede zh-guoyu. =20 I thought that we had done something similar to deal with zh-min-nan and = zh-xiang: =20 zh-min-nan superseded by zh-nan zh-xiang superseded by zh-hsn =20 (Note: in 639-2/639-3, min is the ID for a Philippine language = completely unrelated to Chinese.) =20 I don't see this reflected in the sub-tag registry, however. Did we not = make those changes in the 3066 registry? =20 =20 =20 Thanks. =20 Peter Constable GIFT | GPTS | MICROSOFT =20 ------_=_NextPart_001_01C651CF.5A619DC7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Oh, well. We can deprecate those = two after 3066ter is done.

 

From: = Addison Phillips [mailto:addison@yahoo-inc.com]
Sent: Monday, March 27, = 2006 10:46 AM
To: Peter Constable; ietf-languages@iana.org; ltru@ietf.org
Subject: RE: zh-min-nan, = zh-xiang

 

I never saw = registration requests to that effect, so I would guess the answer is = “no”.

 =

Addison

Addison = Phillips
Internationalization Architect - Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages-bounces@alvestrand.no] On Behalf Of Peter = Constable
Sent: = 2006年3月27日 10:40
To: = ietf-languages@iana.org; ltru@ietf.org
Subject: zh-min-nan, = zh-xiang

 

Before 3066bis was completed, we added some = entries in the 3066 tag registry to bring consistency with our plan for extlang = and 639-3. Specifically, we added zh-cmn to supersede = zh-guoyu.

 

I thought that we had done something similar = to deal with zh-min-nan and zh-xiang:

 

zh-min-nan superseded by = zh-nan

zh-xiang superseded by = zh-hsn

 

(Note: in 639-2/639-3, min is the ID for a Philippine language completely unrelated to = Chinese.)

 

I don’t see this reflected in the = sub-tag registry, however. Did we not make those changes in the 3066 = registry?

 

 

 

Thanks.

 

Peter = Constable

GIFT | GPTS | MICROSOFT

 

------_=_NextPart_001_01C651CF.5A619DC7-- --===============0735787391== 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 --===============0735787391==-- From ltru-bounces@ietf.org Mon Mar 27 13:58:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwvY-0006TE-Qb; Mon, 27 Mar 2006 13:58:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNwvX-0006T9-8H for ltru@ietf.org; Mon, 27 Mar 2006 13:58:55 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNwvV-0003u6-V9 for ltru@ietf.org; Mon, 27 Mar 2006 13:58:55 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FNwvV-0000cA-GA; Mon, 27 Mar 2006 13:58:53 -0500 Date: Mon, 27 Mar 2006 13:58:53 -0500 To: Peter Constable Subject: Re: [Ltru] zh-min-nan, zh-xiang Message-ID: <20060327185853.GK30394@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: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > I thought that we had done something similar to deal with zh-min-nan and > zh-xiang: > > zh-min-nan superseded by zh-nan > zh-xiang superseded by zh-hsn We did not, because nobody requested them before the window closed. After 3066ter comes into effect, deprecating them will presumably be done as part of the batch of inserts and modifies that adds all the 639-3 code elements. Do you have an update for us on the progress of 639-3, BTW? ISO claims it is at stage 40.99, which suggests that the FDIS should be forthcoming shortly. -- A rabbi whose congregation doesn't want John Cowan to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan and a rabbi who lets them do it cowan@ccil.org isn't a man. --Jewish saying http://www.ap.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Mar 28 07:50:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FODe6-0007EI-ST; Tue, 28 Mar 2006 07:50:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FODe5-0007ED-9Z for ltru@ietf.org; Tue, 28 Mar 2006 07:50:01 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FODe4-00014j-0c for ltru@ietf.org; Tue, 28 Mar 2006 07:50:01 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 763AD259704; Tue, 28 Mar 2006 14:48:07 +0200 (CEST) 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 02111-02; Tue, 28 Mar 2006 14:48:04 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2AD21259702; Tue, 28 Mar 2006 14:48:04 +0200 (CEST) Message-ID: <442930F3.4080600@alvestrand.no> Date: Tue, 28 Mar 2006 14:49:55 +0200 From: Harald Alvestrand User-Agent: Mozilla Thunderbird 1.0 (X11/20050207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Constable Subject: Re: [Ltru] RE: zh-min-nan, zh-xiang References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ietf-languages@iana.org, ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > Oh, well. We can deprecate those two after 3066ter is done. > > > > ------------------------------------------------------------------------ so can we live with the situation-as-is until 2010, then? Harald "everything takes longer and costs more" Alvestrand _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 03:45:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOsm7-000350-7s; Thu, 30 Mar 2006 03:45:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOsm5-00032u-S6 for ltru@ietf.org; Thu, 30 Mar 2006 03:45:01 -0500 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOsm3-0008OM-7q for ltru@ietf.org; Thu, 30 Mar 2006 03:45:01 -0500 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k2U8iru08207 for ; Thu, 30 Mar 2006 17:44:53 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 23d7_74e64acc_bfc9_11da_8163_0014221fa3c9; Thu, 30 Mar 2006 17:44:52 +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 k2U8hpMW015781 for ; Thu, 30 Mar 2006 17:44:27 +0900 Message-Id: <6.0.0.20.2.20060330174033.0549b950@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 30 Mar 2006 17:43:42 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ltru] Less than a day to go for WG Last Call on 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: , Errors-To: ltru-bounces@ietf.org Dear LTRU WG members, This is another reminder for the WG Last Call on the matching draft. We have less than a day for this Last Call. The exact deadline is Thursday, March 30, 23:00 UTC (Friday, March 31st, 08:00 Japan time, Thursday, March 30, 3pm US Pacific, and so on). If you haven't read the -11 draft yet, please do so, even if you have read a previous draft. If you have read the -11 draft, please report your findings to the list, even if it is just that you haven't found any issues. Many thanks, Martin. P.S.: I'll update the issues list at http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/ tomorrow, after the deadline. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 04:55:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtse-0003rQ-JO; Thu, 30 Mar 2006 04:55:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOtse-0003rL-4V for ltru@ietf.org; Thu, 30 Mar 2006 04:55:52 -0500 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOtsd-0002OC-C5 for ltru@ietf.org; Thu, 30 Mar 2006 04:55:52 -0500 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k2U9tJd23301 for ; Thu, 30 Mar 2006 18:55:20 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 188c_4c42106a_bfd3_11da_8edf_0014221f2a2d; Thu, 30 Mar 2006 18:55:19 +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 k2U9s1Ki016504 for ; Thu, 30 Mar 2006 18:54:52 +0900 Message-Id: <6.0.0.20.2.20060330173946.0547cb00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 30 Mar 2006 18:53:46 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Subject: [Ltru] Martin's WG last call comments on matching X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [co-chair hat off] I have read the -11 version of the matching draft carefully. Compared to previous drafts, the current draft is quite a bit cleaner and more straightforward, and I think we should not loose much more time on it. However, I think it would be good to check/fix the following few issues. A) editorial, check Section 2.1: Basic language ranges (originally described by HTTP/1.1 [RFC2616] and later [RFC3066]) have the same syntax as an [RFC3066] language tag or are the single character "*". They differ from the language tags defined in [RFC3066bis] only in that there is no requirement that they be "well-formed" or be validated against the IANA Language Subtag Registry (although such ill-formed ranges will probably not match anything). I'm not totally sure the second [RFC3066] on the second line is what we want, or whether it should not be [RFC3066]. B) editorial, move Section 2.1: The last paragraph made sense here earlier, it looked very much out of context, because the concept of prefix is not mentioned anymore beforehand. I propose to move it to Section 4.2, after the current single paragraph in that section. The pararaph reads: Use of a basic language range seems to imply that there is a semantic relationship between language tags that share the same prefix. While this is often the case, it is not always true and users should note that the set of language tags that match a specific language range may not represent mutually intelligible languages. C) potentially substantial, but very minor In Section 2.2, there is a sentence saying: However, wildcards outside the first position in an extended language range are ignored by most matching schemes. I find the 'most' inappropriate. It suggests that there are a considerable number of such schemes in the first place. I suggest changing this to: However, wildcards outside the first position in an extended language range are ignored by some matching schemes, in particular by Extended Filtering (see Section 3.2.2). D) editorial or substantial, depending on why we have the current text There are a few instances where only "Implementations" are mentioned, where I'd have assumed it would say something like "Applications, protocols and implementations" (or whatever our preferred phrase was). If the uses of just "Implementation" in these cases is just an editorial oversight, I suggest we fix it. If it is not an editorial oversight, I still would prefer to fix it. The places I have found are as follows: D-1: Section 2.2: Implementations that specify basic ranges MAY map extended language ranges to basic language ranges: ... D-2: Section 3.3, just after Figure 4: Implementations SHOULD ignore extensions and unrecognized private-use subtags when performing lookup, since these subtags are usually orthogonal to the user's request. D-3: Section 3.3, second-to-last para: Implementations that accept extended language ranges MUST define which content is returned when more than one item matches the extended language range. D-4: Section 3.3, last para (two instances): For example, an implementation could return the matching tag that is first in ASCII-order. If the language range were "*-CH" and the set of tags included "de-CH", "fr-CH", and "it-CH", then the tag "de-CH" would be returned. Another possibility would be for an implementation to map the extended language ranges to basic ranges. E) editorial (or at least I think so) Section 3.2.2 is entitled "Extended Filtering", and starts: When filtering using extended language ranges, each extended language range in the language priority list is considered in turn, according to priority. A particular language range is compared to each language tag using the following process: ... This mixes up the general concept of filtering using extended language ranges and the specific concept of extended filtering as defined in our draft. It is probably a remnant of the earlier days, when our draft was more along the lines of "this is it" rather than "here are some reasonable ways to do things". I suggest to change the above text to: Extended filtering uses extended language ranges. Each extended language range in the language priority list is considered in turn, according to priority. A particular language range is compared to each language tag using the following process: ... F) explanatory I still remember having been surprised by how de-*-DE was used for extended filtering, and wondering whether the range of de-DE would lead to the same results (as it did). To help future readers, I'd like to modify the final paragraph of 3.2.2, which currently reads: Note: The structure of language tags defined by [RFC3066bis] defines each type of subtag (language, script, region, and so forth) according to position, size, and content. This means that subtags in a language range can only match specific types of subtags in a language tag. For example, a subtag such as 'Latn' is always a script subtag (unless it follows a singleton) while a subtag such as 'nedis' can only match the equivalent variant subtag. to something like the following: Note: The structure of language tags defined by [RFC3066bis] defines each type of subtag (language, script, region, and so forth) according to position, size, and content. This means that subtags in a language range can only match specific types of subtags in a language tag. For example, a subtag such as 'Latn' is always a script subtag (unless it follows a singleton) while a subtag such as 'nedis' can only match the equivalent variant subtag. The only exception to this is that two-letter subtags in initial position have a different type (language) than two-letter subtags in later positions (country). This is the reason why in Extended Filtering, "*" characters in extended language ranges are significant in the first position, but insignificant if they appear later. G) editorial, minor The first sentence in 3.3 Lookup reads: Lookup is used to select the single language tag that best matches the language priority list for a given request and return the associated content. I think it would be marginally easier to read if it read: Lookup is used to select the single language tag that best matches the language priority list for a given request and to return the associated content. H) editorial, readability In Section 4.1, second para, please change Most matching schemes make no attempt to process the semantic meaning of the subtags and the language range is compared, in a case- insensitive manner, to each language tag being matched, using basic string processing. to make two sentences, as follows: Most matching schemes make no attempt to process the semantic meaning of the subtags. The language range is compared, in a case- insensitive manner, to each language tag being matched, using basic string processing. I) explanatory, but somewhat major Section 4.1, 4th para, says: Users SHOULD avoid subtags that add no distinguishing value to a language range. When filtering, the fewer the number of subtags that appear in the language range, the more content the range will probably match, while in lookup unnecessary subtags might cause "better", more-specific content to be skipped in favor of less specific content. For example, the range "de-Latn-DE" would return content tagged "de" instead of content tagged "de-DE", even though the latter is probably a better match. This works in the case above, but there are other cases where the choice is not so easy. zh-Hans would be a good example. A user who reads both Simplified and Traditional Chinese, but who prefers simplified would use zh for filtering (getting all the content she can read) but zh-Hans for lookup (making sure she gets the preferred form if it's available, but the fallback to zh will still work). On the other hand, content in this case should be labeled as zh-Hans (or zh-Hant if that applies) for filtering, but for lookup, if there is either zh-Hans content or zh-Hant content, then one of them (the one considered 'default') should also be looked up under a simple zh. I think that if we do not explain this case where ranges and taggings for filtering and lookup differ, users of our document(s) will not be well served. I therefore think it is important to add this explanation. J) editorial, sentence structure/word usage The first para of Section 4.3 says: Private-use subtags require private agreement between the parties that intend to use or exchange language tags that use them and great caution SHOULD be used in employing them in content or protocols intended for general use. Private-use subtags are simply useless for information exchange without prior arrangement. The first sentence is difficult to understand. 'use' is used too much. I suggest the following rewrite: Private argeement is necessary between the parties that intend to use or exchange language tags that contain private-use subtags. Great caution SHOULD be used in employing private-use subtags in content or protocols intended for general use. Private-use subtags are simply useless for information exchange without prior arrangement. K) To say it mildly, I'm rather upset that Section 6, Changes, is still around. I wouldn't mind if it were there and contained useful information, or if it were almost up to date or there were any chance to get it up to date. As it is, it simply totally useless, and should go immediately, and I have said so previously and not received any satisfactory reason for its presence. [co-chair hat on] As a co-chair, I will not forward this draft to the AD and the IESG as long as it still contains section 6 in its present form. While there is some cleanup that the RFC editor has to do (such as replacing RFC3066bis with the real number), I do not want to bother anybody higher up or farther down the line with this section in its present form. [co-chair hat off] Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 09:31:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyBA-0007sm-Qt; Thu, 30 Mar 2006 09:31:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOyB8-0007rs-Tw for ltru@ietf.org; Thu, 30 Mar 2006 09:31:14 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOwEv-0000iv-8u for ltru@ietf.org; Thu, 30 Mar 2006 07:27:01 -0500 Received: from suomi.kotus.fi ([193.166.18.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FOvty-00028M-OP for ltru@ietf.org; Thu, 30 Mar 2006 07:05:26 -0500 Received: from kotus.fi (pc094.kotus.fi [193.166.18.94]) by suomi.kotus.fi (8.12.10+Sun/8.12.9) with ESMTP id k2UC5G6G021954; Thu, 30 Mar 2006 15:05:17 +0300 (EEST) Message-ID: <442BC971.4040704@kotus.fi> Date: Thu, 30 Mar 2006 15:05:05 +0300 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Less than a day to go for WG Last Call on matching draft References: <6.0.0.20.2.20060330174033.0549b950@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear All, I have read the -11 draft, and I haven't found any issues. Sincerely, Erkki I. Kolehmainen Martin Duerst wrote: > Dear LTRU WG members, > > This is another reminder for the WG Last Call on the matching draft. > We have less than a day for this Last Call. The exact deadline > is Thursday, March 30, 23:00 UTC (Friday, March 31st, 08:00 > Japan time, Thursday, March 30, 3pm US Pacific, and so on). > > If you haven't read the -11 draft yet, please do so, even if you > have read a previous draft. If you have read the -11 draft, please > report your findings to the list, even if it is just that you haven't > found any issues. > > Many thanks, Martin. > > P.S.: I'll update the issues list at > http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/ tomorrow, > after the deadline. > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 11:32:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP04H-0007LL-6T; Thu, 30 Mar 2006 11:32:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP04F-0007L5-PM for ltru@ietf.org; Thu, 30 Mar 2006 11:32:15 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP04F-0004mr-Nx for ltru@ietf.org; Thu, 30 Mar 2006 11:32:15 -0500 Received: from anubis.medic.chalmers.se ([129.16.30.218]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FOzwj-00047S-46 for ltru@ietf.org; Thu, 30 Mar 2006 11:24:30 -0500 X-Medic-Info: 809.442c061d.0 voLrujzaI9hJJzq4 Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id C4DFF891E for ; Thu, 30 Mar 2006 18:23:57 +0200 (CEST) Received: from 195.242.62.51 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Thu, 30 Mar 2006 18:23:57 +0200 (CEST) Message-ID: <18622.195.242.62.51.1143735837.squirrel@webmail.chalmers.se> In-Reply-To: <442BC971.4040704@kotus.fi> References: <6.0.0.20.2.20060330174033.0549b950@localhost> <442BC971.4040704@kotus.fi> Date: Thu, 30 Mar 2006 18:23:57 +0200 (CEST) Subject: Re: [Ltru] Less than a day to go for WG Last Call on matching draft From: "Kent Karlsson" To: "LTRU Working Group" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I still object to the text in 3.2.2: "Subtags not specified, including those at the end of the language range, are thus treated as if assigned the wildcard value "*"." (and following examples). I think that wildcards must be explicit, possibly with the exception of final ones, but not internal ones. I see no reason for internal ones not to be explicit. /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 11:56:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP0S3-0000TG-IJ; Thu, 30 Mar 2006 11:56:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP0S1-0000TB-Vo for ltru@ietf.org; Thu, 30 Mar 2006 11:56:49 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP0S0-0005iy-IT for ltru@ietf.org; Thu, 30 Mar 2006 11:56:49 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FP0S0-0006Fn-66; Thu, 30 Mar 2006 11:56:48 -0500 Date: Thu, 30 Mar 2006 11:56:48 -0500 To: Kent Karlsson Subject: Re: [Ltru] Less than a day to go for WG Last Call on matching draft Message-ID: <20060330165648.GI4777@ccil.org> References: <6.0.0.20.2.20060330174033.0549b950@localhost> <442BC971.4040704@kotus.fi> <18622.195.242.62.51.1143735837.squirrel@webmail.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18622.195.242.62.51.1143735837.squirrel@webmail.chalmers.se> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > "Subtags not specified, including those at the end of the language range, > are thus treated as if assigned the wildcard value "*"." (and following > examples). > > I think that wildcards must be explicit, possibly with the exception of > final ones, but not internal ones. I see no reason for internal ones not > to be explicit. As the word "thus" indicates, the statement to which you object is a consequence of the algorithm as described, as you can see by working out the details. Are you in fact objecting to the algorithm? -- John Cowan cowan@ccil.org www.ccil.org/~cowan www.ap.org Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 13:03:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP1Uq-0006kH-Iv; Thu, 30 Mar 2006 13:03:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP1Up-0006jp-VK for ltru@ietf.org; Thu, 30 Mar 2006 13:03:47 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP1Uo-0000Ko-O2 for ltru@ietf.org; Thu, 30 Mar 2006 13:03:47 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FP1Um-0000hO-DY; Thu, 30 Mar 2006 13:03:44 -0500 Date: Thu, 30 Mar 2006 13:03:44 -0500 To: Martin Duerst Subject: Re: [Ltru] Martin's WG last call comments on matching Message-ID: <20060330180344.GK4777@ccil.org> References: <6.0.0.20.2.20060330173946.0547cb00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060330173946.0547cb00@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > I have read the -11 version of the matching draft carefully. > Compared to previous drafts, the current draft is quite a bit > cleaner and more straightforward, and I think we should not > loose much more time on it. > > However, I think it would be good to check/fix the following few > issues. +1 to all specific points. -- A mosquito cried out in his pain, John Cowan "A chemist has poisoned my brain!" http://www.ccil.org/~cowan The cause of his sorrow http://www.ap.org Was para-dichloro- cowan@ccil.org Diphenyltrichloroethane. (aka DDT) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 14:05:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2S1-00036R-1r; Thu, 30 Mar 2006 14:04:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2Rz-00036M-IM for ltru@ietf.org; Thu, 30 Mar 2006 14:04:55 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP2Ry-0003b4-Sx for ltru@ietf.org; Thu, 30 Mar 2006 14:04:55 -0500 Received: from duringpersonlx (wlanvpn-mc1-246-100.corp.yahoo.com [172.21.246.100]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2UJ4GWs092294; Thu, 30 Mar 2006 11:04:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=ElBRPB0e9NEoePos6Nkic59e7f8Suj7zWI2L9Kn1qaqrvZ4yjovIxRiKkkpbqpd7 From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Martin's WG last call comments on matching Date: Thu, 30 Mar 2006 11:06:10 -0800 Message-ID: <000a01c6542d$01fa7310$f4fa15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6.0.0.20.2.20060330173946.0547cb00@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZT4DOXvDNaFjt2Qj6rQoFL/x1ygAARoOxQ X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Responses follow. Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 2006?3?30? 1:54 > To: LTRU Working Group > Subject: [Ltru] Martin's WG last call comments on matching > > > A) editorial, check > > Section 2.1: > Basic language ranges (originally described by HTTP/1.1 [RFC2616] and > later [RFC3066]) have the same syntax as an [RFC3066] language tag or > are the single character "*". They differ from the language tags > defined in [RFC3066bis] only in that there is no requirement that > they be "well-formed" or be validated against the IANA Language > Subtag Registry (although such ill-formed ranges will probably not > match anything). > > I'm not totally sure the second [RFC3066] on the second line is > what we want, or whether it should not be [RFC3066]. Do you mean "it should not be [RFC3066bis]"? If so, the answer is "no, we want RFC 3066 here". The tag syntax for ranges is explicitly more relaxed and is compatible with RFC2616 and friends, not the more stringent 3066bis rules. > > > B) editorial, move > > Section 2.1: The last paragraph made sense here earlier, it looked > very much out of context, because the concept of prefix is not > mentioned anymore beforehand. I propose to move it to Section 4.2, > after the current single paragraph in that section. The pararaph > reads: > > Use of a basic language range seems to imply that there is a semantic > relationship between language tags that share the same prefix. While > this is often the case, it is not always true and users should note > that the set of language tags that match a specific language range > may not represent mutually intelligible languages. The real issue here is not the range syntax but rather that syntax's use in filtering (it doesn't apply to lookup). I propose we move this text to section 3.2 and rephrase as: -- Filtering seems to imply that there is a semantic relationship between language tags that share the same prefix. While this is often the case, it is not always true and users should note that the set of language tags that match a specific language range may not represent mutually intelligible languages. -- > > > C) potentially substantial, but very minor > > In Section 2.2, there is a sentence saying: > > However, wildcards outside the first position in an extended > language range are ignored by most matching schemes. > > I find the 'most' inappropriate. It suggests that there are a > considerable number of such schemes in the first place. I suggest > changing this to: > > However, wildcards outside the first position in an extended > language range are ignored by some matching schemes, in > particular by Extended Filtering (see Section 3.2.2). How about (including a minor mod to the following sentence): -- However, wildcards outside the first position are ignored by Extended Filtering (see Section 3.2.2). The use or absence of one or more wildcards SHOULD NOT be taken to imply that a certain number of subtags will appear in the matching set of language tags. -- > > > D) editorial or substantial, depending on why we have the current > text > > There are a few instances where only "Implementations" are mentioned, > where I'd have assumed it would say something like "Applications, > protocols and implementations" (or whatever our preferred phrase was). > > If the uses of just "Implementation" in these cases is just an > editorial oversight, I suggest we fix it. If it is not an editorial > oversight, I still would prefer to fix it. It isn't an editorial oversight in some cases and is in others. The rationale for the non-oversight instances has subsequently been removed, though. The only one I object to fixing is the last one, which is a non-specific example: > > D-4: Section 3.3, last para (two instances): > For example, an implementation could return the matching tag that is > first in ASCII-order. If the language range were "*-CH" and the set > of tags included "de-CH", "fr-CH", and "it-CH", then the tag "de-CH" > would be returned. Another possibility would be for an > implementation to map the extended language ranges to basic ranges. > > E) editorial (or at least I think so) > > Section 3.2.2 is entitled "Extended Filtering", and starts: > > When filtering using extended language ranges, each extended language > range in the language priority list is considered in turn, according > to priority. A particular language range is compared to each > language tag using the following process: > ... > > This mixes up the general concept of filtering using extended language > ranges and the specific concept of extended filtering as defined in > our draft. It is probably a remnant of the earlier days, when our draft > was more along the lines of "this is it" rather than "here are some > reasonable ways to do things". I suggest to change the above text to: > > Extended filtering uses extended language ranges. Each extended > language > range in the language priority list is considered in turn, according > to priority. A particular language range is compared to each > language tag using the following process: > ... I agree. > > > F) explanatory > > I still remember having been surprised by how de-*-DE was used > for extended filtering, and wondering whether the range of de-DE > would lead to the same results (as it did). That comment resulted in large scale wording changes to the algorithm, as I recall. > > To help future readers, I'd like to modify the final paragraph of > 3.2.2, which currently reads: > > Note: The structure of language tags defined by [RFC3066bis] defines > each type of subtag (language, script, region, and so forth) > according to position, size, and content. This means that subtags in > a language range can only match specific types of subtags in a > language tag. For example, a subtag such as 'Latn' is always a > script subtag (unless it follows a singleton) while a subtag such as > 'nedis' can only match the equivalent variant subtag. > > to something like the following: > > Note: The structure of language tags defined by [RFC3066bis] defines > each type of subtag (language, script, region, and so forth) > according to position, size, and content. This means that subtags in > a language range can only match specific types of subtags in a > language tag. For example, a subtag such as 'Latn' is always a > script subtag (unless it follows a singleton) while a subtag such as > 'nedis' can only match the equivalent variant subtag. The only > exception to this is that two-letter subtags in initial position > have a different type (language) than two-letter subtags in > later positions (country). This is the reason why in Extended > Filtering, "*" characters in extended language ranges are > significant in the first position, but insignificant if they > appear later. The main problem with your suggested text is the word "exception". Position/size/content are what separates the subtag items. The problem is the need to indicate the position if you want an 'emtpy' or "don't care" initial subtag. Note that the algorithm does not permit "*-Latn" to match tags "x-Latn" or "de-f-Latn"!! Thus I would suggest this modified version of your text: -- Note: The structure of language tags defined by [RFC3066bis] defines each type of subtag (language, script, region, and so forth) according to position, size, and content. This means that subtags in a language range can only match specific types of subtags in a language tag. For example, a subtag such as 'Latn' is always a script subtag (unless it follows a singleton) while a subtag such as 'nedis' can only match the equivalent variant subtag. One such difference is that two-letter subtags in initial position have a different type (language) than two-letter subtags in later positions (region). This is the reason why, in Extended Filtering, wildcards in extended language ranges are significant in the first position, but can be ignored if they appear later. -- > > > G) editorial, minor > > The first sentence in 3.3 Lookup reads: > > Lookup is used to select the single language tag that best matches > the language priority list for a given request and return the > associated content. > > I think it would be marginally easier to read if it read: > > Lookup is used to select the single language tag that best matches > the language priority list for a given request and to return the > associated content. I disagree. Your wording separates this single action into two actions. > > > H) editorial, readability > > In Section 4.1, second para, please change > > Most matching schemes make no attempt to process the semantic meaning > of the subtags and the language range is compared, in a case- > insensitive manner, to each language tag being matched, using basic > string processing. > > to make two sentences, as follows: > > Most matching schemes make no attempt to process the semantic meaning > of the subtags. The language range is compared, in a case- > insensitive manner, to each language tag being matched, using basic > string processing. +1 > > > I) explanatory, but somewhat major > > Section 4.1, 4th para, says: > > Users SHOULD avoid subtags that add no distinguishing value to a > language range. When filtering, the fewer the number of subtags > that > appear in the language range, the more content the range will > probably match, while in lookup unnecessary subtags might cause > "better", more-specific content to be skipped in favor of less > specific content. For example, the range "de-Latn-DE" would return > content tagged "de" instead of content tagged "de-DE", even though > the latter is probably a better match. > > This works in the case above, but there are other cases where the > choice is not so easy. zh-Hans would be a good example. A user who > reads both Simplified and Traditional Chinese, but who prefers > simplified would use zh for filtering (getting all the content > she can read) but zh-Hans for lookup (making sure she gets the > preferred form if it's available, but the fallback to zh will > still work). On the other hand, content in this case should be > labeled as zh-Hans (or zh-Hant if that applies) for filtering, > but for lookup, if there is either zh-Hans content or zh-Hant > content, then one of them (the one considered 'default') should > also be looked up under a simple zh. > > I think that if we do not explain this case where ranges and > taggings for filtering and lookup differ, users of our document(s) > will not be well served. I therefore think it is important to > add this explanation. The key phrase is "distinguishing value". I agree that we should add text based on your example. > > > J) editorial, sentence structure/word usage > > The first para of Section 4.3 says: > > Private-use subtags require private agreement between the parties > that intend to use or exchange language tags that use them and great > caution SHOULD be used in employing them in content or protocols > intended for general use. Private-use subtags are simply useless for > information exchange without prior arrangement. > > The first sentence is difficult to understand. 'use' is used too much. > I suggest the following rewrite: > > Private argeement is necessary between the parties that intend to use > or exchange language tags that contain private-use subtags. > Great caution SHOULD be used in employing private-use subtags in > content or protocols intended for general use. Private-use subtags > are simply useless for information exchange without prior arrangement. +1 > > > K) To say it mildly, I'm rather upset that Section 6, Changes, > is still around. I wouldn't mind if it were there and contained > useful information, or if it were almost up to date or there were > any chance to get it up to date. As it is, it simply totally useless, > and should go immediately, and I have said so previously and > not received any satisfactory reason for its presence. I didn't remove it from draft-11 since I intended to (and have been recording) the WGLC changes in the document. Since idnits doesn't care, I have removed it from my editor's copy instead. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 14:42:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP31x-0000zM-Or; Thu, 30 Mar 2006 14:42:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP31w-0000zH-LM for ltru@ietf.org; Thu, 30 Mar 2006 14:42:04 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP31u-0004fG-UG for ltru@ietf.org; Thu, 30 Mar 2006 14:42:04 -0500 Received: from duringpersonlx (wlanvpn-mc1-246-100.corp.yahoo.com [172.21.246.100]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2UJf17B005147; Thu, 30 Mar 2006 11:41:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=jHJ1pqeqb3LY/USlGkER7T9iPOXKgX3h4L3i2l7dY+9IJYJ4kNmIKXRh4nRFUoDY From: "Addison Phillips" To: "'Addison Phillips'" , "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Martin's WG last call comments on matching Date: Thu, 30 Mar 2006 11:42:54 -0800 Message-ID: <001101c65432$236753b0$f4fa15ac@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: <000a01c6542d$01fa7310$f4fa15ac@ds.corp.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZT4DOXvDNaFjt2Qj6rQoFL/x1ygAARoOxQAAK7XTA= X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f0ea5880a0890be2408609376fa519aa Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I updated the editor's copy on: http://www.inter-locale.com/ID/draft-ietf-ltru-matching-12.txt http://www.inter-locale.com/ID/draft-ietf-ltru-matching-12.html http://www.inter-locale.com/ID/draft-ietf-ltru-matching-12.xml ... with the changes discussed below. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 2006?3?30? 11:06 > To: 'Martin Duerst'; 'LTRU Working Group' > Subject: RE: [Ltru] Martin's WG last call comments on matching > > Responses follow. > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > -----Original Message----- > > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > > Sent: 2006?3?30? 1:54 > > To: LTRU Working Group > > Subject: [Ltru] Martin's WG last call comments on matching > > > > > > A) editorial, check > > > > Section 2.1: > > Basic language ranges (originally described by HTTP/1.1 [RFC2616] > and > > later [RFC3066]) have the same syntax as an [RFC3066] language tag > or > > are the single character "*". They differ from the language tags > > defined in [RFC3066bis] only in that there is no requirement that > > they be "well-formed" or be validated against the IANA Language > > Subtag Registry (although such ill-formed ranges will probably not > > match anything). > > > > I'm not totally sure the second [RFC3066] on the second line is > > what we want, or whether it should not be [RFC3066]. > > Do you mean "it should not be [RFC3066bis]"? > > If so, the answer is "no, we want RFC 3066 here". The tag syntax for > ranges > is explicitly more relaxed and is compatible with RFC2616 and friends, not > the more stringent 3066bis rules. > > > > > > B) editorial, move > > > > Section 2.1: The last paragraph made sense here earlier, it looked > > very much out of context, because the concept of prefix is not > > mentioned anymore beforehand. I propose to move it to Section 4.2, > > after the current single paragraph in that section. The pararaph > > reads: > > > > Use of a basic language range seems to imply that there is a > semantic > > relationship between language tags that share the same prefix. > While > > this is often the case, it is not always true and users should note > > that the set of language tags that match a specific language range > > may not represent mutually intelligible languages. > > The real issue here is not the range syntax but rather that syntax's use > in > filtering (it doesn't apply to lookup). I propose we move this text to > section 3.2 and rephrase as: > > -- > Filtering seems to imply that there is a semantic relationship between > language tags that share the same prefix. While this is often the case, it > is not always true and users should note that the set of language tags > that > match a specific language range may not represent mutually intelligible > languages. > -- > > > > > > > C) potentially substantial, but very minor > > > > In Section 2.2, there is a sentence saying: > > > > However, wildcards outside the first position in an extended > > language range are ignored by most matching schemes. > > > > I find the 'most' inappropriate. It suggests that there are a > > considerable number of such schemes in the first place. I suggest > > changing this to: > > > > However, wildcards outside the first position in an extended > > language range are ignored by some matching schemes, in > > particular by Extended Filtering (see Section 3.2.2). > > How about (including a minor mod to the following sentence): > > -- > However, wildcards outside the first position are ignored by Extended > Filtering (see Section 3.2.2). The use or absence of one or more wildcards > SHOULD NOT be taken to imply that a certain number of subtags will appear > in > the matching set of language tags. > -- > > > > > > D) editorial or substantial, depending on why we have the current > > text > > > > There are a few instances where only "Implementations" are mentioned, > > where I'd have assumed it would say something like "Applications, > > protocols and implementations" (or whatever our preferred phrase was). > > > > If the uses of just "Implementation" in these cases is just an > > editorial oversight, I suggest we fix it. If it is not an editorial > > oversight, I still would prefer to fix it. > > It isn't an editorial oversight in some cases and is in others. The > rationale for the non-oversight instances has subsequently been removed, > though. The only one I object to fixing is the last one, which is a > non-specific example: > > > > D-4: Section 3.3, last para (two instances): > > For example, an implementation could return the matching tag that > is > > first in ASCII-order. If the language range were "*-CH" and the > set > > of tags included "de-CH", "fr-CH", and "it-CH", then the tag "de- > CH" > > would be returned. Another possibility would be for an > > implementation to map the extended language ranges to basic ranges. > > > > E) editorial (or at least I think so) > > > > Section 3.2.2 is entitled "Extended Filtering", and starts: > > > > When filtering using extended language ranges, each extended > language > > range in the language priority list is considered in turn, > according > > to priority. A particular language range is compared to each > > language tag using the following process: > > ... > > > > This mixes up the general concept of filtering using extended > language > > ranges and the specific concept of extended filtering as defined in > > our draft. It is probably a remnant of the earlier days, when our > draft > > was more along the lines of "this is it" rather than "here are some > > reasonable ways to do things". I suggest to change the above text to: > > > > Extended filtering uses extended language ranges. Each extended > > language > > range in the language priority list is considered in turn, > according > > to priority. A particular language range is compared to each > > language tag using the following process: > > ... > > I agree. > > > > > > F) explanatory > > > > I still remember having been surprised by how de-*-DE was used > > for extended filtering, and wondering whether the range of de-DE > > would lead to the same results (as it did). > > That comment resulted in large scale wording changes to the algorithm, as > I > recall. > > > > To help future readers, I'd like to modify the final paragraph of > > 3.2.2, which currently reads: > > > > Note: The structure of language tags defined by [RFC3066bis] > defines > > each type of subtag (language, script, region, and so forth) > > according to position, size, and content. This means that subtags > in > > a language range can only match specific types of subtags in a > > language tag. For example, a subtag such as 'Latn' is always a > > script subtag (unless it follows a singleton) while a subtag such > as > > 'nedis' can only match the equivalent variant subtag. > > > > to something like the following: > > > > Note: The structure of language tags defined by [RFC3066bis] > defines > > each type of subtag (language, script, region, and so forth) > > according to position, size, and content. This means that subtags > in > > a language range can only match specific types of subtags in a > > language tag. For example, a subtag such as 'Latn' is always a > > script subtag (unless it follows a singleton) while a subtag such > as > > 'nedis' can only match the equivalent variant subtag. The only > > exception to this is that two-letter subtags in initial position > > have a different type (language) than two-letter subtags in > > later positions (country). This is the reason why in Extended > > Filtering, "*" characters in extended language ranges are > > significant in the first position, but insignificant if they > > appear later. > > The main problem with your suggested text is the word "exception". > Position/size/content are what separates the subtag items. The problem is > the need to indicate the position if you want an 'emtpy' or "don't care" > initial subtag. Note that the algorithm does not permit "*-Latn" to match > tags "x-Latn" or "de-f-Latn"!! > > Thus I would suggest this modified version of your text: > > -- > Note: The structure of language tags defined by [RFC3066bis] defines each > type of subtag (language, script, region, and so forth) according to > position, size, and content. This means that subtags in a language range > can only match specific types of subtags in a language tag. For example, > a > subtag such as 'Latn' is always a script subtag (unless it follows a > singleton) while a subtag such as 'nedis' can only match the equivalent > variant subtag. One such difference is that two-letter subtags in initial > position have a different type (language) than two-letter subtags in later > positions (region). This is the reason why, in Extended Filtering, > wildcards > in extended language ranges are significant in the first position, but can > be ignored if they appear later. > -- > > > > > > > G) editorial, minor > > > > The first sentence in 3.3 Lookup reads: > > > > Lookup is used to select the single language tag that best matches > > the language priority list for a given request and return the > > associated content. > > > > I think it would be marginally easier to read if it read: > > > > Lookup is used to select the single language tag that best matches > > the language priority list for a given request and to return the > > associated content. > > I disagree. Your wording separates this single action into two actions. > > > > > > H) editorial, readability > > > > In Section 4.1, second para, please change > > > > Most matching schemes make no attempt to process the semantic > meaning > > of the subtags and the language range is compared, in a case- > > insensitive manner, to each language tag being matched, using basic > > string processing. > > > > to make two sentences, as follows: > > > > Most matching schemes make no attempt to process the semantic > meaning > > of the subtags. The language range is compared, in a case- > > insensitive manner, to each language tag being matched, using basic > > string processing. > > +1 > > > > > > I) explanatory, but somewhat major > > > > Section 4.1, 4th para, says: > > > > Users SHOULD avoid subtags that add no distinguishing value to a > > language range. When filtering, the fewer the number of subtags > > that > > appear in the language range, the more content the range will > > probably match, while in lookup unnecessary subtags might cause > > "better", more-specific content to be skipped in favor of less > > specific content. For example, the range "de-Latn-DE" would > return > > content tagged "de" instead of content tagged "de-DE", even though > > the latter is probably a better match. > > > > This works in the case above, but there are other cases where the > > choice is not so easy. zh-Hans would be a good example. A user who > > reads both Simplified and Traditional Chinese, but who prefers > > simplified would use zh for filtering (getting all the content > > she can read) but zh-Hans for lookup (making sure she gets the > > preferred form if it's available, but the fallback to zh will > > still work). On the other hand, content in this case should be > > labeled as zh-Hans (or zh-Hant if that applies) for filtering, > > but for lookup, if there is either zh-Hans content or zh-Hant > > content, then one of them (the one considered 'default') should > > also be looked up under a simple zh. > > > > I think that if we do not explain this case where ranges and > > taggings for filtering and lookup differ, users of our document(s) > > will not be well served. I therefore think it is important to > > add this explanation. > > The key phrase is "distinguishing value". I agree that we should add text > based on your example. > > > > > > J) editorial, sentence structure/word usage > > > > The first para of Section 4.3 says: > > > > Private-use subtags require private agreement between the parties > > that intend to use or exchange language tags that use them and > great > > caution SHOULD be used in employing them in content or protocols > > intended for general use. Private-use subtags are simply useless > for > > information exchange without prior arrangement. > > > > The first sentence is difficult to understand. 'use' is used too much. > > I suggest the following rewrite: > > > > Private argeement is necessary between the parties that intend to > use > > or exchange language tags that contain private-use subtags. > > Great caution SHOULD be used in employing private-use subtags in > > content or protocols intended for general use. Private-use subtags > > are simply useless for information exchange without prior > arrangement. > > +1 > > > > > > K) To say it mildly, I'm rather upset that Section 6, Changes, > > is still around. I wouldn't mind if it were there and contained > > useful information, or if it were almost up to date or there were > > any chance to get it up to date. As it is, it simply totally useless, > > and should go immediately, and I have said so previously and > > not received any satisfactory reason for its presence. > > I didn't remove it from draft-11 since I intended to (and have been > recording) the WGLC changes in the document. Since idnits doesn't care, I > have removed it from my editor's copy instead. > > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 15:09:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3SD-00037M-D1; Thu, 30 Mar 2006 15:09:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3MT-0001lZ-0N for ltru@ietf.org; Thu, 30 Mar 2006 15:03:17 -0500 Received: from pne-smtpout2-sn2.hy.skanova.net ([81.228.8.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP3MR-0005bY-N4 for ltru@ietf.org; Thu, 30 Mar 2006 15:03:16 -0500 Received: from chalmers95a69n (83.248.24.153) by pne-smtpout2-sn2.hy.skanova.net (7.2.070) id 4405C12200730CCE for ltru@ietf.org; Thu, 30 Mar 2006 22:03:14 +0200 From: "Kent Karlsson" To: Subject: RE: [Ltru] Less than a day to go for WG Last Call on matching draft Date: Thu, 30 Mar 2006 21:58:12 +0200 Message-ID: <000201c65434$46b18730$6500a8c0@chalmers95a69n> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20060330165648.GI4777@ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Thu, 30 Mar 2006 15:09:12 -0500 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Kent Karlsson scripsit: > > > "Subtags not specified, including those at the end of the language range, > > are thus treated as if assigned the wildcard value "*"." (and following > > examples). > > > > I think that wildcards must be explicit, possibly with the exception of > > final ones, but not internal ones. I see no reason for internal ones not > > to be explicit. > > As the word "thus" indicates, the statement to which you object is a > consequence of the algorithm as described, as you can see by > working out the details. > > Are you in fact objecting to the algorithm? The details of the algorithm paragraph you are referring to are unclear to me. But it is very likely that I object to it (if said consequence is really what falls out). But it seem to me that the "algorithm" totally ignores wildcards... Which is rather strange and objectionable... If the algorithm paragraph can be reformulated for clarity, the better. (You apparently did not like my way of claryfying it, actually talking about partial orders rather than *pretending* there isn't one.) /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 15:47:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP43S-0006LQ-1f; Thu, 30 Mar 2006 15:47:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP43Q-0006LL-O3 for ltru@ietf.org; Thu, 30 Mar 2006 15:47:40 -0500 Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP43P-0007L1-EI for ltru@ietf.org; Thu, 30 Mar 2006 15:47:40 -0500 X-Medic-Info: d5d.442c43ea.0 ho3U9W47GtD3uBii Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 1F8C93E22 for ; Thu, 30 Mar 2006 22:47:38 +0200 (CEST) Received: from 83.248.24.153 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Thu, 30 Mar 2006 22:47:38 +0200 (CEST) Message-ID: <63611.83.248.24.153.1143751658.squirrel@webmail.chalmers.se> In-Reply-To: <000201c65434$46b18730$6500a8c0@chalmers95a69n> References: <20060330165648.GI4777@ccil.org> <000201c65434$46b18730$6500a8c0@chalmers95a69n> Date: Thu, 30 Mar 2006 22:47:38 +0200 (CEST) Subject: RE: [Ltru] Less than a day to go for WG Last Call on matching draft From: "Kent Karlsson" To: ltru@ietf.org User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > Kent Karlsson scripsit: > > > "Subtags not specified, including those at the end of the language range, > > are thus treated as if assigned the wildcard value "*"." (and following > > examples). > > > > I think that wildcards must be explicit, possibly with the exception of > > final ones, but not internal ones. I see no reason for internal ones not > > to be explicit. > > As the word "thus" indicates, the statement to which you object is a > consequence of the algorithm as described, as you can see by > working out the details. > > Are you in fact objecting to the algorithm? The details of the algorithm paragraph you are referring to are unclear to me. But it is very likely that I object to it (if said consequence is really what falls out). But it seem to me that the "algorithm" totally ignores wildcards... Which is rather strange and objectionable... If the algorithm paragraph can be reformulated for clarity, the better. (You apparently did not like my way of claryfying it, actually talking about partial orders rather than *pretending* there isn't one.) /kent k _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 16:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4WJ-0002Nj-9E; Thu, 30 Mar 2006 16:17:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4WI-0002Ne-8s for ltru@ietf.org; Thu, 30 Mar 2006 16:17:30 -0500 Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP4WH-0008SU-1Y for ltru@ietf.org; Thu, 30 Mar 2006 16:17:30 -0500 Received: from h-68-165-6-39.snvacaid.dynamic.covad.net ([68.165.6.39] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FP4WG-0001vI-00 for ltru@ietf.org; Thu, 30 Mar 2006 16:17:28 -0500 Message-ID: <000501c6543f$c11cc9c0$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 30 Mar 2006 13:20:20 -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.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [Ltru] some editorial comments from Randy X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Here are a few editorial comments I have as a technical contributor on draft-ietf-ltru-matching-11.txt. I'll be sending technical comments separately. Editorial Old: Internet-Draft Yahoo! Inc New: Internet-Draft Yahoo! Inc. Editorial: Old: A "basic language range" describes a user's language preference as a specific, uninterrupted, sequence of subtags. Each range consists of a sequence of alphanumeric subtags separated by hyphens. The basic language range is defined by the following ABNF [RFC4234]: New: A "basic language range" consists of a sequence of alphanumeric subtags separated by hyphens. It is defined by the following ABNF [RFC4234]: Old: 'language-range': this is mentioned in the errata) New: (add a reference for the errata) Old: may not represent mutually intelligible languages. New: do not necessarily represent mutually intelligible languages. Old: [RFC2616errata] IETF, "HTTP/1.1 Specification Errata", 10 2004, . New: [RFC2616errata] IETF, "HTTP/1.1 Specification Errata", October 2004, . Old: [XML10] Bray (et al), T., "Extensible Markup Language (XML) 1.0", 02 2004. New: [XML10] Bray, T., et al., "Extensible Markup Language (XML) 1.0", February 2004. Old: Yahoo! Inc New: Yahoo! Inc. Old: Email: addison at inter dash locale dot com New: Email: addison@inter-locale.com Old: Email: mark dot davis at macchiato dot com New: Email: mark.davis@macchiato.com Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 16:34:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4mt-0000bx-Ae; Thu, 30 Mar 2006 16:34:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4ms-0000Zc-IN for ltru@ietf.org; Thu, 30 Mar 2006 16:34:38 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP4mr-0000oM-7N for ltru@ietf.org; Thu, 30 Mar 2006 16:34:38 -0500 Received: from duringpersonlx (wlanvpn-mc1-246-100.corp.yahoo.com [172.21.246.100]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2ULY0jn038044; Thu, 30 Mar 2006 13:34:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=XsANj0JmHp4syCZP700Wa46dsEyKtWFoN9u3GGPsFqvtqp3OukQESGFghBB4a9TF From: "Addison Phillips" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] some editorial comments from Randy Date: Thu, 30 Mar 2006 13:35:59 -0800 Message-ID: <001701c65441$efacbb40$f4fa15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000501c6543f$c11cc9c0$6401a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZUP2RbZVfHvKT+RBaY6M5JJXQIhgAATd9Q X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Comments follow. Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 2006=E5=B9=B43=E6=9C=8830=E6=97=A5 13:20 > To: LTRU Working Group > Subject: [Ltru] some editorial comments from Randy >=20 > Hi - >=20 > Here are a few editorial comments I have as a technical contributor > on draft-ietf-ltru-matching-11.txt. I'll be sending technical > comments separately. >=20 >=20 > Editorial > Old: > Internet-Draft Yahoo! = Inc > New: > Internet-Draft Yahoo! = Inc. Done. >=20 >=20 > Editorial: > Old: > A "basic language range" describes a user's language preference as = a > specific, uninterrupted, sequence of subtags. Each range consists = of > a sequence of alphanumeric subtags separated by hyphens. The basic > language range is defined by the following ABNF [RFC4234]: > New: > A "basic language range" consists of a sequence of alphanumeric = subtags > separated by hyphens. It is defined by the following ABNF = [RFC4234]: Done. >=20 >=20 > Old: > 'language-range': this is mentioned in the errata) > New: > (add a reference for the errata) Done. >=20 >=20 > Old: > may not represent mutually intelligible languages. > New: > do not necessarily represent mutually intelligible languages. Done. >=20 >=20 >=20 > Old: > [RFC2616errata] > IETF, "HTTP/1.1 Specification Errata", 10 2004, > . >=20 > New: > [RFC2616errata] > IETF, "HTTP/1.1 Specification Errata", October 2004, > . Done. >=20 > Old: > [XML10] Bray (et al), T., "Extensible Markup Language (XML) = 1.0", > 02 2004. > New: > [XML10] Bray, T., et al., "Extensible Markup Language (XML) = 1.0", > February 2004. Done. >=20 > Old: > Yahoo! Inc > New: > Yahoo! Inc. Done. Note this is generated from the same text as above. >=20 > Old: > Email: addison at inter dash locale dot com > New: > Email: addison@inter-locale.com Why? I get enough spam from scrapers. Mark's welcome to express his = opinion about his address. >=20 > Old: > Email: mark dot davis at macchiato dot com > New: > Email: mark.davis@macchiato.com >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 16:38:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4qJ-0002mQ-FH; Thu, 30 Mar 2006 16:38:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4qI-0002mL-1V for ltru@ietf.org; Thu, 30 Mar 2006 16:38:10 -0500 Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP4qH-0000x9-R2 for ltru@ietf.org; Thu, 30 Mar 2006 16:38:10 -0500 Received: from h-68-165-6-39.snvacaid.dynamic.covad.net ([68.165.6.39] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FP4qH-0006Tq-00 for ltru@ietf.org; Thu, 30 Mar 2006 16:38:09 -0500 Message-ID: <012401c65442$acc98320$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 30 Mar 2006 13:41:14 -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.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ltru] conformance requirements for matching X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a WG chair and as an I-D author / editor I know how frustrating very general comments can be, but, as a technical contributor, I think one is necessary in regard to the matching draft. Specifically, it is very unclear to me just what an implementation must do in order to conform to this specification. A protocol specification referencing this document needs to be able to specify (and parameterize) a matching algorithm sufficiently well to ensure interoperability. In its current form, it's not even clear how a protocol specification referencing this document is supposed to identify the portions of the matching specification it employs. I suggest providing a way for documents referencing this specification to clearly identify the algorithms to which they require conformance, along with any parameters and options. A related problem is the document's statement that "Implementations or protocols MAY use different matching schemes from the ones described in this document, as long as those mechanisms are clearly specified." Taken at face value, this means that ANY application doing language tag matching of some kind could claim conformnce to this specification, as long as whatever matching scheme it used was clearly specified. This would be absurd, and this text should be removed. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 17:12:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5NQ-0003FU-Re; Thu, 30 Mar 2006 17:12:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5NP-0003FK-Bb for ltru@ietf.org; Thu, 30 Mar 2006 17:12:23 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5NN-0002bV-Vn for ltru@ietf.org; Thu, 30 Mar 2006 17:12:23 -0500 Received: from duringpersonlx (wlanvpn-mc1-246-100.corp.yahoo.com [172.21.246.100]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2UMB5UU048956; Thu, 30 Mar 2006 14:11:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=IlD6CAAFJrx6QK1X9EM3utbQGnvHx6ZytppgvKgOL1gdt63P3ur9dEv9i1ELb8fF From: "Addison Phillips" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] conformance requirements for matching Date: Thu, 30 Mar 2006 14:12:58 -0800 Message-ID: <001901c65447$1b1b4120$f4fa15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <012401c65442$acc98320$6401a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZUQlP4TvPVfrGVSP+EAnb+97tprgAAVQOw X-Spam-Score: -15.0 (---------------) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > This would be absurd, and this text should be removed. I have no problem with removing that text. > In its current form, it's not even clear how a protocol specification > referencing this document is supposed to identify the portions of the > matching specification it employs. This I don't understand. There are three mechanisms. They are clearly = named and identified. What would you suggest we do differently in the = text to make implementation decisions clear?=20 There are clearly a large number of potential applications that can use = these schemes (ranging from language negotiation of web pages to = applying styles to paragraphs to selecting content in a database). The = actual protocol or application has to define how the scheme chosen works = in the context of this higher level application of matching. = Specifically, I'd refer you to Harald's comment: http://article.gmane.org/gmane.ietf.ltru/4180/match=3Dprotocol (The text suggested in this message appears in Section 3.1) Can you identify examples of what the problem is? I have no idea how we = would address this. > As a WG chair and as an I-D author / editor I know how frustrating > very general comments can be Yeah. And you saved one for the last day of the Last Call too :-). Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 2006=E5=B9=B43=E6=9C=8830=E6=97=A5 13:41 > To: LTRU Working Group > Subject: [Ltru] conformance requirements for matching >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 17:22:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5XH-0007aD-Io; Thu, 30 Mar 2006 17:22:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5XG-0007NM-1l for ltru@ietf.org; Thu, 30 Mar 2006 17:22:34 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5XE-0003GG-Ma for ltru@ietf.org; Thu, 30 Mar 2006 17:22:34 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FP5XD-0001PM-SW; Thu, 30 Mar 2006 17:22:31 -0500 Date: Thu, 30 Mar 2006 17:22:31 -0500 To: Kent Karlsson Subject: Re: [Ltru] Less than a day to go for WG Last Call on matching draft Message-ID: <20060330222231.GA30892@ccil.org> References: <20060330165648.GI4777@ccil.org> <000201c65434$46b18730$6500a8c0@chalmers95a69n> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000201c65434$46b18730$6500a8c0@chalmers95a69n> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Kent Karlsson scripsit: > If the algorithm paragraph can be reformulated for clarity, the better. > (You apparently did not like my way of claryfying it, actually talking > about partial orders rather than *pretending* there isn't one.) Here's my attempt: 1. A subtag in the extended language matches a subtag in the language tag if and only if they are the same when compared case-insensitively or the range's subtag is "*". 2. If the first subtag in the range does not match the first subtag in the tag, the overall match fails. Otherwise, remove the first subtags from both the range and the tag. 3. While there are more subtags left in the range: 3a. If the first remaining subtag in the range is "*", remove it and continue with the loop. 3b. Otherwise, if there are no more subtags in the tag, the match fails. 3c. Otherwise, compare the first remaining subtag in the range with the first remaining subtag in the tag. If they match, remove both of them and continue with the loop. 3d. Otherwise, if the tag's subtag is a "singleton" (a single letter or digit, which in this case includes the private-use subtag 'x') the match fails. 3e. Otherwise, remove the tag's subtag and continue with the loop. 4. When the range has no more subtags, the match succeeds. So it is indeed true that wildcard subtags and missing subtags are treated in the same way, except of course for the first subtag. Below is an extremely literal translation into Perl of the above pseudo-code. ============cut here============ #!/usr/bin/perl -w # Implement and test RFC 3066bis extended matching # John Cowan places this code in the public domain, but reserves # the moral right to be known as the author. use strict; # Subtag matching sub submatch { my ($subrange, $subtag) = @_; return 1 if $subrange eq "*"; $subrange = lc($subrange); $subtag = lc($subtag); return $subrange eq $subtag; } # Tag matching sub match { my ($range, $tag) = @_; my @range = split(/-/, $range); my @tag = split(/-/, $tag); return 0 unless submatch($range[0], $tag[0]); shift @range; shift @tag; while (@range) { if ($range[0] eq "*") { shift @range; } elsif (@tag == 0) { return 0; } elsif (submatch($range[0], $tag[0])) { shift @range; shift @tag; } elsif (length($tag[0]) == 1) { return 0; } else { shift @tag; } } return 1; } # Tag testing sub test { my ($range, $tag) = @_; print "Range $range ", match($range, $tag) ? "matches" : "does not match", " tag $tag\n"; } # Successes test("de-*-DE", "de-DE"); test("de-*-DE", "de-Latn-DE"); test("de-*-DE", "de-Latf-DE"); test("de-*-DE", "de-de"); test("de-*-DE", "de-DE-x-goethe"); test("de-*-DE", "de-Latn-DE-1996"); # Failures test("de-*-DE", "de"); test("de-*-DE", "de-x-DE"); test("de-*-DE", "de-Deva"); # Successes (no wildcard) test("de-DE", "de-DE"); test("de-DE", "de-Latn-DE"); test("de-DE", "de-Latf-DE"); test("de-DE", "de-de"); test("de-DE", "de-DE-x-goethe"); test("de-DE", "de-Latn-DE-1996"); # Failures (no wildcard) test("de-DE", "de"); test("de-DE", "de-x-DE"); test("de-DE", "de-Deva"); ============cut here============ -- Well, I have news for our current leaders John Cowan and the leaders of tomorrow: the Bill of cowan@ccil.org Rights is not a frivolous luxury, in force http://www.ccil.org/~cowan only during times of peace and prosperity. http://www.ap.org We don't just push it to the side when the going gets tough. --Molly Ivins _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 17:25:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5a9-0001bk-1t; Thu, 30 Mar 2006 17:25:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5a8-0001bG-Jt for ltru@ietf.org; Thu, 30 Mar 2006 17:25:32 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5a8-0003SL-7b for ltru@ietf.org; Thu, 30 Mar 2006 17:25:32 -0500 Received: from duringpersonlx (wlanvpn-mc1-246-100.corp.yahoo.com [172.21.246.100]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2UMOtun053034; Thu, 30 Mar 2006 14:24:55 -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=pllBvWwDbLKVQArChZeiyyLtUNtVHOYNaR669fXJbWChtucHS7fSIl9pfV1/h4RX From: "Addison Phillips" To: "'John Cowan'" , "'Doug Ewell'" Subject: RE: [Ltru] Re: WG last call for draft-ietf-ltru-matching Date: Thu, 30 Mar 2006 14:26:47 -0800 Message-ID: <001a01c65449$08545c50$f4fa15ac@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: <20060326050035.GY15284@ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZQkxnOoFKwT3GrTpqnQ3r0mjhekwDtE6AQ X-Spam-Score: -15.0 (---------------) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Comments follow. Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 2006?3?25? 21:01 > To: Doug Ewell > Cc: LTRU Working Group > Subject: Re: [Ltru] Re: WG last call for draft-ietf-ltru-matching > > Doug Ewell scripsit: > > > I note that proposals are still on the board to "pretty up" the text. > > There are more than 4,400 RFCs and I don't believe I have seen a single > > one with what I would consider "perfect" wording of every sentence. I > > would like to suggest that we have reached the point of diminishing > > returns, and that unless the meaning or expected interpretation of a > > passage is in doubt, getting this work finished should take precedence > > over further text beautification. > > Well, okay, then. I'll omit, as too trivial to mention, the ugly sequence > of two parenthesized clauses in the penultimate paragraph of Section 2.1. Okay. You failed to mention it and I'll fail to notice that both parentheticals are now removed. :-) > > But I think the SHOULD NOT in 2.2 just after Figure 2 ought not to be > capitalized (and maybe changed to "cannot"). Yes. Done. > > And the claim in 3.3 that an empty xml:lang attribute indicates that > the element it's on contains non-linguistic content is flat wrong. > And yes, I said that myself on this list. But it's still wrong. > It simply indicates that that element makes no declaration of language, > and is needed because a document without xml:lang may wind up embedded > inside a document that has xml:lang. ... and which makes no difference to the meaning. I removed the erroneous phrase thusly: -- with an empty language tag value, in cases where the protocol permits the empty value (see, for example, "xml:lang" in ) -- > > And in Section 4.1, the example in the 4th graf doesn't say whether it's > about filtering or lookup, though it needs to. And in the 6th graf, > the claim "Lookup implementations often ignore ..." is a factual one, > and needs to be changed unless it can be proved. The 4th graf was addressed by Martin's comment, I believe. I tend to agree with the second comment, although I note that the section on Lookup actually has a normative SHOULD recommending this. Might I suggest: -- Lookup implementations are advised to ignore unrecognized private-use and extension subtags when performing language tag fallback. -- Or we could just remove the sentence. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 17:26:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5b3-0002bW-3k; Thu, 30 Mar 2006 17:26:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5b2-0002am-8A for ltru@ietf.org; Thu, 30 Mar 2006 17:26:28 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5b2-0003T1-16 for ltru@ietf.org; Thu, 30 Mar 2006 17:26:28 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FP5b1-0001Tg-MR; Thu, 30 Mar 2006 17:26:27 -0500 Date: Thu, 30 Mar 2006 17:26:27 -0500 To: Kent Karlsson Subject: Re: [Ltru] Less than a day to go for WG Last Call on matching draft Message-ID: <20060330222627.GB30892@ccil.org> References: <20060330165648.GI4777@ccil.org> <000201c65434$46b18730$6500a8c0@chalmers95a69n> <20060330222231.GA30892@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060330222231.GA30892@ccil.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Scripsi: > Kent Karlsson scripsit: > > > If the algorithm paragraph can be reformulated for clarity, the better. > > (You apparently did not like my way of claryfying it, actually talking > > about partial orders rather than *pretending* there isn't one.) > > Here's my attempt: Addison and LTRUers: in case it's not obvious, this is a proposal for replacing the second and third paragraphs of 3.2.2. -- He played King Lear as though John Cowan someone had played the ace. http://www.ccil.org/~cowan --Eugene Field http://www.ap.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 17:31:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5fT-0004wT-RM; Thu, 30 Mar 2006 17:31:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5fT-0004wO-8f for ltru@ietf.org; Thu, 30 Mar 2006 17:31:03 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5fT-0003cC-1C for ltru@ietf.org; Thu, 30 Mar 2006 17:31:03 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FP5fS-0001YY-Nr; Thu, 30 Mar 2006 17:31:02 -0500 Date: Thu, 30 Mar 2006 17:31:02 -0500 To: Addison Phillips Subject: Re: [Ltru] Re: WG last call for draft-ietf-ltru-matching Message-ID: <20060330223102.GC30892@ccil.org> References: <20060326050035.GY15284@ccil.org> <001a01c65449$08545c50$f4fa15ac@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001a01c65449$08545c50$f4fa15ac@ds.corp.yahoo.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Okay. You failed to mention it and I'll fail to notice that both > parentheticals are now removed. :-) Ah, good. (This comes from Cicero's first oration against Cataline, where he is pointing out precedents for summary execution: "I omit, as too antiquated to mention, the case of X, who ...") > I tend to agree with the second comment, although I note that the section on > Lookup actually has a normative SHOULD recommending this. Might I suggest: > > -- > Lookup implementations are advised to ignore > unrecognized private-use and extension subtags when performing language tag > fallback. > -- > > Or we could just remove the sentence. "Advised" looks like a SHOULD, and as you say we already have one. Blow the sentence away, is my advice. -- First known example of political correctness: John Cowan After Nurhachi had united all the other http://www.ap.org Jurchen tribes under the leadership of the http://www.ccil.org/~cowan Manchus, his successor Abahai (1592-1643) cowan@ccil.org issued an order that the name Jurchen should --S. Robert Ramsey, be banned, and from then on, they were all The Languages of China to be called Manchus. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 17:31:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5gJ-00057u-0w; Thu, 30 Mar 2006 17:31:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5gI-00057p-4J for ltru@ietf.org; Thu, 30 Mar 2006 17:31:54 -0500 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5gH-0003dx-TL for ltru@ietf.org; Thu, 30 Mar 2006 17:31:54 -0500 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FP5gG-0001ZT-B5; Thu, 30 Mar 2006 17:31:53 -0500 Date: Thu, 30 Mar 2006 17:31:52 -0500 To: Randy Presuhn Subject: Re: [Ltru] conformance requirements for matching Message-ID: <20060330223152.GD30892@ccil.org> References: <012401c65442$acc98320$6401a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <012401c65442$acc98320$6401a8c0@oemcomputer> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn scripsit: > In its current form, it's not even clear how a protocol specification > referencing this document is supposed to identify the portions of the > matching specification it employs. I suggest providing a way for > documents referencing this specification to clearly identify the > algorithms to which they require conformance, along with any parameters > and options. I agree with Addison here: the names of the matching schemes suffice. -- John Cowan cowan@ccil.org www.ap.org www.ccil.org/~cowan Promises become binding when there is a meeting of the minds and consideration is exchanged. So it was at King's Bench in common law England; so it was under the common law in the American colonies; so it was through more than two centuries of jurisprudence in this country; and so it is today. --Specht v. Netscape _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 17:36:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5kQ-0007Xj-B7; Thu, 30 Mar 2006 17:36:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5kP-0007Xe-9k for ltru@ietf.org; Thu, 30 Mar 2006 17:36:09 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5kO-0003t6-Tx for ltru@ietf.org; Thu, 30 Mar 2006 17:36:09 -0500 Received: from duringpersonlx (wlanvpn-mc1-246-100.corp.yahoo.com [172.21.246.100]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2UMXs6V056304; Thu, 30 Mar 2006 14:33:54 -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=e7voQg3KZsNiC4vUIno0k8ZxfnZB0k+Zd3epKwBljEW8g1fHxl/bnQCdUVmF6Q3g From: "Addison Phillips" To: "'John Cowan'" , "'Kent Karlsson'" Subject: RE: [Ltru] Less than a day to go for WG Last Call on matching draft Date: Thu, 30 Mar 2006 14:35:46 -0800 Message-ID: <001c01c6544a$49c2bcd0$f4fa15ac@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: <20060330222627.GB30892@ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZUSQkuFmoj9rHkQdu/YFAi++DRGgAAOckA X-Spam-Score: -15.0 (---------------) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org It was clear to me. Seems better to enumerate it this way that as formless text. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 2006?3?30? 14:26 > To: Kent Karlsson > Cc: ltru@ietf.org > Subject: Re: [Ltru] Less than a day to go for WG Last Call on matching > draft > > Scripsi: > > > Kent Karlsson scripsit: > > > > > If the algorithm paragraph can be reformulated for clarity, the better. > > > (You apparently did not like my way of claryfying it, actually talking > > > about partial orders rather than *pretending* there isn't one.) > > > > Here's my attempt: > > Addison and LTRUers: in case it's not obvious, this is a proposal for > replacing > the second and third paragraphs of 3.2.2. > > -- > He played King Lear as though John Cowan > someone had played the ace. http://www.ccil.org/~cowan > --Eugene Field http://www.ap.org > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 17:43:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5rv-0001tv-49; Thu, 30 Mar 2006 17:43:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP5ru-0001tq-7O for ltru@ietf.org; Thu, 30 Mar 2006 17:43:54 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP5rs-0004Ab-RU for ltru@ietf.org; Thu, 30 Mar 2006 17:43:54 -0500 Received: from duringpersonlx (wlanvpn-mc1-246-100.corp.yahoo.com [172.21.246.100]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2UMhAp3059140; Thu, 30 Mar 2006 14:43:10 -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=qjw9fNTzd+Lw1gkrJ28ZLWW5SErbOjfo6McrLISQ5NHIyJFBLqe4/UGLrzokOB4z From: "Addison Phillips" To: "'John Cowan'" Subject: RE: [Ltru] Re: WG last call for draft-ietf-ltru-matching Date: Thu, 30 Mar 2006 14:45:01 -0800 Message-ID: <001d01c6544b$947ba790$f4fa15ac@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: <20060330223102.GC30892@ccil.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZUSax/ncnis+0cQG2UFFGGvm5f4gAALPng X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > "Advised" looks like a SHOULD, and as you say we already have one. Blow > the sentence away, is my advice. Would. But the previous sentence makes the missing content obvious. Perhaps: -- These subtags can interfere with Lookup, implementations of which are advised to ignore unrecognized private-use and extension subtags. -- Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 2006?3?30? 14:31 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: WG last call for draft-ietf-ltru-matching > > Addison Phillips scripsit: > > > Okay. You failed to mention it and I'll fail to notice that both > > parentheticals are now removed. :-) > > Ah, good. (This comes from Cicero's first oration against Cataline, > where he is pointing out precedents for summary execution: "I omit, > as too antiquated to mention, the case of X, who ...") > > > I tend to agree with the second comment, although I note that the > section on > > Lookup actually has a normative SHOULD recommending this. Might I > suggest: > > > > -- > > Lookup implementations are advised to > ignore > > unrecognized private-use and extension subtags when performing language > tag > > fallback. > > -- > > > > Or we could just remove the sentence. > > "Advised" looks like a SHOULD, and as you say we already have one. Blow > the sentence away, is my advice. > > -- > First known example of political correctness: John Cowan > After Nurhachi had united all the other http://www.ap.org > Jurchen tribes under the leadership of the http://www.ccil.org/~cowan > Manchus, his successor Abahai (1592-1643) cowan@ccil.org > issued an order that the name Jurchen should --S. Robert Ramsey, > be banned, and from then on, they were all The Languages of China > to be called Manchus. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 17:59:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP66p-0000y2-Ez; Thu, 30 Mar 2006 17:59:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP66o-0000xS-Dj for ltru@ietf.org; Thu, 30 Mar 2006 17:59:18 -0500 Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP66o-0004kP-5T for ltru@ietf.org; Thu, 30 Mar 2006 17:59:18 -0500 Received: from h-68-165-6-39.snvacaid.dynamic.covad.net ([68.165.6.39] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FP66n-00070A-00 for ltru@ietf.org; Thu, 30 Mar 2006 17:59:17 -0500 Message-ID: <008b01c6544e$030e7820$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 30 Mar 2006 15:02:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [Ltru] problematic SHOULDs in 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: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor... Background, RFC 2119 section 3: SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. Generally, the context of such a recommendation is the behaviour of a conformant implementation of the specification. If the specification gives operational guidelines, it may apply to users, but for protocols and algorithms the usage is normally limited to implementations of or other specifications using the specification in question. Consequently, several passages seem a bit problematic, in that they use such normative language to characterize behaviour of the user of an application. I don't want to be in the business of deciding whether users conform to the specification! :-) The following passages have problems with "SHOULD": Old: matching schemes. Use of one or more wildcards SHOULD NOT be taken to imply that a certain number of subtags will appear in the matching set of language tags. New: matching schemes. Use of one or more wildcards does not imply that a corresponding number of subtags will appear in the matching set of language tags. Old: Protocols and specifications SHOULD clearly indicate the particular mechanism used in selecting or matching language tags. New: Protocols and specifications requiring conformance to this specification MUST clearly indicate the particular mechanism used in selecting or matching language tags. Old: string processing. Users SHOULD select language ranges that are well-formed, valid language tags according to [RFC3066bis] (substituting wildcards as appropriate in extended language ranges). I'm not sure what to do about this. We shouldn't be talking about what happens at a user interface other than as an example. What are the bad things that happen if the language range isn't a well-formed, valid language tag? If nothing horrible happens, (an empty result does not qualify as horrible) then SHOULD is too strong anyway. Perhaps we should just delete everything in the paragraph after "processing." Old: Users SHOULD replace tags or subtags which have been deprecated with the Preferred-Value from the IANA Language Subtag Registry. If the This just seems wrong. In some ways, this is a kind of canonicalization, and as such should be part of the matching algorithm's specification (perhaps as a option) rather than a constraint on user behaviour. Alternatively, in the spirit of the rest of the paragraph, I could live with: New: Applications SHOULD use the Preferred-Value from the IANA Language Subtag Registry for tags or subtags which have been deprecated. If the Old: Users SHOULD avoid subtags that add no distinguishing value to a language range. When filtering, the fewer the number of subtags that This is not a question of interoperability. While sound advice, following this advice won't make an implementation any more or less conformant to the specification. I'm tempted to suggest moving all of this kind of material to a separate, non-normative section on "Practical guidelines for users of language matching algorithms" This one does deal with interoperability, but needs a little nudge to be in alignment with 3066bis: Old: Private-use subtags require private agreement between the parties that intend to use or exchange language tags that use them and great caution SHOULD be used in employing them in content or protocols intended for general use. Private-use subtags are simply useless for information exchange without prior arrangement. New: Private-use subtags require private agreement between the parties that intend to use or exchange language tags that use them. They SHOULD NOT be used in content or protocols intended for general use. Private-use subtags are simply useless for information exchange without prior arrangement. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 18:19:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP6QH-0002oF-Ub; Thu, 30 Mar 2006 18:19:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP6QH-0002oA-9Y for ltru@ietf.org; Thu, 30 Mar 2006 18:19:25 -0500 Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP6QH-0005bj-3A for ltru@ietf.org; Thu, 30 Mar 2006 18:19:25 -0500 Received: from h-68-165-6-39.snvacaid.dynamic.covad.net ([68.165.6.39] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FP6QG-0002i1-00 for ltru@ietf.org; Thu, 30 Mar 2006 18:19:24 -0500 Message-ID: <009a01c65450$d445d120$6401a8c0@oemcomputer> From: "Randy Presuhn" To: References: <012401c65442$acc98320$6401a8c0@oemcomputer> <20060330223152.GD30892@ccil.org> Subject: Re: [Ltru] conformance requirements for matching Date: Thu, 30 Mar 2006 15:22:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "John Cowan" > To: "Randy Presuhn" > Cc: > Sent: Thursday, March 30, 2006 2:31 PM > Subject: Re: [Ltru] conformance requirements for matching ... > I agree with Addison here: the names of the matching schemes suffice. ... Presumably "Basic Filtering", "Extended Filtering", and "Lookup"? Then the document should say that a conformant implementation MUST implement at least one of these three, and that a specification based on this one needs to identify it by the appropriate name. This still leaves the question of identifying their respective options or parameters. Four examples of behavioural options I was able to find just by looking for SHOULD and MAY in the text: Implementations that specify basic ranges MAY map extended language Implementations SHOULD ignore extensions and unrecognized private-use language ranges, it SHOULD be skipped. If the language range "*" is range follows, the default content SHOULD be returned. (BTW, talking about default "content" is really in the scope of an application using these algorithms, and should only be mentioned here as an example, if at all.) The combination of the SHOULD/MAYs with the three schemes gives quite a number of things to which implementations could claim conformance, and provides no guidance to the referencing specification to identifying which options are to be used. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 18:28:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP6Ye-0005pv-KG; Thu, 30 Mar 2006 18:28:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP6Yc-0005nI-Py for ltru@ietf.org; Thu, 30 Mar 2006 18:28:02 -0500 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP6Yc-000609-ED for ltru@ietf.org; Thu, 30 Mar 2006 18:28:02 -0500 Received: from duringpersonlx (wlanvpn-mc1-246-224.corp.yahoo.com [172.21.246.224]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k2UNRVuq073010; Thu, 30 Mar 2006 15:27:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=BOJhSttVLN38X1jOrpqmy+9oF7Su1AeOopM4Ii+QhvOTiOayggOB5u0jwvPo9QAX From: "Addison Phillips" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] problematic SHOULDs in matching draft Date: Thu, 30 Mar 2006 15:29:26 -0800 Message-ID: <002101c65451$c8c5d3d0$f4fa15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <008b01c6544e$030e7820$6401a8c0@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZUTaTBbRTU7VFgSbO3xU1yg6QnvwAAtZUg X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Comments follow. Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 2006=E5=B9=B43=E6=9C=8830=E6=97=A5 15:02 > To: LTRU Working Group > Subject: [Ltru] problematic SHOULDs in matching draft >=20 > Hi - >=20 >=20 > The following passages have problems with "SHOULD": >=20 > Old: > matching schemes. Use of one or more wildcards SHOULD NOT be taken > to imply that a certain number of subtags will appear in the = matching > set of language tags. This was already modified per another comment. >=20 >=20 > Old: > Protocols and specifications SHOULD clearly indicate the particular > mechanism used in selecting or matching language tags. >=20 > New: > Protocols and specifications requiring conformance to this > specification > MUST clearly indicate the particular mechanism used in selecting or > matching language tags. Done. >=20 >=20 > Old: > string processing. Users SHOULD select language ranges that are > well-formed, valid language tags according to [RFC3066bis] > (substituting wildcards as appropriate in extended language = ranges). >=20 > I'm not sure what to do about this. We shouldn't be talking about = what > happens at a user interface other than as an example. What are the = bad > things that happen if the language range isn't a well-formed, valid > language tag? If nothing horrible happens, (an empty result does not > qualify as horrible) then SHOULD is too strong anyway. Perhaps > we should just delete everything in the paragraph after "processing." We can remove the normative text. It could just as well read "Users = really ought to select..." >=20 >=20 >=20 > Old: > Users SHOULD replace tags or subtags which have been deprecated = with > the Preferred-Value from the IANA Language Subtag Registry. If the >=20 > This just seems wrong. In some ways, this is a kind of = canonicalization, > and as such should be part of the matching algorithm's specification > (perhaps as a option) rather than a constraint on user behaviour. > Alternatively, > in the spirit of the rest of the paragraph, I could live with: > New: > Applications SHOULD use the Preferred-Value from the IANA Language > Subtag Registry for tags or subtags which have been deprecated. If = the >=20 Done. >=20 >=20 > Old: > Users SHOULD avoid subtags that add no distinguishing value to a > language range. When filtering, the fewer the number of subtags = that > This is not a question of interoperability. While sound advice, = following > this advice won't make an implementation any more or less conformant = to > the > specification. I'm tempted to suggest moving all of this kind of = material > to a separate, non-normative section on "Practical guidelines for = users of > language matching algorithms" It IS in a separate section, which is called "Choosing Language Ranges", = which is in a separate ghettoized section containing only advice for = users. >=20 >=20 >=20 > This one does deal with interoperability, but needs a little nudge to = be > in alignment with 3066bis: > Old: > Private-use subtags require private agreement between the parties > that intend to use or exchange language tags that use them and = great > caution SHOULD be used in employing them in content or protocols > intended for general use. Private-use subtags are simply useless = for > information exchange without prior arrangement. >=20 > New: > Private-use subtags require private agreement between the parties > that intend to use or exchange language tags that use them. They > SHOULD NOT be used in content or protocols intended for general = use. > Private-use subtags are simply useless for information exchange > without prior arrangement. >=20 Done. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 18:43:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP6nM-0006JL-2T; Thu, 30 Mar 2006 18:43:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP6nL-0006IN-Be for ltru@ietf.org; Thu, 30 Mar 2006 18:43:15 -0500 Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP6nJ-0006g7-3T for ltru@ietf.org; Thu, 30 Mar 2006 18:43:15 -0500 Received: from h-68-165-6-39.snvacaid.dynamic.covad.net ([68.165.6.39] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FP6nH-00078i-00 for ltru@ietf.org; Thu, 30 Mar 2006 18:43:12 -0500 Message-ID: <00bd01c65454$26f1ba80$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "'LTRU Working Group'" References: <001901c65447$1b1b4120$f4fa15ac@ds.corp.yahoo.com> Subject: Re: [Ltru] conformance requirements for matching Date: Thu, 30 Mar 2006 15:46:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "'Randy Presuhn'" ; "'LTRU Working Group'" > Sent: Thursday, March 30, 2006 2:12 PM > Subject: RE: [Ltru] conformance requirements for matching ... > There are clearly a large number of potential applications that can use > these schemes (ranging from language negotiation of web pages to applying > styles to paragraphs to selecting content in a database). The actual > protocol or application has to define how the scheme chosen works in > the context of this higher level application of matching. Specifically, > I'd refer you to Harald's comment: > > http://article.gmane.org/gmane.ietf.ltru/4180/match=protocol I agree with Harald's comment. > (The text suggested in this message appears in Section 3.1) It the spirit of his comment were pursued rigorously, I think we'd have a much trimmer document with much clearer conformance requirements. > Can you identify examples of what the problem is? I have no idea how we would address this. See my other message on the MAY and SHOULDs that permit differing behaviour that could potentially affect interoperability. In general, any place where we permit variation in behaviour that could affect interoperability needs to be accounted for in the list of options. We have a few ways to get rid of the complexity, which we can employ alone or in combination to keep the conformance requirements clear and avoid complexity: (1) define the difference in results as non-significant (implementations MUST NOT depend on the difference) (2) get rid of the option by making a particular choice mandatory (3) get rid of the option by making it the responsibility of something else, e.g., the application or protocol using the matching algorithm Harald's suggested text uses technique (3). > > As a WG chair and as an I-D author / editor I know how frustrating > > very general comments can be > > Yeah. And you saved one for the last day of the Last Call too :-). This issue has been around for a while (as Harald's message attests). It's better to get the comment from me, now, than from an AD, the IESG, or in IETF last call. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Mar 30 21:56:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP9o5-0008HT-OU; Thu, 30 Mar 2006 21:56:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP9o4-0008Go-TQ for ltru@ietf.org; Thu, 30 Mar 2006 21:56:12 -0500 Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP9o3-0007Bb-MV for ltru@ietf.org; Thu, 30 Mar 2006 21:56:12 -0500 Received: from h-68-165-6-39.snvacaid.dynamic.covad.net ([68.165.6.39] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FP9o2-0002EX-00 for ltru@ietf.org; Thu, 30 Mar 2006 21:56:10 -0500 Message-ID: <000401c6546f$1caadaa0$6401a8c0@oemcomputer> From: "Randy Presuhn" To: "'LTRU Working Group'" References: <002101c65451$c8c5d3d0$f4fa15ac@ds.corp.yahoo.com> Subject: Re: [Ltru] problematic SHOULDs in matching draft Date: Thu, 30 Mar 2006 18:59:21 -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.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Addison Phillips" > To: "'Randy Presuhn'" ; "'LTRU Working Group'" > Sent: Thursday, March 30, 2006 3:29 PM > Subject: RE: [Ltru] problematic SHOULDs in matching draft ... > > Old: > > Users SHOULD avoid subtags that add no distinguishing value to a > > language range. When filtering, the fewer the number of subtags that > > This is not a question of interoperability. While sound advice, following > > this advice won't make an implementation any more or less conformant to > > the > > specification. I'm tempted to suggest moving all of this kind of material > > to a separate, non-normative section on "Practical guidelines for users of > > language matching algorithms" > > It IS in a separate section, which is called "Choosing Language Ranges", > which is in a separate ghettoized section containing only advice for users. ... That intent wasn't clear to me. That section (4.1) also has two paragraphs (the last two) that are clearly in terms of applications and protocols, and have normative material in them that would impact interoperability. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 31 19:28:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPTyZ-0002jr-B4; Fri, 31 Mar 2006 19:28:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPTyY-0002ic-Hv for ltru@ietf.org; Fri, 31 Mar 2006 19:28:22 -0500 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPTyX-00084i-A1 for ltru@ietf.org; Fri, 31 Mar 2006 19:28:22 -0500 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k310S6GO094524; Fri, 31 Mar 2006 16:28:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; b=RXOTD4Vc5/KXv/h+Kn4PjJSobaStfD8rAdKxLEykdoY/SYuQv7tt7WZD3IXiSQ1U From: "Addison Phillips" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] conformance requirements for matching Date: Fri, 31 Mar 2006 16:30:04 -0800 Message-ID: <005001c65523$6bf62e70$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-reply-to: <00bd01c65454$26f1ba80$6401a8c0@oemcomputer> Thread-index: AcZUU8RbssO7NzPlRXWIabVB77wXXgALSLOA X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > This issue has been around for a while (as Harald's message attests). > It's better to get the comment from me, now, than from an AD, the = IESG, > or in IETF last call. Yes, I hear you. And I don't disagree with your reasoning. If the point = is to generally describe some matching schemes, I think we long ago = achieved our purposes. If our goal is a thorough specification, then = your comments are probably correct. The problem is being specific about = implementation details (particularly in lookup) in areas in which the = choice is not clear cut. I've posted a new editor's copy, mid-stream in a rewrite of the extended = filtering section, but with a number of your suggested changes (plus = some additional editing to remove waffle from the Lookup and "choosing" = sections). I have not dealt with the last two paras of Section 4.1 yet. = Specific advice on wording is most appreciated. Of particular concern if we go down this track: 1. In Section 3.1 (Choosing a Type of Matching), we permit = implementations to not enforce validity/well-formedness on tags or = ranges. My first inclination was to require this ("MUST NOT depend on = valid/well-formed") for ranges, but the following text provides problems = for this: 2. In the following paragraph, we permit implementations to canonicalize = ranges/tags and to use external information ('nb'->'no', for example) to = "inform" the choices made in matching. This is the exact opposite of #1, = since canonicalization requires the registry and presumably a validating = processor. I think the answer here is: a. MUST NOT depend on valid/well-formed ranges b. if validity checking is done, MUST canonicalize c. whether or not validity checking is done, MAY use external = information (RFC2616 already suggests that this is permitted) 3. Section 3.3 (Lookup) has a fair bit of waffle about the handling of = default content. This could all be removed by replacing the last = sentence in the first paragraph with a new paragraph: "If no content matches the request, the "default" content is returned. = The application, protocol, or specification MUST specify the default = content for a request, which MAY include returning an error condition, = such as "not found"." We can then tighten up the remaining content about default handling = (implementations can still choose what the default content is, including = having a default language). Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: 2006=E5=B9=B43=E6=9C=8830=E6=97=A5 15:46 > To: 'LTRU Working Group' > Subject: Re: [Ltru] conformance requirements for matching >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 31 22:06:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPWRi-00045A-7T; Fri, 31 Mar 2006 22:06:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPWRg-0003zn-Et for ltru@ietf.org; Fri, 31 Mar 2006 22:06:36 -0500 Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FPWRf-0006n0-6r for ltru@ietf.org; Fri, 31 Mar 2006 22:06:36 -0500 Received: (qmail 81826 invoked from network); 1 Apr 2006 03:06:34 -0000 Received: from unknown (HELO ?172.19.9.78?) (unknown) by unknown with SMTP; 1 Apr 2006 03:06:34 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <442DEE35.80804@icu-project.org> Date: Fri, 31 Mar 2006 19:06:29 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] some editorial comments from Randy References: <001701c65441$efacbb40$f4fa15ac@ds.corp.yahoo.com> In-Reply-To: <001701c65441$efacbb40$f4fa15ac@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org mark.davis@macchiato.com I don't mind scrapers; with a whitelist and *extremely* aggressive spam filters I'm not bothered much. Mark Addison Phillips wrote: > Comments follow. > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > >> -----Original Message----- >> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >> Sent: 2006年3月30日 13:20 >> To: LTRU Working Group >> Subject: [Ltru] some editorial comments from Randy >> >> Hi - >> >> Here are a few editorial comments I have as a technical contributor >> on draft-ietf-ltru-matching-11.txt. I'll be sending technical >> comments separately. >> >> >> Editorial >> Old: >> Internet-Draft Yahoo! Inc >> New: >> Internet-Draft Yahoo! Inc. >> > > Done. > >> Editorial: >> Old: >> A "basic language range" describes a user's language preference as a >> specific, uninterrupted, sequence of subtags. Each range consists of >> a sequence of alphanumeric subtags separated by hyphens. The basic >> language range is defined by the following ABNF [RFC4234]: >> New: >> A "basic language range" consists of a sequence of alphanumeric subtags >> separated by hyphens. It is defined by the following ABNF [RFC4234]: >> > > Done. > >> Old: >> 'language-range': this is mentioned in the errata) >> New: >> (add a reference for the errata) >> > > Done. > >> Old: >> may not represent mutually intelligible languages. >> New: >> do not necessarily represent mutually intelligible languages. >> > > Done. > >> >> Old: >> [RFC2616errata] >> IETF, "HTTP/1.1 Specification Errata", 10 2004, >> . >> >> New: >> [RFC2616errata] >> IETF, "HTTP/1.1 Specification Errata", October 2004, >> . >> > > Done. > >> Old: >> [XML10] Bray (et al), T., "Extensible Markup Language (XML) 1.0", >> 02 2004. >> New: >> [XML10] Bray, T., et al., "Extensible Markup Language (XML) 1.0", >> February 2004. >> > > > Done. > >> Old: >> Yahoo! Inc >> New: >> Yahoo! Inc. >> > > Done. Note this is generated from the same text as above. > >> Old: >> Email: addison at inter dash locale dot com >> New: >> Email: addison@inter-locale.com >> > > > Why? I get enough spam from scrapers. Mark's welcome to express his opinion about his address. > > >> Old: >> Email: mark dot davis at macchiato dot com >> New: >> Email: mark.davis@macchiato.com >> >> > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 31 22:16:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPWav-0007hz-A5; Fri, 31 Mar 2006 22:16:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPWau-0007hu-ML for ltru@ietf.org; Fri, 31 Mar 2006 22:16:08 -0500 Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FPWat-0007Jo-Da for ltru@ietf.org; Fri, 31 Mar 2006 22:16:08 -0500 Received: (qmail 82949 invoked from network); 1 Apr 2006 03:16:06 -0000 Received: from unknown (HELO ?172.19.9.78?) (unknown) by unknown with SMTP; 1 Apr 2006 03:16:06 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <442DF074.4010107@icu-project.org> Date: Fri, 31 Mar 2006 19:16:04 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] conformance requirements for matching References: <001901c65447$1b1b4120$f4fa15ac@ds.corp.yahoo.com> In-Reply-To: <001901c65447$1b1b4120$f4fa15ac@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I disagree with the wholesale removal. I think it is perfectly reasonable for someone to claim conformance with additional qualifications. That is done in quite a few other specifications. For example, I think it is perfectly reasonable to state the following. The implementation is conformant to RFC xxx Lookup, with the following extensions: - default content matches the default locale as specified in setDefaultLocale() - closely related variants, such as no, nn, nb, fallback to each other first, before resorting to the default content. The exact mapping is found with getVariantFallbacks(). Mark Addison Phillips wrote: >> This would be absurd, and this text should be removed. >> > > I have no problem with removing that text. > > >> In its current form, it's not even clear how a protocol specification >> referencing this document is supposed to identify the portions of the >> matching specification it employs. >> > > This I don't understand. There are three mechanisms. They are clearly named and identified. What would you suggest we do differently in the text to make implementation decisions clear? > > There are clearly a large number of potential applications that can use these schemes (ranging from language negotiation of web pages to applying styles to paragraphs to selecting content in a database). The actual protocol or application has to define how the scheme chosen works in the context of this higher level application of matching. Specifically, I'd refer you to Harald's comment: > > http://article.gmane.org/gmane.ietf.ltru/4180/match=protocol > > (The text suggested in this message appears in Section 3.1) > > Can you identify examples of what the problem is? I have no idea how we would address this. > > >> As a WG chair and as an I-D author / editor I know how frustrating >> very general comments can be >> > > Yeah. And you saved one for the last day of the Last Call too :-). > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > >> -----Original Message----- >> From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >> Sent: 2006年3月30日 13:41 >> To: LTRU Working Group >> Subject: [Ltru] conformance requirements for matching >> >> > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Mar 31 22:17:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPWbz-0008Lr-HG; Fri, 31 Mar 2006 22:17:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPWby-0008Lm-E5 for ltru@ietf.org; Fri, 31 Mar 2006 22:17:14 -0500 Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FPWbx-0007Qq-6v for ltru@ietf.org; Fri, 31 Mar 2006 22:17:14 -0500 Received: (qmail 83148 invoked from network); 1 Apr 2006 03:17:12 -0000 Received: from unknown (HELO ?172.19.9.78?) (unknown) by unknown with SMTP; 1 Apr 2006 03:17:12 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <442DF0B7.3040302@icu-project.org> Date: Fri, 31 Mar 2006 19:17:11 -0800 From: Mark Davis User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Addison Phillips Subject: Re: [Ltru] Re: WG last call for draft-ietf-ltru-matching References: <001a01c65449$08545c50$f4fa15ac@ds.corp.yahoo.com> In-Reply-To: <001a01c65449$08545c50$f4fa15ac@ds.corp.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 'Doug Ewell' , 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org +1 > > I tend to agree with the second comment, although I note that the section on > Lookup actually has a normative SHOULD recommending this. Might I suggest: > > -- > Lookup implementations are advised to ignore > unrecognized private-use and extension subtags when performing language tag > fallback. > -- > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru