From ltru-bounces@ietf.org Tue Aug 01 11:00:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vjJ-00007N-4w; Tue, 01 Aug 2006 11:00:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7vjH-00007H-VN for ltru@ietf.org; Tue, 01 Aug 2006 11:00:19 -0400 Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7vjG-00008T-IC for ltru@ietf.org; Tue, 01 Aug 2006 11:00:19 -0400 Received: from kotus.fi (pc094.kotus.fi [193.166.18.94]) by suomi.kotus.fi (8.12.10+Sun/8.12.10) with ESMTP id k71ExliT003993; Tue, 1 Aug 2006 17:59:48 +0300 (EEST) Message-ID: <44CF6C61.2040805@kotus.fi> Date: Tue, 01 Aug 2006 17:59:45 +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: John Cowan Subject: Re: [Ltru] ISO CD 639-6 (was: Re: Language and script encoding standards) References: <001901c6b208$1709f990$040aa8c0@DGBP7M81> <20060728055347.GA30165@ccil.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Doug Ewell , ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I fully agree on this. Erkki I. Kolehmainen John Cowan wrote: > Doug Ewell scripsit: > >>I fully agree that the appropriate question to discuss right now is >>whether the new charter should *allow* discussions about the pros and >>cons of adding ISO 639-6-based subtags, *when the time comes to have >>those discussions*. We need not, and indeed should not, conduct those >>discussions now. >> > > Just so. And I say that the charter should allow such discussions, > because the relevance (as distinct from the desirability) of > ISO 639-6 is beyond question. > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 01 16:37:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80zT-0006DR-6d; Tue, 01 Aug 2006 16:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G80zS-0006DL-7m for ltru@ietf.org; Tue, 01 Aug 2006 16:37:22 -0400 Received: from bortzmeyer.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G80zP-0004JQ-Vm for ltru@ietf.org; Tue, 01 Aug 2006 16:37:22 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 344EA240814; Tue, 1 Aug 2006 22:37:09 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id E2A5513204; Tue, 1 Aug 2006 22:33:51 +0200 (CEST) Date: Tue, 1 Aug 2006 22:33:51 +0200 From: Stephane Bortzmeyer To: ltru@ietf.org Message-ID: <20060801203351.GA8854@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Ltru] Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I just wrote a non-validating parser for language tags and I'm looking for test data. I want to test bizarre tags to see if the parser does classify them properly. I'm specially interested in badly-formed tags: the I-D contains mostly well-formed tags. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 01 17:06:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G81RR-0005ay-UI; Tue, 01 Aug 2006 17:06:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G81RQ-0005UO-1U for ltru@ietf.org; Tue, 01 Aug 2006 17:06:16 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G81RN-0007ip-MX for ltru@ietf.org; Tue, 01 Aug 2006 17:06:16 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k71L62Zh065744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Aug 2006 14:06:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=rEHcx20jhrM6lhxBG25efIncG/Ym2ozTFurVB/H7hYxwVmX3tseQ6XL8Xs3Oo6s6 Message-ID: <44CFC23A.2000703@yahoo-inc.com> Date: Tue, 01 Aug 2006 14:06:02 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [Ltru] Test suite for language tags? References: <20060801203351.GA8854@sources.org> In-Reply-To: <20060801203351.GA8854@sources.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rsmtp1.corp.yahoo.com id k71L62Zh065744 X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > I just wrote a non-validating parser for language tags and I'm looking > for test data. I want to test bizarre tags to see if the parser does > classify them properly. Good for you! > I'm specially interested in badly-formed tags: the I-D contains mostly > well-formed tags. Your best bet is probably to generate subtag sequences based on the=20 ABNF. Some particular problem cases to check would be: - singletons in the first position (except for 'x' and the grandfathered=20 list) - overlong subtags (longer than 8 characters) - more than three extlangs - misplaced extlang (3ALPHA in the third or later position following any=20 of these: 4ALPHA, 2ALPHA, 3DIGIT, 5*8alphanum, DIGIT 3alpha)[note: stop=20 at singleton] - misplaced script (4ALPHA following any of these: 2ALPHA, 3DIGIT,=20 5*8alphanum, DIGIT 3alphanum)[note: stop at singleton] - misplaced variant (five or more characters, or four or more starting=20 with a digit; either occurring before an extlang/script/region is an erro= r). - non-x singleton followed immediately by a singleton (including 'x') - missing subtag ("--") - a dangling hyphen ("foo-bar-baz-") or initial hyphen ("-foo-bar-baz") - digits in the primary (first) subtag - repeated singleton (note case insensitivity) Thus, these are all errors: "a-foo" "abcdefghi-012345678" "ab-abc-abc-abc-abc" "ab-abcd-abc" "ab-ab-abc" "ab-123-abc" "ab-abcde-abc" "ab-1abc-abc" "ab-ab-abcd" "ab-123-abcd" "ab-abcde-abcd" "ab-1abc-abcd" "ab-a-b" "ab-a-x" "ab--ab" "ab-abc-" "-ab-abc" "ab-a-abc-a-abc" These are not errors: "ab-x-abc-x-abc" // anything goes after x "ab-x-abc-a-a" // ditto "i-default" // grandfathered Hope that helps, Addison Addison Phillips Globalization Architect =E2=88=92 Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 01 17:31:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G81pQ-0002a3-B2; Tue, 01 Aug 2006 17:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G81pP-0002Zy-Lm for ltru@ietf.org; Tue, 01 Aug 2006 17:31:03 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G81pP-0002Wm-A4 for ltru@ietf.org; Tue, 01 Aug 2006 17:31:03 -0400 Received: by py-out-1112.google.com with SMTP id t32so1350218pyc for ; Tue, 01 Aug 2006 14:30:58 -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=tcR7TZp1Dw/d+tnjyawuOcvgzFgMpfnocfu7i3th1zUS2xtIfTu04OBerTjHvVN5mx2Z9f81QZNHrtiWCmRZrdLUczL2MExjlVi4MDIc7pdXCAoDcA2RZ/UFAGDYjPT7jXY0Uopzlk0Zbh/DpYu8mj6gldfjN85SWWzO6iO8q60= Received: by 10.35.99.5 with SMTP id b5mr195058pym; Tue, 01 Aug 2006 14:30:57 -0700 (PDT) Received: by 10.35.67.20 with HTTP; Tue, 1 Aug 2006 14:30:57 -0700 (PDT) Message-ID: <30b660a20608011430i15ddee97p702adbf55e72b9d4@mail.gmail.com> Date: Tue, 1 Aug 2006 14:30:57 -0700 From: "Mark Davis" To: "Addison Phillips" Subject: Re: [Ltru] Test suite for language tags? In-Reply-To: <44CFC23A.2000703@yahoo-inc.com> MIME-Version: 1.0 References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> X-Google-Sender-Auth: fdb74ed6cb2b456e X-Spam-Score: 0.5 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1314520633==" Errors-To: ltru-bounces@ietf.org --===============1314520633== Content-Type: multipart/alternative; boundary="----=_Part_89931_5016162.1154467857769" ------=_Part_89931_5016162.1154467857769 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline V2hhdCBtYXkgYmUgdXNlZnVsIGlzIHRoYXQgSUNVIGhhcyBhIHRlc3Qgc3RyaW5nIGdlbmVyYXRv ciAoQk5GKSB0aGF0CmdlbmVyYXRlcyBzdHJpbmdzIHRoYXQgbWF0Y2ggYSBzcGVjaWZpZWQgQk5G IHN5bnRheC4gSXQgYXVnbWVudHMgdGhlIHJlZ3VsYXIKc3ludGF4IHdpdGggcGVyY2VudCB2YWx1 ZXMgdGhhdCBpbmRpY2F0ZSByZWxhdGl2ZSB3ZWlnaHRzLiBUaGF0IGlzLCBpZiB5b3UKaGF2ZQoK eCA9IChhIHwgYiB8IGMpCgppbiB0aGUgQk5GLCB5b3UgY2FuIG1ha2UgaXQKCnggPSAoYSAyNSUg fCBiIDQ1JSB8IGMgMzAlKQoKc28gdGhhdCBpdCBnZW5lcmF0ZXMgdGhvc2UgYWx0ZXJuYXRpdmVz IHdpdGggdGhvc2UgZnJlcXVlbmNpZXMuCgpJdCBpcyBhbiBpbnRlcm5hbCB0ZXN0aW5nIGNsYXNz LCBhbmQgZG9lc24ndCBoYXZlIG11Y2ggZG9jdW1lbnRhdGlvbiwgYnV0IEkKdGhvdWdodCBJJ2Qg bWVudGlvbiBpdCBpbiBjYXNlIHlvdSdkIGZpbmQgaXQgdXNlZnVsLgoKTWFyawoKT24gOC8xLzA2 LCBBZGRpc29uIFBoaWxsaXBzIDxhZGRpc29uQHlhaG9vLWluYy5jb20+IHdyb3RlOgo+Cj4gPiBJ IGp1c3Qgd3JvdGUgYSBub24tdmFsaWRhdGluZyBwYXJzZXIgZm9yIGxhbmd1YWdlIHRhZ3MgYW5k IEknbSBsb29raW5nCj4gPiBmb3IgdGVzdCBkYXRhLiBJIHdhbnQgdG8gdGVzdCBiaXphcnJlIHRh Z3MgdG8gc2VlIGlmIHRoZSBwYXJzZXIgZG9lcwo+ID4gY2xhc3NpZnkgdGhlbSBwcm9wZXJseS4K Pgo+IEdvb2QgZm9yIHlvdSEKPgo+ID4gSSdtIHNwZWNpYWxseSBpbnRlcmVzdGVkIGluIGJhZGx5 LWZvcm1lZCB0YWdzOiB0aGUgSS1EIGNvbnRhaW5zIG1vc3RseQo+ID4gd2VsbC1mb3JtZWQgdGFn cy4KPgo+IFlvdXIgYmVzdCBiZXQgaXMgcHJvYmFibHkgdG8gZ2VuZXJhdGUgc3VidGFnIHNlcXVl bmNlcyBiYXNlZCBvbiB0aGUKPiBBQk5GLiBTb21lIHBhcnRpY3VsYXIgcHJvYmxlbSBjYXNlcyB0 byBjaGVjayB3b3VsZCBiZToKPgo+IC0gc2luZ2xldG9ucyBpbiB0aGUgZmlyc3QgcG9zaXRpb24g KGV4Y2VwdCBmb3IgJ3gnIGFuZCB0aGUgZ3JhbmRmYXRoZXJlZAo+IGxpc3QpCj4gLSBvdmVybG9u ZyBzdWJ0YWdzIChsb25nZXIgdGhhbiA4IGNoYXJhY3RlcnMpCj4gLSBtb3JlIHRoYW4gdGhyZWUg ZXh0bGFuZ3MKPiAtIG1pc3BsYWNlZCBleHRsYW5nICgzQUxQSEEgaW4gdGhlIHRoaXJkIG9yIGxh dGVyIHBvc2l0aW9uIGZvbGxvd2luZyBhbnkKPiBvZiB0aGVzZTogNEFMUEhBLCAyQUxQSEEsIDNE SUdJVCwgNSo4YWxwaGFudW0sIERJR0lUIDNhbHBoYSlbbm90ZTogc3RvcAo+IGF0IHNpbmdsZXRv bl0KPiAtIG1pc3BsYWNlZCBzY3JpcHQgKDRBTFBIQSBmb2xsb3dpbmcgYW55IG9mIHRoZXNlOiAy QUxQSEEsIDNESUdJVCwKPiA1KjhhbHBoYW51bSwgRElHSVQgM2FscGhhbnVtKVtub3RlOiBzdG9w IGF0IHNpbmdsZXRvbl0KPiAtIG1pc3BsYWNlZCB2YXJpYW50IChmaXZlIG9yIG1vcmUgY2hhcmFj dGVycywgb3IgZm91ciBvciBtb3JlIHN0YXJ0aW5nCj4gd2l0aCBhIGRpZ2l0OyBlaXRoZXIgb2Nj dXJyaW5nIGJlZm9yZSBhbiBleHRsYW5nL3NjcmlwdC9yZWdpb24gaXMgYW4KPiBlcnJvcikuCj4g LSBub24teCBzaW5nbGV0b24gZm9sbG93ZWQgaW1tZWRpYXRlbHkgYnkgYSBzaW5nbGV0b24gKGlu Y2x1ZGluZyAneCcpCj4gLSBtaXNzaW5nIHN1YnRhZyAoIi0tIikKPiAtIGEgZGFuZ2xpbmcgaHlw aGVuICgiZm9vLWJhci1iYXotIikgb3IgaW5pdGlhbCBoeXBoZW4gKCItZm9vLWJhci1iYXoiKQo+ IC0gZGlnaXRzIGluIHRoZSBwcmltYXJ5IChmaXJzdCkgc3VidGFnCj4gLSByZXBlYXRlZCBzaW5n bGV0b24gKG5vdGUgY2FzZSBpbnNlbnNpdGl2aXR5KQo+Cj4gVGh1cywgdGhlc2UgYXJlIGFsbCBl cnJvcnM6Cj4KPiAiYS1mb28iCj4gImFiY2RlZmdoaS0wMTIzNDU2NzgiCj4gImFiLWFiYy1hYmMt YWJjLWFiYyIKPiAiYWItYWJjZC1hYmMiCj4gImFiLWFiLWFiYyIKPiAiYWItMTIzLWFiYyIKPiAi YWItYWJjZGUtYWJjIgo+ICJhYi0xYWJjLWFiYyIKPiAiYWItYWItYWJjZCIKPiAiYWItMTIzLWFi Y2QiCj4gImFiLWFiY2RlLWFiY2QiCj4gImFiLTFhYmMtYWJjZCIKPiAiYWItYS1iIgo+ICJhYi1h LXgiCj4gImFiLS1hYiIKPiAiYWItYWJjLSIKPiAiLWFiLWFiYyIKPiAiYWItYS1hYmMtYS1hYmMi Cj4KPiBUaGVzZSBhcmUgbm90IGVycm9yczoKPgo+ICJhYi14LWFiYy14LWFiYyIgLy8gYW55dGhp bmcgZ29lcyBhZnRlciB4Cj4gImFiLXgtYWJjLWEtYSIgICAvLyBkaXR0bwo+ICJpLWRlZmF1bHQi ICAgICAgLy8gZ3JhbmRmYXRoZXJlZAo+Cj4gSG9wZSB0aGF0IGhlbHBzLAo+Cj4gQWRkaXNvbgo+ Cj4gQWRkaXNvbiBQaGlsbGlwcwo+IEdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IOKIkiBZYWhvbyEg SW5jLgo+Cj4gSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgYW4gYXJjaGl0ZWN0dXJlLgo+IEl0IGlz IG5vdCBhIGZlYXR1cmUuCj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwo+IEx0cnUgbWFpbGluZyBsaXN0Cj4gTHRydUBpZXRmLm9yZwo+IGh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUKPgo= ------=_Part_89931_5016162.1154467857769 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V2hhdCBtYXkgYmUgdXNlZnVsIGlzIHRoYXQgSUNVIGhhcyBhIHRlc3Qgc3RyaW5nIGdlbmVyYXRv ciAoQk5GKSB0aGF0IGdlbmVyYXRlcyBzdHJpbmdzIHRoYXQgbWF0Y2ggYSBzcGVjaWZpZWQgQk5G IHN5bnRheC4gSXQgYXVnbWVudHMgdGhlIHJlZ3VsYXIgc3ludGF4IHdpdGggcGVyY2VudCB2YWx1 ZXMgdGhhdCBpbmRpY2F0ZSByZWxhdGl2ZSB3ZWlnaHRzLiBUaGF0IGlzLCBpZiB5b3UgaGF2ZQo8 YnI+PGJyPnggPSAoYSB8IGIgfCBjKTxicj48YnI+aW4gdGhlIEJORiwgeW91IGNhbiBtYWtlIGl0 PGJyPjxicj54ID0gKGEgMjUlIHwgYiA0NSUgfCBjIDMwJSk8YnI+PGJyPnNvIHRoYXQgaXQgZ2Vu ZXJhdGVzIHRob3NlIGFsdGVybmF0aXZlcyB3aXRoIHRob3NlIGZyZXF1ZW5jaWVzLjxicj48YnI+ SXQgaXMgYW4gaW50ZXJuYWwgdGVzdGluZyBjbGFzcywgYW5kIGRvZXNuJ3QgaGF2ZSBtdWNoIGRv Y3VtZW50YXRpb24sIGJ1dCBJIHRob3VnaHQgSSdkIG1lbnRpb24gaXQgaW4gY2FzZSB5b3UnZCBm aW5kIGl0IHVzZWZ1bC4KPGJyPjxicj5NYXJrPGJyPjxicj48ZGl2PjxzcGFuIGNsYXNzPSJnbWFp bF9xdW90ZSI+T24gOC8xLzA2LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+QWRkaXNvbiBQ aGlsbGlwczwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzphZGRpc29uQHlhaG9vLWluYy5jb20iPmFk ZGlzb25AeWFob28taW5jLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48YmxvY2txdW90ZSBjbGFz cz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIw NCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4K ICZndDsgSSBqdXN0IHdyb3RlIGEgbm9uLXZhbGlkYXRpbmcgcGFyc2VyIGZvciBsYW5ndWFnZSB0 YWdzIGFuZCBJJ20gbG9va2luZzxicj4gJmd0OyBmb3IgdGVzdCBkYXRhLiBJIHdhbnQgdG8gdGVz dCBiaXphcnJlIHRhZ3MgdG8gc2VlIGlmIHRoZSBwYXJzZXIgZG9lczxicj4gJmd0OyBjbGFzc2lm eSB0aGVtIHByb3Blcmx5Ljxicj48YnI+R29vZCBmb3IgeW91ITxicj48YnI+ICZndDsgSSdtIHNw ZWNpYWxseSBpbnRlcmVzdGVkIGluIGJhZGx5LWZvcm1lZCB0YWdzOiB0aGUgSS1EIGNvbnRhaW5z IG1vc3RseQo8YnI+ICZndDsgd2VsbC1mb3JtZWQgdGFncy48YnI+PGJyPllvdXIgYmVzdCBiZXQg aXMgcHJvYmFibHkgdG8gZ2VuZXJhdGUgc3VidGFnIHNlcXVlbmNlcyBiYXNlZCBvbiB0aGU8YnI+ QUJORi4gU29tZSBwYXJ0aWN1bGFyIHByb2JsZW0gY2FzZXMgdG8gY2hlY2sgd291bGQgYmU6PGJy Pjxicj4tIHNpbmdsZXRvbnMgaW4gdGhlIGZpcnN0IHBvc2l0aW9uIChleGNlcHQgZm9yICd4JyBh bmQgdGhlIGdyYW5kZmF0aGVyZWQKPGJyPmxpc3QpPGJyPi0gb3Zlcmxvbmcgc3VidGFncyAobG9u Z2VyIHRoYW4gOCBjaGFyYWN0ZXJzKTxicj4tIG1vcmUgdGhhbiB0aHJlZSBleHRsYW5nczxicj4t IG1pc3BsYWNlZCBleHRsYW5nICgzQUxQSEEgaW4gdGhlIHRoaXJkIG9yIGxhdGVyIHBvc2l0aW9u IGZvbGxvd2luZyBhbnk8YnI+b2YgdGhlc2U6IDRBTFBIQSwgMkFMUEhBLCAzRElHSVQsIDUqOGFs cGhhbnVtLCBESUdJVCAzYWxwaGEpW25vdGU6IHN0b3AKPGJyPmF0IHNpbmdsZXRvbl08YnI+LSBt aXNwbGFjZWQgc2NyaXB0ICg0QUxQSEEgZm9sbG93aW5nIGFueSBvZiB0aGVzZTogMkFMUEhBLCAz RElHSVQsPGJyPjUqOGFscGhhbnVtLCBESUdJVCAzYWxwaGFudW0pW25vdGU6IHN0b3AgYXQgc2lu Z2xldG9uXTxicj4tIG1pc3BsYWNlZCB2YXJpYW50IChmaXZlIG9yIG1vcmUgY2hhcmFjdGVycywg b3IgZm91ciBvciBtb3JlIHN0YXJ0aW5nPGJyPgp3aXRoIGEgZGlnaXQ7IGVpdGhlciBvY2N1cnJp bmcgYmVmb3JlIGFuIGV4dGxhbmcvc2NyaXB0L3JlZ2lvbiBpcyBhbiBlcnJvcikuPGJyPi0gbm9u LXggc2luZ2xldG9uIGZvbGxvd2VkIGltbWVkaWF0ZWx5IGJ5IGEgc2luZ2xldG9uIChpbmNsdWRp bmcgJ3gnKTxicj4tIG1pc3Npbmcgc3VidGFnICgmcXVvdDstLSZxdW90Oyk8YnI+LSBhIGRhbmds aW5nIGh5cGhlbiAoJnF1b3Q7Zm9vLWJhci1iYXotJnF1b3Q7KSBvciBpbml0aWFsIGh5cGhlbiAo JnF1b3Q7LWZvby1iYXItYmF6JnF1b3Q7KQo8YnI+LSBkaWdpdHMgaW4gdGhlIHByaW1hcnkgKGZp cnN0KSBzdWJ0YWc8YnI+LSByZXBlYXRlZCBzaW5nbGV0b24gKG5vdGUgY2FzZSBpbnNlbnNpdGl2 aXR5KTxicj48YnI+VGh1cywgdGhlc2UgYXJlIGFsbCBlcnJvcnM6PGJyPjxicj4mcXVvdDthLWZv byZxdW90Ozxicj4mcXVvdDthYmNkZWZnaGktMDEyMzQ1Njc4JnF1b3Q7PGJyPiZxdW90O2FiLWFi Yy1hYmMtYWJjLWFiYyZxdW90Owo8YnI+JnF1b3Q7YWItYWJjZC1hYmMmcXVvdDs8YnI+JnF1b3Q7 YWItYWItYWJjJnF1b3Q7PGJyPiZxdW90O2FiLTEyMy1hYmMmcXVvdDs8YnI+JnF1b3Q7YWItYWJj ZGUtYWJjJnF1b3Q7PGJyPiZxdW90O2FiLTFhYmMtYWJjJnF1b3Q7PGJyPiZxdW90O2FiLWFiLWFi Y2QmcXVvdDs8YnI+JnF1b3Q7YWItMTIzLWFiY2QmcXVvdDs8YnI+JnF1b3Q7YWItYWJjZGUtYWJj ZCZxdW90Ozxicj4mcXVvdDthYi0xYWJjLWFiY2QmcXVvdDsKPGJyPiZxdW90O2FiLWEtYiZxdW90 Ozxicj4mcXVvdDthYi1hLXgmcXVvdDs8YnI+JnF1b3Q7YWItLWFiJnF1b3Q7PGJyPiZxdW90O2Fi LWFiYy0mcXVvdDs8YnI+JnF1b3Q7LWFiLWFiYyZxdW90Ozxicj4mcXVvdDthYi1hLWFiYy1hLWFi YyZxdW90Ozxicj48YnI+VGhlc2UgYXJlIG5vdCBlcnJvcnM6PGJyPjxicj4mcXVvdDthYi14LWFi Yy14LWFiYyZxdW90OyAvLyBhbnl0aGluZyBnb2VzIGFmdGVyIHgKPGJyPiZxdW90O2FiLXgtYWJj LWEtYSZxdW90OyZuYnNwOyZuYnNwOyAvLyBkaXR0bzxicj4mcXVvdDtpLWRlZmF1bHQmcXVvdDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsvLyBncmFuZGZhdGhlcmVkPGJyPjxi cj5Ib3BlIHRoYXQgaGVscHMsPGJyPjxicj5BZGRpc29uPGJyPjxicj5BZGRpc29uIFBoaWxsaXBz PGJyPkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0IOKIkiBZYWhvbyEgSW5jLjxicj48YnI+SW50ZXJu YXRpb25hbGl6YXRpb24gaXMgYW4gYXJjaGl0ZWN0dXJlLgo8YnI+SXQgaXMgbm90IGEgZmVhdHVy ZS48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPkx0cnUgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpMdHJ1QGlldGYub3JnIj5M dHJ1QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9sdHJ1Ij5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s dHJ1CjwvYT48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj4K ------=_Part_89931_5016162.1154467857769-- --===============1314520633== 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 --===============1314520633==-- From ltru-bounces@ietf.org Wed Aug 02 03:28:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8B9v-0003sc-PI; Wed, 02 Aug 2006 03:28:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8B9v-0003sX-Bg for ltru@ietf.org; Wed, 02 Aug 2006 03:28:51 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8B9u-0006mz-39 for ltru@ietf.org; Wed, 02 Aug 2006 03:28:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 82EA526C19D; Wed, 2 Aug 2006 09:28:49 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 9E98B26C11F; Wed, 2 Aug 2006 09:28:48 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 93044A1DB2C; Wed, 2 Aug 2006 09:28:48 +0200 (CEST) Date: Wed, 2 Aug 2006 09:28:48 +0200 From: Stephane Bortzmeyer To: Mark Davis Message-ID: <20060802072848.GB17404@nic.fr> References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <30b660a20608011430i15ddee97p702adbf55e72b9d4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20608011430i15ddee97p702adbf55e72b9d4@mail.gmail.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ltru@ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Aug 01, 2006 at 02:30:57PM -0700, Mark Davis wrote a message of 117 lines which said: > What may be useful is that ICU has a test string generator (BNF) > that generates strings that match a specified BNF syntax. Interesting. An ABNF2tests that takes RFC 4234 as input and produces Junit / PyUnit / Hunit / whatever would certainly be an useful tool for IETF. I do not use Java but I'll have a look. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 02 08:55:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8GG5-0005Xv-D7; Wed, 02 Aug 2006 08:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8GG4-0005Ul-9B for ltru@ietf.org; Wed, 02 Aug 2006 08:55:32 -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 1G8BCE-0006st-Mu for ltru@ietf.org; Wed, 02 Aug 2006 03:31:14 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8B8R-0001S9-IK for ltru@ietf.org; Wed, 02 Aug 2006 03:27:22 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 4FB7C26C1D8; Wed, 2 Aug 2006 09:27:10 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 7F77826C0E8; Wed, 2 Aug 2006 09:27:09 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 720C7A1DB2C; Wed, 2 Aug 2006 09:27:09 +0200 (CEST) Date: Wed, 2 Aug 2006 09:27:09 +0200 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20060802072709.GA17404@nic.fr> References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44CFC23A.2000703@yahoo-inc.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: -2.4 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Aug 01, 2006 at 02:06:02PM -0700, Addison Phillips wrote a message of 65 lines which said: > Some particular problem cases to check would be: Many thanks for the test cases, I discovered a bug in the parser with them. Now, it works: Cases: 58 Tried: 58 Errors: 0 Failures: 0 :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 02 09:37:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Guf-0005v6-LE; Wed, 02 Aug 2006 09:37:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8Gue-0005v0-Fl for ltru@ietf.org; Wed, 02 Aug 2006 09:37:28 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8Guc-0007Zj-6r for ltru@ietf.org; Wed, 02 Aug 2006 09:37:28 -0400 Received: by py-out-1112.google.com with SMTP id t32so1722191pyc for ; Wed, 02 Aug 2006 06:37:24 -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=O/9RGy7r/kYRWyA0uBlkvPCic/mjakTjqr8eWgUpowNRe1WOTTxwTJBbZ/oHFVvIserIWhvJKYMOdx+gpmjJUwM5Dc2+dlcVgpxf+2h1cGDDv4Hn0Ec904MxNdQpRhov0Xg7VjZW3xSIeET3VX3K2Tsp+1EGtH9o8SdyAUQ3ECY= Received: by 10.35.51.19 with SMTP id d19mr1444863pyk; Wed, 02 Aug 2006 06:37:23 -0700 (PDT) Received: by 10.35.67.20 with HTTP; Wed, 2 Aug 2006 06:37:23 -0700 (PDT) Message-ID: <30b660a20608020637v11048b3alcf34616593826167@mail.gmail.com> Date: Wed, 2 Aug 2006 06:37:23 -0700 From: "Mark Davis" To: "Stephane Bortzmeyer" Subject: Re: [Ltru] Re: Test suite for language tags? In-Reply-To: <20060802072709.GA17404@nic.fr> MIME-Version: 1.0 References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> X-Google-Sender-Auth: 5fe08f65b13a376c X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1790814387==" Errors-To: ltru-bounces@ietf.org --===============1790814387== Content-Type: multipart/alternative; boundary="----=_Part_8451_31057961.1154525843416" ------=_Part_8451_31057961.1154525843416 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm sorry I gave the wrong impression. It doesn't use RFC 4234 syntax; it uses Perl-style syntax, eg x = ( a | b | c ) d* ( e | f )+ .... instead of x=("a"/"b"/"c") *d *1("e"/"f") It would not take a lot of work to have it also take the older syntax as well, but it doesn't use it out of the box. Mark On 8/2/06, Stephane Bortzmeyer wrote: > > On Tue, Aug 01, 2006 at 02:06:02PM -0700, > Addison Phillips wrote > a message of 65 lines which said: > > > Some particular problem cases to check would be: > > Many thanks for the test cases, I discovered a bug in the parser with > them. Now, it works: > > Cases: 58 Tried: 58 Errors: 0 Failures: 0 > > :-) > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_8451_31057961.1154525843416 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm sorry I gave the wrong impression. It doesn't use RFC 4234 syntax; it uses Perl-style syntax, eg

x = ( a | b | c ) d* ( e | f )+ ....
instead of
x=("a"/"b"/"c") *d *1("e"/"f")

It would not take a lot of work to have it also take the older syntax as well, but it doesn't use it out of the box.

Mark

On 8/2/06, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Aug 01, 2006 at 02:06:02PM -0700,
Addison Phillips <addison@yahoo-inc.com> wrote
a message of 65 lines which said:

> Some particular problem cases to check would be:

Many thanks for the test cases, I discovered a bug in the parser with
them. Now, it works:

Cases: 58  Tried: 58  Errors: 0  Failures: 0

:-)


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

------=_Part_8451_31057961.1154525843416-- --===============1790814387== 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 --===============1790814387==-- From ltru-bounces@ietf.org Wed Aug 02 09:47:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8H4g-00035m-9P; Wed, 02 Aug 2006 09:47:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8H4e-00035g-HJ for ltru@ietf.org; Wed, 02 Aug 2006 09:47:48 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8H4d-0001Z6-7F for ltru@ietf.org; Wed, 02 Aug 2006 09:47:48 -0400 Received: by py-out-1112.google.com with SMTP id t32so1726343pyc for ; Wed, 02 Aug 2006 06:47:40 -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=fbGNS/WdyvsYL+hLVcvihsgEfauYYjU0VR71uymWn03klnaYKSF4Ek1LMfPopHWEKPrMKUgWIErUbtz/yGzkaovEZCPJIDOHShhMhAVkSdKi1KyAyVO3GJpYtDoz94ze3C0n0P3ukITKc5Z072X4Yl5ofRlduqjQrRiVzhKsaas= Received: by 10.35.111.14 with SMTP id o14mr1443755pym; Wed, 02 Aug 2006 06:47:40 -0700 (PDT) Received: by 10.35.67.20 with HTTP; Wed, 2 Aug 2006 06:47:40 -0700 (PDT) Message-ID: <30b660a20608020647u2c5522bctc86e46a08035c296@mail.gmail.com> Date: Wed, 2 Aug 2006 06:47:40 -0700 From: "Mark Davis" To: "Stephane Bortzmeyer" Subject: Re: [Ltru] Re: Test suite for language tags? In-Reply-To: <30b660a20608020637v11048b3alcf34616593826167@mail.gmail.com> MIME-Version: 1.0 References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> <30b660a20608020637v11048b3alcf34616593826167@mail.gmail.com> X-Google-Sender-Auth: 1a824f33f1c465b5 X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0652265119==" Errors-To: ltru-bounces@ietf.org --===============0652265119== Content-Type: multipart/alternative; boundary="----=_Part_8759_32449720.1154526460100" ------=_Part_8759_32449720.1154526460100 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline P.S. It was also ported to C++ (although with some limitations) in wbnf.* Mark On 8/2/06, Mark Davis wrote: > > I'm sorry I gave the wrong impression. It doesn't use RFC 4234 syntax; it > uses Perl-style syntax, eg > > x = ( a | b | c ) d* ( e | f )+ .... > instead of > x=("a"/"b"/"c") *d *1("e"/"f") > > It would not take a lot of work to have it also take the older syntax as > well, but it doesn't use it out of the box. > > Mark > > > On 8/2/06, Stephane Bortzmeyer wrote: > > > > On Tue, Aug 01, 2006 at 02:06:02PM -0700, > > Addison Phillips wrote > > a message of 65 lines which said: > > > > > Some particular problem cases to check would be: > > > > Many thanks for the test cases, I discovered a bug in the parser with > > them. Now, it works: > > > > Cases: 58 Tried: 58 Errors: 0 Failures: 0 > > > > :-) > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > ------=_Part_8759_32449720.1154526460100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline P.S. It was also ported to C++ (although with some limitations) in wbnf.*

Mark

On 8/2/06, Mark Davis < mark.davis@icu-project.org> wrote:
I'm sorry I gave the wrong impression. It doesn't use RFC 4234 syntax; it uses Perl-style syntax, eg

x = ( a | b | c ) d* ( e | f )+ ....
instead of
x=("a"/"b"/"c") *d *1("e"/"f")

It would not take a lot of work to have it also take the older syntax as well, but it doesn't use it out of the box.

Mark


On 8/2/06, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Aug 01, 2006 at 02:06:02PM -0700,
Addison Phillips <addison@yahoo-inc.com> wrote
a message of 65 lines which said:

> Some particular problem cases to check would be:

Many thanks for the test cases, I discovered a bug in the parser with
them. Now, it works:

Cases: 58  Tried: 58  Errors: 0  Failures: 0

:-)


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


------=_Part_8759_32449720.1154526460100-- --===============0652265119== 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 --===============0652265119==-- From ltru-bounces@ietf.org Thu Aug 03 11:48:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8fR6-0006rY-Tn; Thu, 03 Aug 2006 11:48:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8fR5-0006nF-Jy for ltru@ietf.org; Thu, 03 Aug 2006 11:48:35 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8fR4-0005hY-9p for ltru@ietf.org; Thu, 03 Aug 2006 11:48:35 -0400 Received: from [10.72.76.180] (snvvpn2-10-72-76-c180.corp.yahoo.com [10.72.76.180]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k73FmTQu059083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Aug 2006 08:48:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Ds6+hhVqXLGF+jEdiFul45uNvh0smzp7n9jgpV2OZiOrWTndBQIrsCBXhGYYtwhJ Message-ID: <44D21ACD.4040707@yahoo-inc.com> Date: Thu, 03 Aug 2006 08:48:29 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> In-Reply-To: <20060802072709.GA17404@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ltru@ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Glad it helped. I could probably have saved time writing that message if I'd just sent my JUnits ;-). Glad to see that others are getting their parsers going. Just curious: will you also be implementing a validating parser? Addison Stephane Bortzmeyer wrote: > On Tue, Aug 01, 2006 at 02:06:02PM -0700, > Addison Phillips wrote > a message of 65 lines which said: > >> Some particular problem cases to check would be: > > Many thanks for the test cases, I discovered a bug in the parser with > them. Now, it works: > > Cases: 58 Tried: 58 Errors: 0 Failures: 0 > > :-) > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 02:02:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8slm-0005Hx-Fg; Fri, 04 Aug 2006 02:02:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8slk-0005FZ-Od for ltru@ietf.org; Fri, 04 Aug 2006 02:02:48 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8slj-0006K8-EN for ltru@ietf.org; Fri, 04 Aug 2006 02:02:48 -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 <20060804060246.JGNK19730.mta13.adelphia.net@DGBP7M81> for ; Fri, 4 Aug 2006 02:02:46 -0400 Message-ID: <002a01c6b78b$999f7820$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 3 Aug 2006 23:02:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I could probably have saved time writing that message if I'd just sent > my JUnits ;-). Glad to see that others are getting their parsers > going. I'm glad that Stephaney is writing his own processor independently and asking others for guidance in prose, not reusing someone else's implementation. Code reuse is normally a good thing, but right now we have essentially a new spec, and bugs in someone's implementation might turn out to be, or might be interpreted as, problems with the spec. There are probably fewer than 5 independent RFC 3066bis processors on the planet; we need more. (BTW, yes, my validating processor did pass the Addison Test Suite.) -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 02:05:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8snu-0007ZF-2k; Fri, 04 Aug 2006 02:05:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8snt-0007ZA-Rp for ltru@ietf.org; Fri, 04 Aug 2006 02:05:01 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8sns-0006jK-Kt for ltru@ietf.org; Fri, 04 Aug 2006 02:05:01 -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 <20060804060459.KVUM12036.mta9.adelphia.net@DGBP7M81>; Fri, 4 Aug 2006 02:04:59 -0400 Message-ID: <003001c6b78b$e444a940$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 3 Aug 2006 23:04:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 wrote: > I'm glad that Stephaney is writing his own processor... Sorry about changing your name. That was the result of hitting "Y" in response to a question my spell-checker asked me. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 04:32:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8v6I-0004rO-DX; Fri, 04 Aug 2006 04:32:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8v6G-0004pk-9M for ltru@ietf.org; Fri, 04 Aug 2006 04:32:08 -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 1G8seY-0003im-2Q for ltru@ietf.org; Fri, 04 Aug 2006 01:55:22 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G8sat-0006WI-Mt for ltru@ietf.org; Fri, 04 Aug 2006 01:51:40 -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 <20060804055133.ZPVZ14422.mta11.adelphia.net@DGBP7M81> for ; Fri, 4 Aug 2006 01:51:33 -0400 Message-ID: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Test suite for language tags? Date: Thu, 3 Aug 2006 22:51:27 -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: -2.5 (--) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > Your best bet is probably to generate subtag sequences based on the > ABNF. Some particular problem cases to check would be: Just a few minor nits here. This is slightly more complex than meets the eye, unfortunately. > - singletons in the first position (except for 'x' and the > grandfathered list) Sadly, the existence of the grandfathered list means that all well-formed processors must also do a limited amount of validity checking. I don't question the importance of maintaining support for the grandfathered tags, but this is a side effect. > - misplaced extlang (3ALPHA in the third or later position following > any of these: 4ALPHA, 2ALPHA, 3DIGIT, 5*8alphanum, DIGIT 3alpha)[note: > stop at singleton] Repalce "following" by "immediately following." 2ALPHA followed by 3ALPHA followed by 3ALPHA is fine. "DIGIT 3alpha" here should be "DIGIT 3alphanum". > - misplaced script (4ALPHA following any of these: 2ALPHA, 3DIGIT, > 5*8alphanum, DIGIT 3alphanum)[note: stop at singleton] Needs another qualifier. 2ALPHA followed by 4ALPHA is fine: "zh-Hans". > - missing subtag ("--") > - a dangling hyphen ("foo-bar-baz-") or initial hyphen > ("-foo-bar-baz") The second is really just a special case of the first: a missing subtag at the end or beginning, respectively. One thing I found useful, when building my validator, was to parse out the subtags first and check them for validity afterward, so the hyphens never become part of the validity checking per se. > Thus, these are all errors: > > "a-foo" > "abcdefghi-012345678" > "ab-abc-abc-abc-abc" > "ab-abcd-abc" > "ab-ab-abc" Why pick on Abkhasian so much? :-) > "ab-x-abc-x-abc" // anything goes after x Not quite anything, of course: 1*("-" (1*8alphanum)) -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 05:24:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vvA-0007Zp-8X; Fri, 04 Aug 2006 05:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vv9-0007YZ-G5 for ltru@ietf.org; Fri, 04 Aug 2006 05:24:43 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8vv6-00029x-SO for ltru@ietf.org; Fri, 04 Aug 2006 05:24:43 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k749OaHh008013; Fri, 4 Aug 2006 18:24:36 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 046e_0bd93e5a_239b_11db_8cfa_0014221fa3c9; Fri, 04 Aug 2006 18:24:36 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k749OWEA027926; Fri, 4 Aug 2006 18:24:33 +0900 Message-Id: <6.0.0.20.2.20060804170806.0240c1b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 04 Aug 2006 17:09:13 +0900 To: "Mark Davis" From: Martin Duerst Subject: Re: [Ltru] Charter update proposal In-Reply-To: <30b660a20607280702i225b0785r401da213c80972c5@mail.gmail.co m> References: <6.0.0.20.2.20060726163255.05cb0cf0@localhost> <30b660a20607280702i225b0785r401da213c80972c5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 23:02 06/07/28, Mark Davis wrote: >Something along these lines looks good. A couple wording items: > >The working group may make adjustments to the registration process >and the form of the registry if this is deemed appropriate based >on ongoing registration and operational experience and such >adjustments are not expected to delay the progress of the work. >=> >The working group may make adjustments to the registration process >and the form of the registry if this is deemed appropriate based >on ongoing registration and operational experience. It may also clarify >some of the text. Such >adjustments are not expected to delay the progress of the work. I have taken this into account, but slightly reworded: >>>> The working group will clarify text where necessary. It may also make adjustments to the registration process and the form of the registry if this is deemed appropriate based on ongoing registration and operational experience. These adjustments and clarifications are not expected to delay the progress of the work. >>>> Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 05:24:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vvA-0007aD-C2; Fri, 04 Aug 2006 05:24:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vv9-0007Z9-Ip for ltru@ietf.org; Fri, 04 Aug 2006 05:24:43 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8vv6-00029z-SO for ltru@ietf.org; Fri, 04 Aug 2006 05:24:43 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k749OdCl008021; Fri, 4 Aug 2006 18:24:39 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 03d0_0d74db02_239b_11db_9e4f_0014221fa3c9; Fri, 04 Aug 2006 18:24:38 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k749OWEE027926; Fri, 4 Aug 2006 18:24:38 +0900 Message-Id: <6.0.0.20.2.20060804174746.07f62c90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 04 Aug 2006 18:00:29 +0900 To: "Addison Phillips" , "'LTRU Working Group'" From: Martin Duerst Subject: RE: [Ltru] Charter update proposal In-Reply-To: <000601c6b286$a34cd0c0$9fcd15ac@ds.corp.yahoo.com> References: <6.0.0.20.2.20060726163255.05cb0cf0@localhost> <000601c6b286$a34cd0c0$9fcd15ac@ds.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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 Hello Addison, At 05:44 06/07/29, Addison Phillips wrote: >Hello Martin, > >Thank you for doing this. Unless notes, I am "+1" to everything you said in >your message. > >Specific comments follow. same here. >Addison > >Addison Phillips >Internationalization Architect - Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. > >> -----Original Message----- >> From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] >> Sent: vendredi 28 juillet 2006 01:41 > > >> ISO 639-3, scheduled for approval towards the end of 2006, >> will make available around 6000 (??) more primary language codes >> and language variant codes. > >As noted by others, this sentence should say something else. However, I'm >convinced that the comments so far go in the wrong direction. In our jargon, >the term "codes" refers to codes in ISO 639, not to subtags. I would thus >propose we say: > >-- >ISO 639-3, scheduled for approval towards the end of 2006, will make >available around 7000 additional codes for identifying languages. I have decided that when speaking about ISO, I'm using their terminology (code elements), and when speaking about our stuff, I'm using our terminology. I hope this will come out reasonably well. >-- >> >> The working group will work on an update to the language subtag > >(Editorial) I would replace the phrase "work on" with "prepare" or "create". Done. >> registry procedures to allow the use of 3-letter codes from >> ISO 639-3 as primary subtags or variant subtags as appropriate. > >As noted by others, replace 'variant' with 'extended language'. Yes, my bad, done, mostly with text from Doug. >> The working group will also deliver means to update the current >> IANA language subtag registry with the newly available codes. > >I would change this to be slightly more expansive: > >-- >The working group will also deliver a means to update the current >IANA language subtag registry with the newly available codes, as well >as procedures for maintaining the registry as codes are assigned >or modified in the future. My understanding is that we already have the procedures for updating. Or do we miss something? >-- > >Or you might consider using a separate sentence, such as the one I proposed >yesterday: > >-- >The working group must decide how ISO 639-3 codes are entered into the >registry, what rules apply to associating a code with the language and/or =>extlang subtag types, and any additional rules or guidance on their adoption >and use. >-- I don't see what's substantially different here from the existing text: >>>> The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter codes from ISO 639-3 as primary subtags or extended language subtags as appropriate. >>>> In short, we have to update the procedures so that we can use IOS 639-3. I don't think that we need more details here. How codes are entered, what types they are given, and so on, should all be covered under Language Subtag Registry procedures. >> >> The working group may make adjustments to the registration process >> and the form of the registry if this is deemed appropriate based >> on ongoing registration and operational experience and such >> adjustments are not expected to delay the progress of the work. > >(Editorial) This is a bit of a run-on sentence. Please break it into two >setences between >'experience' and 'such'. I adopted a split from Mark, with some changes of my own. >I wouldn't oppose including some version of (Mark's version of) my ISO 639-6 >text here ;-). > >> >> Work on the drafts is planned to start before ISO 639-3 is fully >> approved and published. However, the WG will not finalize the drafts >> before ISO 639-3 is fully approved. > >I'm not sure that's correct. It would be more appropriate to say >"Publication of the draft(s) as an RFC will depend on final approval of ISO >639-3." There is ample space in the RFC Editor process for awaiting specific >external events (as we've already discovered). We might well finalize an >update to draft-registry quite quickly, but not the actual registry update >("draft-initial"). Peter said that he would have the approval by the third week of September. Do you think we'll be finished with our drafts before that? Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 05:24:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vvC-0007eT-FO; Fri, 04 Aug 2006 05:24:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vv9-0007Za-Vs for ltru@ietf.org; Fri, 04 Aug 2006 05:24:43 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8vv8-0002A8-Ae for ltru@ietf.org; Fri, 04 Aug 2006 05:24:43 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k749OaPG020170; Fri, 4 Aug 2006 18:24:36 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 0431_0be5a712_239b_11db_9833_0014221fa3c9; Fri, 04 Aug 2006 18:24:36 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k749OWEC027926; Fri, 4 Aug 2006 18:24:36 +0900 Message-Id: <6.0.0.20.2.20060804174507.02409230@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 04 Aug 2006 17:45:37 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Charter update proposal In-Reply-To: <002501c6b251$8355ef20$040aa8c0@DGBP7M81> References: <002501c6b251$8355ef20$040aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Doug, Many thanks for your text proposals, which I have taken up mostly without changes. Regards, Martin. At 23:24 06/07/28, Doug Ewell wrote: >Peter Constable wrote: > >> One small comment: 639-3 won't make any codes available that would get used as variant subtags. It will make available codes that we expect will get used as extlang subtags. > >Agreed. We will probably want to use "extended language" in the charter instead of the jargony "extlang" with which we are comfortable. > >> I'm guessing the number of additional codes that would get added is around 6,800 (I think there was approx 7200 total in the draft code table of which approx 400 are in 639-2). > >The current Registry has 488 primary language subtags. > >My preliminary mockup of an RFC 3066ter Registry includes 7,194 primary language subtags and 354 extlang subtags, for a total of 7,548, or an increase of 7,060 over the status quo. Note that this does not include any of the ISO 639-3 code elements for sign languages, which will have to be their own topic of discussion, though this may not need to be stated in the brief charter text. > >I also note that the words "tags" and "codes," mostly in the first paragraph, should be changed to "subtags" as appropriate. > >Suggested rewording of the first two paragraphs:: > >----- >The primary language subtags allowed by the current IANA Language Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same way as they were limited by RFC 3066. This covers approximately 500 possible language subtags. ISO 639-3, scheduled for approval towards the end of 2006, will make available around 7000 more primary language subtags and extended language subtags. > >The working group will work on an update to the Language Subtag Registry procedures to allow the use of 3-letter codes from ISO 639-3 as primary language subtags or extended language subtags as appropriate. The working group will also deliver means to update the current IANA Language Subtag Registry with the newly available subtags. >----- > >-- >Doug Ewell >Fullerton, California, USA >http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 05:24:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vvE-0007mI-Ir; Fri, 04 Aug 2006 05:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vvD-0007ga-0Q for ltru@ietf.org; Fri, 04 Aug 2006 05:24:47 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8vvB-0002AK-Ch for ltru@ietf.org; Fri, 04 Aug 2006 05:24:46 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k749Oig8020174 for ; Fri, 4 Aug 2006 18:24:44 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 048a_10a1233a_239b_11db_9348_0014221fa3c9; Fri, 04 Aug 2006 18:24:44 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k749OWEI027926 for ; Fri, 4 Aug 2006 18:24:44 +0900 Message-Id: <6.0.0.20.2.20060804144524.07f52660@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 04 Aug 2006 18:24:00 +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: e8a67952aa972b528dd04570d58ad8fe Subject: [Ltru] Charter update proposal (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 Dear LTRU WG, Below please find an updated proposal for our charter update (rechartering). Details of changes are discussed in responses to the commenters. The main change is the addition of a paragraph discussing signed languages, transliterations, transcriptions, and 639-6. I look forward to send our proposal for rechartering to Ted Hardie (Area Director) within the next few days. But in case you find any additional problems in the current draft charter, please tell me (and the WG). Regards, Martin. ------------------------------------------------------------- Description of the Working Group: The primary language subtags allowed by the current IANA Language Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same way as they were limited by RFC 3066. This covers approximately 500 possible language subtags. ISO 639-3, scheduled for approval towards the end of 2006, will make available around 7000 more code elements for identifying languages. The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. The working group will also deliver means to update the current IANA Language Subtag Registry with the newly available subtags. The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions. The working group will also consider how the draft work on ISO 639-6 may relate to the future development of language tags. The working group will clarify text where necessary. It may also make adjustments to the registration process and the form of the registry if this is deemed appropriate based on ongoing registration and operational experience. These adjustments and clarifications are not expected to delay the progress of the work. Work on the drafts is planned to start before ISO 639-3 is fully approved and published. However, the WG will not finalize the drafts before ISO 639-3 is fully approved. Goals and Milestones: September 2006 Submit first WG draft of registry procedure update September 2006 Submit first WG draft of registry data update January 2007 Submit registry procedure update draft for IETF Last Call January 2007 Submit registry data update draft for IETF Last Call #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 05:24:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vvJ-0007zO-M4; Fri, 04 Aug 2006 05:24:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8vvH-0007tR-Ra for ltru@ietf.org; Fri, 04 Aug 2006 05:24:51 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8vvG-0002AT-8e for ltru@ietf.org; Fri, 04 Aug 2006 05:24:51 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k749OiRg008027; Fri, 4 Aug 2006 18:24:44 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 0421_109436c0_239b_11db_8e69_0014221fa3c9; Fri, 04 Aug 2006 18:24:44 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k749OWEG027926; Fri, 4 Aug 2006 18:24:39 +0900 Message-Id: <6.0.0.20.2.20060804181356.09df37f0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 04 Aug 2006 18:15:49 +0900 To: "Mark Davis" , "Addison Phillips" From: Martin Duerst Subject: Re: [Ltru] ISO CD 639-6 (was: Re: Language and scriptencodingstandards) In-Reply-To: <30b660a20607270934q35c8088aw918c2d05db651e17@mail.gmail.co m> References: <30b660a20607270840s6b9714c4ida10fbb6ddd820de@mail.gmail.com> <002601c6b196$fe5a2850$650a0a0a@ds.corp.yahoo.com> <30b660a20607270934q35c8088aw918c2d05db651e17@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 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 I have added a sentence to the charter, as follows: >>>> The working group will also consider how the draft work on ISO 639-6 may relate to the future development of language tags. >>>> This is much shorter than the proposal below, but in my judgement says just about the same. Regards, Martin. At 01:34 06/07/28, Mark Davis wrote: >I agree with that approach, but the last bit needs to be even more tentative, something like: > >The working group should also consider ISO 639-6 and whether or how that evolving work might relate to the future development of language tags. Because this work is not mature and may not be suitable for inclusion, it might not appear in the document produced by this working group. > >Mark #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 11:10:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91Jr-0007mZ-If; Fri, 04 Aug 2006 11:10:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91Jq-0007mU-Et for ltru@ietf.org; Fri, 04 Aug 2006 11:10:34 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G91Jp-0004qu-2V for ltru@ietf.org; Fri, 04 Aug 2006 11:10:34 -0400 Received: from [10.72.72.17] (snvvpn1-10-72-72-c17.corp.yahoo.com [10.72.72.17]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k74FAJW0011303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Aug 2006 08:10:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=Dn7DkMVOtKJ5kViuPDh4ObOf8zy7BMj/PdaTN4oX+amhUkagQRIEojPJnxtaXfze Message-ID: <44D3635C.5020902@yahoo-inc.com> Date: Fri, 04 Aug 2006 08:10:20 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Charter update proposal References: <6.0.0.20.2.20060726163255.05cb0cf0@localhost> <000601c6b286$a34cd0c0$9fcd15ac@ds.corp.yahoo.com> <6.0.0.20.2.20060804174746.07f62c90@localhost> In-Reply-To: <6.0.0.20.2.20060804174746.07f62c90@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.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 >> >> -- >> ISO 639-3, scheduled for approval towards the end of 2006, will make >> available around 7000 additional codes for identifying languages. > > I have decided that when speaking about ISO, I'm using their > terminology (code elements), and when speaking about our stuff, > I'm using our terminology. I hope this will come out reasonably > well. That's fine. > >>> The working group will also deliver means to update the current >>> IANA language subtag registry with the newly available codes. >> I would change this to be slightly more expansive: >> >> -- >> The working group will also deliver a means to update the current >> IANA language subtag registry with the newly available codes, as well >> as procedures for maintaining the registry as codes are assigned >> or modified in the future. > > My understanding is that we already have the procedures for > updating. Or do we miss something? We do. The "means of updating" would probably be some form of new "draft-initial". The "procedures for maintaining" are instructions on how to handle future ISO 639-3 registrations. The reason this is different is that these registrations will need to be evaluated for "lang-or-extlang-ness", which is something we do not have today. > >> -- >> >> Or you might consider using a separate sentence, such as the one I proposed >> yesterday: >> >> -- >> The working group must decide how ISO 639-3 codes are entered into the >> registry, what rules apply to associating a code with the language and/or > =>extlang subtag types, and any additional rules or guidance on their adoption >> and use. >> -- > > I don't see what's substantially different here from the existing > text: > > The working group will prepare an update to the Language Subtag > Registry procedures to allow the use of 3-letter codes from > ISO 639-3 as primary subtags or extended language subtags as > appropriate. > > In short, we have to update the procedures so that we can use > IOS 639-3. I don't think that we need more details here. > How codes are entered, what types they are given, and so on, > should all be covered under Language Subtag Registry > procedures. Yes, but the things I mention are requirements that the Working Group must address. I favor listing requirements explicitly and treating other items as "potentially out of scope". We might, for example, decide that the best thing to do about, say, transliterations is "nothing". But we must decide in this iteration what to do about extlangs. >> >>> Work on the drafts is planned to start before ISO 639-3 is fully >>> approved and published. However, the WG will not finalize the drafts >>> before ISO 639-3 is fully approved. >> I'm not sure that's correct. It would be more appropriate to say >> "Publication of the draft(s) as an RFC will depend on final approval of ISO >> 639-3." There is ample space in the RFC Editor process for awaiting specific >> external events (as we've already discovered). We might well finalize an >> update to draft-registry quite quickly, but not the actual registry update >> ("draft-initial"). > > Peter said that he would have the approval by the third week of September. > Do you think we'll be finished with our drafts before that? No, but your text was not correct. I'm allergic to artificial dependencies, based on our experience with 3066bis. ISO 639-3 might (unlikely as it probably is) take longer than Peter imagines. Our drafts, meanwhile, might go very quickly [if we can avoid the tar pits surrounding issues I personally would prefer to see remain off-topic]. Regards, Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 11:20:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91Sz-0008Py-6h; Fri, 04 Aug 2006 11:20:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91Sx-0008Pt-NW for ltru@ietf.org; Fri, 04 Aug 2006 11:19:59 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G91Sw-0005NC-Bn for ltru@ietf.org; Fri, 04 Aug 2006 11:19:59 -0400 Received: from [10.72.72.17] (snvvpn1-10-72-72-c17.corp.yahoo.com [10.72.72.17]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k74FJpds011622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Aug 2006 08:19:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=DHZ9kGi/YSvtjmfEtOqTHEr4qXbUhYbsDtveftS4qO5+k+rsTE9vky32JhCi+fVe Message-ID: <44D36598.1020304@yahoo-inc.com> Date: Fri, 04 Aug 2006 08:19:52 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Test suite for language tags? References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> In-Reply-To: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell wrote: > > Just a few minor nits here. This is slightly more complex than meets > the eye, unfortunately. Yep. > >> - singletons in the first position (except for 'x' and the >> grandfathered list) > > Sadly, the existence of the grandfathered list means that all > well-formed processors must also do a limited amount of validity > checking. I don't question the importance of maintaining support for > the grandfathered tags, but this is a side effect. Agreed: all RFC 3066bis processors have to have the list of grandfathered tags baked in. > >> - missing subtag ("--") >> - a dangling hyphen ("foo-bar-baz-") or initial hyphen ("-foo-bar-baz") > > The second is really just a special case of the first: a missing subtag > at the end or beginning, respectively. One thing I found useful, when > building my validator, was to parse out the subtags first and check them > for validity afterward, so the hyphens never become part of the validity > checking per se. I did the same thing. However, one must check the hyphens. Tokenizers sometimes do not return "empty" tokens and can miss these cases. > >> "ab-x-abc-x-abc" // anything goes after x > > Not quite anything, of course: 1*("-" (1*8alphanum)) Yes. At least one alphanumeric subtag must follow 'x' and it cannot exceed eight characters in length. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 11:22:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91VL-0002HQ-6g; Fri, 04 Aug 2006 11:22:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G91VK-0002HK-EJ for ltru@ietf.org; Fri, 04 Aug 2006 11:22:26 -0400 Received: from mail3.microsoft.com ([131.107.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G91VI-0005W4-5B for ltru@ietf.org; Fri, 04 Aug 2006 11:22:26 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Fri, 4 Aug 2006 08:22:23 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Fri, 4 Aug 2006 08:22:23 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Charter update proposal (updated) Date: Fri, 4 Aug 2006 08:22:22 -0700 Message-ID: In-Reply-To: <6.0.0.20.2.20060804144524.07f52660@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Charter update proposal (updated) Thread-Index: Aca3p9ZyuLd5Fm49Riq9kNyjPlrXoQAMO2lQ From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 04 Aug 2006 15:22:23.0450 (UTC) FILETIME=[C8FDCBA0:01C6B7D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Below please find an updated proposal for our charter update > (rechartering)... This looks good to me. I have one minor suggested addition, which you can ignore if it means a significant delay for you: > The primary language subtags allowed by the current IANA Language > Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same > way as they were limited by RFC 3066. This covers approximately 500 > possible language subtags. ISO 639-3, scheduled for approval towards > the end of 2006, will make available around 7000 more code elements > for identifying languages. Add:=20 "These additional code elements provide coverage for all known human languages in use today." That would pre-empt questions as to (1) why we would be getting such a large increase in subtags and (2) whether this is a one-time bulk increase or if there are going to be repeated order-of-magnitude increases. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 13:02:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9343-0007dP-B0; Fri, 04 Aug 2006 13:02:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9341-0007dK-Qy for ltru@ietf.org; Fri, 04 Aug 2006 13:02:21 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G933z-00049F-IU for ltru@ietf.org; Fri, 04 Aug 2006 13:02:21 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 39024240814; Fri, 4 Aug 2006 19:02:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id E8E5A117BF; Fri, 4 Aug 2006 18:57:20 +0200 (CEST) Date: Fri, 4 Aug 2006 18:57:20 +0200 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20060804165720.GA24037@sources.org> References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D21ACD.4040707@yahoo-inc.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 Thu, Aug 03, 2006 at 08:48:29AM -0700, Addison Phillips wrote a message of 30 lines which said: > I could probably have saved time writing that message if I'd just > sent my JUnits ;-). I do not program in Java so I'm not sure it would have been helpful :-) The best thing would probably to create four text files containing tags, one per line (may be with comments allowed), with: * two files for well-formedness (OK/broken), * two files for validaty (OK/invalid). So anyone could use it as a test suite, by converting the text files to Junit, PyUnit, HUnit, whatever. > Just curious: will you also be implementing a validating parser? Yes, it is on the tracks. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 13:18:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G93K0-00078c-07; Fri, 04 Aug 2006 13:18:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G93Jy-00078V-A6 for ltru@ietf.org; Fri, 04 Aug 2006 13:18:50 -0400 Received: from mta2.iomartmail.com ([62.128.193.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G93Jw-0005Aj-Sq for ltru@ietf.org; Fri, 04 Aug 2006 13:18:50 -0400 Received: from mta2.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta2.iomartmail.com (8.12.8/8.12.8) with ESMTP id k74HIjax014315; Fri, 4 Aug 2006 18:18:45 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta2.iomartmail.com (8.12.8/8.12.8) with ESMTP id k74HIelP014179; Fri, 4 Aug 2006 18:18:45 +0100 Message-Id: <200608041718.k74HIelP014179@mta2.iomartmail.com> From: "Debbie Garside" To: "'Peter Constable'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter update proposal (updated) Date: Fri, 4 Aug 2006 18:18:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: Aca3p9ZyuLd5Fm49Riq9kNyjPlrXoQAMO2lQAAP0mXA= In-Reply-To: X-Spam-Score: 0.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 Peter wrote: >> "These additional code elements provide coverage for all > known human languages in use today." I think this could form quite a contentious statement and should not be added as is. There are many cases where a linguistic entity can be treated as a dialect by some and a language by others and vice versa. Perhaps a better statement would be: ---- These additional code elements provide coverage for the majority of known human languages in use today. ---- "the majority" could be replaced with "significant proportions". Best regards Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 04 August 2006 16:22 > To: LTRU Working Group > Subject: RE: [Ltru] Charter update proposal (updated) > > > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > > > > Below please find an updated proposal for our charter update > > (rechartering)... > > This looks good to me. > > I have one minor suggested addition, which you can ignore if > it means a significant delay for you: > > > The primary language subtags allowed by the current IANA Language > > Subtag Registry are limited to ISO 639-1 and ISO 639-2 in > the same way > > as they were limited by RFC 3066. This covers approximately 500 > > possible language subtags. ISO 639-3, scheduled for > approval towards > > the end of 2006, will make available around 7000 more code elements > > for identifying languages. > > Add: > > "These additional code elements provide coverage for all > known human languages in use today." > > That would pre-empt questions as to (1) why we would be > getting such a large increase in subtags and (2) whether this > is a one-time bulk increase or if there are going to be > repeated order-of-magnitude increases. > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 14:19:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94GX-0007aF-Cx; Fri, 04 Aug 2006 14:19:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94GV-0007a9-L6 for ltru@ietf.org; Fri, 04 Aug 2006 14:19:19 -0400 Received: from mail3.microsoft.com ([131.107.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G94GT-0000ru-Cy for ltru@ietf.org; Fri, 04 Aug 2006 14:19:19 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Fri, 4 Aug 2006 11:19:16 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 11:19:16 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Charter update proposal (updated) Date: Fri, 4 Aug 2006 11:19:12 -0700 Message-ID: In-Reply-To: <200608041718.k74HIelP014179@mta2.iomartmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Charter update proposal (updated) Thread-Index: Aca3p9ZyuLd5Fm49Riq9kNyjPlrXoQAMO2lQAAP0mXAAAmf38A== From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 04 Aug 2006 18:19:16.0881 (UTC) FILETIME=[7F16D810:01C6B7F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > I think this could form quite a contentious statement and should not = be > added as is. There are many cases where a linguistic entity can be = treated > as a dialect by some and a language by others and vice versa. >=20 > Perhaps a better statement would be: >=20 > ---- >=20 > These additional code elements provide coverage for the majority of = known > human languages in use today. >=20 > ---- Fine with me, but I'd go for "vast majority". But as I said, I'm also OK = with the text that Martin had drafted. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 14:25:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94Mr-000495-EP; Fri, 04 Aug 2006 14:25:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94Mp-00043V-V7 for ltru@ietf.org; Fri, 04 Aug 2006 14:25:51 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G94Mn-0001LO-OA for ltru@ietf.org; Fri, 04 Aug 2006 14:25:51 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1G94Mm-0005g9-5a; Fri, 04 Aug 2006 14:25:48 -0400 Date: Fri, 4 Aug 2006 14:25:48 -0400 To: Debbie Garside Subject: Re: [Ltru] Charter update proposal (updated) Message-ID: <20060804182548.GD10897@ccil.org> References: <200608041718.k74HIelP014179@mta2.iomartmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608041718.k74HIelP014179@mta2.iomartmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Debbie Garside scripsit: > Peter wrote: > > > "These additional code elements provide coverage for all > > known human languages in use today." > > I think this could form quite a contentious statement and should not be > added as is. There are many cases where a linguistic entity can be treated > as a dialect by some and a language by others and vice versa. I think this comment misses the significance of the word "coverage". There are indeed disputes about whether the 639-3 codes match up one-for-one with the world's languages. But nevertheless, for every variety of language, there is a 639-3 code that describes it, if less precisely than some would prefer. This is not the case in 639-2, except insofar as every language might be brought under some collective-language code element or other. So whereas there is simply no sensible way to code, say, Sac content using 639-2 except to blanket it as 'nai', tagging it only as "some North American Indian language", all instances of such content are now covered by the 639-3 code element 'sac', even though that code element also includes Fox and Mesquakie. And so on for all known instances of linguistic content. -- John Cowan cowan@ccil.org http://ccil.org/~cowan In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 14:28:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94PU-0008W2-C6; Fri, 04 Aug 2006 14:28:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94PT-0008Vs-Le for ltru@ietf.org; Fri, 04 Aug 2006 14:28:35 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G94PS-0001SE-CP for ltru@ietf.org; Fri, 04 Aug 2006 14:28:35 -0400 Received: by py-out-1112.google.com with SMTP id m51so374783pye for ; Fri, 04 Aug 2006 11: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:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=i6k3Lksyz7pAFn1XtMMI0Y8fbofKwWLcBmj+AbRt4S3LCmQf64nr9rV+qEzWHhhWUrvRXtjg59J9mJljhlLzpPwlneuOjktA3IxSfh7Ihdqu7gXT1RZUjv3mVvIYiPOnF9zbmSNdNLYBxVdEVCuhLRalw8e/0BM7l/4MoT+Xegk= Received: by 10.35.9.15 with SMTP id m15mr5444827pyi; Fri, 04 Aug 2006 11:28:34 -0700 (PDT) Received: by 10.35.67.20 with HTTP; Fri, 4 Aug 2006 11:28:33 -0700 (PDT) Message-ID: <30b660a20608041128i69ca832at647758d76821047b@mail.gmail.com> Date: Fri, 4 Aug 2006 11:28:34 -0700 From: "Mark Davis" To: "Peter Constable" Subject: Re: [Ltru] Charter update proposal (updated) In-Reply-To: MIME-Version: 1.0 References: <200608041718.k74HIelP014179@mta2.iomartmail.com> X-Google-Sender-Auth: 3dec05565c118bdf X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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="===============0351523594==" Errors-To: ltru-bounces@ietf.org --===============0351523594== Content-Type: multipart/alternative; boundary="----=_Part_13897_29419923.1154716114004" ------=_Part_13897_29419923.1154716114004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline As with many other taxonomies, there are varying degrees of granularity; by 'language' one could mean anything down to ideolects. For the purposes of BCP 47, we have no desire to have indefinitely fine distinctions, so I don't have any problem with Peter's original formulation, perhaps with a minor qualification indicating the degree of granularity being applied. Mark On 8/4/06, Peter Constable wrote: > > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > > > I think this could form quite a contentious statement and should not be > > added as is. There are many cases where a linguistic entity can be > treated > > as a dialect by some and a language by others and vice versa. > > > > Perhaps a better statement would be: > > > > ---- > > > > These additional code elements provide coverage for the majority of > known > > human languages in use today. > > > > ---- > > Fine with me, but I'd go for "vast majority". But as I said, I'm also OK > with the text that Martin had drafted. > > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > ------=_Part_13897_29419923.1154716114004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline As with many other taxonomies, there are varying degrees of granularity; by 'language' one could mean anything down to ideolects. For the purposes of BCP 47, we have no desire to have indefinitely fine distinctions, so I don't have any problem with Peter's original formulation, perhaps with a minor qualification indicating the degree of granularity being applied.

Mark

On 8/4/06, Peter Constable <petercon@microsoft.com> wrote:
> From: Debbie Garside [mailto:debbie@ictmarketing.co.uk]


> I think this could form quite a contentious statement and should not be
> added as is. There are many cases where a linguistic entity can be treated
> as a dialect by some and a language by others and vice versa.
>
> Perhaps a better statement would be:
>
> ----
>
> These additional code elements provide coverage for the majority of known
> human languages in use today.
>
> ----

Fine with me, but I'd go for "vast majority". But as I said, I'm also OK with the text that Martin had drafted.




Peter Constable

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

------=_Part_13897_29419923.1154716114004-- --===============0351523594== 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 --===============0351523594==-- From ltru-bounces@ietf.org Fri Aug 04 14:41:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94c1-0004Yx-H3; Fri, 04 Aug 2006 14:41:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94bz-0004Ys-K1 for ltru@ietf.org; Fri, 04 Aug 2006 14:41:31 -0400 Received: from mta6.iomartmail.com ([62.128.193.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G94by-0002EP-7w for ltru@ietf.org; Fri, 04 Aug 2006 14:41:31 -0400 Received: from mta6.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k74IfMLc005957; Fri, 4 Aug 2006 19:41:22 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k74IfIt8005737; Fri, 4 Aug 2006 19:41:22 +0100 Message-Id: <200608041841.k74IfIt8005737@mta6.iomartmail.com> From: "Debbie Garside" To: "'Addison Phillips'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter update proposal (updated) Date: Fri, 4 Aug 2006 19:41:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: Aca39IDztfSntALvREyUql6kAKojZgAAHX/Q In-Reply-To: <44D392F3.5090901@yahoo-inc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison wrote: > "These additional code elements are intended to provide > coverage for all known human languages in use today." +1 Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison@yahoo-inc.com] > Sent: 04 August 2006 19:33 > To: John Cowan > Cc: Debbie Garside; ltru@ietf.org > Subject: Re: [Ltru] Charter update proposal (updated) > > > > > I think this comment misses the significance of the word > "coverage". > > There are indeed disputes about whether the 639-3 codes > match up > one-for-one with the world's languages. But > nevertheless, for every > variety of language, there is a > 639-3 code that describes it, if less > precisely than some > would prefer. This is not the case in 639-2, except > > insofar as every language might be brought under some > collective-language > code element or other. > > The easiest way out of this conundrum would be: > > "These additional code elements are intended to provide > coverage for all known human languages in use today." > > This covers the reason why without addressing whether the > effort has been a success or not. > > Addison > -- > Addison Phillips > Globalization Architect -- Yahoo! Inc. > > Internationalization is an architecture. > It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 14:47:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94hO-0007WW-A0; Fri, 04 Aug 2006 14:47:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G94hN-0007UH-Sf for ltru@ietf.org; Fri, 04 Aug 2006 14:47:05 -0400 Received: from mta6.iomartmail.com ([62.128.193.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G94hM-0002dq-FT for ltru@ietf.org; Fri, 04 Aug 2006 14:47:05 -0400 Received: from mta6.iomartmail.com (localhost.localdomain [127.0.0.1]) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k74Il3Sl014472; Fri, 4 Aug 2006 19:47:03 +0100 Received: from DebbieLaptop (i-83-67-121-192.freedom2surf.net [83.67.121.192]) (authenticated bits=0) by mta6.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id k74IkwGB014340; Fri, 4 Aug 2006 19:47:03 +0100 Message-Id: <200608041847.k74IkwGB014340@mta6.iomartmail.com> From: "Debbie Garside" To: "'Peter Constable'" , "'LTRU Working Group'" Subject: RE: [Ltru] Charter update proposal (updated) Date: Fri, 4 Aug 2006 19:46:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 thread-index: Aca3p9ZyuLd5Fm49Riq9kNyjPlrXoQAMO2lQAAP0mXAAAmf38AAA9hQQ In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I would also be happy with "Vast majority"... Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 04 August 2006 19:19 > To: LTRU Working Group > Subject: RE: [Ltru] Charter update proposal (updated) > > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > > > I think this could form quite a contentious statement and > should not > > be added as is. There are many cases where a linguistic > entity can be > > treated as a dialect by some and a language by others and > vice versa. > > > > Perhaps a better statement would be: > > > > ---- > > > > These additional code elements provide coverage for the majority of > > known human languages in use today. > > > > ---- > > Fine with me, but I'd go for "vast majority". But as I said, > I'm also OK with the text that Martin had drafted. > > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 17:04:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G96qX-0004Fg-E4; Fri, 04 Aug 2006 17:04:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G96qX-0004EQ-3Z for ltru@ietf.org; Fri, 04 Aug 2006 17:04:41 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G96qV-0004MV-Ro for ltru@ietf.org; Fri, 04 Aug 2006 17:04:41 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 48BB4240814; Fri, 4 Aug 2006 22:42:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 7068C1154E; Fri, 4 Aug 2006 22:39:24 +0200 (CEST) Date: Fri, 4 Aug 2006 22:39:24 +0200 From: Stephane Bortzmeyer To: Doug Ewell Message-ID: <20060804203924.GB24037@sources.org> References: <002a01c6b78b$999f7820$040aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002a01c6b78b$999f7820$040aa8c0@DGBP7M81> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: LTRU Working Group Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 Thu, Aug 03, 2006 at 11:02:41PM -0700, Doug Ewell wrote a message of 27 lines which said: > There are probably fewer than 5 independent RFC 3066bis processors > on the planet; we need more. Five is quite good for a standard which is not even a RFC. I'm not sure that DNS, for instance, or DHCP, has five *independant* implementations. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 17:59:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97ha-0004gu-4S; Fri, 04 Aug 2006 17:59:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97hY-0004gm-Eh for ltru@ietf.org; Fri, 04 Aug 2006 17:59:28 -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 1G94XW-0001uO-4S for ltru@ietf.org; Fri, 04 Aug 2006 14:36:54 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G94UP-0005x8-Gq for ltru@ietf.org; Fri, 04 Aug 2006 14:33:43 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k74IXNMF012311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Aug 2006 11:33:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=JgsgsqJJQG4Wn9Ah7RSeyW7KEn/1NvqINpKDSD+4lecdukp33/te7Rn3jmyUcEir Message-ID: <44D392F3.5090901@yahoo-inc.com> Date: Fri, 04 Aug 2006 11:33:23 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Charter update proposal (updated) References: <200608041718.k74HIelP014179@mta2.iomartmail.com> <20060804182548.GD10897@ccil.org> In-Reply-To: <20060804182548.GD10897@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -17.6 (-----------------) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > I think this comment misses the significance of the word "coverage". > There are indeed disputes about whether the 639-3 codes match up > one-for-one with the world's languages. But nevertheless, for every > variety of language, there is a 639-3 code that describes it, if less > precisely than some would prefer. This is not the case in 639-2, except > insofar as every language might be brought under some collective-language > code element or other. The easiest way out of this conundrum would be: "These additional code elements are intended to provide coverage for all known human languages in use today." This covers the reason why without addressing whether the effort has been a success or not. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 18:15:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97xI-0006qI-4Z; Fri, 04 Aug 2006 18:15:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G97xG-0006qD-UR for ltru@ietf.org; Fri, 04 Aug 2006 18:15:42 -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 1G94zW-0003i3-4R for ltru@ietf.org; Fri, 04 Aug 2006 15:05:50 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G94n7-0006PB-6g for ltru@ietf.org; Fri, 04 Aug 2006 14:53:04 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1G94n0-0006Mz-Dr; Fri, 04 Aug 2006 14:52:54 -0400 Date: Fri, 4 Aug 2006 14:52:54 -0400 To: Martin Duerst Subject: Re: [Ltru] Charter update proposal (updated) Message-ID: <20060804185254.GH10897@ccil.org> References: <6.0.0.20.2.20060804144524.07f52660@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060804144524.07f52660@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: -2.6 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > September 2006 Submit first WG draft of registry procedure update > September 2006 Submit first WG draft of registry data update > > January 2007 Submit registry procedure update draft for IETF Last Call > January 2007 Submit registry data update draft for IETF Last Call Hmm. Are we likely to end up with an RFC that is superseded *before* it is published? And has that ever happened before? -- John Cowan http://www.ccil.org/~cowan .e'osai ko sarji la lojban. Please support Lojban! http://www.lojban.org _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 18:40:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98LV-0008OU-A5; Fri, 04 Aug 2006 18:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G98LU-0008N0-1w for ltru@ietf.org; Fri, 04 Aug 2006 18:40:44 -0400 Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G98LS-0001tD-RN for ltru@ietf.org; Fri, 04 Aug 2006 18:40:44 -0400 Received: from h-68-166-38-133.snvacaid.dynamic.covad.net ([68.166.38.133] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #1) id 1G98LS-0005xl-00 for ltru@ietf.org; Fri, 04 Aug 2006 18:40:42 -0400 Message-ID: <005e01c6b817$4772c3e0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <200608041718.k74HIelP014179@mta2.iomartmail.com><20060804182548.GD10897@ccil.org> <44D392F3.5090901@yahoo-inc.com> Subject: Re: [Ltru] Charter update proposal (updated) Date: Fri, 4 Aug 2006 15:42:33 -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: 97adf591118a232206bdb5a27b217034 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - As a technical contributor ... > From: "Addison Phillips" > To: "John Cowan" > Cc: > Sent: Friday, August 04, 2006 11:33 AM > Subject: Re: [Ltru] Charter update proposal (updated) ... > The easiest way out of this conundrum would be: > > "These additional code elements are intended to provide coverage for all > known human languages in use today." > > This covers the reason why without addressing whether the effort has > been a success or not. ... No. The easiest fix is to not add the text at all. A WG charter is not the place to give a tutorial. A WG charter, according to RFC 2418, | 1. Lists relevant administrative information for the working group; | 2. Specifies the direction or objectives of the working group and | describes the approach that will be taken to achieve the goals; | and | 3. Enumerates a set of milestones together with time frames for their | completion. So, we should identity the standards we propose to use or consider, but there's no point to further elaboration. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 04 22:48:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9CCn-00008K-JE; Fri, 04 Aug 2006 22:48:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9CCm-0008Uq-5l for ltru@ietf.org; Fri, 04 Aug 2006 22:48:00 -0400 Received: from mailb.microsoft.com ([131.107.1.8] helo=mail3.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9CCk-0008Be-To for ltru@ietf.org; Fri, 04 Aug 2006 22:48:00 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Fri, 4 Aug 2006 19:47:58 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 4 Aug 2006 19:47:57 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Charter update proposal (updated) Date: Fri, 4 Aug 2006 19:47:51 -0700 Message-ID: In-Reply-To: <005e01c6b817$4772c3e0$6501a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Charter update proposal (updated) Thread-Index: Aca4FwgbpKF+tYVwTjS9sTHhK6WTMgAIm1Hg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 05 Aug 2006 02:47:58.0154 (UTC) FILETIME=[8F2F82A0:01C6B839] X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============0893782716==" Errors-To: ltru-bounces@ietf.org --===============0893782716== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBSYW5keSBQcmVzdWhuIFttYWlsdG86cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNv bV0NCg0KDQo+IE5vLiAgVGhlIGVhc2llc3QgZml4IGlzIHRvIG5vdCBhZGQgdGhlIHRleHQgYXQg YWxsLi4uDQoNCk9LIHdpdGggbWUuDQoNCg0KDQpQZXRlciBDb25zdGFibGUNCg== --===============0893782716== 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 --===============0893782716==-- From ltru-bounces@ietf.org Sat Aug 05 01:07:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9EO8-0002Db-8J; Sat, 05 Aug 2006 01:07:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9EO7-0002DW-2A for ltru@ietf.org; Sat, 05 Aug 2006 01:07:51 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9EO5-0007To-Qm for ltru@ietf.org; Sat, 05 Aug 2006 01:07:51 -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 <20060805050745.YCQQ14422.mta11.adelphia.net@DGBP7M81> for ; Sat, 5 Aug 2006 01:07:45 -0400 Message-ID: <001801c6b84d$144cd510$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Fri, 4 Aug 2006 22:07:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: >> There are probably fewer than 5 independent RFC 3066bis processors on >> the planet; we need more. > > Five is quite good for a standard which is not even a RFC. I'm not > sure that DNS, for instance, or DHCP, has five *independant* > implementations. Your point is well taken. However: 1. I wouldn't expect there to be a need for more than a few DNS implementations. By contrast, there could be many different types of applications that need to interpret, or even generate, language tags. 2. Five was being generous. I know I have one and Addison has one, and I think Mark put one together for demonstration purposes than was about 98% complete, and now yours. -- 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 Sat Aug 05 03:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk7-0002vF-It; Sat, 05 Aug 2006 03:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk6-0002v2-Ba for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Gk2-0002mZ-LT for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k757cQ66024240; Sat, 5 Aug 2006 16:38:26 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 19b8_617661d4_2455_11db_8eda_0014221fa3c9; Sat, 05 Aug 2006 16:38:26 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k757cBQ0028368; Sat, 5 Aug 2006 16:38:21 +0900 Message-Id: <6.0.0.20.2.20060805114558.09dd4580@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 05 Aug 2006 16:37:49 +0900 To: Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Charter update proposal In-Reply-To: <44D3635C.5020902@yahoo-inc.com> References: <6.0.0.20.2.20060726163255.05cb0cf0@localhost> <000601c6b286$a34cd0c0$9fcd15ac@ds.corp.yahoo.com> <6.0.0.20.2.20060804174746.07f62c90@localhost> <44D3635C.5020902@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 00:10 06/08/05, Addison Phillips wrote: >>>> The working group will also deliver means to update the current >>>> IANA language subtag registry with the newly available codes. >>> I would change this to be slightly more expansive: >>> >>> -- >>> The working group will also deliver a means to update the current >>> IANA language subtag registry with the newly available codes, as well >>> as procedures for maintaining the registry as codes are assigned or modified in the future. >> My understanding is that we already have the procedures for >> updating. Or do we miss something? > >We do. The "means of updating" would probably be some form of new "draft-initial". Yes. This is worded as "means of updating" on purpose, because it gives us some leeway to choose some other means than an internet-draft if we think an internet draft really doesn't work (e.g. because of the volume). >The "procedures for maintaining" are instructions on how to handle future ISO 639-3 registrations. The reason this is different is that these registrations will need to be evaluated for "lang-or-extlang-ness", which is something we do not have today. I understand that we need these. And they are not covered by the "deliver a means" sentence. However, they are covered by the following sentence before: -------- The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. -------- In my understanding, "procedures" here include the procedures for updates to the registry at later points in time when new code elements are added to ISO 639-3. >>> -- >>> >>> Or you mighFrom ltru-bounces@ietf.org Sat Aug 05 03:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk7-0002vF-It; Sat, 05 Aug 2006 03:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk6-0002v2-Ba for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Gk2-0002mZ-LT for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k757cQ66024240; Sat, 5 Aug 2006 16:38:26 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 19b8_617661d4_2455_11db_8eda_0014221fa3c9; Sat, 05 Aug 2006 16:38:26 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k757cBQ0028368; Sat, 5 Aug 2006 16:38:21 +0900 Message-Id: <6.0.0.20.2.20060805114558.09dd4580@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 05 Aug 2006 16:37:49 +0900 To: Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Charter update proposal In-Reply-To: <44D3635C.5020902@yahoo-inc.com> References: <6.0.0.20.2.20060726163255.05cb0cf0@localhost> <000601c6b286$a34cd0c0$9fcd15ac@ds.corp.yahoo.com> <6.0.0.20.2.20060804174746.07f62c90@localhost> <44D3635C.5020902@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 00:10 06/08/05, Addison Phillips wrote: >>>> The working group will also deliver means to update the current >>>> IANA language subtag registry with the newly available codes. >>> I would change this to be slightly more expansive: >>> >>> -- >>> The working group will also deliver a means to update the current >>> IANA language subtag registry with the newly available codes, as well >>> as procedures for maintaining the registry as codes are assigned or modified in the future. >> My understanding is that we already have the procedures for >> updating. Or do we miss something? > >We do. The "means of updating" would probably be some form of new "draft-initial". Yes. This is worded as "means of updating" on purpose, because it gives us some leeway to choose some other means than an internet-draft if we think an internet draft really doesn't work (e.g. because of the volume). >The "procedures for maintaining" are instructions on how to handle future ISO 639-3 registrations. The reason this is different is that these registrations will need to be evaluated for "lang-or-extlang-ness", which is something we do not have today. I understand that we need these. And they are not covered by the "deliver a means" sentence. However, they are covered by the following sentence before: -------- The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. -------- In my understanding, "procedures" here include the procedures for updates to the registry at later points in time when new code elements are added to ISO 639-3. >>> -- >>> >>> Or you mighFrom ltru-bounces@ietf.org Sat Aug 05 03:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk7-0002vF-It; Sat, 05 Aug 2006 03:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk6-0002v2-Ba for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Gk2-0002mZ-LT for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k757cQ66024240; Sat, 5 Aug 2006 16:38:26 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 19b8_617661d4_2455_11db_8eda_0014221fa3c9; Sat, 05 Aug 2006 16:38:26 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k757cBQ0028368; Sat, 5 Aug 2006 16:38:21 +0900 Message-Id: <6.0.0.20.2.20060805114558.09dd4580@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 05 Aug 2006 16:37:49 +0900 To: Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Charter update proposal In-Reply-To: <44D3635C.5020902@yahoo-inc.com> References: <6.0.0.20.2.20060726163255.05cb0cf0@localhost> <000601c6b286$a34cd0c0$9fcd15ac@ds.corp.yahoo.com> <6.0.0.20.2.20060804174746.07f62c90@localhost> <44D3635C.5020902@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: 'LTRU Working Group' X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 00:10 06/08/05, Addison Phillips wrote: >>>> The working group will also deliver means to update the current >>>> IANA language subtag registry with the newly available codes. >>> I would change this to be slightly more expansive: >>> >>> -- >>> The working group will also deliver a means to update the current >>> IANA language subtag registry with the newly available codes, as well >>> as procedures for maintaining the registry as codes are assigned or modified in the future. >> My understanding is that we already have the procedures for >> updating. Or do we miss something? > >We do. The "means of updating" would probably be some form of new "draft-initial". Yes. This is worded as "means of updating" on purpose, because it gives us some leeway to choose some other means than an internet-draft if we think an internet draft really doesn't work (e.g. because of the volume). >The "procedures for maintaining" are instructions on how to handle future ISO 639-3 registrations. The reason this is different is that these registrations will need to be evaluated for "lang-or-extlang-ness", which is something we do not have today. I understand that we need these. And they are not covered by the "deliver a means" sentence. However, they are covered by the following sentence before: -------- The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. -------- In my understanding, "procedures" here include the procedures for updates to the registry at later points in time when new code elements are added to ISO 639-3. >>> -- >>> >>> Or you might consider using a separate sentence, such as the one I proposed >>> yesterday: >>> >>> -- >>> The working group must decide how ISO 639-3 codes are entered into the >>> registry, what rules apply to associating a code with the language and/or >> =>extlang subtag types, and any additional rules or guidance on their adoption >>> and use. >>> -- >> I don't see what's substantially different here from the existing >> text: >> The working group will prepare an update to the Language Subtag >> Registry procedures to allow the use of 3-letter codes from >> ISO 639-3 as primary subtags or extended language subtags as >> appropriate. >> In short, we have to update the procedures so that we can use >> IOS 639-3. I don't think that we need more details here. >> How codes are entered, what types they are given, and so on, >> should all be covered under Language Subtag Registry >> procedures. > >Yes, but the things I mention are requirements that the Working Group must address. I favor listing requirements explicitly and treating other items as "potentially out of scope". We might, for example, decide that the best thing to do about, say, transliterations is "nothing". But we must decide in this iteration what to do about extlangs. I don't see any reason why we wouldn't. The things that you mention to me are obvious details, not things that need to be called out because otherwise there would be major misunderstandings. >>>> Work on the drafts is planned to start before ISO 639-3 is fully >>>> approved and published. However, the WG will not finalize the drafts >>>> before ISO 639-3 is fully approved. >>> I'm not sure that's correct. It would be more appropriate to say >>> "Publication of the draft(s) as an RFC will depend on final approval of ISO >>> 639-3." There is ample space in the RFC Editor process for awaiting specific >>> external events (as we've already discovered). We might well finalize an >>> update to draft-registry quite quickly, but not the actual registry update >>> ("draft-initial"). >> Peter said that he would have the approval by the third week of September. >> Do you think we'll be finished with our drafts before that? > >No, but your text was not correct. Is it still not correct? If yes, how? >I'm allergic to artificial dependencies, based on our experience with 3066bis. ISO 639-3 might (unlikely as it probably is) take longer than Peter imagines. Our drafts, meanwhile, might go very quickly [if we can avoid the tar pits surrounding issues I personally would prefer to see remain off-topic]. I understand that you want things to be done as quickly as possible. And I agree. However, I don't think it would be appropriate for the WG to finalize the new draft and send it to the IESG before we know that ISO 639-3 is really approved, because the fact that it is not fully approved may mean that there are some more changes, in which case we have to go back and make some changes, too. As ISO 639-3 is the major reason for our new work, I wouldn't call this an "artificial" dependency. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 05 03:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk7-0002v7-Cl; Sat, 05 Aug 2006 03:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk6-0002us-7k for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Gk4-0002ow-Kp for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k757cG3b003352; Sat, 5 Aug 2006 16:38:16 +0900 (JST) Received: from (1t consider using a separate sentence, such as the one I proposed >>> yesterday: >>> >>> -- >>> The working group must decide how ISO 639-3 codes are entered into the >>> registry, what rules apply to associating a code with the language and/or >> =>extlang subtag types, and any additional rules or guidance on their adoption >>> and use. >>> -- >> I don't see what's substantially different here from the existing >> text: >> The working group will prepare an update to the Language Subtag >> Registry procedures to allow the use of 3-letter codes from >> ISO 639-3 as primary subtags or extended language subtags as >> appropriate. >> In short, we have to update the procedures so that we can use >> IOS 639-3. I don't think that we need more details here. >> How codes are entered, what types they are given, and so on, >> should all be covered under Language Subtag Registry >> procedures. > >Yes, but the things I mention are requirements that the Working Group must address. I favor listing requirements explicitly and treating other items as "potentially out of scope". We might, for example, decide that the best thing to do about, say, transliterations is "nothing". But we must decide in this iteration what to do about extlangs. I don't see any reason why we wouldn't. The things that you mention to me are obvious details, not things that need to be called out because otherwise there would be major misunderstandings. >>>> Work on the drafts is planned to start before ISO 639-3 is fully >>>> approved and published. However, the WG will not finalize the drafts >>>> before ISO 639-3 is fully approved. >>> I'm not sure that's correct. It would be more appropriate to say >>> "Publication of the draft(s) as an RFC will depend on final approval of ISO >>> 639-3." There is ample space in the RFC Editor process for awaiting specific >>> external events (as we've already discovered). We might well finalize an >>> update to draft-registry quite quickly, but not the actual registry update >>> ("draft-initial"). >> Peter said that he would have the approval by the third week of September. >> Do you think we'll be finished with our drafts before that? > >No, but your text was not correct. Is it still not correct? If yes, how? >I'm allergic to artificial dependencies, based on our experience with 3066bis. ISO 639-3 might (unlikely as it probably is) take longer than Peter imagines. Our drafts, meanwhile, might go very quickly [if we can avoid the tar pits surrounding issues I personally would prefer to see remain off-topic]. I understand that you want things to be done as quickly as possible. And I agree. However, I don't think it would be appropriate for the WG to finalize the new draft and send it to the IESG before we know that ISO 639-3 is really approved, because the fact that it is not fully approved may mean that there are some more changes, in which case we have to go back and make some changes, too. As ISO 639-3 is the major reason for our new work, I wouldn't call this an "artificial" dependency. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 05 03:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk7-0002v7-Cl; Sat, 05 Aug 2006 03:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk6-0002us-7k for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Gk4-0002ow-Kp for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k757cG3b003352; Sat, 5 Aug 2006 16:38:16 +0900 (JST) Received: from (1t consider using a separate sentence, such as the one I proposed >>> yesterday: >>> >>> -- >>> The working group must decide how ISO 639-3 codes are entered into the >>> registry, what rules apply to associating a code with the language and/or >> =>extlang subtag types, and any additional rules or guidance on their adoption >>> and use. >>> -- >> I don't see what's substantially different here from the existing >> text: >> The working group will prepare an update to the Language Subtag >> Registry procedures to allow the use of 3-letter codes from >> ISO 639-3 as primary subtags or extended language subtags as >> appropriate. >> In short, we have to update the procedures so that we can use >> IOS 639-3. I don't think that we need more details here. >> How codes are entered, what types they are given, and so on, >> should all be covered under Language Subtag Registry >> procedures. > >Yes, but the things I mention are requirements that the Working Group must address. I favor listing requirements explicitly and treating other items as "potentially out of scope". We might, for example, decide that the best thing to do about, say, transliterations is "nothing". But we must decide in this iteration what to do about extlangs. I don't see any reason why we wouldn't. The things that you mention to me are obvious details, not things that need to be called out because otherwise there would be major misunderstandings. >>>> Work on the drafts is planned to start before ISO 639-3 is fully >>>> approved and published. However, the WG will not finalize the drafts >>>> before ISO 639-3 is fully approved. >>> I'm not sure that's correct. It would be more appropriate to say >>> "Publication of the draft(s) as an RFC will depend on final approval of ISO >>> 639-3." There is ample space in the RFC Editor process for awaiting specific >>> external events (as we've already discovered). We might well finalize an >>> update to draft-registry quite quickly, but not the actual registry update >>> ("draft-initial"). >> Peter said that he would have the approval by the third week of September. >> Do you think we'll be finished with our drafts before that? > >No, but your text was not correct. Is it still not correct? If yes, how? >I'm allergic to artificial dependencies, based on our experience with 3066bis. ISO 639-3 might (unlikely as it probably is) take longer than Peter imagines. Our drafts, meanwhile, might go very quickly [if we can avoid the tar pits surrounding issues I personally would prefer to see remain off-topic]. I understand that you want things to be done as quickly as possible. And I agree. However, I don't think it would be appropriate for the WG to finalize the new draft and send it to the IESG before we know that ISO 639-3 is really approved, because the fact that it is not fully approved may mean that there are some more changes, in which case we have to go back and make some changes, too. As ISO 639-3 is the major reason for our new work, I wouldn't call this an "artificial" dependency. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 05 03:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk7-0002v7-Cl; Sat, 05 Aug 2006 03:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk6-0002us-7k for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Gk4-0002ow-Kp for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k757cG3b003352; Sat, 5 Aug 2006 16:38:16 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 1a16_5b8e7018_2455_11db_9437_0014221fa3c9; Sat, 05 Aug 2006 16:38:16 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k757cBPu028368; Sat, 5 Aug 2006 16:38:13 +0900 Message-Id: <6.0.0.20.2.20060805113228.09dda0d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 05 Aug 2006 11:34:40 +0900 To: John Cowan From: Martin Duerst Subject: Re: [Ltru] Charter update proposal (updated) In-Reply-To: <20060804185254.GH10897@ccil.org> References: <6.0.0.20.2.20060804144524.07f52660@localhost> <20060804185254.GH10897@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 03:52 06/08/05, John Cowan wrote: >Martin Duerst scripsit: > >> September 2006 Submit first WG draft of registry procedure update >> September 2006 Submit first WG draft of registry data update >> >> January 2007 Submit registry procedure update draft for IETF Last Call >> January 2007 Submit registry data update draft for IETF Last Call > >Hmm. Are we likely to end up with an RFC that is superseded *before* >it is published? And has that ever happened before? It's up to us, and the RFC Editor. If it happens, it would reflect good on us, but bad on the RFC Editor. What we have to think about now is whether these milestones are realistic for us, independent of what the RFC Editor might do or not do. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 05 03:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk7-0002vB-GU; Sat, 05 Aug 2006 03:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk6-0002ux-AV for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Gk2-0002mV-LT for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k757cLnL024236; Sat, 5 Aug 2006 16:38:21 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 198f_5e48e270_2455_11db_9aa0_0014221fa3c9; Sat, 05 Aug 2006 16:38:20 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k757cBPw028368; Sat, 5 Aug 2006 16:38:19 +0900 Message-Id: <6.0.0.20.2.20060805113524.09ddad20@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 05 Aug 2006 11:36:18 +0900 To: "Randy Presuhn" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Charter update proposal (updated) In-Reply-To: <005e01c6b817$4772c3e0$6501a8c0@oemcomputer> References: <33.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 1a16_5b8e7018_2455_11db_9437_0014221fa3c9; Sat, 05 Aug 2006 16:38:16 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k757cBPu028368; Sat, 5 Aug 2006 16:38:13 +0900 Message-Id: <6.0.0.20.2.20060805113228.09dda0d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 05 Aug 2006 11:34:40 +0900 To: John Cowan From: Martin Duerst Subject: Re: [Ltru] Charter update proposal (updated) In-Reply-To: <20060804185254.GH10897@ccil.org> References: <6.0.0.20.2.20060804144524.07f52660@localhost> <20060804185254.GH10897@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 03:52 06/08/05, John Cowan wrote: >Martin Duerst scripsit: > >> September 2006 Submit first WG draft of registry procedure update >> September 2006 Submit first WG draft of registry data update >> >> January 2007 Submit registry procedure update draft for IETF Last Call >> January 2007 Submit registry data update draft for IETF Last Call > >Hmm. Are we likely to end up with an RFC that is superseded *before* >it is published? And has that ever happened before? It's up to us, and the RFC Editor. If it happens, it would reflect good on us, but bad on the RFC Editor. What we have to think about now is whether these milestones are realistic for us, independent of what the RFC Editor might do or not do. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 05 03:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk7-0002vB-GU; Sat, 05 Aug 2006 03:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk6-0002ux-AV for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Gk2-0002mV-LT for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k757cLnL024236; Sat, 5 Aug 2006 16:38:21 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 198f_5e48e270_2455_11db_9aa0_0014221fa3c9; Sat, 05 Aug 2006 16:38:20 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k757cBPw028368; Sat, 5 Aug 2006 16:38:19 +0900 Message-Id: <6.0.0.20.2.20060805113524.09ddad20@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 05 Aug 2006 11:36:18 +0900 To: "Randy Presuhn" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Charter update proposal (updated) In-Reply-To: <005e01c6b817$4772c3e0$6501a8c0@oemcomputer> References: <33.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 1a16_5b8e7018_2455_11db_9437_0014221fa3c9; Sat, 05 Aug 2006 16:38:16 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k757cBPu028368; Sat, 5 Aug 2006 16:38:13 +0900 Message-Id: <6.0.0.20.2.20060805113228.09dda0d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 05 Aug 2006 11:34:40 +0900 To: John Cowan From: Martin Duerst Subject: Re: [Ltru] Charter update proposal (updated) In-Reply-To: <20060804185254.GH10897@ccil.org> References: <6.0.0.20.2.20060804144524.07f52660@localhost> <20060804185254.GH10897@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 03:52 06/08/05, John Cowan wrote: >Martin Duerst scripsit: > >> September 2006 Submit first WG draft of registry procedure update >> September 2006 Submit first WG draft of registry data update >> >> January 2007 Submit registry procedure update draft for IETF Last Call >> January 2007 Submit registry data update draft for IETF Last Call > >Hmm. Are we likely to end up with an RFC that is superseded *before* >it is published? And has that ever happened before? It's up to us, and the RFC Editor. If it happens, it would reflect good on us, but bad on the RFC Editor. What we have to think about now is whether these milestones are realistic for us, independent of what the RFC Editor might do or not do. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 05 03:38:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk7-0002vB-GU; Sat, 05 Aug 2006 03:38:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Gk6-0002ux-AV for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Gk2-0002mV-LT for ltru@ietf.org; Sat, 05 Aug 2006 03:38:42 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k757cLnL024236; Sat, 5 Aug 2006 16:38:21 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 198f_5e48e270_2455_11db_9aa0_0014221fa3c9; Sat, 05 Aug 2006 16:38:20 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k757cBPw028368; Sat, 5 Aug 2006 16:38:19 +0900 Message-Id: <6.0.0.20.2.20060805113524.09ddad20@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 05 Aug 2006 11:36:18 +0900 To: "Randy Presuhn" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Charter update proposal (updated) In-Reply-To: <005e01c6b817$4772c3e0$6501a8c0@oemcomputer> References: <200608041718.k74HIelP014179@mta2.iomartmail.com> <20060804182548.GD10897@ccil.org> <44D392F3.5090901@yahoo-inc.com> <005e01c6b817$4772c3e0$6501a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 On this, I have to agree with Randy, and as Peter has said that not adding an additional sentence would also be fine, I hope this will be okay with everybody. Regards, Martin. At 07:42 06/08/05, Randy Presuhn wrote: >Hi - > >As a technical contributor ... > >> From: "Addison Phillips" >> To: "John Cowan" >> Cc: >> Sent: Friday, August 04, 2006 11:33 AM >> Subject: Re: [Ltru] Charter update proposal (updated) >... >> The easiest way out of this conundrum would be: >> >> "These additional code elements are intended to provide coverage for all >> known human languages in use today." >> >> This covers the reason why without addressing whether the effort has >> been a success or not. >... > >No. The easiest fix is to not add the text at all. A WG charter is not >the place to give a tutorial. A WG charter, according to RFC 2418, > >| 1. Lists relevant administrative information for the working group; >| 2. Specifies the direction or objectives of the working group and >| describes the approach that will be taken to achieve the goals; >| and >| 3. Enumerates a set of milestones together with time frames for their >| completion. > >So, we should identity the standards we propose to use or consider, >but there's no point to further elaboration. > >Randy > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru 200608041718.k74HIelP014179@mta2.iomartmail.com> <20060804182548.GD10897@ccil.org> <44D392F3.5090901@yahoo-inc.com> <005e01c6b817$4772c3e0$6501a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 On this, I have to agree with Randy, and as Peter has said that not adding an additional sentence would also be fine, I hope this will be okay with everybody. Regards, Martin. At 07:42 06/08/05, Randy Presuhn wrote: >Hi - > >As a technical contributor ... > >> From: "Addison Phillips" >> To: "John Cowan" >> Cc: >> Sent: Friday, August 04, 2006 11:33 AM >> Subject: Re: [Ltru] Charter update proposal (updated) >... >> The easiest way out of this conundrum would be: >> >> "These additional code elements are intended to provide coverage for all >> known human languages in use today." >> >> This covers the reason why without addressing whether the effort has >> been a success or not. >... > >No. The easiest fix is to not add the text at all. A WG charter is not >the place to give a tutorial. A WG charter, according to RFC 2418, > >| 1. Lists relevant administrative information for the working group; >| 2. Specifies the direction or objectives of the working group and >| describes the approach that will be taken to achieve the goals; >| and >| 3. Enumerates a set of milestones together with time frames for their >| completion. > >So, we should identity the standards we propose to use or consider, >but there's no point to further elaboration. > >Randy > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru 200608041718.k74HIelP014179@mta2.iomartmail.com> <20060804182548.GD10897@ccil.org> <44D392F3.5090901@yahoo-inc.com> <005e01c6b817$4772c3e0$6501a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 On this, I have to agree with Randy, and as Peter has said that not adding an additional sentence would also be fine, I hope this will be okay with everybody. Regards, Martin. At 07:42 06/08/05, Randy Presuhn wrote: >Hi - > >As a technical contributor ... > >> From: "Addison Phillips" >> To: "John Cowan" >> Cc: >> Sent: Friday, August 04, 2006 11:33 AM >> Subject: Re: [Ltru] Charter update proposal (updated) >... >> The easiest way out of this conundrum would be: >> >> "These additional code elements are intended to provide coverage for all >> known human languages in use today." >> >> This covers the reason why without addressing whether the effort has >> been a success or not. >... > >No. The easiest fix is to not add the text at all. A WG charter is not >the place to give a tutorial. A WG charter, according to RFC 2418, > >| 1. Lists relevant administrative information for the working group; >| 2. Specifies the direction or objectives of the working group and >| describes the approach that will be taken to achieve the goals; >| and >| 3. Enumerates a set of milestones together with time frames for their >| completion. > >So, we should identity the standards we propose to use or consider, >but there's no point to further elaboration. > >Randy > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 05 10:49:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9NT5-0006DI-Qf; Sat, 05 Aug 2006 10:49:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9NT4-0006DC-V1 for ltru@lists.ietf.org; Sat, 05 Aug 2006 10:49:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9NT4-00032C-TK for ltru@lists.ietf.org; Sat, 05 Aug 2006 10:49:34 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G9NT3-0002qz-W1 for ltru@lists.ietf.org; Sat, 05 Aug 2006 10:49:34 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G9NSz-0002bg-9S for ltru@lists.ietf.org; Sat, 05 Aug 2006 16:49:29 +0200 Received: from pd9fba964.dip0.t-ipconnect.de ([217.251.169.100]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Aug 2006 16:49:29 +0200 Received: from nobody by pd9fba964.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Aug 2006 16:49:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 05 Aug 2006 16:48:38 +0200 Organization: Lines: 20 Message-ID: <44D4AFC6.3FB9@xyzzy.claranet.de> References: <6.0.0.20.2.20060726163255.05cb0cf0@localhost> <000601c6b286$a34cd0c0$9fcd15ac@ds.corp.yahoo.com> <6.0.0.20.2.20060804174746.07f62c90@localhost> <44D3635C.5020902@yahoo-inc.com> <6.0.0.20.2.20060805114558.09dd4580@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba964.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: -2.6 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] Re: Charter update proposal X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > I don't think it would be appropriate for the WG to finalize > the new draft and send it to the IESG before we know that > ISO 639-3 is really approved, because the fact that it is not > fully approved may mean that there are some more changes, in > which case we have to go back and make some changes, too. As > ISO 639-3 is the major reason for our new work, I wouldn't > call this an "artificial" dependency. We also need more procedural experience with the rules as they are. State of the art would be "dump review list as complete failure wrt Suppress-Script". If published today 3066ter should be different from 3066bis wrt list and review management. E.g. we now need a "MUST" for the expert reviewer to read the rules (s)he's supposed to follow. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 05 12:07:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Ogd-0007sZ-A0; Sat, 05 Aug 2006 12:07:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Ogc-0007sM-6X for ltru@lists.ietf.org; Sat, 05 Aug 2006 12:07: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 1G9NMv-0001jt-7R for ltru@lists.ietf.org; Sat, 05 Aug 2006 10:43:13 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G9NEc-0002Ps-BZ for ltru@lists.ietf.org; Sat, 05 Aug 2006 10:34:40 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G9NEE-0008Ip-M4 for ltru@lists.ietf.org; Sat, 05 Aug 2006 16:34:15 +0200 Received: from pd9fba964.dip0.t-ipconnect.de ([217.251.169.100]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Aug 2006 16:34:14 +0200 Received: from nobody by pd9fba964.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Aug 2006 16:34:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sat, 05 Aug 2006 16:33:38 +0200 Organization: Lines: 18 Message-ID: <44D4AC42.79E0@xyzzy.claranet.de> References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba964.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: -2.6 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > The best thing would probably to create four text files > containing tags, one per line (may be with comments allowed), > with: > * two files for well-formedness (OK/broken), > * two files for validaty (OK/invalid). > So anyone could use it as a test suite, by converting the > text files to Junit, PyUnit, HUnit, whatever. Maybe it's possible to publish this in a 3066ter appendix, or better a separate document (informational RFC). I often miss examples and test cases in other documents. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 05 13:38:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Q6G-00083B-AI; Sat, 05 Aug 2006 13:38:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9Q6F-000835-Jt for ltru@ietf.org; Sat, 05 Aug 2006 13:38:11 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9Q6C-0005To-Dp for ltru@ietf.org; Sat, 05 Aug 2006 13:38:09 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1G9Q67-0002B3-O5; Sat, 05 Aug 2006 13:38:03 -0400 Date: Sat, 5 Aug 2006 13:38:03 -0400 To: Doug Ewell Subject: Re: [Ltru] Re: Test suite for language tags? Message-ID: <20060805173803.GJ1115@ccil.org> References: <001801c6b84d$144cd510$040aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001801c6b84d$144cd510$040aa8c0@DGBP7M81> 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 Doug Ewell scripsit: > 2. Five was being generous. I know I have one and Addison has one, and > I think Mark put one together for demonstration purposes than was about > 98% complete, and now yours. I published a Perl one a while back. -- There is / One art John Cowan No more / No less http://www.ccil.org/~cowan To do / All things With art- / Lessness -- Piet Hein _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 05 16:13:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9SWe-0006mu-3n; Sat, 05 Aug 2006 16:13:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9SWd-0006ml-2Z for ltru@ietf.org; Sat, 05 Aug 2006 16:13:35 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9STo-0007z2-Sw for ltru@ietf.org; Sat, 05 Aug 2006 16:10:43 -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 <20060805201036.QFBF14422.mta11.adelphia.net@DGBP7M81> for ; Sat, 5 Aug 2006 16:10:36 -0400 Message-ID: <003a01c6b8cb$332fcb80$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 5 Aug 2006 13:10:29 -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: 4d87d2aa806f79fed918a62e834505ca Subject: [Ltru] Delays (was: Re: Charter update proposal) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> We do. The "means of updating" would probably be some form of new >> "draft-initial". > > Yes. This is worded as "means of updating" on purpose, because it > gives us some leeway to choose some other means than an internet-draft > if we think an internet draft really doesn't work (e.g. because of the > volume). This used to worry me simply on the basis of volume -- an I-D like draft-ietf-ltru-initial, containing the entire 3066ter initial registry contents, would be more than 840 pages long. After witnessing the extreme delays involved in this process, I'm increasingly concerned about the temporal problem as well. Draft-initial was sent to IESG in August 2005, ostensibly for a 2- to 4-week Last Call, and spent 3 months there before moving into the RFC Editor queue. During that time alone, the draft had to be updated to reflect changes in its proposed initial registry contents. In the nine months since draft-initial entered the RFC Editor queue, and IANA created the initial Language Subtag Registry, they have updated it SIX times. The "meat" of the draft, which is to be removed by the RFC Editor before publication, is dreadfully obsolete by now. John Cowan's question about an RFC being superseded before publication is appropriate here. The activities of the WG have been repeatedly stalled by side discussions, groundless appeals, IETF activities that take precedence, and our own inactivity -- long periods of silence on the list, and Last Call comments that are withheld until the last day, necessitating lengthy discussions and additional Last Calls. IESG approved the matching draft on July 6, but it took 18 days to send the announcement. Another 12 days have gone by and the matching draft still has not entered the RFC Editor queue. What is the reason for the delay this time? How long can we expect it to go on? Whether it's written into the charter or not, the WG will need to consider the impact of unexpected, protracted delays on each of its activities, and will need to act accordingly to avoid degrading the value and credibility of its deliverables. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ Editor, draft-ietf-ltru-initial _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 00:07:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ZvS-0003HV-Ko; Sun, 06 Aug 2006 00:07:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9ZvS-0003HN-C0 for ltru@ietf.org; Sun, 06 Aug 2006 00:07:42 -0400 Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9ZvR-0007TZ-5Q for ltru@ietf.org; Sun, 06 Aug 2006 00:07:42 -0400 Received: from h-68-166-37-234.snvacaid.dynamic.covad.net ([68.166.37.234] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #1) id 1G9ZvQ-0000Mq-00 for ltru@ietf.org; Sun, 06 Aug 2006 00:07:40 -0400 Message-ID: <002701c6b90e$06c82ae0$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <003a01c6b8cb$332fcb80$040aa8c0@DGBP7M81> Subject: Re: [Ltru] Delays (was: Re: Charter update proposal) Date: Sat, 5 Aug 2006 21:08:51 -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: d6b246023072368de71562c0ab503126 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Saturday, August 05, 2006 1:10 PM > Subject: [Ltru] Delays (was: Re: Charter update proposal) ... > IESG approved the matching draft on July 6, but it took 18 days to send > the announcement. Another 12 days have gone by and the matching draft > still has not entered the RFC Editor queue. What is the reason for the > delay this time? How long can we expect it to go on? ... When I look at http://www.rfc-editor.org/queue.html, the matching draft is there in the queue. What leads you to believe that it isn't? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 00:37:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9aOh-0004q2-I1; Sun, 06 Aug 2006 00:37:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9aOg-0004px-VO for ltru@ietf.org; Sun, 06 Aug 2006 00:37:54 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9aOf-00066F-N6 for ltru@ietf.org; Sun, 06 Aug 2006 00:37:54 -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 <20060806043753.XHRC12036.mta9.adelphia.net@DGBP7M81> for ; Sun, 6 Aug 2006 00:37:53 -0400 Message-ID: <005e01c6b912$11a39180$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Subject: Re: [Ltru] Delays (was: Re: Charter update proposal) Date: Sat, 5 Aug 2006 21:37:47 -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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > When I look at http://www.rfc-editor.org/queue.html, the matching > draft is there in the queue. What leads you to believe that it isn't? The fact that when I visit https://datatracker.ietf.org/public/pidtracker.cgi, type "LTRU" in the space marked "WG Acronym:", and click SEARCH, it shows this for the matching draft: In State: Approved-announcement sent and this for the other two drafts: In State: RFC Ed Queue I'm glad the matching draft really is in the queue, and this is simply a matter of the tracker database not being updated. All of the other delaying factors I mentioned are real and documented. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 00:55:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9afm-00080u-Jh; Sun, 06 Aug 2006 00:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9afm-00080m-AY for ltru@ietf.org; Sun, 06 Aug 2006 00:55:34 -0400 Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9afl-0001fk-3u for ltru@ietf.org; Sun, 06 Aug 2006 00:55:34 -0400 Received: from h-68-166-37-234.snvacaid.dynamic.covad.net ([68.166.37.234] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #1) id 1G9afk-0000gc-00 for ltru@ietf.org; Sun, 06 Aug 2006 00:55:32 -0400 Message-ID: <000801c6b914$d0110a60$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <005e01c6b912$11a39180$040aa8c0@DGBP7M81> Subject: Re: [Ltru] Delays (was: Re: Charter update proposal) Date: Sat, 5 Aug 2006 21:57:25 -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: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Saturday, August 05, 2006 9:37 PM > Subject: Re: [Ltru] Delays (was: Re: Charter update proposal) ... > I'm glad the matching draft really is in the queue, and this is simply a > matter of the tracker database not being updated. All of the other > delaying factors I mentioned are real and documented. ... What specific changes to the proposed updated charter's milestone dates would you like to see? Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 05:42:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9f96-0003Ex-5a; Sun, 06 Aug 2006 05:42:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9f95-0003Es-Fa for ltru@lists.ietf.org; Sun, 06 Aug 2006 05:42:07 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9f91-00025e-Rm for ltru@lists.ietf.org; Sun, 06 Aug 2006 05:42:07 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k769fxLg004597; Sun, 6 Aug 2006 18:42:00 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 1a84_ce973b78_252f_11db_80d1_0014221fa3c9; Sun, 06 Aug 2006 18:41:59 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k769fhdW012240; Sun, 6 Aug 2006 18:41:50 +0900 Message-Id: <6.0.0.20.2.20060806181832.09dd4c70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 06 Aug 2006 18:21:31 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Charter update proposal In-Reply-To: <44D4AFC6.3FB9@xyzzy.claranet.de> References: <6.0.0.20.2.20060726163255.05cb0cf0@localhost> <000601c6b286$a34cd0c0$9fcd15ac@ds.corp.yahoo.com> <6.0.0.20.2.20060804174746.07f62c90@localhost> <44D3635C.5020902@yahoo-inc.com> <6.0.0.20.2.20060805114558.09dd4580@localhost> <44D4AFC6.3FB9@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 23:48 06/08/05, Frank Ellermann wrote: >Martin Duerst wrote: > >> I don't think it would be appropriate for the WG to finalize >> the new draft and send it to the IESG before we know that >> ISO 639-3 is really approved, because the fact that it is not >> fully approved may mean that there are some more changes, in >> which case we have to go back and make some changes, too. As >> ISO 639-3 is the major reason for our new work, I wouldn't >> call this an "artificial" dependency. > >We also need more procedural experience with the rules as they >are. The idea of the current recharter proposal is to use whatever procedural experience we have, and make whatever adjustments we think are necessary based on this, rather than to wait until we have enough experience so that we can create the final, perfect procedures. Are you trying to say that this should be changed? >State of the art would be "dump review list as complete >failure wrt Suppress-Script". > >If published today 3066ter should be different from 3066bis wrt >list and review management. E.g. we now need a "MUST" for the >expert reviewer to read the rules (s)he's supposed to follow. I don't think we need to discuss specific adjustments to procedures now, because we don't plan to mention them in the charter. Are you disagreeing with this? 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 Sun Aug 06 05:42:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9f9B-0003Im-9k; Sun, 06 Aug 2006 05:42:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9f9A-0003Ih-1F for ltru@ietf.org; Sun, 06 Aug 2006 05:42:12 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9f98-000262-DL for ltru@ietf.org; Sun, 06 Aug 2006 05:42:12 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k769g4Nn007580; Sun, 6 Aug 2006 18:42:04 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 1570_d14b9b20_252f_11db_92fa_0014221f2a2d; Sun, 06 Aug 2006 18:42:04 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k769fhdY012240; Sun, 6 Aug 2006 18:42:02 +0900 Message-Id: <6.0.0.20.2.20060806182327.09defec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 06 Aug 2006 18:35:37 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Delays (was: Re: Charter update proposal) In-Reply-To: <003a01c6b8cb$332fcb80$040aa8c0@DGBP7M81> References: <003a01c6b8cb$332fcb80$040aa8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 05:10 06/08/06, Doug Ewell wrote: >Martin Duerst wrote: > >>> We do. The "means of updating" would probably be some form of new "draft-initial". >> >> Yes. This is worded as "means of updating" on purpose, because it gives us some leeway to choose some other means than an internet-draft if we think an internet draft really doesn't work (e.g. because of the volume). > >This used to worry me simply on the basis of volume -- an I-D like draft-ietf-ltru-initial, containing the entire 3066ter initial registry contents, would be more than 840 pages long. Yes indeed, that's the reason for why we have some leeway in the charter. >After witnessing the extreme delays involved in this process, I'm increasingly concerned about the temporal problem as well. Your point that draft-initial, and it's complement in the new round of drafts, are getting obsoleted in the approval and publication process in a way that doesn't happen for the average internet-draft is well taken. In my opinion, we will have to be more clear in the registry draft about what happens with new code elements that get registered by the ISO registration authority during the approval/publication process. But I don't think anything about this needs to be said explicitly in the charter. One thing I'm wondering about is the expected number of updates to the ISO 639-3 registry. One theory would be that 639-3 is already so comprehensive that updates will be very rare. Another theory is that updates will be proportional to the number of code elements registered, at a rate similar to 639-2. Peter, others, any idea which theory might be better? >IESG approved the matching draft on July 6, but it took 18 days to send the announcement. Another 12 days have gone by and the matching draft still has not entered the RFC Editor queue. What is the reason for the delay this time? How long can we expect it to go on? I have noted myself that it's not yet listed as "In State: RFC Ed Queue" in the IETF tracker, although it's already in the RFC Editor Queue. I'll find out who's fault that is. >Whether it's written into the charter or not, the WG will need to consider the impact of unexpected, protracted delays on each of its activities, and will need to act accordingly to avoid degrading the value and credibility of its deliverables. Agreed. I think this applies to any WG, but to this in particular. 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 Sun Aug 06 06:05:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9fVD-0007vo-KK; Sun, 06 Aug 2006 06:04:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9fVC-0007sd-01 for ltru@ietf.org; Sun, 06 Aug 2006 06:04:58 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9fV9-0006hG-OO for ltru@ietf.org; Sun, 06 Aug 2006 06:04:57 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1G9fV7-0004sM-PO; Sun, 06 Aug 2006 06:04:53 -0400 Date: Sun, 6 Aug 2006 06:04:53 -0400 To: Martin Duerst Subject: Re: [Ltru] Delays (was: Re: Charter update proposal) Message-ID: <20060806100453.GB1367@ccil.org> References: <003a01c6b8cb$332fcb80$040aa8c0@DGBP7M81> <6.0.0.20.2.20060806182327.09defec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20060806182327.09defec0@localhost> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Martin Duerst scripsit: > One thing I'm wondering about is the expected number of updates to > the ISO 639-3 registry. One theory would be that 639-3 is already > so comprehensive that updates will be very rare. Another theory is > that updates will be proportional to the number of code elements > registered, at a rate similar to 639-2. Peter, others, any idea > which theory might be better? According to http://www.ethnologue.com/ethno_docs/introduction.asp , the 15th (2005) edition of the Ethnologue, on which 639-3 is based, contains 7299 code elements, and has an increase of 103 code elements since the 14th (2000) edition. That is a growth rate of 20 code elements per year, or 0.27%. Essentially all of those are splits -- what the 14th edition called a single language, the 15th edition calls two or more languages based on additional evidence. And according to http://www.loc.gov/standards/iso639-2/codechanges.html , there have been 68 code elements added to 639-2 in the same period, a growth rate of 2.9%. So I'd say that it's unlikely that updates will be proportional to the number of code elements. -- John Cowan cowan@ccil.org http://ccil.org/~cowan You cannot enter here. Go back to the abyss prepared for you! Go back! Fall into the nothingness that awaits you and your Master. Go! --Gandalf _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 07:45:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9h49-00066l-7K; Sun, 06 Aug 2006 07:45:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9h47-00066f-NQ for ltru@lists.ietf.org; Sun, 06 Aug 2006 07:45:07 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9h46-0006DK-Da for ltru@lists.ietf.org; Sun, 06 Aug 2006 07:45:07 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G9h3x-0006pL-Ll for ltru@lists.ietf.org; Sun, 06 Aug 2006 13:44:57 +0200 Received: from pd9fba8f3.dip0.t-ipconnect.de ([217.251.168.243]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Aug 2006 13:44:57 +0200 Received: from nobody by pd9fba8f3.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Aug 2006 13:44:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 06 Aug 2006 13:44:09 +0200 Organization: Lines: 25 Message-ID: <44D5D609.4E2D@xyzzy.claranet.de> References: <6.0.0.20.2.20060726163255.05cb0cf0@localhost> <000601c6b286$a34cd0c0$9fcd15ac@ds.corp.yahoo.com> <6.0.0.20.2.20060804174746.07f62c90@localhost> <44D3635C.5020902@yahoo-inc.com> <6.0.0.20.2.20060805114558.09dd4580@localhost> <44D4AFC6.3FB9@xyzzy.claranet.de> <6.0.0.20.2.20060806181832.09dd4c70@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8f3.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ltru] Re: Charter update proposal X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >> We also need more procedural experience with the rules as >> they are. > The idea of the current recharter proposal is to use whatever > procedural experience we have, and make whatever adjustments > we think are necessary based on this, rather than to wait > until we have enough experience so that we can create the > final, perfect procedures. Are you trying to say that this > should be changed? If there will be some months with pure 3066bis rules (after it got its number), and no doubt about it, that will be good enough to see how it works. No 3066ter "last call" this year, let alone before 3066bis got its number. > I don't think we need to discuss specific adjustments to > procedures now, because we don't plan to mention them in > the charter. Are you disagreeing with this? No - just no overzealous milestones and timetable please, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 08:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9i7W-0001n2-Fr; Sun, 06 Aug 2006 08:52:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9i7V-0001mQ-48 for ltru@lists.ietf.org; Sun, 06 Aug 2006 08:52:41 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9i7T-00023N-PO for ltru@lists.ietf.org; Sun, 06 Aug 2006 08:52:41 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G9i7M-0002H0-0H for ltru@lists.ietf.org; Sun, 06 Aug 2006 14:52:32 +0200 Received: from pd9fba8f3.dip0.t-ipconnect.de ([217.251.168.243]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Aug 2006 14:52:31 +0200 Received: from nobody by pd9fba8f3.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Aug 2006 14:52:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 06 Aug 2006 14:51:00 +0200 Organization: Lines: 33 Message-ID: <44D5E5B4.18F3@xyzzy.claranet.de> References: <003a01c6b8cb$332fcb80$040aa8c0@DGBP7M81> <6.0.0.20.2.20060806182327.09defec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8f3.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Ltru] Re: Delays X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > One theory would be that 639-3 is already so comprehensive > that updates will be very rare. It comes without Suppress-Scripts. If the review list is unable to deal with this issue it has to be prepared by the WG for 639-3 languages where that's possible (= "obvious"). That might be a point for the updated Charter. > I have noted myself that it's not yet listed as "In State: > RFC Ed Queue" in the IETF tracker, although it's already in > the RFC Editor Queue. I'll find out who's fault that is. http://rtg.ietf.org/~fenner/ietf/rfc/hist.cgi?draft=draft-ietf-ltru-matching says it entered the queue at 2006-07-24 after one day in limbo. In theory a third party like the W3C could ask the IESG to accelerate the publication of BCP 47, because they want to fix their references in say XHTML modularization 1.1. I think it was our fault when we didn't see the implications of an RFC editor note causing a "blocked waiting for 'matching'" - the German word for this could be "Sollbruchstelle". The history tool shows this as "20060725 was in REF-EXT since 20060119 (187 days)" or as "20060726 was in MISSREF*R since 20060120 (187 days)". Before that it took 43 days to create the new IANA registry. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 10:41:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9jog-0004SU-BY; Sun, 06 Aug 2006 10:41:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9jof-0004NO-2F for ltru@ietf.org; Sun, 06 Aug 2006 10:41:21 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9jod-0003dj-Ju for ltru@ietf.org; Sun, 06 Aug 2006 10:41:21 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1G9jod-00016d-6M; Sun, 06 Aug 2006 10:41:19 -0400 Date: Sun, 6 Aug 2006 10:41:19 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: Charter update proposal Message-ID: <20060806144119.GC1367@ccil.org> References: <6.0.0.20.2.20060726163255.05cb0cf0@localhost> <000601c6b286$a34cd0c0$9fcd15ac@ds.corp.yahoo.com> <6.0.0.20.2.20060804174746.07f62c90@localhost> <44D3635C.5020902@yahoo-inc.com> <6.0.0.20.2.20060805114558.09dd4580@localhost> <44D4AFC6.3FB9@xyzzy.claranet.de> <6.0.0.20.2.20060806181832.09dd4c70@localhost> <44D5D609.4E2D@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D5D609.4E2D@xyzzy.claranet.de> 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 Frank Ellermann scripsit: > No 3066ter "last call" this year, let alone before 3066bis got its > number. I hope you are right, but how do you know? Perhaps our stuff will still be hanging in the RFC Editor queue in 2008. -- Verbogeny is one of the pleasurettes John Cowan of a creatific thinkerizer. http://www.ccil.org/~cowan -- Peter da Silva _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 11:00:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9k6l-0006Ps-P9; Sun, 06 Aug 2006 11:00:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9k6l-0006Pn-4A for ltru@ietf.org; Sun, 06 Aug 2006 11:00:03 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9k6j-0006RE-TC for ltru@ietf.org; Sun, 06 Aug 2006 11:00:03 -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 <20060806145955.KWTR14422.mta11.adelphia.net@DGBP7M81> for ; Sun, 6 Aug 2006 10:59:55 -0400 Message-ID: <000d01c6b968$f786c5e0$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sun, 6 Aug 2006 07:59:49 -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: 93238566e09e6e262849b4f805833007 Subject: [Ltru] Re: Delays (was: Re: Charter update proposal) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy Presuhn wrote: > What specific changes to the proposed updated charter's milestone > dates would you like to see? I'm not asking for any change in the milestone dates, and I'm surprised you read my comments that way. We could move the deadlines out a year and there would still be the possibility of missing them due to unforeseen delays. What I would like to see is some sort of contingency planning to defend against delays. An 840-page I-D would likely invite a great deal of scrutiny, of necessity time-consuming, to ensure its accuracy. There may be other delaying factors, and errors may be found that need to be corrected. If the contents change during this time, we should have a way to incorporate the changes without restarting the review cycle for the entire 840 pages. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 11:04:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kAd-0008DW-Ez; Sun, 06 Aug 2006 11:04:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kAd-0008DR-7N for ltru@ietf.org; Sun, 06 Aug 2006 11:04:03 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9kAc-0006ok-0i for ltru@ietf.org; Sun, 06 Aug 2006 11:04:03 -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 <20060806150401.KZLT14422.mta11.adelphia.net@DGBP7M81>; Sun, 6 Aug 2006 11:04:01 -0400 Message-ID: <001301c6b969$8b005fc0$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" , Date: Sun, 6 Aug 2006 08:03:54 -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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Ltru] Away X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I will be out of town and away from e-mail until Thursday 2006-08-10, about 4 pm Pacific Time (23:00 UTC). -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 11:16:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kMh-0006tq-Ph; Sun, 06 Aug 2006 11:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kMg-0006sC-GX for ltru@lists.ietf.org; Sun, 06 Aug 2006 11:16:30 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9kMf-0008Gp-74 for ltru@lists.ietf.org; Sun, 06 Aug 2006 11:16:30 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G9kMX-0006nO-1n for ltru@lists.ietf.org; Sun, 06 Aug 2006 17:16:21 +0200 Received: from pd9fba8f3.dip0.t-ipconnect.de ([217.251.168.243]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Aug 2006 17:16:21 +0200 Received: from nobody by pd9fba8f3.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Aug 2006 17:16:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 06 Aug 2006 17:15:19 +0200 Organization: Lines: 22 Message-ID: <44D60787.85B@xyzzy.claranet.de> References: <6.0.0.20.2.20060726163255.05cb0cf0@localhost> <000601c6b286$a34cd0c0$9fcd15ac@ds.corp.yahoo.com> <6.0.0.20.2.20060804174746.07f62c90@localhost> <44D3635C.5020902@yahoo-inc.com> <6.0.0.20.2.20060805114558.09dd4580@localhost> <44D4AFC6.3FB9@xyzzy.claranet.de> <6.0.0.20.2.20060806181832.09dd4c70@localhost> <44D5D609.4E2D@xyzzy.claranet.de> <20060806144119.GC1367@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8f3.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Re: Charter update proposal X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > I hope you are right, but how do you know? IIRC Bill published statistics, and the average time in the queue was about / almost six months. Including cases where RFCs are blocked (= normative references not yet available), or authors MIA. > Perhaps our stuff will still be hanging in the RFC Editor > queue in 2008. Looking at it from the other side it's "unblocked" for less than 14 days. Addison, Doug, and Mark are ready if they get their AUTH48 info, no "interesting" pending issues, one typo covered by an RFC editor note. I hope that it gets its number before its first "birthday" (approval of initial + registry). Together with matching. But of course my crystal ball isn't better than yours... :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 11:24:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kUd-0002kY-Vt; Sun, 06 Aug 2006 11:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kUd-0002kT-Im for ltru@ietf.org; Sun, 06 Aug 2006 11:24:43 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9kUc-0000vf-CO for ltru@ietf.org; Sun, 06 Aug 2006 11:24:43 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1G9kUc-0002Kg-0u; Sun, 06 Aug 2006 11:24:42 -0400 Date: Sun, 6 Aug 2006 11:24:41 -0400 To: Frank Ellermann Subject: Re: [Ltru] Re: Delays Message-ID: <20060806152441.GA8155@ccil.org> References: <003a01c6b8cb$332fcb80$040aa8c0@DGBP7M81> <6.0.0.20.2.20060806182327.09defec0@localhost> <44D5E5B4.18F3@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D5E5B4.18F3@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > It comes without Suppress-Scripts. If the review list is > unable to deal with this issue it has to be prepared by the > WG for 639-3 languages where that's possible (= "obvious"). The argument for Suppress-Script was a backward compatibility one: that new documents labeled en-Latn-US would not be matched by old matchers against an en-US pattern. That does not apply to the new tags in 639-3, as none of them have ever been valid before. -- My corporate data's a mess! John Cowan It's all semi-structured, no less. http://www.ccil.org/~cowan But I'll be carefree cowan@ccil.org Using XSLT On an XML DBMS. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 11:45:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kpB-0006kv-5f; Sun, 06 Aug 2006 11:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kp9-0006kf-4v for ltru@lists.ietf.org; Sun, 06 Aug 2006 11:45:55 -0400 Received: from mail2.sharplabs.com ([216.65.151.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9kp7-0003Hc-Qo for ltru@lists.ietf.org; Sun, 06 Aug 2006 11:45:55 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by mail2.sharplabs.com (Postfix) with ESMTP id 20D921E14B2; Sun, 6 Aug 2006 08:45:53 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sun, 6 Aug 2006 08:45:53 -0700 Message-ID: <789E617C880666438EDEE30C2A3E8D10EEB0@mailsrvnt05.enet.sharplabs.com> From: "McDonald, Ira" To: 'Frank Ellermann' , ltru@lists.ietf.org Subject: RE: [Ltru] Re: Charter update proposal Date: Sun, 6 Aug 2006 08:45:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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, The statistic I saw awhile back (on another IETF list) was that the average RFC took six months to pass through the IETF AD review and IESG last call alone. The average RFC still spends more than a year in the RFC Editor's queue, unless you do some very dubious statistical manipulations. The IETF standards process has broken down badly. Cheers, - Ira PS - With no references or other issues, Printer MIB v2 (RFC 3805) took well over two years to pass through IETF AD review, IESG 'last call', and RFC Editor. 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: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: Sunday, August 06, 2006 11:15 AM > To: ltru@lists.ietf.org > Subject: [Ltru] Re: Charter update proposal > > > John Cowan wrote: > > > I hope you are right, but how do you know? > > IIRC Bill published statistics, and the average time in the > queue was about / almost six months. Including cases where > RFCs are blocked (= normative references not yet available), > or authors MIA. > > > Perhaps our stuff will still be hanging in the RFC Editor > > queue in 2008. > > Looking at it from the other side it's "unblocked" for less > than 14 days. Addison, Doug, and Mark are ready if they get > their AUTH48 info, no "interesting" pending issues, one typo > covered by an RFC editor note. > > I hope that it gets its number before its first "birthday" > (approval of initial + registry). Together with matching. > > But of course my crystal ball isn't better than yours... :-) > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.7/410 - Release Date: 8/5/2006 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 11:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kti-0000c5-PE; Sun, 06 Aug 2006 11:50:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kth-0000bx-IY for ltru@ietf.org; Sun, 06 Aug 2006 11:50:37 -0400 Received: from mail2.microsoft.com ([131.107.1.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9ktg-0004Bi-81 for ltru@ietf.org; Sun, 06 Aug 2006 11:50:37 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Aug 2006 08:50:35 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Aug 2006 08:50:35 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Delays (was: Re: Charter update proposal) Date: Sun, 6 Aug 2006 08:50:28 -0700 Message-ID: In-Reply-To: <6.0.0.20.2.20060806182327.09defec0@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Delays (was: Re: Charter update proposal) Thread-Index: Aca5PJmVDI+WoZ4KRreTgwoMcG10zQAMk5Xg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 06 Aug 2006 15:50:35.0531 (UTC) FILETIME=[0E605DB0:01C6B970] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > One thing I'm wondering about is the expected number of updates to > the ISO 639-3 registry. One theory would be that 639-3 is already > so comprehensive that updates will be very rare. Another theory is > that updates will be proportional to the number of code elements > registered, at a rate similar to 639-2. Peter, others, any idea > which theory might be better? I'd go with the proportionality theory: I expect there will be = proportionally more cases in which usage is changing, for which = perceptions are changing, or for which our knowledge is evolving. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 11:54:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kxh-00035k-5r; Sun, 06 Aug 2006 11:54:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9kxg-00035f-0D for ltru@ietf.org; Sun, 06 Aug 2006 11:54:44 -0400 Received: from mail3.microsoft.com ([131.107.1.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9kxe-0005Wt-Nx for ltru@ietf.org; Sun, 06 Aug 2006 11:54:43 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Sun, 6 Aug 2006 08:54:42 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Aug 2006 08:54:41 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Delays (was: Re: Charter update proposal) Date: Sun, 6 Aug 2006 08:54:34 -0700 Message-ID: In-Reply-To: <20060806100453.GB1367@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Delays (was: Re: Charter update proposal) Thread-Index: Aca5P8jR4fmdmpqKQ6yS6iLJh2r/MQAMFcmA From: "Peter Constable" To: X-OriginalArrivalTime: 06 Aug 2006 15:54:41.0982 (UTC) FILETIME=[A145CDE0:01C6B970] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: John Cowan [mailto:cowan@ccil.org] > And according to = http://www.loc.gov/standards/iso639-2/codechanges.html , > there have been 68 code elements added to 639-2 in the same period, > a growth rate of 2.9%. So I'd say that it's unlikely that updates = will > be proportional to the number of code elements. OK, I just wrote that I'd expect a proportional increase, but I forgot = about one factor: there have been a lot of changes in 639-2 precisely = because it was a limited list that has been missing things that people = needed, and that is *far* less likely to be the case for 639-3. I'd still expect some increase in the number of annual changes, but I = guess not an order-of-magnitude increase -- i.e. not proportionally = greater. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 13:38:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9maB-0003HW-O5; Sun, 06 Aug 2006 13:38:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9maA-0003HM-IS for ltru@lists.ietf.org; Sun, 06 Aug 2006 13:38:34 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9ma9-0008FO-9G for ltru@lists.ietf.org; Sun, 06 Aug 2006 13:38:34 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G9ma5-0005PT-VB for ltru@lists.ietf.org; Sun, 06 Aug 2006 19:38:29 +0200 Received: from pd9fba8f3.dip0.t-ipconnect.de ([217.251.168.243]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Aug 2006 19:38:29 +0200 Received: from nobody by pd9fba8f3.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 06 Aug 2006 19:38:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Sun, 06 Aug 2006 19:37:21 +0200 Organization: Lines: 18 Message-ID: <44D628D1.5E86@xyzzy.claranet.de> References: <003a01c6b8cb$332fcb80$040aa8c0@DGBP7M81> <6.0.0.20.2.20060806182327.09defec0@localhost> <44D5E5B4.18F3@xyzzy.claranet.de> <20060806152441.GA8155@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8f3.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Scripts (was: Delays) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > new documents labeled en-Latn-US would not be matched by old > matchers against an en-US pattern. That does not apply to > the new tags in 639-3, as none of them have ever been valid > before. Old applications should have no problems with any new language plus region or similar tags, but for extlangs and scripts they might behave oddly. In one case a new language subtag got a Suppress-Script, ngo (2006-06-05) has Nkoo, That's how I'd expect it to work for new language tags (the seven added 2006 excl. zxx), and there are several old language tags with missing Suppress-Scripts. Bye, Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 14:22:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9nGx-0002Dq-9z; Sun, 06 Aug 2006 14:22:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9nGv-0002Dl-GO for ltru@ietf.org; Sun, 06 Aug 2006 14:22:45 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9nGu-0007Kt-6I for ltru@ietf.org; Sun, 06 Aug 2006 14:22:45 -0400 Received: from [10.72.72.111] (snvvpn1-10-72-72-c111.corp.yahoo.com [10.72.72.111]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k76IMXsJ013660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Aug 2006 11:22:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=UYMRh94Bab5bkcHjepcUHRexRbkDhoYfJgvpat5NaFcWkH+ucyYDxO7dbVsnD/D1 Message-ID: <44D63368.3070003@yahoo-inc.com> Date: Sun, 06 Aug 2006 11:22:32 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: Delays References: <000d01c6b968$f786c5e0$040aa8c0@DGBP7M81> In-Reply-To: <000d01c6b968$f786c5e0$040aa8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 > An 840-page I-D would likely invite a great deal of > scrutiny, of necessity time-consuming, to ensure its accuracy. An 840 page I-D whose contents are deleted prior to publication (if we use the same pattern as draft-initial). One of the more interesting absurdities of recent memory. Personally I would favor an I-D with a link in it pointing IANA to the addition. All of which is pointless to discuss just now. Martin's text merely says that we come up with a way to update the registry. I think we can do that within the timeframe provided. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 14:35:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9nTJ-0001z0-H3; Sun, 06 Aug 2006 14:35:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9nTI-0001yq-EP for ltru@lists.ietf.org; Sun, 06 Aug 2006 14:35:32 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9nTH-0001zu-8B for ltru@lists.ietf.org; Sun, 06 Aug 2006 14:35:32 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1G9nTG-0007KW-OR; Sun, 06 Aug 2006 14:35:30 -0400 Date: Sun, 6 Aug 2006 14:35:30 -0400 To: Frank Ellermann Subject: Re: [Ltru] Scripts (was: Delays) Message-ID: <20060806183530.GA27960@ccil.org> References: <003a01c6b8cb$332fcb80$040aa8c0@DGBP7M81> <6.0.0.20.2.20060806182327.09defec0@localhost> <44D5E5B4.18F3@xyzzy.claranet.de> <20060806152441.GA8155@ccil.org> <44D628D1.5E86@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D628D1.5E86@xyzzy.claranet.de> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Frank Ellermann scripsit: > In one case a new language subtag got a Suppress-Script, ngo > (2006-06-05) has Nkoo. Quite so, but it's not a requirement. > That's how I'd expect it to work for > new language tags (the seven added 2006 excl. zxx), and there > are several old language tags with missing Suppress-Scripts. So there are. ietf-languages should take that up. -- John Cowan http://ccil.org/~cowan cowan@ccil.org In might the Feanorians / that swore the unforgotten oath brought war into Arvernien / with burning and with broken troth. and Elwing from her fastness dim / then cast her in the waters wide, but like a mew was swiftly borne, / uplifted o'er the roaring tide. --the Earendillinwe _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 06 22:19:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9uiI-0005vC-EV; Sun, 06 Aug 2006 22:19:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G9uiH-0005uz-TI for ltru@ietf.org; Sun, 06 Aug 2006 22:19:29 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9uiE-00036U-7B for ltru@ietf.org; Sun, 06 Aug 2006 22:19:29 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k772JNgG002097 for ; Mon, 7 Aug 2006 11:19:23 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 1990_241b58c8_25bb_11db_974c_0014221fa3c9; Mon, 07 Aug 2006 11:19:23 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k772JJLW027217 for ; Mon, 7 Aug 2006 11:19:23 +0900 Message-Id: <6.0.0.20.2.20060807111529.07fb17b0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 07 Aug 2006 11:18:14 +0900 To: LTRU Working Group From: Martin Duerst Subject: Re: [Ltru] Charter update proposal (updated) In-Reply-To: <6.0.0.20.2.20060804144524.07f52660@localhost> References: <6.0.0.20.2.20060804144524.07f52660@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org After looking at the comments I have received for the update to the recharter draft, I decided to forward this to Ted Hardie, our Area Director. Just in case you find anything else that you think really needs to be fixed, please feel free to write to the WG list, to the chairs or to the AD, or to comment on the IETF list when this recharter comes up there. Regards, Martin. At 18:24 06/08/04, Martin Duerst wrote: >Dear LTRU WG, > >Below please find an updated proposal for our charter update >(rechartering). Details of changes are discussed in responses >to the commenters. The main change is the addition of a paragraph >discussing signed languages, transliterations, transcriptions, >and 639-6. > >I look forward to send our proposal for rechartering to >Ted Hardie (Area Director) within the next few days. But >in case you find any additional problems in the current >draft charter, please tell me (and the WG). > >Regards, Martin. > >------------------------------------------------------------- > >Description of the Working Group: > >The primary language subtags allowed by the current IANA Language >Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same >way as they were limited by RFC 3066. This covers approximately 500 >possible language subtags. ISO 639-3, scheduled for approval towards >the end of 2006, will make available around 7000 more code elements >for identifying languages. > >The working group will prepare an update to the Language Subtag >Registry procedures to allow the use of 3-letter code elements >from ISO 639-3 as primary language subtags or extended language >subtags as appropriate. The working group will also deliver means >to update the current IANA Language Subtag Registry with the newly >available subtags. > >The working group will examine, and if necessary clarify or adjust, >procedures and guidelines with respect to extended language subtags >and variant subtags. Use cases include the identification of >signed languages, transliterations, and transcriptions. >The working group will also consider how the draft work on >ISO 639-6 may relate to the future development of language tags. > >The working group will clarify text where necessary. It may also >make adjustments to the registration process and the form of the >registry if this is deemed appropriate based on ongoing registration >and operational experience. These adjustments and clarifications >are not expected to delay the progress of the work. > >Work on the drafts is planned to start before ISO 639-3 is fully >approved and published. However, the WG will not finalize the >drafts before ISO 639-3 is fully approved. > > >Goals and Milestones: > >September 2006 Submit first WG draft of registry procedure update >September 2006 Submit first WG draft of registry data update > >January 2007 Submit registry procedure update draft for IETF Last Call >January 2007 Submit registry data update draft for IETF Last Call > > >#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University >#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 08 01:27:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAK7v-0000EL-ND; Tue, 08 Aug 2006 01:27:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAK7u-0000BE-MB for ltru@ietf.org; Tue, 08 Aug 2006 01:27:38 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAK7r-0008F9-2S for ltru@ietf.org; Tue, 08 Aug 2006 01:27:38 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k785RTqN001327 for ; Tue, 8 Aug 2006 14:27:29 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 564a_958a2b22_269e_11db_9a29_0014221fa3c9; Tue, 08 Aug 2006 14:27:28 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k785RRsB019146 for ; Tue, 8 Aug 2006 14:27:28 +0900 Message-Id: <6.0.0.20.2.20060808133652.0b314ca0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 08 Aug 2006 13:44:43 +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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ltru] WG meeting at next IETF X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, The next IETF meeting will be held 5-10 November 2006 in San Diego, CA, USA. This is still a long way ahead, but already the scheduling has begun. >Date: Mon, 07 Aug 2006 18:28:08 -0400 >Subject: 67th IETF - Working Group and BoF Scheduling >We will be accepting scheduling requests for all Working Groups and BOFs >starting today, Monday, August 7, 2006. The milestones and deadlines for >scheduling-related activities are as follows: > >-- Cut-off date for requesting a Working Group session and for preliminary BOF >proposals to ADs: Monday, September 18 at 17:00 ET (21:00 UTC/GMT). We do not know yet wether (and when, and how exactly) we will be rechartered. However, we should make sure we can meet in case we think we need to meet and we actually get rechartered. At the present time, my judgement as a technical contributor is that we do not need to meet face-to-face, the same way there was no such need in the past. As a chair, I would like to make sure that we as for the necessary meeting slot if we think a direct meeting might be necessary. Please provide your input on whether you think a face-to-face meeting will be necessary or not. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 08 11:37:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATdx-0006qq-NV; Tue, 08 Aug 2006 11:37:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GATdx-0006ql-7m for ltru@ietf.org; Tue, 08 Aug 2006 11:37:21 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GATdt-0001SA-Qg for ltru@ietf.org; Tue, 08 Aug 2006 11:37:21 -0400 Received: from [10.72.76.15] (snvvpn2-10-72-76-c15.corp.yahoo.com [10.72.76.15]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k78Fb7is017383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Aug 2006 08:37:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=FJsuOMZv+5Hp4MVzxz2geQfl7oIroT+J2fEYyr6d4zd5b0zr0Cw0KfnNHu44yWow Message-ID: <44D8AFA2.4070400@yahoo-inc.com> Date: Tue, 08 Aug 2006 08:37:06 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] WG meeting at next IETF References: <6.0.0.20.2.20060808133652.0b314ca0@localhost> In-Reply-To: <6.0.0.20.2.20060808133652.0b314ca0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 don't think facetime will be necessary at the IETF meeting. Addison Martin Duerst wrote: > Dear WG, > > The next IETF meeting will be held 5-10 November 2006 in San Diego, CA, USA. > This is still a long way ahead, but already the scheduling has begun. > >> Date: Mon, 07 Aug 2006 18:28:08 -0400 >> Subject: 67th IETF - Working Group and BoF Scheduling > >> We will be accepting scheduling requests for all Working Groups and BOFs >> starting today, Monday, August 7, 2006. The milestones and deadlines for >> scheduling-related activities are as follows: >> >> -- Cut-off date for requesting a Working Group session and for preliminary BOF >> proposals to ADs: Monday, September 18 at 17:00 ET (21:00 UTC/GMT). > > We do not know yet wether (and when, and how exactly) we will be rechartered. > However, we should make sure we can meet in case we think we need to meet > and we actually get rechartered. > > At the present time, my judgement as a technical contributor is that we > do not need to meet face-to-face, the same way there was no such need > in the past. > > As a chair, I would like to make sure that we as for the necessary meeting > slot if we think a direct meeting might be necessary. > > Please provide your input on whether you think a face-to-face > meeting will be necessary or not. > > > 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 -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 10 18:14:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBInA-0002TL-JD; Thu, 10 Aug 2006 18:14:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GBIn8-0002TB-MC for ltru@ietf.org; Thu, 10 Aug 2006 18:14:14 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBIn6-0001dP-Eo for ltru@ietf.org; Thu, 10 Aug 2006 18:14:14 -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 <20060810221411.GXLA28299.mta11.adelphia.net@DGBP7M81> for ; Thu, 10 Aug 2006 18:14:11 -0400 Message-ID: <009e01c6bcca$4d6777c0$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Thu, 10 Aug 2006 15:14:07 -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: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ltru] Re: WG meeting at next IETF X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > The next IETF meeting will be held 5-10 November 2006 in San Diego, > CA, USA. This is still a long way ahead, but already the scheduling > has begun. > >> Date: Mon, 07 Aug 2006 18:28:08 -0400 >> Subject: 67th IETF - Working Group and BoF Scheduling > ... > At the present time, my judgement as a technical contributor is that > we do not need to meet face-to-face, the same way there was no such > need in the past. I agree with Martin (and Addison) that we probably do not need to meet face to face. That said, if a meeting were deemed necessary, I could probably make it. San Diego isn't all that far away. -- 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 Aug 17 02:18:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDbCT-0003J1-7i; Thu, 17 Aug 2006 02:17:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDbCQ-0003Hx-BH for ltru@ietf.org; Thu, 17 Aug 2006 02:17:50 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDbCP-0003iT-3R for ltru@ietf.org; Thu, 17 Aug 2006 02:17:50 -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 <20060817061748.JDKR28299.mta11.adelphia.net@DGBP7M81> for ; Thu, 17 Aug 2006 02:17:48 -0400 Message-ID: <006501c6c1c4$d1898800$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Charter update proposal (updated) Date: Wed, 16 Aug 2006 23:17:28 -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.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 Monday, August 7, Martin Duerst wrote: > After looking at the comments I have received for the update to the > recharter draft, I decided to forward this to Ted Hardie, our Area > Director. Just in case you find anything else that you think really > needs to be fixed, please feel free to write to the WG list, to the > chairs or to the AD, or to comment on the IETF list when this > recharter comes up there. What is the current status of this? There haven't been any public comments on the proposed charter, on either this list or the main IETF discussion list. Randy asked me earlier if I wanted to propose any changes to the target dates, and I didn't at the time. However, I note that the proposed charter calls for WG first drafts in September. We can't write those drafts without group discussions, and we can't really hold those discussions until the charter is approved. The end of September is only six weeks away. -- 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 Aug 17 12:41:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDkvm-0000V5-Ri; Thu, 17 Aug 2006 12:41:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GDkvl-0000V0-T8 for ltru@ietf.org; Thu, 17 Aug 2006 12:41:17 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDkvk-00011k-9J for ltru@ietf.org; Thu, 17 Aug 2006 12:41:17 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7HGf7Dr009786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Aug 2006 09:41:08 -0700 Received: from [70.221.249.247] (vpn-10-50-0-38.qualcomm.com [10.50.0.38]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7HGf1OJ017332; Thu, 17 Aug 2006 09:41:04 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <006501c6c1c4$d1898800$040aa8c0@DGBP7M81> References: <006501c6c1c4$d1898800$040aa8c0@DGBP7M81> Date: Thu, 17 Aug 2006 09:40:58 -0700 To: "Doug Ewell" , "LTRU Working Group" From: Ted Hardie Subject: Re: [Ltru] Charter update proposal (updated) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 11:17 PM -0700 8/16/06, Doug Ewell wrote: >On Monday, August 7, Martin Duerst wrote: > >>After looking at the comments I have received for the update to the recharter draft, I decided to forward this to Ted Hardie, our Area Director. Just in case you find anything else that you think really needs to be fixed, please feel free to write to the WG list, to the chairs or to the AD, or to comment on the IETF list when this recharter comes up there. > >What is the current status of this? There haven't been any public comments on the proposed charter, on either this list or the main IETF discussion list. The IESG agreed on today's telechat to send the proposed charter for public comments; it will return to the IESG agenda to consider those comments in two weeks. Document authors who are interested in proposing documents can certainly put them forward as individual submissions in advance of the charter being approved. One of those could then be adopted as the basis for future work and moved to draft-ietf-ltru at that point. regards, Ted Hardie _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 19 04:01:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GELlC-0006jM-24; Sat, 19 Aug 2006 04:00:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GELlB-0006jE-A1; Sat, 19 Aug 2006 04:00:49 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GELl8-0008Oe-I4; Sat, 19 Aug 2006 04:00:49 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k7J80XVV010771; Sat, 19 Aug 2006 17:00:33 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 7d11_ca2f5b3c_2f58_11db_8b57_0014221f2a2d; Sat, 19 Aug 2006 17:00:32 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7J80QRA004889; Sat, 19 Aug 2006 17:00:29 +0900 Message-Id: <6.0.0.20.2.20060818150743.097d4ec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 18 Aug 2006 16:30:51 +0900 To: Alexey Melnikov , ima@ietf.org From: Martin Duerst In-Reply-To: <44E09667.8070704@isode.com> References: <44E09667.8070704@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: LTRU Working Group Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 Alexey, I have looked at the draft. I'm not totally familiar with all the details of email transmission, but will comment mostly from an LTRU perspective. I have cc'ed the LTRU WG, because I think your draft makes a good usage example for the work of the LTRU WG, and some people may be able to provide more feedback. At 00:27 06/08/15, Alexey Melnikov wrote: > Title : SMTP Language Extension > Author(s) : M. Gahrns, A. Melnikov This list of authors and the one in the draft seem to be out of sync, probably a clerical error? > Filename : draft-melnikov-smtp-lang-05.txt > Pages : 0 This seems to be some administrative error, too, probably a tool that counts drafts without explicit page breaks as 0 pages (I'd understand 1 page, 0 is really weird). > Date : 2006-8-2 Section 3: "It also recommends that server recognizes languges that have multiple different tags (for example "ru" and "rus")." This is a bad idea. RFC 3066, and its successor RFC 3066bis (draft-ietf-ltru-registry-14.txt, approved by the IESG and in operation) both make it very clear that for languages that have both two-letter and three-letter codes, only the two-letter codes are used. Please update the reference to RFC 3066 to RFC3066bis. For language fallback, I suggest you have a look at http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-15.txt (also IESG-approved). This gives you the (basic) "language-range" ABNF construct that includes the "*" wildcard. Also, it seems that the matching going on on the server when the client issues a LANG command (e.g. in Example 5) is very close to and can (and should) be described in terms of Section 3.4, Lookup, of the above draft. The only difference I see is that Section 3.4 requires a solution (maybe default) in all cases, whereas in your case, the default if no matching language is found is not i-default, but "no change" or in other words, "previously selected language". I think the discussion of mul and und is overkill. There is no interoperability problem if the client uses 'mul', it is just a language that's not supported. Suggesting, as in Example 2, that the server has specific code for that issue is a bad idea, it will tend to make the server more complex than necessary. Somewhere in example 1, probably in the comment that starts with "< Once the client changes...", you should say that the example here doesn't show accents because they cannot be represented in this format, but that accented characters, encoded in UTF-8, would be present in the actual protocol exchange. Note 1: This is in part overkill, and in part incorrect. If you do fallback on the server, then you have to leave the decision to the server (or the server programmer or administrator). There is no a-priori difference between the special prefixes i- and x- and two-letter and three- letter prefixes. It's very well possible that for i-foo-bar and i-foo-baz, there is a mutually intellegible i-foo on the server. The server will most probably only have i-foo if the mutual intellegibility is a reasonal assumption. On the other hand, for some people, zh-Hans (Chinese written in simplifed script) and zh-Hant (Chinese written in traditional script) are not mutually intellegible, and so it may be a bad idea to make "zh" available on the server. I think that if you refer to the abovementioned two drafts, that should be enough. Aside: You could get rid of server-side fallbacks if you could assume that the server can always send the complete list of available languages. However, I think this would be a bad idea, because a) there may be dozenz or hundreds of languages, and just sending the list may present somewhat of a scalability problem, and b) it may be much easier computationally for the server to check for the existence of a requested language (or it's fallback) than to list all languages available (which may require an extensive search for files in a large number of directories). For the LANG command, you only allow one language. You could extend that to use a language priority list, but this is not really necessary, the client can simulate a language priority list by using successive requests until one of them is successful. On the other hand, for the LANG parameter for the MAIL command should allow a language priority list. The reason for this is that (if my understanding is correct), this parameter is passed on along the relay chain of SMTP servers, and is supposed to go back to the original sender, and using a list increases the chance that there is something at the relevant server that can be understood by the originator. I'm also not completely clear on / happy with the following paragraph: >>>> If the message is relayed to another SMTP server that supports LANGUAGE ESMTP extension, the MTA acting as the client MUST check if the receiving MTA lists the language specified in lang-param ("requested language") in the list of supported language tags in LANGUAGE EHLO response. If the receiving MTA either lists the requested language or doesn't list any language tag (i.e. the receiving MTA is unable to list languages it supports) the sender MUST issue LANG command for the requested language. After that, regardless of the result of LANG command, the client MTA MUST specify LANG parameter in MAIL command. >>>> After repeated reading, I think this is okay, but some clarification might help. In particular, it should be pointed out that trying to use the LANG command is done so that potential error messages in this relay step can be sent back to the original sender in the appropriate language if possible. Also, on a first reading, I was thinking that if the desired language wasn't available, the LANG parameter would no longer be used. I think the reason for this misunderstanding is that the last two lines come very late. I think it would be easier to understand if the paragraph started out as follows: If the message is relayed to another SMTP server that supports the LANGUAGE ESMTP extension, the MTA acting as the client MUST do the following two things, in the following order: 1) Attempt to set the language of server responses to the requested language(s). 2) Independently of whether 1) is successful, use the LANG parameter on the MAIL command to transmit the requested language(s) to the next relay. If you think more explanations and details for 1) are needed, they should come after this list. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 19 14:17:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEVNf-0007Pm-S3; Sat, 19 Aug 2006 14:17:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GEVNe-0007PV-DX for ltru@ietf.org; Sat, 19 Aug 2006 14:17:10 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEVNd-0001G0-4s for ltru@ietf.org; Sat, 19 Aug 2006 14:17:10 -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 <20060819181704.EOZX14558.mta9.adelphia.net@DGBP7M81>; Sat, 19 Aug 2006 14:17:04 -0400 Message-ID: <004801c6c3bb$a92d3250$040aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 19 Aug 2006 11:16:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: alexey.melnikov@isode.com Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > Section 3: "It also recommends that server recognizes languges that > have multiple different tags (for example "ru" and "rus")." > > This is a bad idea. RFC 3066, and its successor RFC 3066bis > (draft-ietf-ltru-registry-14.txt, approved by the IESG and in > operation) both make it very clear that for languages that > have both two-letter and three-letter codes, only the two-letter > codes are used. > > Please update the reference to RFC 3066 to RFC3066bis. In fact, if you update the reference to RFC 3066bis, your references to ISO 639-1 and ISO 639-2 (e.g. in Example 3 or Section 3) should be replaced by references to the IANA Language Subtag Registry: http://www.iana.org/assignments/language-subtag-registry This contains all valid subtags that can be used to generate a language tag according to the rules of RFC 3066bis. Applications that implement your protocol may use a local copy of the Registry; they are not required to download the IANA-hosted copy on each use. Using this model, the question about "rus" goes away, since that subtag does not exist in the Registry. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ Editor, draft-ietf-ltru-initial _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 21 13:42:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFDmp-0007Lj-DV; Mon, 21 Aug 2006 13:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBNM-0002mm-6h; Mon, 21 Aug 2006 11:07:40 -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 1GF8er-0001On-En; Mon, 21 Aug 2006 08:13:33 -0400 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GF8WN-0005nY-8E; Mon, 21 Aug 2006 08:04:51 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44518) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1GF8W2-0004nU-NM (Exim 4.54) (return-path ); Mon, 21 Aug 2006 13:04:26 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GF8W2-0002mK-5V (Exim 4.54) (return-path ); Mon, 21 Aug 2006 13:04:26 +0100 Date: Mon, 21 Aug 2006 13:04:26 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Martin Duerst In-Reply-To: <6.0.0.20.2.20060818150743.097d4ec0@localhost> Message-ID: References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.3 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Mon, 21 Aug 2006 13:42:06 -0400 Cc: Alexey Melnikov , LTRU Working Group , ima@ietf.org Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, 18 Aug 2006, Martin Duerst wrote: > > For the LANG command, you only allow one language. You could extend that > to use a language priority list, but this is not really necessary, the > client can simulate a language priority list by using successive > requests until one of them is successful. The client knows which languages that the server supports (unless the server can't enumerate them), so it can simply do any priority matching within itself then choose the best match with one LANG command. Perhaps the draft should clarify this. The idea of using multiple LANG commands to implement a priority list is really bad for latency. If the LANG command could be pipelined then you could just issue a load of them in order of increasing priority, so the last one to succeed would be the best match. But this might not be very efficient on some servers. Tony. -- f.a.n.finch http://dotat.at/ FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR GOOD. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 21 14:14:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEHk-0000ls-RG; Mon, 21 Aug 2006 14:14:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEGZ-0000SZ-Ke; Mon, 21 Aug 2006 14:12:51 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFECB-0001QC-H3; Mon, 21 Aug 2006 14:08:23 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=h5sFbLg/FrPVMcjJ+8oWUot84Y3QdVOWqCbtczNXz0/Wx3kn1FEnGD7faXv848pV; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.188.70] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GFECA-0005A0-GR; Mon, 21 Aug 2006 14:08:18 -0400 Message-ID: <003401c6c54d$18765640$6501a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <44E09667.8070704@isode.com><6.0.0.20.2.20060818150743.097d4ec0@localhost> Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses Date: Mon, 21 Aug 2006 11:10:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888866e14058d4cf7af6e6a90c086875e11f11efb69192b565a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.188.70 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ima@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hi - as a technical contributor... > From: "Tony Finch" > To: "Martin Duerst" > Cc: "Alexey Melnikov" ; "LTRU Working Group" ; > Sent: Monday, August 21, 2006 5:04 AM > Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses ... > The client knows which languages that the server supports (unless the > server can't enumerate them), ... Or (if I read the draft correctly) if their tags won't all fit on one line. I also think the statement in the draft that "for the purpose of this document it is safe to treat all languages, whose tags starts with primary language described in ISO 639-1 and ISO 639-2 (i.e. all 2 or 3 letters primary languages) as hierarchical" is incorrect for languages for which multiple scripts are in common use. Randy _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 22 10:32:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFXIa-0000Kc-6V; Tue, 22 Aug 2006 10:32:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFXIW-0000JO-GS; Tue, 22 Aug 2006 10:32:08 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFXAZ-0005AC-2e; Tue, 22 Aug 2006 10:23:56 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 0B67B32871; Tue, 22 Aug 2006 14:23:55 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1GFXAY-0005TZ-Up; Tue, 22 Aug 2006 10:23:54 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 22 Aug 2006 10:23:54 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ltru@ietf.org Subject: [Ltru] WG Review: Recharter of Language Tag Registry Update (ltru) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org A modified charter has been submitted for the Language Tag Registry Update (ltru) working group in the Applications Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by August 29th. +++ Language Tag Registry Update (ltru) =================================== Current Status: Active Working Group Chair(s): Randy Presuhn Martin Duerst Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Ted Hardie Mailing Lists: General Discussion: ltru@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ltru Archive: http://www.ietf.org/mail-archive/web/ltru/index.html Description of Working Group: The primary language subtags allowed by the current IANA Language Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same way as they were limited by RFC 3066. This covers approximately 500 possible language subtags. ISO 639-3, scheduled for approval towards the end of 2006, will make available around 7000 more code elements for identifying languages. The working group will prepare an update to the Language Subtag Registry procedures to allow the use of 3-letter code elements from ISO 639-3 as primary language subtags or extended language subtags as appropriate. The working group will also deliver means to update the current IANA Language Subtag Registry with the newly available subtags. The working group will examine, and if necessary clarify or adjust, procedures and guidelines with respect to extended language subtags and variant subtags. Use cases include the identification of signed languages, transliterations, and transcriptions. The working group will also consider how the draft work on ISO 639-6 may relate to the future development of language tags. The working group will clarify text where necessary. It may also make adjustments to the registration process and the form of the registry if this is deemed appropriate based on ongoing registration and operational experience. These adjustments and clarifications are not expected to delay the progress of the work. Work on the drafts is planned to start before ISO 639-3 is fully approved and published. However, the WG will not finalize the drafts before ISO 639-3 is fully approved. Goals and Milestones: September 2006 Submit first WG draft of registry procedure update September 2006 Submit first WG draft of registry data update January 2007 Submit registry procedure update draft for IETF Last Call January 2007 Submit registry data update draft for IETF Last Call _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 22 12:20:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFYz3-000619-6o; Tue, 22 Aug 2006 12:20:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFVVG-0007Wi-2y; Tue, 22 Aug 2006 08:37:10 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFVVD-0002xc-5w; Tue, 22 Aug 2006 08:37:10 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Tue, 22 Aug 2006 13:36:59 +0100 Message-ID: <44EAFA49.2050605@isode.com> Date: Tue, 22 Aug 2006 13:36:25 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> In-Reply-To: <6.0.0.20.2.20060818150743.097d4ec0@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 X-Mailman-Approved-At: Tue, 22 Aug 2006 12:20:08 -0400 Cc: LTRU Working Group , ima@ietf.org Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: >Hello Alexey, > >I have looked at the draft. I'm not totally familiar with >all the details of email transmission, but will comment >mostly from an LTRU perspective. I have cc'ed the LTRU >WG, because I think your draft makes a good usage example >for the work of the LTRU WG, and some people may be able >to provide more feedback. > > Thank you for your feedback Martin. Draft draft-melnikov-smtp-lang-05.txt is a revision of a draft that expired in 2001 (before LTRU was chartered) and I haven't been following LTRU. >At 00:27 06/08/15, Alexey Melnikov wrote: > > >> Title : SMTP Language Extension >> Author(s) : M. Gahrns, A. Melnikov >> >> >This list of authors and the one in the draft seem to be >out of sync, probably a clerical error? > > No. Mike Garhns written the original IMAP LANGUAGE extension, this document is based on it. >> Filename : draft-melnikov-smtp-lang-05.txt >> Pages : 0 >> >> >This seems to be some administrative error, too, probably >a tool that counts drafts without explicit page breaks as >0 pages (I'd understand 1 page, 0 is really weird). > > I think you are right. >> Date : 2006-8-2 >> >> >Section 3: "It also recommends that server recognizes languges that > have multiple different tags (for example "ru" and "rus")." > > This is a bad idea. RFC 3066, and its successor RFC 3066bis > (draft-ietf-ltru-registry-14.txt, approved by the IESG and in > operation) both make it very clear that for languages that > have both two-letter and three-letter codes, only the two-letter > codes are used. > > Ok, I've removed the paragraph. >Please update the reference to RFC 3066 to RFC3066bis. > > Done. >For language fallback, I suggest you have a look at >http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-15.txt >(also IESG-approved). This gives you the (basic) "language-range" ABNF >construct that includes the "*" wildcard. > >Also, it seems that the matching going on on the server when the >client issues a LANG command (e.g. in Example 5) is very close to >and can (and should) be described in terms of Section 3.4, Lookup, >of the above draft. The only difference I see is that Section 3.4 >requires a solution (maybe default) in all cases, whereas in your >case, the default if no matching language is found is not i-default, >but "no change" or in other words, "previously selected language". > > Ok, this change would require some editing work on my part. I've added to my todo list. >I think the discussion of mul and und is overkill. There is no >interoperability problem if the client uses 'mul', it is just >a language that's not supported. > Ok, removed. >Suggesting, as in Example 2, >that the server has specific code for that issue is a bad idea, >it will tend to make the server more complex than necessary._ >_ > The server is actually [re-]using the same error code, but the error text might be different. This is actually quite useful for debugging implementation errors. However SMTP implementations are not required to do that anyway. >Somewhere in example 1, probably in the comment that starts with >"< Once the client changes...", you should say that the example >here doesn't show accents because they cannot be represented >in this format, but that accented characters, encoded in UTF-8, >would be present in the actual protocol exchange.* >* > Done. >Note 1: This is in part overkill, and in part incorrect. >If you do fallback on the server, then you have to leave >the decision to the server (or the server programmer or >administrator). There is no a-priori difference between >the special prefixes i- and x- and two-letter and three- >letter prefixes. It's very well possible that for i-foo-bar >and i-foo-baz, there is a mutually intellegible i-foo on >the server. The server will most probably only have i-foo >if the mutual intellegibility is a reasonable assumption. >On the other hand, for some people, zh-Hans (Chinese >written in simplifed script) and zh-Hant (Chinese written >in traditional script) are not mutually intellegible, >and so it may be a bad idea to make "zh" available on >the server. I think that if you refer to the abovementioned >two drafts, that should be enough. > > Thanks. I removed the note. >Aside: You could get rid of server-side fallbacks if you >could assume that the server can always send the complete >list of available languages. However, I think this would >be a bad idea, because a) there may be dozenz or hundreds >of languages, and just sending the list may present somewhat >of a scalability problem, and b) it may be much easier >computationally for the server to check for the existence >of a requested language (or it's fallback) than to list >all languages available (which may require an extensive >search for files in a large number of directories).* >* > Agreed. The list of all available langues is not returned for the reasons you stated. >For the LANG command, you only allow one language. >You could extend that to use a language priority list, >but this is not really necessary, the client can >simulate a language priority list by using successive >requests until one of them is successful.* >* > Actually, the LANG command already allows for priority list. >On the other hand, for the LANG parameter for the MAIL >command should allow a language priority list. The reason >for this is that (if my understanding is correct), this >parameter is passed on along the relay chain of SMTP servers, >and is supposed to go back to the original sender, and >using a list increases the chance that there is something >at the relevant server that can be understood by the >originator. > > Ok, this is a valid point. I will try to do this in a future revision. >I'm also not completely clear on / happy with the following >paragraph: > > > If the message is relayed to another SMTP server that supports LANGUAGE > ESMTP extension, the MTA acting as the client MUST check if the receiving > MTA lists the language specified in lang-param ("requested language") in > the list of supported language tags in LANGUAGE EHLO response. If the > receiving MTA either lists the requested language or doesn't list any > language tag (i.e. the receiving MTA is unable to list languages it > supports) the sender MUST issue LANG command for the requested language. > After that, regardless of the result of LANG command, the client MTA MUST > specify LANG parameter in MAIL command. > > > >After repeated reading, I think this is okay, but some clarification >might help. In particular, it should be pointed out that trying to >use the LANG command is done so that potential error messages in >this relay step can be sent back to the original sender in the >appropriate language if possible. > > I've clarified this, thanks. >Also, on a first reading, I was thinking that if the desired language >wasn't available, the LANG parameter would no longer be used.* >* > Yes, that was my original intent. But this would change, if the draft is changed to allow for priority list. >I think the reason for this misunderstanding is that the last two >lines come very late. I think it would be easier to understand if >the paragraph started out as follows: > > If the message is relayed to another SMTP server that supports the > LANGUAGE ESMTP extension, the MTA acting as the client MUST do > the following two things, in the following order: > 1) Attempt to set the language of server responses to the requested > language(s). > 2) Independently of whether 1) is successful, use the LANG > parameter on the MAIL command to transmit the requested > language(s) to the next relay. > >If you think more explanations and details for 1) are needed, they >should come after this list. > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 22 13:19:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZuh-0001MW-9e; Tue, 22 Aug 2006 13:19:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFZDW-0001Ud-Qq; Tue, 22 Aug 2006 12:35:06 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFZDV-0007Te-7q; Tue, 22 Aug 2006 12:35:06 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GFZDU-000OVc-0m; Tue, 22 Aug 2006 12:35:04 -0400 Date: Tue, 22 Aug 2006 12:35:02 -0400 From: John C Klensin To: Randy Presuhn , LTRU Working Group Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses Message-ID: <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> In-Reply-To: <003401c6c54d$18765640$6501a8c0@oemcomputer> References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> <003401c6c54d$18765640$6501a8c0@oemcomputer> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-Mailman-Approved-At: Tue, 22 Aug 2006 13:19:42 -0400 Cc: ima@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I've deferred comment on this draft to see what others think, but now seems to be the time... --On Monday, 21 August, 2006 11:10 -0700 Randy Presuhn wrote: > Hi - > > as a technical contributor... > >> From: "Tony Finch" >> To: "Martin Duerst" >> Cc: "Alexey Melnikov" ; "LTRU >> Working Group" ; Sent: Monday, >> August 21, 2006 5:04 AM >> Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 in >> SMTP responses > ... >> The client knows which languages that the server supports >> (unless the server can't enumerate them), > ... > > Or (if I read the draft correctly) if their tags won't all fit > on one line. that is ok, because the basic statement is false in the general case -- in a relay situation, which the draft does not appear to completely analyze, the originating client (which is the only system that really knows the user's language preferences, if it does) may have no practical way to know the server's language capability. > I also think the statement in the draft that "for the purpose > of this document it is safe to treat all languages, whose tags > starts with primary language described in ISO 639-1 and ISO > 639-2 (i.e. all 2 or 3 letters primary languages) as > hierarchical" is incorrect for languages for which multiple > scripts are in common use. Yes. Another issue you didn't mention is that, in an environment in which the language negotiated runs right to left, it not clear where all the pieces go. Presumably, if this specification doesn't change the syntax specified in 2821 (the examples in this document imply that, but don't state it), we have Reply-line = Reply-code [ SP text ] CRLF But, if "text" can run right to left, do extended reply codes go at the beginning of the string (i.e., to the right) or do they imply a separate subfield... noting that either raises all of the BIDI issues simply because the Reply-code and SP are required to be expressed in Western digits and ASCII characters. Even if we can make this model work, I suggest it is the wrong model. I further suggest that the difficulties with the small, inconvenient, cases, such as those above, are symptomatic of why it is the wrong model. The issue of making the text of SMTP responses language-appropriate has been recognized since RFC 821 was written. As with many other Internet protocols, the most effective model is to use a single form on the wire and then perform translations (of character sets, terminal information, formats, and, yes, languages) at the endpoints. The "rely on the codes" requirement of 821 was, and is, part of that concern. When the codes proved inadequate in practice, we extended the codes, which was entirely consistent with that general model. If a user needs to look at an SMTP reply message directly, then I suggest that either there is a debugging case in action or the relevant MUA is broken. Debugging cases are easier with more uniformity and simplicity, not more options. So I suggest that: (1) This draft be dropped in favor of an effort to make SMTP reply text easier to translate to other languages or generate-able from the codes. (2) Any server implementer who is concerned about internationalization -- and I think all of us should be -- should be generating extended reply codes. If one were to adopt a LANG extension, I would suggest that it would make extended codes mandatory anyway. (3) We should look at the text associated with extended reply codes to be sure that the portions of those lines that are not boilerplate explanations are easily identified and extracted by automatic processes. If we discover cases where that goal is not met, we should fix them. With the latter two conditions in place, I believe the right (and fairly simple) way to get an SMTP reply tailored to local language needs would become: (i) MUA that receives the reply, or MTA that is about to deliver the reply to such an MUA, extracts the extended reply code and non-boilerplace, message-dependent, material from the "text" and discards the rest. (ii) The extended reply code is used to generate response text in the appropriate language, substituting the non-boilerplate elements as needed. While this requires the efforts in (1) - (3) above, it does not require SMTP changes. And the recipient systems can do the right thing as dictated by their environments (which they should do even if the text is more friendly to their usual practices). SMTP is already too complicated. Let's avoid adding more complexity unless it is strictly necessary. This is not. john _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 22 14:10:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFahm-0001ih-3t; Tue, 22 Aug 2006 14:10:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFahk-0001iP-Q0; Tue, 22 Aug 2006 14:10:24 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFahj-00081O-Cm; Tue, 22 Aug 2006 14:10:24 -0400 Received: from [172.21.148.169] (wlanvpn-mc2e-246-169.corp.yahoo.com [172.21.148.169]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k7MIAEGM047539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 11:10:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=nT1oA2+yXCXfz0ws69bNp61dlq0bwqOb9idqH6hFRz0PnxvmrkgOaTO3T1/UoSeh Message-ID: <44EB4886.5010009@yahoo-inc.com> Date: Tue, 22 Aug 2006 11:10:14 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John C Klensin Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> In-Reply-To: <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: LTRU Working Group , ima@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 A few comments follow... John C Klensin wrote: >> ... >>> The client knows which languages that the server supports >>> (unless the server can't enumerate them), >> ... Enumerating languages can be difficult. Most locale systems are quite extensive, with hundreds of potential values available. The server would have to attempt to load resources in each and enumerate whether the resources were extant in the locale or not in order to build an accurate list. In practice, few languages are actually available, but the code to figure it out is not available either. > > Another issue you didn't mention is that, in an environment in > which the language negotiated runs right to left, it not clear > where all the pieces go. This is a common misperception. The logical order of the text is left-to-right until the [ SP text ] is reached. This text is rendered RTL, if appropriate to do so, up to the CRLF (which ends the RTL "run"). See http://www.w3.org/TR/CharMod and http://www.unicode.org/reports/tr9/ > > Even if we can make this model work, I suggest it is the wrong > model. I further suggest that the difficulties with the small, > inconvenient, cases, such as those above, are symptomatic of why > it is the wrong model. The examples given are not very convincing. However... I tend to agree that this is the wrong model. The design of SMTP and other protocols is such that user-agents can present "friendly" messages (including localized messages) to end users. Almost no one interacts with SMTP servers directly. > > (1) This draft be dropped in favor of an effort to make > SMTP reply text easier to translate to other languages > or generate-able from the codes. Allowing UTF-8 would still seem to be a Good Thing, since even boilerplate messages might need to include runtime data that is non-ASCII. Language negotiation is another issue. > > (3) We should look at the text associated with extended > reply codes to be sure that the portions of those lines > that are not boilerplate explanations are easily > identified and extracted by automatic processes. If we > discover cases where that goal is not met, we should fix > them. If extended reply codes permit the server to emit its own internal error messages which are not entirely standardized (i.e. boilerplate), then the user-agent may have not choice other than to render the string on to the user. This is unsatisfactory. > > (i) MUA that receives the reply, or MTA that is about to > deliver the reply to such an MUA, extracts the extended > reply code and non-boilerplace, message-dependent, > material from the "text" and discards the rest. This works best if the message dependent material were clearly separate and in a machine-friendly format. This: 9106 Invalid user name; user=nobody, domain=example.org Is easier to deal with than: "9106 Invalid user name 'nobody' for domain 'example.org'" > > SMTP is already too complicated. Let's avoid adding more > complexity unless it is strictly necessary. This is not. > +1 Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 22 19:24:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfbP-0008Pn-Dt; Tue, 22 Aug 2006 19:24:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFfbO-0008Pf-5d; Tue, 22 Aug 2006 19:24:10 -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 1GFcTF-0007rL-GQ; Tue, 22 Aug 2006 16:03:33 -0400 Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFcEt-0000Xq-Mx; Tue, 22 Aug 2006 15:48:47 -0400 Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1GFcEq-000PvO-Jk; Tue, 22 Aug 2006 15:48:40 -0400 Date: Tue, 22 Aug 2006 15:48:39 -0400 From: John C Klensin To: Addison Phillips Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses Message-ID: In-Reply-To: <44EB4886.5010009@yahoo-inc.com> References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> <44EB4886.5010009@yahoo-inc.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.0 (--) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: LTRU Working Group , ima@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --On Tuesday, 22 August, 2006 11:10 -0700 Addison Phillips wrote: > A few comments follow... > > John C Klensin wrote: >>> ... >>>> The client knows which languages that the server supports >>>> (unless the server can't enumerate them), >>> ... > > Enumerating languages can be difficult. Most locale systems > are quite extensive, with hundreds of potential values > available. The server would have to attempt to load resources > in each and enumerate whether the resources were extant in the > locale or not in order to build an accurate list. In practice, > few languages are actually available, but the code to figure > it out is not available either. That is consistent with what I had assumed, and reinforces the impression that this proposal is not a good idea. >> Another issue you didn't mention is that, in an environment in >> which the language negotiated runs right to left, it not clear >> where all the pieces go. > > This is a common misperception. The logical order of the text > is left-to-right until the [ SP text ] is reached. This text > is rendered RTL, if appropriate to do so, up to the CRLF > (which ends the RTL "run"). See http://www.w3.org/TR/CharMod > and http://www.unicode.org/reports/tr9/ Exactly (!). If I said that badly, I apologize, but I read 821/ 2821 as requiring a three digit code and the SP (in left-to-right order) followed by "text". The extended status code stuff is specific about the text, but wasn't written anticipating internationalization and is not required by the proposed specification anyway. And, to the best of my knowledge, there is no standard requiring the used of W3C CharMod or Unicore TR9 in Internet mail replies. I believe that could be fixed for this spec, and even that it wouldn't be hard to do. But it is, IMO, evidence that the spec is not completely worked out even if it were a good idea. >> Even if we can make this model work, I suggest it is the wrong >> model. I further suggest that the difficulties with the >> small, inconvenient, cases, such as those above, are >> symptomatic of why it is the wrong model. > > The examples given are not very convincing. However... I tend > to agree that this is the wrong model. The design of SMTP and > other protocols is such that user-agents can present > "friendly" messages (including localized messages) to end > users. Almost no one interacts with SMTP servers directly. Right >> (1) This draft be dropped in favor of an effort to make >> SMTP reply text easier to translate to other languages >> or generate-able from the codes. > > Allowing UTF-8 would still seem to be a Good Thing, since even > boilerplate messages might need to include runtime data that > is non-ASCII. Language negotiation is another issue. Clearly, the EAI effort is going to need to deal, in some way, with replies that contain non-ASCII addresses. But, as you say, that is a different issue from language negotiation. >> (3) We should look at the text associated with extended >> reply codes to be sure that the portions of those lines >> that are not boilerplate explanations are easily >> identified and extracted by automatic processes. If we >> discover cases where that goal is not met, we should fix >> them. > If extended reply codes permit the server to emit its own > internal error messages which are not entirely standardized > (i.e. boilerplate), then the user-agent may have not choice > other than to render the string on to the user. This is > unsatisfactory. I think that is what I said. In the current situation, the parts that are clearly non-boilerplate (going back to 821) are situations in which the reply is expected to include an address or part of one. And I was suggesting only that those pieces needed to be easily identified and parsed out. >> (i) MUA that receives the reply, or MTA that is about to >> deliver the reply to such an MUA, extracts the extended >> reply code and non-boilerplace, message-dependent, >> material from the "text" and discards the rest. > > This works best if the message dependent material were clearly > separate and in a machine-friendly format. This: > > 9106 Invalid user name; user=nobody, domain=example.org > > Is easier to deal with than: > > "9106 Invalid user name 'nobody' for domain 'example.org'" Yes. How much of this we can successfully change now, after two or three decades of practice, is an open question. But that is one of the reasons for pushing toward the use of extended reply codes (and formats) which, at the moment, the EAI work is expected to require. >> SMTP is already too complicated. Let's avoid adding more >> complexity unless it is strictly necessary. This is not. >> > > +1 Thanks. john _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 23 01:13:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFl2q-0004fB-1K; Wed, 23 Aug 2006 01:12:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFl2n-0004ex-8D; Wed, 23 Aug 2006 01:12:49 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFl2l-0003LN-02; Wed, 23 Aug 2006 01:12:49 -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 <20060823051246.TQQY14558.mta9.adelphia.net@DGBP7M81>; Wed, 23 Aug 2006 01:12:46 -0400 Message-ID: <003f01c6c672$c2ae1dc0$060aa8c0@DGBP7M81> From: "Doug Ewell" To: References: Date: Tue, 22 Aug 2006 22:12:40 -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.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: LTRU Working Group Subject: [Ltru] Re: WG Review: Recharter of Language Tag Registry Update (ltru) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, 22 Aug 2006 10:23:54 -0400, IESG Secretary wrote: > A modified charter has been submitted for the Language Tag Registry > Update (ltru) working group in the Applications Area of the IETF. The > IESG has not made any determination as yet. The modified charter is > provided below for informational purposes only. Please send your > comments to the IESG mailing list (iesg@ietf.org) by August 29th. > > ... > > Goals and Milestones: > > September 2006 Submit first WG draft of registry procedure update > September 2006 Submit first WG draft of registry data update > January 2007 Submit registry procedure update draft for IETF Last Call > January 2007 Submit registry data update draft for IETF Last Call As the likely editor of the "registry data update" document, I'd like to request that the milestones for the first drafts be extended to October, or perhaps even November, and that the milestones for Last Call drafts remain at least 3 months after the first drafts (e.g. moving them to February if the first drafts arrive in November). Having experienced many lengthy delays in LTRU 1.0, which pushed the original milestones out by many months, I'd like to make sure we have a reasonable chance of hitting the LTRU 2.0 dates. There are several issues to be discussed within the WG before realistic first drafts can be written. The decision on the new charter will not be made until at least August 29, leaving only 32 days to discuss these issues and write drafts before the first milestone. -- 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 Wed Aug 23 01:53:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFlg9-0004Jc-85; Wed, 23 Aug 2006 01:53:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFlg8-0004JX-EJ for ltru@ietf.org; Wed, 23 Aug 2006 01:53:28 -0400 Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFlg7-0000bh-6j for ltru@ietf.org; Wed, 23 Aug 2006 01:53:28 -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 <20060823055326.UNOO14558.mta9.adelphia.net@DGBP7M81> for ; Wed, 23 Aug 2006 01:53:26 -0400 Message-ID: <010301c6c678$71f95a60$060aa8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Tue, 22 Aug 2006 22:53:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; 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.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 explanation might be slightly different from Addison's. John C Klensin wrote: > Another issue you didn't mention is that, in an environment in which > the language negotiated runs right to left, it not clear where all the > pieces go. Presumably, if this specification doesn't change the > syntax specified in 2821 (the examples in this document imply that, > but don't state it), we have > > Reply-line = Reply-code [ SP text ] CRLF > > But, if "text" can run right to left, do extended reply codes go at > the beginning of the string (i.e., to the right) or do they imply a > separate subfield... noting that either raises all of the BIDI issues > simply because the Reply-code and SP are required to be expressed in > Western digits and ASCII characters. Right-to-left is a display concept only. All components appear in the order specified: first a required Reply-code, then (optionally) a space followed by text, then a required CRLF. How this is displayed or printed depends on the directionality of the characters in 'text', but the order of the items is always the same. -- 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 Aug 23 05:14:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFooO-0002qG-E6; Wed, 23 Aug 2006 05:14:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFooN-0002q9-2X for ltru@ietf.org; Wed, 23 Aug 2006 05:14:11 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFooJ-00071L-D4 for ltru@ietf.org; Wed, 23 Aug 2006 05:14:11 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k7N9E4Sv027370 for ; Wed, 23 Aug 2006 18:14:04 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 7763_b9263446_3287_11db_9bd0_0014221f2a2d; Wed, 23 Aug 2006 18:14:03 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7N9DVpD020245 for ; Wed, 23 Aug 2006 18:14:03 +0900 Message-Id: <6.0.0.20.2.20060823180516.18837b20@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 23 Aug 2006 18:06:29 +0900 To: ltru@ietf.org From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Ltru] Fwd: Response to Part 1 of the appeal by JFC Morfin dated 2006-08-17 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 member, This should be of interest to you if you follow the progress of our documents. Regards, Martin. >To: JFC Morfin >From: IESG Secretary >Date: Tue, 22 Aug 2006 12:05:42 -0400 >Cc: iesg@ietf.org, ietf-announce@ietf.org >Subject: Response to Part 1 of the appeal by JFC Morfin dated 2006-08-17 >Response to Part 1 of the appeal by JFC Morfin dated 2006-08-17 > >This is the IESG response to Part 1 of the appeal by JFC Morfin >sent on 2006-08-17 and posted at >http://www.ietf.org/IESG/APPEALS/jefsey-appeal-to-iesg-08-17-2006.pdf > >This was considered during the IESG teleconference >on the same date. Part 1 of the appeal is summarized as: > >"Appeal against the decision to consider a request to the RFC Editor >to expedite the publication of draft-ietf-ltru-registry, >draft-ietf-ltru-matching and draft-ietf-ltru-initial" > >followed by various arguments. > >As discussed in the July 10 response to the appeal from Dean Anderson >against draft-ietf-grow-anycast, the appeals process is designed to >handle disputes that cannot be handled through other means. The IESG >cannot come up with a situation where it would be appropriate to >appeal the consideration of some action before a decision is made; >this is certainly not such a case. Instead, participants should >provide input to that consideration. We interpret this appeal in that >light: we interpret part 1 of the appeal as arguments why the IESG >should choose to delay a decision to expedite this BCP. > >The IESG makes such requests regularly when another SDO's publication >schedule requires the ability to cite a forthcoming RFC normatively. >There is nothing exceptional or discriminatory about doing so in the >case of Unicode. It would not be sufficient for Unicode to refer >generically to BCP 47; the reference needs to be to specific text >and hence to the RFCs. > >We note that RFC 2026 does not require appeals to have suspensive effect. >If an appeal against the approval of a published RFC were to succeed, >that RFC could be reclassified as Historic. > >We find no merit in the arguments in Part 1 of the appeal, which is >dismissed. > >[The response to Part 2 of the appeal will be published later.] > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce #-#-# 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 Aug 23 07:19:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFqlh-0006OF-Gy; Wed, 23 Aug 2006 07:19:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFqlg-0006H5-Ar for ltru@ietf.org; Wed, 23 Aug 2006 07:19:32 -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 1GFp3T-0000ch-Cq for ltru@ietf.org; Wed, 23 Aug 2006 05:29:47 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFooR-0002gw-7R for ltru@ietf.org; Wed, 23 Aug 2006 05:14:17 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k7N9E3Qb027367 for ; Wed, 23 Aug 2006 18:14:03 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 68b1_b87c76ae_3287_11db_826d_0014221fa3c9; Wed, 23 Aug 2006 18:14:02 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7N9DVpB020245 for ; Wed, 23 Aug 2006 18:14:02 +0900 Message-Id: <6.0.0.20.2.20060823180403.18836d80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 23 Aug 2006 18:05:07 +0900 To: ltru@ietf.org From: Martin Duerst Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: -2.2 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [Ltru] Fwd: WG Review: Recharter of Language Tag Registry Update (ltru) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Dear LTRU WG members, As you can see below, the new charter that we have been working on now has been sent to the IETF mailing list for a two-week review. Reagards, Martin. >To: ietf-announce@ietf.org >Cc: Randy Presuhn ,Martin Duerst >, ltru@ietf.org >From: IESG Secretary >Subject: WG Review: Recharter of Language Tag Registry Update (ltru) >Reply-To: iesg@ietf.org >Date: Tue, 22 Aug 2006 10:23:54 -0400 > >A modified charter has been submitted for the Language Tag Registry >Update (ltru) working group in the Applications Area of the IETF. >The IESG has not made any determination as yet. The modified charter is >provided below for informational purposes only. Please send your comments >to the IESG mailing list (iesg@ietf.org) by August 29th. > >+++ > >Language Tag Registry Update (ltru) >=================================== > >Current Status: Active Working Group > >Chair(s): >Randy Presuhn >Martin Duerst > >Applications Area Director(s): >Ted Hardie >Lisa Dusseault > >Applications Area Advisor: >Ted Hardie > >Mailing Lists: >General Discussion: ltru@ietf.org >To Subscribe: https://www1.ietf.org/mailman/listinfo/ltru >Archive: http://www.ietf.org/mail-archive/web/ltru/index.html > >Description of Working Group: > >The primary language subtags allowed by the current IANA Language >Subtag Registry are limited to ISO 639-1 and ISO 639-2 in the same >way as they were limited by RFC 3066. This covers approximately 500 >possible language subtags. ISO 639-3, scheduled for approval towards >the end of 2006, will make available around 7000 more code elements >for identifying languages. > >The working group will prepare an update to the Language Subtag >Registry procedures to allow the use of 3-letter code elements >from ISO 639-3 as primary language subtags or extended language >subtags as appropriate. The working group will also deliver means >to update the current IANA Language Subtag Registry with the newly >available subtags. > >The working group will examine, and if necessary clarify or adjust, >procedures and guidelines with respect to extended language subtags >and variant subtags. Use cases include the identification of >signed languages, transliterations, and transcriptions. >The working group will also consider how the draft work on >ISO 639-6 may relate to the future development of language tags. > >The working group will clarify text where necessary. It may also >make adjustments to the registration process and the form of the >registry if this is deemed appropriate based on ongoing registration >and operational experience. These adjustments and clarifications >are not expected to delay the progress of the work. > >Work on the drafts is planned to start before ISO 639-3 is fully >approved and published. However, the WG will not finalize the >drafts before ISO 639-3 is fully approved. > > >Goals and Milestones: > >September 2006 Submit first WG draft of registry procedure update >September 2006 Submit first WG draft of registry data update >January 2007 Submit registry procedure update draft for IETF Last Call >January 2007 Submit registry data update draft for IETF Last Call #-#-# 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 Aug 23 07:21:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFqnw-0007HH-H8; Wed, 23 Aug 2006 07:21:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFqnu-0007H3-JV; Wed, 23 Aug 2006 07:21:50 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFqnt-0002SF-4T; Wed, 23 Aug 2006 07:21:50 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8324B2596DE; Wed, 23 Aug 2006 13:19:53 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17190-04; Wed, 23 Aug 2006 13:19:47 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1E25B2596DA; Wed, 23 Aug 2006 13:19:47 +0200 (CEST) Message-ID: <44EC3A45.90201@alvestrand.no> Date: Wed, 23 Aug 2006 04:21:41 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: John C Klensin Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> In-Reply-To: <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: LTRU Working Group , ima@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > The issue of making the text of SMTP responses > language-appropriate has been recognized since RFC 821 was > written. As with many other Internet protocols, the most > effective model is to use a single form on the wire and then > perform translations (of character sets, terminal information, > formats, and, yes, languages) at the endpoints. The "rely on > the codes" requirement of 821 was, and is, part of that concern. > When the codes proved inadequate in practice, we extended the > codes, which was entirely consistent with that general model. > > If a user needs to look at an SMTP reply message directly, then > I suggest that either there is a debugging case in action or the > relevant MUA is broken. Debugging cases are easier with more > uniformity and simplicity, not more options. > > just because I have some available, here are some examples of SMTP error codes... | SMTP error in RCPT TO: 553 '<@>' not matched: (ERR | | Error in RCPT TO: 550 5.1.1 unknown or illegal alias: @ (MX) | | Error in RCPT TO: 501 5.7.1 This system is not configured to rel | | Connect(raw) failed: Connection refused | | 5.1.1 (Unknown user): QMail; 550 ... U | | Error in RCPT TO: 550 Sorry, no mailbox here by that name. (#5.1 | | Error in RCPT TO: 554 5.0.0 Mail to ace3 is not permitted (MX) | | Error in RCPT TO: 550 5.1.1 <@>... email address lookup in domai | | Error in RCPT TO: 553 5.3.0 <@>... Unknown user jwessel@staff.ui | | 5.1.1 (Unknown user): QMail; 550 ... Relaying denied (MX) | | Error in RCPT TO: 553 sorry, that domain isn't in my list of all | | Error in RCPT TO: 554 5.7.1 <@>... User unknown (MX) | <@> is an abbreviation for "the original email address was here". These are truncated to 64 chars. the important points are: - a lot of servers return quite different errors with the same error code - the servers try to return info that's useful for the sender, not for the relay agent Query: Has anyone seen a production piece of software that tries to decode the extendedstatuscodes as text for display to the users? Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 23 14:15:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFxGN-0007tJ-1k; Wed, 23 Aug 2006 14:15:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFuMI-00081L-Jg; Wed, 23 Aug 2006 11:09:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFsK4-0006up-NV; Wed, 23 Aug 2006 08:59:08 -0400 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFrxy-0008G3-Fh; Wed, 23 Aug 2006 08:36:21 -0400 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:52637) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1GFrxZ-0006SQ-1G (Exim 4.54) (return-path ); Wed, 23 Aug 2006 13:35:53 +0100 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1GFrxZ-0007fS-Ax (Exim 4.54) (return-path ); Wed, 23 Aug 2006 13:35:53 +0100 Date: Wed, 23 Aug 2006 13:35:53 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Harald Alvestrand Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses In-Reply-To: <44EC3A45.90201@alvestrand.no> Message-ID: References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> <44EC3A45.90201@alvestrand.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.4 (--) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Wed, 23 Aug 2006 14:15:37 -0400 Cc: LTRU Working Group , John C Klensin , ima@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Wed, 23 Aug 2006, Harald Alvestrand wrote: > > Query: Has anyone seen a production piece of software that tries to decode the > extendedstatuscodes as text for display to the users? Yes, and the result is usually unhelpful in my experience. A significant number of support queries that I have to deal with are solved by me pulling an error message out of the logs that was hidden by some software between my servers and the user. (Admittedly, this is more likely to happen for us because we don't support enhanced status codes, but since they carry so little extra information I doubt they would help.) John says: > > As with many other Internet protocols, the most effective model is to > use a single form on the wire and then perform translations (of > character sets, terminal information, formats, and, yes, languages) at > the endpoints. The "rely on the codes" requirement of 821 was, and is, > part of that concern. That's not the way I read it. To me it says that the non-enhanced codes are for the client state machine and the text is for a human; it does not imply that a client should replace the server's text with its own idea of what went wrong. > If a user needs to look at an SMTP reply message directly, then I > suggest that either there is a debugging case in action or the relevant > MUA is broken. Debugging cases are easier with more uniformity and > simplicity, not more options. If a user sees an SMTP response then something has gone wrong so it's a debugging case by definition. Addison says: > > Almost no one interacts with SMTP servers directly. Of course they do, to the same extent that they interact with IMAP or POP or HTTP servers - mediated by a user agent. >From my point of view, and from the point of view of my colleagues on the help desk, it would be much easier if MUAs did not try to impose their own gloss on my servers' error messages (or do other stupid things like truncate them). That way I can provide helpful text that explains what went wrong, and/or a URL to help pages or a directory. The current set of enhanced status codes is non-orthogonal and does not cover the range of possibilities or provide enough detail within their coverage. For example, there are codes for bad syntax and bad domain for both sender and recipient addresses, but you can only specifically say the local part is bad for destination addresses, and there are different OK codes for senders and recipients. There's a code for "too many recipients" but not "too few recipients" (e.g. RFC 4468 has a different gloss of 5.5.0 for this situation). In SMTP you can say that an address has changed (551) but not with enhanced status codes. (We've had a number departments changing name recently where it might have been useful to use the 551 feature, but since no-one implements it we just used an ad-hoc "try newname.cam.ac.uk instead" error.) The range of codes for client policy restrictions is inadequate: there's no way of expressing the distinction between "relaying is not permitted", "you have been blacklisted", "you are making too many concurrent connections", "you have been rate-limited", "you have been greylisted", etc. There are no codes for saying that the message content violates security restrictions, such as a virus infection or a forbidden attachment type or a spam classification. Even if you solve these problems, there is no provision for extending the set of status codes except as a standards action - there is no IANA registry. And in fact an IANA registry wouldn't solve the problem because no existing software will have glosses for any new status codes you might register, so the new codes would be useless. The idea of a fixed set of status codes is fundamentally unable to cope with evolving operational requirements. Tony. -- f.a.n.finch http://dotat.at/ FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR GOOD. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 23 14:54:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFxs9-00088d-FT; Wed, 23 Aug 2006 14:54:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFxNl-0002k9-Ew; Wed, 23 Aug 2006 14:23:17 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFxNg-0003UQ-Vi; Wed, 23 Aug 2006 14:23:17 -0400 Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7NIN8HX028174; Wed, 23 Aug 2006 12:23:09 -0600 (MDT) Received: from we-gotmail.red.iplanet.com (gotmail-1.red.iplanet.com [192.18.73.251]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k7NIN7pf000162; Wed, 23 Aug 2006 11:23:08 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [10.30.0.30] (vpn-129-150-24-217.SFBay.Sun.COM [129.150.24.217]) by we-gotmail.red.iplanet.com (Sun Java(tm) System Messaging Server 6.3-0.08 (built Jun 8 2006)) with ESMTPSA id <0J4G00G2BR2IWN00@we-gotmail.red.iplanet.com>; Wed, 23 Aug 2006 11:23:07 -0700 (PDT) In-reply-to: <44EC3A45.90201@alvestrand.no> References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> <44EC3A45.90201@alvestrand.no> Message-id: <6bb05ca80eb2f8d9e22f86aa5fc9b7c5@sun.com> From: Kristin Hubner Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses Date: Wed, 23 Aug 2006 11:22:59 -0700 To: Harald Alvestrand X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-Mailman-Approved-At: Wed, 23 Aug 2006 14:54:40 -0400 Cc: LTRU Working Group , John C Klensin , ima@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Aug 23, 2006, at 4:21 AM, Harald Alvestrand wrote: >> >> The issue of making the text of SMTP responses >> language-appropriate has been recognized since RFC 821 was >> written. As with many other Internet protocols, the most >> effective model is to use a single form on the wire and then >> perform translations (of character sets, terminal information, >> formats, and, yes, languages) at the endpoints. The "rely on >> the codes" requirement of 821 was, and is, part of that concern. >> When the codes proved inadequate in practice, we extended the >> codes, which was entirely consistent with that general model. >> >> If a user needs to look at an SMTP reply message directly, then >> I suggest that either there is a debugging case in action or the >> relevant MUA is broken. Debugging cases are easier with more >> uniformity and simplicity, not more options. >> > just because I have some available, here are some examples of SMTP > error codes... > > > | SMTP error in RCPT TO: 553 '<@>' not matched: (ERR | > | Error in RCPT TO: 550 5.1.1 unknown or illegal alias: @ (MX) | > | Error in RCPT TO: 501 5.7.1 This system is not configured to rel | > | Connect(raw) failed: Connection refused | > | 5.1.1 (Unknown user): QMail; 550 ... U | > | Error in RCPT TO: 550 Sorry, no mailbox here by that name. (#5.1 | > | Error in RCPT TO: 554 5.0.0 Mail to ace3 is not permitted (MX) | > | Error in RCPT TO: 550 5.1.1 <@>... email address lookup in domai | > | Error in RCPT TO: 553 5.3.0 <@>... Unknown user jwessel@staff.ui | > | 5.1.1 (Unknown user): QMail; 550 | Error in RCPT TO: 550 5.7.1 Unable to relay for @ (MX) | > | Error in RCPT TO: 554 Mail for @ rejected for policy reasons. (M | > | RELAY problem: 550 5.7.1 <@>... Relaying denied (MX) | > | Error in RCPT TO: 553 sorry, that domain isn't in my list of all | > | Error in RCPT TO: 554 5.7.1 <@>... User unknown (MX) | > > <@> is an abbreviation for "the original email address was here". > These are truncated to 64 chars. > > the important points are: > > - a lot of servers return quite different errors with the same error > code > - the servers try to return info that's useful for the sender, not for > the relay agent > > Query: Has anyone seen a production piece of software that tries to > decode the extendedstatuscodes as text for display to the users? > > Harald I'm not sure that this is the sort of example you had in mind, as this is at the MTA level, not the MUA level...but we added at it the MTA level to partially make up for the current dearth of such "localizing SMTP extendedstatuscode" support at the MUA level. The Sun JES MS MTA has options that for DSNs generated by the MTA, sites can specify their own choice (in their own choice of language and charset -- to correspond to their choice of language and charset for the entire first/human-readable portion of the DSN) an additional text string to be reported corresponding to each extendedstatuscode. That is, when the MTA is generating a DSN (based on, say, an SMTP rejection from a remote SMTP server), the DSN can include an optional site-specified "interpretation" of the extendedstatuscode in addition to the actual SMTP rejection code and text. This will then be included in the first (human readable) portion of the multipart/report. That is, a site could set 5.1.1= 5.1.2= etc., (actually, they can set a bunch of such options, one set for each language/charset combination for which they wish such special support) and then when the MTA generates a DSN reporting on encountering such an extended code, the MTA will include the site's localized string, as well as the actual "original" text (if any) issued by the remote SMTP server in the human-readable first portion of the DSN. This option has been used by some sites, though probably not many. As Harald Alvestrand observed, since the current situation is that a single extendedstatuscode will be used by different servers to report various (though "related" in being the same RFC 1893 category) errors, the general "interpretation" you can make for a particular extendedstatuscode currently tends towards the vague -- essentially a localized version of the category as defined in RFC 1893. Regards, Kristin kristin.hubner@sun.com > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 23 18:51:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1Yx-00058M-U0; Wed, 23 Aug 2006 18:51:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1Yx-00058F-2T for ltru@ietf.org; Wed, 23 Aug 2006 18:51:07 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG1Yv-0008Lk-O7 for ltru@ietf.org; Wed, 23 Aug 2006 18:51:07 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M6C52VZ9ZK00O118@mauve.mrochek.com> for ltru@ietf.org; Wed, 23 Aug 2006 15:50:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1156373455; h=Date: From:Subject:MIME-version:Content-type; b=Oa9GcJa9yNhqVAP5wIxRtufVc rCbetsY67n9jvmJsZpYbocyhpMV5Xa6YdSKdwXmvWpXI76+6ZZX5SupTsr5Pw== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M6BZ77KZ1C0008CX@mauve.mrochek.com>; Wed, 23 Aug 2006 15:50:50 -0700 (PDT) To: Doug Ewell Message-id: <01M6C52TCA600008CX@mauve.mrochek.com> Date: Wed, 23 Aug 2006 15:48:39 -0700 (PDT) From: Ned Freed Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses In-reply-to: "Your message dated Tue, 22 Aug 2006 22:53:22 -0700" <010301c6c678$71f95a60$060aa8c0@DGBP7M81> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=iso-8859-1; reply-type=original References: <010301c6c678$71f95a60$060aa8c0@DGBP7M81> X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 > This explanation might be slightly different from Addison's. > John C Klensin wrote: > > Another issue you didn't mention is that, in an environment in which > > the language negotiated runs right to left, it not clear where all the > > pieces go. Presumably, if this specification doesn't change the > > syntax specified in 2821 (the examples in this document imply that, > > but don't state it), we have > > > > Reply-line = Reply-code [ SP text ] CRLF > > > > But, if "text" can run right to left, do extended reply codes go at > > the beginning of the string (i.e., to the right) or do they imply a > > separate subfield... noting that either raises all of the BIDI issues > > simply because the Reply-code and SP are required to be expressed in > > Western digits and ASCII characters. > Right-to-left is a display concept only. All components appear in the > order specified: first a required Reply-code, then (optionally) a space > followed by text, then a required CRLF. How this is displayed or > printed depends on the directionality of the characters in 'text', but > the order of the items is always the same. And RFC 2034 requires that the enhanced status code appear at the beginning of the text part of the response. There's no wiggle room here IMO. Ned P.S. Now that NOTARY is at draft, it's probably time to drag RFC 2034 forward as well. Any objections? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 23 19:14:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1w2-0008Ct-Mv; Wed, 23 Aug 2006 19:14:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG1us-0007bJ-3W; Wed, 23 Aug 2006 19:13:46 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG1k4-0001bP-1M; Wed, 23 Aug 2006 19:02:38 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k7NN2Oee009716; Thu, 24 Aug 2006 08:02:24 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 02e3_7093ee52_32fb_11db_9971_0014221fa3c9; Thu, 24 Aug 2006 08:02:24 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7NN1lXq000606; Thu, 24 Aug 2006 08:02:20 +0900 Message-Id: <6.0.0.20.2.20060824072912.08dc0e60@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 24 Aug 2006 07:50:58 +0900 To: John C Klensin , Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 inSMTP responses In-Reply-To: References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> <44EB4886.5010009@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: LTRU Working Group , ima@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 04:48 06/08/23, John C Klensin wrote: > > >--On Tuesday, 22 August, 2006 11:10 -0700 Addison Phillips > wrote: >> This is a common misperception. The logical order of the text >> is left-to-right until the [ SP text ] is reached. This text >> is rendered RTL, if appropriate to do so, up to the CRLF >> (which ends the RTL "run"). See http://www.w3.org/TR/CharMod >> and http://www.unicode.org/reports/tr9/ > >Exactly (!). If I said that badly, I apologize, but I read >821/ 2821 as requiring a three digit code and the SP (in >left-to-right order) followed by "text". The protocol only defines logical order, i.e. on the wire, the bytes for the three digit code are followed by (a SP and then) the extended error code and then (a SP and then) the TEXT. As Doug has said, how to display these is entirely up to the client. For an Arabic or Hebrew client, something like [(RTL) TEXT goes here] 5.1.1 550 is okay and may make sense. >The extended status >code stuff is specific about the text, but wasn't written >anticipating internationalization and is not required by the >proposed specification anyway. And, to the best of my >knowledge, there is no standard requiring the used of W3C >CharMod or Unicore TR9 in Internet mail replies. TR9 is an Unicode Standards Annex (UAX), which means it is part of the Standard. In many ways, at the very moment you say UTF-8, you include it. For the IETF, http://www.rfc-editor.org/rfc/rfc3629.txt normatively references Unicode 4.0, and this includes TR9 at http://www.unicode.org/unicode/standard/versions/components-4.0.0.html (and I'm sure that the actual book says the same). >> The examples given are not very convincing. However... I tend >> to agree that this is the wrong model. The design of SMTP and >> other protocols is such that user-agents can present >> "friendly" messages (including localized messages) to end >> users. Almost no one interacts with SMTP servers directly. > >Right I think I agree to quite some extent with John and Addison, but as most of us know and Harald has shown again, the situation with SMTP error message consistency is much worse than with any other, comparable protocol. Also, while these error messages with their codes may not have been intended to be show to users, they routinely turn up in bounce messages, which go directly to the end user. Telling the end user that s/he may have mistyped an address should be done in the user's language, should not require support staff invention, and should not be treated as a protocol debugging problem. For EAI, I think it would be immensly helpful to have return messages defined with enough precision so that an MUA receiving a bounce can tell the user directly, or otherwise take an appropriate action (e.g. flagging the relevant entry in the address book as questionable) without necessarily having to show the actual message to the user. If we don't manage to get that for EAI, where we have a fresh slate, I don't think we are in a position to try anything for the vast reminder of error codes and error messages. 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 Aug 23 22:52:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG5K6-00061B-Sa; Wed, 23 Aug 2006 22:52:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG5K5-000616-OR for ltru@lists.ietf.org; Wed, 23 Aug 2006 22:52:01 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG5K0-00041D-FE for ltru@lists.ietf.org; Wed, 23 Aug 2006 22:52:01 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GG5Jq-00028Q-Nb for ltru@lists.ietf.org; Thu, 24 Aug 2006 04:51:46 +0200 Received: from pd9fbad01.dip0.t-ipconnect.de ([217.251.173.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Aug 2006 04:51:46 +0200 Received: from nobody by pd9fbad01.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Aug 2006 04:51:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 24 Aug 2006 04:50:51 +0200 Organization: Lines: 14 Message-ID: <44ED140B.6B8A@xyzzy.claranet.de> References: <010301c6c678$71f95a60$060aa8c0@DGBP7M81> <01M6C52TCA600008CX@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad01.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Ned Freed wrote: > Now that NOTARY is at draft, it's probably time to drag RFC > 2034 forward as well. Any objections? No, what does it take, an implementation report ? Almost an erratum for RFC 4408, where it references RFC 3464 it should also reference RFC 3463 and RFC 2034 - the section mentioning 5.7.1 is written from the server's POV. If you need a note about this from someone who claims to know what RFC 4408 is I can do. Maybe fup2 the SMTP list. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 23 23:08:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG5Zk-0004Fz-LG; Wed, 23 Aug 2006 23:08:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG5Zj-0004Ew-U9 for ltru@lists.ietf.org; Wed, 23 Aug 2006 23:08:11 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG5N2-0004tC-8I for ltru@lists.ietf.org; Wed, 23 Aug 2006 22:55:05 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1GG5N0-0002fE-Ju for ltru@lists.ietf.org; Thu, 24 Aug 2006 04:55:02 +0200 Received: from pd9fbad01.dip0.t-ipconnect.de ([217.251.173.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Aug 2006 04:55:02 +0200 Received: from nobody by pd9fbad01.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Aug 2006 04:55:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 24 Aug 2006 03:47:33 +0200 Organization: Lines: 23 Message-ID: <44ED0534.6C05@xyzzy.claranet.de> References: <6.0.0.20.2.20060823180516.18837b20@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad01.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ltru] Re: Fwd: Response to Part 1 of the appeal by JFC Morfin dated 2006-08-17 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > This should be of interest to you Admittedly I didn't read much of part two. Some poor folks are probably forced to read all of this. The first part is clear, appealing a decision before the decision isn't possible, that counts as contribution. Or as threat. Or more likely as humour, IIRC this contributor proposed to accelerate the publication of 3066bis, "appealing" the same proposal from a third party is incoherent... > follow the progress of our documents ...out of curiosity, does the IETF recognize Unicode (the organization) as SDO ? For the W3C I know that there is an official liaison. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 23 23:37:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG61i-0001TR-DI; Wed, 23 Aug 2006 23:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG61h-0001SP-4Z for ltru@lists.ietf.org; Wed, 23 Aug 2006 23:37:05 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG61e-0004yf-HP for ltru@lists.ietf.org; Wed, 23 Aug 2006 23:37: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 k7O3b0AB010407; Thu, 24 Aug 2006 12:37:00 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 16b6_cd120dbe_3321_11db_88ba_0014221f2a2d; Thu, 24 Aug 2006 12:37:00 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7O3aqEk004615; Thu, 24 Aug 2006 12:36:58 +0900 Message-Id: <6.0.0.20.2.20060824121354.08db0b30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 24 Aug 2006 12:14:32 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Fwd: Response to Part 1 of the appeal by JFC Morfin dated2006-08-17 In-Reply-To: <44ED0534.6C05@xyzzy.claranet.de> References: <6.0.0.20.2.20060823180516.18837b20@localhost> <44ED0534.6C05@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 10:47 06/08/24, Frank Ellermann wrote: >...out of curiosity, does the IETF recognize Unicode >(the organization) as SDO ? For the W3C I know that >there is an official liaison. Yes. Please see http://www.ietf.org/liaisonActivities.html for the full list. 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 Aug 23 23:37:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG61h-0001SU-66; Wed, 23 Aug 2006 23:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG61g-0001SK-6l for ltru@lists.ietf.org; Wed, 23 Aug 2006 23:37:04 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG61e-0004ye-HK for ltru@lists.ietf.org; Wed, 23 Aug 2006 23:37:04 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k7O3b0Zx001975; Thu, 24 Aug 2006 12:37:00 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 024c_cd1e3ac6_3321_11db_8121_0014221fa3c9; Thu, 24 Aug 2006 12:36:59 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7O3aqEm004615; Thu, 24 Aug 2006 12:37:00 +0900 Message-Id: <6.0.0.20.2.20060824121542.08daaa70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 24 Aug 2006 12:18:44 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses In-Reply-To: <44ED140B.6B8A@xyzzy.claranet.de> References: <010301c6c678$71f95a60$060aa8c0@DGBP7M81> <01M6C52TCA600008CX@mauve.mrochek.com> <44ED140B.6B8A@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Frank, It may not have been your fault that at some point, the other mailing list (ima@ietf.org) that I originally cross-posted got lost. But the mail below, apart from being cryptic except for people who have remembering RFC numbers as a hobby, is all about email and nothing about language codes, so the LTRU list is definitely the wrong list to post to. Regards, Martin. At 11:50 06/08/24, Frank Ellermann wrote: >Ned Freed wrote: > >> Now that NOTARY is at draft, it's probably time to drag RFC >> 2034 forward as well. Any objections? > >No, what does it take, an implementation report ? Almost an >erratum for RFC 4408, where it references RFC 3464 it should >also reference RFC 3463 and RFC 2034 - the section mentioning >5.7.1 is written from the server's POV. If you need a note >about this from someone who claims to know what RFC 4408 is I >can do. Maybe fup2 the SMTP list. > >Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 23 23:37:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG61i-0001TR-DI; Wed, 23 Aug 2006 23:37:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG61h-0001SP-4Z for ltru@lists.ietf.org; Wed, 23 Aug 2006 23:37:05 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG61e-0004yf-HP for ltru@lists.ietf.org; Wed, 23 Aug 2006 23:37: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 k7O3b0AB010407; Thu, 24 Aug 2006 12:37:00 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 16b6_cd120dbe_3321_11db_88ba_0014221f2a2d; Thu, 24 Aug 2006 12:37:00 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7O3aqEk004615; Thu, 24 Aug 2006 12:36:58 +0900 Message-Id: <6.0.0.20.2.20060824121354.08db0b30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 24 Aug 2006 12:14:32 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Fwd: Response to Part 1 of the appeal by JFC Morfin dated2006-08-17 In-Reply-To: <44ED0534.6C05@xyzzy.claranet.de> References: <6.0.0.20.2.20060823180516.18837b20@localhost> <44ED0534.6C05@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 10:47 06/08/24, Frank Ellermann wrote: >...out of curiosity, does the IETF recognize Unicode >(the organization) as SDO ? For the W3C I know that >there is an official liaison. Yes. Please see http://www.ietf.org/liaisonActivities.html for the full list. 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 Aug 23 23:37:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG61h-0001SU-66; Wed, 23 Aug 2006 23:37:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG61g-0001SK-6l for ltru@lists.ietf.org; Wed, 23 Aug 2006 23:37:04 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG61e-0004ye-HK for ltru@lists.ietf.org; Wed, 23 Aug 2006 23:37:04 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k7O3b0Zx001975; Thu, 24 Aug 2006 12:37:00 +0900 (JST) Received: from (133.2.210.1) by scmse1.scbb.aoyama.ac.jp via smtp id 024c_cd1e3ac6_3321_11db_8121_0014221fa3c9; Thu, 24 Aug 2006 12:36:59 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7O3aqEm004615; Thu, 24 Aug 2006 12:37:00 +0900 Message-Id: <6.0.0.20.2.20060824121542.08daaa70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 24 Aug 2006 12:18:44 +0900 To: Frank Ellermann , ltru@lists.ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses In-Reply-To: <44ED140B.6B8A@xyzzy.claranet.de> References: <010301c6c678$71f95a60$060aa8c0@DGBP7M81> <01M6C52TCA600008CX@mauve.mrochek.com> <44ED140B.6B8A@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Hello Frank, It may not have been your fault that at some point, the other mailing list (ima@ietf.org) that I originally cross-posted got lost. But the mail below, apart from being cryptic except for people who have remembering RFC numbers as a hobby, is all about email and nothing about language codes, so the LTRU list is definitely the wrong list to post to. Regards, Martin. At 11:50 06/08/24, Frank Ellermann wrote: >Ned Freed wrote: > >> Now that NOTARY is at draft, it's probably time to drag RFC >> 2034 forward as well. Any objections? > >No, what does it take, an implementation report ? Almost an >erratum for RFC 4408, where it references RFC 3464 it should >also reference RFC 3463 and RFC 2034 - the section mentioning >5.7.1 is written from the server's POV. If you need a note >about this from someone who claims to know what RFC 4408 is I >can do. Maybe fup2 the SMTP list. > >Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 24 00:06:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG6UF-000564-0l; Thu, 24 Aug 2006 00:06:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG6UC-00055A-IX for ltru@lists.ietf.org; Thu, 24 Aug 2006 00:06:32 -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 1GG6UC-0001kt-G4 for ltru@lists.ietf.org; Thu, 24 Aug 2006 00:06:32 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GG6Gn-0006nE-MJ for ltru@lists.ietf.org; Wed, 23 Aug 2006 23:52:45 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GG6Gk-00020n-9a for ltru@lists.ietf.org; Thu, 24 Aug 2006 05:52:38 +0200 Received: from pd9fbad01.dip0.t-ipconnect.de ([217.251.173.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Aug 2006 05:52:38 +0200 Received: from nobody by pd9fbad01.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Aug 2006 05:52:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 24 Aug 2006 05:52:09 +0200 Organization: Lines: 63 Message-ID: <44ED2269.70F3@xyzzy.claranet.de> References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> <44EB4886.5010009@yahoo-inc.com> <6.0.0.20.2.20060824072912.08dc0e60@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad01.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: -2.6 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ima@ietf.org Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 inSMTP responses X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > TR9 is an Unicode Standards Annex (UAX), which means it is > part of the Standard. In many ways, at the very moment you > say UTF-8, you include it. You could take UTF-8 as "ASCII plus opaque garbage" in various protocols, and then other parts of [Unicode] are not relevant. Nobody's forced to use say Unicode collation or hyphenation only because (s)he uses UTF-8 referencing STD 63, Another example would be 3066bis, it references ISO 3166. Nobody using language tags is now forced to use also 3166-3 codes, they can still make up their own stuff, use CLDR or what else. > as most of us know and Harald has shown again, the situation > with SMTP error message consistency is much worse than with > any other, comparable protocol. The RFC 4408 folks made sure that URIs work, indirectly that arrives as whatever e.g. http offers. A scenario for RFC 4408 is a user trying to send on a route not permitted by the sender policy of his domain. What really happens: User submits mail to the "wrong" MSA, and this MSA doesnt't enforce submission rights (RFC 4409 6.1), it tries to forward the mail towards the recipient. The MX checks the sender policy (RFC 4408) by querying a nameserver of the domain in the Return-Path. That policy says "FAIL" and offers an explanation in the form of an URI (optional of course). The MX "encodes" this as 5.7.1 error response (RFC 2034) - oops, the 2034-reference was still correct in draft 00, odd, maybe the missing 2034 was my bad - while talking with the "wrong" MSA (or its mailout). Of course the MX is not forced to add the explanation of this third party to its 5.7.1, but it can, let's assume that it did. The MSA had accepted the mail for forward or delivery, and that didn't work, therefore it MUST (RFC 821/2821) generate a non- delivery message (aka "bounce", not the definition in 2821). It will probably copy the 5.7.1 error message verbatim into its non-delivery message. It then puts the error message in the mailbox of the user of this domain. Or forwards it if the user arranged it this way. Later the user finds the bounce, that quotes the 5.7.1 (maybe), and the 5.7.1 quotes the FAIL-explanation (maybe), that is an URI, and now the user can contact that URI (maybe), and if it is HTTP depending on the server, the browser, LTRU, matching, and some other details the user can read the explanation of an admin in his domain in their preferred language, why this mail didn't make it on the wrong route. That's in a nutshell the reason why there are no explicit I18N considerations in RFC 4408: It would never do to tunnel some non-ASCII text from DNS through a 5.7.1 and a bounce, besides it would be pointless, the domain can have many users with many different languages. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 24 00:49:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG7A0-0001dn-CG; Thu, 24 Aug 2006 00:49:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GG79z-0001dc-32 for ltru@lists.ietf.org; Thu, 24 Aug 2006 00:49:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GG79w-0002YO-ON for ltru@lists.ietf.org; Thu, 24 Aug 2006 00:49:43 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GG79e-0003eQ-J6 for ltru@lists.ietf.org; Thu, 24 Aug 2006 06:49:22 +0200 Received: from pd9fbad01.dip0.t-ipconnect.de ([217.251.173.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Aug 2006 06:49:22 +0200 Received: from nobody by pd9fbad01.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 24 Aug 2006 06:49:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 24 Aug 2006 06:33:15 +0200 Organization: Lines: 34 Message-ID: <44ED2C0B.B6A@xyzzy.claranet.de> References: <010301c6c678$71f95a60$060aa8c0@DGBP7M81> <01M6C52TCA600008CX@mauve.mrochek.com> <44ED140B.6B8A@xyzzy.claranet.de> <6.0.0.20.2.20060824121542.08daaa70@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbad01.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > at some point, the other mailing list (ima@ietf.org) that I > originally cross-posted got lost. But the mail below, apart > from being cryptic except for people who have remembering > RFC numbers as a hobby, is all about email and nothing > about language codes, so the LTRU list is definitely > the wrong list to post to. Yes, I also can't tell why EAI discussions appear here, and Alexey's draft is about I18N for SMTP responses - neither EAI nor LTRU, that's why I proposed a followup to the SMTP list: >> Maybe fup2 the SMTP list. The cryptic 3461...3464 was my attempt to dedcode the "NOTARY", apparently the WG creating the predecessors 1891...1894 more than a decade ago, completely unrelated to language tags, this is about (mail) delivery status notifications. As you've seen in another article there is something in common between RFC 2034, EAI, and LTRU, at some point or another they try to use Unicode for I18N. In another article you said: > Please see http://www.ietf.org/liaisonActivities.html Thanks for info, appparently added (1)(2) April 2006, the last time I checked this page was in 2005. Frank 1: https://datatracker.ietf.org/public/liaisons.cgi 2: https://datatracker.ietf.org/documents/LIAISON/file305.pdf _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 24 22:13:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGRC0-0006nz-76; Thu, 24 Aug 2006 22:13:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGIKC-0008ET-Ic; Thu, 24 Aug 2006 12:45:00 -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 1GGG6v-0007nv-VW; Thu, 24 Aug 2006 10:23:10 -0400 Received: from lon-mail-1.gradwell.net ([193.111.201.125]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGFsM-0004zP-A3; Thu, 24 Aug 2006 10:08:14 -0400 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3^clerew#man^ac$uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 44edb2bf.3c15.334; Thu, 24 Aug 2006 15:07:59 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k7OE7uts004672; Thu, 24 Aug 2006 15:07:56 +0100 (BST) To: "LTRU Working Group" , ima@ietf.org Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 inSMTP responses References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> <44EB4886.5010009@yahoo-inc.com> <6.0.0.20.2.20060824072912.08dc0e60@localhost> Message-ID: Date: Thu, 24 Aug 2006 15:07:55 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <6.0.0.20.2.20060824072912.08dc0e60@localhost> User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Spam-Score: -2.6 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Thu, 24 Aug 2006 22:13:07 -0400 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 On Wed, 23 Aug 2006 23:50:58 +0100, Martin Duerst wrote: > At 04:48 06/08/23, John C Klensin wrote: >> >> >> --On Tuesday, 22 August, 2006 11:10 -0700 Addison Phillips >> wrote: > >>> This is a common misperception. The logical order of the text >>> is left-to-right until the [ SP text ] is reached. This text >>> is rendered RTL, if appropriate to do so, up to the CRLF >>> (which ends the RTL "run"). See http://www.w3.org/TR/CharMod >>> and http://www.unicode.org/reports/tr9/ >> >> Exactly (!). If I said that badly, I apologize, but I read >> 821/ 2821 as requiring a three digit code and the SP (in >> left-to-right order) followed by "text". > > The protocol only defines logical order, i.e. on the wire, the > bytes for the three digit code are followed by (a SP and then) > the extended error code and then (a SP and then) the TEXT. > As Doug has said, how to display these is entirely up to the > client. For an Arabic or Hebrew client, something like > [(RTL) TEXT goes here] 5.1.1 550 > is okay and may make sense. Actually, I don't see a problem. The "[(RTL) TEXT goes here] 5.1.1 550", if that is how it appears, should be fine for the human reader. Nothing breaks protocol-wise. For an agent which needs to take some protocol action (e.g. whether to hold on to the message and try again later), all it needs to see is the "550", and for that all it has to do is to look as the first 3 characters as they come off the wire -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131     Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 25 06:48:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGZEz-0008QB-TC; Fri, 25 Aug 2006 06:48:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGZEx-0008Px-89; Fri, 25 Aug 2006 06:48:43 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGZEv-00069M-Ph; Fri, 25 Aug 2006 06:48:43 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 72EF0259706; Fri, 25 Aug 2006 12:46:44 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32076-01; Fri, 25 Aug 2006 12:46:38 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D0FB82596FC; Fri, 25 Aug 2006 12:46:38 +0200 (CEST) Message-ID: <44EED583.4080503@alvestrand.no> Date: Fri, 25 Aug 2006 03:48:35 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: WG Review: Recharter of Language Tag Registry Update (ltru) References: <003f01c6c672$c2ae1dc0$060aa8c0@DGBP7M81> In-Reply-To: <003f01c6c672$c2ae1dc0$060aa8c0@DGBP7M81> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: LTRU Working Group , ietf@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 Doug Ewell wrote: > On Tue, 22 Aug 2006 10:23:54 -0400, IESG Secretary secretary at ietf dot org> wrote: > >> A modified charter has been submitted for the Language Tag Registry >> Update (ltru) working group in the Applications Area of the IETF. >> The IESG has not made any determination as yet. The modified charter >> is provided below for informational purposes only. Please send your >> comments to the IESG mailing list (iesg@ietf.org) by August 29th. >> >> ... >> >> Goals and Milestones: >> >> September 2006 Submit first WG draft of registry procedure update >> September 2006 Submit first WG draft of registry data update >> January 2007 Submit registry procedure update draft for IETF Last Call >> January 2007 Submit registry data update draft for IETF Last Call > > As the likely editor of the "registry data update" document, I'd like > to request that the milestones for the first drafts be extended to > October, or perhaps even November, and that the milestones for Last > Call drafts remain at least 3 months after the first drafts (e.g. > moving them to February if the first drafts arrive in November). > > Having experienced many lengthy delays in LTRU 1.0, which pushed the > original milestones out by many months, I'd like to make sure we have > a reasonable chance of hitting the LTRU 2.0 dates. There are several > issues to be discussed within the WG before realistic first drafts can > be written. The decision on the new charter will not be made until at > least August 29, leaving only 32 days to discuss these issues and > write drafts before the first milestone. I concur. Note also that if the ISO process is delayed for any reason, the completion timelines will also have to move; ISO does not have a stellar track record of keeping schedules either. Harald _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 25 08:39:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGaxe-0003kJ-EO; Fri, 25 Aug 2006 08:38:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGaxc-0003bG-IG for ltru@lists.ietf.org; Fri, 25 Aug 2006 08:38:56 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGaxb-0004Xe-4Z for ltru@lists.ietf.org; Fri, 25 Aug 2006 08:38:56 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GGax4-0007LY-6L for ltru@lists.ietf.org; Fri, 25 Aug 2006 14:38:22 +0200 Received: from pd9fba96d.dip0.t-ipconnect.de ([217.251.169.109]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Aug 2006 14:38:22 +0200 Received: from nobody by pd9fba96d.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 25 Aug 2006 14:38:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Fri, 25 Aug 2006 14:37:13 +0200 Organization: Lines: 54 Message-ID: <44EEEEF9.36CA@xyzzy.claranet.de> References: <20060823100003.F0CF52596DA@eikenes.alvestrand.no> <00b301c6c6be$8aee3270$060aa8c0@DGBP7M81> <44ECDA77.4080508@yahoo-inc.com> <30b660a20608231715i79be71afra07321d8985eafbe@mail.gmail.com> <20060824134848.GD20471@ccil.org> <44EDB914.4FB7@xyzzy.claranet.de> <20060824165736.GJ2769@ccil.org> <30b660a20608241124j235d22e6r960d1f7f60da8a48@mail.gmail.com> <44EE4C6F.7020809@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba96d.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [Ltru] Re: New item in ISO 639-2 - Zaza X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > one can match language tags "at a glance". > I think that is a Good Thing. Where that works, sure. The hypothetical Ryukyu "rkn" was an attempt to create a worst case. > 1. Any ISO 639-3 code that is a "sublanguage" of an existing, > non-deprecated language subtag (and preferably an > acknowledged macrolanguage) is made an extlang. > 2. All others are language subtags. > 3. Once a language subtag, always a language subtag. Once an > extlang, always an extlang. +3 so far. > 4. If a new macro-language code is introduced that would > encompass existing codes, it is put into the registry as a > deprecated language subtag. That solves the hypothetical "rkn" mess. > zh-cmn (right) > cmn (wrong) > rkn (right, deprecated) > ams (right) > rkn-ams (wrong) Good, I arrived at "rkn-ams (right, deprecated)", but "wrong" is probably better. At this point you've lost the info that "ams" is related to "exa" based on a (deprecated) "rkn-exa". On the other hand you've no zoo of deprecated synonyms. The lost info could be kept as comment in "rkn", but comments are not meant to be machine-readable meta-data. > Another way of saying this is that a code is either a > language subtag or an extlang at birth and this can never > change. Noted, I hope that makes it into the first draft. > Incidentally, why are we discussing this here and not on the > LTRU list? Because nobody bothered to change the subject... I don't like to change the subject and the list simultaneously, it could break threading where the references header field is lost. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 25 13:03:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGf5n-0002mX-PY; Fri, 25 Aug 2006 13:03:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGf5m-0002m0-Q0 for ltru@ietf.org; Fri, 25 Aug 2006 13:03: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 1GGekg-0005gM-5y for ltru@ietf.org; Fri, 25 Aug 2006 12:41:50 -0400 Received: from mail3.microsoft.com ([131.107.1.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGefv-0000g2-5x for ltru@ietf.org; Fri, 25 Aug 2006 12:36:57 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Fri, 25 Aug 2006 09:36:54 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 09:36:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 09:36:25 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New item in ISO 639-2 - Zaza Thread-Index: AcbHS/BQPeuw1r4tSCWibfwA3VN7LQAhzAjAACQWwsA= From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 25 Aug 2006 16:36:54.0191 (UTC) FILETIME=[AC6F7BF0:01C6C864] X-Spam-Score: -2.6 (--) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Ltru] RE: New item in ISO 639-2 - Zaza X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages- > bounces@alvestrand.no] On Behalf Of Peter Constable > > The fallback problem has been considered paramount to this point, = and > > was the reason for inventing extended language subtags in the first > > place. >=20 > My recollection is that the idea of extended language subtags was my = idea, and that > fallback was not the paramount reason why it occurred to me that we do = that. Someone asked me offlist for further explanation; I thought I provide = that for the list. The general, underlying issue that was behind this was the need to deal = on the one hand with users that prefer to =FD=FD"clump" and on the other = with users that like to split in certain cases involving very = =FDclosely-related varieties. That was specifically manifested in that = 639-2 had for some =FDtime included identifiers for single entities it = considered "individual" languages (not =FDcollections) that corresponded = in the source data sets for 639-3 to multiple =FDlanguages. =FD Early in our work toward 639-3 (actually before it was an approved work = item), Gary =FDSimons and I established a set of guidelines for mapping = how to map between =FDentries in ISO 639-2 and those in Ethnologue. For = cases that had these 1-to-many =FDmappings, we initially adopted a = principle that, if within the cluster of languages =FDthere was one = variety that was dominant -- significantly larger population and with a = =FDsignificant difference in the degree of language development (use in = media, =FDeducation, etc.), then we would equate the item in 639-2 with = that particular variety.=FD (That principle has thus far been applied in one case: Western Frisian.) In the course of working on 3066bis, however, I realized that that left = a problem. =FDThis struck me particularly in the case of Chinese: there = is long established usage of =FD=FD"zh", and that usage is ambiguous: it = doesn't differentiate between distinct =FDlanguages like Cantonese and = Mandarin. Plus, the IANA registry already had =FDaccepted tags of the = form "zh-yue" etc.: the initial thought was to treat them as = =FDgrandfathered anomalies, but of course there's always some preference = to have a model in =FDwhich everything is systematic rather than having = ad-hoc anomalies. =FD Considering those, it suddenly struck me that there was a way to bridge = the =FDclumping / legacy usage with the distinctions we wanted to add in = 639-3: rather than =FDtry to force the clumped items in 639-2 into a = more granular inventory, we could =FDaccept them as they are: ambiguous = clumps -- "macrolanguages" (I couldn't think of =FDany better term); and = if we simply provided a normative mapping between a =FDmacrolanguage and = the individual languages it encompasses, then that could provide =FDa = basis for creating a model in 3066bis that treated things like "zh-yue" = as systematic =FDrather than anomalies.=FD The fallback behaviour is a by-product of the multi-subtag form of those = tags and the =FDfallback mechanism that already existed in RFC 3066. = That wasn't the main purpose in my =FDmind for proposing the addition of = extlang in the syntax for RFC 3066bis. Rather, the =FDreason was simply = to provide a bridge between users that like to clump and those =FDthat = like to split; and a bridge between legacy in 639-2 and the IANA = registry and =FDwhat was coming in 639-3.=FD Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 25 13:10:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfCP-0007bz-Bb; Fri, 25 Aug 2006 13:10:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGfCO-0007bu-9B for ltru@ietf.org; Fri, 25 Aug 2006 13:10:28 -0400 Received: from mail1.microsoft.com ([131.107.1.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGfCL-0001oq-0C for ltru@ietf.org; Fri, 25 Aug 2006 13:10:28 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 10:10:23 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Fri, 25 Aug 2006 10:10:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 10:09:30 -0700 Message-ID: In-Reply-To: <20060825160000.GH16350@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New item in ISO 639-2 - Zaza Thread-Index: AcbIX4yXpB9TJoEDSzm2rgoIByBQNwACVCWQ From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 25 Aug 2006 17:10:23.0721 (UTC) FILETIME=[5A356D90:01C6C869] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ltru] RE: New item in ISO 639-2 - Zaza X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [moving to LTRU] > From: John Cowan [mailto:cowan@ccil.org] > > our protocols. (Which is exactly the same thing I'd say wrt the 639-1 > > "freeze": we don't need any guarantees from the JAC about new alpha-2 > > IDs; we can simply decide that we will not allow use any new alpha-2 > > IDs from this point forward.) >=20 > At the moment, we have no such option: if the various RAs and MAs add > a new code element, we MUST add it to the registry. The most we can > do is deprecate it on the spot. >=20 > If we want to add the option to reject (and I'd be nervous about it -- > this list could in future be captured by Not Invented Here bigots), > we need to add it to 3066ter. I suggested it for 3066bis, but either most weren't interested or the focus was on other issues at the time. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Aug 25 14:16:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgE0-00086U-P6; Fri, 25 Aug 2006 14:16:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGgDz-00086F-JR for ltru@ietf.org; Fri, 25 Aug 2006 14:16:11 -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 1GGfG9-0002d2-Jh for ltru@ietf.org; Fri, 25 Aug 2006 13:14:21 -0400 Received: from mail3.microsoft.com ([131.107.1.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GGf49-0001N2-BV for ltru@ietf.org; Fri, 25 Aug 2006 13:01:59 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Fri, 25 Aug 2006 10:00:56 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.154]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 25 Aug 2006 10:00:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Aug 2006 09:59:57 -0700 Message-ID: In-Reply-To: <20060825154812.GF16350@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New item in ISO 639-2 - Zaza Thread-Index: AcbIXegWE5LqkIjHTsCrqPFSZUrNwAABtWFQ From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 25 Aug 2006 17:00:55.0610 (UTC) FILETIME=[079691A0:01C6C868] X-Spam-Score: -2.6 (--) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Ltru] RE: New item in ISO 639-2 - Zaza X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [moving my response to LTRU] > From: John Cowan [mailto:cowan@ccil.org] > > It is not out of the question that new macrolanguage entities might > > get created in ISO 639, however, if there is a clear user need for > > such an entity. That was precisely what led to the addition at this > > time of a macrolanguage entity for Zaza. >=20 > Do you have the details? I'd be interested to know just why a > macrolanguage seemed appropriate (as opposed to registering the > two encompassed languages separately in 639-2). We got a request from a librarian. They specifically wanted an entry that included both. (There was confusion at first about what they were asking for, but when it got cleared up, it was clear they needed a macrolanguage entry.) =20 > > My thought is: if a new macrolanguage yyy is added to 639 for which > > there are macrolanguage mappings to some entity xxx that pre-existed, >=20 > This is the Zaza case, correct? A case like Zaza, yes. (Not in the Zaza case itself since we're not yet in the 3066ter era.) =20 > > or if macrolanguage mappings are added to some entity xxx that > > pre-existed >=20 > This case is entirely novel. I understand it to mean that we find out > that although Thwackian is as sharply divergent from both Northern and > Southern Thuddian as they are from each other, nevertheless people > in the Empire of Thud consider Thwackian just another local variety > of Our Glorious Thuddian Language, and so 639-3 adds Thwackian to the > macrolanguage "Thuddian". (LOL) My first "thwack" on the head to follow this resulted in a "thud"; let me try reading it again. OK, you're saying we have an existing macrolanguage "Thuddian" with macrolanguage mappings to existing languages "Northern Thuddian" and "Southern Thuddian", and now we add a macrolanguage mapping from "Thuddian" to an entry (new or existing) "Thwackian". That's not a scenario I was imagining -- haven't considered it, in fact. I was thinking of a case like Rawang: for now, there's only one entry, though we know it's highly likely it will get split out in the future; we just haven't had enough info on the varieties involved to create split entries yet. So, we have Rawang today as an individual language, and at some future point we have X, Y and Z, either deprecating Rawang or, probably more likely, with Rawang now as a macrolanguage encompassing X, Y and Z. Your "Thwackian" scenario might have some issues for 3066ter; the Rawang scenario does not. =20 Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 26 02:15:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGrRy-0005Zc-1J; Sat, 26 Aug 2006 02:15:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GGrRw-0005ZX-To for ltru@ietf.org; Sat, 26 Aug 2006 02:15:20 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGrRv-0001no-NV for ltru@ietf.org; Sat, 26 Aug 2006 02:15:20 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GGrRm-00041A-Qv; Sat, 26 Aug 2006 02:15:10 -0400 Date: Sat, 26 Aug 2006 02:15:10 -0400 To: Peter Constable Subject: Re: [Ltru] RE: New item in ISO 639-2 - Zaza Message-ID: <20060826061510.GB21932@ccil.org> References: <20060825154812.GF16350@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > OK, you're saying we have an existing macrolanguage "Thuddian" with > macrolanguage mappings to existing languages "Northern Thuddian" and > "Southern Thuddian", and now we add a macrolanguage mapping from > "Thuddian" to an entry (new or existing) "Thwackian". Just so. > That's not a scenario I was imagining -- haven't considered it, in fact. > I was thinking of a case like Rawang: for now, there's only one entry, > though we know it's highly likely it will get split out in the future; > we just haven't had enough info on the varieties involved to create > split entries yet. So, we have Rawang today as an individual language, > and at some future point we have X, Y and Z, either deprecating Rawang > or, probably more likely, with Rawang now as a macrolanguage > encompassing X, Y and Z. > > Your "Thwackian" scenario might have some issues for 3066ter; the Rawang > scenario does not. Agreed. -- But you, Wormtongue, you have done what you could for your true master. Some reward you have earned at least. Yet Saruman is apt to overlook his bargains. I should advise you to go quickly and remind him, lest he forget your faithful service. --Gandalf John Cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Aug 26 13:43:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH2Bk-0006rs-R5; Sat, 26 Aug 2006 13:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH2Bj-0006rl-IP for ltru@ietf.org; Sat, 26 Aug 2006 13:43:19 -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 1GH2Bj-0001Um-Gn for ltru@ietf.org; Sat, 26 Aug 2006 13:43:19 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GH1x1-0007y6-MY for ltru@ietf.org; Sat, 26 Aug 2006 13:28:09 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060826172801.BGQG4932.mta11.adelphia.net@DGBP7M81> for ; Sat, 26 Aug 2006 13:28:01 -0400 Message-ID: <000701c6c934$f62e2720$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Sat, 26 Aug 2006 10:27:49 -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.2962 X-Spam-Score: -2.6 (--) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [Ltru] Re: New item in ISO 639-2 - Zaza X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > In the course of working on 3066bis, however, I realized that that > left a problem. This struck me particularly in the case of Chinese: > there is long established usage of "zh", and that usage is ambiguous: > it doesn't differentiate between distinct languages like Cantonese and > Mandarin. Plus, the IANA registry already had accepted tags of the > form "zh-yue" etc.: the initial thought was to treat them as > grandfathered anomalies, but of course there's always some preference > to have a model in which everything is systematic rather than having > ad-hoc anomalies. This was pretty much my understanding all along, and I thought the question of whether we should use extended-language subtags for this scenario had been settled long ago. That was why we went to the effort of defining them and setting up examples in RFC 3066bis even though no such subtags were actually going to exist until 3066ter. I'm really surprised that we are rethinking this now and considering not using extlangs at all. > rather than try to force the clumped items in 639-2 into a more > granular inventory, we could accept them as they are: ambiguous clumps I know I'm supposed to understand intuitively whether "more granular" means "more finely grained" or "more coarsely grained," but it never works for me. In photography a "grainy" image is one where the grains are coarser and clearly visible. Later: >> At the moment, we have no such option: if the various RAs and MAs add >> a new code element, we MUST add it to the registry. The most we can >> do is deprecate it on the spot. >> >> If we want to add the option to reject (and I'd be nervous about >> it -- this list could in future be captured by Not Invented Here >> bigots), we need to add it to 3066ter. > > I suggested it for 3066bis, but either most weren't interested or the > focus was on other issues at the time. We were trying to avoid accusations of "cherry-picking" the ISO code lists, adopting the code elements we "liked" and ignoring the others without justification. We already do have a mechanism to reject -- more accurately, decline to create -- new subtags if they would conflict with existing ones. That is as close as we currently get to solving this problem. -- 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 Sat Aug 26 15:16:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH3dF-0007gH-TV; Sat, 26 Aug 2006 15:15:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH3dE-0007gC-IB for ltru@ietf.org; Sat, 26 Aug 2006 15:15:48 -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 1GH2aE-0003f3-TD for ltru@ietf.org; Sat, 26 Aug 2006 14:08:38 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GH2NU-0008PT-0R for ltru@ietf.org; Sat, 26 Aug 2006 13:55:30 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060826175527.CDCX4932.mta11.adelphia.net@DGBP7M81> for ; Sat, 26 Aug 2006 13:55:27 -0400 Message-ID: <001f01c6c938$ce85e1f0$6501a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <20060826100002.B479825971F@eikenes.alvestrand.no> Date: Sat, 26 Aug 2006 10:55:23 -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.2962 X-Spam-Score: -2.6 (--) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ltru] Stability of lprimary and extended language (was: Re: New item in ISO 639-2 - Zaza) X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote on ietf-languages@iana.org > If we have firm stability rules, then I'm ok with #2 also. But these > rules have to be very explicit and strong, something like: Once added > to the registry: > > - a language subtag may be deprecated, but never becomes an extlang > subtag > - an extlang subtag may be deprecated, but never becomes a language > subtag > - the relationship of an extlang to a language tag (its macro > language) may be deprecated, but is never removed. Using John's example of a language Thwackian which exists in 639- 3, and is subsequently listed under the macrolanguage Thuddian: Does this mean literally that if language subtag "tha" originally existed for Thwackian, a new extlang subtag "tha" cannot be created (with prefix "thn" for Thuddian) after the original "tha" is deprecated? Or does it simply mean the original "tha" can't be reclassified from one category to the other? I don't see any syntactical conflict in RFC 3066{bis, ter} if a language subtag "tha" and an extlang subtag "tha" (one of which is deprecated) both exist, even if ISO 639 doesn't define its codespace that way. The effect would be basically the same as Mark's scenario #3, which would allow both "tha" and "thn-tha" as synonyms, but no additional structure would be needed in the RFC; all the components would be present in the Registry. -- 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 Sat Aug 26 15:37:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH3xn-0000Xy-Mb; Sat, 26 Aug 2006 15:37:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GH3xm-0000Xt-7O for ltru@ietf.org; Sat, 26 Aug 2006 15:37:02 -0400 Received: from mail2.microsoft.com ([131.107.1.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GH3xg-0006Is-GH for ltru@ietf.org; Sat, 26 Aug 2006 15:37:02 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 26 Aug 2006 12:36:53 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Sat, 26 Aug 2006 12:36:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: New item in ISO 639-2 - Zaza Date: Sat, 26 Aug 2006 12:36:52 -0700 Message-ID: In-Reply-To: <000701c6c934$f62e2720$6501a8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Re: New item in ISO 639-2 - Zaza Thread-Index: AcbJNzr8A2vhzDPnSX+d1e123Yfs4AADydog From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 26 Aug 2006 19:36:53.0621 (UTC) FILETIME=[FBCF7A50:01C6C946] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0232618595==" Errors-To: ltru-bounces@ietf.org --===============0232618595== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBGcm9tOiBEb3VnIEV3ZWxsIFttYWlsdG86ZGV3ZWxsQGFkZWxwaGlhLm5ldF0NCg0KDQo+ID4g SSBzdWdnZXN0ZWQgaXQgZm9yIDMwNjZiaXMsIGJ1dCBlaXRoZXIgbW9zdCB3ZXJlbid0IGludGVy ZXN0ZWQgb3IgdGhlDQo+ID4gZm9jdXMgd2FzIG9uIG90aGVyIGlzc3VlcyBhdCB0aGUgdGltZS4N Cj4gDQo+IFdlIHdlcmUgdHJ5aW5nIHRvIGF2b2lkIGFjY3VzYXRpb25zIG9mICJjaGVycnktcGlj a2luZyIgdGhlIElTTyBjb2RlDQo+IGxpc3RzLCBhZG9wdGluZyB0aGUgY29kZSBlbGVtZW50cyB3 ZSAibGlrZWQiIGFuZCBpZ25vcmluZyB0aGUgb3RoZXJzDQo+IHdpdGhvdXQganVzdGlmaWNhdGlv bi4NCg0KUmlnaHQ7IEkgcmVtZW1iZXIgImNoZXJyeS1waWNraW5nIiBiZWluZyByZWZlcnJlZCB0 by4gTWluZCB5b3UsIEkgbmV2ZXIgY29uc2lkZXJlZCBpdCB0aGF0LCBhcyBJIGhhZCBpbiBtaW5k IGEgcGFydGljdWxhciBqdXN0aWZpY2F0aW9uOiByZWplY3RpbmcgYnkgcnVsZSBhbnkgbmV3IDYz OS0xIElEcyBmb3IgYWRkaXRpb24gdG8gdGhlIHN1YnRhZyByZWdpc3RyeSB3aGVyZSBhbiBhbHBo YS0zIGZyb20gNjM5LTIgYWxyZWFkeSBleGlzdGVkIHdvdWxkIGVsaW1pbmF0ZSBhIHBvdGVudGlh bCBzb3VyY2Ugb2YgaW5zdGFiaWxpdHkgaW4gbGFuZ3VhZ2UgdGFncy4NCg0KDQoNClBldGVyIENv bnN0YWJsZQ0K --===============0232618595== 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 --===============0232618595==-- From ltru-bounces@ietf.org Sun Aug 27 03:08:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHEkY-0000Ex-Ay; Sun, 27 Aug 2006 03:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHEkX-0000Em-Du for ltru@ietf.org; Sun, 27 Aug 2006 03:08:05 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHEkV-0000kR-6Z for ltru@ietf.org; Sun, 27 Aug 2006 03:08:05 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GHEkM-0000WY-M2; Sun, 27 Aug 2006 03:07:54 -0400 Date: Sun, 27 Aug 2006 03:07:54 -0400 To: Doug Ewell Subject: Re: [Ltru] Stability of lprimary and extended language (was: Re: New item in ISO 639-2 - Zaza) Message-ID: <20060827070754.GA29315@ccil.org> References: <20060826100002.B479825971F@eikenes.alvestrand.no> <001f01c6c938$ce85e1f0$6501a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001f01c6c938$ce85e1f0$6501a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Doug Ewell scripsit: > Does this mean literally that if language subtag "tha" originally > existed for Thwackian, a new extlang subtag "tha" cannot be created > (with prefix "thn" for Thuddian) after the original "tha" is deprecated? > Or does it simply mean the original "tha" can't be reclassified from one > category to the other? I believe that is what he means, yes. > I don't see any syntactical conflict in RFC 3066{bis, ter} if a language > subtag "tha" and an extlang subtag "tha" (one of which is deprecated) > both exist, even if ISO 639 doesn't define its codespace that way. The > effect would be basically the same as Mark's scenario #3, which would > allow both "tha" and "thn-tha" as synonyms, but no additional structure > would be needed in the RFC; all the components would be present in the > Registry. So they would, but it's not clear that the benefit of doing that (namely, that Thwackian content can be retrieved by asking for Thuddian) outweighs the advantages of stability. Hitherto we have deprecated codes only when clearly-better alternatives exist, and we never allow synonymous codes unless all but one are deprecated. -- As you read this, I don't want you to feel John Cowan sorry for me, because, I believe everyone cowan@ccil.org will die someday. http://www.ccil.org/~cowan --From a Nigerian-type scam spam _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 27 04:07:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHFfX-0001HR-7A; Sun, 27 Aug 2006 04:06:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHFfW-0001HM-4r for ltru@ietf.org; Sun, 27 Aug 2006 04:06:58 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHFfR-000680-GD for ltru@ietf.org; Sun, 27 Aug 2006 04:06:58 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k7R86RJf024984; Sun, 27 Aug 2006 17:06:27 +0900 (JST) Received: from (133.2.210.1) by scmse2.scbb.aoyama.ac.jp via smtp id 53e7_f09eda2c_35a2_11db_92e4_0014221f2a2d; Sun, 27 Aug 2006 17:06:26 +0900 Received: from Tanzawa.it.aoyama.ac.jp (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.7/8.13.1) with ESMTP id k7R86Op1004678; Sun, 27 Aug 2006 17:06:24 +0900 Message-Id: <6.0.0.20.2.20060827164728.05a3a350@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 27 Aug 2006 17:05:53 +0900 To: LTRU Working Group From: Martin Duerst In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: IANA Language Registration Subject: [Ltru] Topic selection, cross-posting, and Subjects X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [LTRU WG co-chair hat on] Executive summary: watch what you are posting where! It's eays to confuse ltru@ietf.org and ietf-languages@iana.org, but they both serve a very clear puprose (see below). It's also easy to reply to a message without changing the Subject, but changing the Subject when changing the subject/topic of the discussion is usually very valuable. ietf-languages@iana.org is for actual registrations of tags. This should be restricted to specific registrations. Any discussions of RFC 3066ter and related subjects on that list are rather useless, because they will have to be repeated if and when the actual work on RFC 3066ter starts. Clarifications on what RFC 3066bis says (for those who don't read it regularly or remember all the details) make sense. But any discussion about unclarities in RFC 3066bis (if there are any) or things that look like they may need an erratum should be brought to the ltru list. [Of course, not being responsible for the ietf-languages list, I leave any kind of enforcement, if deemed necessary, to the people in charge.] ltru@ietf.org is for discussions about RFC 3066bis (all three documents), in particular for clarifications and errata if they should be needed. It is also the best place to discuss possible future work (currently going under the label RFC 3066ter). This is in accordance with the IETF tradition to leave mailing lists of closed WGs open for these kinds of discussions. (Please note that the LTRU WG is not (yet) closed.) With respect to possible future work, the discussion will of course start in full if and when the LTRU WG is rechartered; for the moment, discussion is okay, but will have to remain non-conclusive. (Nobody can declare consensus on an issue that we haven't been chartered to deal with.) In short: Watch what you are posting where! 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 Sun Aug 27 10:27:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHLbV-00058L-Hl; Sun, 27 Aug 2006 10:27:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHLbU-00058D-Ow; Sun, 27 Aug 2006 10:27:12 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHLbT-0007so-8R; Sun, 27 Aug 2006 10:27:12 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Sun, 27 Aug 2006 15:26:38 +0100 Message-ID: <44F18DB8.4040601@isode.com> Date: Sun, 27 Aug 2006 13:19:04 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Tony Finch Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> <44EC3A45.90201@alvestrand.no> In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Greg Vaudreuil , LTRU Working Group , ima@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 Tony Finch wrote: >Addison says: > > >>Almost no one interacts with SMTP servers directly. >> >> >Of course they do, to the same extent that they interact with IMAP or POP >or HTTP servers - mediated by a user agent. > >From my point of view, and from the point of view of my colleagues on the >help desk, it would be much easier if MUAs did not try to impose their own >gloss on my servers' error messages (or do other stupid things like >truncate them). That way I can provide helpful text that explains what >went wrong, and/or a URL to help pages or a directory. > >The current set of enhanced status codes is non-orthogonal and does not >cover the range of possibilities or provide enough detail within their >coverage. > Having recently reviewed Enhanced Status Codes and error messages emitted by Isode's SMTP server, I fully agree with this statement. >For example, there are codes for bad syntax and bad domain for >both sender and recipient addresses, but you can only specifically say the >local part is bad for destination addresses, and there are different OK >codes for senders and recipients. There's a code for "too many recipients" >but not "too few recipients" (e.g. RFC 4468 has a different gloss of 5.5.0 >for this situation). In SMTP you can say that an address has changed (551) >but not with enhanced status codes. > (slightly off topic) Indeed. Some time ago I've tried to use 551 in order to implement Sieve redirect in LMTP server. I wanted to avoid adding SMTP client to Sieve engine, but after looking at Enhanced Status Codes I can only found: X.1.6 Destination mailbox has moved, No forwarding address while I was expecting a status code saying "mailbox moved, send your message here
". > (We've had a number departments >changing name recently where it might have been useful to use the 551 >feature, but since no-one implements it we just used an ad-hoc "try >newname.cam.ac.uk instead" error.) > Speaking of 551 and response boilerplates. Is there any interest in standardizing "mailbox moved, send your message here
" Enhanced Status Code with explicit boilerplate, so that the forwarding address is easily extractable? > The range of codes for client policy restrictions is inadequate: there's no way of expressing the distinction >between "relaying is not permitted", "you have been blacklisted", "you are >making too many concurrent connections", "you have been rate-limited", >"you have been greylisted", etc. There are no codes for saying that the >message content violates security restrictions, such as a virus infection >or a forbidden attachment type or a spam classification. > >Even if you solve these problems, there is no provision for extending the >set of status codes except as a standards action - there is no IANA >registry. And in fact an IANA registry wouldn't solve the problem because >no existing software will have glosses for any new status codes you might >register, so the new codes would be useless. > > Very true. Software is unlikely to be written to automatically download updates to an IANA registry. There are many cases when this is not practical or explicitly prohibited by IT department. >The idea of a fixed set of status codes is fundamentally unable to cope >with evolving operational requirements. > > _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Aug 27 10:27:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHLbX-00058f-NF; Sun, 27 Aug 2006 10:27:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHLbW-00058X-DC; Sun, 27 Aug 2006 10:27:14 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHLbU-0007so-S3; Sun, 27 Aug 2006 10:27:14 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Sun, 27 Aug 2006 15:26:40 +0100 Message-ID: <44F18DD7.90304@isode.com> Date: Sun, 27 Aug 2006 13:19:35 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses References: <44E09667.8070704@isode.com> <6.0.0.20.2.20060818150743.097d4ec0@localhost> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> <44EB4886.5010009@yahoo-inc.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: LTRU Working Group , ima@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John C Klensin wrote: >>> (1) This draft be dropped in favor of an effort to make >>> SMTP reply text easier to translate to other languages >>> or generate-able from the codes. >>> >>Allowing UTF-8 would still seem to be a Good Thing, since even >>boilerplate messages might need to include runtime data that >>is non-ASCII. Language negotiation is another issue. >> >> >Clearly, the EAI effort is going to need to deal, in some way, >with replies that contain non-ASCII addresses. But, as you say, >that is a different issue from language negotiation. > My draft is trying to address the following issues. Let's try to discuss them separately whenever possible, I will split the draft into multiple (or even drop some of them) based on feedback: 1). Allowing for UTF-8 in response text. This is required for both UTF-8 email addresses and localized human readable text 2). Language negotiation. If we agree that localized human readable text is a good idea, then there is a need for the sender to select a language. If the sender is Russian and the server emits responses in Chinese (or vice versa) by default, the response text would be of no much use for the sender. And as many others said, users end up seeing such text in non-delivery reports or in MUAs on message submission. 3). Allow for localized text in DSN messages. There are multiple ways of doing this: a). localize the first text/plain part b). extend format for message/delivery-status to allow for localized reason string, in addition to non-delivery reason in English. c). extend multipart/report to allow for extra bodyparts, that would convey this information. (I am not sure how well this will interoperate in real world, but I am listing this choice here for completeness) 4). Allow for UTF-8 addresses in DSN messages. There are also several ways of achieving this: a). Use ACE in message/delivery-status bodypart. b). Extend message/delivery-status to allow for 8bit data. RFC 3464 seem to disallow this: 2.1 The message/delivery-status content-type The message/delivery-status content-type is defined as follows: MIME type name: message MIME subtype name: delivery-status Optional parameters: none Encoding considerations: "7bit" encoding is sufficient and MUST be used to maintain readability when viewed by non-MIME mail readers. And RFC 2046 seem to advise against non-7bit encodings in message/*: 5.2.4. Other Message Subtypes MIME implementations must in general treat unrecognized subtypes of "message" as being equivalent to "application/octet-stream". Future subtypes of "message" intended for use with email should be restricted to "7bit" encoding. A type other than "message" should be used if restriction to "7bit" is not possible. Alexey P.S. However I still thing that encouraging servers to implement Enhanced Status Codes is a good idea. I would also like to work on response boilerplates. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 28 01:01:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHZFD-0000an-BT; Mon, 28 Aug 2006 01:01:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHZFC-0000ai-Gi for ltru@ietf.org; Mon, 28 Aug 2006 01:01:06 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHZF8-0007e0-69 for ltru@ietf.org; Mon, 28 Aug 2006 01:01:06 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060828050101.GUZH4932.mta11.adelphia.net@DGBP7M81> for ; Mon, 28 Aug 2006 01:01:01 -0400 Message-ID: <004d01c6ca5e$f2709980$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 27 Aug 2006 22:00:55 -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.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [Ltru] Extended language subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Randy and Martin both wrote on ietf-languages@iana.org that we can begin discussing issues related to RFC 3066ter on this list, as long as we don't attempt to claim consensus on any of the issues. That said, I'd like to start the broad discussion about extended language ("extlang") subtags. I doubt we will reach consensus on all of this before the charter is approved. My understanding, for well over a year, has been that languages that are included under a macrolanguage in ISO 639-3 would be mapped to extlang subtags, with that macrolanguage as their Prefix, while all other languages in 639-3 would be mapped to primary language subtags. (Those languages that have an ISO 639-1 alpha-2 code element would continue to use it as the subtag instead of the corresponding alpha-3 code element, for compatibility with RFC 1766 and 3066.) Using this model, the initial RFC 3066ter Registry would include approximately 7200 primary language subtags and approximately 350 extlang subtags. As recent discussions have shown, we will need to figure out what to do with the Registry if and when the ISO 639-3 mappings between individual languages and macrolanguages change. There is plenty of lively debate about that and I don't plan to rehash it here. One topic we have not addressed yet, which may involve extlang subtags, is sign languages. ISO 639-3 lists 124 languages with "Sign Language" in their name. It does not include the ISO 639-2 code element "sgn" ("Sign Languages"), which denotes a collection of languages and is therefore out of scope for 639-3 (but which does exist in the RFC 3066bis Registry). There is a precedent in RFC 3066 for using the "sgn" code element together with an ISO 3166 country code element (plus optionally other symbols) to tag specific sign languages. The classic example is "sgn-US" for American Sign Language (I will use it as my example for convenience only). This system was devised by Michael Everson and the Deaf Action Committee for Sign Writing, and is described at http://www.evertype.com/standards/iso639/sgn.html. Some of the sgn-combinations listed on that page are already registered under RFC 3066, and consequently they are listed as either grandfathered or redundant in the RFC 3066bis Registry; others are not. The ISO 639-3 code element for American Sign Language is "ase". ("asl" is the code element for Asilulu, a language of Indonesia.) If we convert such code elements directly to primary language subtags, as we will likely do for ordinary spoken/written languages that do not have a macrolanguage, then the RFC 3066ter tag for ASL would be "ase". Alternatively, we could choose to add all 639-3 code elements for sign languages as *extlang* subtags, with a Prefix of "sgn". Using this model, the RFC 3066ter tag for ASL would be "sgn-ase". This approach would have the advantage (if such it is) that the sign-language nature would be indicated as part of the tag. This does not necessarily imply any mutual compatibility between "sgn-xxx" languages, any more than the RFC 3066 scheme does. In either case, the existing grandfathered tag "sgn-US" would presumably be deprecated and given a Preferred-Value of either "ase" or "sgn-ase". I understand that Michael may not favor this approach, and may prefer to continue using the "sgn-US" system. There is potentially some material already tagged using these RFC 3066 identifiers. One significant drawback is that tags using this model that go beyond "sgn plus region" are not compatible with the RFC 3066bis syntax: sgn-AU-NT -- uses an ISO 3166-2 country-subdivision code sgn-IL-yi -- uses an ISO 639-1 language code sgn-SE-crp -- uses an ISO 639-2 language code Another drawback, at least in my view, is that the generative model tells us that "sgn-XX" means "sign languages as used in region XX", which can be misleading in regions where multiple sign languages are in common use. There is a strong identity between the concepts "American Sign Language" and "sign languages as used in the United States," but this may not hold for other sign languages. It's important to remember that "deprecated" tags are not invalid; they are simply not recommended for future tagging. Again, our goal right now needs to be to raise questions and consider scenarios, not to declare a Final Answer. -- 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 Mon Aug 28 01:52:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHa2R-0003oE-NB; Mon, 28 Aug 2006 01:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHa2Q-0003o9-QS for ltru@ietf.org; Mon, 28 Aug 2006 01:51:58 -0400 Received: from mail1.microsoft.com ([131.107.1.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHa2K-0006ZE-88 for ltru@ietf.org; Mon, 28 Aug 2006 01:51:58 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 Aug 2006 22:51:49 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 27 Aug 2006 22:51:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Extended language subtags Date: Sun, 27 Aug 2006 22:51:47 -0700 Message-ID: In-Reply-To: <004d01c6ca5e$f2709980$6401a8c0@DGBP7M81> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Extended language subtags Thread-Index: AcbKXw7OXvFA0R2uS22FNEg0AuNi7QABWQlA From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 28 Aug 2006 05:51:49.0629 (UTC) FILETIME=[0DF542D0:01C6CA66] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1908209971==" Errors-To: ltru-bounces@ietf.org --===============1908209971== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB5b3UgbmVlZCB0byBkZWNpZGU6IGFyZSB3ZSBkaXNjdXNzaW5nIGV4dGVuZGVkIGxh bmd1YWdlIHN1YnRhZ3MsIG9yIHRoZSB0YWdnaW5nIG9mIHNpZ25lZCBsYW5ndWFnZXM/IFRob3Nl IGFyZSB0d28gZGlmZmVyZW50IHRvcGljcywgYW5kIEkgdGhpbmsgeW91J3JlIGRpc2N1c3Npbmcg dGhlIGxhdHRlci4NCg0KSWYgd2Ugd2VyZSB0byBlbmNvZGUgdGhlIDYzOS0zIElEcyBmb3Igc2ln bmVkIGxhbmd1YWdlcyBhcyBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIHdpdGggYSBwcmVmaXgg b2YgInNnbiIsIHRoYXQgd291bGQgYmUgYW4gYWQtaG9jIGV4Y2VwdGlvbiB0byB0aGUgb3RoZXJ3 aXNlLWFwcGxpY2FibGUgcHJpbmNpcGxlIHRoYXQgZXZlcnkgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3Vi dGFnIGhhcyBhIG1hY3JvbGFuZ3VhZ2UgbWFwcGluZyB0byBpdHMgZGVzaWduYXRlZCBwcmVmaXgu DQoNCk15IGluY2xpbmF0aW9uIGhhcyBhbHdheXMgYmVlbiB0byB0cmVhdCBzaWduZWQgbGFuZ3Vh Z2VzIGxpa2UgYW55IG90aGVyIGxhbmd1YWdlLCBtZWFuaW5nIHRoYXQgd2UgdXNlIHRoZWlyIDYz OS0zIElEcyBhcyBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3MuIElmIE1pY2hhZWwgYW5kIHRoZSBE QUMgd2FudCBzb21lIHdheSB0byBpbmRpY2F0ZSB0aGF0IGNvbnRlbnQgaXMgaW4gU2lnbiBXcml0 aW5nLCB0aGUgYXBwcm9wcmlhdGUgd2F5IHRvIGRlYWwgd2l0aCB0aGF0IGlzIHRvIGNyZWF0ZSBh IHNjcmlwdCBJRCBpbiAxNTkyNCBhbmQgdXNlIHRoYXQgLS0gaS5lLiB0YWdzIGxpa2UgImFzZS1z Z253Ii4gDQoNCihJIGZpbmQgaXQgb2RkIHRoYXQgTWljaGFlbCBzYXcgdGhhdCAxNTkyNCBJRHMg d2VyZSBhZGRlZCBmb3Igc2NyaXB0cyB0aGF0IGFyZSBsb25nIGRlYWQgYnV0IGZvciBhbGwgaGlz IHN1cHBvc2VkIGludGVyZXN0IGluIHNpZ25lZCBsYW5ndWFnZXMgYW5kIFNpZ24gV3JpdGluZyB0 aGVyZSBpc24ndCBhbiBJU08gMTU5MjQgSUQgZm9yIGEgc2luZ2xlIHdyaXRpbmcgc3lzdGVtIHVz ZWQgaW4gcmVsYXRpb24gdG8gc2lnbmVkIGxhbmd1YWdlcy4pDQoNCg0KUGV0ZXIgQ29uc3RhYmxl DQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERvdWcgRXdlbGwg W21haWx0bzpkZXdlbGxAYWRlbHBoaWEubmV0XQ0KPiBTZW50OiBTdW5kYXksIEF1Z3VzdCAyNywg MjAwNiAxMDowMSBQTQ0KPiBUbzogTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFtMdHJ1 XSBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzDQo+IA0KPiBSYW5keSBhbmQgTWFydGluIGJvdGgg d3JvdGUgb24gaWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmcgdGhhdCB3ZSBjYW4gYmVnaW4NCj4gZGlz Y3Vzc2luZyBpc3N1ZXMgcmVsYXRlZCB0byBSRkMgMzA2NnRlciBvbiB0aGlzIGxpc3QsIGFzIGxv bmcgYXMgd2UNCj4gZG9uJ3QgYXR0ZW1wdCB0byBjbGFpbSBjb25zZW5zdXMgb24gYW55IG9mIHRo ZSBpc3N1ZXMuDQo+IA0KPiBUaGF0IHNhaWQsIEknZCBsaWtlIHRvIHN0YXJ0IHRoZSBicm9hZCBk aXNjdXNzaW9uIGFib3V0IGV4dGVuZGVkDQo+IGxhbmd1YWdlICgiZXh0bGFuZyIpIHN1YnRhZ3Mu ICBJIGRvdWJ0IHdlIHdpbGwgcmVhY2ggY29uc2Vuc3VzIG9uIGFsbCBvZg0KPiB0aGlzIGJlZm9y ZSB0aGUgY2hhcnRlciBpcyBhcHByb3ZlZC4NCj4gDQo+IE15IHVuZGVyc3RhbmRpbmcsIGZvciB3 ZWxsIG92ZXIgYSB5ZWFyLCBoYXMgYmVlbiB0aGF0IGxhbmd1YWdlcyB0aGF0IGFyZQ0KPiBpbmNs dWRlZCB1bmRlciBhIG1hY3JvbGFuZ3VhZ2UgaW4gSVNPIDYzOS0zIHdvdWxkIGJlIG1hcHBlZCB0 byBleHRsYW5nDQo+IHN1YnRhZ3MsIHdpdGggdGhhdCBtYWNyb2xhbmd1YWdlIGFzIHRoZWlyIFBy ZWZpeCwgd2hpbGUgYWxsIG90aGVyDQo+IGxhbmd1YWdlcyBpbiA2MzktMyB3b3VsZCBiZSBtYXBw ZWQgdG8gcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzLiAgKFRob3NlDQo+IGxhbmd1YWdlcyB0aGF0 IGhhdmUgYW4gSVNPIDYzOS0xIGFscGhhLTIgY29kZSBlbGVtZW50IHdvdWxkIGNvbnRpbnVlIHRv DQo+IHVzZSBpdCBhcyB0aGUgc3VidGFnIGluc3RlYWQgb2YgdGhlIGNvcnJlc3BvbmRpbmcgYWxw aGEtMyBjb2RlIGVsZW1lbnQsDQo+IGZvciBjb21wYXRpYmlsaXR5IHdpdGggUkZDIDE3NjYgYW5k IDMwNjYuKQ0KPiANCj4gVXNpbmcgdGhpcyBtb2RlbCwgdGhlIGluaXRpYWwgUkZDIDMwNjZ0ZXIg UmVnaXN0cnkgd291bGQgaW5jbHVkZQ0KPiBhcHByb3hpbWF0ZWx5IDcyMDAgcHJpbWFyeSBsYW5n dWFnZSBzdWJ0YWdzIGFuZCBhcHByb3hpbWF0ZWx5IDM1MA0KPiBleHRsYW5nIHN1YnRhZ3MuDQo+ IA0KPiBBcyByZWNlbnQgZGlzY3Vzc2lvbnMgaGF2ZSBzaG93biwgd2Ugd2lsbCBuZWVkIHRvIGZp Z3VyZSBvdXQgd2hhdCB0byBkbw0KPiB3aXRoIHRoZSBSZWdpc3RyeSBpZiBhbmQgd2hlbiB0aGUg SVNPIDYzOS0zIG1hcHBpbmdzIGJldHdlZW4gaW5kaXZpZHVhbA0KPiBsYW5ndWFnZXMgYW5kIG1h Y3JvbGFuZ3VhZ2VzIGNoYW5nZS4gIFRoZXJlIGlzIHBsZW50eSBvZiBsaXZlbHkgZGViYXRlDQo+ IGFib3V0IHRoYXQgYW5kIEkgZG9uJ3QgcGxhbiB0byByZWhhc2ggaXQgaGVyZS4NCj4gDQo+IE9u ZSB0b3BpYyB3ZSBoYXZlIG5vdCBhZGRyZXNzZWQgeWV0LCB3aGljaCBtYXkgaW52b2x2ZSBleHRs YW5nIHN1YnRhZ3MsDQo+IGlzIHNpZ24gbGFuZ3VhZ2VzLiAgSVNPIDYzOS0zIGxpc3RzIDEyNCBs YW5ndWFnZXMgd2l0aCAiU2lnbiBMYW5ndWFnZSINCj4gaW4gdGhlaXIgbmFtZS4gIEl0IGRvZXMg bm90IGluY2x1ZGUgdGhlIElTTyA2MzktMiBjb2RlIGVsZW1lbnQgInNnbiINCj4gKCJTaWduIExh bmd1YWdlcyIpLCB3aGljaCBkZW5vdGVzIGEgY29sbGVjdGlvbiBvZiBsYW5ndWFnZXMgYW5kIGlz DQo+IHRoZXJlZm9yZSBvdXQgb2Ygc2NvcGUgZm9yIDYzOS0zIChidXQgd2hpY2ggZG9lcyBleGlz dCBpbiB0aGUgUkZDDQo+IDMwNjZiaXMgUmVnaXN0cnkpLg0KPiANCj4gVGhlcmUgaXMgYSBwcmVj ZWRlbnQgaW4gUkZDIDMwNjYgZm9yIHVzaW5nIHRoZSAic2duIiBjb2RlIGVsZW1lbnQNCj4gdG9n ZXRoZXIgd2l0aCBhbiBJU08gMzE2NiBjb3VudHJ5IGNvZGUgZWxlbWVudCAocGx1cyBvcHRpb25h bGx5IG90aGVyDQo+IHN5bWJvbHMpIHRvIHRhZyBzcGVjaWZpYyBzaWduIGxhbmd1YWdlcy4gIFRo ZSBjbGFzc2ljIGV4YW1wbGUgaXMNCj4gInNnbi1VUyIgZm9yIEFtZXJpY2FuIFNpZ24gTGFuZ3Vh Z2UgKEkgd2lsbCB1c2UgaXQgYXMgbXkgZXhhbXBsZSBmb3INCj4gY29udmVuaWVuY2Ugb25seSku ICBUaGlzIHN5c3RlbSB3YXMgZGV2aXNlZCBieSBNaWNoYWVsIEV2ZXJzb24gYW5kIHRoZQ0KPiBE ZWFmIEFjdGlvbiBDb21taXR0ZWUgZm9yIFNpZ24gV3JpdGluZywgYW5kIGlzIGRlc2NyaWJlZCBh dA0KPiBodHRwOi8vd3d3LmV2ZXJ0eXBlLmNvbS9zdGFuZGFyZHMvaXNvNjM5L3Nnbi5odG1sLiAg U29tZSBvZiB0aGUNCj4gc2duLWNvbWJpbmF0aW9ucyBsaXN0ZWQgb24gdGhhdCBwYWdlIGFyZSBh bHJlYWR5IHJlZ2lzdGVyZWQgdW5kZXIgUkZDDQo+IDMwNjYsIGFuZCBjb25zZXF1ZW50bHkgdGhl eSBhcmUgbGlzdGVkIGFzIGVpdGhlciBncmFuZGZhdGhlcmVkIG9yDQo+IHJlZHVuZGFudCBpbiB0 aGUgUkZDIDMwNjZiaXMgUmVnaXN0cnk7IG90aGVycyBhcmUgbm90Lg0KPiANCj4gVGhlIElTTyA2 MzktMyBjb2RlIGVsZW1lbnQgZm9yIEFtZXJpY2FuIFNpZ24gTGFuZ3VhZ2UgaXMgImFzZSIuICAo ImFzbCINCj4gaXMgdGhlIGNvZGUgZWxlbWVudCBmb3IgQXNpbHVsdSwgYSBsYW5ndWFnZSBvZiBJ bmRvbmVzaWEuKSAgSWYgd2UNCj4gY29udmVydCBzdWNoIGNvZGUgZWxlbWVudHMgZGlyZWN0bHkg dG8gcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzLCBhcyB3ZQ0KPiB3aWxsIGxpa2VseSBkbyBmb3Ig b3JkaW5hcnkgc3Bva2VuL3dyaXR0ZW4gbGFuZ3VhZ2VzIHRoYXQgZG8gbm90IGhhdmUgYQ0KPiBt YWNyb2xhbmd1YWdlLCB0aGVuIHRoZSBSRkMgMzA2NnRlciB0YWcgZm9yIEFTTCB3b3VsZCBiZSAi YXNlIi4NCj4gDQo+IEFsdGVybmF0aXZlbHksIHdlIGNvdWxkIGNob29zZSB0byBhZGQgYWxsIDYz OS0zIGNvZGUgZWxlbWVudHMgZm9yIHNpZ24NCj4gbGFuZ3VhZ2VzIGFzICpleHRsYW5nKiBzdWJ0 YWdzLCB3aXRoIGEgUHJlZml4IG9mICJzZ24iLiAgVXNpbmcgdGhpcw0KPiBtb2RlbCwgdGhlIFJG QyAzMDY2dGVyIHRhZyBmb3IgQVNMIHdvdWxkIGJlICJzZ24tYXNlIi4gIFRoaXMgYXBwcm9hY2gN Cj4gd291bGQgaGF2ZSB0aGUgYWR2YW50YWdlIChpZiBzdWNoIGl0IGlzKSB0aGF0IHRoZSBzaWdu LWxhbmd1YWdlIG5hdHVyZQ0KPiB3b3VsZCBiZSBpbmRpY2F0ZWQgYXMgcGFydCBvZiB0aGUgdGFn LiAgVGhpcyBkb2VzIG5vdCBuZWNlc3NhcmlseSBpbXBseQ0KPiBhbnkgbXV0dWFsIGNvbXBhdGli aWxpdHkgYmV0d2VlbiAic2duLXh4eCIgbGFuZ3VhZ2VzLCBhbnkgbW9yZSB0aGFuIHRoZQ0KPiBS RkMgMzA2NiBzY2hlbWUgZG9lcy4NCj4gDQo+IEluIGVpdGhlciBjYXNlLCB0aGUgZXhpc3Rpbmcg Z3JhbmRmYXRoZXJlZCB0YWcgInNnbi1VUyIgd291bGQgcHJlc3VtYWJseQ0KPiBiZSBkZXByZWNh dGVkIGFuZCBnaXZlbiBhIFByZWZlcnJlZC1WYWx1ZSBvZiBlaXRoZXIgImFzZSIgb3IgInNnbi1h c2UiLg0KPiANCj4gSSB1bmRlcnN0YW5kIHRoYXQgTWljaGFlbCBtYXkgbm90IGZhdm9yIHRoaXMg YXBwcm9hY2gsIGFuZCBtYXkgcHJlZmVyIHRvDQo+IGNvbnRpbnVlIHVzaW5nIHRoZSAic2duLVVT IiBzeXN0ZW0uICBUaGVyZSBpcyBwb3RlbnRpYWxseSBzb21lIG1hdGVyaWFsDQo+IGFscmVhZHkg dGFnZ2VkIHVzaW5nIHRoZXNlIFJGQyAzMDY2IGlkZW50aWZpZXJzLiAgT25lIHNpZ25pZmljYW50 DQo+IGRyYXdiYWNrIGlzIHRoYXQgdGFncyB1c2luZyB0aGlzIG1vZGVsIHRoYXQgZ28gYmV5b25k ICJzZ24gcGx1cyByZWdpb24iDQo+IGFyZSBub3QgY29tcGF0aWJsZSB3aXRoIHRoZSBSRkMgMzA2 NmJpcyBzeW50YXg6DQo+IA0KPiBzZ24tQVUtTlQgLS0gdXNlcyBhbiBJU08gMzE2Ni0yIGNvdW50 cnktc3ViZGl2aXNpb24gY29kZQ0KPiBzZ24tSUwteWkgIC0tIHVzZXMgYW4gSVNPIDYzOS0xIGxh bmd1YWdlIGNvZGUNCj4gc2duLVNFLWNycCAtLSB1c2VzIGFuIElTTyA2MzktMiBsYW5ndWFnZSBj b2RlDQo+IA0KPiBBbm90aGVyIGRyYXdiYWNrLCBhdCBsZWFzdCBpbiBteSB2aWV3LCBpcyB0aGF0 IHRoZSBnZW5lcmF0aXZlIG1vZGVsDQo+IHRlbGxzIHVzIHRoYXQgInNnbi1YWCIgbWVhbnMgInNp Z24gbGFuZ3VhZ2VzIGFzIHVzZWQgaW4gcmVnaW9uIFhYIiwNCj4gd2hpY2ggY2FuIGJlIG1pc2xl YWRpbmcgaW4gcmVnaW9ucyB3aGVyZSBtdWx0aXBsZSBzaWduIGxhbmd1YWdlcyBhcmUgaW4NCj4g Y29tbW9uIHVzZS4gIFRoZXJlIGlzIGEgc3Ryb25nIGlkZW50aXR5IGJldHdlZW4gdGhlIGNvbmNl cHRzICJBbWVyaWNhbg0KPiBTaWduIExhbmd1YWdlIiBhbmQgInNpZ24gbGFuZ3VhZ2VzIGFzIHVz ZWQgaW4gdGhlIFVuaXRlZCBTdGF0ZXMsIiBidXQNCj4gdGhpcyBtYXkgbm90IGhvbGQgZm9yIG90 aGVyIHNpZ24gbGFuZ3VhZ2VzLg0KPiANCj4gSXQncyBpbXBvcnRhbnQgdG8gcmVtZW1iZXIgdGhh dCAiZGVwcmVjYXRlZCIgdGFncyBhcmUgbm90IGludmFsaWQ7IHRoZXkNCj4gYXJlIHNpbXBseSBu b3QgcmVjb21tZW5kZWQgZm9yIGZ1dHVyZSB0YWdnaW5nLg0KPiANCj4gQWdhaW4sIG91ciBnb2Fs IHJpZ2h0IG5vdyBuZWVkcyB0byBiZSB0byByYWlzZSBxdWVzdGlvbnMgYW5kIGNvbnNpZGVyDQo+ IHNjZW5hcmlvcywgbm90IHRvIGRlY2xhcmUgYSBGaW5hbCBBbnN3ZXIuDQo+IA0KPiAtLQ0KPiBE b3VnIEV3ZWxsDQo+IEZ1bGxlcnRvbiwgQ2FsaWZvcm5pYSwgVVNBDQo+IGh0dHA6Ly91c2Vycy5h ZGVscGhpYS5uZXQvfmRld2VsbC8NCj4gRWRpdG9yLCBkcmFmdC1pZXRmLWx0cnUtaW5pdGlhbA0K PiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg== --===============1908209971== 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 --===============1908209971==-- From ltru-bounces@ietf.org Mon Aug 28 10:22:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHi07-0007j6-GX; Mon, 28 Aug 2006 10:22:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHi06-0007j1-3D for ltru@ietf.org; Mon, 28 Aug 2006 10:22:06 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHi03-0008Lv-S9 for ltru@ietf.org; Mon, 28 Aug 2006 10:22:06 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GHhzz-0005J2-4k; Mon, 28 Aug 2006 10:21:59 -0400 Date: Mon, 28 Aug 2006 10:21:59 -0400 To: Peter Constable Subject: Re: [Ltru] Extended language subtags Message-ID: <20060828142158.GB20448@ccil.org> References: <004d01c6ca5e$f2709980$6401a8c0@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: 9182cfff02fae4f1b6e9349e01d62f32 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 Peter Constable scripsit: > My inclination has always been to treat signed languages like any > other language, meaning that we use their 639-3 IDs as primary language > subtags. This entirely contradicts your remarks of last February: see http://www.alvestrand.no/pipermail/ietf-languages/2006-February/004061.html I support your previous position. > (I find it odd that Michael saw that 15924 IDs were added for scripts > that are long dead but for all his supposed interest in signed > languages and Sign Writing there isn't an ISO 15924 ID for a single > writing system used in relation to signed languages.) Michael isn't subscribed here, AFAIK. I shall contact him directly, not mentioning your name of course. -- John Cowan cowan@ccil.org http://www.ccil.org/~cowan Humpty Dump Dublin squeaks through his norse Humpty Dump Dublin hath a horrible vorse But for all his kinks English / And his irismanx brogues Humpty Dump Dublin's grandada of all rogues. --Cousin James _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 28 11:30:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHj4I-0007Kz-GR; Mon, 28 Aug 2006 11:30:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHj4H-0007Jq-64 for ltru@ietf.org; Mon, 28 Aug 2006 11:30:29 -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 1GHivz-00010Y-3F for ltru@ietf.org; Mon, 28 Aug 2006 11:21:55 -0400 Received: from mail1.microsoft.com ([131.107.1.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHivH-0006ea-Pz for ltru@ietf.org; Mon, 28 Aug 2006 11:21:16 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 08:21:11 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.61.146]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2725); Mon, 28 Aug 2006 08:21:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Extended language subtags Date: Mon, 28 Aug 2006 08:21:08 -0700 Message-ID: In-Reply-To: <20060828142158.GB20448@ccil.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ltru] Extended language subtags Thread-Index: AcbKrVamKFdfU7/aSwmCBfrKnlXHvwABtFVA From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 28 Aug 2006 15:21:10.0918 (UTC) FILETIME=[97AC4A60:01C6CAB5] X-Spam-Score: -2.6 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > From: John Cowan [mailto:cowan@ccil.org] > > My inclination has always been to treat signed languages like any > > other language, meaning that we use their 639-3 IDs as primary = language > > subtags. >=20 > This entirely contradicts your remarks of last February: see > http://www.alvestrand.no/pipermail/ietf-languages/2006- > February/004061.html Heh, heh... Caught in my error! I completely forgot about that. OK, I think I was long inclined to = prefer treating signed languages like other languages -- with primary = subtags. But, in view of what I wrote last Feb, which was based on = discussion with someone I believes understands the signed-language = space, I'm willing to go along with using sgn as a prefix for signed = languages as per what I wrote in that message.=20 But, we should call that out in 3066ter as a special case in exception = to the otherwise-applicable principle that extended language subtags = must have a macrolanguage mapping in 639 to their prefix. Peter Constable _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 28 11:55:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHjSq-0002C2-N5; Mon, 28 Aug 2006 11:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHjSo-0001pA-Mk for ltru@ietf.org; Mon, 28 Aug 2006 11:55:50 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHjSm-0001L5-Fs for ltru@ietf.org; Mon, 28 Aug 2006 11:55:50 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GHjSm-0007IA-3d; Mon, 28 Aug 2006 11:55:48 -0400 Date: Mon, 28 Aug 2006 11:55:48 -0400 To: Peter Constable Subject: Re: [Ltru] Extended language subtags Message-ID: <20060828155548.GD20448@ccil.org> References: <20060828142158.GB20448@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable scripsit: > Heh, heh... Caught in my error! > > I completely forgot about that. OK, I think I was long inclined to > prefer treating signed languages like other languages -- with primary > subtags. But, in view of what I wrote last Feb, which was based on > discussion with someone I believes understands the signed-language > space, I'm willing to go along with using sgn as a prefix for signed > languages as per what I wrote in that message. Similar things have happened to me often enough. "A man convinced against his will / Is of the same opinion still." [*] > But, we should call that out in 3066ter as a special case in exception > to the otherwise-applicable principle that extended language subtags > must have a macrolanguage mapping in 639 to their prefix. Absolutely. [*] Pedantic footnote: This is a common misquotation of two lines from Samuel Butler's _Hudibras_ that IMHO has more psychological depth than the original, which says "He who complies ...". External coercion is one thing, coercion by reason another -- but it still feels like coercion. -- Cash registers don't really add and subtract; John Cowan they only grind their gears. cowan@ccil.org But then they don't really grind their gears, either; they only obey the laws of physics. --Unknown _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 28 12:41:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHkBF-0000RA-0o; Mon, 28 Aug 2006 12:41:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHkBD-0000Md-OA for ltru@ietf.org; Mon, 28 Aug 2006 12:41:43 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHkBC-0007q2-HI for ltru@ietf.org; Mon, 28 Aug 2006 12:41:43 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GHkBC-0008Oi-57; Mon, 28 Aug 2006 12:41:42 -0400 Date: Mon, 28 Aug 2006 12:41:42 -0400 To: Doug Ewell Subject: Re: [Ltru] Extended language subtags Message-ID: <20060828164142.GF20448@ccil.org> References: <004d01c6ca5e$f2709980$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004d01c6ca5e$f2709980$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Doug Ewell scripsit: > Alternatively, we could choose to add all 639-3 code elements for sign > languages as *extlang* subtags, with a Prefix of "sgn". Using this > model, the RFC 3066ter tag for ASL would be "sgn-ase". This approach > would have the advantage (if such it is) that the sign-language nature > would be indicated as part of the tag. This does not necessarily imply > any mutual compatibility between "sgn-xxx" languages, any more than the > RFC 3066 scheme does. I support this model. > In either case, the existing grandfathered tag "sgn-US" would presumably > be deprecated and given a Preferred-Value of either "ase" or "sgn-ase". The tag "sgn-US" is actually redundant rather than grandfathered. > Another drawback, at least in my view, is that the generative model > tells us that "sgn-XX" means "sign languages as used in region XX", > which can be misleading in regions where multiple sign languages are in > common use. There is a strong identity between the concepts "American > Sign Language" and "sign languages as used in the United States," but > this may not hold for other sign languages. And indeed vice versa: American Sign Language is used in Canada as well. -- John Cowan cowan@ccil.org http://ccil.org/~cowan In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 28 12:53:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHkMP-0005eW-Pt; Mon, 28 Aug 2006 12:53:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHkMO-0005e9-7v for ltru@ietf.org; Mon, 28 Aug 2006 12:53:16 -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 1GHidM-00054B-6e for ltru@ietf.org; Mon, 28 Aug 2006 11:02:40 -0400 Received: from mta13.adelphia.net ([68.168.78.44]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHiWj-0005wL-7q for ltru@ietf.org; Mon, 28 Aug 2006 10:55:51 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta13.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060828145546.JCWT59.mta13.adelphia.net@DGBP7M81> for ; Mon, 28 Aug 2006 10:55:46 -0400 Message-ID: <007c01c6cab2$06f11490$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" Subject: Re: [Ltru] Extended language subtags Date: Mon, 28 Aug 2006 07:55:38 -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.2962 X-Spam-Score: -2.6 (--) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Peter Constable wrote: > I think you need to decide: are we discussing extended language > subtags, or the tagging of signed languages? Those are two different > topics, and I think you're discussing the latter. I was trying to discuss both, combining them into one post on the basis that sign languages might use the "sgn plus extlang" syntax. Probably the Subject line should have been clearer. > If we were to encode the 639-3 IDs for signed languages as extended > language subtags with a prefix of "sgn", that would be an ad-hoc > exception to the otherwise-applicable principle that every extended > language subtag has a macrolanguage mapping to its designated prefix. It would be an exception. I don't know if it would be "ad-hoc" in the sense I'm thinking: it would be a stated exception for all sign languages, not case-by-case. > My inclination has always been to treat signed languages like any > other language, meaning that we use their 639-3 IDs as primary > language subtags. If Michael and the DAC want some way to indicate > that content is in Sign Writing, the appropriate way to deal with that > is to create a script ID in 15924 and use that -- i.e. tags like > "ase-sgnw". (I'm glad the discussion is beginning; that was my goal.) The suggestion to treat them differently was based on the premise that sign languages are inherently different from "traditional" spoken and written languages -- at least from the perspective of data stored on computers, which is what RFC 3066bis/ter langtags are for. This may not be a premise everyone can agree on, and it wasn't necessarily mine. It's also related to the question of how signed spoken languages should be indicated; last time we had that discussion, the results were inconclusive in the extreme. > (I find it odd that Michael saw that 15924 IDs were added for scripts > that are long dead but for all his supposed interest in signed > languages and Sign Writing there isn't an ISO 15924 ID for a single > writing system used in relation to signed languages.) I have no inside knowledge, but I wouldn't be surprised to see a 15924 code element for Sutton in the future. -- Doug Ewell Fullerton, California, USA http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 28 12:59:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHkRy-0007z6-Eh; Mon, 28 Aug 2006 12:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHkRx-0007z1-Pg for ltru@ietf.org; Mon, 28 Aug 2006 12:59:01 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHkRw-0002Jn-G8 for ltru@ietf.org; Mon, 28 Aug 2006 12:59:01 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GHkRw-0000LD-5F; Mon, 28 Aug 2006 12:59:00 -0400 Date: Mon, 28 Aug 2006 12:59:00 -0400 To: Doug Ewell Subject: Re: [Ltru] Extended language subtags Message-ID: <20060828165900.GG20448@ccil.org> References: <004d01c6ca5e$f2709980$6401a8c0@DGBP7M81> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004d01c6ca5e$f2709980$6401a8c0@DGBP7M81> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 Doug Ewell scripsit: > As recent discussions have shown, we will need to figure out what to do > with the Registry if and when the ISO 639-3 mappings between individual > languages and macrolanguages change. There is plenty of lively debate > about that and I don't plan to rehash it here. Well, I will, then. :-) In ISO 639-3, code elements belong to one of three types: macrolanguages, languages encompassed by a macrolanguage, and languages not encompassed by a macrolanguage. Assuming we go with the model that macrolanguages and unencompassed languages become language subtags, and encompassed languages become extlang subtags, then there are a variety of changes in state that can occur within 639-3 that we need to reflect in different ways. ("We" in all cases means ietf-languages.) 1) A new unencompassed language is added. We add a new language subtag. 2) A new encompassed language is added. We add it as an extlang tag, and add the macrolanguage as a language tag if it is not already present. 3) A new macrolanguage is added, encompassing either already coded languages or new languages or both. We add a new language subtag for the macrolanguage itself. We treat the encompassed languages thus: a) If the language is already in the registry, we do nothing; we do not deprecate it as a language subtag or add it as an extlang subtag. [This is a change from my previous position.] b) If the language is new, we add it as an extlang subtag. 4) An existing language is reclassified as a macrolanguage, encompassing either already encoded languages or new languages or both. We do not change the existing language subtag. The languages it encompasses are treated as in case 3. If the new macrolanguage is already encompassed, then we have a nested macrolanguage; nothing special is done except that any new languages it encompasses will have a two-part Prefix setting. 5) An existing unencompassed language is reclassified as encompassed by a macrolanguage. We do nothing. 6) An existing encompassed language is reclassified as unencompassed. We do nothing. 7) An existing encompassed language is reclassified as encompassed by a different macrolanguage. We do nothing. These proposals satisfy the axioms "Once a language tag, always a language tag" and "Once an extlang tag, always an extlang tag." -- "The serene chaos that is Courage, and the phenomenon cowan@ccil.org of Unopened Consciousness have been known to the John Cowan Great World eons longer than Extaboulism." "Why is that?" the woman inquired. "Because I just made that word up", the Master said wisely. --Kehlog Albran, The Profit http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 28 13:57:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHlMj-0001cg-Tl; Mon, 28 Aug 2006 13:57:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHlMi-0001XJ-AM for ltru@ietf.org; Mon, 28 Aug 2006 13:57:40 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHlMg-0006GJ-Uv for ltru@ietf.org; Mon, 28 Aug 2006 13:57:40 -0400 Received: from [172.21.37.80] (duringperson-lx.corp.yahoo.com [172.21.37.80]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k7SHvKe4054306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Aug 2006 10:57:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=A7HQdXDggBq/G16iyx27ZVCFUS2rltGj4bPyfo7XJ6UkBO51EnfH+HuKY1sDP1nf Message-ID: <44F32E80.3000101@yahoo-inc.com> Date: Mon, 28 Aug 2006 10:57:20 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Extended language subtags References: <004d01c6ca5e$f2709980$6401a8c0@DGBP7M81> <20060828165900.GG20448@ccil.org> In-Reply-To: <20060828165900.GG20448@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Doug Ewell , 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 > > These proposals satisfy the axioms "Once a language tag, always a > language tag" and "Once an extlang tag, always an extlang tag." And go a bit further, in that they also adhere to a desire for stability extant in RFC 3066bis: "Once a preferred tag for a language, always the preferred tag for that language." Note that deprecation of subtags in the registry tends to inform the user that "facts on the ground" have changed. Thus, 'NH' is deprecated because that "region" no longer exists. "en-NH" is still, on some level, the preferred tag for that language, but that language doesn't have a lot of meaning. > > Well, I will, then. :-) Good. In general, +1 to your summary. > > 2) A new encompassed language is added. We add it as an extlang tag, > and add the macrolanguage as a language tag if it is not already present. Not quite. The case is: "A new encompassed language is added. We add it as an extlang subtag with a prefix of its enclosing language subtag sequence." If the macrolanguage is not present, the case is #1, as subtags can only be enclosed by other subtags already in the registry. This suggests that, when processing a list of new items, all macrolanguages MUST be processed first (at least mentally). > > 3) A new macrolanguage is added, encompassing either already coded > languages or new languages or both. We add a new language subtag for > the macrolanguage itself. We treat the encompassed languages thus: > > a) If the language is already in the registry, we do nothing; > we do not deprecate it as a language subtag or add it as an > extlang subtag. [This is a change from my previous position.] > > b) If the language is new, we add it as an extlang subtag. > > 4) An existing language is reclassified as a macrolanguage, encompassing > either already encoded languages or new languages or both. We do not > change the existing language subtag. ... change the existing language or extlang subtag. > > 7) An existing encompassed language is reclassified as encompassed by > a different macrolanguage. We do nothing. Hm... an encompassed language is already an extlang. It could be given an additional Prefix. The existing Prefix would remain, however. I'm pretty sure this isn't a really hot idea, but it is a useful fudge, perhaps? Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Aug 28 15:04:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmPM-0003iV-Cc; Mon, 28 Aug 2006 15:04:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHmPL-0003hn-7A for ltru@ietf.org; Mon, 28 Aug 2006 15:04:27 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHmPI-0000yu-2k for ltru@ietf.org; Mon, 28 Aug 2006 15:04:26 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GHmPH-0003dO-85; Mon, 28 Aug 2006 15:04:23 -0400 Date: Mon, 28 Aug 2006 15:04:23 -0400 To: Addison Phillips Subject: Re: [Ltru] Extended language subtags Message-ID: <20060828190423.GB22622@ccil.org> References: <004d01c6ca5e$f2709980$6401a8c0@DGBP7M81> <20060828165900.GG20448@ccil.org> <44F32E80.3000101@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F32E80.3000101@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.6 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > Not quite. The case is: > > "A new encompassed language is added. We add it as an extlang subtag > with a prefix of its enclosing language subtag sequence." > > If the macrolanguage is not present, the case is #1, as subtags can only > be enclosed by other subtags already in the registry. This suggests > that, when processing a list of new items, all macrolanguages MUST be > processed first (at least mentally). Yes. I was trying to cover the case where a macrolanguage and its encompassed languages are added simultaneously. > >4) An existing language is reclassified as a macrolanguage, encompassing > >either already encoded languages or new languages or both. We do not > >change the existing language subtag. > > ... change the existing language or extlang subtag. +1 > >7) An existing encompassed language is reclassified as encompassed by > >a different macrolanguage. We do nothing. > > Hm... an encompassed language is already an extlang. It could be given > an additional Prefix. The existing Prefix would remain, however. I'm > pretty sure this isn't a really hot idea, but it is a useful fudge, perhaps? I think it's a very bad idea: it makes aaa-xxx and bbb-xxx synonymous, which is something we avoid. New axiom: "No sets of language tags are synonymous, unless all but one of them are deprecated." -- John Cowan cowan@ccil.org http://ccil.org/~cowan Assent may be registered by a signature, a handshake, or a click of a computer mouse transmitted across the invisible ether of the Internet. Formality is not a requisite; any sign, symbol or action, or even willful inaction, as long as it is unequivocally referable to the promise, may create a contract. --Specht v. Netscape _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 00:59:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHvhL-0007TD-3f; Tue, 29 Aug 2006 00:59:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHvhJ-0007P3-LK for ltru@lists.ietf.org; Tue, 29 Aug 2006 00:59:37 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHvhG-0007iq-4z for ltru@lists.ietf.org; Tue, 29 Aug 2006 00:59:37 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GHvgR-0002LF-0t for ltru@lists.ietf.org; Tue, 29 Aug 2006 06:58:43 +0200 Received: from pd9fba907.dip0.t-ipconnect.de ([217.251.169.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Aug 2006 06:58:43 +0200 Received: from nobody by pd9fba907.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Aug 2006 06:58:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 29 Aug 2006 06:57:17 +0200 Organization: Lines: 28 Message-ID: <44F3C92D.3DDE@xyzzy.claranet.de> References: <004d01c6ca5e$f2709980$6401a8c0@DGBP7M81> <20060828165900.GG20448@ccil.org> <44F32E80.3000101@yahoo-inc.com> <20060828190423.GB22622@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba907.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.6 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Ltru] Re: Extended language subtags X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >>> 7) An existing encompassed language is reclassified as >>> encompassed by a different macrolanguage. We do nothing. >> Hm... an encompassed language is already an extlang. It >> could be given an additional Prefix. The existing Prefix >> would remain, however. I'm pretty sure this isn't a really >> hot idea, but it is a useful fudge, perhaps? > I think it's a very bad idea: it makes aaa-xxx and bbb-xxx > synonymous, which is something we avoid. New axiom: "No > sets of language tags are synonymous, unless all but one of > them are deprecated." Here's what we have in 3066bis 2.2.2: | Extended language subtag records, once they appear in the | registry, MUST include exactly one 'Prefix' field indicating | an appropriate language subtag or sequence of subtags that | MUST always appear as a prefix to the extended language | subtag. We've guaranteed that 3066bis implementations will work with 3066ter. Let's stick to that plan as long as possible. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 01:31:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHwBo-0008P0-K7; Tue, 29 Aug 2006 01:31:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHwBn-0008Ov-DY for ltru@ietf.org; Tue, 29 Aug 2006 01:31:07 -0400 Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHwBm-0005Hn-5i for ltru@ietf.org; Tue, 29 Aug 2006 01:31:07 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta10.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060829053105.CGBK3509.mta10.adelphia.net@DGBP7M81>; Tue, 29 Aug 2006 01:31:05 -0400 Message-ID: <006301c6cb2c$4e873080$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <004d01c6ca5e$f2709980$6401a8c0@DGBP7M81> <20060828164142.GF20448@ccil.org> Subject: Re: [Ltru] Extended language subtags Date: Mon, 28 Aug 2006 22:30:56 -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.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: >> Alternatively, we could choose to add all 639-3 code elements for >> sign languages as *extlang* subtags, with a Prefix of "sgn"... > > I support this model. So do I. What I like about it is what Peter expressed in his February post: "Having 'sgn' at the start immediately sets apart the modality, which will generally trump any other distinction in importance to the user." That is, the fact that ASL and BSL are both "sign language" gives them much more in common with each other than with any spoken or written language. This is similar to the way Cantonese and Mandarin are both identified as "Chinese," even by speakers of one who don't understand the other. The only difference is that Sign Language per se isn't identified as a macrolanguage (or indeed at all) in ISO 639-3. Peter is absolutely right that if we make all the sign languages extlangs under "sgn", then we need to call attention to this exceptional case in the RFC text. That's not a reason for not doing it, though. >> In either case, the existing grandfathered tag "sgn-US" would >> presumably be deprecated and given a Preferred-Value of either "ase" >> or "sgn-ase". > > The tag "sgn-US" is actually redundant rather than grandfathered. Yes. Well, yes and no. The tag "sgn-US" itself is grandfathered, but in a very real sense the RFC 3066 registered meaning "American Sign Language" is very much grandfathered. It is not the same thing as "sign languages used in the United States." Plains Indian Sign Language is used in, and indigenous to, the U.S. -- 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 Tue Aug 29 07:32:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI1pG-0001md-DP; Tue, 29 Aug 2006 07:32:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI1pF-0001mQ-5z for ltru@ietf.org; Tue, 29 Aug 2006 07:32:13 -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 1GHzw6-00050E-R2 for ltru@ietf.org; Tue, 29 Aug 2006 05:31:10 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHzoG-0003Kt-Cb for ltru@ietf.org; Tue, 29 Aug 2006 05:23:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 2672726C156; Tue, 29 Aug 2006 11:22:59 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id E962526C11F; Tue, 29 Aug 2006 11:22:57 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id D5CD6A1D93E; Tue, 29 Aug 2006 11:22:57 +0200 (CEST) Date: Tue, 29 Aug 2006 11:22:57 +0200 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20060829092257.GA22927@nic.fr> References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D36598.1020304@yahoo-inc.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: -2.4 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Doug Ewell , LTRU Working Group Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org On Fri, Aug 04, 2006 at 08:19:52AM -0700, Addison Phillips wrote a message of 50 lines which said: > Agreed: all RFC 3066bis processors have to have the list of > grandfathered tags baked in. Does it mean that a processor should (ordinary "should" not RFC "SHOULD") define the grammar production "grandfathered" as a list of possible grandfathered tags, rather than the grammar rules expressed in draft-ietf-ltru-registry-14? I ask the question because these rules accept things like "fr-Lat" which is not a well-formed tag. So, I was planning to replace them by a hardwired list of GF tags. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 09:33:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI3iD-0001f2-Sq; Tue, 29 Aug 2006 09:33:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI3iC-0001ev-N4 for ltru@ietf.org; Tue, 29 Aug 2006 09:33:04 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI3iA-000559-Eh for ltru@ietf.org; Tue, 29 Aug 2006 09:33:04 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GI3iA-0005yg-0L; Tue, 29 Aug 2006 09:33:02 -0400 Date: Tue, 29 Aug 2006 09:33:01 -0400 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Test suite for language tags? Message-ID: <20060829133301.GE8529@ccil.org> References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060829092257.GA22927@nic.fr> User-Agent: Mutt/1.3.28i From: John Cowan 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 Stephane Bortzmeyer scripsit: > Does it mean that a processor should (ordinary "should" not RFC > "SHOULD") define the grammar production "grandfathered" as a list of > possible grandfathered tags, rather than the grammar rules expressed > in draft-ietf-ltru-registry-14? Yes, absolutely. MUST would be the appropriate modal verb, in fact. The grammar rules are meant to cover the possibilities, not to serve as a test for recognizing grandfathered tags. At the present time there are exactly 34 grandfathered tags, of which 8 are deprecated with replacements (but must still be recognized). Two more will probably be changed to redundant status before the adoption of 3066ter. At the adoption of 3066ter, six more tags will be transferred to redundant status. The only tags that will remain both grandfathered and not deprecated are cel-gaulish (unless ISO 639-3 is extended to include it), en-GB-oed, i-default, i-enochian (unless ISO 639-3 is extended to include it), and the rather useless zh-min. However, there will be no harm in continuing to bake the full list of 34 into validators. This suggests that in 3066ter we should specify the ABNF definition of "grandfathered" explicitly as a choice of tags. -- John Cowan http://ccil.org/~cowan cowan@ccil.org Mr. Henry James writes fiction as if it were a painful duty. --Oscar Wilde _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 11:25:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI5Sb-0006K1-7l; Tue, 29 Aug 2006 11:25:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI5SZ-0006Jf-MU for ltru@ietf.org; Tue, 29 Aug 2006 11:25:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI5SZ-0002Ho-Kx for ltru@ietf.org; Tue, 29 Aug 2006 11:25:03 -0400 Received: from mta11.adelphia.net ([68.168.78.205]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GI4lJ-0003eL-Pv for ltru@ietf.org; Tue, 29 Aug 2006 10:40:25 -0400 Received: from DGBP7M81 ([68.67.66.131]) by mta11.adelphia.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with SMTP id <20060829144020.ICHT4932.mta11.adelphia.net@DGBP7M81>; Tue, 29 Aug 2006 10:40:20 -0400 Message-ID: <00c001c6cb79$0671f210$6401a8c0@DGBP7M81> From: "Doug Ewell" To: "LTRU Working Group" References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> Date: Tue, 29 Aug 2006 07:40:07 -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.2962 X-Spam-Score: -2.6 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > Does it mean that a processor should (ordinary "should" not RFC > "SHOULD") define the grammar production "grandfathered" as a list of > possible grandfathered tags, rather than the grammar rules expressed > in draft-ietf-ltru-registry-14? > > I ask the question because these rules accept things like "fr-Lat" > which is not a well-formed tag. So, I was planning to replace them by > a hardwired list of GF tags. To add to what John wrote: Since you said [1] you were building a non-validating processor, this is all you need. Grandfathered tags can be reclassified as redundant, if all the component subtags become subtags in their own right, but they could remain in your hard-wired list with no ill effect. If you were building a validating processor, you would need access to the full Registry (possibly in a baked form) and would not need to hard-wire any tags or subtags. [1] http://www1.ietf.org/mail-archive/web/ltru/current/msg05157.html -- 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 Tue Aug 29 13:09:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI75Q-0001eN-MV; Tue, 29 Aug 2006 13:09:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI75Q-0001e6-A0 for ltru@ietf.org; Tue, 29 Aug 2006 13:09:16 -0400 Received: from rsmtp2.corp.yahoo.com ([207.126.228.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI75O-00036Q-Tx for ltru@ietf.org; Tue, 29 Aug 2006 13:09:16 -0400 Received: from [10.72.77.75] (snvvpn2-10-72-77-c75.corp.yahoo.com [10.72.77.75]) (authenticated bits=0) by rsmtp2.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k7TH92GX097007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 10:09:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=egQKI9Tzj83dq0tHQg2G2xzpAipzdmnxp7owB5bLuhMnbKiU6flZ0sf4B9g7o389 Message-ID: <44F474AC.7070906@yahoo-inc.com> Date: Tue, 29 Aug 2006 10:09:00 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Re: Test suite for language tags? References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> In-Reply-To: <20060829133301.GE8529@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > >> Does it mean that a processor should (ordinary "should" not RFC >> "SHOULD") define the grammar production "grandfathered" as a list of >> possible grandfathered tags, rather than the grammar rules expressed >> in draft-ietf-ltru-registry-14? > > Yes, absolutely. MUST would be the appropriate modal verb, in fact. No, actually not. There are two types of grandfathered tag, actually. There are those tags which are "well-formed" but for which some of the subtags are not registered (let us call these "regular" tags). And there are those tags which do not follow the grammar of RFC 3066bis (let us call these "irregular" tags). A well-formed processor needs only a list of the irregular tags, but it MUST have such a list or it will malfunction. A validating processing, by definition, needs the complete list. Note that the list of irregular tags is permanent and immutable. It should be noted that Stephane's example of "fr-Lat" passing is not an error. A three-letter subtag in the second position is an extlang. The tag is not currently valid, but it is well-formed. A validating processor, of course, will catch this. > The grammar rules are meant to cover the possibilities, not to serve as > a test for recognizing grandfathered tags. Yes. And the fact is that we can only list the irregular tags in RFC, since the regular grandfathered tags can become redundant. > > At the present time there are exactly 34 grandfathered tags, of which > 8 are deprecated with replacements (but must still be recognized). > Two more will probably be changed to redundant status before the adoption > of 3066ter. Which ones did you have in mind here, John? I don't think I see any that will become redundant at present (unless you have designs on en-scouse or en-boont). Deprecated, certainly, but not redundant, I think. > The only tags that will remain both grandfathered and > not deprecated are cel-gaulish (unless ISO 639-3 is extended to include > it), en-GB-oed, i-default, i-enochian (unless ISO 639-3 is extended to > include it), and the rather useless zh-min. However, there will be no > harm in continuing to bake the full list of 34 into validators. Indeed, it remains important to have the full list of grandfathered tags in validating processors. Well-formed processors will continue to need the full list of irregular tags. Note that "cel-gaulish" is a regular tag: it still has potential of becoming redundant. Although "zh-min" is regular, the code "min" in ISO 639-3 (at present) represents a wholly different language (Minangkabau) that will be a primary language subtag (and thus can't be an extlang). > > This suggests that in 3066ter we should specify the ABNF definition of > "grandfathered" explicitly as a choice of tags. If we can dispose, somehow, of all the regular tags, then I would support such a scheme. If there are unresolved regular tags (whose stripes could change to redundant), I think it would be more of a problem. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 15:28:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9GQ-0002M5-IU; Tue, 29 Aug 2006 15:28:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9GP-0002M0-HO for ltru@ietf.org; Tue, 29 Aug 2006 15:28:45 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI9GM-0004ez-7E for ltru@ietf.org; Tue, 29 Aug 2006 15:28:45 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GI9GL-0006a1-Fy; Tue, 29 Aug 2006 15:28:41 -0400 Date: Tue, 29 Aug 2006 15:28:41 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: Test suite for language tags? Message-ID: <20060829192841.GE22065@ccil.org> References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F474AC.7070906@yahoo-inc.com> 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 Addison Phillips scripsit: > There are two types of grandfathered tag, actually. There are those tags > which are "well-formed" but for which some of the subtags are not > registered (let us call these "regular" tags). And there are those tags > which do not follow the grammar of RFC 3066bis (let us call these > "irregular" tags). > > A well-formed processor needs only a list of the irregular tags, but it > MUST have such a list or it will malfunction. > > A validating processing, by definition, needs the complete list. > > Note that the list of irregular tags is permanent and immutable. +1 > It should be noted that Stephane's example of "fr-Lat" passing is not an > error. A three-letter subtag in the second position is an extlang. The > tag is not currently valid, but it is well-formed. A validating > processor, of course, will catch this. My point is that fr-Lat is not a *grandfathered* tag. Nothing can ever be a grandfathered tag except the 34 existing examples. The current ABNF for a grandfathered tag, 1*3ALPHA 1*2("-" (2*8alphanum)), therefore recognizes too much. > >The grammar rules are meant to cover the possibilities, not to serve as > >a test for recognizing grandfathered tags. > > Yes. And the fact is that we can only list the irregular tags in RFC, > since the regular grandfathered tags can become redundant. Listing them would do no harm. > Which ones did you have in mind here, John? I don't think I see any that > will become redundant at present (unless you have designs on en-scouse > or en-boont). Deprecated, certainly, but not redundant, I think. See my last two ietf-languages postings. > Note that "cel-gaulish" is a regular tag: it still has potential of > becoming redundant. Although "zh-min" is regular, the code "min" in ISO > 639-3 (at present) represents a wholly different language (Minangkabau) > that will be a primary language subtag (and thus can't be an extlang). Correct; these are regular in form but effectively irregular (Gaulish isn't a variant; if anything, it's a macrolanguage, but not treated as such in 639-3.) > If we can dispose, somehow, of all the regular tags, then I would > support such a scheme. If there are unresolved regular tags (whose > stripes could change to redundant), I think it would be more of a problem. I think there will be none: cel-gaulish and zh-min are regular but cannot be made redundant; the other remaining tags will be redundant, deprecated, or both. -- MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS John Cowan cowan@ccil.org http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 15:36:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9OB-0006a2-Nh; Tue, 29 Aug 2006 15:36:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9OB-0006Zx-5L for ltru@lists.ietf.org; Tue, 29 Aug 2006 15:36:47 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI9O9-0006gQ-R8 for ltru@lists.ietf.org; Tue, 29 Aug 2006 15:36:47 -0400 Received: from [172.21.148.153] (wlanvpn-mc2e-246-153.corp.yahoo.com [172.21.148.153]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k7TJaZMU011599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 12:36:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=aaI1d7b3IYgF9W5dBUy7LAAKW+mb3cUBgWL3IojsftMa1nXClyFkXgEbnUBwK4G1 Message-ID: <44F49742.5040504@yahoo-inc.com> Date: Tue, 29 Aug 2006 12:36:34 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Test suite for language tags? References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> <44F49584.216B@xyzzy.claranet.de> In-Reply-To: <44F49584.216B@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org All of the sgn-xx-yy tags (3 of these), all of the i-xxxx tags (13 of them), plus the Oxford tag. Addison Frank Ellermann wrote: > Addison Phillips wrote: > >> there are those tags which do not follow the grammar of RFC >> 3066bis (let us call these "irregular" tags). > > Actually only en-GB-oed, or did I miss other "irregular" tags ? > > Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 15:45:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9Wd-0001xd-Pw; Tue, 29 Aug 2006 15:45:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9Wc-0001xU-Gr for ltru@ietf.org; Tue, 29 Aug 2006 15:45:30 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI9Wb-0000Ir-5a for ltru@ietf.org; Tue, 29 Aug 2006 15:45:30 -0400 Received: from [172.21.148.153] (wlanvpn-mc2e-246-153.corp.yahoo.com [172.21.148.153]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k7TJjCKV011936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 12:45:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=DBMupHZOp/+QvScm6AJq91cevIug8Yns/IUR1JstrgW+DgAuRpCGIFP0QtFBPTw6 Message-ID: <44F49947.1040301@yahoo-inc.com> Date: Tue, 29 Aug 2006 12:45:11 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Re: Test suite for language tags? References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> <20060829192841.GE22065@ccil.org> In-Reply-To: <20060829192841.GE22065@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > >> It should be noted that Stephane's example of "fr-Lat" passing is not an >> error. A three-letter subtag in the second position is an extlang. The >> tag is not currently valid, but it is well-formed. A validating >> processor, of course, will catch this. > > My point is that fr-Lat is not a *grandfathered* tag. Nothing can ever > be a grandfathered tag except the 34 existing examples. The current ABNF > for a grandfathered tag, 1*3ALPHA 1*2("-" (2*8alphanum)), therefore > recognizes too much. Yes, that's correct. However, his example is well-formed according to the regular ABNF. You are entirely correct that implementing the ABNF for grandfathered is the wrong thing to do. Grandfathered checking of any stripe requires *some* list of tags. > >>> The grammar rules are meant to cover the possibilities, not to serve as >>> a test for recognizing grandfathered tags. >> Yes. And the fact is that we can only list the irregular tags in RFC, >> since the regular grandfathered tags can become redundant. > > Listing them would do no harm. If the list changes, that would be bad. Ideally, with a couple of registrations and some deprecations, the list will entirely be formed of tags that have no future, allowing a list to be, actually, a Good Thing (not just "here they are", but also "don't use these any more, even though they remain valid"). >> Note that "cel-gaulish" is a regular tag: it still has potential of >> becoming redundant. Although "zh-min" is regular, the code "min" in ISO >> 639-3 (at present) represents a wholly different language (Minangkabau) >> that will be a primary language subtag (and thus can't be an extlang). > > Correct; these are regular in form but effectively irregular (Gaulish > isn't a variant; if anything, it's a macrolanguage, but not treated > as such in 639-3.) Regular tags don't concern well-formed processors, except that they may mis-identify the purpose of a grandfathered subtag ("min" is NOT an extlang, for example). > > I think there will be none: cel-gaulish and zh-min are regular but > cannot be made redundant; the other remaining tags will be redundant, > deprecated, or both. > Both cel-gaulish and zh-min could be deprecated, though, leaving only dead tags behind. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 16:02:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9mz-00068k-P4; Tue, 29 Aug 2006 16:02:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9my-00068V-NX for ltru@ietf.org; Tue, 29 Aug 2006 16:02:24 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI9mx-0004Ox-EK for ltru@ietf.org; Tue, 29 Aug 2006 16:02:24 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 1C4CA240814; Tue, 29 Aug 2006 22:02:07 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id E8FA1112F6; Tue, 29 Aug 2006 22:00:41 +0200 (CEST) Date: Tue, 29 Aug 2006 22:00:41 +0200 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20060829200041.GA8845@sources.org> References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F474AC.7070906@yahoo-inc.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Aug 29, 2006 at 10:09:00AM -0700, Addison Phillips wrote a message of 76 lines which said: > And there are those tags which do not follow the grammar of RFC > 3066bis (let us call these "irregular" tags). I may seem pedantic but even such tags follow the grammar, no? You mention in another message the i-xxxx tags and they are described by the grammar: grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum)) ; grandfathered registration ; Note: i is the only singleton ; that starts a grandfathered tag Or do you mean, instead of "the grammar of RFC 3066bis", "the grammar of the 'langtag' production"? > It should be noted that Stephane's example of "fr-Lat" passing is > not an error. A three-letter subtag in the second position is an > extlang. Yes, correct. Sorry. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 16:05:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9q2-0001uJ-Ex; Tue, 29 Aug 2006 16:05:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9q1-0001s3-1p for ltru@ietf.org; Tue, 29 Aug 2006 16:05:33 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI9pz-0005ra-Ne for ltru@ietf.org; Tue, 29 Aug 2006 16:05:33 -0400 Received: from [172.21.148.122] (wlanvpn-mc2e-246-122.corp.yahoo.com [172.21.148.122]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k7TK5U9Y012757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 13:05:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=JLyXvbL/C+fTC53VblPjp22zwtmK+441qNs1rJyyRjJF/oqSo/7vhbZgEjd0Mtju Message-ID: <44F49E0A.4010404@yahoo-inc.com> Date: Tue, 29 Aug 2006 13:05:30 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> <20060829200041.GA8845@sources.org> In-Reply-To: <20060829200041.GA8845@sources.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > Or do you mean, instead of "the grammar of RFC 3066bis", "the grammar > of the 'langtag' production"? Yes, exactly so. > >> It should be noted that Stephane's example of "fr-Lat" passing is >> not an error. A three-letter subtag in the second position is an >> extlang. > > Yes, correct. Sorry. > Nothing to be sorry about. It's just not an "edge case" example. A better example might be "f-Latn" :-). -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 16:07:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9rd-0002Ru-HD; Tue, 29 Aug 2006 16:07:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI9rb-0002Re-QZ for ltru@ietf.org; Tue, 29 Aug 2006 16:07:11 -0400 Received: from virtual3.netaktiv.com ([80.67.170.53] helo=mail.bortzmeyer.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI9rZ-0006bq-IN for ltru@ietf.org; Tue, 29 Aug 2006 16:07:11 -0400 Received: by mail.bortzmeyer.org (Postfix, from userid 10) id BED60240814; Tue, 29 Aug 2006 22:07:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 1DAA4112F6; Tue, 29 Aug 2006 22:02:09 +0200 (CEST) Date: Tue, 29 Aug 2006 22:02:09 +0200 From: Stephane Bortzmeyer To: Addison Phillips Message-ID: <20060829200209.GB8845@sources.org> References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> <20060829192841.GE22065@ccil.org> <44F49947.1040301@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F49947.1040301@yahoo-inc.com> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 3.1 User-Agent: Mutt/1.5.9i X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ltru@ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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, Aug 29, 2006 at 12:45:11PM -0700, Addison Phillips wrote a message of 60 lines which said: > You are entirely correct that implementing the ABNF for > grandfathered is the wrong thing to do. I discovered this the hard way, when testing my parser. Shouldn't we add a warning to implementors in RFC 3066ter? _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 16:41:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAOX-0001uR-Lp; Tue, 29 Aug 2006 16:41:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAOW-0001tm-4d for ltru@ietf.org; Tue, 29 Aug 2006 16:41:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIAOW-0003il-2l for ltru@ietf.org; Tue, 29 Aug 2006 16:41:12 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIANW-0005gf-1m for ltru@ietf.org; Tue, 29 Aug 2006 16:40:12 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GIANR-00004q-4a; Tue, 29 Aug 2006 16:40:05 -0400 Date: Tue, 29 Aug 2006 16:40:05 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: Test suite for language tags? Message-ID: <20060829204005.GM22065@ccil.org> References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> <20060829192841.GE22065@ccil.org> <44F49947.1040301@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F49947.1040301@yahoo-inc.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: -2.6 (--) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips scripsit: > If the list changes, that would be bad. Ideally, with a couple of > registrations and some deprecations, the list will entirely be formed of > tags that have no future, allowing a list to be, actually, a Good Thing > (not just "here they are", but also "don't use these any more, even > though they remain valid"). Here's my conclusions about each of the 34: Tag Type Action Preferred value === ==== ====== =============== art-lojban Broken Already deprecated jbo cel-gaulish Broken Deprecated in 3066ter en-boont Regular Redundant in 3066bis en-GB-oed Irregular Preserved en-scouse Regular Redundant in 3066bis i-ami Irregular Deprecated in 3066ter ami i-bnn Irregular Deprecated in 3066ter bnn i-default Irregular Preserved i-enochian Irregular Deprecated in 3066ter not known i-hak Irregular Already deprecated zh-hakka i-klingon Irregular Already deprecated tlh i-lux Irregular Already deprecated lb i-mingo Irregular Deprecated in 3066ter not known i-navajo Irregular Already deprecated nv i-pwn Irregular Deprecated in 3066ter pwn i-tao Irregular Deprecated in 3066ter tao i-tay Irregular Deprecated in 3066ter tal i-tsu Irregular Deprecated in 3066ter tsu no-bok Broken Already deprecated nb no-nyn Broken Already deprecated nn sgn-BE-fr Irregular Deprecated in 3066ter not known sgn-BE-nl Irregular Deprecated in 3066ter not known sgn-CH-de Irregular Deprecated in 3066ter sgn-sgg zh-cmn Regular Redundant in 3066ter zh-cmn-Hans Regular Redundant in 3066ter zh-cmn-Hant Regular Redundant in 3066ter zh-gan Regular Redundant in 3066ter zh-guoyu Irregular Already deprecated zh-cmn zh-hakka Irregular Deprecated in 3066ter zh-hak zh-min Broken Deprecated in 3066ter zh-min-nan Irregular Deprecated in 3066ter zh-nan zh-wuu Regular Redundant in 3066ter zh-xiang Irregular Deprecated in 3066ter zh-hsn zh-yue Regular Redundant in 3066ter A Regular tag is one that is both syntactically and semantically regular; a Broken tag is one that is syntactically regular but semantically irregular (it does not mean what it appears to mean); an Irregular tag is one that is syntactically irregular. So 8 tags will be changed to redundant in the RFC 3066ter regime; of the remaining 24, all will be deprecated except i-default and en-GB-oed. Possible discrepancies: a) Nothing in 639-3 seems to correspond directly to i-mingo or i-enochian. b) We may decide not to deprecate cel-gaulish or zh-min, which are sort of mini-macrolanguages. c) The split between sgn-BE-fr and sgn-BE-nl seems to be finer than 639-3 recognizes; we may need variant subtags to handle these. -- As you read this, I don't want you to feel John Cowan sorry for me, because, I believe everyone cowan@ccil.org will die someday. http://www.ccil.org/~cowan --From a Nigerian-type scam spam _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 17:13:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAu4-00027R-0p; Tue, 29 Aug 2006 17:13:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAq7-0000gp-M3 for ltru@lists.ietf.org; Tue, 29 Aug 2006 17:09:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIAlb-00073k-6n for ltru@lists.ietf.org; Tue, 29 Aug 2006 17:05:04 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GI9oW-0001Bg-Np for ltru@lists.ietf.org; Tue, 29 Aug 2006 22:04:01 +0200 Received: from 212.82.251.133 ([212.82.251.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Aug 2006 22:04:00 +0200 Received: from nobody by 212.82.251.133 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Aug 2006 22:04:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 29 Aug 2006 22:02:06 +0200 Organization: Lines: 33 Message-ID: <44F49D3E.38F7@xyzzy.claranet.de> References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> <20060829192841.GE22065@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.133 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan wrote: > My point is that fr-Lat is not a *grandfathered* tag. > Nothing can ever be a grandfathered tag except the 34 > existing examples. The current ABNF for a grandfathered > tag, 1*3ALPHA 1*2("-" (2*8alphanum)), therefore recognizes > too much. Okay, now I got it. We could create more elaborated rules with less mismatches, something in the direction of "if it doesn't start with art / cel / en / i / no / sgn / zh it's certainly not grandfathered". And that won't match fr-Lat. Or we split it into i / sgn / zh, adding the rest as direct enumeration (1*art, 1*cel, 3*en, 2*no = 5 exceptions). But then we'd be in a situation if boont / gaulish / scouse are registered as ordinary variants. We could also decree that boont / gaulish / lobjan / scouse are dummy + deprecated variants, this would move 4 of the 34 to redundant. Maybe also guoyu / hakka / xiang for 7 of 34. We had reasons why we didn't do this for 3066bis, but if you have a better plan that could be changed in 3066ter. There's no chance to get rid of en-GB-oed / no-bok / no-nyn. > Listing them would do no harm. Listed they are, you propose to copy the list into the ABNF. For en / no / sgn / zh I don't see a perfect syntax solution. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 17:13:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAu4-00027V-3m; Tue, 29 Aug 2006 17:13:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIAq7-0000gp-LA for ltru@lists.ietf.org; Tue, 29 Aug 2006 17:09:43 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIAld-00073k-Lo for ltru@lists.ietf.org; Tue, 29 Aug 2006 17:05:06 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GI9yp-0003yo-Sm for ltru@lists.ietf.org; Tue, 29 Aug 2006 22:14:40 +0200 Received: from 212.82.251.133 ([212.82.251.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Aug 2006 22:14:39 +0200 Received: from nobody by 212.82.251.133 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Aug 2006 22:14:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Tue, 29 Aug 2006 22:13:16 +0200 Organization: Lines: 11 Message-ID: <44F49FDC.74A8@xyzzy.claranet.de> References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> <44F49584.216B@xyzzy.claranet.de> <44F49742.5040504@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.133 X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 1.6 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > All of the sgn-xx-yy tags (3 of these), all of the i-xxxx > tags (13 of them), plus the Oxford tag. Yes, sgn-BE-fr, sgn-BE-nl, sgn-CH-de, en-GB-oed. For i-xxxx a parser should have no problem, a special case like x-yyyy, but not really "irregular". Depends on how you implement it. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 17:33:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBD3-000733-W6; Tue, 29 Aug 2006 17:33:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIBD3-00072j-41 for ltru@lists.ietf.org; Tue, 29 Aug 2006 17:33:25 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIBCz-0002Eb-Og for ltru@lists.ietf.org; Tue, 29 Aug 2006 17:33:25 -0400 Received: from [172.21.148.224] (wlanvpn-mc2e-246-224.corp.yahoo.com [172.21.148.224]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k7TLX8IA016237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 14:33:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=YbrU/fCX7yI3aWUs2jbf68q3xfCx8jO0/XufdAij/ZJXQwNd0MffDczgQXvJupJL Message-ID: <44F4B294.1090705@yahoo-inc.com> Date: Tue, 29 Aug 2006 14:33:08 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Frank Ellermann Subject: Re: [Ltru] Re: Test suite for language tags? References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> <44F49584.216B@xyzzy.claranet.de> <44F49742.5040504@yahoo-inc.com> <44F49FDC.74A8@xyzzy.claranet.de> In-Reply-To: <44F49FDC.74A8@xyzzy.claranet.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org > > Yes, sgn-BE-fr, sgn-BE-nl, sgn-CH-de, en-GB-oed. For i-xxxx > a parser should have no problem, a special case like x-yyyy, > but not really "irregular". Depends on how you implement it. > Anything starting with a singleton (except "x-" and the grandfathered "i-*" list of tags) is illegal. A parser that claims to be either well-formed or validating should yack on such a tag. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 18:54:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GICTY-0005x8-Rx; Tue, 29 Aug 2006 18:54:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GICTX-0005sb-5Q for ltru@ietf.org; Tue, 29 Aug 2006 18:54: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 1GIA9T-0001hE-81 for ltru@ietf.org; Tue, 29 Aug 2006 16:25:39 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIA0P-0004tO-VQ for ltru@ietf.org; Tue, 29 Aug 2006 16:16:21 -0400 Received: from [172.21.148.122] (wlanvpn-mc2e-246-122.corp.yahoo.com [172.21.148.122]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k7TKGBqC013178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 13:16:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=dROJ8n//dAICHvewk7hIFuZgZlmSsssmc3lZaGhWvUx2uqjDTXm+TPDiTSx29x9a Message-ID: <44F4A08B.6060309@yahoo-inc.com> Date: Tue, 29 Aug 2006 13:16:11 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> <20060829192841.GE22065@ccil.org> <44F49947.1040301@yahoo-inc.com> <20060829200209.GB8845@sources.org> In-Reply-To: <20060829200209.GB8845@sources.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -17.6 (-----------------) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 discovered this the hard way, when testing my parser. Shouldn't we > add a warning to implementors in RFC 3066ter? > Yes. It should be more explicit. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 20:23:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIDrz-000300-Dv; Tue, 29 Aug 2006 20:23:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIDry-0002u1-Cz for ltru@ietf.org; Tue, 29 Aug 2006 20:23:50 -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 1GIAe9-0005ni-81 for ltru@ietf.org; Tue, 29 Aug 2006 16:57:21 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIAU0-00060l-6r for ltru@ietf.org; Tue, 29 Aug 2006 16:46:53 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GIATz-0000G6-NW; Tue, 29 Aug 2006 16:46:51 -0400 Date: Tue, 29 Aug 2006 16:46:51 -0400 To: Addison Phillips Subject: Re: [Ltru] Re: Test suite for language tags? Message-ID: <20060829204651.GO22065@ccil.org> References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> <20060829192841.GE22065@ccil.org> <44F49947.1040301@yahoo-inc.com> <20060829204005.GM22065@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060829204005.GM22065@ccil.org> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: -2.6 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org John Cowan scripsit: > A Regular tag is one that is both syntactically and semantically regular; > a Broken tag is one that is syntactically regular but semantically > irregular (it does not mean what it appears to mean); an Irregular tag > is one that is syntactically irregular. In hindsight I should have used "Misleading" instead of "Broken". -- John Cowan cowan@ccil.org http://ccil.org/~cowan Female celebrity stalker, on a hot morning in Cairo: "Imagine, Colonel Lawrence, ninety-two already!" El Auruns's reply: "Many happy returns of the day!" _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 21:16:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIEgX-0008Hx-Jn; Tue, 29 Aug 2006 21:16:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIEgW-0008Hs-It for ltru@ietf.org; Tue, 29 Aug 2006 21:16:04 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIEgU-0000SO-5d for ltru@ietf.org; Tue, 29 Aug 2006 21:16:04 -0400 Received: by nf-out-0910.google.com with SMTP id l23so25288nfc for ; Tue, 29 Aug 2006 18:16: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:mime-version:content-type:x-google-sender-auth; b=QwhcG/uDn/QBgDl5EnQJksaSjLt+f3DPzB5mLllCHQoqPSEy46j6mNR34a/p54fzDJcgLrzz6s4d8Wmd4RQZ7bXlSqoZagPqZOS2nHT0IuiAx96U4vhloRA6gsk7NNs5XAbbVjDV7MCmOW7vsk+W2i0DoVUn3LTSKZt9lklrnUI= Received: by 10.49.10.3 with SMTP id n3mr2007284nfi; Tue, 29 Aug 2006 18:16:00 -0700 (PDT) Received: by 10.49.20.10 with HTTP; Tue, 29 Aug 2006 18:16:00 -0700 (PDT) Message-ID: <30b660a20608291816gf528f42w53428011360ed00b@mail.gmail.com> Date: Tue, 29 Aug 2006 18:16:00 -0700 From: "Mark Davis" To: "LTRU Working Group" , "ietf-languages@iana.org" MIME-Version: 1.0 X-Google-Sender-Auth: c11553792e8b0066 X-Spam-Score: 0.3 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Subject: [Ltru] Prefix bug X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.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="===============1858365629==" Errors-To: ltru-bounces@ietf.org --===============1858365629== Content-Type: multipart/alternative; boundary="----=_Part_25830_29482708.1156900560932" ------=_Part_25830_29482708.1156900560932 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I just realized that many people may not realize an implication of 3.4. Stability of IANA Registry Entries regarding Prefixes. This has implications for both the LTRU group and the ietf-languages group, so am sending to both. That is, that section says the following: - 3. Values in the field 'Prefix' MAY be added to records of type 'variant' via the registration process. - 4. Values in the field 'Prefix' MAY be modified, so long as the modifications broaden the set of prefixes. That is, a prefix MAY be replaced by one of its own prefixes. For example, the prefix "en-US" could be replaced by "en", but not by the prefixes "en-Latn", "fr", or "en-US-boont". If one of those prefixes were needed, a new Prefix SHOULD be registered. - 5. Values in the field 'Prefix' MUST NOT be removed. However, if you have no Prefix, that is equivalent to having Prefix: *; that is, any prefix will work. Thus suppose that a variant FOOBAR is registered with no Prefix, it can be combined with anything: en-foobar de-Cyrl-AU-1901-foobar zh-foobar ... Thus #4 ("Values in the field 'Prefix' MAY be modified, so long as the modifications broaden the set of prefixes.") implies that once a variant is registered *without* a prefix, it can *never* have a Prefix added, since that would limit the set of valid prefixes that it can be used with. Thus for the FOOBAR case above, once encoded we cannot later add a Prefix. Luckily this situation does not currently arise: all the current variants have Prefixes. For the future, the registration group should be aware of this implication. - Variants with no prefixes are like region codes; they can, and forever will be able to, be combined with any prefix. - Variants with at least one prefix are limited to all and only the registered prefixes. We should make this clearer in the next version, so that people don't trip up on it. Mark P.S. People designing validating parsers should also be aware of this. ------=_Part_25830_29482708.1156900560932 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I just realized that many people may not realize an implication of 3.4. Stability of IANA Registry Entries regarding Prefixes. This has implications for both the LTRU group and the ietf-languages group, so am sending to both.

That is, that section says the following:
  • 3. Values in the field 'Prefix' MAY be added to records of type 'variant' via the registration process.
  • 4. Values in the field 'Prefix' MAY be modified, so long as the modifications broaden the set of prefixes. That is, a prefix MAY be replaced by one of its own prefixes. For example, the prefix "en-US" could be replaced by "en", but not by the prefixes "en-Latn", "fr", or "en-US-boont". If one of those prefixes were needed, a new Prefix SHOULD be registered.
  • 5. Values in the field 'Prefix' MUST NOT be removed.
However, if you have no Prefix, that is equivalent to having Prefix: *; that is, any prefix will work. Thus suppose that a variant FOOBAR is registered with no Prefix, it can be combined with anything:

en-foobar
de-Cyrl-AU-1901-foobar
zh-foobar
...

Thus #4 ("Values in the field 'Prefix' MAY be modified, so long as the modifications broaden the set of prefixes.") implies that once a variant is registered *without* a prefix, it can *never* have a Prefix added, since that would limit the set of valid prefixes that it can be used with. Thus for the FOOBAR case above, once encoded we cannot later add a Prefix.

Luckily this situation does not currently arise: all the current variants have Prefixes. For the future, the registration group should be aware of this implication.
  • Variants with no prefixes are like region codes; they can, and forever will be able to, be combined with any prefix.
  • Variants with at least one prefix are limited to all and only the registered prefixes.
We should make this clearer in the next version, so that people don't trip up on it.

Mark

P.S. People designing validating parsers should also be aware of this.
------=_Part_25830_29482708.1156900560932-- --===============1858365629== 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 --===============1858365629==-- From ltru-bounces@ietf.org Tue Aug 29 21:57:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIFKq-0008WM-JQ; Tue, 29 Aug 2006 21:57:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIFKo-0008WB-GW for ltru@lists.ietf.org; Tue, 29 Aug 2006 21:57:42 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIFKm-0003Ue-UK for ltru@lists.ietf.org; Tue, 29 Aug 2006 21:57:42 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GIFKb-0007Ma-9j for ltru@lists.ietf.org; Wed, 30 Aug 2006 03:57:29 +0200 Received: from pd9fba8e8.dip0.t-ipconnect.de ([217.251.168.232]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Aug 2006 03:57:29 +0200 Received: from nobody by pd9fba8e8.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Aug 2006 03:57:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 30 Aug 2006 03:56:58 +0200 Organization: Lines: 12 Message-ID: <44F4F069.75B2@xyzzy.claranet.de> References: <30b660a20608291816gf528f42w53428011360ed00b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8e8.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Re: Prefix bug X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis wrote: > We should make this clearer in the next version, so that > people don't trip up on it. A solution is s/SHOULD/MUST/ in the variant registration rule. If later something "generic" is desperately needed folks can still create a "g-" extension registry. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Aug 29 22:31:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIFrW-0005iy-Ij; Tue, 29 Aug 2006 22:31:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIFrV-0005i8-P2 for ltru@ietf.org; Tue, 29 Aug 2006 22:31:29 -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 1GIFeK-0006Bt-Tn for ltru@ietf.org; Tue, 29 Aug 2006 22:17:52 -0400 Received: from mercury.ccil.org ([192.190.237.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIFTk-0005GX-3w for ltru@ietf.org; Tue, 29 Aug 2006 22:06:57 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1GIFTj-0003KK-P1; Tue, 29 Aug 2006 22:06:55 -0400 Date: Tue, 29 Aug 2006 22:06:55 -0400 To: Mark Davis Subject: Re: [Ltru] Prefix bug Message-ID: <20060830020655.GD31441@ccil.org> References: <30b660a20608291816gf528f42w53428011360ed00b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30b660a20608291816gf528f42w53428011360ed00b@mail.gmail.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: -2.6 (--) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "ietf-languages@iana.org" , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Mark Davis scripsit: > Thus #4 ("Values in the field 'Prefix' MAY be modified, so long as > the modifications broaden the set of prefixes.") implies that once a > variant is registered *without* a prefix, it can *never* have a Prefix > added, since that would limit the set of valid prefixes that it can > be used with. Thus for the FOOBAR case above, once encoded we cannot > later add a Prefix. Construe, construe! #4 does not say that the modification must broaden the set of *valid* prefixes, simply the set of prefixes (i.e. the set of prefixes mentioned in the record). What *is* discrepant is that nothing in 3066bis prevents a tagger from using a tag like "en-1901", even though that tag is not valid. 2.2.5 should be modified to prevent this. -- John Cowan cowan@ccil.org At times of peril or dubitation, http://www.ccil.org/~cowan Perform swift circular ambulation, With loud and high-pitched ululation. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 30 00:03:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIHIW-0000pS-4a; Wed, 30 Aug 2006 00:03:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIHIU-0000p6-Fi for ltru@ietf.org; Wed, 30 Aug 2006 00:03:26 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIHIR-0001cK-3J for ltru@ietf.org; Wed, 30 Aug 2006 00:03:26 -0400 Received: from [10.72.72.149] (snvvpn1-10-72-72-c149.corp.yahoo.com [10.72.72.149]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k7U434RY030814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Aug 2006 21:03:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=uz1iLJOpVOLzojwlEekhSwL56oEOPYksz4GShM1tjTFONUd5XLxPk/sXF/kBN+FB Message-ID: <44F50DF8.2080005@yahoo-inc.com> Date: Tue, 29 Aug 2006 21:03:04 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: John Cowan Subject: Re: [Ltru] Prefix bug References: <30b660a20608291816gf528f42w53428011360ed00b@mail.gmail.com> <20060830020655.GD31441@ccil.org> In-Reply-To: <20060830020655.GD31441@ccil.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "ietf-languages@iana.org" , LTRU Working Group X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Prefixes for variants are NOT required (there is a strong SHOULD and multiple suggestions that a variant without a prefix is a Bad Idea). As Mark notes, once registered without a prefix, registering *any* prefix will break any and all (non-prefix-bearing) tags. However, the stability prohibition on narrowing the meaning would seem to be in force. John Cowan wrote: > > #4 does not say that the modification must broaden the set of *valid* > prefixes, simply the set of prefixes (i.e. the set of prefixes mentioned > in the record). > > What *is* discrepant is that nothing in 3066bis prevents a tagger > from using a tag like "en-1901", even though that tag is not valid. > 2.2.5 should be modified to prevent this. > Validators should not have been required to check variant prefixes, given what the working group's intentions were originally. However, I very much like firming the registration requirements for variants (from SHOULD to MUST on having at least one Prefix) and leaving the validation rules in place. Notice that this would effectively forbid generic variants (the reason for the SHOULD in the first place). Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 30 06:59:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GINmb-0001KV-Gw; Wed, 30 Aug 2006 06:58:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GINma-0001Ht-37 for ltru@lists.ietf.org; Wed, 30 Aug 2006 06:58:56 -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 1GIMSF-0001Kt-47 for ltru@lists.ietf.org; Wed, 30 Aug 2006 05:33:51 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIMOg-0008OW-EF for ltru@lists.ietf.org; Wed, 30 Aug 2006 05:30:11 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 6751326C10D; Wed, 30 Aug 2006 11:30:03 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 0ADC726C158; Wed, 30 Aug 2006 11:30:00 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id D84D658ED51; Wed, 30 Aug 2006 11:30:00 +0200 (CEST) Date: Wed, 30 Aug 2006 11:30:00 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060830093000.GA31895@nic.fr> References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <44D4AC42.79E0@xyzzy.claranet.de> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: -2.5 (--) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Aug 05, 2006 at 04:33:38PM +0200, Frank Ellermann wrote a message of 18 lines which said: > > The best thing would probably to create four text files > > containing tags, one per line (may be with comments allowed), > > with: > > > * two files for well-formedness (OK/broken), > > * two files for validaty (OK/invalid). > > > So anyone could use it as a test suite, by converting the > > text files to Junit, PyUnit, HUnit, whatever. > > Maybe it's possible to publish this in a 3066ter appendix, > or better a separate document (informational RFC). I often > miss examples and test cases in other documents. I agree and here are the two files I currently use (my parser succeeds for all these tags). I suggest that they should be displayed in a public place (is there a Web site for LTRU?) and added in a future RFC. Corrections and additions are of course very welcome, as well as test reports from other implementations, so we can be sure we all use the same language :-) --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="well-formed-tags.txt" fr fr-Latn fr-fra # Extended tag fr-Latn-FR fr-Latn-419 fr-FR ax-TZ # Not in the registry, but well-formed fr-shadok # Variant fr-y-myext-myext2 fra-Latn # ISO 639 can be 3-letters fra fra-FX i-klingon # grandfathered with singleton no-bok # grandfathered without singleton fr-Lat # Extended mn-Cyrl-MN mN-cYrL-Mn fr-Latn-CA en-US fr-Latn-CA i-enochian # Grand fathered x-fr-CH sr-Latn-CS es-419 sl-nedis de-CH-1996 de-Latg-1996 sl-IT-nedis en-a-bbb-x-a-ccc de-a-value en-Latn-GB-boont-r-extended-sequence-x-private en-x-US az-Arab-x-AZE-derbend es-Latn-CO-x-private en-US-boont ab-x-abc-x-abc # anything goes after x ab-x-abc-a-a # ditto i-default # grandfathered i-klingon # grandfathered --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="broken-tags.txt" f f-Latn fr-Latn-F a-value en-a-bbb-a-ccc # 'a' appears twice tlh-a-b-foo i-notexist # grandfathered but not registered: invalid, even if we only test well-formedness abcdefghi-012345678 ab-abc-abc-abc-abc ab-abcd-abc ab-ab-abc ab-123-abc a-Hant-ZH a1-Hant-ZH ab-abcde-abc ab-1abc-abc ab-ab-abcd ab-123-abcd ab-abcde-abcd ab-1abc-abcd ab-a-b ab-a-x ab--ab ab-abc- -ab-abc ab-c-abc-r-toto-c-abc # 'c' appears twice --tKW2IUtsqtDRztdT 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 --tKW2IUtsqtDRztdT-- From ltru-bounces@ietf.org Wed Aug 30 19:54:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIZso-0002H2-1w; Wed, 30 Aug 2006 19:54:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIZsm-0002EB-Er for ltru@lists.ietf.org; Wed, 30 Aug 2006 19:54:08 -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 1GIYgJ-0001oX-Cb for ltru@lists.ietf.org; Wed, 30 Aug 2006 18:37:11 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIY3x-0006PX-GT for ltru@lists.ietf.org; Wed, 30 Aug 2006 17:57:40 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GIY3B-0001Un-JD for ltru@lists.ietf.org; Wed, 30 Aug 2006 23:56:45 +0200 Received: from pd9fba8b6.dip0.t-ipconnect.de ([217.251.168.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Aug 2006 23:56:45 +0200 Received: from nobody by pd9fba8b6.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Aug 2006 23:56:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Wed, 30 Aug 2006 23:53:52 +0200 Organization: Lines: 45 Message-ID: <44F608F0.4AC5@xyzzy.claranet.de> References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba8b6.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: -2.6 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Stephane Bortzmeyer wrote: > is there a Web site for LTRU? The IETF tools WG page is http://tools.ietf.org/wg/ltru - at the moment this tool offers links to the charter, drafts, list, jabber, etc., but no other documents or links. Addison's page is at http://www.inter-locale.com/ - that had a complete history of all drafts back to the times before LTRU, but I don't find it at the moment. Doug's page is at http://users.adelphia.net/~dewell/ - oops, with a HTML version of UTN 16, replacing PDF by HTML on my box. Maybe publish the test suite as dummy I-D, the tools server should show it as "related" if the third token is "-ltru-", for a draft-bortzmeyer-ltru-tag-test-suite-00.txt or similar. IIRC there was a sudden interest in xml2rfc one second after MARID was closed, and you were one of the interested folks :-) If it's only about an Archived-At link, that exists already: http://permalink.gmane.org/gmane.ietf.ltru/5279 GMaNe apparently mangles the attachments, the original is here: http://article.gmane.org/gmane.ietf.ltru/5279/raw > additions are of course very welcome For well-formed: abcd-Latn AaBbCcDd-x-y-any-x For broken: abcd-efg aabbccddE Maybe use abcde instead of abcd if you have alpha4 as "not yet possible", alpha5 is possible today (individually registered). Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Aug 30 20:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIah2-0002Px-6b; Wed, 30 Aug 2006 20:46:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIah0-0002Pg-Mi for ltru@lists.ietf.org; Wed, 30 Aug 2006 20:46:02 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIagz-0002dB-Bh for ltru@lists.ietf.org; Wed, 30 Aug 2006 20:46:02 -0400 Received: from [10.72.76.138] (snvvpn2-10-72-76-c138.corp.yahoo.com [10.72.76.138]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k7V0jmFr076577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Aug 2006 17:45:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=amG2Y28qx+KuTwOrh4V/isZGoGPT86u1HPm0A/mizW//umMlNXxVTPiZAblA3Inp Message-ID: <44F6313D.2070000@yahoo-inc.com> Date: Wed, 30 Aug 2006 17:45:49 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Stephane Bortzmeyer Subject: Re: [Ltru] Re: Test suite for language tags? References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> In-Reply-To: <20060830093000.GA31895@nic.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org >> or better a separate document (informational RFC). I often >> miss examples and test cases in other documents. > > I agree and here are the two files I currently use (my parser succeeds > for all these tags). I suggest that they should be displayed in a > public place (is there a Web site for LTRU?) and added in a future > RFC. An informational RFC would be quite easy to produce and I think would be worthwhile. I'd even be willing to do some work on it in a couple of weeks. > I suggest that they should be displayed in a > public place (is there a Web site for LTRU?) As Frank points out, you could probably do worse than http://www.inter-locale.com. It has the HTML versions of the various drafts (not all are linked any more), plus other information. I'm happy to host other's materials, within reason. Addison -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 31 02:56:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIgTu-0001Ar-2s; Thu, 31 Aug 2006 02:56:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIgTs-00018V-G9 for ltru@ietf.org; Thu, 31 Aug 2006 02:56:52 -0400 Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIgTo-00076F-Mh for ltru@ietf.org; Thu, 31 Aug 2006 02:56:52 -0400 Received: from scmse1.scbb.aoyama.ac.jp (scmse1 [133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id k7V6uWCO007542 for ; Thu, 31 Aug 2006 15:56:35 +0900 (JST) Received: from (133.2.206.133) by scmse1.scbb.aoyama.ac.jp via smtp id 27fd_d5f5bb78_38bd_11db_8df3_0014221fa3c9; Thu, 31 Aug 2006 15:56:31 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:58136) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 31 Aug 2006 15:56:47 +0900 Message-Id: <6.0.0.20.2.20060830160500.081dc4e0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 30 Aug 2006 16:06:57 +0900 To: John Cowan , Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Re: Test suite for language tags? In-Reply-To: <20060829192841.GE22065@ccil.org> References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> <20060829192841.GE22065@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 04:28 06/08/30, John Cowan wrote: >Addison Phillips scripsit: >> Which ones did you have in mind here, John? I don't think I see any that >> will become redundant at present (unless you have designs on en-scouse >> or en-boont). Deprecated, certainly, but not redundant, I think. > >See my last two ietf-languages postings. [chair hat on] This is very difficult for people to follow, in particular for those who are reading postings in the archives. Everybody, please be more explicit, in particular for stuff from other lists. Regards, Martin. #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 31 03:28:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIgxy-0008Me-GD; Thu, 31 Aug 2006 03:27:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIgxw-0008LV-Oc for ltru@lists.ietf.org; Thu, 31 Aug 2006 03:27:56 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIgoe-0002PT-4t for ltru@lists.ietf.org; Thu, 31 Aug 2006 03:18:22 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 6A02C26C1E0; Thu, 31 Aug 2006 09:18:09 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 98A9726C197; Thu, 31 Aug 2006 09:18:08 +0200 (CEST) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 8BD06A1D93E; Thu, 31 Aug 2006 09:18:08 +0200 (CEST) Date: Thu, 31 Aug 2006 09:18:08 +0200 From: Stephane Bortzmeyer To: Frank Ellermann Message-ID: <20060831071808.GA16919@nic.fr> References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F608F0.4AC5@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44F608F0.4AC5@xyzzy.claranet.de> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@lists.ietf.org Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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 Wed, Aug 30, 2006 at 11:53:52PM +0200, Frank Ellermann wrote a message of 45 lines which said: > Maybe publish the test suite as dummy I-D, the tools server should > show it as "related" if the third token is "-ltru-", for a > draft-bortzmeyer-ltru-tag-test-suite-00.txt or similar. OK, what's the opinion of the WG about that? > For well-formed: > > abcd-Latn > AaBbCcDd-x-y-any-x > > For broken: > > abcd-efg > aabbccddE Thanks, abcd-Latn discovered yet another bug in my parser :-) _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 31 05:22:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIikd-0006Ud-5S; Thu, 31 Aug 2006 05:22:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIikc-0006UY-Hj for ltru@lists.ietf.org; Thu, 31 Aug 2006 05:22:18 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIikb-0000qh-8W for ltru@lists.ietf.org; Thu, 31 Aug 2006 05:22:18 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GIikS-0003Oz-Oy for ltru@lists.ietf.org; Thu, 31 Aug 2006 11:22:09 +0200 Received: from pd9fbadba.dip0.t-ipconnect.de ([217.251.173.186]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Aug 2006 11:22:08 +0200 Received: from nobody by pd9fbadba.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Aug 2006 11:22:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 31 Aug 2006 11:21:18 +0200 Organization: Lines: 15 Message-ID: <44F6AA0E.153C@xyzzy.claranet.de> References: <001d01c6b78a$07b37890$040aa8c0@DGBP7M81> <44D36598.1020304@yahoo-inc.com> <20060829092257.GA22927@nic.fr> <20060829133301.GE8529@ccil.org> <44F474AC.7070906@yahoo-inc.com> <20060829192841.GE22065@ccil.org> <6.0.0.20.2.20060830160500.081dc4e0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fbadba.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: 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: > please be more explicit He tries to register variants "boont" and "scouse" with prefix "en". This would move two "grandfathered" tags to "redundant", reducing the number of "special cases" for a test suite. Relevant for any en-* (excl. en-GB-oed) if 3066ter goes for a "variants MUST have a prefix" instead of the SHOULD in 3066bis. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 31 09:56:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIn1h-0006ud-NX; Thu, 31 Aug 2006 09:56:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIn1g-0006sE-7Z for ltru@lists.ietf.org; Thu, 31 Aug 2006 09:56:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIlcO-0006nq-8h for ltru@lists.ietf.org; Thu, 31 Aug 2006 08:26:00 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIknN-0003j6-Oo for ltru@lists.ietf.org; Thu, 31 Aug 2006 07:33:21 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k7VBXDIb002841 for ; Thu, 31 Aug 2006 20:33:14 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 6332_7ccf11bc_38e4_11db_9f5a_0014221f2a2d; Thu, 31 Aug 2006 20:33:12 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:52995) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 31 Aug 2006 20:33:19 +0900 Message-Id: <6.0.0.20.2.20060831201004.101ab8d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 31 Aug 2006 20:15:19 +0900 To: Addison Phillips , Stephane Bortzmeyer From: Martin Duerst Subject: Re: [Ltru] Re: Test suite for language tags? In-Reply-To: <44F6313D.2070000@yahoo-inc.com> References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org [chair hat on] We haven't put development of test suites into our new charter, but if you think this should be added, you should say so in response to the call for comments on the IETF list. In my impression, test suites are often done in coordination with an IETF WG, but not usually as an official WG task. But my implession might be wrong. I don't think there is anything in the IETF process that would forbid a WG to develop a test suite, or to accept a test suite proposal as a WG draft. [Ted, can you tell us what/where the IETF rules re. test suites are?] So I would in principle not be opposed to the WG (assuming we get rechartered) taking on a test suite internet draft, but we should be sure that this won't slow us down on our main deliverables. Regards, Martin. At 09:45 06/08/31, Addison Phillips wrote: > >>> or better a separate document (informational RFC). I often >>> miss examples and test cases in other documents. >> I agree and here are the two files I currently use (my parser succeeds >> for all these tags). I suggest that they should be displayed in a >> public place (is there a Web site for LTRU?) and added in a future >> RFC. > >An informational RFC would be quite easy to produce and I think would be worthwhile. I'd even be willing to do some work on it in a couple of weeks. > > > I suggest that they should be displayed in a > > public place (is there a Web site for LTRU?) > >As Frank points out, you could probably do worse than http://www.inter-locale.com. It has the HTML versions of the various drafts (not all are linked any more), plus other information. I'm happy to host other's materials, within reason. > >Addison > >-- >Addison Phillips >Globalization Architect -- Yahoo! Inc. > >Internationalization is an architecture. >It is not a feature. > >_______________________________________________ >Ltru mailing list >Ltru@ietf.org >https://www1.ietf.org/mailman/listinfo/ltru #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 31 10:15:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInKh-0008Ll-7S; Thu, 31 Aug 2006 10:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInKf-0008Lf-EE for ltru@lists.ietf.org; Thu, 31 Aug 2006 10:15:49 -0400 Received: from rsmtp1.corp.yahoo.com ([207.126.228.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GInKd-000154-0g for ltru@lists.ietf.org; Thu, 31 Aug 2006 10:15:49 -0400 Received: from [10.72.76.138] (snvvpn2-10-72-76-c138.corp.yahoo.com [10.72.76.138]) (authenticated bits=0) by rsmtp1.corp.yahoo.com (8.13.6/8.13.6/y.rout) with ESMTP id k7VEFfkq004480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Aug 2006 07:15:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=GXYRzqx1QarIdS448qUrKHMp/yebhtuRH5Ufgkpfyf4+cD46tQHdzkwDHeCsQK/Q Message-ID: <44F6EF0E.20602@yahoo-inc.com> Date: Thu, 31 Aug 2006 07:15:42 -0700 From: Addison Phillips User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Re: Test suite for language tags? References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> In-Reply-To: <6.0.0.20.2.20060831201004.101ab8d0@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -15.0 (---------------) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org I was thinking of an individual submission. Addison Martin Duerst wrote: > [chair hat on] > > We haven't put development of test suites into our new charter, > but if you think this should be added, you should say so in > response to the call for comments on the IETF list. > > In my impression, test suites are often done in coordination > with an IETF WG, but not usually as an official WG task. But > my implession might be wrong. I don't think there is anything > in the IETF process that would forbid a WG to develop a test > suite, or to accept a test suite proposal as a WG draft. > [Ted, can you tell us what/where the IETF rules re. test > suites are?] > > So I would in principle not be opposed to the WG (assuming we > get rechartered) taking on a test suite internet draft, but > we should be sure that this won't slow us down on our main > deliverables. > > Regards, Martin. > > > At 09:45 06/08/31, Addison Phillips wrote: >>>> or better a separate document (informational RFC). I often >>>> miss examples and test cases in other documents. >>> I agree and here are the two files I currently use (my parser succeeds >>> for all these tags). I suggest that they should be displayed in a >>> public place (is there a Web site for LTRU?) and added in a future >>> RFC. >> An informational RFC would be quite easy to produce and I think would be worthwhile. I'd even be willing to do some work on it in a couple of weeks. >> >>> I suggest that they should be displayed in a >>> public place (is there a Web site for LTRU?) >> As Frank points out, you could probably do worse than http://www.inter-locale.com. It has the HTML versions of the various drafts (not all are linked any more), plus other information. I'm happy to host other's materials, within reason. >> >> Addison >> >> -- >> Addison Phillips >> Globalization Architect -- Yahoo! Inc. >> >> Internationalization is an architecture. >> It is not a feature. >> >> _______________________________________________ >> Ltru mailing list >> Ltru@ietf.org >> https://www1.ietf.org/mailman/listinfo/ltru > > > #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University > #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp > -- Addison Phillips Globalization Architect -- Yahoo! Inc. Internationalization is an architecture. It is not a feature. _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 31 10:52:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInuK-0003SR-JI; Thu, 31 Aug 2006 10:52:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GInuJ-0003SJ-4G for ltru@lists.ietf.org; Thu, 31 Aug 2006 10:52:39 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GInuH-0004zM-Qo for ltru@lists.ietf.org; Thu, 31 Aug 2006 10:52:39 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GIntz-0002aQ-FW for ltru@lists.ietf.org; Thu, 31 Aug 2006 16:52:19 +0200 Received: from pd9fba976.dip0.t-ipconnect.de ([217.251.169.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Aug 2006 16:52:19 +0200 Received: from nobody by pd9fba976.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 31 Aug 2006 16:52:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@lists.ietf.org From: Frank Ellermann Date: Thu, 31 Aug 2006 16:51:07 +0200 Organization: Lines: 27 Message-ID: <44F6F75B.76F@xyzzy.claranet.de> References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> <44F6EF0E.20602@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba976.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] Re: Test suite for language tags? X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org Addison Phillips wrote: > I was thinking of an individual submission. Yes, not necessarily an RFC, an I-D is fine, or an "ION" (an experiment run by Harald), or just a text file on your site. > Martin Duerst wrote: >> not usually as an official WG task. But my implession might >> be wrong. I guess you're right, "they" don't like conformance testing. As "official" WG task we'd get into discussions about the format etc., the ABNF isn't complex enough for such efforts. Stephane's two lists amended by whatever Addison, Doug, and others see is actually all... >> we should be sure that this won't slow us down on our main >> deliverables. ...it's more or less ready. Of course it would need an update if we change the prefix-SHOULD into a prefix-MUST. We're talking about 26+39 (or 28+41) lines of text, less than 2 KB. Frank _______________________________________________ Ltru mailing list Ltru@ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Aug 31 14:12:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIr1r-0004WS-Td; Thu, 31 Aug 2006 14:12:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIr1q-0004W9-9N for ltru@lists.ietf.org; Thu, 31 Aug 2006 14:12:38 -0400 Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIr1m-00013O-73 for ltru@lists.ietf.org; Thu, 31 Aug 2006 14:12:38 -0400 Received: from scmse2.scbb.aoyama.ac.jp (scmse2 [133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id k7VICUlE003089 for ; Fri, 1 Sep 2006 03:12:32 +0900 (JST) Received: from (133.2.206.133) by scmse2.scbb.aoyama.ac.jp via smtp id 6331_4455fd5e_391c_11db_9d9b_0014221f2a2d; Fri, 01 Sep 2006 03:12:29 +0900 X-AuthUser: duerst@it.aoyama.ac.jp Received: from Tanzawa.it.aoyama.ac.jp ([133.2.210.1]:44272) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 1 Sep 2006 03:12:42 +0900 Message-Id: <6.0.0.20.2.20060901024806.109a6d90@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 01 Sep 2006 02:54:24 +0900 To: Addison Phillips From: Martin Duerst Subject: Re: [Ltru] Re: Test suite for language tags? In-Reply-To: <44F6EF0E.20602@yahoo-inc.com> References: <20060801203351.GA8854@sources.org> <44CFC23A.2000703@yahoo-inc.com> <20060802072709.GA17404@nic.fr> <44D21ACD.4040707@yahoo-inc.com> <20060804165720.GA24037@sources.org> <44D4AC42.79E0@xyzzy.claranet.de> <20060830093000.GA31895@nic.fr> <44F6313D.2070000@yahoo-inc.com> <6.0.0.20.2.20060831201004.101ab8d0@localhost> <44F6EF0E.20602@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Frank Ellermann , ltru@lists.ietf.org X-BeenThere: ltru@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ltru-bounces@ietf.org At 23:15 06/08/31, Addison Phillips wrote: >I was thinking of an individual submission. Yes, I know. I mainly brought up the possibility of a WG draft so that it has been mentioned. Regards, Martin. >Martin Duerst wrote: >> [chair hat on] >> So I would in principle not be opposed to the WG (assuming we >> get rechartered) taking on a test suite internet draft, but >> we should be sure that this won't slow us down on our main >> deliverables. >> 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