From ltru-bounces@ietf.org Mon May 01 14:58:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FadbA-0003Un-66; Mon, 01 May 2006 14:58:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fadb8-0003Sq-Rp; Mon, 01 May 2006 14:58:18 -0400 Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fadb6-0007NR-KP; Mon, 01 May 2006 14:58:18 -0400 Received: from h-68-165-6-72.snvacaid.dynamic.covad.net ([68.165.6.72] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Fadb6-0000hk-00; Mon, 01 May 2006 14:58:16 -0400 Message-ID: <001901c66d51$d3b6f800$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "Disman" , "LTRU Working Group" Date: Mon, 1 May 2006 12:02:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Ltru] Fw: IETF Meeting Survey X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 - forwarded for your information, in the hope of improving future IETF meeting experiences... Randy > From: "Ray Pelletier" > To: > Sent: Monday, May 01, 2006 8:24 AM > Subject: IETF Meeting Survey > > All; > It has been suggested that if I really wanted to get feedback on the > Meeting Survey (and I do) I should have it forwarded by the WG Chairs > to the working groups - so this is a request that you ask members of the > working groups to complete a short survey that focuses primarily, but > not exclusively, on their meeting experience in Dallas. > > I truly want the info to make the changes members of the community want, > if possible and greatly appreciate your assistance in this regard. > > Those interested in taking the survey can find it at: > http://www.surveymonkey.com/s.asp?u=649182049947 > > Thanks > Ray Pelletier > IETF Admininstrative Director > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon May 01 18:15:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fagg0-0007V5-Gx; Mon, 01 May 2006 18:15:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fagfz-0007V0-CX for ltru@ietf.org; Mon, 01 May 2006 18:15:31 -0400 Received: from mail1.microsoft.com ([131.107.1.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fagfw-0007lM-3m for ltru@ietf.org; Mon, 01 May 2006 18:15:31 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 15:15:27 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.150]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 15:15:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Fwd: LTRU Milestones past due (matching draft to IETFLast Call) Date: Mon, 1 May 2006 15:15:22 -0700 Message-ID: In-Reply-To: <006301c66822$b733a630$040aa8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: Fwd: LTRU Milestones past due (matching draft to IETFLast Call) Thread-Index: AcZoIsvQM9oI8TfESliH/bcbMv9bTAFRIyJg From: "Peter Constable" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 01 May 2006 22:15:27.0257 (UTC) FILETIME=[C00C6090:01C66D6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0335425378==" Errors-To: ltru-bounces@ietf.org --===============0335425378== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBEb3VnIEV3ZWxsIFttYWlsdG86ZGV3ZWxsQGFkZWxwaGlhLm5ldF0NCg0KPiBNYXJr IERhdmlzIGFuZCBJIGhhdmUgYmVlbiBhc2tpbmcgdG8gaGF2ZSBkcmFmdC1tYXRjaGluZyBhZHZh bmNlZCB0byBXRw0KPiBMYXN0IENhbGwgZm9yIGEgZmV3IHdlZWtzIG5vdywgd2l0aCBubyByZXNw b25zZS4gIE5vIGFkZGl0aW9uYWwgY29tbWVudHMNCj4gaGF2ZSBhcHBlYXJlZCBvbiB0aGUgbGlz dCBzaW5jZSBBZGRpc29uIHN1Ym1pdHRlZCBkcmFmdC1tYXRjaGluZy0xMiBvbg0KPiBBcHJpbCA2 LiAgV2l0aG91dCB0aGlzIGRlbGF5LCB3ZSBtaWdodCBoYXZlIGJlZW4gYWJsZSB0byBoaXQgdGhl IGVuZCBvZg0KPiBBcHJpbC4NCg0KRm9yIG15IHBhcnQsIEkgYW0gZmluYWxseSB3b3JraW5nIG9u IHByZXBhcmluZyB0aGUgdGV4dCBmb3IgSVNPL0ZESVMgNjM5LTMsIGFuZCBJIGhhdmUgdG8gZmln dXJlIG91dCB3aGF0IHRvIGRvIHdpdGggYSByZWZlcmVuY2UgdG8gUkZDIDMwNjZiaXMuIFdoZW4g SSBwcmVwYXJlZCB0aGUgRElTIHRleHQgaW4gU2VwdGVtYmVyIDIwMDQsIEkgaGFkIGEgcmVmZXJl bmNlIHRvIDMwNjZiaXMgd2l0aCBhIG5vdGUgdG8gbXlzZWxmICJ1cGRhdGUgcmVmZXJlbmNlIG9u Y2UgZmluYWwgUkZDIGhhcyBiZWVuIHB1Ymxpc2hlZC4iIEkgYXNzdW1lZCB3aGVuIEkgd3JvdGUg dGhhdCB0aGF0IHRoZSBmaW5hbCBSRkMgd291bGQgaGF2ZSBiZWVuIHB1Ymxpc2hlZCB3aXRoaW4g dGhlIG5leHQgMTIgbW9udGhzLCBidXQgaGVyZSBpdCBpcyAxOCBtb250aHMgbGF0ZXIuIFJlZmVy ZW5jaW5nIHRoZSBpbnRlcm5ldCBkcmFmdCBvbiB0aGUgSUVURiBzaXRlIGlzbid0IHJlYWxseSBz YXRpc2Z5aW5nOiBpdCdzIG5vdCBpbnRlbmRlZCBhcyBhIGxvbmctdGVybSByZWZlcmVuY2UsIGl0 IGRvZXNuJ3QgcmVmbGVjdCB0aGF0IHRoZSBkb2MgaGFzIGJlZW4gYXBwcm92ZWQsIGFuZCB0aGUg ZHJhZnQgaGFzIGFuIGV4cGlyYXRpb24gZGF0ZSBvZiBBcHJpbCAxNyAtLSBpdCBoYXMgZXhwaXJl ZCENCg== --===============0335425378== 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 --===============0335425378==-- From ltru-bounces@ietf.org Mon May 01 19:56:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaiFI-00069f-OR; Mon, 01 May 2006 19:56:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaiFH-00069a-5j for ltru@ietf.org; Mon, 01 May 2006 19:56:03 -0400 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaiFF-0004ba-U2 for ltru@ietf.org; Mon, 01 May 2006 19:56:03 -0400 Received: from h-68-165-6-72.snvacaid.dynamic.covad.net ([68.165.6.72] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FaiFD-0002DJ-00 for ltru@ietf.org; Mon, 01 May 2006 19:55:59 -0400 Message-ID: <02f601c66d7b$6a4130a0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: Fwd: LTRU Milestones past due (matching draft toIETFLast Call) Date: Mon, 1 May 2006 17:00:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - It has *not* expired. The registry-related drafts are in the RFC editor queue. Documents in the RFC editor queue do not expire. Randy, ltru co-chair ----- Original Message ----- > From: "Peter Constable" > To: "Doug Ewell" ; "LTRU Working Group" > Sent: Monday, May 01, 2006 3:15 PM > Subject: RE: [Ltru] Re: Fwd: LTRU Milestones past due (matching draft toIETFLast Call) > > > From: Doug Ewell [mailto:dewell@adelphia.net] > > > Mark Davis and I have been asking to have draft-matching advanced to WG > > Last Call for a few weeks now, with no response. No additional comments > > have appeared on the list since Addison submitted draft-matching-12 on > > April 6. Without this delay, we might have been able to hit the end of > > April. > > For my part, I am finally working on preparing the text for ISO/FDIS 639-3, and I have to figure out what to do with a reference to RFC 3066bis. When I prepared the DIS text in September 2004, I had a reference to 3066bis with a note to myself "update reference once final RFC has been published." I assumed when I wrote that that the final RFC would have been published within the next 12 months, but here it is 18 months later. Referencing the internet draft on the IETF site isn't really satisfying: it's not intended as a long-term reference, it doesn't reflect that the doc has been approved, and the draft has an expiration date of April 17 -- it has expired! > -------------------------------------------------------------------------------- > _______________________________________________ > 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 May 02 06:20:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Farzd-0004Nf-1B; Tue, 02 May 2006 06:20:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Farzb-0004Na-R7 for ltru@ietf.org; Tue, 02 May 2006 06:20:31 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FarzZ-0003Nl-7W for ltru@ietf.org; Tue, 02 May 2006 06:20:31 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k42AKRZI021198 for ; Tue, 2 May 2006 19:20:27 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 03c6_4665326a_d9c5_11da_8644_0014221f2a2d; Tue, 02 May 2006 19:20:26 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k42AJVgf024642 for ; Tue, 2 May 2006 19:20:02 +0900 Message-Id: <6.0.0.20.2.20060502185911.099e0c10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 02 May 2006 19:17:59 +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: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ltru] 2nd 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 Dear LTRU WG, Many of you have expected a Second WG Last Call, and here it is. Sorry for the delay due to personal reasons. I have looked through the discussion of the previous last call, and tried to keep track of everything at http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. If somebody thinks something is missing (or wrong), or would like some details to be added, or has some questions, please tell me. The substantive changes require another WG Last Call. The duration of this Last Call is two (2) weeks, it will end on Tuesday, May 16, 11:00 UTC (20:00 Japan, 13:00 France,..., 4:00am US Pacific, and so on). Please read the draft at http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt carefully and send in comments, with a subject indicating the issue. Please also send in a comment if you have read the draft and haven't found any issue. If you have read earlier drafts, please note that this draft is a serious revision, better read on its own. I hope that this time, we can successfully complete this last call and send the draft to the IESG. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 02 14:08:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazIU-0002F7-DO; Tue, 02 May 2006 14:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazIS-0002F2-K0 for ltru@ietf.org; Tue, 02 May 2006 14:08:28 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazIS-0007kX-61 for ltru@ietf.org; Tue, 02 May 2006 14:08:28 -0400 Received: from localhost (localhost [127.0.0.1]) by mail2.sharplabs.com (Postfix) with ESMTP id 3A3001E1373; Tue, 2 May 2006 11:08:27 -0700 (PDT) Received: from mail2.sharplabs.com ([127.0.0.1]) by localhost (mail2.sharplabs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16210-09; Tue, 2 May 2006 11:08:23 -0700 (PDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 327AF1E133F; Tue, 2 May 2006 11:08:23 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 2 May 2006 11:08:23 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EDF7@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Randy Presuhn' , LTRU Working Group Subject: RE: [Ltru] Re: Fwd: LTRU Milestones past due (matching draft toIE TFLast Call) Date: Tue, 2 May 2006 11:08:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Virus-Scanned: amavisd-new at sharplabs.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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 Randy, Although I've been repeatedly assured over the years that I-Ds in the RFC Editor's queue don't "expire", nothing in the compulsory boilerplate on an I-D and nothing at the Internet-Drafts repository _tells_ me that. The literal text says it's expired. Lousy I-D boilerplate if you ask me. 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: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Monday, May 01, 2006 8:00 PM > To: LTRU Working Group > Subject: Re: [Ltru] Re: Fwd: LTRU Milestones past due (matching draft > toIETFLast Call) > > > Hi - > > It has *not* expired. The registry-related drafts are in the > RFC editor queue. > Documents in the RFC editor queue do not expire. > > Randy, ltru co-chair > > ----- Original Message ----- > > From: "Peter Constable" > > To: "Doug Ewell" ; "LTRU Working > Group" > > Sent: Monday, May 01, 2006 3:15 PM > > Subject: RE: [Ltru] Re: Fwd: LTRU Milestones past due > (matching draft toIETFLast Call) > > > > > From: Doug Ewell [mailto:dewell@adelphia.net] > > > > > Mark Davis and I have been asking to have draft-matching > advanced to WG > > > Last Call for a few weeks now, with no response. No > additional comments > > > have appeared on the list since Addison submitted > draft-matching-12 on > > > April 6. Without this delay, we might have been able to > hit the end of > > > April. > > > > For my part, I am finally working on preparing the text for > ISO/FDIS 639-3, and I have to figure out what to do with a reference > to RFC 3066bis. When I prepared the DIS text in September > 2004, I had a reference to 3066bis with a note to myself > "update reference > once final RFC has been published." I assumed when I wrote > that that the final RFC would have been published within the next 12 > months, but here it is 18 months later. Referencing the > internet draft on the IETF site isn't really satisfying: it's > not intended > as a long-term reference, it doesn't reflect that the doc has > been approved, and the draft has an expiration date of April 17 -- it > has expired! > > > > > -------------------------------------------------------------- > ------------------ > > > > _______________________________________________ > > 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.5.2/329 - Release > Date: 5/2/2006 > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.5.2/329 - Release Date: 5/2/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 02 15:30:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0ZY-0001lq-Ge; Tue, 02 May 2006 15:30:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb0ZX-0001ll-Hi for ltru@ietf.org; Tue, 02 May 2006 15:30:11 -0400 Received: from mrout3.yahoo.com ([216.145.54.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb0ZU-0002eN-3Y for ltru@ietf.org; Tue, 02 May 2006 15:30:11 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout3.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k42JTQd9014110; Tue, 2 May 2006 12:29:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:thread-index:x-mimeole:in-reply-to; b=eyVsId1GkMxHZlS//Nnr2BOPRn4DvkvJAcsNG2hRzLzl2YevJlRMvCHlJIrphHsz From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] 2nd WG Last Call for draft-ietf-ltru-matching Date: Tue, 2 May 2006 12:29:26 -0700 Message-ID: <000201c66e1e$b9d89150$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcZt0g+qFAOddXpWTH+NyPl11Z1StQAS7m3Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <6.0.0.20.2.20060502185911.099e0c10@localhost> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All, Martin has asked me to enumerate the differences (comments received since draft-12 was created) that are already incorporated into draft-13. This is straightforward: Debbie Garside sent me a small number of editorial comments in a paragraph on page 9. This paragraph used to say: --- Applications, protocols, or specifications, in addressing their particular requirements, can offer pre-processing or configuration options. For example, an implementation could allow a user to associate or map a particular language range to a different value. Such a user might wish to associate the language range subtags 'nn' (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) with the more general subtag 'no' (Norwegian). Or perhaps the user could associate the range "zh-Hans" (Chinese as written in the Simplified script) with the language tag "zh-CN" (Chinese as used in China, where the Simplified script is predominant) because content is available with that tag. Documentation on how the ranges or tags are altered, prioritized, or compared in the subsequent match in such an implementation will assist users in making the best configuration choices. --- The changes are in the last two sentences, making the bottom part of the graf read: --- Or perhaps a user would want to associate requests for the range "zh-Hans" (Chinese as written in the Simplified script) with content bearing the language tag "zh-CN" (Chinese as used in China, where the Simplified script is predominant). Documentation on how the ranges or tags are altered, prioritized, or compared in the subsequent match in such an implementation will assist users in making these types of configuration choices. --- 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?5?2? 3:18 > To: LTRU Working Group > Subject: [Ltru] 2nd WG Last Call for draft-ietf-ltru-matching > > Dear LTRU WG, > > Many of you have expected a Second WG Last Call, and here it is. > Sorry for the delay due to personal reasons. > > I have looked through the discussion of the previous last call, > and tried to keep track of everything at > http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. > If somebody thinks something is missing (or wrong), or would like > some details to be added, or has some questions, please tell me. > The substantive changes require another WG Last Call. > > The duration of this Last Call is two (2) weeks, it will end on > Tuesday, May 16, 11:00 UTC (20:00 Japan, 13:00 France,..., > 4:00am US Pacific, and so on). > > Please read the draft at > http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt > carefully and send in comments, with a subject indicating > the issue. Please also send in a comment if you have read the > draft and haven't found any issue. > > If you have read earlier drafts, please note that this draft > is a serious revision, better read on its own. > > I hope that this time, we can successfully complete this last call > and send the draft to the IESG. > > > 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 May 04 01:02:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbVyl-0001TO-I8; Thu, 04 May 2006 01:02:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbVyl-0001Sg-0y for ltru@ietf.org; Thu, 04 May 2006 01:02:19 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbVyi-0006XR-M3 for ltru@ietf.org; Thu, 04 May 2006 01:02:19 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FbVyf-0007xh-Ob; Thu, 04 May 2006 01:02:13 -0400 Date: Thu, 4 May 2006 01:02:13 -0400 To: Martin Duerst Subject: Re: [Ltru] 2nd WG Last Call for draft-ietf-ltru-matching Message-ID: <20060504050213.GC527@ccil.org> References: <6.0.0.20.2.20060502185911.099e0c10@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060502185911.099e0c10@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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: > Please read the draft at > http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt > carefully and send in comments, with a subject indicating > the issue. Please also send in a comment if you have read the > draft and haven't found any issue. Here are my comments, all editorial in nature: 1. In Section 2.1, the first sentence of the first graf and the first sentence of the second graf are overlapping and partly contradictory. I suggest changing the first to: A "basic language range" (originally described by HTTP/1.1 [RFC 2616] and later [RFC 3066bis] has the same syntax as an [RFC 3066bis] language tag or is the single character "*". and removing the first sentence of the second graf altogether, but expanding the following pronoun "They" to "Basic language ranges" for clarity. 2. In Section 2.2, for "useful in specifying" read "useful for specifying". 3. In Section 3, the second graf is redundant and confuses the number of matching schemes with the number of *types* of matching schemes. I suggest it be removed in favor of changes to Section 3.1 following. 4. In Section 3.1, for "types of matching" read "matching schemes", and append "and returns zero or more matching language tags" to list entries 1 and 2. 5. In Section 3.3.1, replace the first sentenc with "Basic filtering compares basic language ranges to language tags", for conformity wiht Section 3.3.2. 6. In Section 3.3.2, last graf, the words "One such difference is that" don't seem to serve any purpose; I suggest they be removed. 7. In Section 3.4, last graf, I suggest swapping the last two sentences, with the exception of the words "For example" and "Another possibility" which should be left in place. 8. In Section 3.4.1, after "specification" insert "that uses lookup" for clarity. 9. In Section 3.4.1, the bullet list is a random mixture of tags the algorithm might return as defaults, and the actions that the calling application might take as a result. I suggest these be split more or less as follows: Some possible examples of default results are: * return a particular language tag designated for the operation * return a null string as a language tag value, in cases where the protocol permits the empty value (yada yada) * return the language tag "i-default" (see [RFC 2277]) * return an error condition or error message In turn, the application, protocol, or specification may choose to: * return an item with no language tag (yada yada) * return a list of available languages for the user to select from 10. In Section 4.4. for "that apply" read "that can be applied" and for "can also apply" read "can also be applied". -- John Cowan http://ccil.org/~cowan cowan@ccil.org Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, The day and hour soon are coming / When all the IT folks say "Gosh!" It isn't from a clever lawsuit / That Windowsland will finally fall, But thousands writing open source code / Like mice who nibble through a wall. --The Linux-nationale by Greg Baker _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu May 04 12:34:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbgms-0002mq-Nb; Thu, 04 May 2006 12:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbgmr-0002ml-Bk for ltru@ietf.org; Thu, 04 May 2006 12:34:45 -0400 Received: from relay03.pair.com ([209.68.5.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fbgmr-00039z-2C for ltru@ietf.org; Thu, 04 May 2006 12:34:45 -0400 Received: (qmail 11422 invoked from network); 4 May 2006 16:34:42 -0000 Received: from unknown (HELO ?172.18.102.241?) (unknown) by unknown with SMTP; 4 May 2006 16:34:42 -0000 X-pair-Authenticated: 216.239.45.4 Message-ID: <445A2D05.5030005@icu-project.org> Date: Thu, 04 May 2006 09:34:13 -0700 From: Mark Davis User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] 2nd WG Last Call for draft-ietf-ltru-matching References: <6.0.0.20.2.20060502185911.099e0c10@localhost> <20060504050213.GC527@ccil.org> In-Reply-To: <20060504050213.GC527@ccil.org> Content-Type: text/plain; charset=UTF-8; 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 My comments are a) version 12 of the document is fine the way it is, but b) I have no real objection to any of John's suggested changes, except the general one that we could making minor incremental improvements to this document until we die of exhaustion, *none* of which are or have been worth delaying the publication of 3066bis! (Let's get this damn thing out the door!) Mark P.S. Not sure why we are really concerned with a German noble (Graf) in this document ;-) John Cowan wrote: > Martin Duerst scripsit: > > >> Please read the draft at >> http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt >> carefully and send in comments, with a subject indicating >> the issue. Please also send in a comment if you have read the >> draft and haven't found any issue. >> > > Here are my comments, all editorial in nature: > > 1. In Section 2.1, the first sentence of the first graf and the first > sentence of the second graf are overlapping and partly contradictory. > I suggest changing the first to: > > A "basic language range" (originally described by HTTP/1.1 > [RFC 2616] and later [RFC 3066bis] has the same syntax as an > [RFC 3066bis] language tag or is the single character "*". > > and removing the first sentence of the second graf altogether, but > expanding the following pronoun "They" to "Basic language ranges" > for clarity. > > 2. In Section 2.2, for "useful in specifying" read "useful for > specifying". > > 3. In Section 3, the second graf is redundant and confuses the > number of matching schemes with the number of *types* of matching > schemes. I suggest it be removed in favor of changes to Section 3.1 > following. > > 4. In Section 3.1, for "types of matching" read "matching schemes", > and append "and returns zero or more matching language tags" to > list entries 1 and 2. > > 5. In Section 3.3.1, replace the first sentenc with "Basic filtering > compares basic language ranges to language tags", for conformity wiht > Section 3.3.2. > > 6. In Section 3.3.2, last graf, the words "One such difference is that" > don't seem to serve any purpose; I suggest they be removed. > > 7. In Section 3.4, last graf, I suggest swapping the last two > sentences, with the exception of the words "For example" and "Another > possibility" which should be left in place. > > 8. In Section 3.4.1, after "specification" insert "that uses lookup" > for clarity. > > 9. In Section 3.4.1, the bullet list is a random mixture of tags > the algorithm might return as defaults, and the actions that the > calling application might take as a result. I suggest these be > split more or less as follows: > > Some possible examples of default results are: > > * return a particular language tag designated for the operation > > * return a null string as a language tag value, in cases > where the protocol permits the empty value (yada yada) > > * return the language tag "i-default" (see [RFC 2277]) > > * return an error condition or error message > > In turn, the application, protocol, or specification may choose to: > > * return an item with no language tag (yada yada) > > * return a list of available languages for the user to select from > > > 10. In Section 4.4. for "that apply" read "that can be applied" and > for "can also apply" read "can also be applied". > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu May 04 13:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbhr2-0004aa-Iw; Thu, 04 May 2006 13:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbhr0-0004Y5-Nm for ltru@ietf.org; Thu, 04 May 2006 13:43:06 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbhr0-00069t-8T for ltru@ietf.org; Thu, 04 May 2006 13:43:06 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c9.corp.yahoo.com [10.72.76.9]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k44HfpUl081417; Thu, 4 May 2006 10:41:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=RDOtsbcRBI0GkVshg2QMZyro3ZYMWNXGBq3feIVi1t5ijJD01lblsIsqZa6aYxfC From: "Addison Phillips" To: "'Mark Davis'" , "'John Cowan'" Subject: RE: [Ltru] 2nd WG Last Call for draft-ietf-ltru-matching Date: Thu, 4 May 2006 10:41:55 -0700 Message-ID: <002e01c66fa2$09c94bd0$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.2869 Thread-Index: AcZvmLNFyWXzUfM4Rga/0wPZbqxXwgABwShA In-Reply-To: <445A2D05.5030005@icu-project.org> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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 > a) version 12 of the document is fine the way it is, but +1 to that... but... I don't mind minor editorial comments like these, since they will not = prevent us from moving forward and may assist us at IETF Last Call by = making the document better. This is, after all, a Last Call for = comments. The only things that will prevent us finishing this document = off are substantive comments that cannot be addressed or "major" = editorial comments. Substantive comments we can consider on their own = merits and I think we would approach a major edit with great caution. Our goal here, IMO, should be to submit draft-13 in the best possible = shape for an IETF Last Call and to convince the chairs that the document = is ready for its real Last Call and subsequent adoption. To that end, = clarification of the text is welcome: I do not want to have multiple = IETF Last Calls. I'm kind of tired of that. "Bring out 'yer dead." 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=B45=E6=9C=884=E6=97=A5 9:34 > To: John Cowan > Cc: LTRU Working Group > Subject: Re: [Ltru] 2nd WG Last Call for draft-ietf-ltru-matching >=20 > My comments are >=20 > a) version 12 of the document is fine the way it is, but > b) I have no real objection to any of John's suggested changes, except > the general one that we could making minor incremental improvements to > this document until we die of exhaustion, *none* of which are or have > been worth delaying the publication of 3066bis! (Let's get this damn > thing out the door!) >=20 > Mark >=20 > P.S. Not sure why we are really concerned with a German noble (Graf) = in > this document ;-) >=20 > John Cowan wrote: > > Martin Duerst scripsit: > > > > > >> Please read the draft at > >> http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt > >> carefully and send in comments, with a subject indicating > >> the issue. Please also send in a comment if you have read the > >> draft and haven't found any issue. > >> > > > > Here are my comments, all editorial in nature: > > > > 1. In Section 2.1, the first sentence of the first graf and the = first > > sentence of the second graf are overlapping and partly = contradictory. > > I suggest changing the first to: > > > > A "basic language range" (originally described by HTTP/1.1 > > [RFC 2616] and later [RFC 3066bis] has the same syntax as an > > [RFC 3066bis] language tag or is the single character "*". > > > > and removing the first sentence of the second graf altogether, but > > expanding the following pronoun "They" to "Basic language ranges" > > for clarity. > > > > 2. In Section 2.2, for "useful in specifying" read "useful for > > specifying". > > > > 3. In Section 3, the second graf is redundant and confuses the > > number of matching schemes with the number of *types* of matching > > schemes. I suggest it be removed in favor of changes to Section 3.1 > > following. > > > > 4. In Section 3.1, for "types of matching" read "matching schemes", > > and append "and returns zero or more matching language tags" to > > list entries 1 and 2. > > > > 5. In Section 3.3.1, replace the first sentenc with "Basic = filtering > > compares basic language ranges to language tags", for conformity = wiht > > Section 3.3.2. > > > > 6. In Section 3.3.2, last graf, the words "One such difference is = that" > > don't seem to serve any purpose; I suggest they be removed. > > > > 7. In Section 3.4, last graf, I suggest swapping the last two > > sentences, with the exception of the words "For example" and = "Another > > possibility" which should be left in place. > > > > 8. In Section 3.4.1, after "specification" insert "that uses = lookup" > > for clarity. > > > > 9. In Section 3.4.1, the bullet list is a random mixture of tags > > the algorithm might return as defaults, and the actions that the > > calling application might take as a result. I suggest these be > > split more or less as follows: > > > > Some possible examples of default results are: > > > > * return a particular language tag designated for the operation > > > > * return a null string as a language tag value, in cases > > where the protocol permits the empty value (yada yada) > > > > * return the language tag "i-default" (see [RFC 2277]) > > > > * return an error condition or error message > > > > In turn, the application, protocol, or specification may choose to: > > > > * return an item with no language tag (yada yada) > > > > * return a list of available languages for the user to select from > > > > > > 10. In Section 4.4. for "that apply" read "that can be applied" and > > for "can also apply" read "can also be applied". > > > > >=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 May 04 13:44:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbhsK-0006sl-4w; Thu, 04 May 2006 13:44:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbhsJ-0006pH-2G for ltru@ietf.org; Thu, 04 May 2006 13:44:27 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbhsI-0006BL-JT for ltru@ietf.org; Thu, 04 May 2006 13:44:27 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c9.corp.yahoo.com [10.72.76.9]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k44Hhqp2082082; Thu, 4 May 2006 10:43:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=UrhknbpVRd0vIXrN56G9B+9Sj5FG6y/OKa85OVGC+qvv421Qyr2UruDQT+fUr27J From: "Addison Phillips" To: "'John Cowan'" , "'Martin Duerst'" Subject: RE: [Ltru] 2nd WG Last Call for draft-ietf-ltru-matching Date: Thu, 4 May 2006 10:43:56 -0700 Message-ID: <002f01c66fa2$51c92680$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.2869 Thread-Index: AcZvN/fsBYl8NTu/QhWesaJyTPcy5wAZK5Rg In-Reply-To: <20060504050213.GC527@ccil.org> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi John, Thanks for the comments. Comments on my proposed disposition of each 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?5?3? 22:02 > To: Martin Duerst > Cc: LTRU Working Group > Subject: Re: [Ltru] 2nd WG Last Call for draft-ietf-ltru-matching > > Martin Duerst scripsit: > > > Please read the draft at > > http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt > > carefully and send in comments, with a subject indicating > > the issue. Please also send in a comment if you have read the > > draft and haven't found any issue. > > Here are my comments, all editorial in nature: > > 1. In Section 2.1, the first sentence of the first graf and the first > sentence of the second graf are overlapping and partly contradictory. > I suggest changing the first to: > > A "basic language range" (originally described by HTTP/1.1 > [RFC 2616] and later [RFC 3066bis] has the same syntax as an > [RFC 3066bis] language tag or is the single character "*". > > and removing the first sentence of the second graf altogether, but > expanding the following pronoun "They" to "Basic language ranges" > for clarity. Agreed, only I also extracted the parenthetical like this: -- A "basic language range" has the same syntax as an language tag or is the single character "*". The basic language range was originally described by HTTP/1.1 and later . -- > > 2. In Section 2.2, for "useful in specifying" read "useful for > specifying". Done. > > 3. In Section 3, the second graf is redundant and confuses the > number of matching schemes with the number of *types* of matching > schemes. I suggest it be removed in favor of changes to Section 3.1 > following. This would remove the definition of filtering and lookup. It would be better to fix the inconsistencies in the language later. > > 4. In Section 3.1, for "types of matching" read "matching schemes", > and append "and returns zero or more matching language tags" to > list entries 1 and 2. Changed the section title as proposed. Change the intro to the list of schemes from: -- This document describes three types of matching -- To read: -- This document describes three matching schemes -- > > 5. In Section 3.3.1, replace the first sentenc with "Basic filtering > compares basic language ranges to language tags", for conformity wiht > Section 3.3.2. Done. > > 6. In Section 3.3.2, last graf, the words "One such difference is that" > don't seem to serve any purpose; I suggest they be removed. Done. > > 7. In Section 3.4, last graf, I suggest swapping the last two > sentences, with the exception of the words "For example" and "Another > possibility" which should be left in place. I like that more. Here is the resulting para (there are three sentences, actually, and the middle sentence must be after the ASCII-order suggestion): For example, an implementation could map the extended language ranges to basic ranges. Another possibility would be for an implementation to 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. > > 8. In Section 3.4.1, after "specification" insert "that uses lookup" > for clarity. Done. > > 9. In Section 3.4.1, the bullet list is a random mixture of tags > the algorithm might return as defaults, and the actions that the > calling application might take as a result. I suggest these be > split more or less as follows: > > Some possible examples of default results are: > > * return a particular language tag designated for the operation > > * return a null string as a language tag value, in cases > where the protocol permits the empty value (yada yada) > > * return the language tag "i-default" (see [RFC 2277]) > > * return an error condition or error message > > In turn, the application, protocol, or specification may choose to: > > * return an item with no language tag (yada yada) > > * return a list of available languages for the user to select from Hm... I don't see this particular one as necessary and think it subtracts from the unity of the message. I didn't implement this change, as a result. > > > 10. In Section 4.4. for "that apply" read "that can be applied" and > for "can also apply" read "can also be applied". > Done. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu May 04 14:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbiuO-0006Cw-17; Thu, 04 May 2006 14:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbiuN-0006Cr-6m for ltru@ietf.org; Thu, 04 May 2006 14:50:39 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbiuM-0000dI-0P for ltru@ietf.org; Thu, 04 May 2006 14:50:39 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FbiuJ-0002WC-9i; Thu, 04 May 2006 14:50:35 -0400 Date: Thu, 4 May 2006 14:50:35 -0400 To: Addison Phillips Subject: Re: [Ltru] 2nd WG Last Call for draft-ietf-ltru-matching Message-ID: <20060504185035.GI22933@ccil.org> References: <20060504050213.GC527@ccil.org> <002f01c66fa2$51c92680$660a0a0a@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002f01c66fa2$51c92680$660a0a0a@ds.corp.yahoo.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Comments on my proposed disposition of each follow. No complaints and no further comments. I'm done. -- After fixing the Y2K bug in an application: John Cowan WELCOME TO cowan@ccil.org DATE: MONDAK, JANUARK 1, 1900 http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu May 04 15:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbjgo-0004Rx-VC; Thu, 04 May 2006 15:40:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbjgn-0004Pg-PW for ltru@ietf.org; Thu, 04 May 2006 15:40:41 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbjgm-0002cR-JU for ltru@ietf.org; Thu, 04 May 2006 15:40:41 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Fbjgm-0004cd-5O; Thu, 04 May 2006 15:40:40 -0400 Date: Thu, 4 May 2006 15:40:40 -0400 To: Peter Constable Subject: Re: [Ltru] Re: Fwd: LTRU Milestones past due (matching draft to IETFLast Call) Message-ID: <20060504194040.GK22933@ccil.org> References: <006301c66822$b733a630$040aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 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 Peter Constable scripsit: > For my part, I am finally working on preparing the text for ISO/FDIS > 639-3, Ah, excellent. Is this the time to ask you to add "sgn" as a macrolanguage covering all the sign languages? That would greatly simplify the tasks required for 3066ter. -- Why are well-meaning Westerners so concerned that John Cowan the opening of a Colonel Sanders in Beijing means cowan@ccil.org the end of Chinese culture? [...] We have had http://www.ccil.org/~cowan Chinese restaurants in America for over a century, and it hasn't made us Chinese. On the contrary, we obliged the Chinese to invent chop suey. --Marshall Sahlins _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu May 11 11:46:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDMf-0002Dm-2N; Thu, 11 May 2006 11:46:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDMd-0002Cn-Qg for ltru@ietf.org; Thu, 11 May 2006 11:46:07 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeDMa-0007pH-Jq for ltru@ietf.org; Thu, 11 May 2006 11:46:07 -0400 Received: from duringpersonlx (snvvpn2-10-72-76-c88.corp.yahoo.com [10.72.76.88]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4BFjkdN044655 for ; Thu, 11 May 2006 08:45:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:thread-index:x-mimeole; b=lmcOpe6xuIZTAGC4ufiohlHRo7oSQpq8XQghJmjh2k3SeH7ZlU69djrUzv4QOfZH From: "Addison Phillips" To: "'LTRU Working Group'" Date: Thu, 11 May 2006 08:45:45 -0700 Message-ID: <000a01c67511$f82e8550$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: AcZ1Efd2hZKHzYBOQbKHvxX7KqQMUA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] editor's copy updated... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All: The WG last call (on draft-12) ends next Tuesday, 16 May. Yesterday I = updated the editor's copy of draft-13 to incorporate John Cowan's = comments and placed the copy on my personal website here: http://www.inter-locale.com/ID/draft-ietf-ltru-matching-13.txt http://www.inter-locale.com/ID/draft-ietf-ltru-matching-13.html http://www.inter-locale.com/ID/draft-ietf-ltru-matching-13.xml Because this document is subject to change due to other comments, I did = not generate a static diff from draft-12. I did provide a link on my = homepage to generate one on the fly. The TinyURL for this is: http://tinyurl.com/kc3f8 If you have lingering issues or comments, now is the time for them. = Otherwise I look forward to submitting draft-13 next Wednesday and its = subsequent referral to the IESG. Addison (for the editors) 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 May 14 19:23:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfPvJ-0002Qi-4p; Sun, 14 May 2006 19:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfPvH-0002Pq-R0 for ltru@lists.ietf.org; Sun, 14 May 2006 19:22:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfPvF-00054i-H1 for ltru@lists.ietf.org; Sun, 14 May 2006 19:22:51 -0400 Received: by ug-out-1314.google.com with SMTP id m2so390901uge for ; Sun, 14 May 2006 16:22:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=nYzGdTGVLGG9zDj0bj++VCpWp+HcPPJBgXvoWYF+zTOudeJ9qTLDvi11Ku6MHIHL2rmFrdfyXYq5XSMMInVzMhT1P1bQpshb/sgH7i//CCzc4lOWdBcBITVdc1Mns8dGqD5dihg1VH6L/y3/A1AA0asDxqHlr2McXLlkXrsKJ4I= Received: by 10.66.236.15 with SMTP id j15mr1754485ugh; Sun, 14 May 2006 16:22:48 -0700 (PDT) Received: by 10.67.22.18 with HTTP; Sun, 14 May 2006 16:22:48 -0700 (PDT) Message-ID: <30b660a20605141622m35d83c81id98411eae9e15730@mail.gmail.com> Date: Sun, 14 May 2006 16:22:48 -0700 From: "Mark Davis" To: ltru@lists.ietf.org, ltru@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 4e63f23b5e8b3cb5 X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ltru] CLDR mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0900903075==" Errors-To: ltru-bounces@ietf.org --===============0900903075== Content-Type: multipart/alternative; boundary="----=_Part_22225_10840519.1147648968514" ------=_Part_22225_10840519.1147648968514 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSB3YXMganVzdCBtYWtpbmcgZHJhZnQgY2hhbmdlcyB0byBMRE1MICh1c2VkIGZvciBDTERSKSBp biByZXNwb25zZSB0byBhIGJ1Zwp0byB1cGRhdGUgdG8gUkZDMzA2NmJpcyAod2UgdGhvdWdodCB3 ZSdkIGhhdmUgYSBmaW5hbCBudW1iZXIgYnkgbm93LCBidXQgbm8Kc3VjaCBsdWNrISkuIEkgaGF2 ZSBkcmFmdCBsYW5ndWFnZSBhdAoKaHR0cDovL2Rldi5pY3UtcHJvamVjdC5vcmcvY2dpLWJpbi9j bGRyL2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVzCgpBbnkgZmVlZGJhY2sgaXMgd2Vs Y29tZTsgdGhlIGNvbW1pdHRlZSB3aWxsIGJlIGxvb2tpbmcgYXQgdGhpcyBvbiBUdWVzZGF5Cm1v cm5pbmcuCgpCVFcsIGZyb20gdGhlIGxhbmd1YWdlIHBhcnQgb2YgYSBDTERSIGxvY2FsZSBJRCwg aWYgbXkgc3VnZ2VzdGlvbnMgYXJlIHRha2VuCnVwIG9ubHkgdGhlIHZhcmlhbnQgc3VidGFncyB7 UE9TSVgsIFJFVklTRUQsIFNBQUhPfSBhcmUgbWlzc2luZyBmcm9tCjMwNjZiaXMsIHBsdXMgc29t ZSBVTiBNLjQ5IGNvZGVzLgoKTWFyawo= ------=_Part_22225_10840519.1147648968514 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB3YXMganVzdCBtYWtpbmcgZHJhZnQgY2hhbmdlcyB0byBMRE1MICh1c2VkIGZvciBDTERSKSBp biByZXNwb25zZSB0byBhIGJ1ZyB0byB1cGRhdGUKdG8gUkZDMzA2NmJpcyAod2UgdGhvdWdodCB3 ZSdkIGhhdmUgYSBmaW5hbCBudW1iZXIgYnkgbm93LCBidXQgbm8gc3VjaApsdWNrISkuIEkgaGF2 ZSBkcmFmdCBsYW5ndWFnZSBhdDxicj48YnI+PGEgaHJlZj0iaHR0cDovL2Rldi5pY3UtcHJvamVj dC5vcmcvY2dpLWJpbi9jbGRyL2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVzIj5odHRw Oi8vZGV2LmljdS1wcm9qZWN0Lm9yZy9jZ2ktYmluL2NsZHIvbG9jYWxlLWJ1Z3MtcHJpdmF0ZS9k YXRhI3JlcGxpZXM8L2E+PGJyPjxicj5BbnkgZmVlZGJhY2sgaXMgd2VsY29tZTsgdGhlIGNvbW1p dHRlZSB3aWxsIGJlIGxvb2tpbmcgYXQgdGhpcyBvbiBUdWVzZGF5IG1vcm5pbmcuCjxicj48YnI+ QlRXLCBmcm9tIHRoZSBsYW5ndWFnZSBwYXJ0IG9mIGEgQ0xEUiBsb2NhbGUgSUQsIGlmIG15IHN1 Z2dlc3Rpb25zIGFyZSB0YWtlbiB1cCBvbmx5IHRoZSB2YXJpYWFrom ltru-bounces@ietf.org Sun May 14 19:23:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfPvJ-0002Qi-4p; Sun, 14 May 2006 19:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfPvH-0002Pq-R0 for ltru@lists.ietf.org; Sun, 14 May 2006 19:22:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfPvF-00054i-H1 for ltru@lists.ietf.org; Sun, 14 May 2006 19:22:51 -0400 Received: by ug-out-1314.google.com with SMTP id m2so390901uge for ; Sun, 14 May 2006 16:22:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=nYzGdTGVLGG9zDj0bj++VCpWp+HcPPJBgXvoWYF+zTOudeJ9qTLDvi11Ku6MHIHL2rmFrdfyXYq5XSMMInVzMhT1P1bQpshb/sgH7i//CCzc4lOWdBcBITVdc1Mns8dGqD5dihg1VH6L/y3/A1AA0asDxqHlr2McXLlkXrsKJ4I= Received: by 10.66.236.15 with SMTP id j15mr1754485ugh; Sun, 14 May 2006 16:22:48 -0700 (PDT) Received: by 10.67.22.18 with HTTP; Sun, 14 May 2006 16:22:48 -0700 (PDT) Message-ID: <30b660a20605141622m35d83c81id98411eae9e15730@mail.gmail.com> Date: Sun, 14 May 2006 16:22:48 -0700 From: "Mark Davis" To: ltru@lists.ietf.org, ltru@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 4e63f23b5e8b3cb5 X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ltru] CLDR mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0900903075==" Errors-To: ltru-bounces@ietf.org --===============0900903075== Content-Type: multipart/alternative; boundary="----=_Part_22225_10840519.1147648968514" ------=_Part_22225_10840519.1147648968514 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSB3YXMganVzdCBtYWtpbmcgZHJhZnQgY2hhbmdlcyB0byBMRE1MICh1c2VkIGZvciBDTERSKSBp biByZXNwb25zZSB0byBhIGJ1Zwp0byB1cGRhdGUgdG8gUkZDMzA2NmJpcyAod2UgdGhvdWdodCB3 ZSdkIGhhdmUgYSBmaW5hbCBudW1iZXIgYnkgbm93LCBidXQgbm8Kc3VjaCBsdWNrISkuIEkgaGF2 ZSBkcmFmdCBsYW5ndWFnZSBhdAoKaHR0cDovL2Rldi5pY3UtcHJvamVjdC5vcmcvY2dpLWJpbi9j bGRyL2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVzCgpBbnkgZmVlZGJhY2sgaXMgd2Vs Y29tZTsgdGhlIGNvbW1pdHRlZSB3aWxsIGJlIGxvb2tpbmcgYXQgdGhpcyBvbiBUdWVzZGF5Cm1v cm5pbmcuCgpCVFcsIGZyb20gdGhlIGxhbmd1YWdlIHBhcnQgb2YgYSBDTERSIGxvY2FsZSBJRCwg aWYgbXkgc3VnZ2VzdGlvbnMgYXJlIHRha2VuCnVwIG9ubHkgdGhlIHZhcmlhbnQgc3VidGFncyB7 UE9TSVgsIFJFVklTRUQsIFNBQUhPfSBhcmUgbWlzc2luZyBmcm9tCjMwNjZiaXMsIHBsdXMgc29t ZSBVTiBNLjQ5IGNvZGVzLgoKTWFyawo= ------=_Part_22225_10840519.1147648968514 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB3YXMganVzdCBtYWtpbmcgZHJhZnQgY2hhbmdlcyB0byBMRE1MICh1c2VkIGZvciBDTERSKSBp biByZXNwb25zZSB0byBhIGJ1ZyB0byB1cGRhdGUKdG8gUkZDMzA2NmJpcyAod2UgdGhvdWdodCB3 ZSdkIGhhdmUgYSBmaW5hbCBudW1iZXIgYnkgbm93LCBidXQgbm8gc3VjaApsdWNrISkuIEkgaGF2 ZSBkcmFmdCBsYW5ndWFnZSBhdDxicj48YnI+PGEgaHJlZj0iaHR0cDovL2Rldi5pY3UtcHJvamVj dC5vcmcvY2dpLWJpbi9jbGRyL2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVzIj5odHRw Oi8vZGV2LmljdS1wcm9qZWN0Lm9yZy9jZ2ktYmluL2NsZHIvbG9jYWxlLWJ1Z3MtcHJpdmF0ZS9k YXRhI3JlcGxpZXM8L2E+PGJyPjxicj5BbnkgZmVlZGJhY2sgaXMgd2VsY29tZTsgdGhlIGNvbW1p dHRlZSB3aWxsIGJlIGxvb2tpbmcgYXQgdGhpcyBvbiBUdWVzZGF5IG1vcm5pbmcuCjxicj48YnI+ QlRXLCBmcm9tIHRoZSBsYW5ndWFnZSBwYXJ0IG9mIGEgQ0xEUiBsb2NhbGUgSUQsIGlmIG15IHN1 Z2dlc3Rpb25zIGFyZSB0YWtlbiB1cCBvbmx5IHRoZSB2YXJpYW50IHN1YnRhZ3Mge1BPU0lYPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Ij4sIDwvc3Bhbj5SRVZJU0VEPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Ij4sIDwvc3Bhbj5TQUFIT30gYXJlIG1pc3Np bmcgZnJvbSAzMDY2YmlzLCBwbHVzIHNvbWUgVU4gCk0uNDkgY29kZXMuPGJyPjxicj5NYXJrPGJy Pgo8YnI+Cg== ------=_Part_22225_10840519.1147648968514-- --===============0900903075== 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 --===============0900903075==-- From ltru-bounces@ietf.org Sun May 14 19:23:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfPvJ-0002Qm-8P; Sun, 14 May 2006 19:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfPvH-0002Px-Ra for ltru@ietf.org; Sun, 14 May 2006 19:22:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfPvF-00054h-Gy for ltru@ietf.org; Sun, 14 May 2006 19:22:51 -0400 Received: by ug-out-1314.google.com with SMTP id m2so390900uge for ; Sun, 14 May 2006 16:22:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=nYzGdTGVLGG9zDj0bj++VCpWp+HcPPJBgXvoWYF+zTOudeJ9qTLDvi11Ku6MHIHL2rmFrdfyXYq5XSMMInVzMhT1P1bQpshb/sgH7i//CCzc4lOWdBcBITVdc1Mns8dGqD5dihg1VH6L/y3/A1AA0asDxqHlr2McXLlkXrsKJ4I= Received: by 10.66.236.15 with SMTP id j15mr1754485ugh; Sun, 14 May 2006 16:22:48 -0700 (PDT) Received: by 10.67.22.18 with HTTP; Sun, 14 May 2006 16:22:48 -0700 (PDT) Message-ID: <30b660a20605141622m35d83c81id98411eae9e15730@mail.gmail.com> Date: Sun, 14 May 2006 16:22:48 -0700 From: "Mark Davis" To: ltru@lists.ietf.org, ltru@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 4e63f23b5e8b3cb5 X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ltru] CLDR mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0432165213==" Errors-To: ltru-bounces@ietf.org --===============0432165213== Content-Type: multipart/alternative; boundary="----=_Part_22225_10840519.1147648968514" ------=_Part_22225_10840519.1147648968514 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSB3YXMganVzdCBtYWtpbmcgZHJhZnQgY2hhbmdlcyB0byBMRE1MICh1c2VkIGZvciBDTERSKSBp biByZXNwb25zZSB0byBhIGJ1Zwp0byB1cGRhdGUgdG8gUkZDMzA2NmJpcyAod2UgdGhvdWdodCB3 ZSdkIGhhdmUgYSBmaW5hbCBudW1iZXIgYnkgbm93LCBidXQgbm8Kc3VjaCBsdWNrISkuIEkgaGF2 ZSBkcmFmdCBsYW5ndWFnZSBhdAoKaHR0cDovL2Rldi5pY3UtcHJvamVjdC5vcmcvY2dpLWJpbi9j bGRyL2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVzCgpBbnkgZmVlZGJhY2sgaXMgd2Vs Y29tZTsgdGhlIGNvbW1pdHRlZSB3aWxsIGJlIGxvb2tpbmcgYXQgdGhpcyBvbiBUdWVzZGF5Cm1v cm5pbmcuCgpCVFcsIGZyb20gdGhlIGxhbmd1YWdlIHBhcnQgb2YgYSBDTERSIGxvY2FsZSBJRCwg aWYgbXkgc3VnZ2VzdGlvbnMgYXJlIHRha2VuCnVwIG9ubHkgdGhlIHZhcmlhbnQgc3VidGFncyB7 UE9TSVgsIFJFVklTRUQsIFNBQUhPfSBhcmUgbWlzc2luZyBmcm9tCjMwNjZiaXMsIHBsdXMgc29t ZSBVTiBNLjQ5IGNvZGVzLgoKTWFyawo= ------=_Part_22225_10840519.1147648968514 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB3YXMganVzdCBtYWtpbmcgZHJhZnQgY2hhbmdlcyB0byBMRE1MICh1c2VkIGZvciBDTERSKSBp biByZXNwb25zZSB0byBhIGJ1ZyB0byB1cGRhdGUKdG8gUkZDMzA2Nm50IHN1YnRhZ3Mge1BPU0lYPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Ij4sIDwvc3Bhbj5SRVZJU0VEPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Ij4sIDwvc3Bhbj5TQUFIT30gYXJlIG1pc3Np bmcgZnJvbSAzMDY2YmlzLCBwbHVzIHNvbWUgVU4gCk0uNDkgY29kZXMuPGJyPjxicj5NYXJrPGJy Pgo8YnI+Cg== ------=_Part_22225_10840519.1147648968514-- --===============0900903075== 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 --===============0900903075==-- From ltru-bounces@ietf.org Sun May 14 19:23:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfPvJ-0002Qm-8P; Sun, 14 May 2006 19:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfPvH-0002Px-Ra for ltru@ietf.org; Sun, 14 May 2006 19:22:51 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfPvF-00054h-Gy for ltru@ietf.org; Sun, 14 May 2006 19:22:51 -0400 Received: by ug-out-1314.google.com with SMTP id m2so390900uge for ; Sun, 14 May 2006 16:22:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=nYzGdTGVLGG9zDj0bj++VCpWp+HcPPJBgXvoWYF+zTOudeJ9qTLDvi11Ku6MHIHL2rmFrdfyXYq5XSMMInVzMhT1P1bQpshb/sgH7i//CCzc4lOWdBcBITVdc1Mns8dGqD5dihg1VH6L/y3/A1AA0asDxqHlr2McXLlkXrsKJ4I= Received: by 10.66.236.15 with SMTP id j15mr1754485ugh; Sun, 14 May 2006 16:22:48 -0700 (PDT) Received: by 10.67.22.18 with HTTP; Sun, 14 May 2006 16:22:48 -0700 (PDT) Message-ID: <30b660a20605141622m35d83c81id98411eae9e15730@mail.gmail.com> Date: Sun, 14 May 2006 16:22:48 -0700 From: "Mark Davis" To: ltru@lists.ietf.org, ltru@ietf.org MIME-Version: 1.0 X-Google-Sender-Auth: 4e63f23b5e8b3cb5 X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ltru] CLDR mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0432165213==" Errors-To: ltru-bounces@ietf.org --===============0432165213== Content-Type: multipart/alternative; boundary="----=_Part_22225_10840519.1147648968514" ------=_Part_22225_10840519.1147648968514 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SSB3YXMganVzdCBtYWtpbmcgZHJhZnQgY2hhbmdlcyB0byBMRE1MICh1c2VkIGZvciBDTERSKSBp biByZXNwb25zZSB0byBhIGJ1Zwp0byB1cGRhdGUgdG8gUkZDMzA2NmJpcyAod2UgdGhvdWdodCB3 ZSdkIGhhdmUgYSBmaW5hbCBudW1iZXIgYnkgbm93LCBidXQgbm8Kc3VjaCBsdWNrISkuIEkgaGF2 ZSBkcmFmdCBsYW5ndWFnZSBhdAoKaHR0cDovL2Rldi5pY3UtcHJvamVjdC5vcmcvY2dpLWJpbi9j bGRyL2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVzCgpBbnkgZmVlZGJhY2sgaXMgd2Vs Y29tZTsgdGhlIGNvbW1pdHRlZSB3aWxsIGJlIGxvb2tpbmcgYXQgdGhpcyBvbiBUdWVzZGF5Cm1v cm5pbmcuCgpCVFcsIGZyb20gdGhlIGxhbmd1YWdlIHBhcnQgb2YgYSBDTERSIGxvY2FsZSBJRCwg aWYgbXkgc3VnZ2VzdGlvbnMgYXJlIHRha2VuCnVwIG9ubHkgdGhlIHZhcmlhbnQgc3VidGFncyB7 UE9TSVgsIFJFVklTRUQsIFNBQUhPfSBhcmUgbWlzc2luZyBmcm9tCjMwNjZiaXMsIHBsdXMgc29t ZSBVTiBNLjQ5IGNvZGVzLgoKTWFyawo= ------=_Part_22225_10840519.1147648968514 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSB3YXMganVzdCBtYWtpbmcgZHJhZnQgY2hhbmdlcyB0byBMRE1MICh1c2VkIGZvciBDTERSKSBp biByZXNwb25zZSB0byBhIGJ1ZyB0byB1cGRhdGUKdG8gUkZDMzA2NmJpcyAod2UgdGhvdWdodCB3 ZSdkIGhhdmUgYSBmaW5hbCBudW1iZXIgYnkgbm93LCBidXQgbm8gc3VjaApsdWNrISkuIEkgaGF2 ZSBkcmFmdCBsYW5ndWFnZSBhdDxicj48YnI+PGEgaHJlZj0iaHR0cDovL2Rldi5pY3UtcHJvamVj dC5vcmcvY2dpLWJpbi9jbGRyL2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVzIj5odHRw Oi8vZGV2LmljdS1wcm9qZWN0Lm9yZy9jZ2ktYmluL2NsZHIvbG9jYWxlLWJ1Z3MtcHJpdmF0ZS9k YXRhI3JlcGxpZXM8L2E+PGJyPjxicj5BbnkgZmVlZGJhY2sgaXMgd2VsY29tZTsgdGhlIGNvbW1p dHRlZSB3aWxsIGJlIGxvb2tpbmcgYXQgdGhpcyBvbiBUdWVzZGF5IG1vcm5pbmcuCjxicj48YnI+ QlRXLCBmcm9tIHRoZSBsYW5ndWFnZSBwYXJ0IG9mIGEgQ0xEUiBsb2NhbGUgSUQsIGlmIG15IHN1 Z2dlc3Rpb25zIGFyZSB0YWtlbiB1cCBvbmx5IHRoZSB2YXJpYW50IHN1YnRhZ3Mge1BPU0lYPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Ij4sIDwvc3Bhbj5SRVZJU0VEPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Ij4sIDwvc3Bhbj5TQUFIT30gYXJlIG1pc3Np bmcgZnJvbSAzMDY2YmlzLCBwbHVzIHNvbWUgVU4gCk0uNDkgY29kZXMuPGJyPjxicj5NYXJrPGJy Pgo8YnI+Cg== ------=_Part_22225_10840519.1147648968514-- --===============0432165213== 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 --===============0432165213==-- JpcyAod2UgdGhvdWdodCB3 ZSdkIGhhdmUgYSBmaW5hbCBudW1iZXIgYnkgbm93LCBidXQgbm8gc3VjaApsdWNrISkuIEkgaGF2 ZSBkcmFmdCBsYW5ndWFnZSBhdDxicj48YnI+PGEgaHJlZj0iaHR0cDovL2Rldi5pY3UtcHJvamVj dC5vcmcvY2dpLWJpbi9jbGRyL2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVzIj5odHRw Oi8vZGV2LmljdS1wcm9qZWN0Lm9yZy9jZ2ktYmluL2NsZHIvbG9jYWxlLWJ1Z3MtcHJpdmF0ZS9k YXRhI3JlcGxpZXM8L2E+PGJyPjxicj5BbnkgZmVlZGJhY2sgaXMgd2VsY29tZTsgdGhlIGNvbW1p dHRlZSB3aWxsIGJlIGxvb2tpbmcgYXQgdGhpcyBvbiBUdWVzZGF5IG1vcm5pbmcuCjxicj48YnI+ QlRXLCBmcm9tIHRoZSBsYW5ndWFnZSBwYXJ0IG9mIGEgQ0xEUiBsb2NhbGUgSUQsIGlmIG15IHN1 Z2dlc3Rpb25zIGFyZSB0YWtlbiB1cCBvbmx5IHRoZSB2YXJpYW50IHN1YnRhZ3Mge1BPU0lYPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Ij4sIDwvc3Bhbj5SRVZJU0VEPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Ij4sIDwvc3Bhbj5TQUFIT30gYXJlIG1pc3Np bmcgZnJvbSAzMDY2YmlzLCBwbHVzIHNvbWUgVU4gCk0uNDkgY29kZXMuPGJyPjxicj5NYXJrPGJy Pgo8YnI+Cg== ------=_Part_22225_10840519.1147648968514-- --===============0432165213== 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 --===============0432165213==-- From ltru-bounces@ietf.org Mon May 15 00:28:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfUhA-00060U-S5; Mon, 15 May 2006 00:28:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfUhA-00060L-2D for ltru@ietf.org; Mon, 15 May 2006 00:28:36 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfUh8-0002Nr-NC for ltru@ietf.org; Mon, 15 May 2006 00:28:36 -0400 Received: by ug-out-1314.google.com with SMTP id m2so416468uge for ; Sun, 14 May 2006 21:28:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=QcHT44alpWZF8bTcSQY8/fbjx7jW0GCFhUG88cNAeqlkmA5gndhcaTbRtRJjjxDOei8EO/FKQ5SRN6XuBNSdZxK0Pq5DiOryEXFOiw7al8wvaMbU3ven0K/T9Fy0UfaX8SwI+Xhhq5oeOQ9OrFiIJLbJ06EHZVtFb+j8jlHb8V8= Received: by 10.67.108.27 with SMTP id k27mr3798132ugm; Sun, 14 May 2006 21:28:33 -0700 (PDT) Received: by 10.67.22.18 with HTTP; Sun, 14 May 2006 21:28:33 -0700 (PDT) Message-ID: <30b660a20605142128r855d172y93d5e77d99fa0bc2@mail.gmail.com> Date: Sun, 14 May 2006 21:28:33 -0700 From: "Mark Davis" To: ltru@lists.ietf.org, ltru@ietf.org In-Reply-To: <30b660a20605141622m35d83c81id98411eae9e15730@mail.gmail.com> MIME-Version: 1.0 References: <30b660a20605141622m35d83c81id98411eae9e15730@mail.gmail.com> X-Google-Sender-Auth: 526100a398b6e02a X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [Ltru] Re: CLDR mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1990010723==" Errors-To: ltru-bounces@ietf.org --===============1990010723== Content-Type: multipart/alternative; boundary="----=_Part_23209_22822585.1147667313875" ------=_Part_23209_22822585.1147667313875 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline QXBvbG9naWVzLCB0aGUgbGluayB3b24ndCB3b3JrIGZvciB5b3U7IHRyeToKCmh0dHA6Ly9kZXYu aWN1LXByb2plY3Qub3JnL2NnaS1iaW4vbG9jYWxlLWJ1Z3M/ZmluZGlkPTc5MyNyZXBsaWVzCgpO b3RlOiB0aGUgbGFzdCBiaXQgaGFzIGEgY291cGxlIG9mIHR5cG9zLiBEcmFmdCBsYW5ndWFnZSBp cyBhdCB0aGUgZW5kIG9mCnNlY3Rpb24gMzoKCmh0dHA6Ly93d3cudW5pY29kZS5vcmcvZHJhZnQv cmVwb3J0cy90cjM1L3RyMzUuaHRtbCNMb2NhbGVfSURzCgpNYXJrCgpPbiA1LzE0LzA2LCBNYXJr IERhdmlzIDxtYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZz4gd3JvdGU6Cj4KPiBJIHdhcyBqdXN0 IG1ha2luZyBkcmFmdCBjaGFuZ2VzIHRvIExETUwgKHVzZWQgZm9yIENMRFIpIGluIHJlc3BvbnNl IHRvIGEKPiBidWcgdG8gdXBkYXRlIHRvIFJGQzMwNjZiaXMgKHdlIHRob3VnaHQgd2UnZCBoYXZl IGEgZmluYWwgbnVtYmVyIGJ5IG5vdywgYnV0Cj4gbm8gc3VjaCBsdWNrISkuIEkgaGF2ZSBkcmFm dCBsYW5ndWFnZSBhdAo+Cj4gaHR0cDovL2Rldi5pY3UtcHJvamVjdC5vcmcvY2dpLWJpbi9jbGRy L2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVzCj4KPiBBbnkgZmVlZGJhY2sgaXMgd2Vs Y29tZTsgdGhlIGNvbW1pdHRlZSB3aWxsIGJlIGxvb2tpbmcgYXQgdGhpcyBvbiBUdWVzZGF5Cj4g bW9ybmluZy4KPgo+IEJUVywgZnJvbSB0aGUgbGFuZ3VhZ2UgcGFydCBvZiBhIENMRFIgbG9jYWxl IElELCBpZiBteSBzdWdnZXN0aW9ucyBhcmUKPiB0YWtlbiB1cCBvbmx5IHRoZSB2YXJpYW50IHN1 YnRhZ3Mge1BPU0lYLCBSRVZJU0VELCBTQUFIT30gYXJlIG1pc3NpbmcgZnJvbQo+IDMwNjZiaXMs IHBsdXMgc29tZSBVTiBNLjQ5IGNvZGVzLgo+Cj4gTWFyawo+Cj4K ------=_Part_23209_22822585.1147667313875 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline QXBvbG9naWVzLCB0aGUgbGluayB3b24ndCB3b3JrIGZvciB5b3U7IHRyeTo8YnI+PGJyPjxhIGhy ZWY9Imh0dHA6Ly9kZXYuaWN1LXByb2plY3Qub3JnL2NnaS1iaW4vbG9jYWxlLWJ1Z3M/ZmluZGlk PTc5MyNyZXBsaWVzIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVu RXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmh0dHA6Ly9kZXYuaWN1LXByb2plY3Qub3JnL2Nn aS1iaW4vbG9jYWxlLWJ1Z3M/ZmluZGlkPTc5MyNyZXBsaWVzCjwvYT48YnI+PGJyPk5vdGU6IHRo ZSBsYXN0IGJpdCBoYXMgYSBjb3VwbGUgb2YgdHlwb3MuIERyYWZ0IGxhbmd1YWdlIGlzIGF0IHRo ZSBlbmQgb2Ygc2VjdGlvbiAzOgo8YnI+PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cudW5pY29kZS5v cmcvZHJhZnQvcmVwb3J0cy90cjM1L3RyMzUuaHRtbCNMb2NhbGVfSURzIiB0YXJnZXQ9Il9ibGFu ayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcyki Pmh0dHA6Ly93d3cudW5pY29kZS5vcmcvZHJhZnQvcmVwb3J0cy90cjM1L3RyMzUuaHRtbCNMb2Nh bGVfSURzPC9hPjxicj4KPGJyPk1hcms8YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiA1LzE0LzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+TWFyayBEYXZpczwv Yj4gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZyI+bWFyay5k YXZpc0BpY3UtcHJvamVjdC5vcmc8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAy MDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+ CjxkaXY+SSB3YXMganVzdCBtYWtpbmcgZHJhZnQgY2hhbmdlcyB0byBMRE1MICh1c2VkIGZvciBD TERSKSBpbiByZXNwb25zZSB0byBhIGJ1ZyB0byB1cGRhdGUKdG8gUkZDMzA2NmJpcyAod2UgdGhv dWdodCB3ZSdkIGhhdmUgYSBmaW5hbCBudW1iZXIgYnkgbm93LCBidXQgbm8gc3VjaApsdWNrISku IEkgaGF2ZSBkcmFmdCBsYW5ndWFnZSBhdDxicj48YnI+PGEgaHJlZj0iaHR0cDovL2Rldi5pY3Ut cHJvamVjdC5vcmcvY2dpLWJpbi9jbGRyL2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVz IiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5k b3csZXZlbnQsdGhpcykiPmh0dHA6Ly9kZXYuaWN1LXByb2plY3Qub3JnL2NnaS1iaW4vY2xkci9s b2NhbGUtYnVncy1wcml2YXRlL2RhdGEjcmVwbGllcwo8L2E+PGJyPjxicj5BbnkgZmVlZGJhY2sg aXMgd2VsY29tZTsgdGhlIGNvbW1pdHRlZSB3aWxsIGJlIGxvb2tpbmcgYXQgdGhpcyBvbiBUdWVz ZGF5IG1vcm5pbmcuCjxicj48YnI+QlRXLCBmcm9tIHRoZSBsYW5ndWFnZSBwYXJ0IG9mIGEgQ0xE UiBsb2NhbGUgSUQsIGlmIG15IHN1Z2dlc3Rpb25zIGFyZSB0YWtlbiB1cCBvbmx5IHRoZSB2YXJp YW50IHN1YnRhZ3Mge1BPU0lYPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Ij4s IDwvc3Bhbj5SRVZJU0VEPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Ij4sIDwv c3Bhbj4KU0FBSE99IGFyZSBtaXNzaW5nIGZyb20gMzA2NmJpcywgcGx1cyBzb21lIFVOIApNLjQ5 IGNvZGVzLjxicj48L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJzZyI+PGJyPk1hcms8YnI+Cjxicj4K PC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+Cg== ------=_Part_23209_22822585.1147667313875-- --===============1990010723== 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 --===============1990010723==-- From ltru-bounces@ietf.org Mon May 15 00:28:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfUhA-00060Y-VE; Mon, 15 May 2006 00:28:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfUhA-00060K-2D for ltru@lists.ietf.org; Mon, 15 May 2006 00:28:36 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfUh8-0002Ns-NC for ltru@lists.ietf.org; Mon, 15 May 2006 00:28:36 -0400 Received: by ug-out-1314.google.com with SMTP id m2so416469uge for ; Sun, 14 May 2006 21:28:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=QcHT44alpWZF8bTcSQY8/fbjx7jW0GCFhUG88cNAeqlkmA5gndhcaTbRtRJjjxDOei8EO/FKQ5SRN6XuBNSdZxK0Pq5DiOryEXFOiw7al8wvaMbU3ven0K/T9Fy0UfaX8SwI+Xhhq5oeOQ9OrFiIJLbJ06EHZVtFb+j8jlHb8V8= Received: by 10.67.108.27 with SMTP id k27mr3798132ugm; Sun, 14 May 2006 21:28:33 -0700 (PDT) Received: by 10.67.22.18 with HTTP; Sun, 14 May 2006 21:28:33 -0700 (PDT) Message-ID: <30b660a20605142128r855d172y93d5e77d99fa0bc2@mail.gmail.com> Date: Sun, 14 May 2006 21:28:33 -0700 From: "Mark Davis" To: ltru@lists.ietf.org, ltru@ietf.org In-Reply-To: <30b660a20605141622m35d83c81id98411eae9e15730@mail.gmail.com> MIME-Version: 1.0 References: <30b660a20605141622m35d83c81id98411eae9e15730@mail.gmail.com> X-Google-Sender-Auth: 526100a398b6e02a X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [Ltru] Re: CLDR mapping X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0201159276==" Errors-To: ltru-bounces@ietf.org --===============0201159276== Content-Type: multipart/alternative; boundary="----=_Part_23209_22822585.1147667313875" ------=_Part_23209_22822585.1147667313875 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline QXBvbG9naWVzLCB0aGUgbGluayB3b24ndCB3b3JrIGZvciB5b3U7IHRyeToKCmh0dHA6Ly9kZXYu aWN1LXByb2plY3Qub3JnL2NnaS1iaW4vbG9jYWxlLWJ1Z3M/ZmluZGlkPTc5MyNyZXBsaWVzCgpO b3RlOiB0aGUgbGFzdCBiaXQgaGFzIGEgY291cGxlIG9mIHR5cG9zLiBEcmFmdCBsYW5ndWFnZSBp cyBhdCB0aGUgZW5kIG9mCnNlY3Rpb24gMzoKCmh0dHA6Ly93d3cudW5pY29kZS5vcmcvZHJhZnQv cmVwb3J0cy90cjM1L3RyMzUuaHRtbCNMb2NhbGVfSURzCgpNYXJrCgpPbiA1LzE0LzA2LCBNYXJr IERhdmlzIDxtYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZz4gd3JvdGU6Cj4KPiBJIHdhcyBqdXN0 IG1ha2luZyBkcmFmdCBjaGFuZ2VzIHRvIExETUwgKHVzZWQgZm9yIENMRFIpIGluIHJlc3BvbnNl IHRvIGEKPiBidWcgdG8gdXBkYXRlIHRvIFJGQzMwNjZiaXMgKHdlIHRob3VnaHQgd2UnZCBoYXZl IGEgZmluYWwgbnVtYmVyIGJ5IG5vdywgYnV0Cj4gbm8gc3VjaCBsdWNrISkuIEkgaGF2ZSBkcmFm dCBsYW5ndWFnZSBhdAo+Cj4gaHR0cDovL2Rldi5pY3UtcHJvamVjdC5vcmcvY2dpLWJpbi9jbGRy L2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVzCj4KPiBBbnkgZmVlZGJhY2sgaXMgd2Vs Y29tZTsgdGhlIGNvbW1pdHRlZSB3aWxsIGJlIGxvb2tpbmcgYXQgdGhpcyBvbiBUdWVzZGF5Cj4g bW9ybmluZy4KPgo+IEJUVywgZnJvbSB0aGUgbGFuZ3VhZ2UgcGFydCBvZiBhIENMRFIgbG9jYWxl IElELCBpZiBteSBzdWdnZXN0aW9ucyBhcmUKPiB0YWtlbiB1cCBvbmx5IHRoZSB2YXJpYW50IHN1 YnRhZ3Mge1BPU0lYLCBSRVZJU0VELCBTQUFIT30gYXJlIG1pc3NpbmcgZnJvbQo+IDMwNjZiaXMs IHBsdXMgc29tZSBVTiBNLjQ5IGNvZGVzLgo+Cj4gTWFyawo+Cj4K ------=_Part_23209_22822585.1147667313875 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline QXBvbG9naWVzLCB0aGUgbGluayB3b24ndCB3b3JrIGZvciB5b3U7IHRyeTo8YnI+PGJyPjxhIGhy ZWY9Imh0dHA6Ly9kZXYuaWN1LXByb2plY3Qub3JnL2NnaS1iaW4vbG9jYWxlLWJ1Z3M/ZmluZGlk PTc5MyNyZXBsaWVzIiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVu RXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiPmh0dHA6Ly9kZXYuaWN1LXByb2plY3Qub3JnL2Nn aS1iaW4vbG9jYWxlLWJ1Z3M/ZmluZGlkPTc5MyNyZXBsaWVzCjwvYT48YnI+PGJyPk5vdGU6IHRo ZSBsYXN0IGJpdCBoYXMgYSBjb3VwbGUgb2YgdHlwb3MuIERyYWZ0IGxhbmd1YWdlIGlzIGF0IHRo ZSBlbmQgb2Ygc2VjdGlvbiAzOgo8YnI+PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cudW5pY29kZS5v cmcvZHJhZnQvcmVwb3J0cy90cjM1L3RyMzUuaHRtbCNMb2NhbGVfSURzIiB0YXJnZXQ9Il9ibGFu ayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcyki Pmh0dHA6Ly93d3cudW5pY29kZS5vcmcvZHJhZnQvcmVwb3J0cy90cjM1L3RyMzUuaHRtbCNMb2Nh bGVfSURzPC9hPjxicj4KPGJyPk1hcms8YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiA1LzE0LzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+TWFyayBEYXZpczwv Yj4gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrLmRhdmlzQGljdS1wcm9qZWN0Lm9yZyI+bWFyay5k YXZpc0BpY3UtcHJvamVjdC5vcmc8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAy MDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+ CjxkaXY+SSB3YXMganVzdCBtYWtpbmcgZHJhZnQgY2hhbmdlcyB0byBMRE1MICh1c2VkIGZvciBD TERSKSBpbiByZXNwb25zZSB0byBhIGJ1ZyB0byB1cGRhdGUKdG8gUkZDMzA2NmJpcyAod2UgdGhv dWdodCB3ZSdkIGhhdmUgYSBmaW5hbCBudW1iZXIgYnkgbm93LCBidXQgbm8gc3VjaApsdWNrISku IEkgaGF2ZSBkcmFmdCBsYW5ndWFnZSBhdDxicj48YnI+PGEgaHJlZj0iaHR0cDovL2Rldi5pY3Ut cHJvamVjdC5vcmcvY2dpLWJpbi9jbGRyL2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVz IiB0YXJnZXQ9Il9ibGFuayIgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5k b3csZXZlbnQsdGhpcykiPmh0dHA6Ly9kZXYuaWN1LXByb2plY3Qub3JnL2NnaS1iaW4vY2xkci9s b2NhbGUtYnVncy1wcml2YXRlL2RhdGEjcmVwbGllcwo8L2E+PGJyPjxicj5BbnkgZmVlZGJhY2sg aXMgd2VsY29tZTsgdGhlIGNvbW1pdHRlZSB3aWxsIGJlIGxvb2tpbmcgYXQgdGhpcyBvbiBUdWVz ZGF5IG1vcm5pbmcuCjxicj48YnI+QlRXLCBmcm9tIHRoZSBsYW5ndWFnZSBwYXJ0IG9mIGEgQ0xE UiBsb2NhbGUgSUQsIGlmIG15IHN1Z2dlc3Rpb25zIGFyZSB0YWtlbiB1cCBvbmx5IHRoZSB2YXJp YW50IHN1YnRhZ3Mge1BPU0lYPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Ij4s IDwvc3Bhbj5SRVZJU0VEPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7Ij4sIDwv c3Bhbj4KU0FBSE99IGFyZSBtaXNzaW5nIGZyb20gMzA2NmJpcywgcGx1cyBzb21lIFVOIApNLjQ5 IGNvZGVzLjxicj48L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJzZyI+PGJyPk1hcms8YnI+Cjxicj4K PC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+Cg== ------=_Part_23209_22822585.1147667313875-- --===============0201159276== 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 --===============0201159276==-- From ltru-bounces@ietf.org Mon May 15 13:36:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfgzP-0008Bx-Lc; Mon, 15 May 2006 13:36:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfgzP-0008Bs-1c for ltru@ietf.org; Mon, 15 May 2006 13:36:15 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfgzM-00083R-FC for ltru@ietf.org; Mon, 15 May 2006 13:36:15 -0400 Received: by ug-out-1314.google.com with SMTP id m2so544149uge for ; Mon, 15 May 2006 10:36:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=RSyG5VU9uI08n0SXypaOcQgb8NcTISMV5vQBUObr2P6mcpFk5VeALda9Dy0MbDDmF+V6+GR1djQKZ6Bt1GvwtBbwWM0N80z/Y/H0nw76CFvP/pgV8Qg1Hh7/CnSN4up1tkg5gJKs7dPmT0qEYu1xorFFT/R7Fq85Rab38knjg1A= Received: by 10.67.129.5 with SMTP id g5mr2501956ugn; Mon, 15 May 2006 10:36:11 -0700 (PDT) Received: by 10.67.22.18 with HTTP; Mon, 15 May 2006 10:36:11 -0700 (PDT) Message-ID: <30b660a20605151036h2879e550u70e8026b9e297b10@mail.gmail.com> Date: Mon, 15 May 2006 10:36:11 -0700 From: "Mark Davis" To: "Kent Karlsson" , "LTRU Working Group" Subject: Re: [Ltru] Re: CLDR mapping In-Reply-To: <001f01c677fa$1e36e040$6500a8c0@chalmers95a69n> MIME-Version: 1.0 References: <30b660a20605142128r855d172y93d5e77d99fa0bc2@mail.gmail.com> <001f01c677fa$1e36e040$6500a8c0@chalmers95a69n> X-Google-Sender-Auth: bf568d520b6920cb X-Spam-Score: 0.1 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0436422187==" Errors-To: ltru-bounces@ietf.org --===============0436422187== Content-Type: multipart/alternative; boundary="----=_Part_28530_5173289.1147714571526" ------=_Part_28530_5173289.1147714571526 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline Q29tbWVudHMgYmVsb3cuCgpPbiA1LzE1LzA2LCBLZW50IEthcmxzc29uIDxrZW50Lmthcmxzc29u MTRAY29taGVtLnNlPiB3cm90ZToKPgo+ICA+IFdlIGFsc28gaGF2ZToKPiA+IEJPS01BTAo+ID4g TllOT1JTSwo+ID4gQUFMQU5ECj4gQm9rbcOlbCBOb3J3ZWdpYW4gYW5kIE5ldyBOb3J3ZWdpYW4g aGF2ZSB0aGVpciBvd24gbGFuZ3VhZ2UgY29kZXMgbm93LCBzbwo+IEknZCBwcmVmZXIKPiBkZXBy ZWNhdGluZy9yZW1vdmluZyB0aGVzZSB2YXJpYW50cyBhcyBtdWNoIGFzIHBvc3NpYmxlLiDDhWxh bmQgaGFzIGl0J3MKPiBvd24gdGVycml0b3J5IGNvZGUKPiBub3csIHNvIGFnYWluIEknZCBwcmVm ZXIgZGVwcmVjYXRpbmcvcmVtb3ZpbmcgdGhhdCB2YXJpYW50IGFzIG11Y2ggYXMKPiBwb3NzaWJs ZS4KPgoKVGhleSBhcmUgZGVwcmVjYXRlZC4gSWYgeW91IGxvb2sgYXQgdGhlIHRleHQgaW4gdGhl IGRyYWZ0IG9mIHRyMzUsIHlvdSdsbApzZWUgdGhhdCBkaXNjdXNzZWQgYXMgcGFydCBvZiB0aGUg cHJvY2VzcyBvZiBwcm9kdWNpbmcgYSAzMDY2YmlzIGNvZGUuCgoKPiBQcml2YXRlL0RlcHJlY2F0 ZWQgRGF0YSBmb3I6IHRlcnJpdG9yeSBRVSBFdXJvcGVhbiBVbmlvbiBbUFJJVkFURSBVU0UsCj4g PiAyMDA1LTEwLTE2LCBdCj4gRVUgaGFzIGFuICJleGNlcHRpb25hbGx5IHJlc2VydmVkIiB0ZXJy aXRvcnkgY29kZSAoRVUpLiBTbyB3aHkgbm90IHVzZQo+IHRoYXQgb25lPwo+CgpCZWNhdXNlIGl0 IGlzIGlsbGVnYWwgaW4gMzA2NmJpcy4gTm90IGF0IGFsbCB0aGUgcmlnaHQgZGVjaXNpb24sIGlu IG15Cm9waW5pb24sIHNpbmNlIHdlIGFyZSBmb3JjZWQgdG8gdXNlIGEgUFUgY29kZSB3aGljaCB3 aWxsIGluZXZpdGFibHkgZ2V0CmV4Y2hhbmdlZCBwdWJsaWNseS4gVGhlIHNhbWUgZ29lcyBmb3Ig c29tZSBVTiBNLjQ5IGNvZGVzLgoKPiBDTERSIExvY2FsZSBJRHMgY2FuIGJlIGNvbnZlcnRlZCB0 byB2YWxpZCBSRkMgMzA2NmJpcyBsYW5ndWFnZSB0YWdzIGJ5Cj4gPiBwZXJmb3JtaW5nIHRoZSBm b2xsb3dpbmcgdHJhbnNmb3JtYXRpb24uCj4gLi4uCj4gPiBUaHVzICJlbi1VUy1QT1NJWEBjYWxl bmRhcj1pc2xhbWljLGNvbGxhdGlvbj10cmFkaXRpb25hbCIgY29udmVydHMgdG8KPiA+ICJlbi1V Uy14LVBPU0lYLWstY2FsZW5kYXItaXNsYW1pYy1rLWNvbGxhdGlvbj10cmFkaXRpbyIuCj4gVW5s ZXNzIEkgbWlzc2VkIHNvbWV0aGluZywgIj0iIGlzbid0IGFsbG93ZWQgaW4gUkZDIDMwNjYgYmlz IGxhbmd1YWdlCj4gdGFncy4KPiBJIGd1ZXNzIHlvdSBtZWFudCB0aGUgc2Vjb25kICI9IiBhbHNv IHRvIGJlIHJlcGxhY2VkIHRvICItIi4KPgoKCllvdSBhcmUgbG9va2luZyBhdCBhIHN0YWxlIHZl cnNpb247IHRyeSBsb29raW5nIGF0Cmh0dHA6Ly93d3cudW5pY29kZS5vcmcvZHJhZnQvcmVwb3J0 cy90cjM1L3RyMzUuaHRtbCNMb2NhbGVfSURzIGFuZApyZWZyZXNoaW5nIHlvdXIgYnJvd3NlcnMu CgpJbiB0aGlzIGV4YW1wbGUgdGhlICItay0iIGFscmVhZHkgb2NjdXJzIGFmdGVyIGFuICIteC0i LCBidXQgaW4gY2FzZXMgd2hlcmUKPiB0aGF0IGlzIG5vdAo+IHRoZSBjYXNlLCBtYWtlIHN1cmUg dG8gaW5zZXJ0IGFuICIteC0iIGJlZm9yZSB0aGUgZmlyc3QgIi1rLSIsIGFzICItay0iIGlzCj4g bm90IHJlZ2lzdGVyZWQuCj4KPiAgICAgICAgIC9rZW50IGsKPgo+Cj4gIC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tCj4gKkZyb206KiBNYXJrIERhdmlzIFttYWlsdG86bWFyay5kYXZpc0BpY3Ut cHJvamVjdC5vcmddCj4gKlNlbnQ6KiBNb25kYXksIE1heSAxNSwgMjAwNiA2OjI5IEFNCj4gKlRv OiogbHRydUBsaXN0cy5pZXRmLm9yZzsgbHRydUBpZXRmLm9yZwo+ICpTdWJqZWN0OiogW0x0cnVd IFJlOiBDTERSIG1hcHBpbmcKPgo+IEFwb2xvZ2llcywgdGhlIGxpbmsgd29uJ3Qgd29yayBmb3Ig eW91OyB0cnk6Cj4KPiBodHRwOi8vZGV2LmljdS1wcm9qZWN0Lm9yZy9jZ2ktYmluL2xvY2FsZS1i dWdzP2ZpbmRpZD03OTMjcmVwbGllcwo+Cj4gTm90ZTogdGhlIGxhc3QgYml0IGhhcyBhIGNvdXBs ZSBvZiB0eXBvcy4gRHJhZnQgbGFuZ3VhZ2UgaXMgYXQgdGhlIGVuZCBvZgo+IHNlY3Rpb24gMzoK Pgo+IGh0dHA6Ly93d3cudW5pY29kZS5vcmcvZHJhZnQvcmVwb3J0cy90cjM1L3RyMzUuaHRtbCNM b2NhbGVfSURzCj4KPiBNYXJrCj4KPiBPbiA1LzE0LzA2LCBNYXJrIERhdmlzIDxtYXJrLmRhdmlz QGljdS1wcm9qZWN0Lm9yZz4gd3JvdGU6Cj4gPgo+ID4gSSB3YXMganVzdCBtYWtpbmcgZHJhZnQg Y2hhbmdlcyB0byBMRE1MICh1c2VkIGZvciBDTERSKSBpbiByZXNwb25zZSB0byBhCj4gPiBidWcg dG8gdXBkYXRlIHRvIFJGQzMwNjZiaXMgKHdlIHRob3VnaHQgd2UnZCBoYXZlIGEgZmluYWwgbnVt YmVyIGJ5IG5vdywgYnV0Cj4gPiBubyBzdWNoIGx1Y2shKS4gSSBoYXZlIGRyYWZ0IGxhbmd1YWdl IGF0Cj4gPgo+ID4gaHR0cDovL2Rldi5pY3UtcHJvamVjdC5vcmcvY2dpLWJpbi9jbGRyL2xvY2Fs ZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVzCj4gPgo+ID4KPiA+IEFueSBmZWVkYmFjayBpcyB3 ZWxjb21lOyB0aGUgY29tbWl0dGVlIHdpbGwgYmUgbG9va2luZyBhdCB0aGlzIG9uCj4gPiBUdWVz ZGF5IG1vcm5pbmcuCj4gPgo+ID4gQlRXLCBmcm9tIHRoZSBsYW5ndWFnZSBwYXJ0IG9mIGEgQ0xE UiBsb2NhbGUgSUQsIGlmIG15IHN1Z2dlc3Rpb25zIGFyZQo+ID4gdGFrZW4gdXAgb25seSB0aGUg dmFyaWFudCBzdWJ0YWdzIHtQT1NJWCwgUkVWSVNFRCwgU0FBSE99IGFyZSBtaXNzaW5nCj4gPiBm cm9tIDMwNjZiaXMsIHBsdXMgc29tZSBVTiBNLjQ5IGNvZGVzLgo+ID4KPiA+IE1hcmsKPiA+Cj4g Pgo+Cg== ------=_Part_28530_5173289.1147714571526 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Q29tbWVudHMgYmVsb3cuPGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24g NS8xNS8wNiwgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPktlbnQgS2FybHNzb248L2I+ICZs dDs8YSBocmVmPSJtYWlsdG86a2VudC5rYXJsc3NvbjE0QGNvbWhlbS5zZSI+a2VudC5rYXJsc3Nv bjE0QGNvbWhlbS5zZTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0 KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KPGRpdj4K CgoKCgo8ZGl2Pgo8ZGl2PjxzcGFuPiZndDsgPC9zcGFuPldlIGFsc28gaGF2ZTo8YnI+PHNwYW4+ Jmd0OyA8L3NwYW4+Qk9LTUFMPGJyPjxzcGFuPiZndDsgPC9zcGFuPk5ZTk9SU0s8YnI+PHNwYW4+ Jmd0OyA8L3NwYW4+QUFMQU5EPGJyPjwvZGl2Pgo8ZGl2PjxzcGFuPjxmb250IGNvbG9yPSIjMDAw MDgwIj5Cb2ttw6VsIE5vcndlZ2lhbiBhbmQgTmV3IApOb3J3ZWdpYW4gaGF2ZSB0aGVpciBvd24g bGFuZ3VhZ2UgY29kZXMgbm93LCBzbyBJJ2QgcHJlZmVyPC9mb250Pjwvc3Bhbj48L2Rpdj4KPGRp dj48c3Bhbj48Zm9udCBjb2xvcj0iIzAwMDA4MCI+ZGVwcmVjYXRpbmcvcmVtb3ZpbmcgCnRoZXNl IHZhcmlhbnRzIGFzIG11Y2ggYXMgcG9zc2libGUuIMOFbGFuZCBoYXMgaXQncyBvd24gdGVycml0 b3J5IApjb2RlPC9mb250Pjwvc3Bhbj48L2Rpdj4KPGRpdj48c3Bhbj48Zm9udCBjb2xvcj0iIzAw MDA4MCI+bm93LCBzbyBhZ2FpbiBJJ2QgcHJlZmVyIAo8c3Bhbj48Zm9udCBjb2xvcj0iIzAwMDA4 MCI+ZGVwcmVjYXRpbmcvcmVtb3ZpbmcgdGhhdCAKdmFyaWFudCBhcyBtdWNoIGFzIHBvc3NpYmxl LjwvZm9udD48L3NwYW4+PC9mb250Pjwvc3Bhbj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVv dGU+PGRpdj48YnI+VGhleSBhcmUgZGVwcmVjYXRlZC4gSWYgeW91IGxvb2sgYXQgdGhlIHRleHQg aW4gdGhlIGRyYWZ0IG9mIHRyMzUsIHlvdSdsbCBzZWUgdGhhdCBkaXNjdXNzZWQgYXMgcGFydCBv ZiB0aGUgcHJvY2VzcyBvZiBwcm9kdWNpbmcgYSAzMDY2YmlzIGNvZGUuCjxicj4mbmJzcDs8L2Rp dj48YnI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6 IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7 IHBhZGRpbmctbGVmdDogMWV4OyI+PGRpdj48ZGl2PjxkaXY+PHNwYW4+PHNwYW4+Jmd0OyAKUHJp dmF0ZS9EZXByZWNhdGVkIERhdGEgZm9yOiB0ZXJyaXRvcnkJUVUJRXVyb3BlYW4gVW5pb24JW1BS SVZBVEUgVVNFLDxicj4mZ3Q7IAoyMDA1LTEwLTE2LCBdPGJyPjwvc3Bhbj48L3NwYW4+PC9kaXY+ CjxkaXY+PHNwYW4+PHNwYW4+PGZvbnQgY29sb3I9IiMwMDAwODAiIGZhY2U9IkFyaWFsIFVuaWNv ZGUgTVMiPkVVIGhhcyBhbiAmcXVvdDtleGNlcHRpb25hbGx5IHJlc2VydmVkJnF1b3Q7IAp0ZXJy aXRvcnkgY29kZSAoRVUpLiBTbyB3aHkgbm90IHVzZSB0aGF0IG9uZT88L2ZvbnQ+PC9zcGFuPjwv c3Bhbj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+QmVjYXVzZSBpdCBp cyBpbGxlZ2FsIGluIDMwNjZiaXMuIE5vdCBhdCBhbGwgdGhlIHJpZ2h0IGRlY2lzaW9uLCBpbiBt eSBvcGluaW9uLCBzaW5jZSB3ZSBhcmUgZm9yY2VkIHRvIHVzZSBhIFBVIGNvZGUgd2hpY2ggd2ls bCBpbmV2aXRhYmx5IGdldCBleGNoYW5nZWQgcHVibGljbHkuIFRoZSBzYW1lIGdvZXMgZm9yIHNv bWUgVU4gCk0uNDkgY29kZXMuPGJyPjwvZGl2Pjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsg bWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij48ZGl2PjxkaXY+ PGRpdj48c3Bhbj48c3Bhbj4mZ3Q7IENMRFIgCkxvY2FsZSBJRHMgY2FuIGJlIGNvbnZlcnRlZCB0 byB2YWxpZCBSRkMgMzA2NmJpcyBsYW5ndWFnZSB0YWdzIGJ5PGJyPiZndDsgCnBlcmZvcm1pbmcg dGhlIGZvbGxvd2luZyB0cmFuc2Zvcm1hdGlvbi48YnI+Li4uPC9zcGFuPjwvc3Bhbj48L2Rpdj4K PGRpdj48c3Bhbj48c3Bhbj4mZ3Q7IFRodXMgCiZxdW90O2VuLVVTLVBPU0lYQGNhbGVuZGFyPWlz bGFtaWMsY29sbGF0aW9uPXRyYWRpdGlvbmFsJnF1b3Q7IGNvbnZlcnRzIHRvPGJyPiZndDsgCiZx dW90O2VuLVVTLXgtUE9TSVgtay1jYWxlbmRhci1pc2xhbWljLWstY29sbGF0aW9uPXRyYWRpdGlv JnF1b3Q7Ljxicj48L3NwYW4+PC9zcGFuPjwvZGl2Pgo8ZGl2PjxzcGFuPjxzcGFuPjxmb250IGNv bG9yPSIjMDAwMDgwIiBmYWNlPSJBcmlhbCBVbmljb2RlIE1TIj5Vbmxlc3MgSSBtaXNzZWQgc29t ZXRoaW5nLCAmcXVvdDs9JnF1b3Q7IGlzbid0IAphbGxvd2VkIGluIFJGQyAzMDY2IGJpcyBsYW5n dWFnZSB0YWdzLjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZGl2Pgo8ZGl2PjxzcGFuPjxzcGFuPjxm b250IGNvbG9yPSIjMDAwMDgwIj5JIGd1ZXNzIHlvdSBtZWFudCB0aGUgc2Vjb25kICZxdW90Oz0m cXVvdDsgYWxzbyB0byBiZSByZXBsYWNlZCB0byAKJnF1b3Q7LSZxdW90Oy48L2ZvbnQ+PC9zcGFu Pjwvc3Bhbj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PGJyPllvdSBh cmUgbG9va2luZyBhdCBhIHN0YWxlIHZlcnNpb247IHRyeSBsb29raW5nIGF0IDxhIGhyZWY9Imh0 dHA6Ly93d3cudW5pY29kZS5vcmcvZHJhZnQvcmVwb3J0cy90cjM1L3RyMzUuaHRtbCNMb2NhbGVf SURzIj5odHRwOi8vd3d3LnVuaWNvZGUub3JnL2RyYWZ0L3JlcG9ydHMvdHIzNS90cjM1Lmh0bWwj TG9jYWxlX0lEcwo8L2E+IGFuZCByZWZyZXNoaW5nIHlvdXIgYnJvd3NlcnMuPGJyPjwvZGl2Pjxi cj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4 IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFk ZGluZy1sZWZ0OiAxZXg7Ij48ZGl2PjxkaXY+PGRpdj48c3Bhbj48c3Bhbj48Zm9udCBjb2xvcj0i IzAwMDA4MCI+CkluIHRoaXMgZXhhbXBsZSB0aGUgJnF1b3Q7LWstJnF1b3Q7IGFscmVhZHkgb2Nj dXJzIGFmdGVyIGFuICZxdW90Oy14LSZxdW90OywgYnV0IGluIApjYXNlcyB3aGVyZSB0aGF0IGlz IDwvZm9udD48L3NwYW4+PC9zcGFuPjxzcGFuPjxzcGFuPjxmb250IGNvbG9yPSIjMDAwMDgwIj5u b3Q8L2ZvbnQ+PC9zcGFuPjwvc3Bhbj48L2Rpdj4KPGRpdj48c3Bhbj48c3Bhbj48Zm9udCBjb2xv cj0iIzAwMDA4MCI+dGhlIGNhc2UsIDwvZm9udD48L3NwYW4+PC9zcGFuPjxzcGFuPjxzcGFuPjxm b250IGNvbG9yPSIjMDAwMDgwIj5tYWtlIApzdXJlIHRvIGluc2VydCBhbiAmcXVvdDsteC0mcXVv dDsgYmVmb3JlIHRoZSBmaXJzdCAmcXVvdDstay0mcXVvdDssIGFzICZxdW90Oy1rLSZxdW90OyBp cyBub3QgCnJlZ2lzdGVyZWQuPC9mb250Pjwvc3Bhbj48L3NwYW4+PC9kaXY+CjxkaXY+PHNwYW4+ PHNwYW4+PGZvbnQgY29sb3I9IiMwMDAwODAiPjwvZm9udD48L3NwYW4+PC9zcGFuPiZuYnNwOzwv ZGl2Pgo8ZGl2PjxzcGFuPjxzcGFuPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8Zm9udCBjb2xvcj0iIzAwMDA4MCI+L2tlbnQgazwvZm9udD48L3NwYW4+PC9zcGFu PjwvZGl2PjwvZGl2PjxkaXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzEwYjM3MmRjOWI4OWIwMDlf MSI+CjxkaXY+PHNwYW4+PHNwYW4+PGZvbnQgY29sb3I9IiMwMDAwODAiPjwvZm9udD4mbmJzcDs8 L3NwYW4+PC9zcGFuPjwvZGl2Pgo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLWxlZnQ6IDJweCBz b2xpZCByZ2IoMCwgMCwgMTI4KTsgcGFkZGluZy1sZWZ0OiA1cHg7IG1hcmdpbi1sZWZ0OiA1cHg7 IG1hcmdpbi1yaWdodDogMHB4OyI+CiAgPGRpdj48L2Rpdj4KICA8ZGl2IGRpcj0ibHRyIiBhbGln bj0ibGVmdCIgbGFuZz0iZW4tdXMiPjxmb250IGZhY2U9IlRhaG9tYSIgc2l6ZT0iMiI+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+PGI+RnJvbTo8L2I+IE1hcmsgRGF2aXMgCiAgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmciIHRhcmdldD0iX2Js YW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlz KSI+bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmc8L2E+XSA8YnI+PGI+U2VudDo8L2I+IE1vbmRh eSwgTWF5IDE1LCAyMDA2IDY6MjkgCiAgQU08YnI+PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86 bHRydUBsaXN0cy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3Au anMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5sdHJ1QGxpc3RzLmlldGYub3JnPC9h PjsgPGEgaHJlZj0ibWFpbHRvOmx0cnVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNr PSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+Cmx0cnVAaWV0 Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBbTHRydV0gCiAgUmU6IENMRFIgbWFwcGluZzxi cj48YnI+PC9mb250PjwvZGl2PkFwb2xvZ2llcywgdGhlIGxpbmsgd29uJ3Qgd29yayBmb3IgeW91 OyAKICB0cnk6PGJyPjxicj48YSBocmVmPSJodHRwOi8vZGV2LmljdS1wcm9qZWN0Lm9yZy9jZ2kt YmluL2xvY2FsZS1idWdzP2ZpbmRpZD03OTMjcmVwbGllcyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xp Y2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8v ZGV2LmljdS1wcm9qZWN0Lm9yZy9jZ2ktYmluL2xvY2FsZS1idWdzP2ZpbmRpZD03OTMjcmVwbGll cyAKICA8L2E+PGJyPjxicj5Ob3RlOiB0aGUgbGFzdCBiaXQgaGFzIGEgY291cGxlIG9mIHR5cG9z LiBEcmFmdCBsYW5ndWFnZSBpcyBhdCB0aGUgCiAgZW5kIG9mIHNlY3Rpb24gMzogPGJyPjxicj48 YSBocmVmPSJodHRwOi8vd3d3LnVuaWNvZGUub3JnL2RyYWZ0L3JlcG9ydHMvdHIzNS90cjM1Lmh0 bWwjTG9jYWxlX0lEcyIgdGFyZ2V0PSJfYmxhbmsiIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3Bl bkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIj5odHRwOi8vd3d3LnVuaWNvZGUub3JnL2RyYWZ0 L3JlcG9ydHMvdHIzNS90cjM1Lmh0bWwjTG9jYWxlX0lEcwo8L2E+PGJyPjxicj5NYXJrPGJyPjxi cj4KICA8ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gNS8xNC8wNiwgPGIgY2xhc3M9 ImdtYWlsX3NlbmRlcm5hbWUiPk1hcmsgCiAgRGF2aXM8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86 bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmciIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1 cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+bWFyay5kYXZpc0BpY3Ut cHJvamVjdC5vcmc8L2E+Jmd0OyAKICB3cm90ZTo8L3NwYW4+CiAgPGJsb2NrcXVvdGUgY2xhc3M9 ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQs IDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+CiAg ICA8ZGl2Pkkgd2FzIGp1c3QgbWFraW5nIGRyYWZ0IGNoYW5nZXMgdG8gTERNTCAodXNlZCBmb3Ig Q0xEUikgaW4gcmVzcG9uc2UgdG8gCiAgICBhIGJ1ZyB0byB1cGRhdGUgdG8gUkZDMzA2NmJpcyAo d2UgdGhvdWdodCB3ZSdkIGhhdmUgYSBmaW5hbCBudW1iZXIgYnkgbm93LCAKICAgIGJ1dCBubyBz dWNoIGx1Y2shKS4gSSBoYXZlIGRyYWZ0IGxhbmd1YWdlIGF0PGJyPjxicj48YSBocmVmPSJodHRw Oi8vZGV2LmljdS1wcm9qZWN0Lm9yZy9jZ2ktYmluL2NsZHIvbG9jYWxlLWJ1Z3MtcHJpdmF0ZS9k YXRhI3JlcGxpZXMiIHRhcmdldD0iX2JsYW5rIiBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5F eHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSI+aHR0cDovL2Rldi5pY3UtcHJvamVjdC5vcmcvY2dp LWJpbi9jbGRyL2xvY2FsZS1idWdzLXByaXZhdGUvZGF0YSNyZXBsaWVzIAogICAgPC9hPjxicj48 YnI+QW55IGZlZWRiYWNrIGlzIHdlbGNvbWU7IHRoZSBjb21taXR0ZWUgd2lsbCBiZSBsb29raW5n IGF0IHRoaXMgCiAgICBvbiBUdWVzZGF5IG1vcm5pbmcuIDxicj48YnI+QlRXLCBmcm9tIHRoZSBs YW5ndWFnZSBwYXJ0IG9mIGEgQ0xEUiBsb2NhbGUgSUQsIAogICAgaWYgbXkgc3VnZ2VzdGlvbnMg YXJlIHRha2VuIHVwIG9ubHkgdGhlIHZhcmlhbnQgc3VidGFncyB7UE9TSVg8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6IG1vbm9zcGFjZTsiPiwgPC9zcGFuPlJFVklTRUQ8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IG1vbm9zcGFjZTsiPiwgPC9zcGFuPlNBQUhPfSBhcmUgbWlzc2luZyBmcm9tIDMw NjZiaXMsIAogICAgcGx1cyBzb21lIFVOIE0uNDkgY29kZXMuPGJyPjwvZGl2PgogICAgPGRpdj48 c3Bhbj48YnI+TWFyazxicj48YnI+PC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+ PC9ibG9ja3F1b3RlPjwvc3Bhbj48L2Rpdj48ZGl2PjwvZGl2PgoKPC9kaXY+PC9ibG9ja3F1b3Rl PjwvZGl2Pjxicj4K ------=_Part_28530_5173289.1147714571526-- --===============0436422187== 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 --===============0436422187==-- From ltru-bounces@ietf.org Tue May 16 05:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfwD7-0007sQ-Bk; Tue, 16 May 2006 05:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfwD6-0007sL-9V for ltru@ietf.org; Tue, 16 May 2006 05:51:24 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfwD5-0003tG-HR for ltru@ietf.org; Tue, 16 May 2006 05:51:24 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k4G9pEdm025785 for ; Tue, 16 May 2006 18:51:14 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 779b_831dcddc_e4c1_11da_8693_0014221f2a2d; Tue, 16 May 2006 18:51:13 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4G9o9qe007748 for ; Tue, 16 May 2006 18:50:48 +0900 Message-Id: <6.0.0.20.2.20060516170754.09692b00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 16 May 2006 18:48:44 +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: ed68cc91cc637fea89623888898579ba Subject: [Ltru] 2nd WG last call: reduce 'could', 'would', 'might' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, for this and following mails, unless explicitly indicating the contrary] This is something I have been working on continuously, with not too much success, but I'm trying it again: There are many instances where 'might', 'could', or 'would' is used, but isn't necessary. This is particularly frequent in examples. If something is declared as an example, there is no need to use conditional language, it's already prefectly clear that it's just an example. I hope that with the changes below, the document will read more like a spec and less like speculation :-). [sometimes, some other word also needs to be changed, e.g. from past/conditional to present] Please change as proposed below: Applications, protocols, or specifications, in addressing their particular requirements, can offer pre-processing or configuration options. For example, an implementation could allow a user to associate or map a particular language range to a different value. could -> can Or perhaps the user could associate the range "zh-Hans" (Chinese as written in the Simplified script) with the language tag "zh-CN" (Chinese as used in China, where the Simplified script is predominant) because content is available with that tag. could -> will (maybe also change 'the user' to 'a user') 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. could -> can, were -> is, included -> includes, would be -> is (two times) 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"). "would be read" -> "is read" (or "reads") An example of this would be the use of "q" values in the syntax of the "Accept-Language" header (defined in [RFC2616], Section 14.4, and [RFC3282]). "would be" -> "is" An extended language range is mapped to a basic language range as follows: if the first subtag is a '*' then the entire range is treated as "*", otherwise each wildcard subtag is removed. For example, if the language range were "en-*-US", then the range would be mapped to "en-US". "were" -> "is", "would be" -> "is" For example, if a particular user's language priority list were "fr-FR, zh-Hant" and the program doing the matching had a default language range of "ja-JP", the program would search as follows: "were" -> "is", "would search" -> "searches" 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. might -> can, would -> will For example, if a process were to insert a human readable error message into a protocol header, it might select the text based on the user's language priority list. 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. were to insert -> inserts, might select -> can select The wildcard subtag '*' can occur in any position in the extended language range, where it matches any sequence of subtags that might occur in that position in a language tag. might occur -> occur Filtering can be used to produce a set of results (such as a collection of documents) by comparing the user's preferences to a set of language tags. For example, when performing a search, one might use filtering to limit the results to items tagged as being in the French language. Filtering can also be used when deciding whether to perform a language-sensitive process on some content. For example, a process might cause paragraphs whose language tag matched the language range "nl" to be displayed in italics within a document. might -> can (two times), matched -> match Lookup produces the single result that best matches the user's preferences from the list of available tags, so it is useful in cases in which a single item is required (and for which only a single item can be returned). For example, if a process were to insert a human readable error message into a protocol header, it might select the text based on the user's language priority list. 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. were to insert -> inserts, might select -> selects o For lookup, what the default item is (or the sequence of operations or configuration information used to determine the default) when no matching tag is found. For instance, a protocol might define the result as failure of the operation, an empty value, returning some protocol defined or implementation defined default, or returning i-default [RFC2277]. might -> can Some examples of applications where filtering might be appropriatd 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"). "would be read" -> "is read" (or "reads") An example of this would be the use of "q" values in the syntax of the "Accept-Language" header (defined in [RFC2616], Section 14.4, and [RFC3282]). "would be" -> "is" An extended language range is mapped to a basic language range as follows: if the first subtag is a '*' then the entire range is treated as "*", otherwise each wildcard subtag is removed. For example, if the language range were "en-*-US", then the range would be mapped to "en-US". "were" -> "is", "would be" -> "is" For example, if a particular user's language priority list were "fr-FR, zh-Hant" and the program doing the matching had a default language range of "ja-JP", the program would search as follows: "were" -> "is", "would search" -> "searches" 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. might -> can, would -> will For example, if a process were to insert a human readable error message into a protocol header, it might select the text based on the user's language priority list. 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. were to insert -> inserts, might select -> can select The wildcard subtag '*' can occur in any position in the extended language range, where it matches any sequence of subtags that might occur in that position in a language tag. might occur -> occur Filtering can be used to produce a set of results (such as a collection of documents) by comparing the user's preferences to a set of language tags. For example, when performing a search, one might use filtering to limit the results to items tagged as being in the French language. Filtering can also be used when deciding whether to perform a language-sensitive process on some content. For example, a process might cause paragraphs whose language tag matched the language range "nl" to be displayed in italics within a document. might -> can (two times), matched -> match Lookup produces the single result that best matches the user's preferences from the list of available tags, so it is useful in cases in which a single item is required (and for which only a single item can be returned). For example, if a process were to insert a human readable error message into a protocol header, it might select the text based on the user's language priority list. 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. were to insert -> inserts, might select -> selects o For lookup, what the default item is (or the sequence of operations or configuration information used to determine the default) when no matching tag is found. For instance, a protocol might define the result as failure of the operation, an empty value, returning some protocol defined or implementation defined default, or returning i-default [RFC2277]. might -> can Some examples of applications where filtering might be appropriate include: might -> can (or will?) For example, if an application inserts some dynamic content into a document, returning an empty string if there is no exact match is not an option. Instead, the application "falls back" until it finds a matching language tag associated with a suitable piece of content to insert. Examples of lookup might include: might include -> include Extensions and unrecognized private-use subtags might be unrelated to a particular application of lookup. Since these subtags come at the end of the subtag sequence, they are removed first during the fallback process and usually pose no barrier to interoperability. might be -> can be Such modification is internal to the implementation and applications, protocols, or specifications SHOULD NOT remove or modify subtags in content that they return or forward, because this removes information that might be used elsewhere. might be -> can be In some cases, the language priority list might contain one or more extended language ranges (as, for example, when the same language priority list is used as input for both lookup and filtering operations). might contain -> can contain Each application, protocol, or specification MUST define the defaulting behavior when no tag matches the language priority list. What this action consists of strongly depends on how lookup is being applied. Some examples of defaulting behavior might include: might include -> include The default value MAY be calculated and might include additional searching or matching. Applications, protocols, or specifications can specify different ways in which users can specify or override the defaults. might -> can Applications are encouraged to canonicalize language tags and ranges by using the Preferred-Value from the IANA Language Subtag Registry for tags or subtags which have been deprecated. If the user is working with content that might use the older form, the user might want to 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, so the user might use it to form the language range. Or the user might include both in a language priority list: "jbo, art-lojban". four 'might' in a single paragraph, please reduce 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. might -> can Whether a subtag adds distinguishing value can depend on the context of the request. For example, a user who reads both Simplified and Traditional Chinese, but who prefers Simplified, might use the range "zh" for filtering (matching all items that user can read) but "zh- Hans" for lookup (making sure that user 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 available under a simple "zh". might use -> can use There is also a lower-case should, which we should remove. Maybe write "preferably also is made available under a simple "zh"." Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 05:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfwDB-0007sZ-Ec; Tue, 16 May 2006 05:51:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfwD9-0007sU-LP for ltru@ietf.org; Tue, 16 May 2006 05:51:27 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfwD9-0003tW-0v for ltru@ietf.org; Tue, 16 May 2006 05:51:27 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k4G9pP7a025794 for ; Tue, 16 May 2006 18:51:26 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 77b8_8a348836_e4c1_11da_92a6_0014221f2a2d; Tue, 16 May 2006 18:51:25 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4G9oaP3007751 for ; Tue, 16 May 2006 18:51:00 +0900 Message-Id: <6.0.0.20.2.20060516165017.09639d80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 16 May 2006 17:00:49 +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: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Ltru] 2nd WG last call: leftover X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 leftover from the previous last call: [co-chair hat off] In http://www1.ietf.org/mail-archive/web/ltru/current/msg04779.html, as point J, I wrote: 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. >>>>>>>> To this, Addison had a simple +1 at http://www1.ietf.org/mail-archive/web/ltru/current/msg04784.html. But this paragraph currently reads: 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. This change was due to a last call comment from Randy, but it leaves the problem in the first sentence that I pointed out originally. Please fix. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 06:42:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx0h-0003Ly-En; Tue, 16 May 2006 06:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx0g-0003Lm-QH for ltru@ietf.org; Tue, 16 May 2006 06:42:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffx0g-0006PQ-Oo for ltru@ietf.org; Tue, 16 May 2006 06:42:38 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfwxD-0003qI-1S for ltru@ietf.org; Tue, 16 May 2006 06:39:06 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k4GAd1gn029328 for ; Tue, 16 May 2006 19:39:01 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 22ef_303897d0_e4c8_11da_9e86_0014221fa3c9; Tue, 16 May 2006 19:39:00 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4GAc60j008452 for ; Tue, 16 May 2006 19:38:35 +0900 Message-Id: <6.0.0.20.2.20060516192715.09693580@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 16 May 2006 19:36:49 +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.4 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [Ltru] 2nd WG last call: expanding 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 One of the editing guidelines that I think we have adopted is that we always make clear what the codes in the examples mean. There are a few cases where we forgot: For example, a process might cause paragraphs whose language tag matched the language range "nl" to be displayed in italics within a document. Note that canonicalizing language ranges makes certain operations impossible. For example, an implementation that canonicalizes the language range "art-lojban" to use the more modern "jbo" cannot be used to select just the items with the older tag. An extended language range is mapped to a basic language range as follows: if the first subtag is a '*' then the entire range is treated as "*", otherwise each wildcard subtag is removed. For example, if the language range were "en-*-US", then the range would be mapped to "en-US". For example, if the language priority list consists of the range "de-CH", one might see tags such as "de-CH-1996" but one will never see a tag such as "de" (because the 'CH' subtag is missing). For example, the language-range "de-de" matches the language tag "de-DE-1996", but not the language tags "de- Deva" or "de-Latn-DE". The following list (at least those that we didn't explain previously) de-DE de-Latn-DE de-Latf-DE de-de de-DE-x-goethe de-Latn-DE-1996 de-Deva-DE 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') For example, starting with the range "zh-Hant-CN-x-private1-private2", the lookup progressively searches for content as shown below: 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. For example, if a particular user's language priority list were "fr-FR, zh-Hant" and the program doing the matching had a default language range of "ja-JP", the program would search as follows: [I have not mentioned all the repetitions of the same tag, because I don't think giving the same explanations every time is necessary.] Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 06:42:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx0h-0003Lu-CI; Tue, 16 May 2006 06:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx0g-0003LV-O6 for ltru@ietf.org; Tue, 16 May 2006 06:42:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffx0g-0006PQ-Mc for ltru@ietf.org; Tue, 16 May 2006 06:42:38 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfwxD-0003qE-1R for ltru@ietf.org; Tue, 16 May 2006 06:39:08 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k4GAcxXF029320 for ; Tue, 16 May 2006 19:38:59 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 784b_2ef15ace_e4c8_11da_8e25_0014221f2a2d; Tue, 16 May 2006 19:38:59 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4GAc60d008452 for ; Tue, 16 May 2006 19:38:33 +0900 Message-Id: <6.0.0.20.2.20060516191028.09692b00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 16 May 2006 19:18:50 +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: -1.6 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ltru] 2nd WG last call: Abstract X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 abstract is one of the most important pieces of a document. Given this, I feel that ours could need some work. I have felt that way for a long time, but I thought I'd wait until the content doesn't change anymore. The abstract currently reads: 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. Which effectively just is: 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 XXXX, replaces RFC 3066, which replaced RFC 1766. I propose to change this as follows: This document describes a syntax, called language-range, for indicating language preferences, and different mechanisms for comparing and matching language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a potentially empty list of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 3066bis (Ed.: replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 06:42:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx0g-0003LR-9c; Tue, 16 May 2006 06:42:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx0e-0003L6-KM for ltru@ietf.org; Tue, 16 May 2006 06:42:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffx0e-0006PQ-Ij for ltru@ietf.org; Tue, 16 May 2006 06:42:36 -0400 Received: from suomi.kotus.fi ([193.166.18.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfwyB-0003rK-Vz for ltru@ietf.org; Tue, 16 May 2006 06:40:09 -0400 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 k4GAdw6G016219; Tue, 16 May 2006 13:39:58 +0300 (EEST) Message-ID: <4469ABFA.3010907@kotus.fi> Date: Tue, 16 May 2006 13:39:54 +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] 2nd WG Last Call for draft-ietf-ltru-matching References: <6.0.0.20.2.20060502185911.099e0c10@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 have read the document and I haven't found any particular issues with it. The editorial comments that I might have made appear to have been dealt with. Sincerely, Erkki I. Kolehmainen Martin Duerst wrote: > Dear LTRU WG, > > Many of you have expected a Second WG Last Call, and here it is. > Sorry for the delay due to personal reasons. > > I have looked through the discussion of the previous last call, > and tried to keep track of everything at > http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. > If somebody thinks something is missing (or wrong), or would like > some details to be added, or has some questions, please tell me. > The substantive changes require another WG Last Call. > > The duration of this Last Call is two (2) weeks, it will end on > Tuesday, May 16, 11:00 UTC (20:00 Japan, 13:00 France,..., > 4:00am US Pacific, and so on). > > Please read the draft at > http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt > carefully and send in comments, with a subject indicating > the issue. Please also send in a comment if you have read the > draft and haven't found any issue. > > If you have read earlier drafts, please note that this draft > is a serious revision, better read on its own. > > I hope that this time, we can successfully complete this last call > and send the draft to the IESG. > > > 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 Tue May 16 06:42:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx0h-0003Lu-CI; Tue, 16 May 2006 06:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx0g-0003LV-O6 for ltru@ietf.org; Tue, 16 May 2006 06:42:38 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffx0g-0006PQ-Mc for ltru@ietf.org; Tue, 16 May 2006 06:42:38 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfwxD-0003qE-1R for ltru@ietf.org; Tue, 16 May 2006 06:39:08 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k4GAcxXF029320 for ; Tue, 16 May 2006 19:38:59 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 784b_2ef15ace_e4c8_11da_8e25_0014221f2a2d; Tue, 16 May 2006 19:38:59 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4GAc60d008452 for ; Tue, 16 May 2006 19:38:33 +0900 Message-Id: <6.0.0.20.2.20060516191028.09692b00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 16 May 2006 19:18:50 +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: -1.6 (-) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ltru] 2nd WG last call: Abstract X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 abstract is one of the most important pieces of a document. Given this, I feel that ours could need some work. I have felt that way for a long time, but I thought I'd wait until the content doesn't change anymore. The abstract currently reads: 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. Which effectively just is: 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 XXXX, replaces RFC 3066, which replaced RFC 1766. I propose to change this as follows: This document describes a syntax, called language-range, for indicating language preferences, and different mechanisms for comparing and matching language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a potentially empty list of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 3066bis (Ed.: replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 06:42:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx0g-0003LR-9c; Tue, 16 May 2006 06:42:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx0e-0003L6-KM for ltru@ietf.org; Tue, 16 May 2006 06:42:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffx0e-0006PQ-Ij for ltru@ietf.org; Tue, 16 May 2006 06:42:36 -0400 Received: from suomi.kotus.fi ([193.166.18.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfwyB-0003rK-Vz for ltru@ietf.org; Tue, 16 May 2006 06:40:09 -0400 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 k4GAdw6G016219; Tue, 16 May 2006 13:39:58 +0300 (EEST) Message-ID: <4469ABFA.3010907@kotus.fi> Date: Tue, 16 May 2006 13:39:54 +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] 2nd WG Last Call for draft-ietf-ltru-matching References: <6.0.0.20.2.20060502185911.099e0c10@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 have read the document and I haven't found any particular issues with it. The editorial comments that I might have made appear to have been dealt with. Sincerely, Erkki I. Kolehmainen Martin Duerst wrote: > Dear LTRU WG, > > Many of you have expected a Second WG Last Call, and here it is. > Sorry for the delay due to personal reasons. > > I have looked through the discussion of the previous last call, > and tried to keep track of everything at > http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. > If somebody thinks something is missing (or wrong), or would like > some details to be added, or has some questions, please tell me. > The substantive changes require another WG Last Call. > > The duration of this Last Call is two (2) weeks, it will end on > Tuesday, May 16, 11:00 UTC (20:00 Japan, 13:00 France,..., > 4:00am US Pacific, and so on). > > Please read the draft at > http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-12.txt > carefully and send in comments, with a subject indicating > the issue. Please also send in a comment if you have read the > draft and haven't found any issue. > > If you have read earlier drafts, please note that this draft > is a serious revision, better read on its own. > > I hope that this time, we can successfully complete this last call > and send the draft to the IESG. > > > 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 Tue May 16 06:46:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx3w-0004Qi-Eh; Tue, 16 May 2006 06:46:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx3v-0004Qd-Bt for ltru@ietf.org; Tue, 16 May 2006 06:45:59 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffx3u-0006dP-Qn for ltru@ietf.org; Tue, 16 May 2006 06:45:59 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k4GAjvml029783 for ; Tue, 16 May 2006 19:45:57 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 2294_281e5264_e4c9_11da_920b_0014221fa3c9; Tue, 16 May 2006 19:45:56 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4GAj2im008561 for ; Tue, 16 May 2006 19:45:32 +0900 Message-Id: <6.0.0.20.2.20060516193723.09640af0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 16 May 2006 19:44:03 +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: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] Please Comment on Matching Draft 2nd WG Last Call X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear WG Members, [co-chair hat on] The 2nd WG Last Call for the matching draft ends at the top of the hour. So far, we have not received many comments. In many ways, this may be a good sign, because it can mean there is not much anymore to fix in this draft, we are ready to submit it to the IESG. However, it may also mean that just very few people have read the draft, which would mean that it has not yet received enough review. As there were quite some significant changes from the previous version (-11), it is important that we make sure that enough people have read the draft carefully. So, if you have read the draft and not found any issues, please say so on the mailing list (or privately to the chairs if you prefer). You can do so even after the deadline has passed. I would in particular like to hear from those people who made comments on the first Last Call. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 07:32:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffxn7-0007hm-0V; Tue, 16 May 2006 07:32:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffxn5-0007hX-P7 for ltru@ietf.org; Tue, 16 May 2006 07:32:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffx0g-0006PN-RM for ltru@ietf.org; Tue, 16 May 2006 06:42:38 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfwxC-0003qG-Bm for ltru@ietf.org; Tue, 16 May 2006 06:39:04 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k4GAd0hB008605 for ; Tue, 16 May 2006 19:39:00 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 784b_2fa1bc98_e4c8_11da_8e25_0014221f2a2d; Tue, 16 May 2006 19:39:00 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4GAc60h008452 for ; Tue, 16 May 2006 19:38:34 +0900 Message-Id: <6.0.0.20.2.20060516174019.096997a0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 16 May 2006 19:37:10 +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: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Ltru] 2nd WG last call: Language improvement X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 somehow the 'misc' bucket of my comments.] Here is a sentence that I think is too complicated: This 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. 'that' and 'than' in the same sentence, and the length of the sentence, make this difficult to read. I propose: This fallback behavior allows some flexibility in finding a match. Without fallback, in the case that content that exactly matches is not available, the default content would be returned immediately. The fallback in lookup will make sure that a better result (i.e. content more closely matching the user request) is made available if it exists. (any other fix that keeps the meaning while simplifying the long sentence is also okay with me) Here's some typo: since these ranges will won't match any valid language tags. will won't -> will not The first para in the introduction: Human beings on our planet have, past and present, used a number of languages. There are many reasons why one would want to identify the language used when presenting or requesting information or in some specific set of information items. Every time I read this, I have problems parsing the second sentence. What about rewording as follows: There are many reasons why one wants to identify the language used when presenting or requesting information, or the language used in some specific set of information items. Just before 3.4: This is the reason why a wildcard in the extended language range is significant in the first position and subsequently ignored. I think this is easier to read if it says: This is the reason why a wildcard in the extended language range is significant in the first position, but is subsequently ignored. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 07:38:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffxsk-0000mN-4g; Tue, 16 May 2006 07:38:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffxsi-0000mI-HK for ltru@ietf.org; Tue, 16 May 2006 07:38:28 -0400 Received: from mta5.iomartmail.com ([62.128.193.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffxsg-0000jO-3f for ltru@ietf.org; Tue, 16 May 2006 07:38:28 -0400 Received: from mta5.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta5.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k4GBcK25008507; Tue, 16 May 2006 12:38:20 +0100 Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) (authenticated bits=0) by mta5.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k4GBcJ2F008456; Tue, 16 May 2006 12:38:19 +0100 From: "Debbie Garside" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] Please Comment on Matching Draft 2nd WG Last Call Date: Tue, 16 May 2006 12:38:18 +0100 Message-ID: <05fc01c678dd$3aeffdf0$0400a8c0@debbie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcZ41ewIDqIxJ52yQNaeZLTk828O/QABxLow X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <6.0.0.20.2.20060516193723.09640af0@localhost> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi Martin I have read the draft in detail and have no further comments to make. Best regards Debbie Garside -----Original Message----- From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] Sent: 16 May 2006 11:44 To: LTRU Working Group Subject: [Ltru] Please Comment on Matching Draft 2nd WG Last Call Dear WG Members, [co-chair hat on] The 2nd WG Last Call for the matching draft ends at the top of the hour. So far, we have not received many comments. In many ways, this may be a good sign, because it can mean there is not much anymore to fix in this draft, we are ready to submit it to the IESG. However, it may also mean that just very few people have read the draft, which would mean that it has not yet received enough review. As there were quite some significant changes from the previous version (-11), it is important that we make sure that enough people have read the draft carefully. So, if you have read the draft and not found any issues, please say so on the mailing list (or privately to the chairs if you prefer). You can do so even after the deadline has passed. I would in particular like to hear from those people who made comments on the first 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 Tue May 16 07:39:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffxtk-00017G-Ju; Tue, 16 May 2006 07:39:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffxtj-00017B-My for ltru@ietf.org; Tue, 16 May 2006 07:39:31 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffx0g-0006PN-PJ for ltru@ietf.org; Tue, 16 May 2006 06:42:38 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfwxC-0003qF-Bm for ltru@ietf.org; Tue, 16 May 2006 06:39:05 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k4GAcxwl008599 for ; Tue, 16 May 2006 19:38:59 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 784b_2f3c6c58_e4c8_11da_8e25_0014221f2a2d; Tue, 16 May 2006 19:38:59 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4GAc60f008452 for ; Tue, 16 May 2006 19:38:34 +0900 Message-Id: <6.0.0.20.2.20060516191930.096380d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 16 May 2006 19:24:34 +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: -1.0 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] 2nd WG last call: singletons don't match X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 the only last call comment that I have that is potentially substantive: In section 3.3.2, Extended Filtering, point D says: D. Else, if the language tag's subtag is a "singleton" (a single letter or digit, which includes the private-use subtag 'x') the match fails. The way I understand this, this makes it impossible e.g. to match the language range "en-US-x-private" to the language tag "en-US-x-private". In my recollection, this was different even just as late as the previous draft (-11). My questions here: Is my interpretation of the current text correct? Is my recollection of the state in -11 and earlier correct? If the answer to both questions above is yes, then do we really want things to work this way? Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 07:40:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfxuW-0001DY-Uu; Tue, 16 May 2006 07:40:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfxuU-0001DP-Tp for ltru@ietf.org; Tue, 16 May 2006 07:40:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffx0g-0006PN-Mc for ltru@ietf.org; Tue, 16 May 2006 06:42:38 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfwxC-0003qD-Bm for ltru@ietf.org; Tue, 16 May 2006 06:39:06 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k4GAcwY3008592 for ; Tue, 16 May 2006 19:38:58 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 2339_2e8d35a8_e4c8_11da_8584_0014221fa3c9; Tue, 16 May 2006 19:38:57 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4GAc60b008452 for ; Tue, 16 May 2006 19:38:32 +0900 Message-Id: <6.0.0.20.2.20060516184846.096a3ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 16 May 2006 19:07:29 +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: -1.1 (-) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [Ltru] 2nd WG last call: lower-case may/should/must X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org These are the lower-case may/should/must in the main text that I found. There is no IETF rule that forbids these that I'm aware of, but as we tried hard to avoid them, we can as well do the full job. If not, we can as well change back many 'might's to simple 'may's. A speaker of Breton in France, for example, may specify "br" followed by "fr", meaning that if Breton is available, it is preferred, but otherwise French is the best alternative. It can get more complex: a user may wish to fall back from Skolt Sami to Northern Sami to Finnish. may specify -> can specify may wish to -> wants to When working with language ranges and matching schemes, there are some additional points that may influence the choice of either. may -> can 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 do not necessarily represent mutually intelligible languages. change " and users should not that" to ": ". Also, while at it, change "the set of language tags that match" to "the language tags that match", to make this match with "do" later in the sentence. The result of these edits would be: 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: the language tags that match a specific language range do not necessarily represent mutually intelligible languages. Whether a subtag adds distinguishing value can depend on the context of the request. For example, a user who reads both Simplified and Traditional Chinese, but who prefers Simplified, might use the range "zh" for filtering (matching all items that user can read) but "zh- Hans" for lookup (making sure that user 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 available under a simple "zh". should be labeled -> preferabily is labeled should also be available -> preferably also is made available Language tags permit only the characters A-Z, a-z, 0-9, and HYPHEN- MINUS (%x2D). Language ranges also use the character ASTERISK (%x2A). These characters are present in most character sets, so presentation or exchange of language tags or ranges should not be constrained by character set issues. should not be -> is not Lookup produces the single result that best matches the user's preferences from the list of available tags, so it is useful in cases in which a single item is required (and for which only a single item can be returned). For example, if a process were to insert a human readable error message into a protocol header, it might select the text based on the user's language priority list. 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. must -> has to (twice) Very special thanks must go to Harald Tveit Alvestrand, who originated RFCs 1766 and 3066, and without whom this document would not have been possible. [I can live with that, since it's clearly outside the normative part of the spec.] Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 07:53:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffy7H-0004qJ-NK; Tue, 16 May 2006 07:53:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffy7G-0004q5-3t for ltru@ietf.org; Tue, 16 May 2006 07:53:30 -0400 Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffy7D-00026Q-I7 for ltru@ietf.org; Tue, 16 May 2006 07:53:30 -0400 Received: from spam.cs.tut.fi (spam-eth1.lintula [10.11.18.2]) by mail.cs.tut.fi (Postfix) with ESMTP id 5A7E2B8A for ; Tue, 16 May 2006 14:32:17 +0300 (EEST) Received: from mail.cs.tut.fi ([130.230.4.42]) by spam.cs.tut.fi (spam.cs.tut.fi [10.11.18.2]) (amavisd-new, port 10024) with ESMTP id 26092-02-3 for ; Tue, 16 May 2006 14:32:17 +0300 (EEST) Received: from korppi.cs.tut.fi (korppi.cs.tut.fi [130.230.4.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 254F29AE for ; Tue, 16 May 2006 14:32:16 +0300 (EEST) Date: Tue, 16 May 2006 14:32:16 +0300 (EEST) From: "Jukka K. Korpela" To: LTRU Working Group Subject: Re: [Ltru] 2nd WG last call: Abstract In-Reply-To: <6.0.0.20.2.20060516191028.09692b00@localhost> Message-ID: References: <6.0.0.20.2.20060516191028.09692b00@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: amavisd-new at cs.tut.fi X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Tue, 16 May 2006, Martin Duerst wrote: > I propose to change this as follows: > > This document describes a syntax, called language-range, for indicating > language preferences, and different mechanisms for comparing and > matching language tags. Two kinds of matching mechanisms, filtering > and lookup, are defined. Filtering produces a potentially empty list > of language tags, whereas lookup produces a single language tag. > Possible applications include language negotiation or content selection. Looks much more informative. In the last sentence of the part that I quoted, I think the order should be different, corresponding to the order in which filtering (which is usually for content selection) and lookup have been mentioned, and "and" would sound like a more suitable conjunction than "or": "Possible applications include content selection and language negotiation." -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 09:02:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzCN-0006bR-S1; Tue, 16 May 2006 09:02:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzCN-0006bH-5d for ltru@ietf.org; Tue, 16 May 2006 09:02:51 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzCL-0005H9-PG for ltru@ietf.org; Tue, 16 May 2006 09:02:51 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FfzCJ-0004gl-B8; Tue, 16 May 2006 09:02:47 -0400 Date: Tue, 16 May 2006 09:02:47 -0400 To: Martin Duerst Subject: Re: [Ltru] 2nd WG last call: reduce 'could', 'would', 'might' Message-ID: <20060516130247.GL31206@ccil.org> References: <6.0.0.20.2.20060516170754.09692b00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060516170754.09692b00@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: -1. Not clear why on this one either. > Please change as proposed below: Some of these changes generate forms that, to a native anglophone ear, are unnatural English. Anything I don't mention here, I approve of without comment. > Or perhaps the user could associate the > range "zh-Hans" (Chinese as written in the Simplified script) with > the language tag "zh-CN" (Chinese as used in China, where the > Simplified script is predominant) because content is available with > that tag. > > could -> will (maybe also change 'the user' to 'a user') Unnatural. Better: "a user will want to" > 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. > > could -> can, were -> is, included -> includes, would be -> is (two > times) -1. This should be left firmly conditional. > 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"). > > "would be read" -> "is read" (or "reads") +1. "is read" is preferable. > An extended language range is mapped to a basic language range as > follows: if the first subtag is a '*' then the entire range is > treated as "*", otherwise each wildcard subtag is removed. For > example, if the language range were "en-*-US", then the range would > be mapped to "en-US". > > "were" -> "is", "would be" -> "is" +1 in principle. Better: 'For example, a language range of "en-*-US" is mapped to "en-US".' > Filtering can be used to produce a set of results (such as a > collection of documents) by comparing the user's preferences to a set > of language tags. For example, when performing a search, one might > use filtering to limit the results to items tagged as being in the > French language. Filtering can also be used when deciding whether to > perform a language-sensitive process on some content. For example, a > process might cause paragraphs whose language tag matched the > language range "nl" to be displayed in italics within a document. > > might -> can (two times), matched -> match "Match" would be outright ungrammatical, but "matches" works. I doubt this is worth changing. +1 on might -> can. > o For lookup, what the default item is (or the sequence of > operations or configuration information used to determine the > default) when no matching tag is found. For instance, a protocol > might define the result as failure of the operation, an empty > value, returning some protocol defined or implementation defined > default, or returning i-default [RFC2277]. > > might -> can -1. This should be left alone for reasons I can't quite explain (a matter of Sprachgefuehl). > Some examples of applications where filtering might be appropriate > include: > > might -> can (or will?) -1. This should definitely be left alone. Both "can" and "will" are too strong. > For example, if an application inserts some dynamic content into a > document, returning an empty string if there is no exact match is not > an option. Instead, the application "falls back" until it finds a > matching language tag associated with a suitable piece of content to > insert. Examples of lookup might include: > > might include -> include Better: "Possible applications of lookup include:" > Extensions and unrecognized private-use subtags might be unrelated to > a particular application of lookup. Since these subtags come at the > end of the subtag sequence, they are removed first during the > fallback process and usually pose no barrier to interoperability. > > might be -> can be -1. That changes meaning. > Such modification is internal to the > implementation and applications, protocols, or specifications SHOULD > NOT remove or modify subtags in content that they return or forward, > because this removes information that might be used elsewhere. > > might be -> can be +1, even though this too changes meaning. > Applications are encouraged to canonicalize language tags and ranges > by using the Preferred-Value from the IANA Language Subtag Registry > for tags or subtags which have been deprecated. If the user is > working with content that might use the older form, the user might > want to 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, so the user might use it to > form the language range. Or the user might include both in a > language priority list: "jbo, art-lojban". > > four 'might' in a single paragraph, please reduce I think the last can be changed to "can include", but the rest should stand: the first one is about a speculation (on what exists in the unsearched data); the second and third express mere possibility and would be "may" if that word weren't effectively pre-empted. > Whether a subtag adds distinguishing value can depend on the context > of the request. For example, a user who reads both Simplified and > Traditional Chinese, but who prefers Simplified, might use the range > "zh" for filtering (matching all items that user can read) but "zh- > Hans" for lookup (making sure that user 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 available under a simple > "zh". > > might use -> can use -1. This is mere possibility, so "might" is appropriate (see above). > There is also a lower-case should, which we should remove. > Maybe write "preferably also is made available under a simple "zh"." -1. That is very clunky. I propose "ought also to be available". -- It was impossible to inveigle John Cowan Georg Wilhelm Friedrich Hegel http://www.ccil.org/~cowan Into offering the slightest apology For his Phenomenology. --W. H. Auden, from "People" (1953) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 09:08:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzHe-00088s-Q2; Tue, 16 May 2006 09:08:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzHd-00088n-Uf for ltru@ietf.org; Tue, 16 May 2006 09:08:17 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzHd-0005YK-MG for ltru@ietf.org; Tue, 16 May 2006 09:08:17 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FfzHd-0004rK-Ek; Tue, 16 May 2006 09:08:17 -0400 Date: Tue, 16 May 2006 09:08:17 -0400 To: Martin Duerst Subject: Re: [Ltru] 2nd WG last call: lower-case may/should/must Message-ID: <20060516130817.GM31206@ccil.org> References: <6.0.0.20.2.20060516184846.096a3ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060516184846.096a3ec0@localhost> User-Agent: Mutt/1.3.28i From: John Cowan 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 Martin Duerst scripsit: > These are the lower-case may/should/must in the main text that > I found. There is no IETF rule that forbids these that I'm aware > of, but as we tried hard to avoid them, we can as well do the > full job. If not, we can as well change back many 'might's to > simple 'may's. As before, anything omitted is a simple +1. > A speaker of Breton in France, for example, may specify > "br" followed by "fr", meaning that if Breton is available, it is > preferred, but otherwise French is the best alternative. It can get > more complex: a user may wish to fall back from Skolt Sami to > Northern Sami to Finnish. > > may specify -> can specify > may wish to -> wants to +1 on the first, but -1 on the second: omitting "may" altogether makes the sentence into a factual claim rather than a hypothetical one. "Might" is probably the best bet here. > Whether a subtag adds distinguishing value can depend on the context > of the request. For example, a user who reads both Simplified and > Traditional Chinese, but who prefers Simplified, might use the range > "zh" for filtering (matching all items that user can read) but "zh- > Hans" for lookup (making sure that user 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 available under a simple > "zh". > > should be labeled -> preferabily is labeled > should also be available -> preferably also is made available -1. Clunky. For the first, use "ought to be labeled"; for the second, use "also ought to be available. > Lookup produces the single result that best matches the user's > preferences from the list of available tags, so it is useful in cases > in which a single item is required (and for which only a single item > can be returned). For example, if a process were to insert a human > readable error message into a protocol header, it might select the > text based on the user's language priority list. 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. > > must -> has to (twice) "Needs to" makes the process less human and is preferable. -- You're a brave man! Go and break through the John Cowan lines, and remember while you're out there cowan@ccil.org risking life and limb through shot and shell, http://ccil.org/~cowan we'll be in here thinking what a sucker you are! --Rufus T. Firefly _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 09:09:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzIn-0008HK-LA; Tue, 16 May 2006 09:09:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzIn-0008HF-44 for ltru@ietf.org; Tue, 16 May 2006 09:09:29 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzIl-0005bj-TS for ltru@ietf.org; Tue, 16 May 2006 09:09:29 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FfzIl-0004uH-Ms; Tue, 16 May 2006 09:09:27 -0400 Date: Tue, 16 May 2006 09:09:27 -0400 To: Martin Duerst Subject: Re: [Ltru] 2nd WG last call: Abstract Message-ID: <20060516130927.GN31206@ccil.org> References: <6.0.0.20.2.20060516191028.09692b00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060516191028.09692b00@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > I propose to change this as follows: > > This document describes a syntax, called language-range, for > indicating > language preferences, and different mechanisms for comparing and > matching language tags. Two kinds of matching mechanisms, filtering > and lookup, are defined. Filtering produces a potentially empty list > of language tags, whereas lookup produces a single language tag. > Possible applications include language negotiation or content > selection. > This document, in combination with RFC 3066bis (Ed.: replace "3066bis" > with the RFC number assigned to draft-ietf-ltru-registry-14), replaces > RFC 3066, which replaced RFC 1766. +1 -- John Cowan http://www.ccil.org/~cowan But no living man am I! You look upon a woman. Eowyn I am, Eomund's daughter. You stand between me and my lord and kin. Begone, if you be not deathless. For living or dark undead, I will smite you if you touch him. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 09:10:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzJS-0008Th-4B; Tue, 16 May 2006 09:10:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzJQ-0008Tc-TZ for ltru@ietf.org; Tue, 16 May 2006 09:10:08 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzJP-0005dN-Nb for ltru@ietf.org; Tue, 16 May 2006 09:10:08 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FfzJP-0004vM-Bi; Tue, 16 May 2006 09:10:07 -0400 Date: Tue, 16 May 2006 09:10:07 -0400 To: "Jukka K. Korpela" Subject: Re: [Ltru] 2nd WG last call: Abstract Message-ID: <20060516131007.GO31206@ccil.org> References: <6.0.0.20.2.20060516191028.09692b00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Jukka K. Korpela scripsit: > "Possible applications include content selection and language > negotiation." +1 -- Schlingt dreifach einen Kreis vom dies! John Cowan Schliesst euer Aug vor heiliger Schau, http://www.ccil.org/~cowan Denn er genoss vom Honig-Tau, Und trank die Milch vom Paradies. -- Coleridge (tr. Politzer) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 09:10:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzK8-0000Is-AA; Tue, 16 May 2006 09:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzK6-0000In-ME for ltru@ietf.org; Tue, 16 May 2006 09:10:50 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzK5-0005eU-Fn for ltru@ietf.org; Tue, 16 May 2006 09:10:50 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FfzK5-0004wK-8l; Tue, 16 May 2006 09:10:49 -0400 Date: Tue, 16 May 2006 09:10:49 -0400 To: Martin Duerst Subject: Re: [Ltru] 2nd WG last call: expanding codes Message-ID: <20060516131049.GP31206@ccil.org> References: <6.0.0.20.2.20060516192715.09693580@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6.0.0.20.2.20060516192715.09693580@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > One of the editing guidelines that I think we have adopted > is that we always make clear what the codes in the examples > mean. There are a few cases where we forgot: +1 to all. -- Híggledy-pìggledy / XML programmers John Cowan Try to escape those / I-eighteen-N woes; http://www.ccil.org/~cowan Incontrovertibly / What we need more of is cowan@ccil.org Unicode weenies and / François Yergeaus. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 09:21:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzU1-0002qX-Ps; Tue, 16 May 2006 09:21:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzU1-0002qS-1D for ltru@ietf.org; Tue, 16 May 2006 09:21:05 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzTz-000663-Le for ltru@ietf.org; Tue, 16 May 2006 09:21:05 -0400 Received: from duringpersonlx (snvvpn1-10-72-72-c217.corp.yahoo.com [10.72.72.217]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4GDK6te040940; Tue, 16 May 2006 06:20:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=wIXwzwWXEAmIUZ3KblLUB48fpK7l4oWnSYNy1BVOgx97lK8AhF0N2S5PCuR393pJ From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] 2nd WG last call: singletons don't match Date: Tue, 16 May 2006 06:20:06 -0700 Message-ID: <001501c678eb$72f5b1f0$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.20060516191930.096380d0@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ43WhSaG1mrEwBSJS1yL9ZCeBu1AADayGg 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 Your interpretation of the text is wrong. Rule C says: "Else, if the current subtag in the range's list matches the current subtag in the language tag's list, move to the next subtag in both lists and continue with the loop." This means that ranges "en-US-x-private" and "en-x-private" both match the tag "en-US-x-private", but prevents the range "en-US-private" from matching "en-US-x-private" (private has a different semantic meaning there). 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?5?16? 3:25 > To: LTRU Working Group > Subject: [Ltru] 2nd WG last call: singletons don't match > > This is the only last call comment that I have that is potentially > substantive: > > In section 3.3.2, Extended Filtering, point D says: > > D. Else, if the language tag's subtag is a "singleton" (a single > letter or digit, which includes the private-use subtag 'x') > the match fails. > > The way I understand this, this makes it impossible e.g. to > match the language range "en-US-x-private" to the language tag > "en-US-x-private". > > In my recollection, this was different even just as late as the > previous draft (-11). > > My questions here: > > Is my interpretation of the current text correct? > > Is my recollection of the state in -11 and earlier correct? > > If the answer to both questions above is yes, then do we really > want things to work this way? > > > 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 Tue May 16 09:23:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzWd-0003bZ-Sz; Tue, 16 May 2006 09:23:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzWc-0003av-Je for ltru@ietf.org; Tue, 16 May 2006 09:23:46 -0400 Received: from mta5.iomartmail.com ([62.128.193.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzWb-0006E1-5R for ltru@ietf.org; Tue, 16 May 2006 09:23:46 -0400 Received: from mta5.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta5.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k4GDNZUD002861; Tue, 16 May 2006 14:23:35 +0100 Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) (authenticated bits=0) by mta5.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k4GDNYve002848; Tue, 16 May 2006 14:23:34 +0100 From: "Debbie Garside" To: "'John Cowan'" , "'Martin Duerst'" Subject: RE: [Ltru] 2nd WG last call: Abstract Date: Tue, 16 May 2006 14:23:34 +0100 Message-ID: <063001c678eb$ef1eab10$0400a8c0@debbie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcZ46ff+KkjZ4tXhQsahF2J7mqExYQAAbZ3g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <20060516130927.GN31206@ccil.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin wrote: > Filtering produces a potentially empty list > of language tags Do you really want to say this? Surely if the list is empty there are no tags! Debbie -----Original Message----- From: John Cowan [mailto:cowan@ccil.org] Sent: 16 May 2006 14:09 To: Martin Duerst Cc: LTRU Working Group Subject: Re: [Ltru] 2nd WG last call: Abstract Martin Duerst scripsit: > I propose to change this as follows: > > This document describes a syntax, called language-range, for > indicating > language preferences, and different mechanisms for comparing and > matching language tags. Two kinds of matching mechanisms, filtering > and lookup, are defined. Filtering produces a potentially empty list > of language tags, whereas lookup produces a single language tag. > Possible applications include language negotiation or content > selection. > This document, in combination with RFC 3066bis (Ed.: replace "3066bis" > with the RFC number assigned to draft-ietf-ltru-registry-14), replaces > RFC 3066, which replaced RFC 1766. +1 -- John Cowan http://www.ccil.org/~cowan But no living man am I! You look upon a woman. Eowyn I am, Eomund's daughter. You stand between me and my lord and kin. Begone, if you be not deathless. For living or dark undead, I will smite you if you touch him. _______________________________________________ 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 May 16 09:29:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzcG-0004c7-CW; Tue, 16 May 2006 09:29:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzcF-0004c2-MM for ltru@ietf.org; Tue, 16 May 2006 09:29:35 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzcF-0006Wf-GR for ltru@ietf.org; Tue, 16 May 2006 09:29:35 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1FfzcF-0005NB-7x; Tue, 16 May 2006 09:29:35 -0400 Date: Tue, 16 May 2006 09:29:35 -0400 To: Debbie Garside Subject: Re: [Ltru] 2nd WG last call: Abstract Message-ID: <20060516132935.GQ31206@ccil.org> References: <20060516130927.GN31206@ccil.org> <063001c678eb$ef1eab10$0400a8c0@debbie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <063001c678eb$ef1eab10$0400a8c0@debbie> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside scripsit: > Martin wrote: > > > Filtering produces a potentially empty list > > of language tags > > Do you really want to say this? Surely if the list is empty there are no > tags! Sure. It's like "a potentially empty bucket of clams"; if the bucket is empty (as when you've eaten every one) there are no clams. Empty lists are a very familiar concept to developers. -- Andrew Watt on Microsoft: John Cowan Never in the field of human computing cowan@ccil.org has so much been paid by so many http://www.ccil.org/~cowan to so few! (pace Winston Churchill) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 09:30:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzdZ-0005KV-4x; Tue, 16 May 2006 09:30:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfzdY-0005KQ-Or for ltru@ietf.org; Tue, 16 May 2006 09:30:56 -0400 Received: from mta3.iomartmail.com ([62.128.193.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzdX-0006aW-CI for ltru@ietf.org; Tue, 16 May 2006 09:30:56 -0400 Received: from mta3.iomartmail.com (localhost [127.0.0.1]) by mta3.iomartmail.com (8.12.8/8.12.8) with ESMTP id k4GDUlLQ021515; Tue, 16 May 2006 14:30:48 +0100 Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) (authenticated bits=0) by mta3.iomartmail.com (8.12.8/8.12.8) with ESMTP id k4GDUlge021489; Tue, 16 May 2006 14:30:47 +0100 From: "Debbie Garside" To: "'John Cowan'" Subject: RE: [Ltru] 2nd WG last call: Abstract Date: Tue, 16 May 2006 14:30:47 +0100 Message-ID: <063701c678ec$f1057700$0400a8c0@debbie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcZ47MbT/f8ofUzLRvWjpMBRc+kSDAAABWfA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <20060516132935.GQ31206@ccil.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org But empty lists are not lists at all... :-) -----Original Message----- From: John Cowan [mailto:cowan@ccil.org] Sent: 16 May 2006 14:30 To: Debbie Garside Cc: ltru@ietf.org Subject: Re: [Ltru] 2nd WG last call: Abstract Debbie Garside scripsit: > Martin wrote: > > > Filtering produces a potentially empty list > > of language tags > > Do you really want to say this? Surely if the list is empty there are > no tags! Sure. It's like "a potentially empty bucket of clams"; if the bucket is empty (as when you've eaten every one) there are no clams. Empty lists are a very familiar concept to developers. -- Andrew Watt on Microsoft: John Cowan Never in the field of human computing cowan@ccil.org has so much been paid by so many http://www.ccil.org/~cowan to so few! (pace Winston Churchill) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 09:43:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzq4-0001Gi-Ua; Tue, 16 May 2006 09:43:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzq3-0001Gd-Gm for ltru@ietf.org; Tue, 16 May 2006 09:43:51 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffzq2-0007Cy-8o for ltru@ietf.org; Tue, 16 May 2006 09:43:51 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1Ffzq0-0005kR-Cn; Tue, 16 May 2006 09:43:48 -0400 Date: Tue, 16 May 2006 09:43:48 -0400 To: Martin Duerst Subject: Re: [Ltru] 2nd WG last call: Language improvement Message-ID: <20060516134348.GS31206@ccil.org> References: <6.0.0.20.2.20060516174019.096997a0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060516174019.096997a0@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: As before, an omitted item means +1. This completes my review^2, since Addison already dealt with the substantive point. It can be hard to grasp what extended matching does: basically, it skips over subtags that it can prove have no counterparts on the other side of the match. But it cannot skip a singleton, as what appears to the right of a singleton doesn't obey the usual rules for subtag lengths. > Here is a sentence that I think is too complicated: > > This 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. > > 'that' and 'than' in the same sentence, and the length of the > sentence, > make this difficult to read. I propose: > > This fallback behavior allows some flexibility in finding a match. > Without fallback, in the case that content that exactly matches is > not available, the default content would be returned immediately. > The fallback in lookup will make sure that a better result (i.e. > content more closely matching the user request) is made available > if it exists. How about this: This fallback behavior allows some flexibility in finding a match. Without fallback, the default content would be returned immediately if exactly matching content is unavailable. With fallback, a result more closely matching the user request can be provided. > Just before 3.4: > > This is the reason why a wildcard in the > extended language range is significant in the first position and > subsequently ignored. > > I think this is easier to read if it says: > > This is the reason why a wildcard in the > extended language range is significant in the first position, but > is subsequently ignored. I propose "but is ignored in all other positions", to block the interpretation that "subsequently" refers to time rather than space. -- Unless it was by accident that I had John Cowan offended someone, I never apologized. cowan@ccil.org --Quentin Crisp http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 10:15:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0KC-00025x-EO; Tue, 16 May 2006 10:15:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0KB-00025s-8y for ltru@ietf.org; Tue, 16 May 2006 10:14:59 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0K8-0008SF-1Y for ltru@ietf.org; Tue, 16 May 2006 10:14:59 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060516141455.DNVE9009.mta11.adelphia.net@DGBP7M81> for ; Tue, 16 May 2006 10:14:55 -0400 Message-ID: <013101c678f3$1a202c60$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 16 May 2006 07:14:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ltru] Re: Please Comment on Matching Draft 2nd WG Last Call X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 the current draft, and have not found any problems significant enough to justify further delay. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ Editor, draft-ietf-ltru-initial-06 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 10:33:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0bf-0006lQ-Ml; Tue, 16 May 2006 10:33:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0bd-0006Zw-Pf for ltru@ietf.org; Tue, 16 May 2006 10:33:02 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0bc-0000r4-D8 for ltru@ietf.org; Tue, 16 May 2006 10:33:01 -0400 Received: from duringpersonlx (snvvpn1-10-72-72-c217.corp.yahoo.com [10.72.72.217]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4GEVlIn055534; Tue, 16 May 2006 07:31:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=ArMamJoO0Uh5FFew4GA/BsMWAiu5O1pm6vhn/iEaNU4j6xfwjdcvB1sL9rqRsZzZ From: "Addison Phillips" To: "'Debbie Garside'" , "'John Cowan'" , "'Martin Duerst'" Subject: RE: [Ltru] 2nd WG last call: Abstract Date: Tue, 16 May 2006 07:31:47 -0700 Message-ID: <001601c678f5$769f2660$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: <063001c678eb$ef1eab10$0400a8c0@debbie> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ46ff+KkjZ4tXhQsahF2J7mqExYQAAbZ3gAAJNe0A= X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > Do you really want to say this? Surely if the list is empty there are no > tags! Yes, exactly so: Lists may be empty. Technically, the word "set" would probably be more correct than the word "list". List implies something about the ordering of the values, while set contains no such implications. Some applications may choose to use a list, but this isn't strictly a requirement of the filtering algorithms. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: 2006?5?16? 6:24 > To: 'John Cowan'; 'Martin Duerst' > Cc: 'LTRU Working Group' > Subject: RE: [Ltru] 2nd WG last call: Abstract > > Martin wrote: > > > > Filtering produces a potentially empty list > > of language tags > > Do you really want to say this? Surely if the list is empty there are no > tags! > > Debbie > > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: 16 May 2006 14:09 > To: Martin Duerst > Cc: LTRU Working Group > Subject: Re: [Ltru] 2nd WG last call: Abstract > > Martin Duerst scripsit: > > > I propose to change this as follows: > > > > This document describes a syntax, called language-range, for > > indicating > > language preferences, and different mechanisms for comparing and > > matching language tags. Two kinds of matching mechanisms, filtering > > and lookup, are defined. Filtering produces a potentially empty list > > of language tags, whereas lookup produces a single language tag. > > Possible applications include language negotiation or content > > selection. > > This document, in combination with RFC 3066bis (Ed.: replace > "3066bis" > > with the RFC number assigned to draft-ietf-ltru-registry-14), > replaces > > RFC 3066, which replaced RFC 1766. > > +1 > > -- > John Cowan http://www.ccil.org/~cowan > But no living man am I! You look upon a woman. Eowyn I am, Eomund's > daughter. > You stand between me and my lord and kin. Begone, if you be not deathless. > For living or dark undead, I will smite you if you touch him. > > _______________________________________________ > 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 Tue May 16 10:44:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0mK-0001Q7-DK; Tue, 16 May 2006 10:44:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0mJ-0001Q2-4Y for ltru@ietf.org; Tue, 16 May 2006 10:44:03 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0mH-0001gq-Qs for ltru@ietf.org; Tue, 16 May 2006 10:44:03 -0400 Received: by ug-out-1314.google.com with SMTP id m2so743998uge for ; Tue, 16 May 2006 07:44:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=nV3ExuEy6FXm7w3NoCi7g8QRqbJs5DjPuaE81ILrrL8qd2D52Ka4oJze4LszssSayxfcF/CxKVc93l8ESS8KGYIyjv4jlP7sC66zcQaJ+1Y73WaoEsMaLXVXxpwlsJX5nbLw4YpA8k2XUmqHPAJcIi6xWvB6V8umo6M6mxT9JSc= Received: by 10.67.15.3 with SMTP id s3mr3367105ugi; Tue, 16 May 2006 07:44:00 -0700 (PDT) Received: by 10.67.22.18 with HTTP; Tue, 16 May 2006 07:44:00 -0700 (PDT) Message-ID: <30b660a20605160744g38185346x7ed8d8367746c80@mail.gmail.com> Date: Tue, 16 May 2006 07:44:00 -0700 From: "Mark Davis" To: "Doug Ewell" Subject: Re: [Ltru] Re: Please Comment on Matching Draft 2nd WG Last Call In-Reply-To: <013101c678f3$1a202c60$040aa8c0@DGBP7M81> MIME-Version: 1.0 References: <013101c678f3$1a202c60$040aa8c0@DGBP7M81> X-Google-Sender-Auth: 956838848c674ad5 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0813540090==" Errors-To: ltru-bounces@ietf.org --===============0813540090== Content-Type: multipart/alternative; boundary="----=_Part_38022_21412894.1147790640869" ------=_Part_38022_21412894.1147790640869 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline RGl0dG8KCk9uIDUvMTYvMDYsIERvdWcgRXdlbGwgPGRld2VsbEBhZGVscGhpYS5uZXQ+IHdyb3Rl Ogo+Cj4gSSBoYXZlIHJlYWQgdGhlIGN1cnJlbnQgZHJhZnQsIGFuZCBoYXZlIG5vdCBmb3VuZCBh bnkgcHJvYmxlbXMKPiBzaWduaWZpY2FudCBlbm91Z2ggdG8ganVzdGlmeSBmdXJ0aGVyIGRlbGF5 Lgo+Cj4gLS0KPiBEb3VnIEV3ZWxsCj4gRnVsbGVydG9uLCBDYWxpZm9ybmlhLCBVU0EKPiBodHRw Oi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvCj4gRWRpdG9yLCBkcmFmdC1pZXRmLWx0cnUt aW5pdGlhbC0wNgo+Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCj4gTHRydSBtYWlsaW5nIGxpc3QKPiBMdHJ1QGlldGYub3JnCj4gaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQo+Cg== ------=_Part_38022_21412894.1147790640869 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline RGl0dG88YnI+PGJyPjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiA1LzE2LzA2LCA8 YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+RG91ZyBFd2VsbDwvYj4gJmx0OzxhIGhyZWY9Im1h aWx0bzpkZXdlbGxAYWRlbHBoaWEubmV0Ij5kZXdlbGxAYWRlbHBoaWEubmV0PC9hPiZndDsgd3Jv dGU6PC9zcGFuPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1s ZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAu OGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgpJIGhhdmUgcmVhZCB0aGUgY3VycmVudCBkcmFmdCwg YW5kIGhhdmUgbm90IGZvdW5kIGFueSBwcm9ibGVtczxicj5zaWduaWZpY2FudCBlbm91Z2ggdG8g anVzdGlmeSBmdXJ0aGVyIGRlbGF5Ljxicj48YnI+LS08YnI+RG91ZyBFd2VsbDxicj5GdWxsZXJ0 b24sIENhbGlmb3JuaWEsIFVTQTxicj48YSBocmVmPSJodHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0 L35kZXdlbGwvIj5odHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvCjwvYT48YnI+RWRp dG9yLCBkcmFmdC1pZXRmLWx0cnUtaW5pdGlhbC0wNjxicj48YnI+PGJyPjxicj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5MdHJ1IG1haWxpbmcgbGlz dDxicj48YSBocmVmPSJtYWlsdG86THRydUBpZXRmLm9yZyI+THRydUBpZXRmLm9yZzwvYT48YnI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydSI+Cmh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnU8L2E+PGJyPjwvYmxvY2tx dW90ZT48L2Rpdj48YnI+Cg== ------=_Part_38022_21412894.1147790640869-- --===============0813540090== 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 --===============0813540090==-- From ltru-bounces@ietf.org Tue May 16 13:20:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg3DM-0005NU-Pv; Tue, 16 May 2006 13:20:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg3DL-0005Lt-Lu for ltru@ietf.org; Tue, 16 May 2006 13:20:07 -0400 Received: from mrout3.yahoo.com ([216.145.54.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg3DK-0002TN-9Z for ltru@ietf.org; Tue, 16 May 2006 13:20:07 -0400 Received: from duringpersonlx (wlanvpn-dfg-229-207.corp.yahoo.com [172.21.229.207]) by mrout3.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4GHI2Qt020396; Tue, 16 May 2006 10:18:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=cJCONVfViP2nprZb9HCi+6HC8X39iFgoIO6wsf9IsSIBhgNk0R/GejA/6jxRcU+Y From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] 2nd WG last call: leftover Date: Tue, 16 May 2006 10:18:02 -0700 Message-ID: <000601c6790c$b0616860$a8dd15ac@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.20060516165017.09639d80@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ4zl51lgdh3n1MRlGpHNUrYYQYiAAPkznA X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Done. 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?5?16? 1:01 > To: LTRU Working Group > Subject: [Ltru] 2nd WG last call: leftover > > This is a leftover from the previous last call: [co-chair hat off] > > In http://www1.ietf.org/mail-archive/web/ltru/current/msg04779.html, > as point J, I wrote: > > 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. > >>>>>>>> > > To this, Addison had a simple +1 at > http://www1.ietf.org/mail-archive/web/ltru/current/msg04784.html. > > > But this paragraph currently reads: > > 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. > > This change was due to a last call comment from Randy, but it leaves > the problem in the first sentence that I pointed out originally. > > Please fix. > > 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 Tue May 16 16:08:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg5po-00038Z-SS; Tue, 16 May 2006 16:08:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg5po-00038U-4D for ltru@ietf.org; Tue, 16 May 2006 16:08:00 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg5pn-0004Dc-Ex for ltru@ietf.org; Tue, 16 May 2006 16:08:00 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4GK7Gex007727; Tue, 16 May 2006 13:07:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=g2fI3sZHUcitTiEp20pLVwo6C/TKbYmVqlnt1kzQRx5nq/TKnJjLJBRceuJ+sX55 From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] 2nd WG last call: reduce 'could', 'would', 'might' Date: Tue, 16 May 2006 13:07:16 -0700 Message-ID: <000201c67924$545aacd0$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.2869 Thread-Index: AcZ4zmkwLB1oZbRPSqWtV4gZ5SpsNwAPlhag In-Reply-To: <6.0.0.20.2.20060516170754.09692b00@localhost> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 913ee11e7c554f7d4da75d500826397e Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org As usual, Martin, thank you for an excellent close reading of the document. Comments follow. ~Addison > > This is something I have been working on continuously, with not > too much success, but I'm trying it again: There are many > instances where 'might', 'could', or 'would' is used, but isn't necessary. > This is particularly frequent in examples. If something is declared > as an example, there is no need to use conditional language, > it's already prefectly clear that it's just an example. I'm not entirely happy to implement lots of editorial changes that make no difference. It seems that I use more of the "subjunctive mood" in my writing than most. In some cases, you'll have to live with it :-). > > > Please change as proposed below: > > Applications, protocols, or specifications, in addressing their > particular requirements, can offer pre-processing or configuration > options. For example, an implementation could allow a user to > associate or map a particular language range to a different value. > > could -> can I disagree. This is a speculative example. > > > Or perhaps the user could associate the > range "zh-Hans" (Chinese as written in the Simplified script) with > the language tag "zh-CN" (Chinese as used in China, where the > Simplified script is predominant) because content is available with > that tag. > > could -> will (maybe also change 'the user' to 'a user') Ditto. > > > 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. > > could -> can, were -> is, included -> includes, would be -> is (two > times) I disagree. I don't want to make this example anything less that suppositional. > > > 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"). > > "would be read" -> "is read" (or "reads") Done. > > > An example of this would be the use > of "q" values in the syntax of the "Accept-Language" header (defined > in [RFC2616], Section 14.4, and [RFC3282]). > > "would be" -> "is" Done. > > > An extended language range is mapped to a basic language range as > follows: if the first subtag is a '*' then the entire range is > treated as "*", otherwise each wildcard subtag is removed. For > example, if the language range were "en-*-US", then the range would > be mapped to "en-US". > > "were" -> "is", "would be" -> "is" > 'For example, the extended language range "en-*-US" maps to "en-US".' Nice to see that John Cowan's edit matched mine. > > For example, if a particular user's language priority list were > "fr-FR, zh-Hant" and the program doing the matching had a default > language range of "ja-JP", the program would search as follows: > > "were" -> "is", "would search" -> "searches" Done. > > > 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. > > might -> can, would -> will Done, with some minor differences. > > > For example, if a process were to insert a human > readable error message into a protocol header, it might select the > text based on the user's language priority list. 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. > > were to insert -> inserts, might select -> can select I don't think the changes would be correct. > > > The wildcard subtag '*' can occur in any position in the extended > language range, where it matches any sequence of subtags that might > occur in that position in a language tag. > > might occur -> occur Ditto. > > > Filtering can be used to produce a set of results (such as a > collection of documents) by comparing the user's preferences to a set > of language tags. For example, when performing a search, one might > use filtering to limit the results to items tagged as being in the > French language. Filtering can also be used when deciding whether to > perform a language-sensitive process on some content. For example, a > process might cause paragraphs whose language tag matched the > language range "nl" to be displayed in italics within a document. > > might -> can (two times), matched -> match For the first might->can, I chose to rewrite instead (to be in keeping with the form of the other sentences): -- For example, when performing a search, filtering can be used to limit the results to items tagged as being in the French language. -- I really don't want to change the second "might". > > > Lookup produces the single result that best matches the user's > preferences from the list of available tags, so it is useful in cases > in which a single item is required (and for which only a single item > can be returned). For example, if a process were to insert a human > readable error message into a protocol header, it might select the > text based on the user's language priority list. 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. > > were to insert -> inserts, might select -> selects This is an excellent example of the subjunctive in action. Changing it as you ask would make the example too definite. > > > o For lookup, what the default item is (or the sequence of > operations or configuration information used to determine the > default) when no matching tag is found. For instance, a protocol > might define the result as failure of the operation, an empty > value, returning some protocol defined or implementation defined > default, or returning i-default [RFC2277]. > > might -> can Nope. For the reason John Cowan gave ("for instance" signals that these are examples from a larger list. I could say "can", but that is somehow too definite....) > > > Some examples of applications where filtering might be appropriate > include: > > might -> can (or will?) Not done. This is an incomplete list of appropriate applications. No reason to make it more definite. > > > For example, if an application inserts some dynamic content into a > document, returning an empty string if there is no exact match is not > an option. Instead, the application "falls back" until it finds a > matching language tag associated with a suitable piece of content to > insert. Examples of lookup might include: > > might include -> include I wrote: -- Some applications of lookup include: -- > > > Extensions and unrecognized private-use subtags might be unrelated to > a particular application of lookup. Since these subtags come at the > end of the subtag sequence, they are removed first during the > fallback process and usually pose no barrier to interoperability. > > might be -> can be No, for the reason John Cowan gave: it changes the meaning. > > > Such modification is internal to the > implementation and applications, protocols, or specifications SHOULD > NOT remove or modify subtags in content that they return or forward, > because this removes information that might be used elsewhere. > > might be -> can be Done. > > > In some cases, the language priority list might contain one or more > extended language ranges (as, for example, when the same language > priority list is used as input for both lookup and filtering > operations). > > might contain -> can contain Done. > > > Each application, protocol, or specification MUST define the > defaulting behavior when no tag matches the language priority list. > What this action consists of strongly depends on how lookup is being > applied. Some examples of defaulting behavior might include: > > might include -> include Done. > > > The default value MAY be calculated and might include additional > searching or matching. Applications, protocols, or specifications > can specify different ways in which users can specify or override the > defaults. > > might -> can I rewrote this sentence slightly, making use of both the normative meaning of "MAY" and the English meaning of "may": -- The default value MAY be calculated or include additional searching or matching. -- > > > Applications are encouraged to canonicalize language tags and ranges > by using the Preferred-Value from the IANA Language Subtag Registry > for tags or subtags which have been deprecated. If the user is > working with content that might use the older form, the user might > want to 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, so the user might use it to > form the language range. Or the user might include both in a > language priority list: "jbo, art-lojban". > > four 'might' in a single paragraph, please reduce John Cowan spelled out the reasoning behind the conditional text here. It all stems from the first 'might'... > > > 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. > > might -> can Done. > > > Whether a subtag adds distinguishing value can depend on the context > of the request. For example, a user who reads both Simplified and > Traditional Chinese, but who prefers Simplified, might use the range > "zh" for filtering (matching all items that user can read) but "zh- > Hans" for lookup (making sure that user 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 available under a simple > "zh". > > might use -> can use No, this is supposition. > There is also a lower-case should, which we should remove. > Maybe write "preferably also is made available under a simple "zh"." > > Actually, there are two lowercase 'shoulds'. I changed the sentence to: -- On the other hand, content in this case ought to be labeled as "zh-Hans" (or "zh-Hant" if that applies) for filtering, while for lookup, if there is either "zh-Hans" content or "zh-Hant" content, one of them (the one considered 'default') also ought to be made available with the simple "zh". -- _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 17:11:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6or-00065f-6Q; Tue, 16 May 2006 17:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6oq-00065U-Es for ltru@ietf.org; Tue, 16 May 2006 17:11:04 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg6oq-0007Y6-1A for ltru@ietf.org; Tue, 16 May 2006 17:11:04 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4GL9uqJ027209; Tue, 16 May 2006 14:09:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=QrTDpcV88hdqsTqcMwQ9CwLfod1e+pC3tm3lM4QbcuVTIKz7+4mMFl7cCR+BrE2l From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] 2nd WG last call: expanding codes Date: Tue, 16 May 2006 14:09:56 -0700 Message-ID: <000501c6792d$15686450$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.2869 Thread-Index: AcZ41Y3bsyzyEJK+Ryq++VN1OwZT/QATtpHw In-Reply-To: <6.0.0.20.2.20060516192715.09693580@localhost> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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. > -----Original Message----- > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 2006?5?16? 3:37 > To: LTRU Working Group > Subject: [Ltru] 2nd WG last call: expanding codes > > One of the editing guidelines that I think we have adopted > is that we always make clear what the codes in the examples > mean. There are a few cases where we forgot: > > > For example, a > process might cause paragraphs whose language tag matched the > language range "nl" to be displayed in italics within a document. Done. > > > Note that canonicalizing language ranges makes certain operations > impossible. For example, an implementation that canonicalizes the > language range "art-lojban" to use the more modern "jbo" cannot be > used to select just the items with the older tag. Done. It reads: Note that canonicalizing language ranges makes certain operations impossible. For example, an implementation that canonicalizes the language range "art-lojban" (artificial language, lojban variant) to use the more modern "jbo" (Lojban) cannot be used to select just the items with the older tag. > > > An extended language range is mapped to a basic language range as > follows: if the first subtag is a '*' then the entire range is > treated as "*", otherwise each wildcard subtag is removed. For > example, if the language range were "en-*-US", then the range would > be mapped to "en-US". Done. > > > For example, if the language priority list consists of the > range "de-CH", one might see tags such as "de-CH-1996" but one will > never see a tag such as "de" (because the 'CH' subtag is missing). Done: -- For example, if the language priority list consists of the range "de-CH" (German as used in Switzerland), one might see tags such as "de-CH-1996" (German as used in Switzerland, orthography of 1996) but one will never see a tag such as "de" (because the 'CH' subtag is missing). -- > > > For example, the language-range "de-de" > matches the language tag "de-DE-1996", but not the language tags "de- > Deva" or "de-Latn-DE". Done. -- For example, the language-range "de-de" (German as used in German) matches the language tag "de-DE-1996" (German as used in Germany, orthography of 1996), but not the language tags "de-Deva" (German as written in the Devanagari script) or "de-Latn-DE" (German, Latin script, as used in Germany). -- > > > The following list (at least those that we didn't explain previously) > > de-DE > > de-Latn-DE > > de-Latf-DE > > de-de > > de-DE-x-goethe > > de-Latn-DE-1996 > > de-Deva-DE > de-DE (German, as used in Germany) de-de (German, as used in Germany) de-Latn-DE (Latin script) de-Latf-DE (Fraktur variant of Latin script) de-DE-x-goethe (private use subtag) de-Latn-DE-1996 (orthography of 1996) de-Deva-DE (Devanagari script) > > > For > example, starting with the range "zh-Hant-CN-x-private1-private2", > the lookup progressively searches for content as shown below: Done -- For example, starting with the range "zh-Hant-CN-x-private1-private2" (Chinese, Traditional script, China, two private use tags) the lookup progressively searches for content as shown below: -- > > > 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. Done. > > > For example, if a particular user's language priority list were > "fr-FR, zh-Hant" and the program doing the matching had a default > language range of "ja-JP", the program would search as follows: Done. > > > [I have not mentioned all the repetitions of the same tag, because > I don't think giving the same explanations every time is necessary.] > > Good. The ones we have are ugly enough :-). _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 17:34:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7Bb-0007Ra-OT; Tue, 16 May 2006 17:34:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7BZ-0007RV-VP for ltru@ietf.org; Tue, 16 May 2006 17:34:33 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg7BZ-0000aV-GS for ltru@ietf.org; Tue, 16 May 2006 17:34:33 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4GLXLNI035158; Tue, 16 May 2006 14:33:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=FmpoorLMDYC6quf88wA57GFc1ARDRcKNIUMmxJHbGfMrOHv7m2qVhQuZqkFst1GU From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] 2nd WG last call: lower-case may/should/must Date: Tue, 16 May 2006 14:33:18 -0700 Message-ID: <000601c67930$5abb4010$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.2869 Thread-Index: AcZ43YwWsChjS9DtT5qgyBPMTHQ1EQAT+N3Q In-Reply-To: <6.0.0.20.2.20060516184846.096a3ec0@localhost> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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 More comments... 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?5?16? 3:07 > To: LTRU Working Group > Subject: [Ltru] 2nd WG last call: lower-case may/should/must > > These are the lower-case may/should/must in the main text that > I found. There is no IETF rule that forbids these that I'm aware > of, but as we tried hard to avoid them, we can as well do the > full job. If not, we can as well change back many 'might's to > simple 'may's. > > > A speaker of Breton in France, for example, may specify > "br" followed by "fr", meaning that if Breton is available, it is > preferred, but otherwise French is the best alternative. It can get > more complex: a user may wish to fall back from Skolt Sami to > Northern Sami to Finnish. > > may specify -> can specify > may wish to -> wants to I did this (which you'll hate for its "might"): -- A speaker of Breton in France, for example, can specify "br" followed by "fr", meaning that if Breton is available, it is preferred, but otherwise French is the best alternative. It can get more complex: a different user might want to fall back from Skolt Sami to Northern Sami to Finnish. -- > > > When working with language ranges and matching schemes, there are > some additional points that may influence the choice of either. > > may -> can Done. > > > > 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: the language tags that match > a specific language range do not necessarily represent mutually > intelligible languages. Done. > > > Whether a subtag adds distinguishing value can depend on the context > of the request. For example, a user who reads both Simplified and > Traditional Chinese, but who prefers Simplified, might use the range > "zh" for filtering (matching all items that user can read) but "zh- > Hans" for lookup (making sure that user 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 available under a simple > "zh". > > should be labeled -> preferabily is labeled > should also be available -> preferably also is made available This was changed in response to the last message (and not according to this precise suggestion). > > > Language tags permit only the characters A-Z, a-z, 0-9, and HYPHEN- > MINUS (%x2D). Language ranges also use the character ASTERISK > (%x2A). These characters are present in most character sets, so > presentation or exchange of language tags or ranges should not be > constrained by character set issues. > > should not be -> is not > Uh... this text is exactly the same as that in 3066bis... and is almost an exact quote from RFC 3066: -- Language tags may always be presented using the characters A-Z, a-z, 0-9 and HYPHEN-MINUS, which are present in most character sets, so presentation of language tags should not have any character set issues. -- > > > > Lookup produces the single result that best matches the user's > preferences from the list of available tags, so it is useful in cases > in which a single item is required (and for which only a single item > can be returned). For example, if a process were to insert a human > readable error message into a protocol header, it might select the > text based on the user's language priority list. 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. > > must -> has to (twice) > I implemented this slightly differently: -- Since the process can return only one item, it is forced to choose a single item and it has to return some item, even if none of the content's language tags match the language priority list supplied by the user. -- > > > Very special thanks must go to Harald Tveit Alvestrand, who > originated RFCs 1766 and 3066, and without whom this document would > not have been possible. > > [I can live with that, since it's clearly outside the normative > part of the spec.] > I could elide the "must", but I like the emphasis. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 17:43:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7KZ-0002gA-SJ; Tue, 16 May 2006 17:43:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7KY-0002g5-Q0 for ltru@ietf.org; Tue, 16 May 2006 17:43:50 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg7KY-0001Gb-DO for ltru@ietf.org; Tue, 16 May 2006 17:43:50 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4GLgKl3038173; Tue, 16 May 2006 14:42:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=NgqtxYlUMSBR5JYQeZB6ZI5LLCi63tBGHGQoEbmfTBijn21clEoxSqHNPeqtVz1T From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] 2nd WG last call: Abstract Date: Tue, 16 May 2006 14:42:19 -0700 Message-ID: <000701c67931$9bf486d0$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.2869 Thread-Index: AcZ41Y50PMSZP6YESVSBIeK930hHOgAW7xqA In-Reply-To: <6.0.0.20.2.20060516191028.09692b00@localhost> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Okay, except that it neglects to mention the language priority list. I borrowed and adapted, instead, text from the Introduction to make the abstract read: -- This document describes a syntax, called a "language-range", for specifying items in a user's list of language preferences, called a "language priority list". It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a potentially empty set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 3066bis (Ed.: replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. -- 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?5?16? 3:19 > To: LTRU Working Group > Subject: [Ltru] 2nd WG last call: Abstract > > The abstract is one of the most important pieces of a document. > Given this, I feel that ours could need some work. I have felt > that way for a long time, but I thought I'd wait until the > content doesn't change anymore. The abstract currently > reads: > > 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. > > > Which effectively just is: > > 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 XXXX, replaces RFC 3066, which > replaced RFC 1766. > > I propose to change this as follows: > > This document describes a syntax, called language-range, for > indicating > language preferences, and different mechanisms for comparing and > matching language tags. Two kinds of matching mechanisms, filtering > and lookup, are defined. Filtering produces a potentially empty list > of language tags, whereas lookup produces a single language tag. > Possible applications include language negotiation or content > selection. > This document, in combination with RFC 3066bis (Ed.: replace "3066bis" > with the RFC number assigned to draft-ietf-ltru-registry-14), replaces > RFC 3066, which replaced RFC 1766. > > > 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 Tue May 16 17:52:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7TN-0006KQ-6Q; Tue, 16 May 2006 17:52:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7TM-0006KL-6N for ltru@ietf.org; Tue, 16 May 2006 17:52:56 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg7TK-0001X4-QF for ltru@ietf.org; Tue, 16 May 2006 17:52:56 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4GLoeAc040990; Tue, 16 May 2006 14:50:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=kXP3lIWtetFoLrLhYztoWYe8VR/4c33EvBvhUr/E750D50WP/hYksjRTiCQmoFkp From: "Addison Phillips" To: "'John Cowan'" , "'Martin Duerst'" Subject: RE: [Ltru] 2nd WG last call: Language improvement Date: Tue, 16 May 2006 14:50:39 -0700 Message-ID: <000801c67932$c5d20940$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.2869 Thread-Index: AcZ47tbsy2zNc9/ET+KXNnA/vxDiLwAQ5zCA In-Reply-To: <20060516134348.GS31206@ccil.org> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 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?5?16? 6:44 > To: Martin Duerst > Cc: ltru@ietf.org > Subject: Re: [Ltru] 2nd WG last call: Language improvement > > > > > This fallback behavior allows some flexibility in finding a match. > > Without fallback, in the case that content that exactly matches is > > not available, the default content would be returned immediately. > > The fallback in lookup will make sure that a better result (i.e. > > content more closely matching the user request) is made available > > if it exists. > > How about this: > > This fallback behavior allows some flexibility in finding > a match. Without fallback, the default content would be > returned immediately if exactly matching content is unavailable. > With fallback, a result more closely matching the user request > can be provided. Good. Done. > > > Just before 3.4: > > > > This is the reason why a wildcard in the > > extended language range is significant in the first position and > > subsequently ignored. > > > > I think this is easier to read if it says: > > > > This is the reason why a wildcard in the > > extended language range is significant in the first position, but > > is subsequently ignored. > > I propose "but is ignored in all other positions", to block the > interpretation that "subsequently" refers to time rather than space. Done. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 17:55:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7W0-0007AM-OG; Tue, 16 May 2006 17:55:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7W0-0007AH-70 for ltru@ietf.org; Tue, 16 May 2006 17:55:40 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg7Vz-0001Zx-Su for ltru@ietf.org; Tue, 16 May 2006 17:55:40 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4GLsfpj042438; Tue, 16 May 2006 14:54:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=hdQato8HgKYL0bWPHgN0CCu4+LUVNb6OCkEXoEkhVULoxzVG5aDoF0bj0okS0mwZ From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" Subject: RE: [Ltru] 2nd WG last call: Language improvement Date: Tue, 16 May 2006 14:54:39 -0700 Message-ID: <000901c67933$556f5350$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.2869 Thread-Index: AcZ43Hi25js4D609QROKGgdLGpgLXQAVlFeg In-Reply-To: <6.0.0.20.2.20060516174019.096997a0@localhost> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 And lastly... comments 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?5?16? 3:37 > To: LTRU Working Group > Subject: [Ltru] 2nd WG last call: Language improvement > > [This is somehow the 'misc' bucket of my comments.] > > > Here is a sentence that I think is too complicated: Dealt with in John Cowan's message. > > > Here's some typo: > > since these ranges will won't match any valid language tags. > > will won't -> will not Done. > > > The first para in the introduction: > > Human beings on our planet have, past and present, used a number of > languages. There are many reasons why one would want to identify the > language used when presenting or requesting information or in some > specific set of information items. > > Every time I read this, I have problems parsing the second sentence. > What about rewording as follows: > > There are many reasons why one wants to identify the > language used when presenting or requesting information, or the > language used in some specific set of information items. :: sigh :: RFC 3066bis has, in the same position: -- There are many reasons why one would want to identify the language used when presenting or requesting information. -- The addition of "set" I guess has to do with the fact that matching schemes produce sets of content and not necessarily just a single information item. Nonetheless, the 3066bis formulation is every bit as effective and less verbose. I restored it here. > > > Just before 3.4: > Also dealt with previously. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue May 16 18:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7cw-0000rD-QM; Tue, 16 May 2006 18:02:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7cv-0000r8-IO for ltru@ietf.org; Tue, 16 May 2006 18:02:49 -0400 Received: from mrout1.yahoo.com ([216.145.54.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg7cu-0001un-7b for ltru@ietf.org; Tue, 16 May 2006 18:02:49 -0400 Received: from duringpersonlx (duringperson-lx.corp.yahoo.com [172.21.37.80]) by mrout1.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4GM1UUL044610 for ; Tue, 16 May 2006 15:01:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index; b=Fu9pTfjO4I6Sg1TuY4XqlkiftoL0hJh5cCkHvTC5Z/iYGnBn5GYY30hSD8G+/ARH From: "Addison Phillips" To: "'LTRU Working Group'" Date: Tue, 16 May 2006 15:01:30 -0700 Message-ID: <000a01c67934$49625840$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.2869 Thread-Index: AcZ5NEkYF0Gdgpu7TeSC05JaW7Cw8g== X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ltru] editor's copy updated... X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All, I have implemented all of the changes mentioned in my previous = dispatches today and posted the updated copies online here: http://www.inter-locale.com/ID/draft-ietf-ltru-matching-13.txt http://www.inter-locale.com/ID/draft-ietf-ltru-matching-13.html http://www.inter-locale.com/ID/draft-ietf-ltru-matching-13.xml I did not generate a static diff, but one can be obtained from this = link: http://tinyurl.com/kc3f8 Martin, on your direction I will submit this draft, pace any changes to = correct omissions or problems with my implementation of comments. I look = forward to seeing this work in the tenacious teeth of the IESG. Hopefully, 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 May 17 01:10:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgEJA-0007zZ-Mp; Wed, 17 May 2006 01:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgEJ8-0007zU-SJ for ltru@ietf.org; Wed, 17 May 2006 01:10:50 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgEJ7-0008IO-LM for ltru@ietf.org; Wed, 17 May 2006 01:10:50 -0400 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 <20060517051049.JNDE27996.mta10.adelphia.net@DGBP7M81>; Wed, 17 May 2006 01:10:49 -0400 Message-ID: <000d01c67970$41e766a0$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] 2nd WG last call: Abstract Date: Tue, 16 May 2006 22:10:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Debbie Garside X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside wrote: > But empty lists are not lists at all... :-) To a programmer's mind, a list (ordered set) can be empty, just as an unordered set can be. I agree that to a non-programmer's mind, this might seem absurd, and the draft is probably intended to be read by both species. Would it be better to say "set" in this context? -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed May 17 10:04:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMcz-0007hf-2o; Wed, 17 May 2006 10:03:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMcx-0007hT-GV for ltru@ietf.org; Wed, 17 May 2006 10:03:51 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMcu-0002Om-48 for ltru@ietf.org; Wed, 17 May 2006 10:03:51 -0400 Received: from duringpersonlx (snvvpn2-10-72-77-c45.corp.yahoo.com [10.72.77.45]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4HE2tYp021495; Wed, 17 May 2006 07:02:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=xpLxNMgxm3GopXoLlzU9An+Uo9j9TIfb1kze+Nea9EPbpTiZR2wpnVj/9j8Tmm3Y From: "Addison Phillips" To: "'Doug Ewell'" , "'Debbie Garside'" Subject: RE: [Ltru] 2nd WG last call: Abstract Date: Wed, 17 May 2006 07:02:55 -0700 Message-ID: <000c01c679ba$98da9e60$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: <006901c679b8$63488c00$040aa8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ5uHRfR7Kh3Wi/TTK1WAnfMwwv9gAAcJ2w X-Spam-Score: -15.0 (---------------) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I agree with Doug. I think the best way to address the problem is to = change it from its current: -- Filtering produces a potentially empty set of language tags... -- To a "less negative": -- Filtering produces a (potentially empty) set of language tags... --- I'm going to make this change, run idnits and the other tools, and = submit draft-13 this morning. Best Regards, Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 2006=E5=B9=B45=E6=9C=8817=E6=97=A5 6:47 > To: Debbie Garside; 'Addison Phillips' > Subject: Re: [Ltru] 2nd WG last call: Abstract >=20 > Hi Debbie, >=20 > > I can see where you programmers are coming from but if you look at = the > > filtering description within the abstract as it stands: > > > >> Filtering produces a potentially empty list > >> of language tags > > > > It rather focuses on the negative. Perhaps it would be better to = say: > > > > "Filtering produces a set of language tags." > > > > In database query terms one would expect that if there is no match = the > > list would be empty. >=20 > I agree about not wanting to focusing on the negative, but I also feel > it needs to state somewhere that this set can have zero elements -- > especially for the non-programmers who might not think of this case. >=20 > Addison, can you think of a way to spin this wording? >=20 > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed May 17 10:17:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMqa-00051X-8z; Wed, 17 May 2006 10:17:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMqZ-00051S-1W for ltru@ietf.org; Wed, 17 May 2006 10:17:55 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMqW-0002xq-Oy for ltru@ietf.org; Wed, 17 May 2006 10:17:55 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta9.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060517141752.PYGT8718.mta9.adelphia.net@DGBP7M81>; Wed, 17 May 2006 10:17:52 -0400 Message-ID: <007901c679bc$ae02cef0$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "Addison Phillips" , "'Debbie Garside'" References: <000c01c679ba$98da9e60$660a0a0a@ds.corp.yahoo.com> Subject: Re: [Ltru] 2nd WG last call: Abstract Date: Wed, 17 May 2006 07:17:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 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 I think the parentheses shift the emphasis away from the negative adequately. Hopefully this will suit Debbie's need also. Is this going to be a final submission for IANA Last Call, or are we going to go through the same drill all over again? (Issue draft, wait for LC to be called, let two weeks pass, flood of comments, repeat...) -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ ----- Original Message ----- From: "Addison Phillips" To: "'Doug Ewell'" ; "'Debbie Garside'" Cc: "'LTRU Working Group'" Sent: Wednesday, May 17, 2006 7:02 Subject: RE: [Ltru] 2nd WG last call: Abstract I agree with Doug. I think the best way to address the problem is to change it from its current: -- Filtering produces a potentially empty set of language tags... -- To a "less negative": -- Filtering produces a (potentially empty) set of language tags... --- I'm going to make this change, run idnits and the other tools, and submit draft-13 this morning. Best Regards, Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 2006å¹´5月17æ—¥ 6:47 > To: Debbie Garside; 'Addison Phillips' > Subject: Re: [Ltru] 2nd WG last call: Abstract > > Hi Debbie, > > > I can see where you programmers are coming from but if you look at > > the > > filtering description within the abstract as it stands: > > > >> Filtering produces a potentially empty list > >> of language tags > > > > It rather focuses on the negative. Perhaps it would be better to > > say: > > > > "Filtering produces a set of language tags." > > > > In database query terms one would expect that if there is no match > > the > > list would be empty. > > I agree about not wanting to focusing on the negative, but I also feel > it needs to state somewhere that this set can have zero elements -- > especially for the non-programmers who might not think of this case. > > Addison, can you think of a way to spin this wording? > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed May 17 10:24:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMwt-0007ZI-9V; Wed, 17 May 2006 10:24:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMws-0007ZD-Gu for ltru@ietf.org; Wed, 17 May 2006 10:24:26 -0400 Received: from mrout2.yahoo.com ([216.145.54.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMwr-0003DL-4y for ltru@ietf.org; Wed, 17 May 2006 10:24:26 -0400 Received: from duringpersonlx (snvvpn2-10-72-77-c45.corp.yahoo.com [10.72.77.45]) by mrout2.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4HEMkKg025776; Wed, 17 May 2006 07:22:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=YJpLCuGCpQ3QHXG/4O9GYn/JYb8zi/gSpyFXDeaSYDRapxnbTy26obwiQ+XE5dVK From: "Addison Phillips" To: "'Doug Ewell'" , "'Debbie Garside'" Subject: RE: [Ltru] 2nd WG last call: Abstract Date: Wed, 17 May 2006 07:22:46 -0700 Message-ID: <000d01c679bd$5ea32d90$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: <007901c679bc$ae02cef0$040aa8c0@DGBP7M81> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ5vLjtAO6euv8lTDmihKPN/RbqXgAAI6xw X-Spam-Score: -15.0 (---------------) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 has indicated that this will be submitted to our AD, rather than = going back to another WG last call. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 2006=E5=B9=B45=E6=9C=8817=E6=97=A5 7:18 > To: Addison Phillips; 'Debbie Garside' > Cc: 'LTRU Working Group' > Subject: Re: [Ltru] 2nd WG last call: Abstract >=20 > I think the parentheses shift the emphasis away from the negative > adequately. Hopefully this will suit Debbie's need also. >=20 > Is this going to be a final submission for IANA Last Call, or are we > going to go through the same drill all over again? (Issue draft, wait > for LC to be called, let two weeks pass, flood of comments, repeat...) >=20 > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ >=20 >=20 >=20 > ----- Original Message ----- > From: "Addison Phillips" > To: "'Doug Ewell'" ; "'Debbie Garside'" > > Cc: "'LTRU Working Group'" > Sent: Wednesday, May 17, 2006 7:02 > Subject: RE: [Ltru] 2nd WG last call: Abstract >=20 >=20 > I agree with Doug. I think the best way to address the problem is to > change it from its current: >=20 > -- > Filtering produces a potentially empty set of language tags... > -- >=20 > To a "less negative": >=20 > -- > Filtering produces a (potentially empty) set of language tags... > --- >=20 > I'm going to make this change, run idnits and the other tools, and > submit draft-13 this morning. >=20 > Best Regards, >=20 > Addison >=20 > Addison Phillips > Internationalization Architect - Yahoo! Inc. >=20 > Internationalization is an architecture. > It is not a feature. >=20 > > -----Original Message----- > > From: Doug Ewell [mailto:dewell@adelphia.net] > > Sent: 2006=E5=B9=B45=E6=9C=8817=E6=97=A5 6:47 > > To: Debbie Garside; 'Addison Phillips' > > Subject: Re: [Ltru] 2nd WG last call: Abstract > > > > Hi Debbie, > > > > > I can see where you programmers are coming from but if you look at > > > the > > > filtering description within the abstract as it stands: > > > > > >> Filtering produces a potentially empty list > > >> of language tags > > > > > > It rather focuses on the negative. Perhaps it would be better to > > > say: > > > > > > "Filtering produces a set of language tags." > > > > > > In database query terms one would expect that if there is no match > > > the > > > list would be empty. > > > > I agree about not wanting to focusing on the negative, but I also = feel > > it needs to state somewhere that this set can have zero elements -- > > especially for the non-programmers who might not think of this case. > > > > Addison, can you think of a way to spin this wording? > > > > -- > > Doug Ewell > > Fullerton, California, USA > > http://users.adelphia.net/~dewell/ > > >=20 >=20 >=20 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed May 17 10:47:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNJ9-00018W-0z; Wed, 17 May 2006 10:47:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNJ7-00012j-Rq for ltru@ietf.org; Wed, 17 May 2006 10:47:25 -0400 Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNJ5-0004zN-H9 for ltru@ietf.org; Wed, 17 May 2006 10:47:25 -0400 Received: from DGBP7M81 ([69.162.95.23]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060517144722.NBBA9479.mta13.adelphia.net@DGBP7M81>; Wed, 17 May 2006 10:47:22 -0400 Message-ID: <007f01c679c0$cd8b54a0$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "Addison Phillips" , "'Debbie Garside'" References: <000d01c679bd$5ea32d90$660a0a0a@ds.corp.yahoo.com> Subject: Re: [Ltru] 2nd WG last call: Abstract Date: Wed, 17 May 2006 07:47:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Outstanding. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ ----- Original Message ----- From: "Addison Phillips" To: "'Doug Ewell'" ; "'Debbie Garside'" Cc: "'LTRU Working Group'" Sent: Wednesday, May 17, 2006 7:22 Subject: RE: [Ltru] 2nd WG last call: Abstract Martin has indicated that this will be submitted to our AD, rather than going back to another WG last call. Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: 2006å¹´5月17æ—¥ 7:18 > To: Addison Phillips; 'Debbie Garside' > Cc: 'LTRU Working Group' > Subject: Re: [Ltru] 2nd WG last call: Abstract > > I think the parentheses shift the emphasis away from the negative > adequately. Hopefully this will suit Debbie's need also. > > Is this going to be a final submission for IANA Last Call, or are we > going to go through the same drill all over again? (Issue draft, wait > for LC to be called, let two weeks pass, flood of comments, repeat...) > > -- > Doug Ewell > Fullerton, California, USA > http://users.adelphia.net/~dewell/ > > > > ----- Original Message ----- > From: "Addison Phillips" > To: "'Doug Ewell'" ; "'Debbie Garside'" > > Cc: "'LTRU Working Group'" > Sent: Wednesday, May 17, 2006 7:02 > Subject: RE: [Ltru] 2nd WG last call: Abstract > > > I agree with Doug. I think the best way to address the problem is to > change it from its current: > > -- > Filtering produces a potentially empty set of language tags... > -- > > To a "less negative": > > -- > Filtering produces a (potentially empty) set of language tags... > --- > > I'm going to make this change, run idnits and the other tools, and > submit draft-13 this morning. > > Best Regards, > > Addison > > Addison Phillips > Internationalization Architect - Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. > > > -----Original Message----- > > From: Doug Ewell [mailto:dewell@adelphia.net] > > Sent: 2006å¹´5月17æ—¥ 6:47 > > To: Debbie Garside; 'Addison Phillips' > > Subject: Re: [Ltru] 2nd WG last call: Abstract > > > > Hi Debbie, > > > > > I can see where you programmers are coming from but if you look at > > > the > > > filtering description within the abstract as it stands: > > > > > >> Filtering produces a potentially empty list > > >> of language tags > > > > > > It rather focuses on the negative. Perhaps it would be better to > > > say: > > > > > > "Filtering produces a set of language tags." > > > > > > In database query terms one would expect that if there is no match > > > the > > > list would be empty. > > > > I agree about not wanting to focusing on the negative, but I also > > feel > > it needs to state somewhere that this set can have zero elements -- > > especially for the non-programmers who might not think of this case. > > > > Addison, can you think of a way to spin this wording? > > > > -- > > Doug Ewell > > Fullerton, California, USA > > http://users.adelphia.net/~dewell/ > > > > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu May 18 14:13:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgmzX-0002ws-Il; Thu, 18 May 2006 14:12:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgmzW-0002wX-Tr; Thu, 18 May 2006 14:12:54 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgmzT-0001Sx-JP; Thu, 18 May 2006 14:12:54 -0400 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 k4IICTYY001275; Thu, 18 May 2006 11:12:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:x-mailer:x-mimeole:thread-index; b=fLp8zVvrM4QRcqpN8zdSeen0c3r/ZHKBlbj1r3ArVPs3iWOrD4jsU9Uipx3tGT89 From: "Addison Phillips" To: Date: Thu, 18 May 2006 11:12:28 -0700 Message-ID: <000601c67aa6$a10d6fd0$9fcd15ac@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01C67A6B.F4B834C0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ6pp8PbBAJNX5+Sz+/8oa2yAgfNA== X-Spam-Score: -15.0 (---------------) X-Scan-Signature: dfc1655f2189092f4fafe696b2c0f089 Cc: 'LTRU Working Group' Subject: [Ltru] Submission: draft-ietf-ltru-matching-13 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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_0007_01C67A6B.F4B834C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear Editors, Please find attached in text format draft-ietf-ltru-matching-13. Best Regards, Addison (for the editors) Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature. ------=_NextPart_000_0007_01C67A6B.F4B834C0 Content-Type: text/plain; name="draft-ietf-ltru-matching-13.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ltru-matching-13.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: November 19, 2006 Google=0A= May 18, 2006=0A= =0A= =0A= Matching of Language Tags=0A= draft-ietf-ltru-matching-13=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 November 19, 2006.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2006).=0A= =0A= Abstract=0A= =0A= This document describes a syntax, called a "language-range", for=0A= specifying items in a user's language preferences, called a "language=0A= priority list". It also describes different mechanisms for comparing=0A= and matching these to language tags. Two kinds of matching=0A= mechanisms, filtering and lookup, are defined. Filtering produces a=0A= (potentially empty) set of language tags, whereas lookup produces a=0A= single language tag. Possible applications include language=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 1]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= negotiation or content selection. This document, in combination with=0A= RFC 3066bis (Ed.: replace "3066bis" with the RFC number assigned to=0A= draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC=0A= 1766.=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. The Language Range . . . . . . . . . . . . . . . . . . . . . . 4=0A= 2.1. Basic Language Range . . . . . . . . . . . . . . . . . . . 4=0A= 2.2. Extended Language Range . . . . . . . . . . . . . . . . . 5=0A= 2.3. The Language Priority List . . . . . . . . . . . . . . . . 5=0A= 3. Types of Matching . . . . . . . . . . . . . . . . . . . . . . 7=0A= 3.1. Choosing a Matching Scheme . . . . . . . . . . . . . . . . 7=0A= 3.2. Implementation Considerations . . . . . . . . . . . . . . 8=0A= 3.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 3.3.1. Basic Filtering . . . . . . . . . . . . . . . . . . . 10=0A= 3.3.2. Extended Filtering . . . . . . . . . . . . . . . . . . 11=0A= 3.4. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 12=0A= 3.4.1. Default Values . . . . . . . . . . . . . . . . . . . . 14=0A= 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 16=0A= 4.1. Choosing Language Ranges . . . . . . . . . . . . . . . . . 16=0A= 4.2. Meaning of Language Tags and Ranges . . . . . . . . . . . 17=0A= 4.3. Considerations for Private Use Subtags . . . . . . . . . . 17=0A= 4.4. Length Considerations for Language Ranges . . . . . . . . 18=0A= 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19=0A= 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20=0A= 7. Character Set Considerations . . . . . . . . . . . . . . . . . 21=0A= 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22=0A= 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22=0A= 8.2. Informative References . . . . . . . . . . . . . . . . . . 22=0A= Appendix A. 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= Phillips & Davis Expires November 19, 2006 [Page 2]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 1. Introduction=0A= =0A= Human beings on our planet have, past and present, used a number of=0A= languages. There are many reasons why one would want to identify the=0A= language used when presenting or requesting information.=0A= =0A= Applications, protocols, or specifications that use language=0A= identifiers, such as the language tags defined in [RFC3066bis],=0A= sometimes need to match language tags to a user's language=0A= preferences.=0A= =0A= This document defines a syntax (called a language range (Section 2))=0A= for specifying items in the user's list of language preferences=0A= (called a language priority list (Section 2.3)), as well as several=0A= schemes for selecting or filtering sets of language tags by comparing=0A= the language tags to the user's preferences. Applications,=0A= protocols, or specifications will have varying needs and requirements=0A= that affect the choice of a suitable matching scheme.=0A= =0A= This document describes: how to indicate a user's preferences using=0A= language ranges; three schemes for matching these ranges to a set of=0A= language tags; and the various practical considerations that apply to=0A= implementing and using these schemes.=0A= =0A= This document, in combination with [RFC3066bis] (Ed.: replace=0A= "3066bis" globally in this document with the RFC number assigned to=0A= draft-ietf-ltru-registry-14), replaces [RFC3066], which replaced=0A= [RFC1766].=0A= =0A= The 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= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 3]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 2. The Language Range=0A= =0A= Language tags [RFC3066bis] are used to help identify languages,=0A= whether spoken, written, signed, or otherwise signaled, for the=0A= purpose of communication. Applications, protocols, or specifications=0A= that use language tags are often faced with the problem of=0A= identifying sets of content that share certain language attributes.=0A= For example, HTTP/1.1 [RFC2616] describes one such mechanism in its=0A= discussion of the Accept-Language header (Section 14.4), which is=0A= used when selecting content from servers based on the language of=0A= that content.=0A= =0A= It is, thus, useful to have a mechanism for identifying sets of=0A= language tags that share specific attributes. This allows users to=0A= select or filter the language tags based on specific requirements.=0A= Such an identifier is called a "language range".=0A= =0A= There are different types of language range, whose specific=0A= attributes vary according to their application. Language ranges are=0A= similar to language tags: they consist of a sequence of subtags=0A= separated by hyphens. In a language range, each subtag MUST either=0A= be a sequence of ASCII alphanumeric characters or the single=0A= character '*' (%2A, ASTERISK). The character '*' is a "wildcard"=0A= that matches any sequence of subtags. The meaning and uses of=0A= wildcards vary according to the type of language range.=0A= =0A= Language tags and thus language ranges are to be treated as case-=0A= insensitive: there exist conventions for the capitalization of some=0A= of the subtags, but these MUST NOT be taken to carry meaning.=0A= Matching of language tags to language ranges MUST be done in a case-=0A= insensitive manner.=0A= =0A= 2.1. Basic Language Range=0A= =0A= A "basic language range" has the same syntax as an [RFC3066] language=0A= tag or is the single character "*". The basic language range was=0A= originally described by HTTP/1.1 [RFC2616] and later [RFC3066]. It=0A= is defined by the following ABNF [RFC4234]:=0A= =0A= language-range =3D (1*8ALPHA *("-" 1*8alphanum)) / "*"=0A= alphanum =3D ALPHA / DIGIT=0A= =0A= A basic language range differs from the language tags defined in=0A= [RFC3066bis] only in that there is no requirement that they be "well-=0A= formed" or be validated against the IANA Language Subtag Registry.=0A= Such ill-formed ranges will probably not match anything. Note that=0A= the ABNF [RFC4234] in [RFC2616] is incorrect, since it disallows the=0A= use of digits anywhere in the 'language-range' (see:=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 4]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= [RFC2616errata]).=0A= =0A= 2.2. Extended Language Range=0A= =0A= Occasionally users will wish to select a set of language tags based=0A= on the presence of specific subtags. An "extended language range"=0A= describes a user's language preference as an ordered sequence of=0A= subtags. For example, a user might wish to select all language tags=0A= that contain the region subtag 'CH' (Switzerland). Extended language=0A= ranges are useful for specifying a particular sequence of subtags=0A= that appear in the set of matching tags without having to specify all=0A= of the intervening subtags.=0A= =0A= An extended language range can be represented by the following ABNF:=0A= =0A= extended-language-range =3D (1*8ALPHA / "*")=0A= *("-" (1*8alphanum / "*"))=0A= =0A= 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 are ignored by Extended Filtering (see Section=0A= 3.2.2). The use or absence of one or more wildcards cannot be taken=0A= to imply that a certain number of subtags will appear in the matching=0A= set of language tags.=0A= =0A= 2.3. The Language Priority List=0A= =0A= A user's language preferences will often need to specify more than=0A= one language range and thus users often need to specify a prioritized=0A= list of language ranges in order to best reflect their language=0A= preferences. This is especially true for speakers of minority=0A= languages. A speaker of Breton in France, for example, can specify=0A= "br" followed by "fr", meaning that if Breton is available, it is=0A= preferred, but otherwise French is the best alternative. It can get=0A= more complex: a different user might want to fall back from Skolt=0A= Sami to Northern Sami to Finnish.=0A= =0A= A "language priority list" is a prioritized or weighted list of=0A= language ranges. One well known example of such a list is the=0A= "Accept-Language" header defined in RFC 2616 [RFC2616] (see Section=0A= 14.4) and RFC 3282 [RFC3282].=0A= =0A= The various matching operations described in this document include=0A= considerations for using a language priority list. This document=0A= does not define the syntax for a language priority list; defining=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 5]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =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 is read=0A= "English before French before Chinese as written in the Traditional=0A= script").=0A= =0A= A simple list of ranges is considered to be in descending order of=0A= priority. Other language priority lists provide "quality weights"=0A= for the language ranges in order to specify the relative priority of=0A= the user's language preferences. An example of this is the use of=0A= "q" values in the syntax of the "Accept-Language" header (defined in=0A= [RFC2616], Section 14.4, and [RFC3282]).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 6]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 3. Types of Matching=0A= =0A= Matching language ranges to language tags can be done in many=0A= different ways. This section describes three such matching schemes,=0A= as well as the considerations for choosing between them. Protocols=0A= and specifications requiring conformance to this specification MUST=0A= clearly indicate the particular mechanism used in selecting or=0A= matching language tags.=0A= =0A= There are two types of matching scheme in this document. A matching=0A= scheme that produces zero or more matching language tags is called=0A= "filtering". A matching scheme that produces exactly one match for a=0A= given request is called "lookup".=0A= =0A= 3.1. Choosing a Matching Scheme=0A= =0A= Applications, protocols, and specifications are faced with the=0A= decision of what type of matching to use. Sometimes, different=0A= styles of matching are suited to different kinds of processing within=0A= a particular application or protocol.=0A= =0A= This document describes three matching schemes:=0A= =0A= 1. Basic Filtering (Section 3.3.1) matches a language priority list=0A= consisting of basic language ranges (Section 2.1) to sets of=0A= language tags.=0A= =0A= 2. Extended Filtering (Section 3.3.2) matches a language priority=0A= list consisting of extended language ranges (Section 2.2) to sets=0A= of language tags.=0A= =0A= 3. Lookup (Section 3.4) matches a language priority list consisting=0A= of basic language ranges to sets of language tags to find the one=0A= _exact_ language tag that best matches the range.=0A= =0A= Filtering can be used to produce a set of results (such as a=0A= collection of documents) by comparing the user's preferences to a set=0A= of language tags. For example, when performing a search, filtering=0A= can be used to limit the results to items tagged as being in the=0A= French language. Filtering can also be used when deciding whether to=0A= perform a language-sensitive process on some content. For example, a=0A= process might cause paragraphs whose language tag matched the=0A= language range "nl" (Dutch) to be displayed in italics within a=0A= document.=0A= =0A= Lookup produces the single result that best matches the user's=0A= preferences from the list of available tags, so it is useful in cases=0A= in which a single item is required (and for which only a single item=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 7]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= can be returned). For example, if a process were to insert a human=0A= readable error message into a protocol header, it might select the=0A= text based on the user's language priority list. Since the process=0A= can return only one item, it is forced to choose a single item and it=0A= has to return some item, even if none of the content's language tags=0A= match the language priority list supplied by the user.=0A= =0A= 3.2. Implementation Considerations=0A= =0A= Language tag matching is a tool, and does not by itself specify a=0A= complete procedure for the use of language tags. Such procedures are=0A= intimately tied to the application protocol in which they occur.=0A= When specifying a protocol operation using matching, the protocol=0A= MUST specify:=0A= =0A= o Which type(s) of language tag matching it uses=0A= =0A= o Whether the operation returns a single result (lookup) or a=0A= possibly empty set of results (filtering)=0A= =0A= o For lookup, what the default item is (or the sequence of=0A= operations or configuration information used to determine the=0A= default) when no matching tag is found. For instance, a protocol=0A= might define the result as failure of the operation, an empty=0A= value, returning some protocol defined or implementation defined=0A= default, or returning i-default [RFC2277].=0A= =0A= Applications, protocols, and specifications are not required to=0A= validate or understand any of the semantics of the language tags or=0A= ranges or of the subtags in them, nor do they require access to the=0A= IANA Language Subtag Registry (see Section 3 in [RFC3066bis]). This=0A= simplifies implementation.=0A= =0A= However, designers of applications, protocols, or specifications are=0A= encouraged to use the information from the IANA Language Subtag=0A= Registry to support canonicalizing language tags and ranges in order=0A= to map grandfathered and obsolete tags or subtags into modern=0A= equivalents.=0A= =0A= Applications, protocols, or specifications that canonicalize ranges=0A= MUST either perform matching operations with both the canonical and=0A= original (unmodified) form of the range or MUST also canonicalize=0A= each tag for the purposes of comparison.=0A= =0A= Note that canonicalizing language ranges makes certain operations=0A= impossible. For example, an implementation that canonicalizes the=0A= language range "art-lojban" (artificial language, lojban variant) to=0A= use the more modern "jbo" (Lojban) cannot be used to select just the=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 8]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= items with the older tag.=0A= =0A= Applications, protocols, or specifications that use basic ranges=0A= might sometimes receive extended language ranges instead. An=0A= application, protocol, or specification MUST choose to: a) map=0A= extended language ranges to basic ranges using the algorithm below,=0A= b) reject any extended language ranges in the language priority list=0A= that are not valid basic language ranges, or c) treat each extended=0A= language range as if it were a basic language range, which will have=0A= the same result as ignoring them, since these ranges will not match=0A= any valid language tags.=0A= =0A= An extended language range is mapped to a basic language range as=0A= follows: if the first subtag is a '*' then the entire range is=0A= treated as "*", otherwise each wildcard subtag is removed. For=0A= example, the extended language range "en-*-US" maps to "en-US"=0A= (English, United States).=0A= =0A= Applications, protocols, or specifications, in addressing their=0A= particular requirements, can offer pre-processing or configuration=0A= options. For example, an implementation could allow a user to=0A= associate or map a particular language range to a different value.=0A= Such a user might wish to associate the language range subtags 'nn'=0A= (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) with the more general=0A= subtag 'no' (Norwegian). Or perhaps a user would want to associate=0A= requests for the range "zh-Hans" (Chinese as written in the=0A= Simplified script) with content bearing the language tag "zh-CN"=0A= (Chinese as used in China, where the Simplified script is=0A= predominant). Documentation on how the ranges or tags are altered,=0A= prioritized, or compared in the subsequent match in such an=0A= implementation will assist users in making these types of=0A= configuration choices.=0A= =0A= 3.3. Filtering=0A= =0A= Filtering is used to select the set of language tags that matches a=0A= given language priority list. It is called "filtering" because this=0A= set might contain no items at all or it might return an arbitrarily=0A= large number of matching items: as many items as match the language=0A= priority list, thus "filtering out" the non-matching items.=0A= =0A= In filtering, each language range represents the _least_ specific=0A= language tag (that is, the language tag with fewest number of=0A= subtags) which is an acceptable match. All of the language tags in=0A= the matching set of tags will have an equal or greater number of=0A= subtags than the language range. Every non-wildcard subtag in the=0A= language range will appear in every one of the matching language=0A= tags. For example, if the language priority list consists of the=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 9]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= range "de-CH" (German as used in Switzerland), one might see tags=0A= such as "de-CH-1996" (German as used in Switzerland, orthography of=0A= 1996) but one will never see a tag such as "de" (because the 'CH'=0A= subtag is missing).=0A= =0A= If the language priority list (see Section 2.3) contains more than=0A= one range, the content returned is typically ordered in descending=0A= level of preference, but it MAY be unordered, according to the needs=0A= of the application or protocol.=0A= =0A= Some examples of applications where filtering might be appropriate=0A= include:=0A= =0A= o Applying a style to sections of a document in a particular set of=0A= languages.=0A= =0A= o Displaying the set of documents containing a particular set of=0A= keywords written in a specific set of languages.=0A= =0A= o Selecting all email items written in a specific set of languages.=0A= =0A= o Selecting audio files spoken in a particular language.=0A= =0A= Filtering seems to imply that there is a semantic relationship=0A= between language tags that share the same prefix. While this is=0A= often the case, it is not always true: the language tags that match a=0A= specific language range do not necessarily represent mutually=0A= intelligible languages.=0A= =0A= 3.3.1. Basic Filtering=0A= =0A= Basic filtering compares basic language ranges to language tags.=0A= Each basic language range in the language priority list is considered=0A= in turn, according to priority. A language range matches a=0A= particular language tag if, in a case-insensitive comparison, it=0A= exactly equals the tag, or if it exactly equals a prefix of the tag=0A= such that the first character following the prefix is "-". For=0A= example, the language-range "de-de" (German as used in German)=0A= matches the language tag "de-DE-1996" (German as used in Germany,=0A= orthography of 1996), but not the language tags "de-Deva" (German as=0A= written in the Devanagari script) or "de-Latn-DE" (German, Latin=0A= script, as used in Germany).=0A= =0A= The special range "*" in a language priority list matches any tag. A=0A= protocol which uses language ranges MAY specify additional rules=0A= about the semantics of "*"; for instance, HTTP/1.1 [RFC2616]=0A= specifies that the range "*" matches only languages not matched by=0A= any other range within an "Accept-Language" header.=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 10]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= Basic filtering is identical to the type of matching described in=0A= [RFC3066], Section 2.5 (Language-range).=0A= =0A= 3.3.2. Extended Filtering=0A= =0A= Extended filtering compares extended language ranges to language=0A= tags. Each extended language range in the language priority list is=0A= considered in turn, according to priority. A language range matches=0A= a particular language tag if their list of subtags match. To=0A= determine a match:=0A= =0A= 1. Split both the extended language range and the language tag being=0A= compared into a list of subtags by dividing on the hyphen (%2D)=0A= character. Two subtags match if either they are the same when=0A= compared case-insensitively or the language range's subtag is the=0A= wildcard '*'.=0A= =0A= 2. Begin with the first subtag in each list. If the first subtag in=0A= the range does not match the first subtag in the tag, the overall=0A= match fails. Otherwise, move to the next subtag in both the=0A= range and the tag.=0A= =0A= 3. While there are more subtags left in the language range's list:=0A= =0A= A. If the subtag currently being examined in the range is the=0A= wildcard ('*'), move to the next subtag in the range and=0A= continue with the loop.=0A= =0A= B. Else, if there are no more subtags in the language tag's=0A= list, the match fails.=0A= =0A= C. Else, if the current subtag in the range's list matches the=0A= current subtag in the language tag's list, move to the next=0A= subtag in both lists and continue with the loop.=0A= =0A= D. Else, if the language tag's subtag is a "singleton" (a single=0A= letter or digit, which includes the private-use subtag 'x')=0A= the match fails.=0A= =0A= E. Else, move to the next subtag in the language tag's list and=0A= continue with the loop.=0A= =0A= 4. When the language range's list has no more subtags, the match=0A= succeeds.=0A= =0A= Subtags not specified, including those at the end of the language=0A= range, are thus treated as if assigned the wildcard value '*'. Much=0A= like basic filtering, extended filtering selects content with=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 11]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= arbitrarily long tags that share the same initial subtags as the=0A= language range. In addition, extended filtering selects language=0A= tags that contain any intermediate subtags not specified in the=0A= language range. For example, the extended language range "de-*-DE"=0A= (or its synonym "de-DE") matches all of the following tags:=0A= =0A= de-DE (German, as used in Germany)=0A= =0A= de-de (German, as used in Germany)=0A= =0A= de-Latn-DE (Latin script)=0A= =0A= de-Latf-DE (Fraktur variant of Latin script)=0A= =0A= de-DE-x-goethe (private use subtag)=0A= =0A= de-Latn-DE-1996 (orthography of 1996)=0A= =0A= de-Deva-DE (Devanagari script)=0A= =0A= The same range does not match any of the following tags for the=0A= reasons shown:=0A= =0A= de (missing 'DE')=0A= =0A= de-x-DE (singleton 'x' occurs before 'DE')=0A= =0A= de-Deva ('Deva' not equal to 'DE')=0A= =0A= Note: [RFC3066bis] defines each type of subtag (language, script,=0A= region, and so forth) according to position, size, and content. This=0A= means that subtags in a language range can only match specific types=0A= of subtags in a language tag. For example, a subtag such as 'Latn'=0A= is always a script subtag (unless it follows a singleton) while a=0A= subtag such as 'nedis' can only match the equivalent variant subtag.=0A= Two-letter subtags in initial position have a different type=0A= (language) than two-letter subtags in later positions (region). This=0A= is the reason why a wildcard in the extended language range is=0A= significant in the first position but is ignored in all other=0A= positions.=0A= =0A= 3.4. Lookup=0A= =0A= Lookup is used to select the single language tag that best matches=0A= the language priority list for a given request. When performing=0A= lookup, each language range in the language priority list is=0A= considered in turn, according to priority. By contrast with=0A= filtering, each language range represents the _most_ specific tag=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 12]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= which is an acceptable match. The first matching tag found,=0A= according to the user's priority, is considered the closest match and=0A= is the item returned. For example, if the language range is "de-ch",=0A= a lookup operation can produce content with the tags "de" or "de-CH"=0A= but never content with the tag "de-CH-1996". If no language tag=0A= matches the request, the "default" value is returned.=0A= =0A= For example, if an application inserts some dynamic content into a=0A= document, returning an empty string if there is no exact match is not=0A= an option. Instead, the application "falls back" until it finds a=0A= matching language tag associated with a suitable piece of content to=0A= insert. Some applications of lookup include:=0A= =0A= o Selection of a template containing the text for an automated email=0A= response.=0A= =0A= o Selection of a item containing some text for inclusion in a=0A= particular Web page.=0A= =0A= o Selection of a string of text for inclusion in an error log.=0A= =0A= o Selection of an audio file to play as a prompt in a phone system.=0A= =0A= In the lookup scheme, the language range is progressively truncated=0A= from the end until a matching language tag is located. Single letter=0A= or digit subtags (including both the letter 'x' which introduces=0A= private-use sequences, and the subtags that introduce extensions) are=0A= removed at the same time as their closest trailing subtag. For=0A= example, starting with the range "zh-Hant-CN-x-private1-private2"=0A= (Chinese, Traditional script, China, two private use tags) the lookup=0A= progressively searches for content as shown below:=0A= =0A= Range to match: zh-Hant-CN-x-private1-private2=0A= 1. zh-Hant-CN-x-private1-private2=0A= 2. zh-Hant-CN-x-private1=0A= 3. zh-Hant-CN=0A= 4. zh-Hant=0A= 5. zh=0A= 6. (default)=0A= =0A= Figure 3: Example of a Lookup Fallback Pattern=0A= =0A= This fallback behavior allows some flexibility in finding a match.=0A= Without fallback, the default content would be returned immediately=0A= if exactly matching content is unavailable. With fallback, a result=0A= more closely matching the user request can be provided.=0A= =0A= Extensions and unrecognized private-use subtags might be unrelated to=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 13]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= a particular application of lookup. Since these subtags come at the=0A= end of the subtag sequence, they are removed first during the=0A= fallback process and usually pose no barrier to interoperability.=0A= However, an implementation MAY remove these from ranges prior to=0A= performing the lookup (provided the implementation also removes them=0A= from the tags being compared). Such modification is internal to the=0A= implementation and applications, protocols, or specifications SHOULD=0A= NOT remove or modify subtags in content that they return or forward,=0A= because this removes information that can be used elsewhere.=0A= =0A= The special language range "*" matches any language tag. In the=0A= lookup scheme, this range does not convey enough information by=0A= itself to determine which language tag is most appropriate, since it=0A= matches everything. If the language range "*" is followed by other=0A= language ranges, it is skipped. If the language range "*" is the=0A= only one in the language priority list or if no other language range=0A= follows, the default value is computed and returned.=0A= =0A= In some cases, the language priority list can contain one or more=0A= extended language ranges (as, for example, when the same language=0A= priority list is used as input for both lookup and filtering=0A= operations). Wildcard values in an extended language range normally=0A= match any value that can occur in that position in a language tag.=0A= Since only one item can be returned for any given lookup request,=0A= wildcards in a language range have to be processed in a consistent=0A= manner or the same request will produce widely varying results.=0A= Applications, protocols, or specifications that accept extended=0A= language ranges MUST define which item is returned when more than one=0A= item matches the extended language range.=0A= =0A= For example, an implementation could map the extended language ranges=0A= to basic ranges. Another possibility would be for an implementation=0A= to return the matching tag that is first in ASCII-order. If the=0A= language range were "*-CH" ('CH' represents Switzerland) and the set=0A= of tags included "de-CH" (German as used in Switzerland), "fr-CH"=0A= (French, Switzerland), and "it-CH" (Italian, Switzerland), then the=0A= tag "de-CH" would be returned.=0A= =0A= 3.4.1. Default Values=0A= =0A= Each application, protocol, or specification that uses lookup MUST=0A= define the defaulting behavior when no tag matches the language=0A= priority list. What this action consists of strongly depends on how=0A= lookup is being applied. Some examples of defaulting behavior=0A= include:=0A= =0A= o return an item with no language tag or an item of a non-linguistic=0A= nature, such as an image or sound=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 14]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= o return a null string as the language tag value, in cases where the=0A= protocol permits the empty value (see, for example, "xml:lang" in=0A= [XML10])=0A= =0A= o return a particular language tag designated for the operation=0A= =0A= o return the language tag "i-default" (see: [RFC2277])=0A= =0A= o return an error condition or error message=0A= =0A= o return a list of available languages for the user to select from=0A= =0A= When performing lookup using a language priority list, the=0A= progressive search MUST process each language range in the list=0A= before seeking or calculating the default.=0A= =0A= The default value MAY be calculated or include additional searching=0A= or matching. Applications, protocols, or specifications can specify=0A= different ways in which users can specify or override the defaults.=0A= =0A= One common way to provide for a default is to allow a specific=0A= language range to be set as the default for a specific type of=0A= request. If this approach is chosen, this language range MUST be=0A= treated as if it were appended to the end of the language priority=0A= list as a whole, rather than after each item in the language priority=0A= list. The application, protocol, or specification MUST also define=0A= the defaulting behavior if that search fails to find a matching tag=0A= or item.=0A= =0A= For example, if a particular user's language priority list is "fr-FR,=0A= zh-Hant" (French as used in France followed by Chinese as written in=0A= the Traditional script) and the program doing the matching had a=0A= default language range of "ja-JP" (Japanese as used in Japan), then=0A= the program searches as follows:=0A= =0A= 1. fr-FR=0A= 2. fr=0A= 3. zh-Hant // next language=0A= 4. zh=0A= 5. ja-JP // now searching for the default content=0A= 6. ja=0A= 7. (implementation defined default)=0A= =0A= Figure 4: Lookup Using a Language Priority List=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 15]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 4. Other Considerations=0A= =0A= When working with language ranges and matching schemes, there are=0A= some additional points that can influence the choice of either.=0A= =0A= 4.1. Choosing Language Ranges=0A= =0A= Users indicate their language preferences via the choice of a=0A= language range or the list of language ranges in a language priority=0A= list. The type of matching affects what the best choice is for a=0A= user.=0A= =0A= Most matching schemes make no attempt to process the semantic meaning=0A= of the subtags. The language range is compared, in a case-=0A= insensitive manner, to each language tag being matched, using basic=0A= string processing. Users SHOULD select language ranges that are=0A= well-formed, valid language tags according to [RFC3066bis]=0A= (substituting wildcards as appropriate in extended language ranges).=0A= =0A= Applications are encouraged to canonicalize language tags and ranges=0A= by using the Preferred-Value from the IANA Language Subtag Registry=0A= for tags or subtags which have been deprecated. If the user is=0A= working with content that might use the older form, the user might=0A= want to include both the new and old forms in a language priority=0A= list. For example, the tag "art-lojban" is deprecated. The subtag=0A= 'jbo' is supposed to be used instead, so the user might use it to=0A= form the language range. Or the user might include both in a=0A= language priority list: "jbo, art-lojban".=0A= =0A= Users SHOULD avoid subtags that add no distinguishing value to a=0A= language range. When filtering, the fewer the number of subtags that=0A= appear in the language range, the more content the range will=0A= probably match, while in lookup unnecessary subtags can cause=0A= "better", more-specific content to be skipped in favor of less=0A= specific content. For example, the range "de-Latn-DE" returns=0A= content tagged "de" instead of content tagged "de-DE", even though=0A= the latter is probably a better match.=0A= =0A= Whether a subtag adds distinguishing value can depend on the context=0A= of the request. For example, a user who reads both Simplified and=0A= Traditional Chinese, but who prefers Simplified, might use the range=0A= "zh" for filtering (matching all items that user can read) but "zh-=0A= Hans" for lookup (making sure that user gets the preferred form if=0A= it's available, but the fallback to "zh" will still work). On the=0A= other hand, content in this case ought to be labeled as "zh-Hans" (or=0A= "zh-Hant" if that applies) for filtering, while for lookup, if there=0A= is either "zh-Hans" content or "zh-Hant" content, one of them (the=0A= one considered 'default') also ought to be made available with the=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 16]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= simple "zh". Note that the user can create a language priority list=0A= "zh-Hans, zh" that delivers the best possible results for both=0A= schemes. If the user cannot be sure which scheme is being used (or=0A= if more than one might be applied to a given request), the user=0A= SHOULD specify the most specific (largest number of subtags) range=0A= first and then supply shorter prefixes later in the list to ensure=0A= that filtering returns a complete set of tags.=0A= =0A= Many languages are written predominantly in a single script. This is=0A= usually recorded in the Suppress-Script field in that language=0A= subtag's registry entry. For these languages, script subtags SHOULD=0A= NOT be used to form a language range. Thus the language range "en-=0A= Latn" is inappropriate in most cases (because the vast majority of=0A= English documents are written in the Latin script and thus the 'en'=0A= language subtag has a Suppress-Script field for 'Latn' in the=0A= registry).=0A= =0A= When working with tags and ranges, note that extensions and most=0A= private-use subtags are orthogonal to language tag matching, in that=0A= they specify additional attributes of the text not related to the=0A= goals of most matching schemes. Users SHOULD avoid using these=0A= subtags in language ranges, since they interfere with the selection=0A= of available content. When used in language tags (as opposed to=0A= ranges), these subtags normally do not interfere with filtering=0A= (Section 3), since they appear at the end of the tag and will match=0A= all prefixes. Lookup (Section 3.4) implementations are advised to=0A= ignore unrecognized private-use and extension subtags when performing=0A= language tag fallback.=0A= =0A= 4.2. Meaning of Language Tags and Ranges=0A= =0A= Selecting language tags using language ranges requires some=0A= understanding by users of what they are selecting. The meaning of=0A= the various subtags in a language range are identical to their=0A= meaning in a language tag (see Section 4.2 in [RFC3066bis]), with the=0A= addition that the wildcard "*" represents any matching sequence of=0A= values.=0A= =0A= 4.3. Considerations for Private Use Subtags=0A= =0A= Private argeement is necessary between the parties that intend to use=0A= or exchange language tags that contain private-use subtags. Great=0A= caution SHOULD be used in employing private-use subtags in content or=0A= protocols intended for general use. Private-use subtags are simply=0A= useless for information exchange without prior arrangement.=0A= =0A= The value and semantic meaning of private-use tags and of the subtags=0A= used within such a language tag are not defined. Matching private-=0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 17]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= use tags using language ranges or extended language ranges can result=0A= in unpredictable content being returned.=0A= =0A= 4.4. Length Considerations for Language Ranges=0A= =0A= Language ranges are very similar to language tags in terms of content=0A= and usage. The same types of restrictions on length that can be=0A= applied to language tags can also be applied to language ranges. See=0A= [RFC3066bis] Section 4.3 (Length Considerations).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 18]=0A= =0C=0A= Internet-Draft ltru-matching May 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 November 19, 2006 [Page 19]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 6. Security Considerations=0A= =0A= Language ranges used in content negotiation might be used to infer=0A= the nationality of the sender, and thus identify potential targets=0A= for surveillance. In addition, unique or highly unusual language=0A= ranges or combinations of language ranges might be used to track a=0A= specific individual's activities.=0A= =0A= This is a special case of the general problem that anything you send=0A= is visible to the receiving party. It is useful to be aware that=0A= such concerns can exist in some cases.=0A= =0A= The evaluation of the exact magnitude of the threat, and any possible=0A= countermeasures, is left to each application or protocol.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 20]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 7. Character Set Considerations=0A= =0A= Language tags permit only the characters A-Z, a-z, 0-9, and HYPHEN-=0A= MINUS (%x2D). Language ranges also use the character ASTERISK=0A= (%x2A). These characters are present in most character sets, so=0A= presentation or exchange of language tags or ranges should not be=0A= constrained by character set issues.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 21]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 8. References=0A= =0A= 8.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and=0A= Languages", BCP 18, RFC 2277, January 1998.=0A= =0A= [RFC3066bis]=0A= Phillips, A., Ed. and M. Davis, Ed., "Tags for the=0A= Identification of Languages", October 2005, .=0A= =0A= [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax=0A= Specifications: ABNF", RFC 4234, October 2005.=0A= =0A= 8.2. Informative References=0A= =0A= [RFC1766] Alvestrand, H., "Tags for the Identification of=0A= Languages", RFC 1766, March 1995.=0A= =0A= [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,=0A= Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext=0A= Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.=0A= =0A= [RFC2616errata]=0A= IETF, "HTTP/1.1 Specification Errata", October 2004,=0A= .=0A= =0A= [RFC3066] Alvestrand, H., "Tags for the Identification of=0A= Languages", BCP 47, RFC 3066, January 2001.=0A= =0A= [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,=0A= May 2002.=0A= =0A= [XML10] Bray (et al), T., "Extensible Markup Language (XML) 1.0",=0A= February 2004.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 22]=0A= =0C=0A= Internet-Draft ltru-matching May 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, Stephane Bortzmeyer, Jeremy Carroll, Peter=0A= Constable, John Cowan, Mark Crispin, Martin Duerst, Frank Ellermann,=0A= Doug Ewell, Debbie Garside, Marion Gunn, Jon Hanna, Kent Karlsson,=0A= Erkki Kolehmainen, Jukka Korpela, Ira McDonald, M. Patton, Randy=0A= Presuhn, Eric van der Poel, Markus Scherer, Misha Wolf, and many,=0A= many others.=0A= =0A= Very special thanks must go to Harald Tveit Alvestrand, who=0A= originated RFCs 1766 and 3066, and without whom this document would=0A= not have been possible.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 23]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= Authors' Addresses=0A= =0A= Addison Phillips (editor)=0A= Yahoo! Inc.=0A= =0A= Email: addison@inter-locale.com=0A= =0A= =0A= Mark Davis (editor)=0A= Google=0A= =0A= Email: mark.davis@macchiato.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 19, 2006 [Page 24]=0A= =0C=0A= Internet-Draft ltru-matching May 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 November 19, 2006 [Page 25]=0A= =0C=0A= ------=_NextPart_000_0007_01C67A6B.F4B834C0 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_0007_01C67A6B.F4B834C0-- From ltru-bounces@ietf.org Thu May 18 17:44:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqIj-0004ZZ-8z; Thu, 18 May 2006 17:44:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqIi-0004ZU-M2 for ltru@ietf.org; Thu, 18 May 2006 17:44:56 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgqIg-0000bm-1q for ltru@ietf.org; Thu, 18 May 2006 17:44:56 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k4ILiiZ5018021; Fri, 19 May 2006 06:44:44 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 74d7_84bf64c8_e6b7_11da_9136_0014221fa3c9; Fri, 19 May 2006 06:44:43 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4ILhUdA001582; Fri, 19 May 2006 06:43:56 +0900 Message-Id: <6.0.0.20.2.20060518212742.05d4dec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 19 May 2006 06:38:24 +0900 To: "'LTRU Working Group'" , Addison Phillips , Mark Davis From: Martin Duerst In-Reply-To: <000d01c679bd$5ea32d90$660a0a0a@ds.corp.yahoo.com> References: <007901c679bc$ae02cef0$040aa8c0@DGBP7M81> <000d01c679bd$5ea32d90$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: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Ltru] Next Steps X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [co-chair hat on] At 23:22 06/05/17, Addison Phillips wrote: >Martin has indicated that this will be submitted to our AD, rather than >going back to another WG last call. Yes indeed. >> From: Doug Ewell [mailto:dewell@adelphia.net] >> Is this going to be a final submission for IANA Last Call, or are we >> going to go through the same drill all over again? (Issue draft, wait >> for LC to be called, let two weeks pass, flood of comments, repeat...) The first WG Last Call brought up quite a few substantive issues, and resulted in significant changes in the document. It was therefore necessary to make another WG Last Call. The second WG Last only brought up editorial issues, which means we can move forward with the document. This is my assessment as the 'managing' co-chair for the matching document. If anybody disagrees, they should say so soon, and why. Here are the next steps: - Editors, please officially submit another draft version of the matching document. With this, everybody can use an official version to cross-check that their Last Call comments have been addressed. Also, I will use this version to prepare the necessary documents for submission to the Area Director in charge and to the IESG. - I plan to do my side of the work over the weekend, but we probably have to give everybody a couple days after the draft officially appeared for cross-checking. - If there are any further problems found, the editors will have to roll further drafts. But if not, this will be the draft that goes to the IESG. "Further problems" at this stage can be mainly two things: 1) If find something that doesn't conform to one of the various checklists that the IETF has for this stage (I don't expect anything serious, because our editors have been aware of this all the time.) 2) Somebody finds that the editors didn't understand, or made a mistake when implementing, their (2nd!) Last Call comments. Any other comments or changes are in principle out of range at this stage, although we will still fix obvious typos and we in principle would still be open (as we are at any stage) to going back to fix serious substantial errors if there were any. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu May 18 17:57:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqUb-0001fV-OT; Thu, 18 May 2006 17:57:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqUa-0001fN-AC for ltru@ietf.org; Thu, 18 May 2006 17:57:12 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgqUY-0001PU-1e for ltru@ietf.org; Thu, 18 May 2006 17:57:12 -0400 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 k4ILuknF028015; Thu, 18 May 2006 14:56:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:subject:date:message-id:mime-version:content-type: content-transfer-encoding:x-mailer:x-mimeole:thread-index:in-reply-to; b=2DnWCPPMcFBAlL1vlBq7gEu20a60tT8WPoOpwAz9gziSKiMlhyZAUNN/XaCrrLT/ From: "Addison Phillips" To: "'Martin Duerst'" , "'LTRU Working Group'" , "'Mark Davis'" Date: Thu, 18 May 2006 14:56:46 -0700 Message-ID: <003701c67ac5$f5fc5aa0$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.2869 Thread-Index: AcZ6xFcXsARKEW5WSOKxgRW9i0DZ9QAAMgNw In-Reply-To: <6.0.0.20.2.20060518212742.05d4dec0@localhost> X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [Ltru] RE: Next Steps X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Thank you, Martin. > - Editors, please officially submit another draft version of the > matching document. With this, everybody can use an official version > to cross-check that their Last Call comments have been addressed. > Also, I will use this version to prepare the necessary documents > for submission to the Area Director in charge and to the IESG. Draft-13 was submitted this morning (Pacific Time) and, with any luck, will be published shortly. Unofficial copies (which are identical to the submitted document) are posted on my personal website: http://www.inter-locale.com/ID/draft-ietf-ltru-matching-13.txt http://www.inter-locale.com/ID/draft-ietf-ltru-matching-13.html http://www.inter-locale.com/ID/draft-ietf-ltru-matching-13.xml I did not generate a static diff. There is a TinyURL link on my home page that causes rfcdiff to generate one for you, should you desire it. Note that I ran idnits. The only warning was that we were missing the RFC 2119 text (we aren't: xml2rfc generates the text with a pair of very small differences that confuse the tool---the word "keywords" is used instead of "key words" and the reference to RFC 2119 is in square brackets in our version (since it is a reference)). I hope you don't find anything in your review, but am prepared to make any last second changes that result from it or from the reviews of others. For the editors, 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?5?18? 14:38 > To: 'LTRU Working Group'; Addison Phillips; Mark Davis > Subject: Next Steps > > [co-chair hat on] > > At 23:22 06/05/17, Addison Phillips wrote: > >Martin has indicated that this will be submitted to our AD, rather than > >going back to another WG last call. > > Yes indeed. > > > >> From: Doug Ewell [mailto:dewell@adelphia.net] > > > >> Is this going to be a final submission for IANA Last Call, or are we > >> going to go through the same drill all over again? (Issue draft, wait > >> for LC to be called, let two weeks pass, flood of comments, repeat...) > > The first WG Last Call brought up quite a few substantive issues, and > resulted in significant changes in the document. It was therefore > necessary to make another WG Last Call. The second WG Last only brought > up editorial issues, which means we can move forward with the document. > > This is my assessment as the 'managing' co-chair for the matching > document. If anybody disagrees, they should say so soon, and why. > > Here are the next steps: > > - Editors, please officially submit another draft version of the > matching document. With this, everybody can use an official version > to cross-check that their Last Call comments have been addressed. > Also, I will use this version to prepare the necessary documents > for submission to the Area Director in charge and to the IESG. > > - I plan to do my side of the work over the weekend, but we probably > have to give everybody a couple days after the draft officially > appeared for cross-checking. > > - If there are any further problems found, the editors will have to > roll further drafts. But if not, this will be the draft that goes > to the IESG. "Further problems" at this stage can be mainly two > things: 1) If find something that doesn't conform to one of the various > checklists that the IETF has for this stage (I don't expect anything > serious, because our editors have been aware of this all the time.) > 2) Somebody finds that the editors didn't understand, or made a > mistake when implementing, their (2nd!) Last Call comments. > Any other comments or changes are in principle out of range at this > stage, although we will still fix obvious typos and we in principle > would still be open (as we are at any stage) to going back to fix > serious substantial errors if there were any. > > Regards, Martin. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri May 19 03:13:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgzBL-0004jt-Tx; Fri, 19 May 2006 03:13:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgzBJ-0004jg-6S; Fri, 19 May 2006 03:13:53 -0400 Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgzBG-0001BI-TA; Fri, 19 May 2006 03:13:53 -0400 Received: from h-68-166-188-90.snvacaid.dynamic.covad.net ([68.166.188.90] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1FgzBA-0006a7-00; Fri, 19 May 2006 03:13:44 -0400 Message-ID: <004701c67b14$7dcd3280$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "Disman" , "LTRU Working Group" Date: Fri, 19 May 2006 00:18:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Subject: [Ltru] Fw: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - Forwarded for your information. Note well that currently there are no plans for either disman or ltru to meet in Montreal. If you think a face-to-face meeting is warranted for either group, please post your agenda proposals to the appropriate working group's mailing list. Randy > From: > To: > Sent: Thursday, May 18, 2006 9:00 PM > Subject: Internet-Drafts Submission Cutoff Dates for the 66th IETF Meeting in Montreal, Quebec, Canada > > There are two (2) Internet-Draft cutoff dates for the 66th > IETF Meeting in Montreal, Quebec, Canada: > > June 19th: Cutoff Date for Initial (i.e., version -00) > Internet-Draft Submissions > > All initial Internet-Drafts (version -00) must be submitted by Monday, > June 19th at 9:00 AM ET. As always, all initial submissions with a > filename beginning with "draft-ietf" must be approved by the > appropriate WG Chair before they can be processed or announced. The > Secretariat would appreciate receiving WG Chair approval by Monday, > June 12th at 9:00 AM ET. > > June 26th: Cutoff Date for Revised (i.e., version -01 and higher) > Internet-Draft Submissions > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, June 26th at 9:00 AM ET. > > Initial and revised Internet-Drafts received after their respective > cutoff dates will not be made available in the Internet-Drafts > directory or announced until on or after Monday, July 10th at 9:00 > AM ET, when Internet-Draft posting resumes. Please do not wait until > the last minute to submit. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant dates > for the 66th IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_66.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri May 19 15:50:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAzE-0006pU-2Z; Fri, 19 May 2006 15:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAz5-0006nY-7A; Fri, 19 May 2006 15:50:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhAz3-0007tE-TO; Fri, 19 May 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4JJo1XO012581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 19 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FhAz3-00031e-Ba; Fri, 19 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 19 May 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-matching-13.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-13.txt Pages : 25 Date : 2006-5-19 This document describes a syntax, called a "language-range", for specifying items in a user's language preferences, called a "language priority list". It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 3066bis (Ed.: replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-13.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-13.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-13.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-5-19143354.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-matching-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-matching-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-19143354.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 Sat May 20 13:59:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhVjb-0000aN-5E; Sat, 20 May 2006 13:59:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhVja-0000aI-7L for ltru@ietf.org; Sat, 20 May 2006 13:59:26 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhVjW-0007Mp-Ur for ltru@ietf.org; Sat, 20 May 2006 13:59:26 -0400 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 <20060520175922.GNCG27996.mta10.adelphia.net@DGBP7M81> for ; Sat, 20 May 2006 13:59:22 -0400 Message-ID: <001401c67c37$1e024ab0$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Next Steps Date: Sat, 20 May 2006 10:59:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst wrote: >>> Is this going to be a final submission for IANA Last Call, or are we >>> going to go through the same drill all over again? (Issue draft, >>> wait for LC to be called, let two weeks pass, flood of comments, >>> repeat...) > > The first WG Last Call brought up quite a few substantive issues, and > resulted in significant changes in the document. It was therefore > necessary to make another WG Last Call. The second WG Last only > brought up editorial issues, which means we can move forward with the > document. I agree with this assessment. I still think it was unfortunate that a large number of the substantive issues with draft-matching-11 were raised on the final day of that document's Last Call (March 30); that the Last Call for draft-12 was delayed until almost four weeks after Addison submitted the draft (I know Martin said there were "personal reasons" for this); and that the vast majority of editorial comments on draft-12 were not raised until May 16, again the final day of Last Call. I understand the concept of deadlines being missed and pushed back when additional work is identified, but I really don't understand much of the recent "dead time" delay in moving this document forward. Draft-13 has been posted and announced, and I hope it can be submitted to IETF no later than Wednesday (allowing time for Martin's weekend work and the "couple days" he wants to give everyone else for cross-checking). Sorry to seem confrontational, but I'm very tired of the current "it is but it isn't" limbo of RFC 3066bis and BCP 47, and I'm sure others are too. -- 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 Tue May 30 08:43:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl3ZV-0000fm-Cq; Tue, 30 May 2006 08:43:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl3ZU-0000fS-Ez; Tue, 30 May 2006 08:43:40 -0400 Received: from mrout1-b.corp.dcn.yahoo.com ([216.109.112.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl3ZQ-0006xw-3S; Tue, 30 May 2006 08:43:40 -0400 Received: from duringpersonlx (snvvpn1-10-72-72-c10.corp.yahoo.com [10.72.72.10]) by mrout1-b.corp.dcn.yahoo.com (8.13.6/8.13.4/y.out) with ESMTP id k4UCh3FW023127; Tue, 30 May 2006 05:43:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=from:to:cc:subject:date:message-id:mime-version: content-type:x-mailer:x-mimeole:thread-index; b=dCNqkBA+6XwofWfkiZNbc+rARroQ7gqwvH/DRUccLfKBNfSctfkycU7VhSgyu68J From: "Addison Phillips" To: Date: Tue, 30 May 2006 14:43:02 +0200 Message-ID: <000a01c683e6$98347810$0831a8c0@ds.corp.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C683F7.5BBD4810" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcaD5pazzV7Vk8VGTBC1K9zUOi9EnQ== X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 559f665b314b470cdc75385381d53ee0 Cc: 'LTRU Working Group' Subject: [Ltru] Submission: draft-ietf-ltru-matching-14 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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_000B_01C683F7.5BBD4810 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear Editors, Please find attached draft-14 of "draft-ietf-ltru-matching" in text = format. Idnits was run. LTRU members: this draft was requested by the chair as the final step = for submission for last call (at the IETF level). As soon as I get the = chance I will post a link to the diff (very minor editorial = corrections). Addison Addison Phillips Internationalization Architect - Yahoo! Inc. Internationalization is an architecture. It is not a feature.=20 ------=_NextPart_000_000B_01C683F7.5BBD4810 Content-Type: text/plain; name="draft-ietf-ltru-matching-14.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-ltru-matching-14.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: November 30, 2006 Google=0A= May 29, 2006=0A= =0A= =0A= Matching of Language Tags=0A= draft-ietf-ltru-matching-14=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 November 30, 2006.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2006).=0A= =0A= Abstract=0A= =0A= This document describes a syntax, called a "language-range", for=0A= specifying items in a user's language preferences, called a "language=0A= priority list". It also describes different mechanisms for comparing=0A= and matching these to language tags. Two kinds of matching=0A= mechanisms, filtering and lookup, are defined. Filtering produces a=0A= (potentially empty) set of language tags, whereas lookup produces a=0A= single language tag. Possible applications include language=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 1]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= negotiation or content selection. This document, in combination with=0A= RFC 3066bis (Ed.: replace "3066bis" with the RFC number assigned to=0A= draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC=0A= 1766.=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. The Language Range . . . . . . . . . . . . . . . . . . . . . . 4=0A= 2.1. Basic Language Range . . . . . . . . . . . . . . . . . . . 4=0A= 2.2. Extended Language Range . . . . . . . . . . . . . . . . . 5=0A= 2.3. The Language Priority List . . . . . . . . . . . . . . . . 5=0A= 3. Types of Matching . . . . . . . . . . . . . . . . . . . . . . 7=0A= 3.1. Choosing a Matching Scheme . . . . . . . . . . . . . . . . 7=0A= 3.2. Implementation Considerations . . . . . . . . . . . . . . 8=0A= 3.3. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 3.3.1. Basic Filtering . . . . . . . . . . . . . . . . . . . 10=0A= 3.3.2. Extended Filtering . . . . . . . . . . . . . . . . . . 11=0A= 3.4. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 12=0A= 3.4.1. Default Values . . . . . . . . . . . . . . . . . . . . 14=0A= 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 16=0A= 4.1. Choosing Language Ranges . . . . . . . . . . . . . . . . . 16=0A= 4.2. Meaning of Language Tags and Ranges . . . . . . . . . . . 17=0A= 4.3. Considerations for Private Use Subtags . . . . . . . . . . 17=0A= 4.4. Length Considerations for Language Ranges . . . . . . . . 18=0A= 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19=0A= 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20=0A= 7. Character Set Considerations . . . . . . . . . . . . . . . . . 21=0A= 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22=0A= 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22=0A= 8.2. Informative References . . . . . . . . . . . . . . . . . . 22=0A= Appendix A. 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= Phillips & Davis Expires November 30, 2006 [Page 2]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 1. Introduction=0A= =0A= Human beings on our planet have, past and present, used a number of=0A= languages. There are many reasons why one would want to identify the=0A= language used when presenting or requesting information.=0A= =0A= Applications, protocols, or specifications that use language=0A= identifiers, such as the language tags defined in [RFC3066bis],=0A= sometimes need to match language tags to a user's language=0A= preferences.=0A= =0A= This document defines a syntax (called a language range (Section 2))=0A= for specifying items in the user's list of language preferences=0A= (called a language priority list (Section 2.3)), as well as several=0A= schemes for selecting or filtering sets of language tags by comparing=0A= the language tags to the user's preferences. Applications,=0A= protocols, or specifications will have varying needs and requirements=0A= that affect the choice of a suitable matching scheme.=0A= =0A= This document describes: how to indicate a user's preferences using=0A= language ranges; three schemes for matching these ranges to a set of=0A= language tags; and the various practical considerations that apply to=0A= implementing and using these schemes.=0A= =0A= This document, in combination with [RFC3066bis] (Ed.: replace=0A= "3066bis" globally in this document with the RFC number assigned to=0A= draft-ietf-ltru-registry-14), replaces [RFC3066], which replaced=0A= [RFC1766].=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 3]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 2. The Language Range=0A= =0A= Language tags [RFC3066bis] are used to help identify languages,=0A= whether spoken, written, signed, or otherwise signaled, for the=0A= purpose of communication. Applications, protocols, or specifications=0A= that use language tags are often faced with the problem of=0A= identifying sets of content that share certain language attributes.=0A= For example, HTTP/1.1 [RFC2616] describes one such mechanism in its=0A= discussion of the Accept-Language header (Section 14.4), which is=0A= used when selecting content from servers based on the language of=0A= that content.=0A= =0A= It is, thus, useful to have a mechanism for identifying sets of=0A= language tags that share specific attributes. This allows users to=0A= select or filter the language tags based on specific requirements.=0A= Such an identifier is called a "language range".=0A= =0A= There are different types of language range, whose specific=0A= attributes vary according to their application. Language ranges are=0A= similar to language tags: they consist of a sequence of subtags=0A= separated by hyphens. In a language range, each subtag MUST either=0A= be a sequence of ASCII alphanumeric characters or the single=0A= character '*' (%2A, ASTERISK). The character '*' is a "wildcard"=0A= that matches any sequence of subtags. The meaning and uses of=0A= wildcards vary according to the type of language range.=0A= =0A= Language tags and thus language ranges are to be treated as case-=0A= insensitive: there exist conventions for the capitalization of some=0A= of the subtags, but these MUST NOT be taken to carry meaning.=0A= Matching of language tags to language ranges MUST be done in a case-=0A= insensitive manner.=0A= =0A= 2.1. Basic Language Range=0A= =0A= A "basic language range" has the same syntax as an [RFC3066] language=0A= tag or is the single character "*". The basic language range was=0A= originally described by HTTP/1.1 [RFC2616] and later [RFC3066]. It=0A= is defined by the following ABNF [RFC4234]:=0A= =0A= language-range =3D (1*8ALPHA *("-" 1*8alphanum)) / "*"=0A= alphanum =3D ALPHA / DIGIT=0A= =0A= A basic language range differs from the language tags defined in=0A= [RFC3066bis] only in that there is no requirement that it be "well-=0A= formed" or be validated against the IANA Language Subtag Registry.=0A= Such ill-formed ranges will probably not match anything. Note that=0A= the ABNF [RFC4234] in [RFC2616] is incorrect, since it disallows the=0A= use of digits anywhere in the 'language-range' (see:=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 4]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= [RFC2616errata]).=0A= =0A= 2.2. Extended Language Range=0A= =0A= Occasionally users will wish to select a set of language tags based=0A= on the presence of specific subtags. An "extended language range"=0A= describes a user's language preference as an ordered sequence of=0A= subtags. For example, a user might wish to select all language tags=0A= that contain the region subtag 'CH' (Switzerland). Extended language=0A= ranges are useful for specifying a particular sequence of subtags=0A= that appear in the set of matching tags without having to specify all=0A= of the intervening subtags.=0A= =0A= An extended language range can be represented by the following ABNF:=0A= =0A= extended-language-range =3D (1*8ALPHA / "*")=0A= *("-" (1*8alphanum / "*"))=0A= =0A= 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 are ignored by Extended Filtering (see Section=0A= 3.2.2). The use or absence of one or more wildcards cannot be taken=0A= to imply that a certain number of subtags will appear in the matching=0A= set of language tags.=0A= =0A= 2.3. The Language Priority List=0A= =0A= A user's language preferences will often need to specify more than=0A= one language range and thus users often need to specify a prioritized=0A= list of language ranges in order to best reflect their language=0A= preferences. This is especially true for speakers of minority=0A= languages. A speaker of Breton in France, for example, can specify=0A= "br" followed by "fr", meaning that if Breton is available, it is=0A= preferred, but otherwise French is the best alternative. It can get=0A= more complex: a different user might want to fall back from Skolt=0A= Sami to Northern Sami to Finnish.=0A= =0A= A "language priority list" is a prioritized or weighted list of=0A= language ranges. One well known example of such a list is the=0A= "Accept-Language" header defined in RFC 2616 [RFC2616] (see Section=0A= 14.4) and RFC 3282 [RFC3282].=0A= =0A= The various matching operations described in this document include=0A= considerations for using a language priority list. This document=0A= does not define the syntax for a language priority list; defining=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 5]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =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 is read=0A= "English before French before Chinese as written in the Traditional=0A= script").=0A= =0A= A simple list of ranges is considered to be in descending order of=0A= priority. Other language priority lists provide "quality weights"=0A= for the language ranges in order to specify the relative priority of=0A= the user's language preferences. An example of this is the use of=0A= "q" values in the syntax of the "Accept-Language" header (defined in=0A= [RFC2616], Section 14.4, and [RFC3282]).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 6]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 3. Types of Matching=0A= =0A= Matching language ranges to language tags can be done in many=0A= different ways. This section describes three such matching schemes,=0A= as well as the considerations for choosing between them. Protocols=0A= and specifications requiring conformance to this specification MUST=0A= clearly indicate the particular mechanism used in selecting or=0A= matching language tags.=0A= =0A= There are two types of matching scheme in this document. A matching=0A= scheme that produces zero or more matching language tags is called=0A= "filtering". A matching scheme that produces exactly one match for a=0A= given request is called "lookup".=0A= =0A= 3.1. Choosing a Matching Scheme=0A= =0A= Applications, protocols, and specifications are faced with the=0A= decision of what type of matching to use. Sometimes, different=0A= styles of matching are suited to different kinds of processing within=0A= a particular application or protocol.=0A= =0A= This document describes three matching schemes:=0A= =0A= 1. Basic Filtering (Section 3.3.1) matches a language priority list=0A= consisting of basic language ranges (Section 2.1) to sets of=0A= language tags.=0A= =0A= 2. Extended Filtering (Section 3.3.2) matches a language priority=0A= list consisting of extended language ranges (Section 2.2) to sets=0A= of language tags.=0A= =0A= 3. Lookup (Section 3.4) matches a language priority list consisting=0A= of basic language ranges to sets of language tags to find the one=0A= _exact_ language tag that best matches the range.=0A= =0A= Filtering can be used to produce a set of results (such as a=0A= collection of documents) by comparing the user's preferences to a set=0A= of language tags. For example, when performing a search, filtering=0A= can be used to limit the results to items tagged as being in the=0A= French language. Filtering can also be used when deciding whether to=0A= perform a language-sensitive process on some content. For example, a=0A= process might cause paragraphs whose language tag matched the=0A= language range "nl" (Dutch) to be displayed in italics within a=0A= document.=0A= =0A= Lookup produces the single result that best matches the user's=0A= preferences from the list of available tags, so it is useful in cases=0A= in which a single item is required (and for which only a single item=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 7]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= can be returned). For example, if a process were to insert a human=0A= readable error message into a protocol header, it might select the=0A= text based on the user's language priority list. Since the process=0A= can return only one item, it is forced to choose a single item and it=0A= has to return some item, even if none of the content's language tags=0A= match the language priority list supplied by the user.=0A= =0A= 3.2. Implementation Considerations=0A= =0A= Language tag matching is a tool, and does not by itself specify a=0A= complete procedure for the use of language tags. Such procedures are=0A= intimately tied to the application protocol in which they occur.=0A= When specifying a protocol operation using matching, the protocol=0A= MUST specify:=0A= =0A= o Which type(s) of language tag matching it uses=0A= =0A= o Whether the operation returns a single result (lookup) or a=0A= possibly empty set of results (filtering)=0A= =0A= o For lookup, what the default item is (or the sequence of=0A= operations or configuration information used to determine the=0A= default) when no matching tag is found. For instance, a protocol=0A= might define the result as failure of the operation, an empty=0A= value, returning some protocol defined or implementation defined=0A= default, or returning i-default [RFC2277].=0A= =0A= Applications, protocols, and specifications are not required to=0A= validate or understand any of the semantics of the language tags or=0A= ranges or of the subtags in them, nor do they require access to the=0A= IANA Language Subtag Registry (see Section 3 in [RFC3066bis]). This=0A= simplifies implementation.=0A= =0A= However, designers of applications, protocols, or specifications are=0A= encouraged to use the information from the IANA Language Subtag=0A= Registry to support canonicalizing language tags and ranges in order=0A= to map grandfathered and obsolete tags or subtags into modern=0A= equivalents.=0A= =0A= Applications, protocols, or specifications that canonicalize ranges=0A= MUST either perform matching operations with both the canonical and=0A= original (unmodified) form of the range or MUST also canonicalize=0A= each tag for the purposes of comparison.=0A= =0A= Note that canonicalizing language ranges makes certain operations=0A= impossible. For example, an implementation that canonicalizes the=0A= language range "art-lojban" (artificial language, lojban variant) to=0A= use the more modern "jbo" (Lojban) cannot be used to select just the=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 8]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= items with the older tag.=0A= =0A= Applications, protocols, or specifications that use basic ranges=0A= might sometimes receive extended language ranges instead. An=0A= application, protocol, or specification MUST choose to: a) map=0A= extended language ranges to basic ranges using the algorithm below,=0A= b) reject any extended language ranges in the language priority list=0A= that are not valid basic language ranges, or c) treat each extended=0A= language range as if it were a basic language range, which will have=0A= the same result as ignoring them, since these ranges will not match=0A= any valid language tags.=0A= =0A= An extended language range is mapped to a basic language range as=0A= follows: if the first subtag is a '*' then the entire range is=0A= treated as "*", otherwise each wildcard subtag is removed. For=0A= example, the extended language range "en-*-US" maps to "en-US"=0A= (English, United States).=0A= =0A= Applications, protocols, or specifications, in addressing their=0A= particular requirements, can offer pre-processing or configuration=0A= options. For example, an implementation could allow a user to=0A= associate or map a particular language range to a different value.=0A= Such a user might wish to associate the language range subtags 'nn'=0A= (Nynorsk Norwegian) and 'nb' (Bokmal Norwegian) with the more general=0A= subtag 'no' (Norwegian). Or perhaps a user would want to associate=0A= requests for the range "zh-Hans" (Chinese as written in the=0A= Simplified script) with content bearing the language tag "zh-CN"=0A= (Chinese as used in China, where the Simplified script is=0A= predominant). Documentation on how the ranges or tags are altered,=0A= prioritized, or compared in the subsequent match in such an=0A= implementation will assist users in making these types of=0A= configuration choices.=0A= =0A= 3.3. Filtering=0A= =0A= Filtering is used to select the set of language tags that matches a=0A= given language priority list. It is called "filtering" because this=0A= set might contain no items at all or it might return an arbitrarily=0A= large number of matching items: as many items as match the language=0A= priority list, thus "filtering out" the non-matching items.=0A= =0A= In filtering, each language range represents the _least_ specific=0A= language tag (that is, the language tag with fewest number of=0A= subtags) which is an acceptable match. All of the language tags in=0A= the matching set of tags will have an equal or greater number of=0A= subtags than the language range. Every non-wildcard subtag in the=0A= language range will appear in every one of the matching language=0A= tags. For example, if the language priority list consists of the=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 9]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= range "de-CH" (German as used in Switzerland), one might see tags=0A= such as "de-CH-1996" (German as used in Switzerland, orthography of=0A= 1996) but one will never see a tag such as "de" (because the 'CH'=0A= subtag is missing).=0A= =0A= If the language priority list (see Section 2.3) contains more than=0A= one range, the content returned is typically ordered in descending=0A= level of preference, but it MAY be unordered, according to the needs=0A= of the application or protocol.=0A= =0A= Some examples of applications where filtering might be appropriate=0A= include:=0A= =0A= o Applying a style to sections of a document in a particular set of=0A= languages.=0A= =0A= o Displaying the set of documents containing a particular set of=0A= keywords written in a specific set of languages.=0A= =0A= o Selecting all email items written in a specific set of languages.=0A= =0A= o Selecting audio files spoken in a particular language.=0A= =0A= Filtering seems to imply that there is a semantic relationship=0A= between language tags that share the same prefix. While this is=0A= often the case, it is not always true: the language tags that match a=0A= specific language range do not necessarily represent mutually=0A= intelligible languages.=0A= =0A= 3.3.1. Basic Filtering=0A= =0A= Basic filtering compares basic language ranges to language tags.=0A= Each basic language range in the language priority list is considered=0A= in turn, according to priority. A language range matches a=0A= particular language tag if, in a case-insensitive comparison, it=0A= exactly equals the tag, or if it exactly equals a prefix of the tag=0A= such that the first character following the prefix is "-". For=0A= example, the language-range "de-de" (German as used in Germany)=0A= matches the language tag "de-DE-1996" (German as used in Germany,=0A= orthography of 1996), but not the language tags "de-Deva" (German as=0A= written in the Devanagari script) or "de-Latn-DE" (German, Latin=0A= script, as used in Germany).=0A= =0A= The special range "*" in a language priority list matches any tag. A=0A= protocol which uses language ranges MAY specify additional rules=0A= about the semantics of "*"; for instance, HTTP/1.1 [RFC2616]=0A= specifies that the range "*" matches only languages not matched by=0A= any other range within an "Accept-Language" header.=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 10]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= Basic filtering is identical to the type of matching described in=0A= [RFC3066], Section 2.5 (Language-range).=0A= =0A= 3.3.2. Extended Filtering=0A= =0A= Extended filtering compares extended language ranges to language=0A= tags. Each extended language range in the language priority list is=0A= considered in turn, according to priority. A language range matches=0A= a particular language tag if their list of subtags match. To=0A= determine a match:=0A= =0A= 1. Split both the extended language range and the language tag being=0A= compared into a list of subtags by dividing on the hyphen (%2D)=0A= character. Two subtags match if either they are the same when=0A= compared case-insensitively or the language range's subtag is the=0A= wildcard '*'.=0A= =0A= 2. Begin with the first subtag in each list. If the first subtag in=0A= the range does not match the first subtag in the tag, the overall=0A= match fails. Otherwise, move to the next subtag in both the=0A= range and the tag.=0A= =0A= 3. While there are more subtags left in the language range's list:=0A= =0A= A. If the subtag currently being examined in the range is the=0A= wildcard ('*'), move to the next subtag in the range and=0A= continue with the loop.=0A= =0A= B. Else, if there are no more subtags in the language tag's=0A= list, the match fails.=0A= =0A= C. Else, if the current subtag in the range's list matches the=0A= current subtag in the language tag's list, move to the next=0A= subtag in both lists and continue with the loop.=0A= =0A= D. Else, if the language tag's subtag is a "singleton" (a single=0A= letter or digit, which includes the private-use subtag 'x')=0A= the match fails.=0A= =0A= E. Else, move to the next subtag in the language tag's list and=0A= continue with the loop.=0A= =0A= 4. When the language range's list has no more subtags, the match=0A= succeeds.=0A= =0A= Subtags not specified, including those at the end of the language=0A= range, are thus treated as if assigned the wildcard value '*'. Much=0A= like basic filtering, extended filtering selects content with=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 11]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= arbitrarily long tags that share the same initial subtags as the=0A= language range. In addition, extended filtering selects language=0A= tags that contain any intermediate subtags not specified in the=0A= language range. For example, the extended language range "de-*-DE"=0A= (or its synonym "de-DE") matches all of the following tags:=0A= =0A= de-DE (German, as used in Germany)=0A= =0A= de-de (German, as used in Germany)=0A= =0A= de-Latn-DE (Latin script)=0A= =0A= de-Latf-DE (Fraktur variant of Latin script)=0A= =0A= de-DE-x-goethe (private use subtag)=0A= =0A= de-Latn-DE-1996 (orthography of 1996)=0A= =0A= de-Deva-DE (Devanagari script)=0A= =0A= The same range does not match any of the following tags for the=0A= reasons shown:=0A= =0A= de (missing 'DE')=0A= =0A= de-x-DE (singleton 'x' occurs before 'DE')=0A= =0A= de-Deva ('Deva' not equal to 'DE')=0A= =0A= Note: [RFC3066bis] defines each type of subtag (language, script,=0A= region, and so forth) according to position, size, and content. This=0A= means that subtags in a language range can only match specific types=0A= of subtags in a language tag. For example, a subtag such as 'Latn'=0A= is always a script subtag (unless it follows a singleton) while a=0A= subtag such as 'nedis' can only match the equivalent variant subtag.=0A= Two-letter subtags in initial position have a different type=0A= (language) than two-letter subtags in later positions (region). This=0A= is the reason why a wildcard in the extended language range is=0A= significant in the first position but is ignored in all other=0A= positions.=0A= =0A= 3.4. Lookup=0A= =0A= Lookup is used to select the single language tag that best matches=0A= the language priority list for a given request. When performing=0A= lookup, each language range in the language priority list is=0A= considered in turn, according to priority. By contrast with=0A= filtering, each language range represents the _most_ specific tag=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 12]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= which is an acceptable match. The first matching tag found,=0A= according to the user's priority, is considered the closest match and=0A= is the item returned. For example, if the language range is "de-ch",=0A= a lookup operation can produce content with the tags "de" or "de-CH"=0A= but never content with the tag "de-CH-1996". If no language tag=0A= matches the request, the "default" value is returned.=0A= =0A= For example, if an application inserts some dynamic content into a=0A= document, returning an empty string if there is no exact match is not=0A= an option. Instead, the application "falls back" until it finds a=0A= matching language tag associated with a suitable piece of content to=0A= insert. Some applications of lookup include:=0A= =0A= o Selection of a template containing the text for an automated email=0A= response.=0A= =0A= o Selection of a item containing some text for inclusion in a=0A= particular Web page.=0A= =0A= o Selection of a string of text for inclusion in an error log.=0A= =0A= o Selection of an audio file to play as a prompt in a phone system.=0A= =0A= In the lookup scheme, the language range is progressively truncated=0A= from the end until a matching language tag is located. Single letter=0A= or digit subtags (including both the letter 'x' which introduces=0A= private-use sequences, and the subtags that introduce extensions) are=0A= removed at the same time as their closest trailing subtag. For=0A= example, starting with the range "zh-Hant-CN-x-private1-private2"=0A= (Chinese, Traditional script, China, two private use tags) the lookup=0A= progressively searches for content as shown below:=0A= =0A= Range to match: zh-Hant-CN-x-private1-private2=0A= 1. zh-Hant-CN-x-private1-private2=0A= 2. zh-Hant-CN-x-private1=0A= 3. zh-Hant-CN=0A= 4. zh-Hant=0A= 5. zh=0A= 6. (default)=0A= =0A= Figure 3: Example of a Lookup Fallback Pattern=0A= =0A= This fallback behavior allows some flexibility in finding a match.=0A= Without fallback, the default content would be returned immediately=0A= if exactly matching content is unavailable. With fallback, a result=0A= more closely matching the user request can be provided.=0A= =0A= Extensions and unrecognized private-use subtags might be unrelated to=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 13]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= a particular application of lookup. Since these subtags come at the=0A= end of the subtag sequence, they are removed first during the=0A= fallback process and usually pose no barrier to interoperability.=0A= However, an implementation MAY remove these from ranges prior to=0A= performing the lookup (provided the implementation also removes them=0A= from the tags being compared). Such modification is internal to the=0A= implementation and applications, protocols, or specifications SHOULD=0A= NOT remove or modify subtags in content that they return or forward,=0A= because this removes information that can be used elsewhere.=0A= =0A= The special language range "*" matches any language tag. In the=0A= lookup scheme, this range does not convey enough information by=0A= itself to determine which language tag is most appropriate, since it=0A= matches everything. If the language range "*" is followed by other=0A= language ranges, it is skipped. If the language range "*" is the=0A= only one in the language priority list or if no other language range=0A= follows, the default value is computed and returned.=0A= =0A= In some cases, the language priority list can contain one or more=0A= extended language ranges (as, for example, when the same language=0A= priority list is used as input for both lookup and filtering=0A= operations). Wildcard values in an extended language range normally=0A= match any value that can occur in that position in a language tag.=0A= Since only one item can be returned for any given lookup request,=0A= wildcards in a language range have to be processed in a consistent=0A= manner or the same request will produce widely varying results.=0A= Applications, protocols, or specifications that accept extended=0A= language ranges MUST define which item is returned when more than one=0A= item matches the extended language range.=0A= =0A= For example, an implementation could map the extended language ranges=0A= to basic ranges. Another possibility would be for an implementation=0A= to return the matching tag that is first in ASCII-order. If the=0A= language range were "*-CH" ('CH' represents Switzerland) and the set=0A= of tags included "de-CH" (German as used in Switzerland), "fr-CH"=0A= (French, Switzerland), and "it-CH" (Italian, Switzerland), then the=0A= tag "de-CH" would be returned.=0A= =0A= 3.4.1. Default Values=0A= =0A= Each application, protocol, or specification that uses lookup MUST=0A= define the defaulting behavior when no tag matches the language=0A= priority list. What this action consists of strongly depends on how=0A= lookup is being applied. Some examples of defaulting behavior=0A= include:=0A= =0A= o return an item with no language tag or an item of a non-linguistic=0A= nature, such as an image or sound=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 14]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= o return a null string as the language tag value, in cases where the=0A= protocol permits the empty value (see, for example, "xml:lang" in=0A= [W3C.REC-xml-20040204])=0A= =0A= o return a particular language tag designated for the operation=0A= =0A= o return the language tag "i-default" (see: [RFC2277])=0A= =0A= o return an error condition or error message=0A= =0A= o return a list of available languages for the user to select from=0A= =0A= When performing lookup using a language priority list, the=0A= progressive search MUST process each language range in the list=0A= before seeking or calculating the default.=0A= =0A= The default value MAY be calculated or include additional searching=0A= or matching. Applications, protocols, or specifications can specify=0A= different ways in which users can specify or override the defaults.=0A= =0A= One common way to provide for a default is to allow a specific=0A= language range to be set as the default for a specific type of=0A= request. If this approach is chosen, this language range MUST be=0A= treated as if it were appended to the end of the language priority=0A= list as a whole, rather than after each item in the language priority=0A= list. The application, protocol, or specification MUST also define=0A= the defaulting behavior if that search fails to find a matching tag=0A= or item.=0A= =0A= For example, if a particular user's language priority list is "fr-FR,=0A= zh-Hant" (French as used in France followed by Chinese as written in=0A= the Traditional script) and the program doing the matching had a=0A= default language range of "ja-JP" (Japanese as used in Japan), then=0A= the program searches as follows:=0A= =0A= 1. fr-FR=0A= 2. fr=0A= 3. zh-Hant // next language=0A= 4. zh=0A= 5. ja-JP // now searching for the default content=0A= 6. ja=0A= 7. (implementation defined default)=0A= =0A= Figure 4: Lookup Using a Language Priority List=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 15]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 4. Other Considerations=0A= =0A= When working with language ranges and matching schemes, there are=0A= some additional points that can influence the choice of either.=0A= =0A= 4.1. Choosing Language Ranges=0A= =0A= Users indicate their language preferences via the choice of a=0A= language range or the list of language ranges in a language priority=0A= list. The type of matching affects what the best choice is for a=0A= user.=0A= =0A= Most matching schemes make no attempt to process the semantic meaning=0A= of the subtags. The language range is compared, in a case-=0A= insensitive manner, to each language tag being matched, using basic=0A= string processing. Users SHOULD select language ranges that are=0A= well-formed, valid language tags according to [RFC3066bis]=0A= (substituting wildcards as appropriate in extended language ranges).=0A= =0A= Applications are encouraged to canonicalize language tags and ranges=0A= by using the Preferred-Value from the IANA Language Subtag Registry=0A= for tags or subtags which have been deprecated. If the user is=0A= working with content that might use the older form, the user might=0A= want to include both the new and old forms in a language priority=0A= list. For example, the tag "art-lojban" is deprecated. The subtag=0A= 'jbo' is supposed to be used instead, so the user might use it to=0A= form the language range. Or the user might include both in a=0A= language priority list: "jbo, art-lojban".=0A= =0A= Users SHOULD avoid subtags that add no distinguishing value to a=0A= language range. When filtering, the fewer the number of subtags that=0A= appear in the language range, the more content the range will=0A= probably match, while in lookup unnecessary subtags can cause=0A= "better", more-specific content to be skipped in favor of less=0A= specific content. For example, the range "de-Latn-DE" returns=0A= content tagged "de" instead of content tagged "de-DE", even though=0A= the latter is probably a better match.=0A= =0A= Whether a subtag adds distinguishing value can depend on the context=0A= of the request. For example, a user who reads both Simplified and=0A= Traditional Chinese, but who prefers Simplified, might use the range=0A= "zh" for filtering (matching all items that user can read) but "zh-=0A= Hans" for lookup (making sure that user gets the preferred form if=0A= it's available, but the fallback to "zh" will still work). On the=0A= other hand, content in this case ought to be labeled as "zh-Hans" (or=0A= "zh-Hant" if that applies) for filtering, while for lookup, if there=0A= is either "zh-Hans" content or "zh-Hant" content, one of them (the=0A= one considered 'default') also ought to be made available with the=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 16]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= simple "zh". Note that the user can create a language priority list=0A= "zh-Hans, zh" that delivers the best possible results for both=0A= schemes. If the user cannot be sure which scheme is being used (or=0A= if more than one might be applied to a given request), the user=0A= SHOULD specify the most specific (largest number of subtags) range=0A= first and then supply shorter prefixes later in the list to ensure=0A= that filtering returns a complete set of tags.=0A= =0A= Many languages are written predominantly in a single script. This is=0A= usually recorded in the Suppress-Script field in that language=0A= subtag's registry entry. For these languages, script subtags SHOULD=0A= NOT be used to form a language range. Thus the language range "en-=0A= Latn" is inappropriate in most cases (because the vast majority of=0A= English documents are written in the Latin script and thus the 'en'=0A= language subtag has a Suppress-Script field for 'Latn' in the=0A= registry).=0A= =0A= When working with tags and ranges, note that extensions and most=0A= private-use subtags are orthogonal to language tag matching, in that=0A= they specify additional attributes of the text not related to the=0A= goals of most matching schemes. Users SHOULD avoid using these=0A= subtags in language ranges, since they interfere with the selection=0A= of available content. When used in language tags (as opposed to=0A= ranges), these subtags normally do not interfere with filtering=0A= (Section 3), since they appear at the end of the tag and will match=0A= all prefixes. Lookup (Section 3.4) implementations are advised to=0A= ignore unrecognized private-use and extension subtags when performing=0A= language tag fallback.=0A= =0A= 4.2. Meaning of Language Tags and Ranges=0A= =0A= Selecting language tags using language ranges requires some=0A= understanding by users of what they are selecting. The meaning of=0A= the various subtags in a language range are identical to their=0A= meaning in a language tag (see Section 4.2 in [RFC3066bis]), with the=0A= addition that the wildcard "*" represents any matching sequence of=0A= values.=0A= =0A= 4.3. Considerations for Private Use Subtags=0A= =0A= Private argeement is necessary between the parties that intend to use=0A= or exchange language tags that contain private-use subtags. Great=0A= caution SHOULD be used in employing private-use subtags in content or=0A= protocols intended for general use. Private-use subtags are simply=0A= useless for information exchange without prior arrangement.=0A= =0A= The value and semantic meaning of private-use tags and of the subtags=0A= used within such a language tag are not defined. Matching private-=0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 17]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= use tags using language ranges or extended language ranges can result=0A= in unpredictable content being returned.=0A= =0A= 4.4. Length Considerations for Language Ranges=0A= =0A= Language ranges are very similar to language tags in terms of content=0A= and usage. The same types of restrictions on length that can be=0A= applied to language tags can also be applied to language ranges. See=0A= [RFC3066bis] Section 4.3 (Length Considerations).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 18]=0A= =0C=0A= Internet-Draft ltru-matching May 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 November 30, 2006 [Page 19]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 6. Security Considerations=0A= =0A= Language ranges used in content negotiation might be used to infer=0A= the nationality of the sender, and thus identify potential targets=0A= for surveillance. In addition, unique or highly unusual language=0A= ranges or combinations of language ranges might be used to track a=0A= specific individual's activities.=0A= =0A= This is a special case of the general problem that anything you send=0A= is visible to the receiving party. It is useful to be aware that=0A= such concerns can exist in some cases.=0A= =0A= The evaluation of the exact magnitude of the threat, and any possible=0A= countermeasures, is left to each application or protocol.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 20]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 7. Character Set Considerations=0A= =0A= Language tags permit only the characters A-Z, a-z, 0-9, and HYPHEN-=0A= MINUS (%x2D). Language ranges also use the character ASTERISK=0A= (%x2A). These characters are present in most character sets, so=0A= presentation or exchange of language tags or ranges should not be=0A= constrained by character set issues.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 21]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= 8. References=0A= =0A= 8.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and=0A= Languages", BCP 18, RFC 2277, January 1998.=0A= =0A= [RFC3066bis]=0A= Phillips, A., Ed. and M. Davis, Ed., "Tags for the=0A= Identification of Languages", October 2005, .=0A= =0A= [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax=0A= Specifications: ABNF", RFC 4234, October 2005.=0A= =0A= 8.2. Informative References=0A= =0A= [RFC1766] Alvestrand, H., "Tags for the Identification of=0A= Languages", RFC 1766, March 1995.=0A= =0A= [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,=0A= Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext=0A= Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.=0A= =0A= [RFC2616errata]=0A= IETF, "HTTP/1.1 Specification Errata", October 2004,=0A= .=0A= =0A= [RFC3066] Alvestrand, H., "Tags for the Identification of=0A= Languages", BCP 47, RFC 3066, January 2001.=0A= =0A= [RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,=0A= May 2002.=0A= =0A= [W3C.REC-xml-20040204]=0A= Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,=0A= and E. Maler, "Extensible Markup Language (XML) 1.0 (Third=0A= Edition)", W3C REC REC-xml-20040204, February 2004.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 22]=0A= =0C=0A= Internet-Draft ltru-matching May 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, Stephane Bortzmeyer, Jeremy Carroll, Peter=0A= Constable, John Cowan, Mark Crispin, Martin Duerst, Frank Ellermann,=0A= Doug Ewell, Debbie Garside, Marion Gunn, Jon Hanna, Kent Karlsson,=0A= Erkki Kolehmainen, Jukka Korpela, Ira McDonald, M. Patton, Randy=0A= Presuhn, Eric van der Poel, Markus Scherer, Misha Wolf, and many,=0A= many others.=0A= =0A= Very special thanks must go to Harald Tveit Alvestrand, who=0A= originated RFCs 1766 and 3066, and without whom this document would=0A= not have been possible.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 23]=0A= =0C=0A= Internet-Draft ltru-matching May 2006=0A= =0A= =0A= Authors' Addresses=0A= =0A= Addison Phillips (editor)=0A= Yahoo! Inc.=0A= =0A= Email: addison@inter-locale.com=0A= =0A= =0A= Mark Davis (editor)=0A= Google=0A= =0A= Email: mark.davis@macchiato.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Phillips & Davis Expires November 30, 2006 [Page 24]=0A= =0C=0A= Internet-Draft ltru-matching May 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 November 30, 2006 [Page 25]=0A= =0C=0A= ------=_NextPart_000_000B_01C683F7.5BBD4810 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_000B_01C683F7.5BBD4810-- From ltru-bounces@ietf.org Wed May 31 01:28:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlJFy-0006uW-Hm; Wed, 31 May 2006 01:28:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlJFx-0006rQ-To for ltru@ietf.org; Wed, 31 May 2006 01:28:33 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlJFv-0001hN-2B for ltru@ietf.org; Wed, 31 May 2006 01:28:33 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k4V5SJd1010412; Wed, 31 May 2006 14:28:19 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 3dea_44e1471e_f066_11da_8762_0014221fa3c9; Wed, 31 May 2006 14:28:19 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4V5R8R9032474; Wed, 31 May 2006 14:27:37 +0900 Message-Id: <6.0.0.20.2.20060530211915.0a0f9520@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 31 May 2006 14:22:43 +0900 To: Ted Hardie From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: LTRU Working Group Subject: [Ltru] Shepherding writeup 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 Hello Ted, Below please find the shepherding writeup for draft-ietf-ltru-matching. Addison has submitted draft-ietf-ltru-matching-14, which you should be able to see in the relevant directories soon. Please contact me at any time if you have any questions or comments on the draft. Regards, Martin. P.S.: Ted, I'll send another LAST CALL REQUESTED message as soon as I get the notice that draft-ietf-ltru-matching-14 is up. ------------------------------------------------------------------------ 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes. The chairs have repeatedly reviewed the drafts, including this version, and we firmly believe that this ID is ready for forwarding to the IESG for publication. Which chair is the WG Chair Shepherd for this document? That's Martin Duerst, duerst@it.aoyama.ac.jp. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Yes. Key outside reviewers included internationalization experts from W3C and from the Unicode Consortium. Do you have any concerns about the depth or breadth of the reviews that have been performed? No. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, internationalization, XML, etc.)? No, not at all. Internationalization and XML concerns have been very well covered due to the nature of the topic of the draft. Operational issues (related to registry access) have been discussed and resolved, too. Security issues (which relate more to the use of language tags as such than to the definition of particular matching schemes) have been documented. A list of issues brought up during the first and second WG Last Calls and their disposition can be found at http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. There are no concerns about whether there is really a need for the three matching schemes described in the draft. In earlier versions of the draft, there were more matching schemes, and the question "is there really a need for all of these" was quite legitimate. However, the number of matching schemes has been reduced to what we think is the minimum: a) Basic Filtering, as available already in RFC 3066 and widely used, b) Extended Filtering, which addresses the need for certain new kinds of matching due to the change from a tag registry to a subtag registry in draft-ietf-ltru-registry-14, and c) Lookup, which, although newly described in this document, is already implemented, with slight variations, in some HTTP servers, language/locale resource lookup schemes, and so on). If there is any concern that I have personally, it is that I still feel that in a few odd places, the language could be slightly more polished. But I have to admit that I'm usually way more sensitive on such editorial details than others. 1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I think it is fair to say that the WG as a whole understands and agrees with the document, and that there is wide consensus. Even those members of the WG that have mainly been interested and been working on the -registry and -inital draft and are not totally familiar with every minor detail of the -matching draft have read it and understand and agree with the general direction. 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. (It should be separate email because this questionnaire will be entered into the tracker). Yes. See separate mail. 1.g) Have the chairs verified that the document checks out against all the ID nits? (see http://www.ietf.org/ID-Checklist.html). Boilerplate checks are not enough; this check needs to be thorough. Yes. 1.h) Has the document split its references into normative and informative? Yes. Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? No. On the contrary, there is draft-ietf-ltru-registry-14 (and draft-ietf-ltru-initial-06) which are already in the RFC Editor queue but are held up by this draft. The RFC Editor will not publish an RFC with normative references to IDs (will delay the publication until all such IDs are also ready for RFC publicatioin). If the normative references are behind, what is the strategy for their completion? No strategy needed. On a related matter, are there normative references that are downward references, as described in BCP 97, RFC 3967 RFC 3967 [RFC3967]? No. Listing these supports the Area Director in the Last Call downref procedure specified in RFC 3967. 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary * Working Group Summary * Protocol Quality 1.j) Please provide such a write-up. Recent examples can be found in the "Action" announcements for approved documents. Technical Summary The document describes recommended practices for matching language tags as defined in draft-ietf-ltru-registry-14 (customarily called RFC3066bis) to user preferences. To express user preferences, two types of syntax are used, called "Basic Language Range" (allowing wildcards only as single characters) and "Extended Language Range" (allowing wildcards as subtags). Both Basic Language Ranges and Extended Language Ranges can (and customarily are) used in lists which are called "Language Priority Lists". The document describes three different matching schemes. The first matching scheme, Basic Filtering, matches (lists of) Basic Language Ranges against (lists of) language tags, resulting in a (possibly empty) list of matching language tags. This matching scheme is identical to that described in RFC 3066. The second matching scheme, Extended Filtering, matches (lists of) Extended Language Ranges against (lists of) language tags, and produces a (possibly empty) list of matching language tags. This matching scheme takes into account that draft-ietf-ltru-registry (RFC3066bis), in contrast to RFC3066, defines language tags by using a *sub*tag registry. The third matching scheme, Lookup, differs from filtering in that it produces a single matching language tag, possibly by falling back to some default. Lookup is therefore suitable for situations where a single result that best matches user preferences is needed. An example would be the generation of content from a data store. Filtering is useful for situations where multiple results are acceptable, such as searching matching documents or document fragments with certain language tags, or applying certain operations such as styling to document fragments. Working Group Summary This document is the second work item of the LTRU WG. A large part of the work on this document was done after finishing the first work item, which is currently draft-ietf-ltru-registry-14 (together with draft-ietf-ltru-initial-06). While in an intermediary stage, the document contained a larger number of matching schemes, some of which were not well defined, had too many options, or were at best 'nice to have', the WG worked hard to reduce the number of schemes to the necessary minimum. Protocol Quality Of the three language tag matching schemes described in the document, Basic Filtering is already widely implemented. Various implementations of Extended Filtering exist, but they are not yet widely deployed. Implementations corresponding to Lookup also exist and are well used, although not currently directly in IETF technology. 1.k) Note: * The relevant information for the technical summary can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. * For the Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points, decisions where consensus was particularly rough, etc. * For the protocol quality, useful information includes: + Are there existing implementations of the protocol? + Have a significant number of vendors indicated they plan to implement the specification? + Are there any reviewers that merit special mention as having done a thorough review (i.e., that resulted in important changes or a conclusion that the document had no substantive issues)? #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed May 31 06:23:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlNrg-000265-WF; Wed, 31 May 2006 06:23:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlNrf-000260-Es for ltru@ietf.org; Wed, 31 May 2006 06:23:47 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlNrb-0004Ng-Qv for ltru@ietf.org; Wed, 31 May 2006 06:23:47 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k4VANbF0028691 for ; Wed, 31 May 2006 19:23:37 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 3dca_856a6f1c_f08f_11da_910c_0014221fa3c9; Wed, 31 May 2006 19:23:36 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k4VAM4IO004589 for ; Wed, 31 May 2006 19:23:11 +0900 Message-Id: <6.0.0.20.2.20060530210931.0984a860@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 31 May 2006 18:05:05 +0900 To: "LTRU Working Group" From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Next steps for the 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, [This mail was supposed to go out before the 'shephearding' mail, but got stuck. FYI anyway.] This is an update on how things are moving forward with the matching draft. As the shephearding chair for the matching draft, I have carefully re-read draft 13 and checked it against the various guideline documents provided by the IETF. As a result, I have asked the editors to make a few tweaks, and have asked Ted (our AD) to check or confirm a few issues. As a result, the editors will submit draft 14 very soon. I also have updated the last call issues list at http://www.sw.it.aoyama.ac.jp/2006/IETF/ltru/, to show that all the issues brought up have been adequately addressed. I have also drafted the shepherding document, which I will send out as soon as the new draft is out. Based on that, Ted will then trigger the IETF Last Call. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed May 31 15:50:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWhh-00077d-PQ; Wed, 31 May 2006 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWhf-00075R-8E; Wed, 31 May 2006 15:50:03 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWhe-00008k-0K; Wed, 31 May 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k4VJo1Rx020139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FlWhd-0003X1-Lo; Wed, 31 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 31 May 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-matching-14.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-14.txt Pages : 25 Date : 2006-5-31 This document describes a syntax, called a "language-range", for specifying items in a user's language preferences, called a "language priority list". It also describes different mechanisms for comparing and matching these to language tags. Two kinds of matching mechanisms, filtering and lookup, are defined. Filtering produces a (potentially empty) set of language tags, whereas lookup produces a single language tag. Possible applications include language negotiation or content selection. This document, in combination with RFC 3066bis (Ed.: replace "3066bis" with the RFC number assigned to draft-ietf-ltru-registry-14), replaces RFC 3066, which replaced RFC 1766. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-14.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-14.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-14.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-5-31125756.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-matching-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-matching-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-31125756.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 May 31 21:21:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flbss-0007gD-A0; Wed, 31 May 2006 21:21:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flbrg-0006sg-45 for ltru@ietf.org; Wed, 31 May 2006 21:20:44 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flbm5-0001uX-Ce for ltru@ietf.org; Wed, 31 May 2006 21:14:59 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k511En3D009575; Thu, 1 Jun 2006 10:14:49 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 248a_05987572_f10c_11da_8e5d_0014221f2a2d; Thu, 01 Jun 2006 10:14:48 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.6/8.13.1) with ESMTP id k511DlhJ018214; Thu, 1 Jun 2006 10:14:13 +0900 Message-Id: <6.0.0.20.2.20060530212156.04462960@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 31 May 2006 14:25:53 +0900 To: Ted Hardie From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: LTRU Working Group Subject: [Ltru] LAST CALL REQUESTED X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 Ted, I herewith would like to ask you to start the IETF Last Call for draft-ietf-ltru-matching-14. As you can see from the shepherding document that I sent earlier, this draft has successfully passed a WG last call with only minor editorial changes, and in my and Randy's assessment as co-chairs is ready for further processing and approval by the IESG and publication as an RFC. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru