From ltru-bounces@ietf.org Fri Apr 1 02:21:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19262; Fri, 1 Apr 2005 02:21:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGa3-0005X6-0N; Fri, 01 Apr 2005 02:28:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGRy-0001Ni-2B; Fri, 01 Apr 2005 02:20:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGRv-0001Ml-Tc for ltru@megatron.ietf.org; Fri, 01 Apr 2005 02:20:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18409 for ; Fri, 1 Apr 2005 02:20:10 -0500 (EST) Received: from web42008.mail.yahoo.com ([66.218.93.176]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHGZC-0005Vz-3m for ltru@ietf.org; Fri, 01 Apr 2005 02:27:43 -0500 Received: (qmail 14954 invoked by uid 60001); 1 Apr 2005 07:20:01 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=db771TL75E0rKr0sU2ptxBmqOOhNY9bbN551heQf70rU6gwtUcsicNub0366o7UbNJFkl6JF5eTbIBL9Bz6/0cWOMJ+jRm/cxkUDNtqDJwTOGfpjz3JzOA4qySTsdMy9H1AI47IlK3jbjjCB2NgwRtyf0YJx7219ur7blP/4YIc= ; Message-ID: <20050401072001.14945.qmail@web42008.mail.yahoo.com> Received: from [83.99.66.202] by web42008.mail.yahoo.com via HTTP; Fri, 01 Apr 2005 08:20:01 BST Date: Fri, 1 Apr 2005 08:20:01 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: RE: [Ltru] Re: Language transformation To: ltru@ietf.org In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AD17F2D@irvmbxw01.quest.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 8bit This is attempt to distill the previous discussions and a proposal to go forward: 1) Transliteration Use this term as it is the one most people associate with this mechanisms. Define the term in a way the includes transcription and similar nuances. I will write a short definition for approval. 2) Semantics The important issue is to be able to tag transliteration; it should be specifically mentioned and explained in the RFC. 3) Syntaxis The syntaxis must follow the current situation and avoid unwarranted complications. As per Addison proposal "don't distinguish [transliteration] per-se, just register variants for the different ones". Assuming that "widegile" (8 characters) is a registered variant, I assume that one could have the following language tags: zh-widegile zh-TW-widegile 4) Transliteration Registry Transliterations must be first registered in the proposed "Transliteration Registry". Then following the appropiate procedure, there would be an application for inclusion as a variant. The Transliteration Registry is out of scope of LTRU. Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 02:38:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22346; Fri, 1 Apr 2005 02:38:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGqc-00065Q-Oy; Fri, 01 Apr 2005 02:45:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGir-0005Da-Of; Fri, 01 Apr 2005 02:37:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGio-0005DM-5a for ltru@megatron.ietf.org; Fri, 01 Apr 2005 02:37:38 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22297 for ; Fri, 1 Apr 2005 02:37:36 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050401073706.DVHK2192.mta9.adelphia.net@DEWELL> for ; Fri, 1 Apr 2005 02:37:06 -0500 Message-ID: <005f01c5368d$6cab9540$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050331180027.LYQV2135.mta4.adelphia.net@megatron.ietf.org> Date: Thu, 31 Mar 2005 23:35:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Language transformation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit M.T. Carrasco Benitez wrote: > From the experience of the last time, having the target language > caused confusion: it must be very clear that the text tagged by > "ru-t-foo" is Russian. So having "ru-t-fr" lead to believe that there > was some French in the text. There actually isn't a way to construct a single language tag that means "Russian with some French mixed in." In a tag that has an extension singleton such as 't', everything following the singleton is part of the extended meaning (until you get to the next singleton, or the end of the tag). So in the tag "ru-t-fr", you know that the 'fr' is part of the extension because it comes after the singleton 't'. The draft explains this in Section 2.2.6, with another example: "All subtags following the singleton and before another singleton are part of the extension. Example: In the tag 'fr-a-Latn', the subtag 'Latn' does not represent the script subtag 'Latn' defined in the IANA Language Subtag Registry. Its meaning is defined by the extension 'a'." > Also, I suspect (I am not certain) that transformation schemes would > typically target more than one language; except in languages like > Armenian with a very specific script. That is why it would be good to be able to indicate both (a) schemes that are language-dependent and (b) schemes that are not. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 02:46:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22830; Fri, 1 Apr 2005 02:46:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHGyI-0006JA-Q9; Fri, 01 Apr 2005 02:53:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGqd-0007JD-Uv; Fri, 01 Apr 2005 02:45:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHGqP-0007I6-Th for ltru@megatron.ietf.org; Fri, 01 Apr 2005 02:45:30 -0500 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22732 for ; Fri, 1 Apr 2005 02:45:28 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050401074458.HYLA4618.mta13.adelphia.net@DEWELL> for ; Fri, 1 Apr 2005 02:44:58 -0500 Message-ID: <006601c5368e$84e84e40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050331192543.YDBK2135.mta2.adelphia.net@megatron.ietf.org> Date: Thu, 31 Mar 2005 23:43:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Language transformation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > What should be considered is the result to the user. A recording or a > transcoding resulting in the same voice-text, look the same to me? I > do not see script difference between a voice, in Russian and a voice > in English speaking the same way? Questions can be about the sex, > accent, timber, age of the voice and about the speaking style? Same a > short-hand or phonetic or icons or music or menu figures (as long as > there is a common understanding of what means what - what is a > script?) Spoken content should not be tagged as to script, transcription method, or transliteration method. Conversely, if a system were developed for tagging spoken accents, that system should not be applied to written content. This should be apparent. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 03:20:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01283; Fri, 1 Apr 2005 03:20:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHHMw-0007Dh-DD; Fri, 01 Apr 2005 03:19:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHHEx-0003Eg-S8; Fri, 01 Apr 2005 03:10:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHHEl-0003EY-Qf for ltru@megatron.ietf.org; Fri, 01 Apr 2005 03:10:40 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00810 for ; Fri, 1 Apr 2005 03:10:38 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050401081008.EGXI2192.mta9.adelphia.net@DEWELL> for ; Fri, 1 Apr 2005 03:10:08 -0500 Message-ID: <006d01c53691$ff839b20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050331230207.TMQV2128.mta1.adelphia.net@megatron.ietf.org> Date: Fri, 1 Apr 2005 00:08:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Language transformation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit M.T. Carrasco Benitez wrote: > As proposed in section 4 of "Codes for language transformation" > http://www1.ietf.org/mail-archive/web/ltru/current/msg00387.html > > "Two registries are need: > > - IANA > - Schemes for Language Transformation" If you read the sections on extensions in the LTRU draft, you will see that for a given extension, the specification and list of valid extension subtags lives within an RFC, not within the IANA Language Subtag Registry. On the other hand, if these are implemented as variant subtags, there is no need for a separate registry to provide further explanation or description of the variants. They are listed in the registry, with a recommended prefix, and that is that. Each has a registration form, as described in Section 3.3, which provides more information about the variant, but that information is not normative and not used by software when forming tags. > Lets call "wadegiles" the "transliteration identifier". As commented > in a previous message, the IANA register should contain the list of > unique transliteration identifier. Example: > > # Transformations > transformation | widegile | | yyyy-mm-dd | | > transformation | pinyin| | yyyy-mm-dd | | One thing you need to realize is that there is not going to be a separate type of subtag, called "transformation," that can be six or eight characters long and directly follows the primary language subtag. The variant subtag already has those characteristics. A parser must be able to identify the type of each subtag uniquely based on its length and position. That won't work if a 6-letter variant called "scouse" and a 6-letter transformation called "pinyin" both exist. This is why Addison's choice (a) is not really an option, and the choice is basically between (b) and (c), where (b) uses the variant mechanism and (c) uses the extension mechanism. I prefer (c) partly because it allows more flexibility in the syntax of transformation subtags. You can create subtags that are 2 to 8 characters long, whereas variants must be 5 to 8 characters long, or 4 characters if they start with a digit (unlikely in this case). You can use 2-letter or 3-letter subtags to indicate the target language of a transcription scheme. I know you think this will confuse users, but I don't. I think "ru-t-fr" is a very elegant way to say "Russian, transformed so as to be readable by a French-speaking person." Another reason I prefer the extension approach is that this category seems inherently open-ended, compared with the existing variants, and assigning the maintenance of this database to an authority other than IANA seems consistent with Tomas's vision of how the mechanism should work. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 03:29:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01927; Fri, 1 Apr 2005 03:29:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHHeN-0007ve-7F; Fri, 01 Apr 2005 03:37:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHHVD-0005Ip-2m; Fri, 01 Apr 2005 03:27:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHHVB-0005Ik-Oy for ltru@megatron.ietf.org; Fri, 01 Apr 2005 03:27:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01887 for ; Fri, 1 Apr 2005 03:27:36 -0500 (EST) Received: from web42003.mail.yahoo.com ([66.218.93.171]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHHcS-0007qp-Gd for ltru@ietf.org; Fri, 01 Apr 2005 03:35:09 -0500 Received: (qmail 40885 invoked by uid 60001); 1 Apr 2005 08:27:26 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=JuwqTqzD1q1KFwOrF/N1hB86oFJv1fMv49QCBRB+uoNroOMj5gzNEKTCr/GK9UYH9NH6nTEbmnVd3ykLoVngdBVpsLOiViXhoC6FHhNEteHsNO2LyKz4mS9aPMNSZyWwLxgj7eDQ8aIfQpXlniGkaGfThb5dnMGa7dNVHIvTng4= ; Message-ID: <20050401082726.40883.qmail@web42003.mail.yahoo.com> Received: from [83.99.66.202] by web42003.mail.yahoo.com via HTTP; Fri, 01 Apr 2005 09:27:26 BST Date: Fri, 1 Apr 2005 09:27:26 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: Re: [Ltru] Re: Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 8bit >[Carrasco] >> By the way, Armenians are celebrating this year the 1600th anniversary >> of their script. It would be nice to go to the "Targmanchats Ton" >> (translators day). This is a case of very successful standardisation: >> would LTRU be here in 1600 years ? -:) > > [Ewell] > Well, certainly not the working group. We're only chartered to do 2 > documents, and the second is scheduled to go into Last Call this August. Even if the Last Call was scheduled for August 2105, the Last Call of the members would come before -:), though members could be replaced ... > If you mean, "Will the revised language tagging standard exist and be > relevant in 1600 years?" the answer is probably no. But then, most > technology standards don't last as long as most writing systems, so that > seems an odd comparison. Lets be optimistic and go for a "yes".
About 1610 years ago, King Vramshapuh Arshakouni and Catholicos Sahak Partev (Areas Directors) started a working group with Saint Mesrop Mashtots as Chair. He travelled (mailing list) in Armenia to collect data on the different dialects; went to Alexandria and delivered the alphabet (RFC) in 405 AD. The working group did a quite good job as the 36 characters alphabet did not have to be updated for about 500 years (RFCbis). Not due to a mistake in their part: the were a couple of new sounds in the language and their principle is to have a direct correletion between the phonetics and the ortography. Yes, a very successful standardisation.
Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 06:42:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15295; Fri, 1 Apr 2005 06:42:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHKes-0006NQ-Vy; Fri, 01 Apr 2005 06:49:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHKWI-0006Vb-Qu; Fri, 01 Apr 2005 06:40:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHKWF-0006VM-MZ for ltru@megatron.ietf.org; Fri, 01 Apr 2005 06:40:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15119 for ; Fri, 1 Apr 2005 06:40:51 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHKdX-0006KV-MO for ltru@ietf.org; Fri, 01 Apr 2005 06:48:28 -0500 Received: from lns-p19-19-idf-82-254-247-171.adsl.proxad.net ([82.254.247.171] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DHKW9-0006cE-Ut; Fri, 01 Apr 2005 03:40:50 -0800 Message-Id: <6.1.2.0.2.20050401104829.042ec010@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Apr 2005 13:40:44 +0200 To: "M.T. Carrasco Benitez" , ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Language transformation In-Reply-To: <20050331221215.3408.qmail@web42003.mail.yahoo.com> References: <20050331221215.3408.qmail@web42003.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 At 00:12 01/04/2005, M.T. Carrasco Benitez wrote: >--- "JFC (Jefsey) Morfin" wrote: > > What should be considered is the result to the user. > >Yes. This is the point. > > > A recording or a > > transcoding resulting in the same voice-text, look the same to me? I do > not > > see script difference between a voice, in Russian and a voice in English > > speaking the same way? Questions can be about the sex, accent, timber, age > > of the voice and about the speaking style? Same a short-hand or > phonetic or > > icons or music or menu figures (as long as there is a common understanding > > of what means what - what is a script?) > > > > Describing the process would be like documenting the version of Apache > > being used to show an HTML page? > >There is real need for tagging transliterations and the requirements are as >discussed before. I accept that there might be a need. I accept the requirements are along the line you discussed. But I would need to understand what is the need. The way to address a need should start from the description of the need, not from a partial way to address it. >Some of your comments above might well fall in a similar model to >transliteration; so any volunteer ? Other comments looks more like metadata, >though the language is also metadata. True. IMHO we have two possibilities: - either to define them all and we will take a huge amount of time for nothing, as you say elsewhere the users communities will decide. - or we structure an open concept able to support several semantic and syntaxes and any user/standard addition in the proper place and understandable to the participants to a relation. I obviously favor the second one, but legacy, transition and legitimate needs of some applications designers (such as seemingly some Unicode and W3C persons) should also be supported. This should be easy in having the first solution supported as one of the possibilities of the second one. As a general comment, after a debate of three months I still fail to understand the need. Which means the basics who, when, why, how. This affects the whole proposition credibility. Harald said four years ago: we will store a few data in the IANA through a privately organized list. This solution turned out to be too limited to some and experimented huge delays in updating the IANA server. The first question is therefore to know if RFC 3066 made good choices. Errare humanum est (RFC 3066), diabolicum perseverare (current idea of dramatically increasing the load on a lame solution). Until I have a clear description of the need(s), I do not think a response can be described and quantified. Until then I do not think we can say if the IANA is the appropriate location and for what. For example, I suppose that your voice reading support (not to enter the debate of the trans- faux-amis) concerns primarily the mobile and mail reading in market terms. There are 3 billions phones and 1.3 billions mobiles. This makes 5.3 billions of probable users. We all understand that we need to discuss better to know how many times a year, a month, a day they may have to download 300 or 600.000 bytes? Thank you. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 06:44:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15473; Fri, 1 Apr 2005 06:44:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHKh9-0006Ti-Ef; Fri, 01 Apr 2005 06:52:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHKWJ-0006Vf-7W; Fri, 01 Apr 2005 06:40:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHKWF-0006VP-MZ for ltru@megatron.ietf.org; Fri, 01 Apr 2005 06:40:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15125 for ; Fri, 1 Apr 2005 06:40:52 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHKdZ-0006Kc-9F for ltru@ietf.org; Fri, 01 Apr 2005 06:48:29 -0500 Received: from lns-p19-19-idf-82-254-247-171.adsl.proxad.net ([82.254.247.171] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DHKWC-0006cE-Dc; Fri, 01 Apr 2005 03:40:52 -0800 Message-Id: <6.1.2.0.2.20050401103458.042e0140@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 01 Apr 2005 12:35:15 +0200 To: John Cowan From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] In-Reply-To: <20050331201010.GA6550@skunk.reutershealth.com> References: <4A7C6FA2AB31194E80E13FE585F6A21292A1CE@EVS-EC1-NODE1.surrey.ac.uk> <6.1.2.0.2.20050331201305.042e0c60@mail.jefsey.com> <20050331201010.GA6550@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru , "L.Gillam" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 At 22:10 31/03/2005, John Cowan wrote: >Many dictionaries do not have this last item, particularly dictionaries of >and in English, where the boundaries are extremely permeable. 1. Unfortunately. However I suppose you will make a difference between Basic American and English. But you have to consider the purpose: you cannot consider a lingua franca as a reference. 2. I am sure that all the people who work on ontologies round the world desserve better a comment by their standardisers. 3. Standard are made by cute people to permit less interested people to live better. Don't you agree? There is something which says that dumbness of some only enlights smartness of others. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 07:50:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20063; Fri, 1 Apr 2005 07:50:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHLip-0000GL-57; Fri, 01 Apr 2005 07:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHLal-0005yx-LJ; Fri, 01 Apr 2005 07:49:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHLak-0005ys-Lh for ltru@megatron.ietf.org; Fri, 01 Apr 2005 07:49:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19989 for ; Fri, 1 Apr 2005 07:49:35 -0500 (EST) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHLi2-0000C3-FB for ltru@ietf.org; Fri, 01 Apr 2005 07:57:13 -0500 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Fri, 1 Apr 2005 13:48:03 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 13:48:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] is there some wiskey in the jar - [was: Registry in record-jar format] Date: Fri, 1 Apr 2005 13:48:02 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A1D7@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] Thread-Index: AcU2KK2oDUAUiTB7Q8Krx6ibkebRLAAgEl4A From: "L.Gillam" To: ltru X-OriginalArrivalTime: 01 Apr 2005 12:48:03.0040 (UTC) FILETIME=[0AF1DE00:01C536B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: quoted-printable > >Also, where did you discover that Moore's law was a "joke"? Not from=20 > >Intel, surely? (http://www.intel.com/research/silicon/mooreslaw.htm) >=20 > Moore law applies to computers not to networks. On networks=20 > Metcalfe and=20 > Reeds laws are to be used as a never reached limit or as a=20 > maximum filtering. Well, it's about "Cramming more components onto integrated circuits". If = network technologies do not use ICs then you are correct. What I see is = a move from 10Mbps -> 100MBps -> 1G -> 10G on TP, and various increases = on wireless. I'd say this would have quite an impact on communication = throughput. Perhaps you disagree? > I have no other model to offer than existing systems. This is=20 > why I ask and=20 > why I worry. I do not document, I ask it to be documented.=20 Not a general requirement then, and not something that I guess could be = fulfilled in any conclusive way. So, how would your expectations be = satisfied? NB: comments below about IANA loads.=20 > There is to date=20 > no other request to IANA such as some of the discussed=20 > propositions. IMHO=20 > the IANA is not conceptually what fits these demands. I just want to=20 > understand first what is the demand. This Draft is made to=20 > address specific=20 > application needs: I just ask how will this applications=20 > operate. What are=20 > the risks of usage creep. > I am open to every suggestion. But first I want to understand=20 > the problem.=20 > Who is accessing, for what purpose, the length and the size of the=20 > transaction. For example caching what, where, when, for how long. I=20 > documented long caching in using a langtags file and yearly update??? >=20 Ah, more predictions required. One existing demand would seem to come = from xml:lang. So, applications using XML markup may have use of it. = Does every XML application need to query the registry every time = xml:lang is to be used? I suspect not. Do you need to update that which = has not changed? My guess would be no - how would you? A "date not = changed" attribute? Could a future registry operate on a push = (publish/subscribe) model rather than a pull basis? I don't see why not. = If it were OS updates that used the data, would the OS company pull 1 = copy then distribute many within their updates? Sounds reasonable, and = somewhat akin to current practices.=20 > >Is your concern purely financial? >=20 > My concern is also financial. There is a necessary compromise=20 > between cost,=20 > quality of the service, volume of access, procedures, ways to=20 > limiting=20 > traffic. I want to understand first what we are talking=20 > about. So, I ask. > I have yet no real idea of when=20 > people will access, why, etc. and I mean in real life, not in=20 > theory:=20 The answer, then, is the current use of RFC 3066. Other uses are theory. Who knows what technology may be invented tomorrow that has a better use for it? > If someone updates his tables every=20 > time it calls someone, the impact is zero, but if he does it=20 > only when he=20 > calls a new language, if he speaks only one language, no=20 > impact, but if he=20 > speaks 10 languages the impact if 10 times more, plus possible errors. Suppose I have a table. It is 2 years old. I need a tag that isn't in = there. Why? If the "major" languages are covered (the 639-1, 639-2, = 3166, 15924 lang3tag?), the impact is likely to be at the "scale" of a = community rather than a global outreach. I find out if there are = updates. So, if it's a new language that isn't in this set, there may be = an update. Generative mechanisms allow me some freedom (see previous = discussions).=20 > There is no use in having to enter/read something which is=20 > not on your=20 > keyboard. People at the Airport can type ASCII - for the time=20 > being as=20 > probably RFID will change many things. Not end users. Pardon? My keyboard shows certain characters. Hopefully pressing them = results in the same character being shown on screen. Certain internal = mappings are happening that enables this. The internal representation is = a series of 1s and 0s. I did not enter those. At the airport, the human = sees something. The "internal representation" makes it onto your luggage = for use by other systems. YYZ is a good example of a non-mnemonic code = that works perfectly well for indentifying such items. Items with the = wrong code should be flagged and dealt with by other procedures. The = internal representation versus the external presentation. An ASCII = internal representation is sufficient for providing the link to, for = example, a Unicode presentation. Gratuitous simplifications = notwithstanding. =20 > >Where is it documented? How do people use it for=20 > interoperability? Who=20 > >ensures it is well maintained? >=20 > No one. You know the Babel symbolism: it is precisely to free=20 > people from=20 > the one who wanted things to be well maintained. So people=20 > are free to do=20 > it the way they want. So there is no single point of failure. 7520=20 > languages are the way to make us free from someone ensuring=20 > maintenance.=20 > This is for us to feel secure we found a reliable way to be=20 > stable, secure=20 > and innovative without having to rely on a single one, with all the=20 > possible cross verifications, which will insure us that our=20 > system is well=20 > maintained. >=20 > More complex, smarter, more work to find it? Probably yes. The Tower of Babel is certainly an example of how to impede progress. People are always free to do what they want - within the laws of = society,=20 morality, .... man is free, but everywhere in chains as the saying goes. I'm curious here - does the Academie Francaise not maintain French? Are there not major works on endangered languages? And how do we know which language is which so that we can organise content and not be given stuff = we don't know how to read? If you didn't have such a system, you'd have to=20 invent it. > Open a dictionary. It will tell you five things about every=20 > word, plus=20 > information on the meaning, nature and syntax: >=20 > - the language (on the cover) > - the script (you see it) > - where it was published (ISSN-ISBN) or the title > - the author (on the cover) > - either it is standard style by default, or it mentions the=20 > style: fam.=20 > pop, old, etc. The computational solution to language is for a human to read a = dictionary? The dictionary doesn't tell me this information about every = word - I have to infer it from the cover. OED also contains etymological = information, part of speech data, ..... which English dictionary is the = "standard style"? What do I do about symbols from = physics/chemistry/mathematics in definitions? Should I infer the script = from the text? Ever try using a dictionary for a language you don't = know? It's one of those nice catch-22s. > There are many needs to consider. >=20 > 1. application needs. The only considered needs are XML/HTML=20 > pages by W3C=20 > and some CLDR needs? OPES, DNS, Web Services, History, Users=20 > communities,=20 > CRC, etc. and innovation. Predict innovation? You will become a very rich man. Web Services? Ummm = ... seem to use XML. I see text..... = http://www.w3.org/International/ws/ws-i18n-requirements-edit/ History? = Described where, on the web? Books in libraries? User communities? Users = of what? Web texts? Other texts? DNS? If I can't remember the site = address I tend to use a natural language string with Google. Would I = want to remember ever more complicated addresses? How memorable is the = following address: = http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=3D= 32347 compared to the search string "ISO 16642" on Google? OPES? Do they = *need* language tagging? Perhaps the "transformation" extension? Surely = they've found RFC 1766/3066 or ISO 639 already? RSS 3.0 perhaps? > 2. there is not such a thing as a "wider community".=20 Pardon? Now there are no users? I'm confused by this comment. > Again, at this time we do not discuss a solution. We just need to=20 > understand if there is a problem (I am surprised nobody came=20 > in saying:=20 > there is no problem because ....).=20 Nobody has yet been able to agree with you that there is a problem. = Abscence of evidence is not necessarily evidence of abscence. But what = evidence do you have that there is a problem? Hypotheticals can be = passed around ad nauseam. > Roughly there are comments=20 > saying "on OS=20 > installation" - I do not know why, nor the size of the=20 > access. But with=20 > usual 10 times markup this means 3 to 4 billions a year=20 > increasing. I do=20 > not know the size, but I tend to think the lower the size the=20 > greater the=20 > number of accesses? See OS comments above. Where do you get your OS updates from? > My first real concern is why do I need the IANA for? Let take=20 > the DNS. The=20 > IANA delivers the Master file to the Alpha Machine and to the=20 > Internic, and=20 > the Whois file online. I would be very interested in IANA=20 > documenting the=20 > load each represents. But it's not a user need, right? I'd be interested in all sorts of = information. Doesn't mean I'll ever get it. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 12:54:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21287; Fri, 1 Apr 2005 12:54:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQTH-0004Ys-1N; Fri, 01 Apr 2005 13:02:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQJS-00044H-SV; Fri, 01 Apr 2005 12:52:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQJR-000449-SO for ltru@megatron.ietf.org; Fri, 01 Apr 2005 12:52:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20891 for ; Fri, 1 Apr 2005 12:52:02 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQQn-0004NQ-RE for ltru@ietf.org; Fri, 01 Apr 2005 12:59:43 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j31Hpjc5018829; Fri, 1 Apr 2005 12:51:46 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 1 Apr 2005 12:51:43 -0500 Date: Fri, 1 Apr 2005 12:51:42 -0500 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: Language transformation Message-ID: <20050401175036.GH6550@skunk.reutershealth.com> References: <20050331230207.TMQV2128.mta1.adelphia.net@megatron.ietf.org> <006d01c53691$ff839b20$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006d01c53691$ff839b20$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Doug Ewell scripsit: > On the other hand, if these are implemented as variant subtags, there is > no need for a separate registry to provide further explanation or > description of the variants. They are listed in the registry, with a > recommended prefix, and that is that. This overstates the case. In order to make practical use of such orthographies, they must be defined somewhere, and if the users of trans*tions find it useful to have a registry of these things, then LTRU has nothing to say about it. After all, if you want to know what "nn" codes for, the registry will tell you "Nynorsk", but if you want to know what Nynorsk is, or how to recognize it, or how to spell-check it, you must look elsewhere. At the moment there is no single "elsewhere" to look: this may be accounted good or bad. -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. --Edsger Dijkstra _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 13:06:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22555; Fri, 1 Apr 2005 13:06:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQec-000581-Mj; Fri, 01 Apr 2005 13:13:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQWr-0007G4-9r; Fri, 01 Apr 2005 13:05:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQWp-0007Fw-A0 for ltru@megatron.ietf.org; Fri, 01 Apr 2005 13:05:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22522 for ; Fri, 1 Apr 2005 13:05:52 -0500 (EST) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQeC-00057K-7j for ltru@ietf.org; Fri, 01 Apr 2005 13:13:32 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 10:05:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Language transformation Date: Fri, 1 Apr 2005 10:05:41 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7540@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU2i0ekQx2AxSuKQBac2wudbhixsQAVGq+w From: "Addison Phillips" To: "M.T. Carrasco Benitez" , X-OriginalArrivalTime: 01 Apr 2005 18:05:42.0356 (UTC) FILETIME=[6B2EB140:01C536E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Some comments below. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of M.T. Carrasco Benitez > Sent: jeudi 31 mars 2005 23:20 > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Language transformation >=20 > This is attempt to distill the previous discussions and a proposal to = go > forward: >=20 > 1) Transliteration > Use this term as it is the one most people associate with this = mechanisms. > Define the term in a way the includes transcription and similar = nuances. > I will write a short definition for approval. >=20 > 2) Semantics > The important issue is to be able to tag transliteration; it should be > specifically > mentioned and explained in the RFC. [Addison Phillips]=20 (wearing the editor's hat for a second) How should it be explained? Variants are already explained and cover = orthographic variations and other things like transliteration. = Specifically, section 2.2.9 defines what can be registered as a variant: Dialect or other divisions or variations within a language, its = orthography, writing system, regional variation, or historical usage may = be registered as variant subtags. An example is the 'scouse' subtag (the = Scouse dialect of English). Would it be sufficient to modify this to say: Dialect or other divisions or variations within a language, its = orthography, writing system, regional or historical usage, = transliteration, or other transformation or distinguishing variation may = be registered as variant subtags. An example is the 'scouse' subtag (the = Scouse dialect of English). (Returning to private commentary) Phrased another way, why should the RFC draft attempt to explain = transmogrification any more than some other language variation? The = draft as it sits is not very specific precisely to allow for a wide = range of variation to be considered or proposed for registration. >=20 > 3) Syntaxis > The syntaxis must follow the current situation and avoid unwarranted > complications. > As per Addison proposal "don't distinguish [transliteration] per-se, = just > register > variants for the different ones". Assuming that "widegile" (8 = characters) > is a > registered variant, I assume that one could have the following = language > tags: >=20 > zh-widegile > zh-TW-widegile [Addison Phillips]=20 Yes. Exactly so. >=20 > 4) Transliteration Registry > Transliterations must be first registered in the proposed = "Transliteration > Registry". > Then following the appropiate procedure, there would be an application = for > inclusion > as a variant.=20 [Addison Phillips]=20 Why? More specifically: what distinguishes a transliteration from some = other variant registration request? How does the Subtag Reviewer or the = ietf-languages list tell if it should or should not entertain a specific = request? I understand the desire for a vetting process, but this RFC = will need to explain what the rules are for registering variants = clearly. If you go down the variant path, then someone quite clearly = could (at least attempt to) register a transliteration variant without = it being in the Transliteration Registry, perhaps by not calling it a = transliteration. Conversely, whatever the process is for creating = entries in the Transliteration Registry would affect the actions of the = ietf-languages list and the Subtag Reviewer who are maintaining LTRU's = registry.=20 Since your work is in its very early stages, I don't think it mature = enough to enshrine in the LTRU draft except as a possibility for = registration of variants (as above). Perhaps if it is ready for 3066ter = that would be an appropriate time to consider incorporating more formal, = normative language related to transliterations and/or a registry = thereof. For now you'll be better off if we DON'T mention it because = your work will not be constrained by an existing RFC (and LTRU will be = better off by not constraining its delivery date or actions = artificially). I should add that the ietf-languages community is pretty responsible. = They have actively avoided, for example, creating subtags that would be = grandfathered in 3066bis for nearly two years now. As long as progress = on and the syntax of transliteration variants is clear, I would suspect = that the registry would act 'de facto' according to the rules expected = to be formalized in the near future regarding transliterations. The key = is to define the structure, syntax, and other formalisms required for = transliterations well enough so that no registrations are performed that = cause problems for a transliteration registry in the future. [Addison Phillips] > The Transliteration Registry is out of scope of = LTRU. [Addison Phillips]=20 Yes, I agree, although the (non-)existence of that registry affects = LTRU's ability to refer to it in a normative sense. >=20 > Regards > Tomas >=20 >=20 > Send instant messages to your online friends = http://uk.messenger.yahoo.com >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 13:16:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23500; Fri, 1 Apr 2005 13:16:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQok-0005Yu-4Q; Fri, 01 Apr 2005 13:24:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQgy-0000d8-Qz; Fri, 01 Apr 2005 13:16:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHQgx-0000aL-Kb for ltru@megatron.ietf.org; Fri, 01 Apr 2005 13:16:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23468 for ; Fri, 1 Apr 2005 13:16:20 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHQoJ-0005V7-Kf for ltru@ietf.org; Fri, 01 Apr 2005 13:24:01 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 10:16:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Language transformation Date: Fri, 1 Apr 2005 10:16:08 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7555@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU249rD7DOMJ/0OSvuR/IYfGgdxawAAZU+A From: "Addison Phillips" To: "John Cowan" , "Doug Ewell" X-OriginalArrivalTime: 01 Apr 2005 18:16:09.0200 (UTC) FILETIME=[E0CF7F00:01C536E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable Hmm... Transmogrifications not mentioned in the Language Subtag Registry cannot = be used in (valid) language tags. Having a separate registry is, indeed, = useful. But it isn't a requirement for registering a variant and cannot = practically be made into one until there is an RFC and registry for the = other. I suspect, based on past conversations with Mark and others, that = transliteration may not be well-defined by a single, simple tag. It = might be that this is wrong: I'm no expert. But it might not (and end up = needing an extension after all). Therefore I think that trans*tions need = some bake time to ensure we know what makes the most sense. In my last email I proposed some language allowing for the possibility = of registering trans*tion variants, but I don't think we're in a = position to go beyond that in 3066bis. I don't see an ironclad = requirement for handling these in language tags currently (to date NO = registered values have even been proposed for indicating them), although = I don't dismiss the need either.=20 Is there something else we SHOULD do now? Or is my proposal enough, = giving Tomas time to pursue his work? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: vendredi 1 avril 2005 09:52 > To: Doug Ewell > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Language transformation >=20 > Doug Ewell scripsit: >=20 > > On the other hand, if these are implemented as variant subtags, = there is > > no need for a separate registry to provide further explanation or > > description of the variants. They are listed in the registry, with = a > > recommended prefix, and that is that. >=20 > This overstates the case. In order to make practical use of such > orthographies, > they must be defined somewhere, and if the users of trans*tions find = it > useful to have a registry of these things, then LTRU has nothing to = say > about it. >=20 > After all, if you want to know what "nn" codes for, the registry will = tell > you "Nynorsk", but if you want to know what Nynorsk is, or how to > recognize > it, or how to spell-check it, you must look elsewhere. At the moment > there > is no single "elsewhere" to look: this may be accounted good or bad. >=20 > -- > John Cowan jcowan@reutershealth.com www.ccil.org/~cowan > www.reutershealth.com > The competent programmer is fully aware of the strictly limited size = of > his own > skull; therefore he approaches the programming task in full humility, = and > among > other things he avoids clever tricks like the plague. --Edsger = Dijkstra >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 13:49:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25966; Fri, 1 Apr 2005 13:49:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHRK9-0006gC-J4; Fri, 01 Apr 2005 13:56:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHRC8-0006hx-2H; Fri, 01 Apr 2005 13:48:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHRC5-0006hs-Pi for ltru@megatron.ietf.org; Fri, 01 Apr 2005 13:48:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25946 for ; Fri, 1 Apr 2005 13:48:30 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHRJS-0006fW-B6 for ltru@ietf.org; Fri, 01 Apr 2005 13:56:11 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Fri, 1 Apr 2005 10:46:18 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Fri, 1 Apr 2005 10:46:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Language transformation Date: Fri, 1 Apr 2005 10:45:56 -0800 Message-ID: Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU2i0ekQx2AxSuKQBac2wudbhixsQAVGq+wAAKbvIA= From: "Peter Constable" To: X-OriginalArrivalTime: 01 Apr 2005 18:46:16.0834 (UTC) FILETIME=[163E8E20:01C536EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > > The important issue is to be able to tag transliteration; it should be > > specifically > > mentioned and explained in the RFC. > Phrased another way, why should the RFC draft attempt to explain transmogrification > any more than some other language variation? The draft as it sits is not very specific > precisely to allow for a wide range of variation to be considered or proposed for > registration. I agree that it would be good to mention transliteration, but not to explain it, both because other comparable things aren't explained, and because -- as Tomas as pointed out several times -- trying to come up with an explanation that everyone would agree to is inviting polemic debates. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 13:51:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26050; Fri, 1 Apr 2005 13:51:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHRM7-0006ka-RT; Fri, 01 Apr 2005 13:58:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHRE6-00071Q-G2; Fri, 01 Apr 2005 13:50:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHRE4-00071L-RP for ltru@megatron.ietf.org; Fri, 01 Apr 2005 13:50:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26036 for ; Fri, 1 Apr 2005 13:50:33 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHRLS-0006kN-ED for ltru@ietf.org; Fri, 01 Apr 2005 13:58:14 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Fri, 1 Apr 2005 10:48:22 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Fri, 1 Apr 2005 10:51:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Language transformation Date: Fri, 1 Apr 2005 10:48:00 -0800 Message-ID: Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU249rD7DOMJ/0OSvuR/IYfGgdxawAAZU+AAAFtPvA= From: "Peter Constable" To: X-OriginalArrivalTime: 01 Apr 2005 18:51:08.0080 (UTC) FILETIME=[C3D72B00:01C536EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > Is there something else we SHOULD do now? Or is my proposal enough, giving Tomas > time to pursue his work? I think your suggestion to mention transliteration as a possible kind of variant, and perhaps something like zh-wadegile as a hypothetical example is adequate for now. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 14:31:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28483; Fri, 1 Apr 2005 14:31:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHRyu-00085M-O9; Fri, 01 Apr 2005 14:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHRrA-0003tV-3V; Fri, 01 Apr 2005 14:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHRr8-0003tA-U5 for ltru@megatron.ietf.org; Fri, 01 Apr 2005 14:30:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28425 for ; Fri, 1 Apr 2005 14:30:50 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHRyS-00084M-1Z for ltru@ietf.org; Fri, 01 Apr 2005 14:38:32 -0500 Received: from h-68-165-6-195.snvacaid.dynamic.covad.net ([68.165.6.195] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DHRr1-00029X-00 for ltru@ietf.org; Fri, 01 Apr 2005 11:30:51 -0800 Message-ID: <002801c536f1$77e2d5e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 1 Apr 2005 11:31:56 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Ltru] Fw: RFC 4042 on UTF-9 and UTF-18 Efficient Transformation Formats ofUnicode X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Hi - In the spirit of the day, and about as relevant to this WG as some of the recent barely-topical posting to this mailing list... > From: > To: > Cc: > Sent: Friday, April 01, 2005 9:13 AM > Subject: RFC 4042 on UTF-9 and UTF-18 Efficient Transformation Formats ofUnicode > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 4042 > > Title: UTF-9 and UTF-18 Efficient Transformation Formats > of Unicode > Author(s): M. Crispin > Status: Informational > Date: 1 April 2005 > Mailbox: UTF9@Lingling.Panda.COM > Pages: 9 > Characters: 19123 > Updates/Obsoletes/SeeAlso: None > > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4042.txt > > > ISO-10646 defines a large character set called the Universal > Character Set (UCS), which encompasses most of the world's writing > systems. The same set of codepoints is defined by Unicode, which > further defines additional character properties and other > implementation details. By policy of the relevant standardization > committees, changes to Unicode and amendments and additions to > ISO/IEC 646 track each other, so that the character repertoires and > code point assignments remain in synchronization. > > The current representation formats for Unicode (UTF-7, UTF-8, UTF-16) > are not storage and computation efficient on platforms that utilize > the 9 bit nonet as a natural storage unit instead of the 8 bit octet. > > This document describes a transformation format of Unicode that takes > advantage of the nonet so that the format will be storage and > computation efficient. > > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF list and the RFC-DIST list. > Requests to be added to or deleted from the IETF distribution list > should be sent to IETF-REQUEST@IETF.ORG. Requests to be > added to or deleted from the RFC-DIST distribution list should > be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. ... _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 15:08:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01579; Fri, 1 Apr 2005 15:08:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHSYh-0000wU-Mq; Fri, 01 Apr 2005 15:16:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHSOj-00087M-Ra; Fri, 01 Apr 2005 15:05:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHSOi-00087H-N3 for ltru@megatron.ietf.org; Fri, 01 Apr 2005 15:05:41 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01222 for ; Fri, 1 Apr 2005 15:05:36 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DHSMS-0001hg-O6 for ltru@lists.ietf.org; Fri, 01 Apr 2005 22:03:20 +0200 Received: from 212.82.251.41 ([212.82.251.41]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Apr 2005 22:03:20 +0200 Received: from nobody by 212.82.251.41 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 01 Apr 2005 22:03:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 01 Apr 2005 22:03:01 +0200 Organization: Lines: 41 Message-ID: <424DA8F5.37A1@xyzzy.claranet.de> References: <20050330165046.TVVC4900.mta8.adelphia.net@megatron.ietf.org> <004b01c53609$b5d0e920$030aa8c0@DEWELL> 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.41 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > Last Call for the registry draft is scheduled for May I really don't care about timetables decreed by somebody else, they are free to fix it when necessary. > I think we need to figure out the rules now, rather > than saving things for an unspecified "later." Too many changes at once would be confusing. One draft per month would be fine for me, let's see an April draft soon, and then a draft registry based on whatever it says. Depending on our editors this could already specify the record-jar or similar format, so that you have a chance to create a proper first I-D in this format. > Can you think of a use case for 200? As an optional replacement for old cs-CS / sk-CS / rom-CS tags. We want backwards compatibility with BU / DD / YD, therefore we should also offer it for the old CS. > It's not needed for current tagging needs, nor for > backward compatibility. So what is the correct replacement for rom-CS if you're very sure that the CS is the old CS ? Just rom ? I've no idea which other languages might be relevant in the old CS. Maybe hu-CS, what is this, hu-SK, or is hu-CZ also possible ? If both are possible somebody trying to fix it could need a 200 created by a better "split" rule. Or he needs an info to use hu-SK if hu-CS was the old CS. It's messy, minority languages in the old CS could be also minority languages in the new CS (rom, hu, yi, de, what else ?). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 15:57:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15989; Fri, 1 Apr 2005 15:57:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHTKY-0005Wk-H1; Fri, 01 Apr 2005 16:05:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHT2B-0002MS-HN; Fri, 01 Apr 2005 15:46:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHT2A-0002H3-Bb for ltru@megatron.ietf.org; Fri, 01 Apr 2005 15:46:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12205 for ; Fri, 1 Apr 2005 15:46:17 -0500 (EST) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHT9U-0003tJ-0f for ltru@ietf.org; Fri, 01 Apr 2005 15:54:00 -0500 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 12:45:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed changes to region subtags Date: Fri, 1 Apr 2005 12:45:58 -0800 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE75EE@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed changes to region subtags Thread-Index: AcU29orKgWpxOSbgQpCKkHGatTVogwAALvhg From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 01 Apr 2005 20:45:59.0445 (UTC) FILETIME=[CF6A0450:01C536FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Some comments below. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: vendredi 1 avril 2005 12:03 > To: ltru@ietf.org > Subject: [Ltru] Re: Proposed changes to region subtags >=20 > Doug Ewell wrote: >=20 > > Last Call for the registry draft is scheduled for May >=20 > I really don't care about timetables decreed by somebody > else, they are free to fix it when necessary. >=20 > > I think we need to figure out the rules now, rather > > than saving things for an unspecified "later." >=20 > Too many changes at once would be confusing. One draft > per month would be fine for me, let's see an April draft > soon, and then a draft registry based on whatever it says. [Addison Phillips]=20 Documents that are "somewhere in the middle" of a change are confusing. = We should make all of the necessary changes to the draft to make it = coherent, i.e. a plausible candidate for RFC-hood. This doesn't rule out = make more additions or emendations later. >=20 > Depending on our editors this could already specify the > record-jar or similar format, so that you have a chance > to create a proper first I-D in this format. [Addison Phillips]=20 (editor hat on) It doesn't because that debate seems to have fallen off without a = genuine consensus being reached. I *think* the consensus is record-jar. = And maybe also XML.=20 At present I intend that when I next sit down to update the editor's = copy (that usually being my job in our editing duopoly) I'll incorporate = the changes necessary to make record-jar the format with no mention of = XML. Any objections? (removing editor hat) > > Can you think of a use case for 200? >=20 > As an optional replacement for old cs-CS / sk-CS / rom-CS > tags. We want backwards compatibility with BU / DD / YD, > therefore we should also offer it for the old CS. [Addison Phillips]=20 More to the point: what is the rule for registry conversion to include = 200 and not some other codes? (more below) >=20 > > It's not needed for current tagging needs, nor for > > backward compatibility. >=20 > So what is the correct replacement for rom-CS if you're > very sure that the CS is the old CS ? Just rom ? I've > no idea which other languages might be relevant in the > old CS. Maybe hu-CS, what is this, hu-SK, or is hu-CZ > also possible ? [Addison Phillips]=20 Rule 0: tag content wisely. No matter what we pick as the meaning for 'CS', some existing content = could have its meaning invalidated and need to be "retagged". That = choice will be done in the here-and-now. For 'YU'/'CS', appropriate = choices exist in the registry which "mean the right thing", so I think = 200 may not be useful to codify after all. This keeps the rules for M49 numbers simple: 1. Create an M49-based registration for any number that 3166 doesn't = encode (with certain exceptions, i.e. the economic codes---sorry, no = "English as spoken in the 10 currently poorest countries"). 2. Create an M49-based registration for any 3166 code that collides with = an existing registry region entry. The additional rule you suggest would be, btw: 3. Create an M49-based registration for any 3166 code that was withdrawn = after Date A and subsequently assigned a new value before Date B (in = Cowan's terms). >=20 > If both are possible somebody trying to fix it could need > a 200 created by a better "split" rule. Or he needs an > info to use hu-SK if hu-CS was the old CS. It's messy, > minority languages in the old CS could be also minority > languages in the new CS (rom, hu, yi, de, what else ?). >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 17:46:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29134; Fri, 1 Apr 2005 17:46:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHV1L-0002jY-E1; Fri, 01 Apr 2005 17:53:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHUt6-0005o7-KR; Fri, 01 Apr 2005 17:45:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHUt4-0005kC-9m for ltru@megatron.ietf.org; Fri, 01 Apr 2005 17:45:10 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29079 for ; Fri, 1 Apr 2005 17:45:07 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DHUrV-0004ad-8s for ltru@lists.ietf.org; Sat, 02 Apr 2005 00:43:33 +0200 Received: from 212.82.251.41 ([212.82.251.41]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Apr 2005 00:43:33 +0200 Received: from nobody by 212.82.251.41 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Apr 2005 00:43:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 02 Apr 2005 00:36:35 +0200 Organization: Lines: 79 Message-ID: <424DCCF3.1F65@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0ADE75EE@irvmbxw01.quest.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.41 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > Documents that are "somewhere in the middle" of a change are > confusing. We should make all of the necessary changes to > the draft to make it coherent, i.e. a plausible candidate for > RFC-hood. Yes. And Doug's proposal was coherent, it defines 1988 as the first of the two "start dates" (the 2nd date is just the day of the publication of his future I-Ds). > This doesn't rule out make more additions or emendations > later. The current rules handle some splits. But we don't apply them in the past for the old CS, that's why the old CS 200 is lost. The current rules don't handle unions where the union inherits the CC of one of its former parts, that's why we lost the old DE and the old YE. In practice probably irrelevant for these two cases (for DE I'm almost sure). But there's no guarantee that it's always irrelevant. Today something like ru-RU and ru-BY is allowed (I don't check this, please adjust it if necessary). If BY + RU form a union with the new CC RU, and if the difference between ru-RU and ru-BY was important, then a tagger willing to update old ru-RU tags has a problem, the old region RU is lost. IMHO Doug is wrong, we can delay this one minor point to draft -02 without problem. And if the "last call" is in June instead of May then it won't be a side-effect of a simple "union" rule. > I *think* the consensus is record-jar. And maybe also XML. Me too, and for draft -01 the former is good enough. > More to the point: what is the rule for registry conversion > to include 200 and not some other codes? (more below) It's trapped between date A and B, a hopeless case. We could create an ad hoc exception (ugly), and explain why that's never again necessary (fine). If we fix the problem for all future splits and unions, where an alpha-2 CC changes its meaning as defined by the corresponding UN numbers (old vs. new). The current -00 rules preserve YU as code, but only the new meaning. Somebody trying to update old ??-YU tags would need the old UN number for unclear cases. > Rule 0: tag content wisely. Also known as "pray that 639-3 comes a.s.a.p., and all these funny region codes will be less important". > For 'YU'/'CS', appropriate choices exist in the registry > which "mean the right thing" If you can identify "the right thing". Otherwise all you know is that the old tag "inherited" a new meaning, and the 3066bis registry doesn't offer the UN number for the old meaning. > The additional rule you suggest would be, btw: > 3. Create an M49-based registration for any 3166 code that > was withdrawn after Date A and subsequently assigned a new > value before Date B (in Cowan's terms). No, I'd add the old UN number always as soon as new UN numbers are assigned, and an old region is lost without this trick. A case like the old CS cannot happen again under the current rules (the old CS would be frozen, the new CS gets a number). But a case like the old YU is always possible, e.g. if the US splits into a new smaller US + other parts. One or two unclear en-US pages would then need the old UN number. Otherwise they are automagically a (linguistical) part of the new smaller US. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 18:06:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00842; Fri, 1 Apr 2005 18:06:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHVLb-0003Qr-M1; Fri, 01 Apr 2005 18:14:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHVDC-0000pv-71; Fri, 01 Apr 2005 18:05:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHVDA-0000pq-FR for ltru@megatron.ietf.org; Fri, 01 Apr 2005 18:05:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00687 for ; Fri, 1 Apr 2005 18:05:53 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHVKZ-0003PS-2I for ltru@ietf.org; Fri, 01 Apr 2005 18:13:36 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j31N5fts029816; Fri, 1 Apr 2005 15:05:41 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Apr 2005 15:05:42 -0800 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , ltru@ietf.org Subject: RE: [Ltru] Re: Proposed changes to region subtags Date: Fri, 1 Apr 2005 15:05:41 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Addison Phillips wrote: >(editor hat on) > >It doesn't because that debate seems to have fallen off without a genuine >consensus being reached. I *think* the consensus is record-jar. And maybe >also XML. >At present I intend that when I next sit down to update the editor's copy >(that usually being my job in our editing duopoly) I'll incorporate the >changes necessary to make record-jar the format with no mention of XML. >Any objections? > >(removing editor hat) I agree that the working group concensus now is record-jar. I also agree that it's fine (better) not to mention any XML format in the next draft. When the metadata elements in this LT registry have crystallized further is soon enough to require or recommend any additional XML format. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 20:50:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12168; Fri, 1 Apr 2005 20:50:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHXtj-0000Ob-KW; Fri, 01 Apr 2005 20:58:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHXlz-0004yv-0T; Fri, 01 Apr 2005 20:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHXlx-0004yO-Hw for ltru@megatron.ietf.org; Fri, 01 Apr 2005 20:50:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12137 for ; Fri, 1 Apr 2005 20:49:57 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHXtM-0000Nu-Vu for ltru@ietf.org; Fri, 01 Apr 2005 20:57:42 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j321nmk0021239; Fri, 1 Apr 2005 20:49:49 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 1 Apr 2005 20:49:47 -0500 Date: Fri, 1 Apr 2005 20:49:47 -0500 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] Message-ID: <20050402014946.GA16332@skunk.reutershealth.com> References: <4A7C6FA2AB31194E80E13FE585F6A21292A1CE@EVS-EC1-NODE1.surrey.ac.uk> <6.1.2.0.2.20050331201305.042e0c60@mail.jefsey.com> <20050331201010.GA6550@skunk.reutershealth.com> <6.1.2.0.2.20050401103458.042e0140@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050401103458.042e0140@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 JFC (Jefsey) Morfin scripsit: > >Many dictionaries do not have this last item, particularly dictionaries of > >and in English, where the boundaries are extremely permeable. > > 1. Unfortunately. We like it that way. > However I suppose you will make a difference between > Basic American and English. But you have to consider the purpose: you > cannot consider a lingua franca as a reference. Eh? American English is somewhat more standardized in written form than British English is. > 2. I am sure that all the people who work on ontologies round the world > desserve better a comment by their standardisers. The genius of the English language is its immense flexibility. > 3. Standard are made by cute people to permit less interested people to > live better. Don't you agree? There is something which says that dumbness > of some only enlights smartness of others. I more or less understand your words, but your point escapes me entirely. -- We call nothing profound jcowan@reutershealth.com that is not wittily expressed. John Cowan --Northrop Frye (improved) http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 1 23:21:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24985; Fri, 1 Apr 2005 23:21:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHaFz-0007Wf-JL; Fri, 01 Apr 2005 23:29:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHa7V-00049h-8K; Fri, 01 Apr 2005 23:20:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHa7N-00047D-0d for ltru@megatron.ietf.org; Fri, 01 Apr 2005 23:20:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24740 for ; Fri, 1 Apr 2005 23:20:13 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHaEm-0007Ua-CQ for ltru@ietf.org; Fri, 01 Apr 2005 23:27:57 -0500 Received: from lns-p19-19-idf-82-254-247-171.adsl.proxad.net ([82.254.247.171] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DHa7I-0006ZF-3d; Fri, 01 Apr 2005 20:20:12 -0800 Message-Id: <6.1.2.0.2.20050402040415.03b58530@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 02 Apr 2005 06:20:09 +0200 To: John Cowan From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] is there some wiskey in the jar - [was: Registry in record-jar format] In-Reply-To: <20050402014946.GA16332@skunk.reutershealth.com> References: <4A7C6FA2AB31194E80E13FE585F6A21292A1CE@EVS-EC1-NODE1.surrey.ac.uk> <6.1.2.0.2.20050331201305.042e0c60@mail.jefsey.com> <20050331201010.GA6550@skunk.reutershealth.com> <6.1.2.0.2.20050401103458.042e0140@mail.jefsey.com> <20050402014946.GA16332@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f At 03:49 02/04/2005, John Cowan wrote: >JFC (Jefsey) Morfin scripsit: > > > >Many dictionaries do not have this last item, particularly dictionaries of > > >and in English, where the boundaries are extremely permeable. > > > > 1. Unfortunately. > >We like it that way. This is exactly what I say. Personal gustos have nothing to do in an international standard. > > However I suppose you will make a difference between > > Basic American and English. But you have to consider the purpose: you > > cannot consider a lingua franca as a reference. > >Eh? American English is somewhat more standardized in written form than >British English is. ??? Your whole point is that "in English boundaries are extremely permeable". You seem to contradict. > > 2. I am sure that all the people who work on ontologies round the world > > desserve better a comment by their standardisers. > >The genius of the English language is its immense flexibility. I suppose you lost the thread here. Your comment wiped off all the ontologies. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 01:02:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00896; Sat, 2 Apr 2005 01:02:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHbpr-0003cy-M1; Sat, 02 Apr 2005 01:10:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHbf6-0002Kr-HY; Sat, 02 Apr 2005 00:59:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHbf1-0002Km-Ha for ltru@megatron.ietf.org; Sat, 02 Apr 2005 00:59:07 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00631 for ; Sat, 2 Apr 2005 00:59:04 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050402055835.BKGE4618.mta13.adelphia.net@DEWELL> for ; Sat, 2 Apr 2005 00:58:35 -0500 Message-ID: <00b201c53748$ff604780$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org> Date: Fri, 1 Apr 2005 21:58:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Language transformation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit John Cowan wrote: >> On the other hand, if these are implemented as variant subtags, >> there is no need for a separate registry to provide further >> explanation or description of the variants. They are listed in the >> registry, with a recommended prefix, and that is that. > > This overstates the case. In order to make practical use of such > orthographies, they must be defined somewhere, and if the users of > trans*tions find it useful to have a registry of these things, then > LTRU has nothing to say about it. > > After all, if you want to know what "nn" codes for, the registry will > tell you "Nynorsk", but if you want to know what Nynorsk is, or how to > recognize it, or how to spell-check it, you must look elsewhere. At > the moment there is no single "elsewhere" to look: this may be > accounted good or bad. I don't disagree that it would be helpful to have a reference to what 'wadegile' or 'mccnrsch' means. I would think the registration forms might be a good place to start. What concerns me is the idea of a Transliteration Board that maintains its own registry of transliterations, and tells the Language Subtag Reviewer and ietf-languages which variant subtags to register, based on what they have already approved for their registry. If Tomas wants a separate organization to be responsible for vetting these, he should pursue the extension-RFC path, which does exactly that, but requires the use of a singleton such as -t-. If he wants to be able to write "zh-wadegile" without the -t-, then he is talking about variants, and those will be proposed and debated and approved (or rejected) using the same process that will apply to all other variants. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 01:32:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02992; Sat, 2 Apr 2005 01:32:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHcJH-00056c-50; Sat, 02 Apr 2005 01:40:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHc8Z-0006or-Df; Sat, 02 Apr 2005 01:29:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHc8W-0006om-Vz for ltru@megatron.ietf.org; Sat, 02 Apr 2005 01:29:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02846 for ; Sat, 2 Apr 2005 01:29:35 -0500 (EST) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHcG0-0004yO-5r for ltru@ietf.org; Sat, 02 Apr 2005 01:37:20 -0500 Received: from h-64-105-35-87.snvacaid.dynamic.covad.net ([64.105.35.87] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DHc8U-00063x-00 for ltru@ietf.org; Fri, 01 Apr 2005 22:29:34 -0800 Message-ID: <002901c5374d$7f2b97e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <4A7C6FA2AB31194E80E13FE585F6A21292A1CE@EVS-EC1-NODE1.surrey.ac.uk><6.1.2.0.2.20050331201305.042e0c60@mail.jefsey.com><20050331201010.GA6550@skunk.reutershealth.com><6.1.2.0.2.20050401103458.042e0140@mail.jefsey.com><20050402014946.GA16332@skunk.reutershealth.com> <6.1.2.0.2.20050402040415.03b58530@mail.jefsey.com> Subject: Re: [Ltru] is there some wiskey in the jar - [was: Registry inrecord-jar format] Date: Fri, 1 Apr 2005 22:30:43 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi - > From: "JFC (Jefsey) Morfin" > To: "John Cowan" > Cc: > Sent: Friday, April 01, 2005 8:20 PM > Subject: Re: [Ltru] is there some wiskey in the jar - [was: Registry inrecord-jar format] > > At 03:49 02/04/2005, John Cowan wrote: > >JFC (Jefsey) Morfin scripsit: > > > > > >Many dictionaries do not have this last item, particularly dictionaries of > > > >and in English, where the boundaries are extremely permeable. > > > > > > 1. Unfortunately. > > > >We like it that way. > > This is exactly what I say. Personal gustos have nothing to do in an > international standard. Please identify the specific text you want changed. (I assume you meant something like "Personal taste should not be reflected in international standards." (I've never observed this to be true in practice.)) > > > However I suppose you will make a difference between > > > Basic American and English. But you have to consider the purpose: you > > > cannot consider a lingua franca as a reference. > > > >Eh? American English is somewhat more standardized in written form than > >British English is. > > ??? Your whole point is that "in English boundaries are extremely > permeable". You seem to contradict. I see no contradiction. The permeability of the boundaries in question is completely independent of the extent to which spelling has been standardized. > > > 2. I am sure that all the people who work on ontologies round the world > > > desserve better a comment by their standardisers. > > > >The genius of the English language is its immense flexibility. > > I suppose you lost the thread here. Your comment wiped off all the ontologies. ... Everyone: if you want your postings to be taken seriously, please identify the specific changes needed to address your concerns. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 02:18:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24149; Sat, 2 Apr 2005 02:18:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHd1C-0007Ze-8G; Sat, 02 Apr 2005 02:26:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHcpl-0005lR-2y; Sat, 02 Apr 2005 02:14:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHcpS-0005jV-2Y for ltru@megatron.ietf.org; Sat, 02 Apr 2005 02:13:58 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18941 for ; Sat, 2 Apr 2005 02:13:55 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050402071311.GSFL7277.mta10.adelphia.net@DEWELL> for ; Sat, 2 Apr 2005 02:13:11 -0500 Message-ID: <00bf01c53753$6c312320$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org> Date: Fri, 1 Apr 2005 23:13:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> Last Call for the registry draft is scheduled for May > > I really don't care about timetables decreed by somebody > else, they are free to fix it when necessary. We're trying to hammer out the details of a stable mechanism. May vs. June might not make that much difference, but we can't drag this out indefinitely. >> Can you think of a use case for 200? > > As an optional replacement for old cs-CS / sk-CS / rom-CS > tags. We want backwards compatibility with BU / DD / YD, > therefore we should also offer it for the old CS. That's not the type of backward compatibility that BU and DD and YD provide. They are there precisely so that existing content with those tags *does not* have to be retagged with MM or DE or YE. > So what is the correct replacement for rom-CS if you're > very sure that the CS is the old CS ? Just rom ? I've > no idea which other languages might be relevant in the > old CS. Maybe hu-CS, what is this, hu-SK, or is hu-CZ > also possible ? > > If both are possible somebody trying to fix it could need > a 200 created by a better "split" rule. Or he needs an > info to use hu-SK if hu-CS was the old CS. It's messy, > minority languages in the old CS could be also minority > languages in the new CS (rom, hu, yi, de, what else ?). I won't fight hard on this 200 issue, but we need to come to some sort of agreement that not every problem related to the splitting and merging and shifting of countries is going to be solved within language tags. Originally you didn't even want pre-1995 region subtags to be allowed; now the correct "replacement" for old CS (withdrawn in 1993) is important? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 02:26:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00675; Sat, 2 Apr 2005 02:26:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHd90-00086t-Qz; Sat, 02 Apr 2005 02:34:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHcyr-0007Nq-NL; Sat, 02 Apr 2005 02:23:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHcyq-0007Nh-09 for ltru@megatron.ietf.org; Sat, 02 Apr 2005 02:23:40 -0500 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29490 for ; Sat, 2 Apr 2005 02:23:38 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050402072308.COKO4618.mta13.adelphia.net@DEWELL> for ; Sat, 2 Apr 2005 02:23:08 -0500 Message-ID: <00c401c53754$cdfe41e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org> Date: Fri, 1 Apr 2005 23:23:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Addison Phillips wrote: >> Depending on our editors this could already specify the >> record-jar or similar format, so that you have a chance >> to create a proper first I-D in this format. > > It doesn't because that debate seems to have fallen off without a > genuine consensus being reached. I *think* the consensus is record- > jar. And maybe also XML. I remember some pretty firm objections to XML. > At present I intend that when I next sit down to update the editor's > copy (that usually being my job in our editing duopoly) I'll > incorporate the changes necessary to make record-jar the format with > no mention of XML. Any objections? No objection at all. I'm ready with record-jar any time you folks are. I would appreciate some guidance on the exact flavor of record-jar that people want. There are a few choices to be made: - max line length (80, 72, etc.) - character(s) used for comments ("%%" versus "#") - line breaking convention (backslash-newline, newline-space, etc.) > The additional rule you suggest would be, btw: > > 3. Create an M49-based registration for any 3166 code that was > withdrawn after Date A and subsequently assigned a new value before > Date B (in Cowan's terms). I'm glad to see this (and the other two rules) expressed as general rules, not special exceptions. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 02:45:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02101; Sat, 2 Apr 2005 02:45:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHdR3-0000h1-7b; Sat, 02 Apr 2005 02:52:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHdJE-0004N1-GF; Sat, 02 Apr 2005 02:44:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHdIs-0004LN-KO for ltru@megatron.ietf.org; Sat, 02 Apr 2005 02:44:22 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02079 for ; Sat, 2 Apr 2005 02:44:20 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050402074351.DXDG2192.mta9.adelphia.net@DEWELL> for ; Sat, 2 Apr 2005 02:43:51 -0500 Message-ID: <00cc01c53757$b172cb60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 1 Apr 2005 23:43:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > But there's no guarantee that it's always irrelevant. Today > something like ru-RU and ru-BY is allowed (I don't check this, > please adjust it if necessary). If BY + RU form a union with > the new CC RU, and if the difference between ru-RU and ru-BY > was important, then a tagger willing to update old ru-RU tags > has a problem, the old region RU is lost. Didn't you say, just a few weeks ago, that it would be terrible for us to keep BQ and AQ and NQ in the registry because if those codes were reassigned in ISO 3166, the new recipients would be stuck with those awful UN numeric codes for language tags? Isn't the merger of country X into country Y, keeping the existing country code for Y, a much greater likelihood? Your suggestion replaces the alpha-2 code for both of these former countries with a numeric code for the union. > IMHO Doug is wrong, we can delay this one minor point to draft > -02 without problem. And if the "last call" is in June instead > of May then it won't be a side-effect of a simple "union" rule. It's not June I worry about. I don't see this issue coming to an end. Perhaps naively, I thought it would be resolved when we reached something resembling consensus on the 1988 cutoff date. > The current -00 rules preserve YU as code, but only the new > meaning. Somebody trying to update old ??-YU tags would need > the old UN number for unclear cases. Existing tags should not have to be "updated" like this. That is not what backward compatibility is all about. If we were big believers in going back through old content and updating all the tags, we probably wouldn't be here in the first place, trying to add more stability to RFC 3066. >> Rule 0: tag content wisely. > > Also known as "pray that 639-3 comes a.s.a.p., and all these > funny region codes will be less important". 639-3 will not distinguish between en-US and en-GB and en-AU, nor between fr-FR and fr-CA, nor between other region varieties that people feel a need to distinguish. I could have sworn I said this. > No, I'd add the old UN number always as soon as new UN numbers > are assigned, and an old region is lost without this trick. A > case like the old CS cannot happen again under the current > rules (the old CS would be frozen, the new CS gets a number). I will continue to oppose this. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 03:38:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05428; Sat, 2 Apr 2005 03:38:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHeGb-0003W4-3u; Sat, 02 Apr 2005 03:46:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHe6j-0002Va-Qg; Sat, 02 Apr 2005 03:35:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHe6H-0002SJ-KV for ltru@megatron.ietf.org; Sat, 02 Apr 2005 03:35:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05195 for ; Sat, 2 Apr 2005 03:35:23 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHeDl-0003P3-Ew for ltru@ietf.org; Sat, 02 Apr 2005 03:43:10 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j328Z8T9022754; Sat, 2 Apr 2005 03:35:08 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 2 Apr 2005 03:35:13 -0500 Date: Sat, 2 Apr 2005 03:35:13 -0500 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: Proposed changes to region subtags Message-ID: <20050402083512.GD19110@skunk.reutershealth.com> References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org> <00c401c53754$cdfe41e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c401c53754$cdfe41e0$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Doug Ewell scripsit: > - max line length (80, 72, etc.) No opinion on this one. > - character(s) used for comments ("%%" versus "#") In record-jar the %% is a separator, and anything following that on the same line is not part of the data structure. So IMHO comments should be handled as a separate "comment:" field. > - line breaking convention (backslash-newline, newline-space, etc.) Record-jar is based on RFC (2)822, so newline-space(s) is the convention. -- John Cowan jcowan@reutershealth.com http://www.reutershealth.com 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 05:00:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09911; Sat, 2 Apr 2005 05:00:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHfYK-000805-10; Sat, 02 Apr 2005 05:08:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHfQ0-0000Gy-Nn; Sat, 02 Apr 2005 04:59:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHfPy-0000Gk-Mp for ltru@megatron.ietf.org; Sat, 02 Apr 2005 04:59:50 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09836 for ; Sat, 2 Apr 2005 04:59:47 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050402095918.EENB5402.mta11.adelphia.net@DEWELL>; Sat, 2 Apr 2005 04:59:18 -0500 Message-ID: <00db01c5376a$97d97880$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org> <00c401c53754$cdfe41e0$030aa8c0@DEWELL> <20050402083512.GD19110@skunk.reutershealth.com> Subject: Re: [Ltru] Re: Proposed changes to region subtags Date: Sat, 2 Apr 2005 01:58:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit John Cowan wrote: >> - character(s) used for comments ("%%" versus "#") > > In record-jar the %% is a separator, and anything following that on > the same line is not part of the data structure. So IMHO comments > should be handled as a separate "comment:" field. There are actually two types of comments. There are the headers, like this: # IANA Language Subtag Registry # This registry lists all valid subtags for language tags # created under RFC 3066bis. and then there are the comments that belong to a single record, and go at the end like this: # deprecated 1989 For the latter, I agree that these should be a true field. For the former, I've kept them more or less as they were in the bar-delimited file, introduced by a "#" in column 1. But the documentation for the "Open-RJ" library says comments should begin with "%%", so I couldn't be sure. >> - line breaking convention (backslash-newline, newline-space, etc.) > > Record-jar is based on RFC (2)822, so newline-space(s) is the > convention. Again, I trusted the Open-RJ page and went with backslash-newline. I'll change this. OK, so right now I have something like this: # IANA Language Subtag Registry # etc. etc. Type: date Date: 2005-03-30 # language codes: ISO 639 and registered codes # ISO 639-1 (alpha-2) codes Type: language Subtag: aa Description: Afar Date: 2004-07-06 %% Type: language Subtag: ab Description: Abkhazian Date: 2004-07-06 %% etc. etc. If the group agrees on this format, or have concrete suggestions for improvement, then that's what I'll post Wednesday or thereabouts. I'm also waiting to see what the consensus is on 200. So far, one person would like to see it back. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 08:31:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21886; Sat, 2 Apr 2005 08:31:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHiq3-0000dH-CF; Sat, 02 Apr 2005 08:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHiiG-0006p0-74; Sat, 02 Apr 2005 08:30:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHiiE-0006ov-GR for ltru@megatron.ietf.org; Sat, 02 Apr 2005 08:30:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21862 for ; Sat, 2 Apr 2005 08:30:52 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHipk-0000cg-IR for ltru@ietf.org; Sat, 02 Apr 2005 08:38:41 -0500 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j32DUZbO004614; Sat, 2 Apr 2005 05:30:35 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 2 Apr 2005 05:30:35 -0800 Message-ID: From: "McDonald, Ira" To: "'John Cowan'" , Doug Ewell Subject: RE: [Ltru] Re: Proposed changes to region subtags Date: Sat, 2 Apr 2005 05:30:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f John Cowan replied to Doug Ewell: >> - max line length (80, 72, etc.) > >No opinion on this one. > >> - character(s) used for comments ("%%" versus "#") > >In record-jar the %% is a separator, and anything following that on the >same line is not part of the data structure. So IMHO comments should >be handled as a separate "comment:" field. > >> - line breaking convention (backslash-newline, newline-space, etc.) > >Record-jar is based on RFC (2)822, so newline-space(s) is the convention. I agree with John's comments above on comments and line breaking. Please make max line length 72 - otherwise it can't be published in an RFC with margins (which the RFC editor now requires). Also, the record-jar can then be reviewed in plaintext with prefix or suffix line numbers and still be within 80 characters. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 09:24:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24766; Sat, 2 Apr 2005 09:24:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHjfR-0002pw-9N; Sat, 02 Apr 2005 09:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHjXD-0007kN-Qa; Sat, 02 Apr 2005 09:23:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHjXC-0007kI-D8 for ltru@megatron.ietf.org; Sat, 02 Apr 2005 09:23:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24722 for ; Sat, 2 Apr 2005 09:23:32 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHjej-0002pR-79 for ltru@ietf.org; Sat, 02 Apr 2005 09:31:22 -0500 Received: from lns-p19-1-idf-82-251-95-81.adsl.proxad.net ([82.251.95.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DHjX1-0003Rd-FM; Sat, 02 Apr 2005 06:23:24 -0800 Message-Id: <6.1.2.0.2.20050402114743.03713610@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 02 Apr 2005 16:23:12 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Proposed changes to region subtags In-Reply-To: <00c401c53754$cdfe41e0$030aa8c0@DEWELL> References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org> <00c401c53754$cdfe41e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 At 09:23 02/04/2005, Doug Ewell wrote: >Addison Phillips wrote: >No objection at all. I'm ready with record-jar any time you folks are. >I would appreciate some guidance on the exact flavor of record-jar that >people want. There are a few choices to be made: I need to translate this to our system management language through a simple C program. >- max line length (80, 72, etc.) No special requirement. >- character(s) used for comments ("%%" versus "#") "%%" could help to transliterate it to "//" while "#" may happen to be used elsewhere. >- line breaking convention (backslash-newline, newline-space, etc.) No special need. > > The additional rule you suggest would be, btw: > > > > 3. Create an M49-based registration for any 3166 code that was > > withdrawn after Date A and subsequently assigned a new value before > > Date B (in Cowan's terms). > >I'm glad to see this (and the other two rules) expressed as general >rules, not special exceptions. Our intent is to add the expiration date of a code to the concerned code element. If you have the information very good. We currently miss the 3166-2 revisions. But it is likely that 3166-2 will not be muched used in APMD draft context. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 12:20:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06462; Sat, 2 Apr 2005 12:20:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHmPk-0001pf-0K; Sat, 02 Apr 2005 12:28:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHmHB-00019W-Nk; Sat, 02 Apr 2005 12:19:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHmH9-00018j-19 for ltru@megatron.ietf.org; Sat, 02 Apr 2005 12:19:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06284 for ; Sat, 2 Apr 2005 12:19:04 -0500 (EST) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHmOc-0001bH-Dr for ltru@ietf.org; Sat, 02 Apr 2005 12:26:57 -0500 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j32HIoLg564764 for ; Sat, 2 Apr 2005 12:18:50 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j32HIoZQ177398 for ; Sat, 2 Apr 2005 10:18:50 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j32HIoMs006862 for ; Sat, 2 Apr 2005 10:18:50 -0700 Received: from markdavis (sig-9-48-118-206.mts.ibm.com [9.48.118.206]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j32HIm5v006840; Sat, 2 Apr 2005 10:18:49 -0700 Message-ID: <103801c537a8$08284f20$857e3009@sanjose.ibm.com> From: "Mark Davis" To: , "Frank Ellermann" References: <20050330165046.TVVC4900.mta8.adelphia.net@megatron.ietf.org><004b01c53609$b5d0e920$030aa8c0@DEWELL> <424DA8F5.37A1@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Proposed changes to region subtags Date: Sat, 2 Apr 2005 09:18:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j32HIoLg564764 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable > I really don't care about timetables decreed by somebody > else, they are free to fix it when necessary. > > > I think we need to figure out the rules now, rather > > than saving things for an unspecified "later." Most of us have practical requirements that require this to be done in a timely manner. And this effort has been going on for a long time. While y= ou many see no urgency to this, I suggest that you remember that there are s= ome people for whom this is no academic exercise. =E2=80=8EMark ----- Original Message -----=20 From: "Frank Ellermann" To: Sent: Friday, April 01, 2005 12:03 Subject: [Ltru] Re: Proposed changes to region subtags > Doug Ewell wrote: > > > Last Call for the registry draft is scheduled for May > > I really don't care about timetables decreed by somebody > else, they are free to fix it when necessary. > > > I think we need to figure out the rules now, rather > > than saving things for an unspecified "later." > > Too many changes at once would be confusing. One draft > per month would be fine for me, let's see an April draft > soon, and then a draft registry based on whatever it says. > > Depending on our editors this could already specify the > record-jar or similar format, so that you have a chance > to create a proper first I-D in this format. > > > Can you think of a use case for 200? > > As an optional replacement for old cs-CS / sk-CS / rom-CS > tags. We want backwards compatibility with BU / DD / YD, > therefore we should also offer it for the old CS. > > > It's not needed for current tagging needs, nor for > > backward compatibility. > > So what is the correct replacement for rom-CS if you're > very sure that the CS is the old CS ? Just rom ? I've > no idea which other languages might be relevant in the > old CS. Maybe hu-CS, what is this, hu-SK, or is hu-CZ > also possible ? > > If both are possible somebody trying to fix it could need > a 200 created by a better "split" rule. Or he needs an > info to use hu-SK if hu-CS was the old CS. It's messy, > minority languages in the old CS could be also minority > languages in the new CS (rom, hu, yi, de, what else ?). > > Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 14:46:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15047; Sat, 2 Apr 2005 14:46:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHoh8-0007an-HE; Sat, 02 Apr 2005 14:54:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHoZK-0004u9-FU; Sat, 02 Apr 2005 14:46:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHoZJ-0004sT-Sz for ltru@megatron.ietf.org; Sat, 02 Apr 2005 14:46:06 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15036 for ; Sat, 2 Apr 2005 14:46:02 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DHoXb-00023L-SX for ltru@lists.ietf.org; Sat, 02 Apr 2005 21:44:20 +0200 Received: from 212.82.251.101 ([212.82.251.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Apr 2005 21:44:19 +0200 Received: from nobody by 212.82.251.101 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Apr 2005 21:44:19 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 02 Apr 2005 21:43:35 +0200 Organization: Lines: 45 Message-ID: <424EF5E7.7DF1@xyzzy.claranet.de> References: <00cc01c53757$b172cb60$030aa8c0@DEWELL> 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.101 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Doug Ewell wrote: > Didn't you say, just a few weeks ago, [...] Yes, that was me, and you've alreay solved this problem for the very old alpha-2 codes (before 1988). > Isn't the merger of country X into country Y, keeping the > existing country code for Y, a much greater likelihood? Exactly. > Your suggestion replaces the alpha-2 code for both of these > former countries with a numeric code for the union. No, I want the UN number for the "lost region" in the registry. Not the UN number for the union, if they inherit the alpha-2 code. The "lost region number" allows (option) to update old tags, and it documents the change of the meaning for the alpha-2 code. > It's not June I worry about. I don't see this issue coming > to an end. Now it's not that important, our chairs can always decree that the rules are good enough as they are for RfC 3066bis. When a fix is needed in the future, because there will be problems with unions and splits, somebody else could create a 3066ter. If we're lucky these potential problems won't show up for a very long time. Any issues with 7000+ laguages in ISO 639-3 are much more interesting than this alpha-2 CC "inheritance". > Existing tags should not have to be "updated" like this. > That is not what backward compatibility is all about. I proposed a way to get rid of all "inheritace oddities" with alpha-2 CCs, nobody here liked it. It's really not my fault when new regions "inherit" the CC of an old region, it's one of the ideas for these country codes (e.g. DE, VN, YE, YU). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 15:46:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24733; Sat, 2 Apr 2005 15:46:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHpd7-00036t-S6; Sat, 02 Apr 2005 15:54:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHpVG-0004YJ-AJ; Sat, 02 Apr 2005 15:45:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHpVF-0004YE-86 for ltru@megatron.ietf.org; Sat, 02 Apr 2005 15:45:57 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24717 for ; Sat, 2 Apr 2005 15:45:54 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DHpSv-0008Sc-2h for ltru@lists.ietf.org; Sat, 02 Apr 2005 22:43:33 +0200 Received: from 212.82.251.101 ([212.82.251.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Apr 2005 22:43:33 +0200 Received: from nobody by 212.82.251.101 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Apr 2005 22:43:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 02 Apr 2005 22:43:23 +0200 Organization: Lines: 31 Message-ID: <424F03EB.C30@xyzzy.claranet.de> References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org> <00c401c53754$cdfe41e0$030aa8c0@DEWELL> 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.101 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Doug Ewell wrote: > I remember some pretty firm objections to XML. And one reason pro XML (clear support for Unicode character references in an otherwise US-ASCII text). JFTR, I prefer record-jar in the body of the I-D registry. > - max line length (80, 72, etc.) It's not "unlimited", therefore you can pick any reasonable limit. For an I-D 72 is perfect. > - character(s) used for comments ("%%" versus "#") %% is the terminator for an entry. As far as I'm concerned an empty line is also okay. The %% idea is for formats, where the begin of the next entry isn't obvious. and where empty lines could be lost, that's not the case for the I-D registry. Comments introduced by # are fine. If you stick to %%, then maybe % is better than # (?) > - line breaking convention (backslash-newline, newline-space, > etc.) CrLfSp / CrLfSpSp / ... as in folded mail / news header fields. CrLf plus one or more spaces (maybe more are better readable ?) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 15:51:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25330; Sat, 2 Apr 2005 15:51:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHphu-0003MV-OB; Sat, 02 Apr 2005 15:59:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHpZb-0005DU-LM; Sat, 02 Apr 2005 15:50:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHpZa-0005DP-KC for ltru@megatron.ietf.org; Sat, 02 Apr 2005 15:50:26 -0500 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25290 for ; Sat, 2 Apr 2005 15:50:24 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050402204950.UIX7277.mta10.adelphia.net@DEWELL> for ; Sat, 2 Apr 2005 15:49:50 -0500 Message-ID: <010e01c537c5$7ca68520$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: Proposed changes to region subtags Date: Sat, 2 Apr 2005 12:49:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit McDonald, Ira wrote: > I agree with John's comments above on comments and line breaking. I have to admit, I'm surprised that newline-space (with no backslash) is preferred. I would think that would make parsing more difficult, since you have to look one line ahead to see if you have line continuation. > Please make max line length 72 - otherwise it can't be published > in an RFC with margins (which the RFC editor now requires). Also, > the record-jar can then be reviewed in plaintext with prefix or > suffix line numbers and still be within 80 characters. Will do. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 16:03:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26308; Sat, 2 Apr 2005 16:03:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHptm-0004Oc-In; Sat, 02 Apr 2005 16:11:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHplA-0006rA-0P; Sat, 02 Apr 2005 16:02:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHpl8-0006r5-GE for ltru@megatron.ietf.org; Sat, 02 Apr 2005 16:02:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26232 for ; Sat, 2 Apr 2005 16:02:19 -0500 (EST) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHpsi-0004ND-8l for ltru@ietf.org; Sat, 02 Apr 2005 16:10:13 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j32L2A4I584242 for ; Sat, 2 Apr 2005 16:02:11 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j32L2Aeh200136 for ; Sat, 2 Apr 2005 14:02:10 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j32L2AEm011310 for ; Sat, 2 Apr 2005 14:02:10 -0700 Received: from markdavis (sig-9-48-118-206.mts.ibm.com [9.48.118.206]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j32L29ur011280; Sat, 2 Apr 2005 14:02:09 -0700 Message-ID: <10e401c537c7$3bbd52d0$857e3009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <006201c52f73$bba93420$030aa8c0@DEWELL> Subject: Re: [Ltru] Registry in record-jar format Date: Sat, 2 Apr 2005 13:02:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j32L2A4I584242 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable The deprecated info might as well be a real field instead of just a comme= nt: Type: language Subtag: in Description: Indonesian Date: 2004-07-06 Canonical_Value: id # deprecated 1989 =3D> Type: language Subtag: in Description: Indonesian Date: 2004-07-06 Canonical_Value: id Deprecated: 1989 Same for the name change: Type: region Subtag: NH Description: Vanuatu Date: 2004-07-06 Canonical_Value: VU # changed 1980, formerly New Hebrides=3D> Type: region Subtag: NH Description: Vanuatu Date: 2004-07-06 Canonical_Value: VU Name_Changed: 1980Former_Value: New HebridesThe comments for redundant ca= n be dropped, they don't add information: Type: redundant Subtag: az-Cyrl Description: Azerbaijani in Cyrillic script Date: 2003-05-30 # use language az + script Cyrl =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Tuesday, March 22, 2005 22:44 Subject: [Ltru] Registry in record-jar format > At least one person expressed some interest in seeing the draft / > proposed / sample registry in record-jar format, so here it is: > > http://users.adelphia.net/~dewell/lstreg-rj.txt > > This has no official sanction or consensus; it's just there so people > can visualize it (which I guess is true for the other one as well). > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 16:07:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26571; Sat, 2 Apr 2005 16:07:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHpxR-0004aW-6Z; Sat, 02 Apr 2005 16:15:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHpox-0007Qt-3h; Sat, 02 Apr 2005 16:06:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHpow-0007Qo-CU for ltru@megatron.ietf.org; Sat, 02 Apr 2005 16:06:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26493 for ; Sat, 2 Apr 2005 16:06:15 -0500 (EST) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHpwW-0004Yq-Ta for ltru@ietf.org; Sat, 02 Apr 2005 16:14:10 -0500 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050402210603.YTIJ2192.mta9.adelphia.net@DEWELL> for ; Sat, 2 Apr 2005 16:06:03 -0500 Message-ID: <011101c537c7$be722b60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org> <00c401c53754$cdfe41e0$030aa8c0@DEWELL> <6.1.2.0.2.20050402114743.03713610@mail.jefsey.com> Subject: Re: [Ltru] Re: Proposed changes to region subtags Date: Sat, 2 Apr 2005 13:05:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > I need to translate this to our system management language through a > simple C program. > ... >>- character(s) used for comments ("%%" versus "#") > > "%%" could help to transliterate it to "//" while "#" may happen to be > used elsewhere. If you're converting this to another format, you may have to do special processing on "%%" anyway. Question for the group: Do I need "%%" at the beginning and end of *all* records? Right now I omit it if the otherwise-adjacent records are separated by at least one comment, as shown in my previous examples. (Or perhaps that's a reason to use "%%" for comments instead of "#".) > Our intent is to add the expiration date of a code to the concerned > code element. If you have the information very good. Code elements don't have an expiration date. They're good forever, or until the MA withdraws or deprecates them. Subtags are good forever, or until the language tagging mechanism is totally replaced. > We currently miss the 3166-2 revisions. But it is likely that 3166-2 > will not be muched used in APMD draft context. ISO 3166-2 code elements (for country subdivisions) are one to three characters long, and wouldn't fit within the proposed language tag syntax. I don't know what you mean by "APMD." A quick Web search led me to information on power management for laptops, which I'm sure is not what you meant. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 16:25:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27594; Sat, 2 Apr 2005 16:25:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHqF2-0005Th-NW; Sat, 02 Apr 2005 16:33:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHq6w-0001J8-Lg; Sat, 02 Apr 2005 16:24:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHq6v-0001J3-20 for ltru@megatron.ietf.org; Sat, 02 Apr 2005 16:24:53 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27590 for ; Sat, 2 Apr 2005 16:24:49 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DHq5C-000404-4P for ltru@lists.ietf.org; Sat, 02 Apr 2005 23:23:06 +0200 Received: from 212.82.251.101 ([212.82.251.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Apr 2005 23:23:06 +0200 Received: from nobody by 212.82.251.101 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Apr 2005 23:23:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 02 Apr 2005 23:17:13 +0200 Organization: Lines: 43 Message-ID: <424F0BD9.7960@xyzzy.claranet.de> References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org> <00bf01c53753$6c312320$030aa8c0@DEWELL> 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.101 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Doug Ewell wrote: [200] > That's not the type of backward compatibility that BU and DD > and YD provide. They are there precisely so that existing > content with those tags *does not* have to be retagged with > MM or DE or YE. Point. Let's forget 200, it's a hopeless case, and the rules in 3066bis enforce that it can never happen again. > we need to come to some sort of agreement that not every > problem related to the splitting and merging and shifting of > countries is going to be solved within language tags. Mark claims that this is only an "academic exercise". Maybe he thinks that CS, DE, VN, YE, and YU were all academic exercises. So far we discussed three solutions: 1 - Fix it for past problems (before 1988), ignore 200, DE, YE, and YU. That's now ready, and 200 can't happen again. 2 - Add UN numbers for regions when they are otherwise "lost". You don't like it, because it only works by updating old tags. I also don't like it, but it's the only emergency exit in this "academic exercise" (about twice per decade) with something like the draft -00 rules. 3 - Use UN numbers for stable entries, otherwise allow and accept that all alpha-2 codes are instable by design. I don't see a fourth solution, Sooner or later "1" loses some regions, that's an observation for the simple rules in draft -00 and before, demonstrated by YE and YU. Now if you and Mark would say that you understand the problem and ignore it intentionally, then we can go with solution "1". Is the problem clear ? Or should I elaborate the BY + RU => RU and US => US + XX "academic exercises" ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 19:13:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06176; Sat, 2 Apr 2005 19:13:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHsrj-0006Kh-4p; Sat, 02 Apr 2005 19:21:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHsjm-0007By-JT; Sat, 02 Apr 2005 19:13:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHsjl-0007Bq-Ft for ltru@megatron.ietf.org; Sat, 02 Apr 2005 19:13:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06154 for ; Sat, 2 Apr 2005 19:13:05 -0500 (EST) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHsrN-0006IA-75 for ltru@ietf.org; Sat, 02 Apr 2005 19:21:02 -0500 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j330ClOc026393; Sat, 2 Apr 2005 19:12:47 -0500 (EST) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 2 Apr 2005 19:12:48 -0500 Date: Sat, 2 Apr 2005 19:12:48 -0500 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: Proposed changes to region subtags Message-ID: <20050403001210.GG19110@skunk.reutershealth.com> References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org> <00c401c53754$cdfe41e0$030aa8c0@DEWELL> <6.1.2.0.2.20050402114743.03713610@mail.jefsey.com> <011101c537c7$be722b60$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011101c537c7$be722b60$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Doug Ewell scripsit: > Question for the group: Do I need "%%" at the beginning and end of > *all* records? Right now I omit it if the otherwise-adjacent records > are separated by at least one comment, as shown in my previous examples. > (Or perhaps that's a reason to use "%%" for comments instead of "#".) You need it between each record. You do not need it at the beginning or the end, but it doesn't hurt. You should not omit it in any circumstance. To recap the history, record-jar format descends from cookie-jar format (not Web cookies, but fortune cookies), which is just chunks of unformatted text separated by "%%" lines. Record-jar just adds to that the idea that each chunk is made up of RFC (2)822 headers. -- John Cowan www.ccil.org/~cowan jcowan@reutershealth.com www.reutershealth.com Monday we watch-a Firefly's house, but he no come out. He wasn't home. Tuesday we go to the ball game, but he fool us. He no show up. Wednesday he go to the ball game, and we fool him. We no show up. Thursday was a double-header. Nobody show up. Friday it rained all day. There was no ball game, so we stayed home and we listened to it on-a the radio. --Chicolini _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 19:56:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07928; Sat, 2 Apr 2005 19:56:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHtXL-0000OU-9D; Sat, 02 Apr 2005 20:04:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHtOd-00053O-KE; Sat, 02 Apr 2005 19:55:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHtOc-00053E-2E for ltru@megatron.ietf.org; Sat, 02 Apr 2005 19:55:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07908 for ; Sat, 2 Apr 2005 19:55:18 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHtWF-00007f-Jh for ltru@ietf.org; Sat, 02 Apr 2005 20:03:15 -0500 Received: from lns-p19-1-idf-82-251-95-81.adsl.proxad.net ([82.251.95.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DHtOa-00052B-D9; Sat, 02 Apr 2005 16:55:20 -0800 Message-Id: <6.1.2.0.2.20050403010904.03bf9600@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 03 Apr 2005 01:39:52 +0200 To: Frank Ellermann , ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Proposed changes to region subtags In-Reply-To: <424F0BD9.7960@xyzzy.claranet.de> References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org> <00bf01c53753$6c312320$030aa8c0@DEWELL> <424F0BD9.7960@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 I do not understand all this endless academic debate. ICANN (IANA) is a member of the ISO 3166 MA group. I suggest you try to locate who is the IANA person in charge and ask him what is the fix the IANA supports. Then you publish an RFC on the issue to help him/her go and impose to ISO. As Randy says standards reflect personal references: make sure your personal reference becomes the rule. Let be realistic: this WG will probably not rule the world, and will not prevent changes (and their resulting many possible mistakes). Any rigid system will not scale. And will not adapt in continuity with past situations (prior 1988 or 1974). The only rule you can apply is "parameter in context" what means you must know the date of the system a document refers to. In real life, ISO 3166-2 will be used. You cannot imagine that en-US is descriptive enough when en-PT can offer an accuracy down to a group of 56 people. jfc At 23:17 02/04/2005, Frank Ellermann wrote: >Doug Ewell wrote: > > [200] > > That's not the type of backward compatibility that BU and DD > > and YD provide. They are there precisely so that existing > > content with those tags *does not* have to be retagged with > > MM or DE or YE. > >Point. Let's forget 200, it's a hopeless case, and the rules >in 3066bis enforce that it can never happen again. > > > we need to come to some sort of agreement that not every > > problem related to the splitting and merging and shifting of > > countries is going to be solved within language tags. > >Mark claims that this is only an "academic exercise". Maybe he >thinks that CS, DE, VN, YE, and YU were all academic exercises. >So far we discussed three solutions: > >1 - Fix it for past problems (before 1988), ignore 200, DE, YE, > and YU. That's now ready, and 200 can't happen again. > >2 - Add UN numbers for regions when they are otherwise "lost". > You don't like it, because it only works by updating old > tags. I also don't like it, but it's the only emergency > exit in this "academic exercise" (about twice per decade) > with something like the draft -00 rules. > >3 - Use UN numbers for stable entries, otherwise allow and > accept that all alpha-2 codes are instable by design. > >I don't see a fourth solution, Sooner or later "1" loses some >regions, that's an observation for the simple rules in draft >-00 and before, demonstrated by YE and YU. > >Now if you and Mark would say that you understand the problem >and ignore it intentionally, then we can go with solution "1". > >Is the problem clear ? Or should I elaborate the BY + RU => RU >and US => US + XX "academic exercises" ? > > Bye, Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 19:57:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07974; Sat, 2 Apr 2005 19:57:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHtYL-0000PC-NR; Sat, 02 Apr 2005 20:05:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHtOZ-00053A-LY; Sat, 02 Apr 2005 19:55:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHtOX-000532-HS for ltru@megatron.ietf.org; Sat, 02 Apr 2005 19:55:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07903 for ; Sat, 2 Apr 2005 19:55:13 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHtWA-00007W-ME for ltru@ietf.org; Sat, 02 Apr 2005 20:03:10 -0500 Received: from lns-p19-1-idf-82-251-95-81.adsl.proxad.net ([82.251.95.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DHtOV-00052B-Ew; Sat, 02 Apr 2005 16:55:16 -0800 Message-Id: <6.1.2.0.2.20050402115512.032d5e30@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 03 Apr 2005 02:55:04 +0200 To: "Randy Presuhn" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] is there some wiskey in the jar In-Reply-To: <002901c5374d$7f2b97e0$7f1afea9@oemcomputer> References: <4A7C6FA2AB31194E80E13FE585F6A21292A1CE@EVS-EC1-NODE1.surrey.ac.uk> <6.1.2.0.2.20050331201305.042e0c60@mail.jefsey.com> <20050331201010.GA6550@skunk.reutershealth.com> <6.1.2.0.2.20050401103458.042e0140@mail.jefsey.com> <20050402014946.GA16332@skunk.reutershealth.com> <6.1.2.0.2.20050402040415.03b58530@mail.jefsey.com> <002901c5374d$7f2b97e0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 On 08:30 02/04/2005, Randy Presuhn said: >Hi - >Please identify the specific text you want changed. Dear Randy, I indicated that I will present a review and a Draft. AP & MD documented it took them a full year's work to produce their Draft which does not consider others' needs. Allow us time enough to do something serious. I indicated: before mid-April. >(I assume you meant something like "Personal taste should not be reflected >in international standards." I mean gustos (spa) or gustoes (eng) as the personal taste and the artistic enjoyment of John. I acknowledge there John has a literary culture to be respected. And remind this culture is not unique, in ISO and in real world: even if it is in the IETF for historic and pragmatic reason. > (I've never observed this to be true in practice.)) Neither did I. But I also observed that most of the international standard blockages and delays result from the need of compromise on that very matter. This is why the best way to block the Draft I am advised, is to leave it the way it is. >I see no contradiction. The permeability of the boundaries in question is >completely independent of the extent to which spelling has been standardized. We talked of meanings and styles. Anyway the point is that standard should address concepts, not languages specifics. Lacks of a language cannot be a motive not to consider issues risen by others. >Everyone: if you want your postings to be taken seriously, please identify >the specific changes needed to address your concerns. Sorry, but before proposing changes (or a new approach) we try first to understand what are the needs the Draft tries to address. This is why I take everyone's postings very seriously and I thank everyone for their contribution, in particular Frank, Thomas, Ira, L.Gillam, Debbie, Doug and John. This is one of the ways I try to understand what are the needs the Draft tries to address. The other way is to call for help betters than me. I made a PDF of the Draft and send it around. No one yet said "I read it, I understand it, I support it". Most say "I do not understand what they want, it does not really make sense". A few say "their charter is not bad, may be should they read it". The remaining says: "Drop the issue. It will never fly, we will oppose: our prerequisites are not even considered". I must say I am quite dismayed by these reponses (which call for a real effort to obtain). Obviously no one is really excited about improving RFC 3066 which just middly does not work in a way most are happy with. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 20:32:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09368; Sat, 2 Apr 2005 20:32:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHu5r-0002QU-7O; Sat, 02 Apr 2005 20:40:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHtxP-0001Az-HE; Sat, 02 Apr 2005 20:31:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHtxO-0001Au-Pd for ltru@megatron.ietf.org; Sat, 02 Apr 2005 20:31:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09287 for ; Sat, 2 Apr 2005 20:31:16 -0500 (EST) Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHu51-0002HM-J1 for ltru@ietf.org; Sat, 02 Apr 2005 20:39:12 -0500 Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050403013103.IRBT7277.mta10.adelphia.net@DEWELL> for ; Sat, 2 Apr 2005 20:31:03 -0500 Message-ID: <012201c537ec$c793f820$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <006201c52f73$bba93420$030aa8c0@DEWELL> <10e401c537c7$3bbd52d0$857e3009@sanjose.ibm.com> Subject: Re: [Ltru] Registry in record-jar format Date: Sat, 2 Apr 2005 17:30:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Mark Davis wrote: > The deprecated info might as well be a real field instead of just a > comment: > ... > Deprecated: 1989 > > Same for the name change: > ... > Name_Changed: 1980 > Former_Value: New Hebrides That adds new fields "Deprecated," "Name_Changed," and "Former_Value," which aren't mentioned anywhere in the draft, and which constitute more of a change than converting from vertical-bar-delimited to record-jar in the first place. I don't feel comfortable with this unless there's some consensus. In the latest version, due to be posted around Wednesday if there is consensus, I've changed "Canonical_Value" to "Canonical" and "Recommended_Prefix" to "Prefix," and I wondered if even that was too much to do unilaterally. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 20:47:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10102; Sat, 2 Apr 2005 20:47:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHuKR-0003Ga-IU; Sat, 02 Apr 2005 20:55:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHuCR-0002tU-VC; Sat, 02 Apr 2005 20:46:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHuCQ-0002tP-JB for ltru@megatron.ietf.org; Sat, 02 Apr 2005 20:46:50 -0500 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10093 for ; Sat, 2 Apr 2005 20:46:48 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050403014619.DTZJ5402.mta11.adelphia.net@DEWELL> for ; Sat, 2 Apr 2005 20:46:19 -0500 Message-ID: <012801c537ee$e7c022c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050403005618.BJER2135.mta2.adelphia.net@megatron.ietf.org> Date: Sat, 2 Apr 2005 17:46:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > Mark claims that this is only an "academic exercise". Maybe he > thinks that CS, DE, VN, YE, and YU were all academic exercises. No, you got it backward. Mark wrote: > While you many see no urgency to this, I suggest that you remember > that there are some people for whom this is no academic exercise. Mark is one of the people who does NOT think this is an academic exercise. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 22:23:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18645; Sat, 2 Apr 2005 22:23:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHvpv-0000AC-11; Sat, 02 Apr 2005 22:31:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHvhl-0006bx-1q; Sat, 02 Apr 2005 22:23:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHvhk-0006bs-Ef for ltru@megatron.ietf.org; Sat, 02 Apr 2005 22:23:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18584 for ; Sat, 2 Apr 2005 22:23:13 -0500 (EST) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHvpO-00009c-Bq for ltru@ietf.org; Sat, 02 Apr 2005 22:31:11 -0500 Received: from lns-p19-1-idf-82-251-95-81.adsl.proxad.net ([82.251.95.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DHvhh-0000Nx-T0; Sat, 02 Apr 2005 19:23:14 -0800 Message-Id: <6.1.2.0.2.20050403051351.02f51ac0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 03 Apr 2005 05:23:06 +0200 To: "Doug Ewell" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Proposed changes to region subtags In-Reply-To: <012501c537ed$77b5b0e0$030aa8c0@DEWELL> References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org> <00c401c53754$cdfe41e0$030aa8c0@DEWELL> <6.1.2.0.2.20050402114743.03713610@mail.jefsey.com> <011101c537c7$be722b60$030aa8c0@DEWELL> <6.1.2.0.2.20050403005935.03c05b90@mail.jefsey.com> <012501c537ed$77b5b0e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 At 03:35 03/04/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > >> Code elements don't have an expiration date. They're good forever, > >> or until the MA withdraws or deprecates them. Subtags are good > >> forever, or until the language tagging mechanism is totally replaced. > > > > What makes their expiration date. > >Can you predict when those events will happen? If not, does it make >sense to reserve a field for it? I do not plan to reserve a field but to add the year in the code element. But the approach we _consider_ is quite different and much more Internet like. >Never mind; this is the structure for your draft, and you will design it >in the way you think is best. Yes. But the idea is not to design it differently from APMD for the XML/HTML/CLDR applications (t)hey know better what they want and did not document the CLDR specific needs. But to maintain the underlaying information available to every possible application format. Including the currently discussed format. Them being free to use it or not, the way they think the best. > >> I don't know what you mean by "APMD." A quick Web search led me to > >> information on power management for laptops, which I'm sure is not > >> what you meant. > > > > Addison Philips' and Mark Davis' Draft. > >Aha. > >Please write to me publicly, on the list, on issues related to the >Working Group. Sorry, privacy was not intended. I copy the list. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 2 22:24:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18684; Sat, 2 Apr 2005 22:24:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHvqY-0000Ag-G1; Sat, 02 Apr 2005 22:32:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHviP-0006gS-5X; Sat, 02 Apr 2005 22:23:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHviN-0006gN-QV for ltru@megatron.ietf.org; Sat, 02 Apr 2005 22:23:56 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18666 for ; Sat, 2 Apr 2005 22:23:52 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DHvgD-0007wR-33 for ltru@lists.ietf.org; Sun, 03 Apr 2005 05:21:41 +0200 Received: from 212.82.251.101 ([212.82.251.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Apr 2005 05:21:41 +0200 Received: from nobody by 212.82.251.101 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Apr 2005 05:21:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 03 Apr 2005 05:20:00 +0200 Organization: Lines: 25 Message-ID: <424F60E0.52A@xyzzy.claranet.de> References: <006201c52f73$bba93420$030aa8c0@DEWELL> <10e401c537c7$3bbd52d0$857e3009@sanjose.ibm.com> <012201c537ec$c793f820$030aa8c0@DEWELL> 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.101 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > That adds new fields "Deprecated," "Name_Changed," and > "Former_Value," which aren't mentioned anywhere in the draft, Maybe one new field "Comment" is better than separate fields "Depecated" + "Name_Changed" + "Former_Value". Please don't mention any former value like NH, if it's not more in the registry. Don't mention CS as former value for CZ or as former value for SK. Any "Former_Value" is like a pointer to a deprecated tag, the inverse of "Canonical". This won't work in a case like the old CS. > I've changed "Canonical_Value" to "Canonical" and > "Recommended_Prefix" to "Prefix," I like it. I'd like "Related" instead of "Prefix" even better, if that's the way to get a "default script" for some languages. Otherwise "Prefix" is fine. Do we need the "redundant" entries ? As the name says they are really redundant. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 01:17:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27519; Sun, 3 Apr 2005 01:17:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHyXl-0001NI-6o; Sun, 03 Apr 2005 01:25:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHyPK-00031d-GM; Sun, 03 Apr 2005 01:16:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHyPI-00031Y-TR for ltru@megatron.ietf.org; Sun, 03 Apr 2005 01:16:25 -0500 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27445 for ; Sun, 3 Apr 2005 01:16:23 -0500 (EST) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050403061551.NXMF2192.mta9.adelphia.net@DEWELL>; Sun, 3 Apr 2005 01:15:51 -0500 Message-ID: <000c01c5380c$3189bac0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050403005618.BJER2135.mta2.adelphia.net@megatron.ietf.org> Date: Sat, 2 Apr 2005 21:15:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: =?utf-8?Q?Martin_D=C3=BCrst?= Subject: [Ltru] Re: is there some wiskey in the jar X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > Neither did I. But I also observed that most of the international > standard blockages and delays result from the need of compromise on > that very matter. This is why the best way to block the Draft I am > advised, is to leave it the way it is. Does participation in an IETF Working Group with the intent of finding "the best way to block the Draft" qualify as "disruptive behavior" under BCP 94? If not, then what would? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 05:00:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06051; Sun, 3 Apr 2005 05:00:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI15b-0006ve-U3; Sun, 03 Apr 2005 05:08:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI0tg-00036m-TB; Sun, 03 Apr 2005 04:55:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI0te-00036h-DV for ltru@megatron.ietf.org; Sun, 03 Apr 2005 04:55:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05905 for ; Sun, 3 Apr 2005 04:55:52 -0400 (EDT) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI11M-0006cD-0B for ltru@ietf.org; Sun, 03 Apr 2005 05:03:52 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN4-5424faf87198; Sun, 03 Apr 2005 04:55:35 -0500 Received: from DEBHOME (ACD8C638.ipt.aol.com [172.216.198.56]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j338tOLO011572; Sun, 3 Apr 2005 04:55:24 -0400 Message-Id: <200504030855.j338tOLO011572@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Registry in record-jar format Date: Sun, 3 Apr 2005 09:55:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU37PAaRdCC5iDTTYKTVtrvYqnRBwAPWzLw In-Reply-To: <012201c537ec$c793f820$030aa8c0@DEWELL> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 X-Spam-Score: 2.6 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Doug Ewell wrote: >That adds new fields "Deprecated," "Name_Changed," and "Former_Value," >which aren't mentioned anywhere in the draft, and which constitute more of >a change than converting from vertical-bar-delimited to record-jar in the >first place. IMHO, these fields should be included... I am including something similar in -6. I am also including a date field for "last updated" Debbie Garside -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Doug Ewell Sent: 03 April 2005 02:31 To: LTRU Working Group Subject: Re: [Ltru] Registry in record-jar format Mark Davis wrote: > The deprecated info might as well be a real field instead of just a > comment: > ... > Deprecated: 1989 > > Same for the name change: > ... > Name_Changed: 1980 > Former_Value: New Hebrides That adds new fields "Deprecated," "Name_Changed," and "Former_Value," which aren't mentioned anywhere in the draft, and which constitute more of a change than converting from vertical-bar-delimited to record-jar in the first place. I don't feel comfortable with this unless there's some consensus. In the latest version, due to be posted around Wednesday if there is consensus, I've changed "Canonical_Value" to "Canonical" and "Recommended_Prefix" to "Prefix," and I wondered if even that was too much to do unilaterally. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 05:19:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06969; Sun, 3 Apr 2005 05:19:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI1Nk-0007yC-6S; Sun, 03 Apr 2005 05:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI1FQ-0005aC-DC; Sun, 03 Apr 2005 05:18:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI1FO-0005Zz-FY for ltru@megatron.ietf.org; Sun, 03 Apr 2005 05:18:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06958 for ; Sun, 3 Apr 2005 05:18:20 -0400 (EDT) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI1N5-0007xi-6p for ltru@ietf.org; Sun, 03 Apr 2005 05:26:20 -0400 Received: from lns-p19-1-idf-82-251-95-81.adsl.proxad.net ([82.251.95.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DI1FI-0004zR-UR; Sun, 03 Apr 2005 01:18:17 -0800 Message-Id: <6.1.2.0.2.20050403111029.02f60c10@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 03 Apr 2005 11:15:45 +0200 To: "Debbie Garside" , "'Doug Ewell'" , "'LTRU Working Group'" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Registry in record-jar format In-Reply-To: <200504030855.j338tOLO011572@smtp-los02.proxy.aol.com> References: <012201c537ec$c793f820$030aa8c0@DEWELL> <200504030855.j338tOLO011572@smtp-los02.proxy.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 At 10:55 03/04/2005, Debbie Garside wrote: >Doug Ewell wrote: > > >That adds new fields "Deprecated," "Name_Changed," and "Former_Value," > >which aren't mentioned anywhere in the draft, and which constitute more of > >a change than converting from vertical-bar-delimited to record-jar in the > >first place. > >IMHO, these fields should be included... I am including something similar in >-6. I am also including a date field for "last updated" Great. Will it be by the date of by the year? I would suggest that updates are carried by January 1st as for UDC (with the hope of a generalization) when to the day. The reason why is that it permits to cover the entire History (-32.000/+32.000) with two bytes. Otherwise Unix like dates will be used, what will cause much more troubles. I feel from experience that one full year incertitude is - one way or another - the degree of error we can expect in real life (and it is widely covered by the current practices of 5, 10 or 50 years delays). jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 05:19:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07018; Sun, 3 Apr 2005 05:19:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI1Nv-0007yP-5S; Sun, 03 Apr 2005 05:27:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI1FQ-0005aG-Hn; Sun, 03 Apr 2005 05:18:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI1FO-0005a0-Gr for ltru@megatron.ietf.org; Sun, 03 Apr 2005 05:18:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06957 for ; Sun, 3 Apr 2005 05:18:20 -0400 (EDT) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI1N5-0007xb-6l for ltru@ietf.org; Sun, 03 Apr 2005 05:26:20 -0400 Received: from lns-p19-1-idf-82-251-95-81.adsl.proxad.net ([82.251.95.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DI1FH-0004zR-AF; Sun, 03 Apr 2005 01:18:15 -0800 Message-Id: <6.1.2.0.2.20050403110609.02f41100@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 03 Apr 2005 11:10:05 +0200 To: "Doug Ewell" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: is there some wiskey in the jar In-Reply-To: <000c01c5380c$3189bac0$030aa8c0@DEWELL> References: <20050403005618.BJER2135.mta2.adelphia.net@megatron.ietf.org> <000c01c5380c$3189bac0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 On 07:15 03/04/2005, Doug Ewell said: >JFC (Jefsey) Morfin wrote: > > > Neither did I. But I also observed that most of the international > > standard blockages and delays result from the need of compromise on > > that very matter. This is why the best way to block the Draft I am > > advised, is to leave it the way it is. > >Does participation in an IETF Working Group with the intent of finding >"the best way to block the Draft" qualify as "disruptive behavior" under >BCP 94? If not, then what would? This permanent twisting starts being a boring disruptive behavior per se. Please reread what I wrote. Or may be, you are precisely referring to your own attitude. In this case I apologize for the misinderstanding. When is the jar going to be ready? I have a meeting on this on Tuesday and would like to show them an example or two of what you produced. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 06:36:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11616; Sun, 3 Apr 2005 06:36:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI2aZ-0003gZ-EF; Sun, 03 Apr 2005 06:44:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI2SG-0007qX-Fn; Sun, 03 Apr 2005 06:35:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI2SE-0007qS-If for ltru@megatron.ietf.org; Sun, 03 Apr 2005 06:35:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11571 for ; Sun, 3 Apr 2005 06:35:40 -0400 (EDT) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI2Zx-0003fc-86 for ltru@ietf.org; Sun, 03 Apr 2005 06:43:41 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN6-7424fc6f1246; Sun, 03 Apr 2005 06:35:29 -0500 Received: from DEBHOME (ACD8C638.ipt.aol.com [172.216.198.56]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j33AZMiq028765; Sun, 3 Apr 2005 06:35:22 -0400 Message-Id: <200504031035.j33AZMiq028765@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'JFC \(Jefsey\) Morfin'" , "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Registry in record-jar format Date: Sun, 3 Apr 2005 11:35:36 +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.2900.2180 Thread-Index: AcU4LgrBcueiwu9CTuCVIcPOdT3isQACnrWg In-Reply-To: <6.1.2.0.2.20050403111029.02f60c10@mail.jefsey.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 X-Spam-Score: 2.6 (++) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit At 10:55 03/04/2005, Debbie Garside wrote: >Doug Ewell wrote: > > >That adds new fields "Deprecated," "Name_Changed," and "Former_Value," > >which aren't mentioned anywhere in the draft, and which constitute > >more of a change than converting from vertical-bar-delimited to > >record-jar in the first place. > >IMHO, these fields should be included... I am including something >similar in -6. I am also including a date field for "last updated" Jefsey Wrote: >Great. Will it be by the date of by the year? I had thought by the date as I want to be as concise as possible but everything (in my draft) is up for discussion. Debbie Garside -----Original Message----- From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] Sent: 03 April 2005 10:16 To: Debbie Garside; 'Doug Ewell'; 'LTRU Working Group' Subject: RE: [Ltru] Registry in record-jar format At 10:55 03/04/2005, Debbie Garside wrote: >Doug Ewell wrote: > > >That adds new fields "Deprecated," "Name_Changed," and "Former_Value," > >which aren't mentioned anywhere in the draft, and which constitute more of > >a change than converting from vertical-bar-delimited to record-jar in the > >first place. > >IMHO, these fields should be included... I am including something similar in >-6. I am also including a date field for "last updated" Great. Will it be by the date of by the year? I would suggest that updates are carried by January 1st as for UDC (with the hope of a generalization) when to the day. The reason why is that it permits to cover the entire History (-32.000/+32.000) with two bytes. Otherwise Unix like dates will be used, what will cause much more troubles. I feel from experience that one full year incertitude is - one way or another - the degree of error we can expect in real life (and it is widely covered by the current practices of 5, 10 or 50 years delays). jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 06:58:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12913; Sun, 3 Apr 2005 06:58:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI2vt-0004w2-Pv; Sun, 03 Apr 2005 07:06:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI2n9-0001Qn-PQ; Sun, 03 Apr 2005 06:57:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI2n8-0001Qi-NN for ltru@megatron.ietf.org; Sun, 03 Apr 2005 06:57:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12854 for ; Sun, 3 Apr 2005 06:57:16 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI2uq-0004uz-DH for ltru@ietf.org; Sun, 03 Apr 2005 07:05:17 -0400 Received: from eupig1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Sun, 3 Apr 2005 10:57:04 +0000 Message-ID: Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IED00CZGAF4N8@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Sun, 03 Apr 2005 10:57:04 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Sun, 03 Apr 2005 11:57:03 +0100 Date: Sun, 03 Apr 2005 11:57:03 +0100 From: Misha Wolf Subject: RE: [Ltru] Registry in record-jar format To: ltru@ietf.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Registry in record-jar format Thread-Index: AcU4LgrBcueiwu9CTuCVIcPOdT3isQACnrWgAAC/ItA= content-class: urn:content-classes:message X-OriginalArrivalTime: 03 Apr 2005 10:57:03.0631 (UTC) FILETIME=[DE7431F0:01C5383B] X-Spam-Score: 0.8 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Hi Debbie, You wrote: > I had thought by the date as I want to be as concise=20 > as possible but everything (in my draft) is up for=20 > discussion.=20 This is the second time you've used the word "concise"=20 in a way that is unfamiliar to me. Please clarify what=20 you mean by it. Thanks, Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 07:27:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14632; Sun, 3 Apr 2005 07:27:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI3OJ-0006jS-Kh; Sun, 03 Apr 2005 07:35:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI3Fj-0003gy-EE; Sun, 03 Apr 2005 07:26:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI3Fi-0003gt-6i for ltru@megatron.ietf.org; Sun, 03 Apr 2005 07:26:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14607 for ; Sun, 3 Apr 2005 07:26:47 -0400 (EDT) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI3NR-0006im-AE for ltru@ietf.org; Sun, 03 Apr 2005 07:34:49 -0400 Received: from smtp-los03.proxy.aol.com (smtp-los03.proxy.aol.com [195.93.24.41]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN7-8424fd2ed93; Sun, 03 Apr 2005 07:26:37 -0500 Received: from DEBHOME (ACD8C638.ipt.aol.com [172.216.198.56]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j33BQWWE011730; Sun, 3 Apr 2005 07:26:32 -0400 Message-Id: <200504031126.j33BQWWE011730@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Misha Wolf'" , Subject: RE: [Ltru] Registry in record-jar format Date: Sun, 3 Apr 2005 12:26:46 +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.2900.2180 Thread-Index: AcU4LgrBcueiwu9CTuCVIcPOdT3isQACnrWgAAC/ItAAAMSvgA== In-Reply-To: X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.6 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Hi Miska You wrote: > This is the second time you've used the word "concise" > in a way that is unfamiliar to me. Please clarify what > you mean by it. My meaning is in the strict English sense, as taken from the OED, "giving a lot of information clearly but in few words". In this instance I feel that date as opposed to year is more precise/concise... (precision is also top of my agenda) however, as previously stated, everything is up for discussion and if there is a clear, valid reason for having just "year" I am very interested. Kind regards Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Misha Wolf Sent: 03 April 2005 11:57 To: ltru@ietf.org Subject: RE: [Ltru] Registry in record-jar format Hi Debbie, You wrote: > I had thought by the date as I want to be as concise > as possible but everything (in my draft) is up for > discussion. This is the second time you've used the word "concise" in a way that is unfamiliar to me. Please clarify what you mean by it. Thanks, Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 07:56:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16864; Sun, 3 Apr 2005 07:56:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI3pk-0008T6-Lh; Sun, 03 Apr 2005 08:04:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI3cl-0006Vi-Ix; Sun, 03 Apr 2005 07:50:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI3ck-0006Vd-7Q for ltru@megatron.ietf.org; Sun, 03 Apr 2005 07:50:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16619 for ; Sun, 3 Apr 2005 07:50:35 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI3kR-00086U-I9 for ltru@ietf.org; Sun, 03 Apr 2005 07:58:37 -0400 Received: from smtp-los04.proxy.aol.com (smtp-los04.proxy.aol.com [195.93.24.101]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN2-3424fd882bf; Sun, 03 Apr 2005 07:50:26 -0500 Received: from DEBHOME (ACD8C638.ipt.aol.com [172.216.198.56]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j33BoJWC005577; Sun, 3 Apr 2005 07:50:19 -0400 Message-Id: <200504031150.j33BoJWC005577@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'JFC \(Jefsey\) Morfin'" , "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Registry in record-jar format Date: Sun, 3 Apr 2005 12:50:33 +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.2900.2180 Thread-Index: AcU4LgrBcueiwu9CTuCVIcPOdT3isQAFJrmQ In-Reply-To: <6.1.2.0.2.20050403111029.02f60c10@mail.jefsey.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.101 X-Spam-Score: 2.6 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit JFC wrote: >I would suggest that updates are carried by January 1st as for UDC (with the hope of a generalization) when to the day. The reason why is that it permits to cover the entire History (-32.000/+32.000) with two bytes. Otherwise Unix like dates will be used, what will cause much more troubles. I feel from experience that one full year incertitude is - one way or another - the degree of error we can expect in real life (and it is widely covered by the current practices of 5, 10 or 50 years delays). For my own purposes (and these are purely database maintenance at the moment) I would want to see a full date... However, there is no reason why the proposed registry itself could not just be year (as taken from full date). Debbie -----Original Message----- From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] Sent: 03 April 2005 10:16 To: Debbie Garside; 'Doug Ewell'; 'LTRU Working Group' Subject: RE: [Ltru] Registry in record-jar format At 10:55 03/04/2005, Debbie Garside wrote: >Doug Ewell wrote: > > >That adds new fields "Deprecated," "Name_Changed," and "Former_Value," > >which aren't mentioned anywhere in the draft, and which constitute more of > >a change than converting from vertical-bar-delimited to record-jar in the > >first place. > >IMHO, these fields should be included... I am including something similar in >-6. I am also including a date field for "last updated" Great. Will it be by the date of by the year? I would suggest that updates are carried by January 1st as for UDC (with the hope of a generalization) when to the day. The reason why is that it permits to cover the entire History (-32.000/+32.000) with two bytes. Otherwise Unix like dates will be used, what will cause much more troubles. I feel from experience that one full year incertitude is - one way or another - the degree of error we can expect in real life (and it is widely covered by the current practices of 5, 10 or 50 years delays). jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 10:05:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26445; Sun, 3 Apr 2005 10:05:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI5qb-00082R-T7; Sun, 03 Apr 2005 10:13:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI5hZ-0004Xg-70; Sun, 03 Apr 2005 10:03:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI5hW-0004Xb-QY for ltru@megatron.ietf.org; Sun, 03 Apr 2005 10:03:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26217 for ; Sun, 3 Apr 2005 10:03:41 -0400 (EDT) Received: from [63.247.76.194] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI5pG-0007so-7Q for ltru@ietf.org; Sun, 03 Apr 2005 10:11:43 -0400 Received: from lns-p19-1-idf-82-251-95-81.adsl.proxad.net ([82.251.95.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DI5hT-0000Ks-NS; Sun, 03 Apr 2005 07:03:40 -0700 Message-Id: <6.1.2.0.2.20050403125824.04aedd00@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 03 Apr 2005 16:03:31 +0200 To: Frank Ellermann From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Registry in record-jar format In-Reply-To: <424F60E0.52A@xyzzy.claranet.de> References: <006201c52f73$bba93420$030aa8c0@DEWELL> <10e401c537c7$3bbd52d0$857e3009@sanjose.ibm.com> <012201c537ec$c793f820$030aa8c0@DEWELL> <424F60E0.52A@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 On 05:20 03/04/2005, Frank Ellermann said: >Do we need the "redundant" entries ? As the name says they are >really redundant. > Bye, Frank Dear Frank, The first thing you are to publish in a compilation - as in every open source code - is the list of your sources and of their intellectual property rights or acknowledgements. So everyone can make its own compilation. So there is no real problem if deontology is respected. What may help is a note on the filtering process of each document, to avoid the mistakes others have already experimented. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 12:22:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06032; Sun, 3 Apr 2005 12:22:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI7zK-0007X2-Gx; Sun, 03 Apr 2005 12:30:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI7r6-0003vb-4x; Sun, 03 Apr 2005 12:21:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI7r4-0003vO-7F for ltru@megatron.ietf.org; Sun, 03 Apr 2005 12:21:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05983 for ; Sun, 3 Apr 2005 12:21:38 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI7yn-0007W5-FC for ltru@ietf.org; Sun, 03 Apr 2005 12:29:42 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j33GLSam031034 for ; Sun, 3 Apr 2005 12:21:28 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j33GLSlJ217998 for ; Sun, 3 Apr 2005 12:21:28 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j33GLR0Z019647 for ; Sun, 3 Apr 2005 11:21:28 -0500 Received: from markdavis (sig-9-48-118-3.mts.ibm.com [9.48.118.3]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with SMTP id j33GLPUa019614; Sun, 3 Apr 2005 11:21:27 -0500 Message-ID: <003d01c53869$2e2f23d0$03763009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <006201c52f73$bba93420$030aa8c0@DEWELL><10e401c537c7$3bbd52d0$857e3009@sanjose.ibm.com> <012201c537ec$c793f820$030aa8c0@DEWELL> Subject: Re: [Ltru] Registry in record-jar format Date: Sun, 3 Apr 2005 09:19:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e3.ny.us.ibm.com id j33GLSam031034 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable > I don't feel comfortable with this unless there's some consensus. Of course. =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Saturday, April 02, 2005 18:30 Subject: Re: [Ltru] Registry in record-jar format > Mark Davis wrote: > > > The deprecated info might as well be a real field instead of just a > > comment: > > ... > > Deprecated: 1989 > > > > Same for the name change: > > ... > > Name_Changed: 1980 > > Former_Value: New Hebrides > > That adds new fields "Deprecated," "Name_Changed," and "Former_Value," > which aren't mentioned anywhere in the draft, and which constitute more > of a change than converting from vertical-bar-delimited to record-jar i= n > the first place. > > I don't feel comfortable with this unless there's some consensus. In > the latest version, due to be posted around Wednesday if there is > consensus, I've changed "Canonical_Value" to "Canonical" and > "Recommended_Prefix" to "Prefix," and I wondered if even that was too > much to do unilaterally. > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 12:49:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07968; Sun, 3 Apr 2005 12:49:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI8Q1-0000kU-WC; Sun, 03 Apr 2005 12:57:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI8H2-0007LS-0o; Sun, 03 Apr 2005 12:48:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI8H1-0007LK-Dx for ltru@megatron.ietf.org; Sun, 03 Apr 2005 12:48:31 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07908 for ; Sun, 3 Apr 2005 12:48:28 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050403164759.UXVC5402.mta11.adelphia.net@DEWELL> for ; Sun, 3 Apr 2005 12:47:59 -0400 Message-ID: <009401c5386c$dd99e140$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <200504030855.j338tOLO011572@smtp-los02.proxy.aol.com> Subject: Re: [Ltru] Registry in record-jar format Date: Sun, 3 Apr 2005 09:47:46 -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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Debbie Garside wrote: > IMHO, these fields should be included... I am including something > similar in -6. I am also including a date field for "last updated" That is what our existing "Date" field is for. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 12:57:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08466; Sun, 3 Apr 2005 12:57:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI8Xl-0001Iu-DW; Sun, 03 Apr 2005 13:05:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI8Ke-0007cw-Bb; Sun, 03 Apr 2005 12:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI8Kd-0007co-1Q for ltru@megatron.ietf.org; Sun, 03 Apr 2005 12:52:15 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08083 for ; Sun, 3 Apr 2005 12:52:11 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050403165138.UPRB4618.mta13.adelphia.net@DEWELL> for ; Sun, 3 Apr 2005 12:51:38 -0400 Message-ID: <009501c5386d$62c81e40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050403005618.BJER2135.mta2.adelphia.net@megatron.ietf.org> <000c01c5380c$3189bac0$030aa8c0@DEWELL> <6.1.2.0.2.20050403110609.02f41100@mail.jefsey.com> Date: Sun, 3 Apr 2005 09:51:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags (incorporating "wiskey") X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > When is the jar going to be ready? I have a meeting on this on Tuesday > and would like to show them an example or two of what you produced. Please reread what I wrote on Tuesday, March 29: > I propose the following changes to the region subtags. I'd like to > see if we can reach a rough consensus on these items by next > Wednesday, April 6, at which point I will float a new version of the > registry, as well as complete step-by-step instructions for populating > all parts of the registry. The goal was to allow everyone a week to review the proposed changes. So far, Mark and Peter have agreed, and perhaps Addison and John too (based on responses to a different message), and Frank has agreed with the proviso that more rules could be added later. Nobody so far has explicitly disapproved. If you need some examples for Tuesday, my message of Saturday, April 2 at 2:58 includes an example of the date record (not very informative) and two language records. There are no examples yet of the fields "Deprecated," "Name_Changed," and "Former_Value" because those are still being debated, and because they are not authorized in any draft. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 13:02:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09248; Sun, 3 Apr 2005 13:02:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI8cJ-0001cH-0R; Sun, 03 Apr 2005 13:10:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI8Tw-0000vm-Vn; Sun, 03 Apr 2005 13:01:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI8Tw-0000vh-1a for ltru@megatron.ietf.org; Sun, 03 Apr 2005 13:01:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09072 for ; Sun, 3 Apr 2005 13:01:49 -0400 (EDT) Received: from postie2.hosting365.ie ([82.195.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI8bg-0001Zm-TN for ltru@ietf.org; Sun, 03 Apr 2005 13:09:54 -0400 Received: from Lugh (83-70-34-168.b-ras1.prp.dublin.eircom.net [83.70.34.168]) by postie2.hosting365.ie (Postfix) with ESMTP id C088027B1A90E for ; Sun, 3 Apr 2005 18:01:46 +0100 (IST) From: "Jon Hanna" To: "'LTRU Working Group'" Date: Sun, 3 Apr 2005 18:01:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU4btEVSdDqh5iaT9K/OirkPA9RlA== Message-Id: <20050403170146.C088027B1A90E@postie2.hosting365.ie> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Ltru] Registry in RDF/XML format. X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Hi, I've only barely been able to keep up with this list of late due to = other obligations, but is an RDF/XML format completely out of the = question? Regards, Jon Hanna Work: Play: Chat: _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 13:10:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10054; Sun, 3 Apr 2005 13:10:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI8jq-000230-Ee; Sun, 03 Apr 2005 13:18:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI8aE-0001cA-BD; Sun, 03 Apr 2005 13:08:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI8aD-0001bt-9W for ltru@megatron.ietf.org; Sun, 03 Apr 2005 13:08:21 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09905 for ; Sun, 3 Apr 2005 13:08:18 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050403170749.DBHA7277.mta10.adelphia.net@DEWELL> for ; Sun, 3 Apr 2005 13:07:49 -0400 Message-ID: <00a001c5386f$a29dc0e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050403103606.VJUH4900.mta8.adelphia.net@megatron.ietf.org> Date: Sun, 3 Apr 2005 10:07:35 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> I've changed "Canonical_Value" to "Canonical" and >> "Recommended_Prefix" to "Prefix," > > I like it. I'd like "Related" instead of "Prefix" even better, > if that's the way to get a "default script" for some languages. > Otherwise "Prefix" is fine. Did we have consensus on default script? I remember a lot of discussion, but no agreement. If default script is going to be in the registry, its behavior needs to be specified in the draft and in the matching draft, and someone needs to do the expert work of deciding which languages have a "default" script and which do not. > Do we need the "redundant" entries ? As the name says they are > really redundant. I'm not sure. I don't use them myself, except as an informative note in my validator, as shown with example "zh-Hans": > Subtag 1: zh > Language subtag: Chinese (registered 2004-07-06) > > Subtag 2: Hans > Script subtag: Han (Simplified variant) (registered 2004-07-06) > > RFC 3066 registered description: simplified Chinese (registered > 2003-05-30) -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 13:37:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12207; Sun, 3 Apr 2005 13:37:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI99q-0003vZ-Cr; Sun, 03 Apr 2005 13:45:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI91T-00045Z-Q7; Sun, 03 Apr 2005 13:36:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DI91R-00045T-Qi for ltru@megatron.ietf.org; Sun, 03 Apr 2005 13:36:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12149 for ; Sun, 3 Apr 2005 13:36:26 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DI99B-0003uD-3M for ltru@ietf.org; Sun, 03 Apr 2005 13:44:32 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j33Ha9n4000016; Sun, 3 Apr 2005 13:36:10 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 3 Apr 2005 13:35:34 -0400 Date: Sun, 3 Apr 2005 13:35:34 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: Registry in record-jar format Message-ID: <20050403173534.GA6190@skunk.reutershealth.com> References: <20050403103606.VJUH4900.mta8.adelphia.net@megatron.ietf.org> <00a001c5386f$a29dc0e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a001c5386f$a29dc0e0$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Doug Ewell scripsit: > If default script is going to be in the registry, its behavior needs to > be specified in the draft and in the matching draft, and someone needs > to do the expert work of deciding which languages have a "default" > script and which do not. I think this is out of scope, and only going to get worse with ISO 639-3. Let's just not go there. -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 15:24:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20791; Sun, 3 Apr 2005 15:24:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIApg-00023X-UL; Sun, 03 Apr 2005 15:32:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIAg6-00046S-Rg; Sun, 03 Apr 2005 15:22:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIAg5-00046N-F3 for ltru@megatron.ietf.org; Sun, 03 Apr 2005 15:22:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20688 for ; Sun, 3 Apr 2005 15:22:29 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIAnp-00022Q-N3 for ltru@ietf.org; Sun, 03 Apr 2005 15:30:35 -0400 Received: from lns-p19-1-idf-82-251-95-81.adsl.proxad.net ([82.251.95.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DIAg0-0007d4-BH for ltru@ietf.org; Sun, 03 Apr 2005 12:22:28 -0700 Message-Id: <6.1.2.0.2.20050403212027.04aed090@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 03 Apr 2005 21:22:17 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Registry in record-jar format Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 On 13:26 03/04/2005, Debbie Garside said: >Hi Miska > >You wrote: > > > This is the second time you've used the word "concise" > > in a way that is unfamiliar to me. Please clarify what > > you mean by it. > >My meaning is in the strict English sense, as taken from the OED, "giving a >lot of information clearly but in few words". > >In this instance I feel that date as opposed to year is more >precise/concise... (precision is also top of my agenda) however, as >previously stated, everything is up for discussion and if there is a clear, >valid reason for having just "year" I am very interested. Misha, date includes year. precision is relative. There are cases where date is needed (for example to sort standards, or "first come first serve" cases). There are cases where year is enough. And is more consise as well as more precise due to the errors the date treatment can introduce. For example the date depends on a format, the year not. The date is often on 4 bytes, the year can be on 2 or less. If the date is presented with an appropriate ascii format, the year is part of it and you have 2 information for the digital cost of one, etc. If you list the year first, month and day in digits you also get yourself a precise sorting order. If you concatenate the and may be a part of a unique string, you have a unique ID you can then scramble with an MD5 to obtain a unique stable 32 bytes anonymous ID suitable for a random sorting or protection. This is a way to get 3, 4, 5 or more information one shot. "consise" seems therefore the most appropriate word. As many noted in term of size of a base (which is very different from resulting traffic generated by an application) we are not concerned by the size but by the apparent complexity of access translating in delays, added/biased noise, time, simplisity, surety, security and flexibility of update and access, risks of error, database consistency, versatility and independence from formats, % availability, involved costs, etc.. So conciseness is a complete thinking, including data collection, management and dissemination processes, openess, delays and costs. This is precisly the issue here. Debbie is here working one of the most important issue. This is why I do not think we can reach anything final before having read what the ISO 639 group comes with on the matter. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 15:40:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21746; Sun, 3 Apr 2005 15:40:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIB59-0002zD-Pa; Sun, 03 Apr 2005 15:48:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIAvV-0004YP-Be; Sun, 03 Apr 2005 15:38:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIAvT-0004YK-Lw for ltru@megatron.ietf.org; Sun, 03 Apr 2005 15:38:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21536 for ; Sun, 3 Apr 2005 15:38:25 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIB3F-0002tE-SJ for ltru@ietf.org; Sun, 03 Apr 2005 15:46:31 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j33JcHss032296 for ; Sun, 3 Apr 2005 15:38:17 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j33JcGU3076114 for ; Sun, 3 Apr 2005 15:38:16 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j33JcGBT030761 for ; Sun, 3 Apr 2005 14:38:16 -0500 Received: from markdavis (sig-9-48-118-3.mts.ibm.com [9.48.118.3]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with SMTP id j33JcFU0030742; Sun, 3 Apr 2005 14:38:16 -0500 Message-ID: <006301c53884$ad28d4e0$03763009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <20050403103606.VJUH4900.mta8.adelphia.net@megatron.ietf.org> <00a001c5386f$a29dc0e0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Registry in record-jar format Date: Sun, 3 Apr 2005 12:38:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e6.ny.us.ibm.com id j33JcHss032296 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable > Did we have consensus on default script? I remember a lot of > discussion, but no agreement. No, it's a bad idea. That's for matching. > > Do we need the "redundant" entries ? As the name says they are > > really redundant. I don't care much either way. What I was saying in my note that the redundant *comments* on the redundant records were, well, redundant. =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Sunday, April 03, 2005 10:07 Subject: [Ltru] Re: Registry in record-jar format > Frank Ellermann wrote: > > >> I've changed "Canonical_Value" to "Canonical" and > >> "Recommended_Prefix" to "Prefix," > > > > I like it. I'd like "Related" instead of "Prefix" even better, > > if that's the way to get a "default script" for some languages. > > Otherwise "Prefix" is fine. > ... > > If default script is going to be in the registry, its behavior needs to > be specified in the draft and in the matching draft, and someone needs > to do the expert work of deciding which languages have a "default" > script and which do not. > ... > > I'm not sure. I don't use them myself, except as an informative note i= n > my validator, as shown with example "zh-Hans": > > > Subtag 1: zh > > Language subtag: Chinese (registered 2004-07-06) > > > > Subtag 2: Hans > > Script subtag: Han (Simplified variant) (registered 2004-07-06) > > > > RFC 3066 registered description: simplified Chinese (registered > > 2003-05-30) > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 16:07:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23275; Sun, 3 Apr 2005 16:07:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIBV1-0004cI-7K; Sun, 03 Apr 2005 16:15:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIBH9-0006lA-E8; Sun, 03 Apr 2005 16:00:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIBH8-0006l5-5s for ltru@megatron.ietf.org; Sun, 03 Apr 2005 16:00:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23047 for ; Sun, 3 Apr 2005 16:00:48 -0400 (EDT) Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIBOu-0004I5-QO for ltru@ietf.org; Sun, 03 Apr 2005 16:08:54 -0400 Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050403200035.BEVS5402.mta11.adelphia.net@DEWELL> for ; Sun, 3 Apr 2005 16:00:35 -0400 Message-ID: <000a01c53887$93e18ce0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050403103606.VJUH4900.mta8.adelphia.net@megatron.ietf.org> <00a001c5386f$a29dc0e0$030aa8c0@DEWELL> <006301c53884$ad28d4e0$03763009@sanjose.ibm.com> Date: Sun, 3 Apr 2005 12:58:58 -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.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Mark Davis wrote: >>> Do we need the "redundant" entries ? As the name says they are >>> really redundant. > > I don't care much either way. What I was saying in my note that the > redundant *comments* on the redundant records were, well, redundant. I don't like them either. I thought there was a statement in the draft that "redundant" entries had to have such a comment. Maybe it has to do with the passage in Appendix C that grandfathered entries have to have a comment "indicating... [the] reason for the deprecation." Maybe it was part of a discussion months ago. Maybe I just dreamed it. In any case, I'm happy to remove the redundant comments (ambiguity intended) if it's OK with everyone else. BTW, that whole paragraph in Appendix C is confusing to me: "Tags that are currently deprecated will be maintained as grandfathered entries. The record for the grandfathered entry will contain a note indicating that the entry is 'deprecated' and reason for the deprecation. For example, the tag "art-lojban" is deprecated and will be placed in the grandfathered section." There is no intrinsic relationship between grandfathered and deprecated. The tag "i-ami" is grandfathered but not deprecated, while the tag "in" is deprecated but not grandfathered. Only 28% of the grandfathered tags are deprecated, and in fact none were until we added the long-missing provision to give them a whole-tag canonical value. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 16:07:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23315; Sun, 3 Apr 2005 16:07:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIBVI-0004kg-Qq; Sun, 03 Apr 2005 16:15:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIBLL-0006vZ-MG; Sun, 03 Apr 2005 16:05:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIBLK-0006vR-Jo for ltru@megatron.ietf.org; Sun, 03 Apr 2005 16:05:10 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23156 for ; Sun, 3 Apr 2005 16:05:08 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050403200439.JZRL2192.mta9.adelphia.net@DEWELL> for ; Sun, 3 Apr 2005 16:04:39 -0400 Message-ID: <001101c53888$27ca3c40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050403160207.FFYP2140.mta3.adelphia.net@megatron.ietf.org> Date: Sun, 3 Apr 2005 13:03:06 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > The first thing you are to publish in a compilation - as in every open > source code - is the list of your sources and of their intellectual > property rights or acknowledgements. So everyone can make its own > compilation. I thought one of the things we wanted to avoid was having everyone make his own compilation. That's how we end up with mismatched versions and incompatible implementations. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 17:45:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28824; Sun, 3 Apr 2005 17:45:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DID22-0001xg-5k; Sun, 03 Apr 2005 17:53:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DICtD-0006c6-GD; Sun, 03 Apr 2005 17:44:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DICtB-0006c1-Qv for ltru@megatron.ietf.org; Sun, 03 Apr 2005 17:44:13 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28719 for ; Sun, 3 Apr 2005 17:44:10 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050403214341.EQNJ5402.mta11.adelphia.net@DEWELL> for ; Sun, 3 Apr 2005 17:43:41 -0400 Message-ID: <005001c53896$1cde2ea0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050403200703.DBLB2140.mta3.adelphia.net@megatron.ietf.org> Date: Sun, 3 Apr 2005 14:43:01 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in RDF/XML format. X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Jon Hanna wrote: > is an RDF/XML format completely out of the question? Nothing is completely out of the question yet. The current thought seems to be that record-jar would be easy for everyone to parse, while XML requires a lot more overhead unless you already have an XML parser, which is far from universally true. There may be an XML version available for informative purposes, but the record-jar version would be the one and only normative resource. (For that matter, I suppose anyone could host an XML version privately, as long as it was clear that it was not official.) -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 17:57:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29515; Sun, 3 Apr 2005 17:57:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIDDW-0002gQ-SU; Sun, 03 Apr 2005 18:05:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DID2x-0007EX-J4; Sun, 03 Apr 2005 17:54:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DID2w-0007EP-9a for ltru@megatron.ietf.org; Sun, 03 Apr 2005 17:54:18 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29427 for ; Sun, 3 Apr 2005 17:54:15 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050403215346.FSQA4618.mta13.adelphia.net@DEWELL> for ; Sun, 3 Apr 2005 17:53:46 -0400 Message-ID: <006501c53897$7daf8840$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 3 Apr 2005 14:52:53 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Date of deprecation (was: Re: Registry in record-jar format) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit What is the perceived benefit, for language tagging purposes, of including a field that indicates the date a given subtag was deprecated? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 18:13:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01408; Sun, 3 Apr 2005 18:13:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIDTI-0003bh-VY; Sun, 03 Apr 2005 18:21:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIDKC-0000VH-6O; Sun, 03 Apr 2005 18:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIDKA-0000Ug-V5 for ltru@megatron.ietf.org; Sun, 03 Apr 2005 18:12:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01286 for ; Sun, 3 Apr 2005 18:12:04 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIDRy-0003ah-Cn for ltru@ietf.org; Sun, 03 Apr 2005 18:20:11 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j33MBu5E006851 for ; Sun, 3 Apr 2005 18:11:56 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j33MBuU3096084 for ; Sun, 3 Apr 2005 18:11:56 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j33MBu0U003519 for ; Sun, 3 Apr 2005 17:11:56 -0500 Received: from markdavis (sig-9-48-118-3.mts.ibm.com [9.48.118.3]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with SMTP id j33MBs8l003509; Sun, 3 Apr 2005 17:11:55 -0500 Message-ID: <00fa01c5389a$2460cd50$03763009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <006501c53897$7daf8840$030aa8c0@DEWELL> Subject: Re: [Ltru] Date of deprecation (was: Re: Registry in record-jar format) Date: Sun, 3 Apr 2005 15:11:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e3.ny.us.ibm.com id j33MBu5E006851 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable If it is worth putting in a comment for every instance, it is worth makin= g it a field, because then it can be parsed. =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Sunday, April 03, 2005 14:52 Subject: [Ltru] Date of deprecation (was: Re: Registry in record-jar form= at) > What is the perceived benefit, for language tagging purposes, of > including a field that indicates the date a given subtag was deprecated= ? > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 3 19:24:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06619; Sun, 3 Apr 2005 19:24:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIEa2-0007vF-Ks; Sun, 03 Apr 2005 19:32:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIERC-0005bo-5v; Sun, 03 Apr 2005 19:23:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIERA-0005bj-7x for ltru@megatron.ietf.org; Sun, 03 Apr 2005 19:23:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06530 for ; Sun, 3 Apr 2005 19:23:19 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIEYv-0007uY-PP for ltru@ietf.org; Sun, 03 Apr 2005 19:31:27 -0400 Received: from lns-p19-1-idf-82-251-95-81.adsl.proxad.net ([82.251.95.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DIEQw-0005iW-QE; Sun, 03 Apr 2005 16:23:11 -0700 Message-Id: <6.1.2.0.2.20050403230438.02f6eb60@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 04 Apr 2005 01:23:02 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Registry in record-jar format In-Reply-To: <001101c53888$27ca3c40$030aa8c0@DEWELL> References: <20050403160207.FFYP2140.mta3.adelphia.net@megatron.ietf.org> <001101c53888$27ca3c40$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca At 22:03 03/04/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > > The first thing you are to publish in a compilation - as in every open > > source code - is the list of your sources and of their intellectual > > property rights or acknowledgements. So everyone can make its own > > compilation. > >I thought one of the things we wanted to avoid was having everyone make >his own compilation. That's how we end up with mismatched versions and >incompatible implementations. Dear Doug, the Internet is the "adherence of the people to the network of the people by the people". There is no "we" able to decide anything. You can only convince by the quality, the usefulness and the availability of the service you propose. Consensus is not a rule, it is a prerequisite which does not give any warranty of success ("not all RFCs become standards"). Looking for consensus is only an incentive to be good and professional. The flaw is to ask friends on a list "what do you want" instead of "what will the users want (to pay for?)" (and to try to ban those disagreeing with your own vision!). There is a basic network law: everything permitted by the code which may hurt, be fun, make money, or be useful to some will be attempted and may develop. Another on a closed or global network is "everything another member thinks bad for him is bad for you". Obviously everyone who is not happy with yours will do his own compilation (I only wait for yours to know if I can make it compatible with the ones I make for many years) - this is the very nature of competition and of networking! This is why you have two priorities: - make me happy enough so I do not develop my own solution and I can use yours - if I continue developing mine our solutions stay compatible with all the others. This is the only interest of the IANA registration. This is why I keep asking about the target. The target cannot be to build and maintain a table avoiding mismatched versions and incompatible implementations controlled by a lawyer and enforced by a cop. It can only be to propose practices which will preserve end to end compatibility between the different implementations and versions which may attract the users. I know, multilateral, intelligent and distributed networking calls for more skills, vision and work than for the prototype unilateral, default and centralized network. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 01:36:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01942; Mon, 4 Apr 2005 01:36:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIKO5-0001ME-9E; Mon, 04 Apr 2005 01:44:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIKF8-0000kW-4r; Mon, 04 Apr 2005 01:35:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIKF5-0000kR-Vr for ltru@megatron.ietf.org; Mon, 04 Apr 2005 01:35:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01850 for ; Mon, 4 Apr 2005 01:35:19 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIKMx-0001KV-BF for ltru@ietf.org; Mon, 04 Apr 2005 01:43:28 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 3 Apr 2005 22:35:08 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sun, 3 Apr 2005 22:35:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Registry in record-jar format Date: Sun, 3 Apr 2005 22:35:14 -0700 Message-ID: Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU4c8k2RO14vqjfR3uyheOcklhRNgAZDqrg From: "Peter Constable" To: "John Cowan" , "Doug Ewell" X-OriginalArrivalTime: 04 Apr 2005 05:35:07.0490 (UTC) FILETIME=[0F8CBC20:01C538D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of John Cowan > > If default script is going to be in the registry, its behavior needs to > > be specified in the draft and in the matching draft, and someone needs > > to do the expert work of deciding which languages have a "default" > > script and which do not. >=20 > I think this is out of scope, and only going to get worse with ISO 639-3. > Let's just not go there. +1 Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 09:32:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05298; Mon, 4 Apr 2005 09:32:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIRoR-0004tG-Kz; Mon, 04 Apr 2005 09:40:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIRfY-0003gz-Vb; Mon, 04 Apr 2005 09:31:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIRfW-0003gu-Js for ltru@megatron.ietf.org; Mon, 04 Apr 2005 09:31:06 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05197 for ; Mon, 4 Apr 2005 09:31:04 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIRdP-00029q-8i for ltru@lists.ietf.org; Mon, 04 Apr 2005 15:28:55 +0200 Received: from c-134-88-60.hh.dial.de.ignite.net ([62.134.88.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 15:28:55 +0200 Received: from nobody by c-134-88-60.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 15:28:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 04 Apr 2005 15:27:51 +0200 Organization: Lines: 27 Message-ID: <425140D7.62E@xyzzy.claranet.de> References: <20050403103606.VJUH4900.mta8.adelphia.net@megatron.ietf.org> <00a001c5386f$a29dc0e0$030aa8c0@DEWELL> 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: c-134-88-60.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > Did we have consensus on default script? No. We only have "consensus" that the language is at the left end of a tag, and therefore it cannot have any "prefix". If we'd later want to do anything with this field for language tags, then "prefix" is much better than "recommended_prefix". We could say en with "prefix" en-Latn, interpreted as default script. We can't say en with "prefix" Latn, because Latn is no prefix. > If default script is going to be in the registry, its > behavior needs to be specified in the draft and in the > matching draft Yes. But so far there is no matching draft, and the subject of the corresponding thread was "preparations for smart matching". OTOH changing all "Prefix" to "Related" later (if necessary) would be only a minor point before the "last call" of the draft registry and registry draft. Only changing this later would be a bad idea. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 09:49:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07994; Mon, 4 Apr 2005 09:49:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIS5R-0005vV-0d; Mon, 04 Apr 2005 09:57:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIRx1-0005UD-Ck; Mon, 04 Apr 2005 09:49:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIRwz-0005U8-Vk for ltru@megatron.ietf.org; Mon, 04 Apr 2005 09:49:10 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07941 for ; Mon, 4 Apr 2005 09:49:08 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIRsN-0004nC-4n for ltru@lists.ietf.org; Mon, 04 Apr 2005 15:44:23 +0200 Received: from c-134-88-60.hh.dial.de.ignite.net ([62.134.88.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 15:44:23 +0200 Received: from nobody by c-134-88-60.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 15:44:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 04 Apr 2005 15:43:22 +0200 Organization: Lines: 18 Message-ID: <4251447A.6AF7@xyzzy.claranet.de> References: <200504030855.j338tOLO011572@smtp-los02.proxy.aol.com> <009401c5386c$dd99e140$030aa8c0@DEWELL> 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: c-134-88-60.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Doug Ewell wrote: >> I am also including a date field for "last updated" > That is what our existing "Date" field is for. Having both could make sense, date of introduction and date of last update. Some "whois" databases do it this way. For a case like i-klingon the LTRU registry could give the date of the registration, and later the date of the deprecation. At the moment i-klingon is still an officially registered tag. Probably it's different from tlh, with Klingons you never know, maybe they have more than one language. ;-) No, I've not yet asked IANA why they stopped to maintain the old 3066-registry. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 11:42:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19735; Mon, 4 Apr 2005 11:42:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITqU-0003Mj-4x; Mon, 04 Apr 2005 11:50:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIThu-0007pS-L5; Mon, 04 Apr 2005 11:41:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITht-0007pL-KG for ltru@megatron.ietf.org; Mon, 04 Apr 2005 11:41:41 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19645 for ; Mon, 4 Apr 2005 11:41:38 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050404154109.BIMQ2192.mta9.adelphia.net@DEWELL> for ; Mon, 4 Apr 2005 11:41:09 -0400 Message-ID: <004c01c5392c$b2b0c280$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 4 Apr 2005 08:40:57 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> If default script is going to be in the registry, its >> behavior needs to be specified in the draft and in the >> matching draft > > Yes. But so far there is no matching draft, and the subject of > the corresponding thread was "preparations for smart matching". The thread titled "Preparations for smart matching" was started on March 19 by Frank Ellermann, to introduce the idea of adding "default script." > OTOH changing all "Prefix" to "Related" later (if necessary) > would be only a minor point before the "last call" of the draft > registry and registry draft. Only changing this later would be > a bad idea. Changing the name of something *so that* it can be used for a different, or expanded, purpose is not a good way to design standards or protocols. We could call the field "Frank" and it would have no impact on the things we could do with that field. A better approach is to determine first what the entity should do, and then name it accordingly. In other words, we should (or should not) add the "default script" mappings based on an agreement that it is (or is not) a good thing, not because the name of the field appears to permit it. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 11:48:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20326; Mon, 4 Apr 2005 11:48:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DITw6-0003aA-Iy; Mon, 04 Apr 2005 11:56:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITo4-0008R3-JX; Mon, 04 Apr 2005 11:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITo4-0008Qy-5q for ltru@megatron.ietf.org; Mon, 04 Apr 2005 11:48:04 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20323 for ; Mon, 4 Apr 2005 11:48:01 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050404154732.OWEA4618.mta13.adelphia.net@DEWELL> for ; Mon, 4 Apr 2005 11:47:32 -0400 Message-ID: <004f01c5392d$96b541e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 4 Apr 2005 08:47:20 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Date of deprecation (was: Re: Registry in record-jar format) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Mark Davis wrote: > If it is worth putting in a comment for every instance, it is worth > making it a field, because then it can be parsed. Similarly, Frank Ellermann wrote: > Having both could make sense, date of introduction and date of > last update. Some "whois" databases do it this way. I know it would be physically possible to add these additional date fields. My question was, what is the benefit for language tagging? How are these fields to be used in practice? There have already been complaints about the size of the registry (maybe not now, but once the ISO 639-3 codes are added). We should have a demonstrably good reason for adding more stuff to it. > For a case like i-klingon the LTRU registry could give the date of > the registration, and later the date of the deprecation. At > the moment i-klingon is still an officially registered tag. Tags that are deprecated don't become un-registered, as this seems to imply. They just have a note attached to them that says, "You shouldn't use this." -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 11:58:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21260; Mon, 4 Apr 2005 11:58:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIU5l-000454-Lc; Mon, 04 Apr 2005 12:06:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITxF-0000wA-Qv; Mon, 04 Apr 2005 11:57:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DITxE-0000w1-7c for ltru@megatron.ietf.org; Mon, 04 Apr 2005 11:57:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21207 for ; Mon, 4 Apr 2005 11:57:28 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIU59-00044P-Gl for ltru@ietf.org; Mon, 04 Apr 2005 12:05:44 -0400 Received: from if12m4-235.d2.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DITx9-0006T9-75; Mon, 04 Apr 2005 08:57:27 -0700 Message-Id: <6.1.2.0.2.20050404175130.042c55c0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 04 Apr 2005 17:54:05 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Date of deprecation (was: Re: Registry in record-jar format) In-Reply-To: <004f01c5392d$96b541e0$030aa8c0@DEWELL> References: <004f01c5392d$96b541e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 At 17:47 04/04/2005, Doug Ewell wrote: >There have already been complaints about the size of the registry (maybe >not now, but once the ISO 639-3 codes are added). We should have a >demonstrably good reason for adding more stuff to it. The good reason is simple. You just prove that it is easier to remove than to add. For the rest I documented it already. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 12:16:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23359; Mon, 4 Apr 2005 12:16:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUND-00052o-Lr; Mon, 04 Apr 2005 12:24:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUF0-0003N0-Ej; Mon, 04 Apr 2005 12:15:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUEy-0003LP-Qu for ltru@megatron.ietf.org; Mon, 04 Apr 2005 12:15:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23322 for ; Mon, 4 Apr 2005 12:15:50 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUMw-000520-MA for ltru@ietf.org; Mon, 04 Apr 2005 12:24:06 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 09:15:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Registry in record-jar format Date: Mon, 4 Apr 2005 09:15:38 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7981@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU3/KOUfo6i11tVRyWt8QLCZQNGBQBNL8Kw From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 04 Apr 2005 16:15:39.0618 (UTC) FILETIME=[8AE21420:01C53931] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable The Recommended Prefix field is rather tightly defined in the draft. If = we're going to change the semantics of the field, then we should discuss = exactly how, not just change the name. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: samedi 2 avril 2005 19:20 > To: ltru@ietf.org > Subject: [Ltru] Re: Registry in record-jar format >=20 > Doug Ewell wrote: >=20 > > That adds new fields "Deprecated," "Name_Changed," and > > "Former_Value," which aren't mentioned anywhere in the draft, >=20 > Maybe one new field "Comment" is better than separate fields > "Depecated" + "Name_Changed" + "Former_Value". >=20 > Please don't mention any former value like NH, if it's not more > in the registry. Don't mention CS as former value for CZ or as > former value for SK. Any "Former_Value" is like a pointer to a > deprecated tag, the inverse of "Canonical". This won't work in > a case like the old CS. >=20 > > I've changed "Canonical_Value" to "Canonical" and > > "Recommended_Prefix" to "Prefix," >=20 > I like it. I'd like "Related" instead of "Prefix" even better, > if that's the way to get a "default script" for some languages. > Otherwise "Prefix" is fine. >=20 > Do we need the "redundant" entries ? As the name says they are > really redundant. > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 12:20:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23747; Mon, 4 Apr 2005 12:20:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUR3-0005QF-Ee; Mon, 04 Apr 2005 12:28:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUHy-0003hK-CC; Mon, 04 Apr 2005 12:18:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUHx-0003hF-9q for ltru@megatron.ietf.org; Mon, 04 Apr 2005 12:18:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23602 for ; Mon, 4 Apr 2005 12:18:55 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUPu-0005CE-Mu for ltru@ietf.org; Mon, 04 Apr 2005 12:27:12 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 09:18:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Proposed changes to region subtags (incorporating"wiskey") Date: Mon, 4 Apr 2005 09:18:45 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7987@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed changes to region subtags (incorporating"wiskey") Thread-Index: AcU4bi8awTx4qsoESeuvKpsUcPZGOQAw8QyA From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 04 Apr 2005 16:18:46.0893 (UTC) FILETIME=[FA81F9D0:01C53931] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0814445502==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 --===============0814445502== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGFncmVlZC4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxp emF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25h bGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5v dCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFpbHRv Omx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIERvdWcgRXdlbGwN Cj4gU2VudDogZGltYW5jaGUgMyBhdnJpbCAyMDA1IDA5OjUxDQo+IFRvOiBMVFJVIFdvcmtpbmcg R3JvdXANCj4gU3ViamVjdDogW0x0cnVdIFJlOiBQcm9wb3NlZCBjaGFuZ2VzIHRvIHJlZ2lvbiBz dWJ0YWdzDQo+IChpbmNvcnBvcmF0aW5nIndpc2tleSIpDQo+IA0KPiBKRkMgKEplZnNleSkgTW9y ZmluIDxqZWZzZXkgYXQgamVmc2V5IGRvdCBjb20+IHdyb3RlOg0KPiANCj4gPiBXaGVuIGlzIHRo ZSBqYXIgZ29pbmcgdG8gYmUgcmVhZHk/IEkgaGF2ZSBhIG1lZXRpbmcgb24gdGhpcyBvbiBUdWVz ZGF5DQo+ID4gYW5kIHdvdWxkIGxpa2UgdG8gc2hvdyB0aGVtIGFuIGV4YW1wbGUgb3IgdHdvIG9m IHdoYXQgeW91IHByb2R1Y2VkLg0KPiANCj4gUGxlYXNlIHJlcmVhZCB3aGF0IEkgd3JvdGUgb24g VHVlc2RheSwgTWFyY2ggMjk6DQo+IA0KPiA+IEkgcHJvcG9zZSB0aGUgZm9sbG93aW5nIGNoYW5n ZXMgdG8gdGhlIHJlZ2lvbiBzdWJ0YWdzLiAgSSdkIGxpa2UgdG8NCj4gPiBzZWUgaWYgd2UgY2Fu IHJlYWNoIGEgcm91Z2ggY29uc2Vuc3VzIG9uIHRoZXNlIGl0ZW1zIGJ5IG5leHQNCj4gPiBXZWRu ZXNkYXksIEFwcmlsIDYsIGF0IHdoaWNoIHBvaW50IEkgd2lsbCBmbG9hdCBhIG5ldyB2ZXJzaW9u IG9mIHRoZQ0KPiA+IHJlZ2lzdHJ5LCBhcyB3ZWxsIGFzIGNvbXBsZXRlIHN0ZXAtYnktc3RlcCBp bnN0cnVjdGlvbnMgZm9yIHBvcHVsYXRpbmcNCj4gPiBhbGwgcGFydHMgb2YgdGhlIHJlZ2lzdHJ5 Lg0KPiANCj4gVGhlIGdvYWwgd2FzIHRvIGFsbG93IGV2ZXJ5b25lIGEgd2VlayB0byByZXZpZXcg dGhlIHByb3Bvc2VkIGNoYW5nZXMuDQo+IFNvIGZhciwgTWFyayBhbmQgUGV0ZXIgaGF2ZSBhZ3Jl ZWQsIGFuZCBwZXJoYXBzIEFkZGlzb24gYW5kIEpvaG4gdG9vDQo+IChiYXNlZCBvbiByZXNwb25z ZXMgdG8gYSBkaWZmZXJlbnQgbWVzc2FnZSksIGFuZCBGcmFuayBoYXMgYWdyZWVkIHdpdGgNCj4g dGhlIHByb3Zpc28gdGhhdCBtb3JlIHJ1bGVzIGNvdWxkIGJlIGFkZGVkIGxhdGVyLiAgTm9ib2R5 IHNvIGZhciBoYXMNCj4gZXhwbGljaXRseSBkaXNhcHByb3ZlZC4NCj4gDQo+IElmIHlvdSBuZWVk IHNvbWUgZXhhbXBsZXMgZm9yIFR1ZXNkYXksIG15IG1lc3NhZ2Ugb2YgU2F0dXJkYXksIEFwcmls IDINCj4gYXQgMjo1OCBpbmNsdWRlcyBhbiBleGFtcGxlIG9mIHRoZSBkYXRlIHJlY29yZCAobm90 IHZlcnkgaW5mb3JtYXRpdmUpDQo+IGFuZCB0d28gbGFuZ3VhZ2UgcmVjb3Jkcy4gIFRoZXJlIGFy ZSBubyBleGFtcGxlcyB5ZXQgb2YgdGhlIGZpZWxkcw0KPiAiRGVwcmVjYXRlZCwiICJOYW1lX0No YW5nZWQsIiBhbmQgIkZvcm1lcl9WYWx1ZSIgYmVjYXVzZSB0aG9zZSBhcmUgc3RpbGwNCj4gYmVp bmcgZGViYXRlZCwgYW5kIGJlY2F1c2UgdGhleSBhcmUgbm90IGF1dGhvcml6ZWQgaW4gYW55IGRy YWZ0Lg0KPiANCj4gLURvdWcgRXdlbGwNCj4gIEZ1bGxlcnRvbiwgQ2FsaWZvcm5pYQ0KPiAgaHR0 cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiANCj4gDQo+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5n IGxpc3QNCj4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --===============0814445502== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0814445502==-- From ltru-bounces@ietf.org Mon Apr 4 12:23:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24035; Mon, 4 Apr 2005 12:23:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUUc-0005VN-F3; Mon, 04 Apr 2005 12:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUKz-0003rJ-HA; Mon, 04 Apr 2005 12:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUKy-0003rA-Eg for ltru@megatron.ietf.org; Mon, 04 Apr 2005 12:22:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23908 for ; Mon, 4 Apr 2005 12:22:02 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUSw-0005Sf-S7 for ltru@ietf.org; Mon, 04 Apr 2005 12:30:19 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 09:21:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Registry in record-jar format Date: Mon, 4 Apr 2005 09:21:54 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7991@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU4b/yXIj7LBehTRxuF5G3nMNWEegAwlltg From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 04 Apr 2005 16:21:55.0129 (UTC) FILETIME=[6AB48290:01C53932] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0743236485==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 --===============0743236485== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBvcHBvc2UgZGVmYXVsdCBzY3JpcHQsIGFzIGRvLCBJIGJlbGlldmUsIGEgbnVtYmVyIG9mIG90 aGVycywgYXMgdW53b3JrYWJsZSBpbiBwcmFjdGljZS4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAu IFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWly LCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0 aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0 cy5pZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVo YWxmIE9mIERvdWcgRXdlbGwNCj4gU2VudDogZGltYW5jaGUgMyBhdnJpbCAyMDA1IDEwOjA4DQo+ IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogW0x0cnVdIFJlOiBSZWdpc3RyeSBp biByZWNvcmQtamFyIGZvcm1hdA0KPiANCj4gRnJhbmsgRWxsZXJtYW5uIDxub2JvZHkgYXQgeHl6 enkgZG90IGNsYXJhbmV0IGRvdCBkZT4gd3JvdGU6DQo+IA0KPiA+PiBJJ3ZlIGNoYW5nZWQgIkNh bm9uaWNhbF9WYWx1ZSIgdG8gIkNhbm9uaWNhbCIgYW5kDQo+ID4+ICJSZWNvbW1lbmRlZF9QcmVm aXgiIHRvICJQcmVmaXgsIg0KPiA+DQo+ID4gSSBsaWtlIGl0LiAgSSdkIGxpa2UgIlJlbGF0ZWQi IGluc3RlYWQgb2YgIlByZWZpeCIgZXZlbiBiZXR0ZXIsDQo+ID4gaWYgdGhhdCdzIHRoZSB3YXkg dG8gZ2V0IGEgImRlZmF1bHQgc2NyaXB0IiBmb3Igc29tZSBsYW5ndWFnZXMuDQo+ID4gT3RoZXJ3 aXNlICJQcmVmaXgiIGlzIGZpbmUuDQo+IA0KPiBEaWQgd2UgaGF2ZSBjb25zZW5zdXMgb24gZGVm YXVsdCBzY3JpcHQ/ICBJIHJlbWVtYmVyIGEgbG90IG9mDQo+IGRpc2N1c3Npb24sIGJ1dCBubyBh Z3JlZW1lbnQuDQo+IA0KPiBJZiBkZWZhdWx0IHNjcmlwdCBpcyBnb2luZyB0byBiZSBpbiB0aGUg cmVnaXN0cnksIGl0cyBiZWhhdmlvciBuZWVkcyB0bw0KPiBiZSBzcGVjaWZpZWQgaW4gdGhlIGRy YWZ0IGFuZCBpbiB0aGUgbWF0Y2hpbmcgZHJhZnQsIGFuZCBzb21lb25lIG5lZWRzDQo+IHRvIGRv IHRoZSBleHBlcnQgd29yayBvZiBkZWNpZGluZyB3aGljaCBsYW5ndWFnZXMgaGF2ZSBhICJkZWZh dWx0Ig0KPiBzY3JpcHQgYW5kIHdoaWNoIGRvIG5vdC4NCj4gDQo+ID4gRG8gd2UgbmVlZCB0aGUg InJlZHVuZGFudCIgZW50cmllcyA/ICBBcyB0aGUgbmFtZSBzYXlzIHRoZXkgYXJlDQo+ID4gcmVh bGx5IHJlZHVuZGFudC4NCj4gDQo+IEknbSBub3Qgc3VyZS4gIEkgZG9uJ3QgdXNlIHRoZW0gbXlz ZWxmLCBleGNlcHQgYXMgYW4gaW5mb3JtYXRpdmUgbm90ZSBpbg0KPiBteSB2YWxpZGF0b3IsIGFz IHNob3duIHdpdGggZXhhbXBsZSAiemgtSGFucyI6DQo+IA0KPiA+IFN1YnRhZyAxOiB6aA0KPiA+ IExhbmd1YWdlIHN1YnRhZzogQ2hpbmVzZSAocmVnaXN0ZXJlZCAyMDA0LTA3LTA2KQ0KPiA+DQo+ ID4gU3VidGFnIDI6IEhhbnMNCj4gPiBTY3JpcHQgc3VidGFnOiBIYW4gKFNpbXBsaWZpZWQgdmFy aWFudCkgKHJlZ2lzdGVyZWQgMjAwNC0wNy0wNikNCj4gPg0KPiA+IFJGQyAzMDY2IHJlZ2lzdGVy ZWQgZGVzY3JpcHRpb246IHNpbXBsaWZpZWQgQ2hpbmVzZSAocmVnaXN0ZXJlZA0KPiA+IDIwMDMt MDUtMzApDQo+IA0KPiAtRG91ZyBFd2VsbA0KPiAgRnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+ICBo dHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvDQo+IA0KPiANCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBs aXN0DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbHRydQ0KDQo= --===============0743236485== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0743236485==-- From ltru-bounces@ietf.org Mon Apr 4 12:24:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24169; Mon, 4 Apr 2005 12:24:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUVB-0005We-QY; Mon, 04 Apr 2005 12:32:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUKC-0003o8-4x; Mon, 04 Apr 2005 12:21:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUKB-0003o3-Ak for ltru@megatron.ietf.org; Mon, 04 Apr 2005 12:21:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23833 for ; Mon, 4 Apr 2005 12:21:13 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUS9-0005RO-Nb for ltru@ietf.org; Mon, 04 Apr 2005 12:29:29 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 09:21:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Registry in RDF/XML format. Date: Mon, 4 Apr 2005 09:21:05 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7990@irvmbxw01.quest.com> Thread-Topic: [Ltru] Registry in RDF/XML format. Thread-Index: AcU4btEVSdDqh5iaT9K/OirkPA9RlAAwzQzg From: "Addison Phillips" To: "Jon Hanna" , "LTRU Working Group" X-OriginalArrivalTime: 04 Apr 2005 16:21:05.0882 (UTC) FILETIME=[4D5A03A0:01C53932] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1742066516==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --===============1742066516== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIGJ1dCB5b3UgYW5kIEkgYXJlIGN1cnJlbnRseSB0aGUgb25seSBzdXBwb3J0ZXJzIG9mIGl0 LCBzbyBpdCBpcyB1bmxpa2VseSB0byBtYWtlIHRoZSBuZXh0IGRyYWZ0LiBBdCB0aGlzIHBvaW50 IEkgc3VzcGVjdCB0aGF0IGl0IGNvdWxkIGJlIGRlZmluZWQgaW4gYSBmdXR1cmUgZHJhZnQgYXMg YW4gYW5jaWxsYXJ5IGZvcm1hdCAodG8gdGhlIG9mZmljaWFsIHJlZ2lzdHJ5IGluIHJlY29yZC1q YXIgZm9ybWF0KS4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0 aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6 YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBh IGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFpbHRvOmx0 cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIEpvbiBIYW5uYQ0KPiBT ZW50OiBkaW1hbmNoZSAzIGF2cmlsIDIwMDUgMTA6MDINCj4gVG86ICdMVFJVIFdvcmtpbmcgR3Jv dXAnDQo+IFN1YmplY3Q6IFtMdHJ1XSBSZWdpc3RyeSBpbiBSREYvWE1MIGZvcm1hdC4NCj4gDQo+ IEhpLCBJJ3ZlIG9ubHkgYmFyZWx5IGJlZW4gYWJsZSB0byBrZWVwIHVwIHdpdGggdGhpcyBsaXN0 IG9mIGxhdGUgZHVlIHRvDQo+IG90aGVyIG9ibGlnYXRpb25zLCBidXQgaXMgYW4gUkRGL1hNTCBm b3JtYXQgY29tcGxldGVseSBvdXQgb2YgdGhlIHF1ZXN0aW9uPw0KPiANCj4gUmVnYXJkcywNCj4g Sm9uIEhhbm5hDQo+IFdvcms6IDxodHRwOi8vd3d3LnNlbGtpZXdlYi5jb20vPg0KPiBQbGF5OiA8 aHR0cDovL3d3dy5oYWNrY3JhZnQubmV0Lz4NCj4gQ2hhdDogPGlyYzovL2lyYy5mcmVlbm9kZS5u ZXQvc2Vsa2llPg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQo= --===============1742066516== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1742066516==-- From ltru-bounces@ietf.org Mon Apr 4 12:27:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24572; Mon, 4 Apr 2005 12:27:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUXv-0005i4-DG; Mon, 04 Apr 2005 12:35:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUPq-0004gM-UD; Mon, 04 Apr 2005 12:27:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIUPn-0004eS-Io for ltru@megatron.ietf.org; Mon, 04 Apr 2005 12:27:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24553 for ; Mon, 4 Apr 2005 12:27:01 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUXl-0005hN-0R for ltru@ietf.org; Mon, 04 Apr 2005 12:35:18 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 09:26:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Registry in record-jar format Date: Mon, 4 Apr 2005 09:26:52 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7998@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU4iLlOqO9UUZW0QPCXMBtA1BBWeAAqjAeg From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 04 Apr 2005 16:26:53.0348 (UTC) FILETIME=[1C751E40:01C53933] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0168057108==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da --===============0168057108== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UkVHSVNURVJFRCB0YWdzIGZyb20gdGhlIFJGQyAzMDY2IHJlZ2lzdHJ5IHRoYXQgYXJlIGRlcHJl Y2F0ZWQgd2lsbCBiZSBtYWludGFpbmVkIGFzIGdyYW5kZmF0aGVyZWQgZW50cmllcy4NCg0KVGhl IGN1cnJlbnQgdGV4dCB3YXMgYWRkZWQgaW4gdGhlIGN1cnJlbnQgZHJhZnQgdG8gcHJldmVudCB0 aGUgdmFyaWFudCBzdWJ0YWcgJ2xvamJhbicuIEFkZGluZyB0aGUgd29yZCBpbiBjYXBzIGFib3Zl IHdvdWxkIGZpeCB0aGF0LCBJIGJlbGlldmUuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGls bGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzND IEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFs aXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0 Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBP ZiBEb3VnIEV3ZWxsDQo+IFNlbnQ6IGRpbWFuY2hlIDMgYXZyaWwgMjAwNSAxMjo1OQ0KPiBUbzog TFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFtMdHJ1XSBSZTogUmVnaXN0cnkgaW4gcmVj b3JkLWphciBmb3JtYXQNCj4gDQo+IE1hcmsgRGF2aXMgPG1hcmsgZG90IGRhdmlzIGF0IGp0Y3N2 IGRvdCBjb20+IHdyb3RlOg0KPiANCj4gPj4+IERvIHdlIG5lZWQgdGhlICJyZWR1bmRhbnQiIGVu dHJpZXMgPyAgQXMgdGhlIG5hbWUgc2F5cyB0aGV5IGFyZQ0KPiA+Pj4gcmVhbGx5IHJlZHVuZGFu dC4NCj4gPg0KPiA+IEkgZG9uJ3QgY2FyZSBtdWNoIGVpdGhlciB3YXkuIFdoYXQgSSB3YXMgc2F5 aW5nIGluIG15IG5vdGUgdGhhdCB0aGUNCj4gPiByZWR1bmRhbnQgKmNvbW1lbnRzKiBvbiB0aGUg cmVkdW5kYW50IHJlY29yZHMgd2VyZSwgd2VsbCwgcmVkdW5kYW50Lg0KPiANCj4gSSBkb24ndCBs aWtlIHRoZW0gZWl0aGVyLiAgSSB0aG91Z2h0IHRoZXJlIHdhcyBhIHN0YXRlbWVudCBpbiB0aGUg ZHJhZnQNCj4gdGhhdCAicmVkdW5kYW50IiBlbnRyaWVzIGhhZCB0byBoYXZlIHN1Y2ggYSBjb21t ZW50LiAgTWF5YmUgaXQgaGFzIHRvIGRvDQo+IHdpdGggdGhlIHBhc3NhZ2UgaW4gQXBwZW5kaXgg QyB0aGF0IGdyYW5kZmF0aGVyZWQgZW50cmllcyBoYXZlIHRvIGhhdmUgYQ0KPiBjb21tZW50ICJp bmRpY2F0aW5nLi4uIFt0aGVdIHJlYXNvbiBmb3IgdGhlIGRlcHJlY2F0aW9uLiIgIE1heWJlIGl0 IHdhcw0KPiBwYXJ0IG9mIGEgZGlzY3Vzc2lvbiBtb250aHMgYWdvLiAgTWF5YmUgSSBqdXN0IGRy ZWFtZWQgaXQuDQo+IA0KPiBJbiBhbnkgY2FzZSwgSSdtIGhhcHB5IHRvIHJlbW92ZSB0aGUgcmVk dW5kYW50IGNvbW1lbnRzIChhbWJpZ3VpdHkNCj4gaW50ZW5kZWQpIGlmIGl0J3MgT0sgd2l0aCBl dmVyeW9uZSBlbHNlLg0KPiANCj4gQlRXLCB0aGF0IHdob2xlIHBhcmFncmFwaCBpbiBBcHBlbmRp eCBDIGlzIGNvbmZ1c2luZyB0byBtZToNCj4gDQo+ICJUYWdzIHRoYXQgYXJlIGN1cnJlbnRseSBk ZXByZWNhdGVkIHdpbGwgYmUgbWFpbnRhaW5lZCBhcyBncmFuZGZhdGhlcmVkDQo+IGVudHJpZXMu IFRoZSByZWNvcmQgZm9yIHRoZSBncmFuZGZhdGhlcmVkIGVudHJ5IHdpbGwgY29udGFpbiBhIG5v dGUNCj4gaW5kaWNhdGluZyB0aGF0IHRoZSBlbnRyeSBpcyAnZGVwcmVjYXRlZCcgYW5kIHJlYXNv biBmb3IgdGhlDQo+IGRlcHJlY2F0aW9uLiBGb3IgZXhhbXBsZSwgdGhlIHRhZyAiYXJ0LWxvamJh biIgaXMgZGVwcmVjYXRlZCBhbmQgd2lsbCBiZQ0KPiBwbGFjZWQgaW4gdGhlIGdyYW5kZmF0aGVy ZWQgc2VjdGlvbi4iDQo+IA0KPiBUaGVyZSBpcyBubyBpbnRyaW5zaWMgcmVsYXRpb25zaGlwIGJl dHdlZW4gZ3JhbmRmYXRoZXJlZCBhbmQgZGVwcmVjYXRlZC4NCj4gVGhlIHRhZyAiaS1hbWkiIGlz IGdyYW5kZmF0aGVyZWQgYnV0IG5vdCBkZXByZWNhdGVkLCB3aGlsZSB0aGUgdGFnICJpbiINCj4g aXMgZGVwcmVjYXRlZCBidXQgbm90IGdyYW5kZmF0aGVyZWQuICBPbmx5IDI4JSBvZiB0aGUgZ3Jh bmRmYXRoZXJlZCB0YWdzDQo+IGFyZSBkZXByZWNhdGVkLCBhbmQgaW4gZmFjdCBub25lIHdlcmUg dW50aWwgd2UgYWRkZWQgdGhlIGxvbmctbWlzc2luZw0KPiBwcm92aXNpb24gdG8gZ2l2ZSB0aGVt IGEgd2hvbGUtdGFnIGNhbm9uaWNhbCB2YWx1ZS4NCj4gDQo+IC1Eb3VnIEV3ZWxsDQo+ICBGdWxs ZXJ0b24sIENhbGlmb3JuaWENCj4gIGh0dHA6Ly91c2Vycy5hZGVscGhpYS5uZXQvfmRld2VsbC8N Cj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiBodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --===============0168057108== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0168057108==-- From ltru-bounces@ietf.org Mon Apr 4 12:29:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24815; Mon, 4 Apr 2005 12:29:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUZx-0005wh-1G; Mon, 04 Apr 2005 12:37:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIURa-00057h-N9; Mon, 04 Apr 2005 12:28:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIURZ-00057c-8s for ltru@megatron.ietf.org; Mon, 04 Apr 2005 12:28:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24782 for ; Mon, 4 Apr 2005 12:28:51 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIUZW-0005wO-HN for ltru@ietf.org; Mon, 04 Apr 2005 12:37:08 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 09:28:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Date of deprecation (was: Re: Registry in record-jar format) Date: Mon, 4 Apr 2005 09:28:40 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE79A3@irvmbxw01.quest.com> Thread-Topic: [Ltru] Date of deprecation (was: Re: Registry in record-jar format) Thread-Index: AcU4mBbw4WgPQNalTSGs8N67NutRUAAmxapQ From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 04 Apr 2005 16:28:40.0897 (UTC) FILETIME=[5C8FCB10:01C53933] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1636510792==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --===============1636510792== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tcGF0aWJpbGl0eS4gWW91IGNhbiBzZXQgeW91ciB0YWcgcHJvY2Vzc29yIHRvIHByb2R1Y2Ug b3IgdmFsaWRhdGUgdGFncyBhcyBhdCBhIGNlcnRhaW4gZGF0ZS4gSXQgYWxzbyBtaWdodCBoZWxw IHBlb3BsZSB1cGRhdGluZyB0aGVpciBpbXBsZW1lbnRhdGlvbiBmaWd1cmUgb3V0IHdoYXQgaGFz IGNoYW5nZWQgc2luY2UgdGhlIGxhc3QgdGltZSB0aGV5IGxvb2tlZCAoc2luY2UgYWxsIG9mIHRo ZSBpbmZvcm1hdGlvbiBpcyBpbiB0aGUgcmVnaXN0cnkpLg0KDQpBZGRpc29uDQoNCkFkZGlzb24g UC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hh aXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJu YXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4g DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGxp c3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnXSBPbg0KPiBC ZWhhbGYgT2YgRG91ZyBFd2VsbA0KPiBTZW50OiBkaW1hbmNoZSAzIGF2cmlsIDIwMDUgMTQ6NTMN Cj4gVG86IExUUlUgV29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBbTHRydV0gRGF0ZSBvZiBkZXBy ZWNhdGlvbiAod2FzOiBSZTogUmVnaXN0cnkgaW4gcmVjb3JkLWphcg0KPiBmb3JtYXQpDQo+IA0K PiBXaGF0IGlzIHRoZSBwZXJjZWl2ZWQgYmVuZWZpdCwgZm9yIGxhbmd1YWdlIHRhZ2dpbmcgcHVy cG9zZXMsIG9mDQo+IGluY2x1ZGluZyBhIGZpZWxkIHRoYXQgaW5kaWNhdGVzIHRoZSBkYXRlIGEg Z2l2ZW4gc3VidGFnIHdhcyBkZXByZWNhdGVkPw0KPiANCj4gLURvdWcgRXdlbGwNCj4gIEZ1bGxl cnRvbiwgQ2FsaWZvcm5pYQ0KPiAgaHR0cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0K PiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+IGh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg0K --===============1636510792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1636510792==-- From ltru-bounces@ietf.org Mon Apr 4 13:15:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00355; Mon, 4 Apr 2005 13:15:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIVIV-00006Y-7c; Mon, 04 Apr 2005 13:23:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIV9z-0002NU-I8; Mon, 04 Apr 2005 13:14:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIV9x-0002M2-L3 for ltru@megatron.ietf.org; Mon, 04 Apr 2005 13:14:46 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00241 for ; Mon, 4 Apr 2005 13:14:42 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIV75-0007J2-Tc for ltru@lists.ietf.org; Mon, 04 Apr 2005 19:11:47 +0200 Received: from 212.82.251.116 ([212.82.251.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 19:11:47 +0200 Received: from nobody by 212.82.251.116 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 19:11:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 04 Apr 2005 19:11:57 +0200 Organization: Lines: 27 Message-ID: <4251755D.122@xyzzy.claranet.de> References: <004f01c5392d$96b541e0$030aa8c0@DEWELL> 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.116 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Date of deprecation (was: Re: Registry in record-jar format) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > My question was, what is the benefit for language tagging? It could help to figure out what happened when and why. I've no idea how important this is for language tags, but I'm sure that I like it in "whois" entries. > There have already been complaints about the size of the > registry (maybe not now, but once the ISO 639-3 codes are > added). And some possible solutions, like an A..Z organization. Scott said that IANA won't try to be smart unless we tell them what to do (or that's how I interpreted his remark). If the size is a problem, then the number of 7000+ entries is the key, the size of individual entries is secondary. [ Is this use of "secondary" en-DE or still en ? ;-) ] >> i-klingon is still an officially registered tag. > Tags that are deprecated don't become un-registered Yes, sorry, I meant "officially undeprecated tag". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 14:04:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05592; Mon, 4 Apr 2005 14:04:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIW3r-000385-2L; Mon, 04 Apr 2005 14:12:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIVkn-0007nt-7j; Mon, 04 Apr 2005 13:52:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIVkm-0007nk-B8 for ltru@megatron.ietf.org; Mon, 04 Apr 2005 13:52:48 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04508 for ; Mon, 4 Apr 2005 13:52:47 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIVhn-0004f7-8U for ltru@lists.ietf.org; Mon, 04 Apr 2005 19:49:43 +0200 Received: from 212.82.251.116 ([212.82.251.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 19:49:43 +0200 Received: from nobody by 212.82.251.116 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 19:49:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 04 Apr 2005 19:49:01 +0200 Organization: Lines: 48 Message-ID: <42517E0D.EF2@xyzzy.claranet.de> References: <004c01c5392c$b2b0c280$030aa8c0@DEWELL> 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.116 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > The thread titled "Preparations for smart matching" was > started on March 19 by Frank Ellermann, to introduce the > idea of adding "default script." Yes, and it's impossible to come to a final conclusion "now" (like say today), because there is no "smart matching draft". At the moment I only _think_ that default scripts are a MUST HAVE, because otherwise en-Latn-GB-scouse, en-GB-scouse, en-Latn-scouse, and en-scouse could run into trouble if they don't match each other. Maybe I'm wrong and this only breaks RTL matching. Maybe it causes major havoc for all Web servers and browsers. I don't know before I see the matching draft. > A better approach is to determine first what the entity > should do, and then name it accordingly. I want it to be used for the default script, because otherwise we might create a "language tag soup" and no way to match them except from a few trivial cases, where RfC 3066 is good enough or even better than RfC 3066bis. A viable alternative is a RECOMMENDATION to never omit the script or the region in tags with a variant. I hope that the matching draft proposes a better way, but at the moment some kind of "default script" is the only solution I see, and the "prefix" field of languages is the only place to add this info. > In other words, we should (or should not) add the "default > script" mappings based on an agreement that it is (or is > not) a good thing, not because the name of the field appears > to permit it. You can't decide this before the real issue (= "matching") is clear. That's like discussing cut-off dates together with the language tags (where it's mostly irrelevant) before the strange side-effect for region codes are visible. Let's just see a new state of the art. There have been so many changes from the "ABNF" over "record-jar" to the "normative references" that I lost track. It's only an I-D, not the last chance to get it right. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 14:11:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07306; Mon, 4 Apr 2005 14:11:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIWB7-0003ub-KD; Mon, 04 Apr 2005 14:20:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIVxF-0000ob-8g; Mon, 04 Apr 2005 14:05:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIVxE-0000oO-0T; Mon, 04 Apr 2005 14:05:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05960; Mon, 4 Apr 2005 14:05:39 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIW5D-0003Eq-Bg; Mon, 04 Apr 2005 14:13:55 -0400 Received: from h-68-166-189-216.snvacaid.dynamic.covad.net ([68.166.189.216] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DIVxB-0003hP-00; Mon, 04 Apr 2005 11:05:37 -0700 Message-ID: <002e01c53941$1340d2c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" , "Disman" Date: Mon, 4 Apr 2005 11:06:50 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Ltru] Fw: Enforcement of Updated IPR Boilerplate X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Hi - Anyone submitting or planning to submit internet drafts, please take note! > From: "IETF Secretariat" > To: "IETF Announcement list" > Cc: ; ; > Sent: Monday, April 04, 2005 10:05 AM > Subject: Enforcement of Updated IPR Boilerplate > > As you may be aware, RFC 3667 (BCP 78), "IETF Rights in Contributions," > has been obsoleted by RFC 3978 (BCP 78), which was published in March > 2005, and which bears the same title. The major difference between the > two RFCs is that the IPR-related notices and disclaimers that the IETF > requires in all Internet-Drafts have been updated to correct anomalies. > > The updated versions of the required notices and disclaimers are specified > in Section 5, "Notices Required in IETF Documents," of RFC 3978, and in > Section 3, "IPR-Related Notices Required in Internet-Drafts," of the > recently revised "Guidelines to Authors of Internet-Drafts" > (http://www.ietf.org/ietf/1id-guidelines.html). The "Guidelines" document > also provides additional guidance regarding the placement of these notices. > > Currently, the IETF Secretariat accepts and posts Internet-Drafts that > include *either* the RFC 3667 or the RFC 3978 version of these notices. > However, as of 17:00 ET on Friday May 6, 2005, the Secretariat will > accept *only* those Internet-Drafts that comply with the requirements > of RFC 3978, and with the most recent version of the "Guidelines" > document. > > Please note that the required notices and disclaimers must be reproduced > verbatim since they have been legally reviewed and formally adopted as part > of the IETF process. The Secretariat will not accept deviations from the > specified text, nor will it correct the text. Any documents that do not > comply with the requirements will be returned to the submitter. > > The IETF Secretariat > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 14:50:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10973; Mon, 4 Apr 2005 14:50:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIWmM-0005up-3e; Mon, 04 Apr 2005 14:58:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIWdT-0000Iz-JM; Mon, 04 Apr 2005 14:49:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIWdS-0000If-3T for ltru@megatron.ietf.org; Mon, 04 Apr 2005 14:49:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10900 for ; Mon, 4 Apr 2005 14:49:16 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIWlQ-0005hV-OY for ltru@ietf.org; Mon, 04 Apr 2005 14:57:33 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j34In3lk001023; Mon, 4 Apr 2005 14:49:03 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 4 Apr 2005 14:49:07 -0400 Date: Mon, 4 Apr 2005 14:49:06 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: Registry in record-jar format Message-ID: <20050404184906.GB7640@skunk.reutershealth.com> References: <004c01c5392c$b2b0c280$030aa8c0@DEWELL> <42517E0D.EF2@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42517E0D.EF2@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Frank Ellermann scripsit: > At the moment I only _think_ that default scripts are a MUST > HAVE, because otherwise en-Latn-GB-scouse, en-GB-scouse, > en-Latn-scouse, and en-scouse could run into trouble if they > don't match each other. > > Maybe I'm wrong and this only breaks RTL matching. Maybe it > causes major havoc for all Web servers and browsers. I don't > know before I see the matching draft. I have yet to receive any comments on my proposed alternative (not replacement) matching algorithm. People seemed to get lost in the details of Date A and Date B. To recap in a way that doesn't reawaken that: 1) Normalize the tag. 2) Create a quadruple (lang, script, region, variant), filling in missing components with *s. 3) Subtags match if they are the same or if either is "*". 4) Add {8, 4, 2, 1} to the figure of merit if the {lang, script, region, variant} matches. -- Using RELAX NG compact syntax to John Cowan develop schemas is one of the simple http://www.reutershealth.com pleasures in life.... http://www.ccil.org/~cowan --Jeni Tennison _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 15:05:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12186; Mon, 4 Apr 2005 15:05:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIX0t-0006Uo-FA; Mon, 04 Apr 2005 15:13:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIWri-00018x-61; Mon, 04 Apr 2005 15:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIWrh-00018s-Gs for ltru@megatron.ietf.org; Mon, 04 Apr 2005 15:04:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11952 for ; Mon, 4 Apr 2005 15:04:00 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIWze-0006RT-VB for ltru@ietf.org; Mon, 04 Apr 2005 15:12:17 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 12:03:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Registry in record-jar format Date: Mon, 4 Apr 2005 12:03:41 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7AF9@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU5Rx9h5kkusJTFTTK9HClbWL45zwAAONaA From: "Addison Phillips" To: "John Cowan" , "Frank Ellermann" X-OriginalArrivalTime: 04 Apr 2005 19:03:42.0238 (UTC) FILETIME=[0497CBE0:01C53949] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable I've thought about it. First a comment, then some observations. Extlang and variant can both be repeated and order is significant. Does = one variant matching from a list of variants count as "1 point" or as a = fraction? Extensions are always ignored (good). What about private use subtags? Unless you receive a "perfect" score of 15, is it a match? What do I do = with tags with a score of 14, 13, 11, 2? Finally, how is this different in practice from the "extended language = range" matching currently proposed? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: lundi 4 avril 2005 11:49 > To: Frank Ellermann > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Registry in record-jar format >=20 > Frank Ellermann scripsit: >=20 > > At the moment I only _think_ that default scripts are a MUST > > HAVE, because otherwise en-Latn-GB-scouse, en-GB-scouse, > > en-Latn-scouse, and en-scouse could run into trouble if they > > don't match each other. > > > > Maybe I'm wrong and this only breaks RTL matching. Maybe it > > causes major havoc for all Web servers and browsers. I don't > > know before I see the matching draft. >=20 > I have yet to receive any comments on my proposed alternative > (not replacement) matching algorithm. People seemed to get lost in > the details of Date A and Date B. To recap in a way that doesn't > reawaken that: >=20 > 1) Normalize the tag. >=20 > 2) Create a quadruple (lang, script, region, variant), filling in = missing > components with *s. >=20 > 3) Subtags match if they are the same or if either is "*". >=20 > 4) Add {8, 4, 2, 1} to the figure of merit if the {lang, script, = region, > variant} matches. >=20 > -- > Using RELAX NG compact syntax to John Cowan > develop schemas is one of the simple http://www.reutershealth.com > pleasures in life.... http://www.ccil.org/~cowan > --Jeni Tennison >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 15:05:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12459; Mon, 4 Apr 2005 15:05:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIX1X-0006W7-AN; Mon, 04 Apr 2005 15:14:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIWnk-00014X-Tq; Mon, 04 Apr 2005 14:59:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIWnk-00014N-1H for ltru@megatron.ietf.org; Mon, 04 Apr 2005 14:59:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11593 for ; Mon, 4 Apr 2005 14:59:54 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIWvi-0006H2-Pu for ltru@ietf.org; Mon, 04 Apr 2005 15:08:12 -0400 Received: from uknsprd1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Mon, 4 Apr 2005 18:59:38 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IEF00MNDRFEYZ@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Mon, 04 Apr 2005 19:59:38 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Mon, 04 Apr 2005 18:59:38 +0000 Date: Mon, 04 Apr 2005 19:59:37 +0100 From: Misha Wolf Subject: RE: [Ltru] Alternative matching algorithm To: ltru@ietf.org Message-id: <1987416CA83AC7499AC772F92E2DBF78036EEB7A@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Alternative matching algorithm Thread-Index: AcU5Ryan/ZCMmslAS66zIiBbOiWBawAAPhNg content-class: urn:content-classes:message X-OriginalArrivalTime: 04 Apr 2005 18:59:38.0219 (UTC) FILETIME=[732573B0:01C53948] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable John Cowan wrote: > I have yet to receive any comments on my proposed alternative > (not replacement) matching algorithm. I think it's brilliant. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 15:33:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15254; Mon, 4 Apr 2005 15:33:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIXSR-0007x3-W0; Mon, 04 Apr 2005 15:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXJE-0003Kl-GN; Mon, 04 Apr 2005 15:32:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXJD-0003Kg-MA for ltru@megatron.ietf.org; Mon, 04 Apr 2005 15:32:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15013 for ; Mon, 4 Apr 2005 15:32:26 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIXRD-0007vc-I8 for ltru@ietf.org; Mon, 04 Apr 2005 15:40:44 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 12:32:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Registry in record-jar format Date: Mon, 4 Apr 2005 12:32:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7B34@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU5QM0xfUpaHrY8Sp29Lg+zJFyccgABKfqw From: "Addison Phillips" To: X-OriginalArrivalTime: 04 Apr 2005 19:32:17.0929 (UTC) FILETIME=[03397790:01C5394D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: quoted-printable > Yes, and it's impossible to come to a final conclusion "now" > (like say today), because there is no "smart matching draft". That's not really accurate. We can debate the matching problem for 3066bis language tags without = having the matching I-D finished. The basic questions are: 1. Does the insertion of script subtags between language and region = subtags constitute a problem for matching user requests to existing = (remove-from-right [RFR]) RFC 3066 implementations? Answer: Yes, it is a problem, since users might have to specify two = ranges or may get results inconsistent with their expectations. For = example, the range "zh-TW" does not match the tag "zh-Hant-TW" using = strict 3066 matching rules. 2. Does placing the script after the region solve the problem? Answer: No, because variants also pose a positioning problem (of lower = frequency) and, more importantly, because users who need to select = content where script is more important have to know every potential = region subtag they are interested in. For example, the range "zh-Hant" = doesn't match the tag "zh-TW-Hant" using strict 3066 matching rules. Once we admit more than two subtags, you need at least extended range = matching or some requests will produce results inconsistent with user = expectations. In fact, RFC 3066 already has the subtag ordering problem. It is just = that there are relatively few registered tags that display it. Notably, = the German orthographic variations produce this exact pattern of = problem. 3. Is there a proposal to solve this? Answer: Yes. There are several. i. "Extended Range Matching" is an extension of RFR in which "missing" = subtags are considered to be (or are expanded to be) wildcards. So = "de-1901" is expanded to "de-*-*-1901" and matches "de-Latn-1901" and = "de-AT-1901", not to mention "de-Latg-NA-1901". NB> Probably we need to extend this scheme to allow users to specify = that they do NOT want a specific field to be filled in. For example = "de-!-1901" would match only "de-1901" and not a tag such as = "de-Latn-1901". ii. "Lookup" is the opposite of matching, in which subtags are removed = from the tag rather than the range (i.e. locale-style) to fill in all = slots in a dataset. This matches a very different content set. iii. "Scored Matching" was proposed by John Cowan and produces content = with a range of scores, allowing the content to be filtered by choosing = a "quality level" (my words) for the match. The user can set a threshold = for matching, presumably. The problem here is that matching cannot be as simple as it was under = RFC 3066 and still capture all possible cases. The alternatives as I see it would be: a. Force script to appear at the end of the subtag sequence, but write = new matching rules that allow processors to consider script in its more = appropriate position (after language).=20 I think this creates enormous processing issues for very little gain: = RFR matching works for existing requests, but not for new content. = Processing in cases such as CSS 2.1 or XML is greatly increased for no = apparent benefit and at the cost of more obscure tag syntax. b. Make RFC 3066bis into an extension itself (for example = "de-1901-i-Latn"). This is just "re-spelling" the problem in (a). It fixes #1 above, but = not #2 for RFR processors. c. Go with RFC 3066bis's design and Tag Content Wisely. This basically says that scripts will only be used when they contribute = something of value in the tag (or that they will be used more-or-less = universally). Users who don't adapt to this for languages (such as = Chinese or Serbian) where content will be semi-universally tagged with = scripts get inconsistent results until they adopt implementations that = use extended range or some other form of matching. Extended range = matching or scored matching may help this transition along, but isn't a = pre-requisite for forming tags. RFR works correctly for new-style ranges = and produces inconsistent results in some cases. This is the price of = transition. Again, note that any 3066bis tag can be registered under RFC 3066. When = more tags with scripts come into existence, the matching problems will = be present under RFC 3066 and with no way out for the end user. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: lundi 4 avril 2005 10:49 > To: ltru@ietf.org > Subject: [Ltru] Re: Registry in record-jar format >=20 > Doug Ewell wrote: >=20 > > The thread titled "Preparations for smart matching" was > > started on March 19 by Frank Ellermann, to introduce the > > idea of adding "default script." >=20 > Yes, and it's impossible to come to a final conclusion "now" > (like say today), because there is no "smart matching draft". >=20 > At the moment I only _think_ that default scripts are a MUST > HAVE, because otherwise en-Latn-GB-scouse, en-GB-scouse, > en-Latn-scouse, and en-scouse could run into trouble if they > don't match each other. >=20 > Maybe I'm wrong and this only breaks RTL matching. Maybe it > causes major havoc for all Web servers and browsers. I don't > know before I see the matching draft. >=20 > > A better approach is to determine first what the entity > > should do, and then name it accordingly. >=20 > I want it to be used for the default script, because otherwise > we might create a "language tag soup" and no way to match them > except from a few trivial cases, where RfC 3066 is good enough > or even better than RfC 3066bis. >=20 > A viable alternative is a RECOMMENDATION to never omit the > script or the region in tags with a variant. I hope that the > matching draft proposes a better way, but at the moment some > kind of "default script" is the only solution I see, and the > "prefix" field of languages is the only place to add this info. >=20 > > In other words, we should (or should not) add the "default > > script" mappings based on an agreement that it is (or is > > not) a good thing, not because the name of the field appears > > to permit it. >=20 > You can't decide this before the real issue (=3D "matching") is > clear. That's like discussing cut-off dates together with the > language tags (where it's mostly irrelevant) before the strange > side-effect for region codes are visible. >=20 > Let's just see a new state of the art. There have been so many > changes from the "ABNF" over "record-jar" to the "normative > references" that I lost track. It's only an I-D, not the last > chance to get it right. > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 16:16:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27596; Mon, 4 Apr 2005 16:16:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIY82-0004Wz-Fn; Mon, 04 Apr 2005 16:24:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXnD-00067o-Ai; Mon, 04 Apr 2005 16:03:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXnC-00067i-Eu for ltru@megatron.ietf.org; Mon, 04 Apr 2005 16:03:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24162 for ; Mon, 4 Apr 2005 16:03:24 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIXvC-0003AS-LJ for ltru@ietf.org; Mon, 04 Apr 2005 16:11:43 -0400 Received: from smtp-los04.proxy.aol.com (smtp-los04.proxy.aol.com [195.93.24.101]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN10-b42519d69375; Mon, 04 Apr 2005 16:02:49 -0500 Received: from DEBHOME (ACD5A91F.ipt.aol.com [172.213.169.31]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j34K2iZu021741; Mon, 4 Apr 2005 16:02:44 -0400 Message-Id: <200504042002.j34K2iZu021741@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'Frank Ellermann'" , Subject: RE: [Ltru] Re: Registry in record-jar format Date: Mon, 4 Apr 2005 21:02: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.2900.2180 Thread-Index: AcU5QL9LGMXqDjZEROqLNnYKxm1CowAD2CYg In-Reply-To: <42517E0D.EF2@xyzzy.claranet.de> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.101 X-Spam-Score: 2.6 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > At the moment I only _think_ that default scripts are a MUST HAVE, What do you -think- you would apply to the proposed 639-3 tags like "ess" Central Siberian Yupik which is written in Cyrillic script in Siberia and Latin script in Alaska? Debbie Garside www.linguasphere.com -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Frank Ellermann Sent: 04 April 2005 18:49 To: ltru@ietf.org Subject: [Ltru] Re: Registry in record-jar format Doug Ewell wrote: > The thread titled "Preparations for smart matching" was > started on March 19 by Frank Ellermann, to introduce the > idea of adding "default script." Yes, and it's impossible to come to a final conclusion "now" (like say today), because there is no "smart matching draft". At the moment I only _think_ that default scripts are a MUST HAVE, because otherwise en-Latn-GB-scouse, en-GB-scouse, en-Latn-scouse, and en-scouse could run into trouble if they don't match each other. Maybe I'm wrong and this only breaks RTL matching. Maybe it causes major havoc for all Web servers and browsers. I don't know before I see the matching draft. > A better approach is to determine first what the entity > should do, and then name it accordingly. I want it to be used for the default script, because otherwise we might create a "language tag soup" and no way to match them except from a few trivial cases, where RfC 3066 is good enough or even better than RfC 3066bis. A viable alternative is a RECOMMENDATION to never omit the script or the region in tags with a variant. I hope that the matching draft proposes a better way, but at the moment some kind of "default script" is the only solution I see, and the "prefix" field of languages is the only place to add this info. > In other words, we should (or should not) add the "default > script" mappings based on an agreement that it is (or is > not) a good thing, not because the name of the field appears > to permit it. You can't decide this before the real issue (= "matching") is clear. That's like discussing cut-off dates together with the language tags (where it's mostly irrelevant) before the strange side-effect for region codes are visible. Let's just see a new state of the art. There have been so many changes from the "ABNF" over "record-jar" to the "normative references" that I lost track. It's only an I-D, not the last chance to get it right. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 16:24:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29843; Mon, 4 Apr 2005 16:24:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIYG4-0005J2-JU; Mon, 04 Apr 2005 16:33:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIY6o-0003zz-Cr; Mon, 04 Apr 2005 16:23:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIY6m-0003zl-Vo for ltru@megatron.ietf.org; Mon, 04 Apr 2005 16:23:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29600 for ; Mon, 4 Apr 2005 16:23:39 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIYEn-0005E5-HH for ltru@ietf.org; Mon, 04 Apr 2005 16:31:57 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 13:23:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Registry in record-jar format Date: Mon, 4 Apr 2005 13:23:22 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7B87@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU5UVfTMZw29EQ4R4GWBFjb2in+owAAMxLg From: "Addison Phillips" To: "John Cowan" X-OriginalArrivalTime: 04 Apr 2005 20:23:25.0081 (UTC) FILETIME=[2763B890:01C53954] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable See below. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] > Sent: lundi 4 avril 2005 13:03 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Registry in record-jar format >=20 > Addison Phillips scripsit: >=20 > > Answer: Yes, it is a problem, since users might have to specify two > > ranges or may get results inconsistent with their expectations. For > > example, the range "zh-TW" does not match the tag "zh-Hant-TW" using > > strict 3066 matching rules. >=20 > Just a terminological note: I think these should be called HTTP or RFC > 2616 > matching rules, since RFC 2616 is the true and authoritative source = for > them. [Addison Phillips]=20 Agreed.=20 >=20 > > i. "Extended Range Matching" is an extension of RFR in which = "missing" > > subtags are considered to be (or are expanded to be) wildcards. So > > "de-1901" is expanded to "de-*-*-1901" and matches "de-Latn-1901" = and > > "de-AT-1901", not to mention "de-Latg-NA-1901". >=20 > I think this should be mentioned in the matching I-D. [Addison Phillips]=20 I believe it is, although not this specific example. See = http://www.inter-locale.com/ID/draft-ietf-ltru-matching-00.html#extrange >=20 > > NB> Probably we need to extend this scheme to allow users to specify > > that they do NOT want a specific field to be filled in. For example > > "de-!-1901" would match only "de-1901" and not a tag such as > > "de-Latn-1901". >=20 > I'd like to see a use case for this (not involving boont). [Addison Phillips]=20 Find all content in need of retagging with a script in my Traditional = Chinese document using XPath: /*@[lang=3D"zh-!-TW"] >=20 > > ii. "Lookup" is the opposite of matching, in which subtags are = removed > > from the tag rather than the range (i.e. locale-style) to fill in = all > > slots in a dataset. This matches a very different content set. >=20 > This too should be mentioned. [Addison Phillips]=20 Being added. Mark supplied text that I haven't had time to insert. >=20 > > iii. "Scored Matching" was proposed by John Cowan and produces = content > > with a range of scores, allowing the content to be filtered by = choosing > > a "quality level" (my words) for the match. The user can set a = threshold > > for matching, presumably. >=20 > As should this. [Addison Phillips]=20 Agreed.=20 >=20 > > The problem here is that matching cannot be as simple as it was = under > > RFC 3066 and still capture all possible cases. >=20 > This is badly stated. Only matching of predefined tags in RFC 3066 > captures > all cases. [Addison Phillips]=20 It is badly stated. But I'm not sure your version captures the nuances = either. Perhaps: Only generative tags in RFC 3066 (i.e. those with only two possible = subtags) are guaranteed to work with RFC 2616 defined matching. >=20 > -- > Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. > Send us, bright one, light one, Horhorn, quickening, and wombfruit. = (3x) > Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, > hoopsa! > -- Joyce, Ulysses, "Oxen of the Sun" jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 16:49:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06388; Mon, 4 Apr 2005 16:49:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIYeD-0007et-40; Mon, 04 Apr 2005 16:58:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXxq-0001Ee-FK; Mon, 04 Apr 2005 16:14:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXxo-0001D6-4E for ltru@megatron.ietf.org; Mon, 04 Apr 2005 16:14:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26978 for ; Mon, 4 Apr 2005 16:14:16 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIY5g-0004I4-O7 for ltru@ietf.org; Mon, 04 Apr 2005 16:22:35 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j34KDhM6026838; Mon, 4 Apr 2005 13:13:48 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Apr 2005 13:13:44 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Jon Hanna , LTRU Working Group Subject: RE: [Ltru] Registry in RDF/XML format. Date: Mon, 4 Apr 2005 13:13:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Hi, As long as the XML format registry is clearly labelled 'Informative' and only the one Record-Jar format registry is labelled 'Normative' (and maintained by IANA), I'd be happy to see an auxiliary XML format registry. There are clearly numerous benefits to the XML registry. One of them (the ability to use the full range of Unicode characters) is one of the strongest arguments _against_ the XML format registry as the Normative one (because it cannot be published in an initial registry RFC, which has been customary with most other new IANA registries). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Addison Phillips Sent: Monday, April 04, 2005 12:21 PM To: Jon Hanna; LTRU Working Group Subject: RE: [Ltru] Registry in RDF/XML format. No, but you and I are currently the only supporters of it, so it is unlikely to make the next draft. At this point I suspect that it could be defined in a future draft as an ancillary format (to the official registry in record-jar format). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Jon Hanna > Sent: dimanche 3 avril 2005 10:02 > To: 'LTRU Working Group' > Subject: [Ltru] Registry in RDF/XML format. > > Hi, I've only barely been able to keep up with this list of late due to > other obligations, but is an RDF/XML format completely out of the question? > > Regards, > Jon Hanna > Work: > Play: > Chat: > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 16:55:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07658; Mon, 4 Apr 2005 16:55:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIYjG-00089r-Hr; Mon, 04 Apr 2005 17:03:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXn1-000678-7D; Mon, 04 Apr 2005 16:03:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIXmz-00066v-Tq for ltru@megatron.ietf.org; Mon, 04 Apr 2005 16:03:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24154 for ; Mon, 4 Apr 2005 16:03:12 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIXv0-0003A4-C5 for ltru@ietf.org; Mon, 04 Apr 2005 16:11:30 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j34K34hZ001317; Mon, 4 Apr 2005 16:03:04 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 4 Apr 2005 16:03:07 -0400 Date: Mon, 4 Apr 2005 16:03:07 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] Re: Registry in record-jar format Message-ID: <20050404200306.GC7640@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0ADE7B34@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0ADE7B34@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Addison Phillips scripsit: > Answer: Yes, it is a problem, since users might have to specify two > ranges or may get results inconsistent with their expectations. For > example, the range "zh-TW" does not match the tag "zh-Hant-TW" using > strict 3066 matching rules. Just a terminological note: I think these should be called HTTP or RFC 2616 matching rules, since RFC 2616 is the true and authoritative source for them. > i. "Extended Range Matching" is an extension of RFR in which "missing" > subtags are considered to be (or are expanded to be) wildcards. So > "de-1901" is expanded to "de-*-*-1901" and matches "de-Latn-1901" and > "de-AT-1901", not to mention "de-Latg-NA-1901". I think this should be mentioned in the matching I-D. > NB> Probably we need to extend this scheme to allow users to specify > that they do NOT want a specific field to be filled in. For example > "de-!-1901" would match only "de-1901" and not a tag such as > "de-Latn-1901". I'd like to see a use case for this (not involving boont). > ii. "Lookup" is the opposite of matching, in which subtags are removed > from the tag rather than the range (i.e. locale-style) to fill in all > slots in a dataset. This matches a very different content set. This too should be mentioned. > iii. "Scored Matching" was proposed by John Cowan and produces content > with a range of scores, allowing the content to be filtered by choosing > a "quality level" (my words) for the match. The user can set a threshold > for matching, presumably. As should this. > The problem here is that matching cannot be as simple as it was under > RFC 3066 and still capture all possible cases. This is badly stated. Only matching of predefined tags in RFC 3066 captures all cases. -- Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! -- Joyce, Ulysses, "Oxen of the Sun" jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 17:14:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11582; Mon, 4 Apr 2005 17:14:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZ25-0001DW-HS; Mon, 04 Apr 2005 17:22:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYk0-0008J6-FV; Mon, 04 Apr 2005 17:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYjz-0008Ip-IO for ltru@megatron.ietf.org; Mon, 04 Apr 2005 17:04:12 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09432 for ; Mon, 4 Apr 2005 17:04:08 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIYgr-00033h-UH for ltru@lists.ietf.org; Mon, 04 Apr 2005 23:00:57 +0200 Received: from 212.82.251.116 ([212.82.251.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 23:00:57 +0200 Received: from nobody by 212.82.251.116 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 23:00:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 04 Apr 2005 22:59:37 +0200 Organization: Lines: 15 Message-ID: <4251AAB9.2BAA@xyzzy.claranet.de> References: <004c01c5392c$b2b0c280$030aa8c0@DEWELL> <42517E0D.EF2@xyzzy.claranet.de> <20050404184906.GB7640@skunk.reutershealth.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.116 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit John Cowan wrote: > 1) Normalize the tag. > 2) Create a quadruple (lang, script, region, variant), > filling in missing components with *s. > 3) Subtags match if they are the same or if either is "*". > 4) Add {8, 4, 2, 1} to the figure of merit if the {lang, > script, region, variant} matches. Nice. I'd prefer {4, 3, 1, 2}. If somebody goes to the trouble of specifying a variant it could be more important than the region (2 > 1). 4+3+2+1=10 because I like REXX ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 17:15:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11715; Mon, 4 Apr 2005 17:15:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZ2h-0001FP-4m; Mon, 04 Apr 2005 17:23:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYli-0000dY-SV; Mon, 04 Apr 2005 17:05:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYlh-0000Yq-W9 for ltru@megatron.ietf.org; Mon, 04 Apr 2005 17:05:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09972 for ; Mon, 4 Apr 2005 17:05:55 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIYth-0000Xf-77 for ltru@ietf.org; Mon, 04 Apr 2005 17:14:14 -0400 Received: from eupig1 (unverified) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Mon, 4 Apr 2005 21:05:43 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IEF0032RX9HZ9@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Mon, 04 Apr 2005 21:05:41 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Mon, 04 Apr 2005 21:05:40 +0000 Date: Mon, 04 Apr 2005 22:05:40 +0100 From: Misha Wolf Subject: RE: [Ltru] Registry in RDF/XML format To: LTRU Working Group MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Registry in RDF/XML format Thread-Index: AcU5WRnv1F7RJPiYQdKRdI6WCUjZ4gAAC9Ug content-class: urn:content-classes:message X-OriginalArrivalTime: 04 Apr 2005 21:05:40.0592 (UTC) FILETIME=[0EABFF00:01C5395A] X-Spam-Score: 0.8 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable I think that derivate registries are only plausible if they=20 are obtained through automated transformations from the normative=20 one. This makes the inclusion of any additional information=20 (eg names in other languages) difficult, though not impossible. Such additional information would have to be held separately and=20 merged (automatically) with the transform. Anything else (ie human tampering) is asking for trouble. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 17:16:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11946; Mon, 4 Apr 2005 17:16:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZ3b-0001Jo-5d; Mon, 04 Apr 2005 17:24:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYa4-0005Xu-LT; Mon, 04 Apr 2005 16:53:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYa0-0005XC-TT for ltru@megatron.ietf.org; Mon, 04 Apr 2005 16:53:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07421 for ; Mon, 4 Apr 2005 16:53:50 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIYi0-00083s-Bp for ltru@ietf.org; Mon, 04 Apr 2005 17:02:09 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 4 Apr 2005 13:53:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Registry in RDF/XML format. Date: Mon, 4 Apr 2005 13:53:36 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7BC4@irvmbxw01.quest.com> Thread-Topic: [Ltru] Registry in RDF/XML format. Thread-Index: AcU5UuJTXXAcYj7AS8K6neMAImbTpAAAXBVg From: "Addison Phillips" To: "McDonald, Ira" , "Jon Hanna" , "LTRU Working Group" X-OriginalArrivalTime: 04 Apr 2005 20:53:37.0092 (UTC) FILETIME=[5F6EA840:01C53958] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0146669816==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --===============0146669816== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGVyZSBhcmUgY2xlYXJseSBudW1lcm91cyBiZW5lZml0cyB0byB0aGUgWE1MIHJlZ2lzdHJ5 Lg0KPiBPbmUgb2YgdGhlbSAodGhlIGFiaWxpdHkgdG8gdXNlIHRoZSBmdWxsIHJhbmdlIG9mIFVu aWNvZGUNCj4gY2hhcmFjdGVycykgaXMgb25lIG9mIHRoZSBzdHJvbmdlc3QgYXJndW1lbnRzIF9h Z2FpbnN0Xw0KPiB0aGUgWE1MIGZvcm1hdCByZWdpc3RyeSBhcyB0aGUgTm9ybWF0aXZlIG9uZSAo YmVjYXVzZQ0KPiBpdCBjYW5ub3QgYmUgcHVibGlzaGVkIGluIGFuIGluaXRpYWwgcmVnaXN0cnkg UkZDLCB3aGljaA0KPiBoYXMgYmVlbiBjdXN0b21hcnkgd2l0aCBtb3N0IG90aGVyIG5ldyBJQU5B IHJlZ2lzdHJpZXMpLg0KDQpUaGF0IGluZmVsaWNpdHkgaXMgY2xlYXJseSBhbiBhcmd1bWVudCBh Z2FpbnN0IHBhc3QgSUVURiBwcmFjdGljZSwgbm90IFhNTCA6LSkuIEFsc28sIGFuIFhNTCBmaWxl IGNvdWxkIGJlIHB1Ymxpc2hlZCBpbiBhbiBSRkMgdXNpbmcgTkNScy4gRm9yIHRoYXQgbWF0dGVy LCBJIGRvbid0IHNlZSB0aGF0IHJlY29yZC1qYXIgaXMgZGVmaW5lZCBmb3JtYWxseSBhbnl3aGVy ZTogaXQgaXMgd2VsbC1kZWZpbmVkLCBidXQgbm90IGluIGEgY2FwaXRhbC1TIFN0YW5kYXJkIHRo YXQgSSBrbm93IG9mLiANCg0KV2UgY291bGQgdGh1cyBkZWZpbmUgdGhhdCB0aGUgcmVjb3JkLWph ciByZWdpc3RyeSB1c2VzIGEgXHV4eHh4IChvciBzaW1pbGFyKSBzeW50YXggdG8gZ2V0IHRoZSBz YW1lIGVmZmVjdCBpbiB0aGUgcmVnaXN0cnkgYXMgdXNpbmcgYSBVbmljb2RlIGVuY29kaW5nLiBJ biBmYWN0LCB3ZSBzaG91bGQgcHJvYmFibHkgZGVmaW5lIHRoZSB0aGF0IHZhbHVlcyBvdXRzaWRl IHRoZSByYW5nZSBVKzAwMDAuLlUrMDA3RSB1c2UgXHUgZXNjYXBlZCBoZXggc3ludGF4LiANCg0K VGhlIGFyZ3VtZW50IGhlcmUgaXMgd2hldGhlciB0aGUgdXRpbGl0eSBvZiBoYXZpbmcgYW4gWE1M IGZvcm1hdCBpcyB3b3J0aCB0aGUgY29zdCwgb3Igd2hldGhlciB0aGUgbmF0dXJlIG9mIHRoZSBy ZWdpc3RyeSBpcyBzdWNoIHRoYXQgYSBzdHJ1Y3R1cmVkIGZvcm1hdCBzdWNoIGFzIFhNTCBpcyBh IGJldHRlciB3YXkgaW4gd2hpY2ggdG8gcmVwcmVzZW50IHRoZSBkYXRhLiBBbmQgSSBiZWxpZXZl IHRoZSBjb25zZW5zdXMgaXMgIm5vLCBpdCBpc24ndCBuZWNlc3NhcnksIHVzZSByZWNvcmQtamFy IGFzIHRoZSBub3JtYXRpdmUgZm9ybWF0Ii4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxs aXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0Mg SW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxp emF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1jRG9uYWxkLCBJcmEgW21haWx0bzpp bWNkb25hbGRAc2hhcnBsYWJzLmNvbV0NCj4gU2VudDogbHVuZGkgNCBhdnJpbCAyMDA1IDEzOjE0 DQo+IFRvOiBBZGRpc29uIFBoaWxsaXBzOyBKb24gSGFubmE7IExUUlUgV29ya2luZyBHcm91cA0K PiBTdWJqZWN0OiBSRTogW0x0cnVdIFJlZ2lzdHJ5IGluIFJERi9YTUwgZm9ybWF0Lg0KPiANCj4g SGksDQo+IA0KPiBBcyBsb25nIGFzIHRoZSBYTUwgZm9ybWF0IHJlZ2lzdHJ5IGlzIGNsZWFybHkg bGFiZWxsZWQNCj4gJ0luZm9ybWF0aXZlJyBhbmQgb25seSB0aGUgb25lIFJlY29yZC1KYXIgZm9y bWF0IHJlZ2lzdHJ5DQo+IGlzIGxhYmVsbGVkICdOb3JtYXRpdmUnIChhbmQgbWFpbnRhaW5lZCBi eSBJQU5BKSwgSSdkIGJlDQo+IGhhcHB5IHRvIHNlZSBhbiBhdXhpbGlhcnkgWE1MIGZvcm1hdCBy ZWdpc3RyeS4NCj4gDQo+IFRoZXJlIGFyZSBjbGVhcmx5IG51bWVyb3VzIGJlbmVmaXRzIHRvIHRo ZSBYTUwgcmVnaXN0cnkuDQo+IE9uZSBvZiB0aGVtICh0aGUgYWJpbGl0eSB0byB1c2UgdGhlIGZ1 bGwgcmFuZ2Ugb2YgVW5pY29kZQ0KPiBjaGFyYWN0ZXJzKSBpcyBvbmUgb2YgdGhlIHN0cm9uZ2Vz dCBhcmd1bWVudHMgX2FnYWluc3RfDQo+IHRoZSBYTUwgZm9ybWF0IHJlZ2lzdHJ5IGFzIHRoZSBO b3JtYXRpdmUgb25lIChiZWNhdXNlDQo+IGl0IGNhbm5vdCBiZSBwdWJsaXNoZWQgaW4gYW4gaW5p dGlhbCByZWdpc3RyeSBSRkMsIHdoaWNoDQo+IGhhcyBiZWVuIGN1c3RvbWFyeSB3aXRoIG1vc3Qg b3RoZXIgbmV3IElBTkEgcmVnaXN0cmllcykuDQo+IA0KPiBDaGVlcnMsDQo+IC0gSXJhDQo+IA0K PiBJcmEgTWNEb25hbGQgKE11c2ljaWFuIC8gU29mdHdhcmUgQXJjaGl0ZWN0KQ0KPiBCbHVlIFJv b2YgTXVzaWMgLyBIaWdoIE5vcnRoIEluYw0KPiBQTyBCb3ggMjIxICBHcmFuZCBNYXJhaXMsIE1J ICA0OTgzOQ0KPiBwaG9uZTogKzEtOTA2LTQ5NC0yNDM0DQo+IGVtYWlsOiBpbWNkb25hbGRAc2hh cnBsYWJzLmNvbQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRy dS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3RzLmlldGYu b3JnXU9uDQo+IEJlaGFsZiBPZiBBZGRpc29uIFBoaWxsaXBzDQo+IFNlbnQ6IE1vbmRheSwgQXBy aWwgMDQsIDIwMDUgMTI6MjEgUE0NCj4gVG86IEpvbiBIYW5uYTsgTFRSVSBXb3JraW5nIEdyb3Vw DQo+IFN1YmplY3Q6IFJFOiBbTHRydV0gUmVnaXN0cnkgaW4gUkRGL1hNTCBmb3JtYXQuDQo+IA0K PiANCj4gTm8sIGJ1dCB5b3UgYW5kIEkgYXJlIGN1cnJlbnRseSB0aGUgb25seSBzdXBwb3J0ZXJz IG9mIGl0LCBzbyBpdCBpcw0KPiB1bmxpa2VseQ0KPiB0byBtYWtlIHRoZSBuZXh0IGRyYWZ0LiBB dCB0aGlzIHBvaW50IEkgc3VzcGVjdCB0aGF0IGl0IGNvdWxkIGJlIGRlZmluZWQNCj4gaW4NCj4g YSBmdXR1cmUgZHJhZnQgYXMgYW4gYW5jaWxsYXJ5IGZvcm1hdCAodG8gdGhlIG9mZmljaWFsIHJl Z2lzdHJ5IGluDQo+IHJlY29yZC1qYXIgZm9ybWF0KS4NCj4gDQo+IEFkZGlzb24NCj4gDQo+IEFk ZGlzb24gUC4gUGhpbGxpcHMNCj4gR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3 YXJlDQo+IENoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3Vw DQo+IA0KPiBJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KPiBJdCBpcyBh biBhcmNoaXRlY3R1cmUuDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g RnJvbTogbHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxp c3RzLmlldGYub3JnXQ0KPiBPbg0KPiA+IEJlaGFsZiBPZiBKb24gSGFubmENCj4gPiBTZW50OiBk aW1hbmNoZSAzIGF2cmlsIDIwMDUgMTA6MDINCj4gPiBUbzogJ0xUUlUgV29ya2luZyBHcm91cCcN Cj4gPiBTdWJqZWN0OiBbTHRydV0gUmVnaXN0cnkgaW4gUkRGL1hNTCBmb3JtYXQuDQo+ID4NCj4g PiBIaSwgSSd2ZSBvbmx5IGJhcmVseSBiZWVuIGFibGUgdG8ga2VlcCB1cCB3aXRoIHRoaXMgbGlz dCBvZiBsYXRlIGR1ZSB0bw0KPiA+IG90aGVyIG9ibGlnYXRpb25zLCBidXQgaXMgYW4gUkRGL1hN TCBmb3JtYXQgY29tcGxldGVseSBvdXQgb2YgdGhlDQo+IHF1ZXN0aW9uPw0KPiA+DQo+ID4gUmVn YXJkcywNCj4gPiBKb24gSGFubmENCj4gPiBXb3JrOiA8aHR0cDovL3d3dy5zZWxraWV3ZWIuY29t Lz4NCj4gPiBQbGF5OiA8aHR0cDovL3d3dy5oYWNrY3JhZnQubmV0Lz4NCj4gPiBDaGF0OiA8aXJj Oi8vaXJjLmZyZWVub2RlLm5ldC9zZWxraWU+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gTHRydSBtYWlsaW5nIGxpc3QN Cj4gPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbHRydQ0KDQoNCg== --===============0146669816== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0146669816==-- From ltru-bounces@ietf.org Mon Apr 4 17:17:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12263; Mon, 4 Apr 2005 17:17:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZ4u-0001Ol-PH; Mon, 04 Apr 2005 17:25:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYpD-00022P-OP; Mon, 04 Apr 2005 17:09:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYpC-000220-Gz for ltru@megatron.ietf.org; Mon, 04 Apr 2005 17:09:34 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11020 for ; Mon, 4 Apr 2005 17:09:31 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIYm5-0004AK-Ec for ltru@lists.ietf.org; Mon, 04 Apr 2005 23:06:21 +0200 Received: from 212.82.251.116 ([212.82.251.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 23:06:21 +0200 Received: from nobody by 212.82.251.116 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 23:06:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 04 Apr 2005 23:06:33 +0200 Organization: Lines: 9 Message-ID: <4251AC59.58B2@xyzzy.claranet.de> References: <42517E0D.EF2@xyzzy.claranet.de> <200504042002.j34K2iZu021741@smtp-los04.proxy.aol.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.116 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Debbie Garside wrote: > What do you -think- you would apply to the proposed 639-3 > tags like "ess" Central Siberian Yupik which is written in > Cyrillic script in Siberia and Latin script in Alaska? No default when it's unclear. This case sounds like the now deprecated sh (sr + hr). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 17:17:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12281; Mon, 4 Apr 2005 17:17:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZ4v-0001Op-Hv; Mon, 04 Apr 2005 17:25:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYwn-0003ZR-KE; Mon, 04 Apr 2005 17:17:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYwm-0003Yh-3S for ltru@megatron.ietf.org; Mon, 04 Apr 2005 17:17:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12221 for ; Mon, 4 Apr 2005 17:17:21 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZ4m-0001Nc-HE for ltru@ietf.org; Mon, 04 Apr 2005 17:25:40 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j34LH8jb001502; Mon, 4 Apr 2005 14:17:08 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 4 Apr 2005 14:17:08 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , John Cowan , "'Kurt@OpenLDAP.org'" Subject: RE: [Ltru] Re: Registry in record-jar format Date: Mon, 4 Apr 2005 14:17:05 -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: dbb8771284c7a36189745aa720dc20ab Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Hi, Relative to 'RFC 2616' matching rules below: It would be well to _explicitly_ address the impact of RFC3066bis matching rules on the recently published standards-track RFC 3866 "Language Tags and Ranges in the LDAP" (July 2004). If directory entries and/or directory attributes are returned 'incorrectly' by following RFC3066bis versus RFC3066, then this will have a visible impact on many enterprise applications. And to answer the immediate criticism, no I don't know the precise text to be added. Perhaps Kurt Zeilenga (editor of RFC 3866) can comment? I copied him on this reply. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On Behalf Of Addison Phillips Sent: Monday, April 04, 2005 4:23 PM To: John Cowan Cc: ltru@ietf.org Subject: RE: [Ltru] Re: Registry in record-jar format See below. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] > Sent: lundi 4 avril 2005 13:03 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Registry in record-jar format > > Addison Phillips scripsit: > > > Answer: Yes, it is a problem, since users might have to specify two > > ranges or may get results inconsistent with their expectations. For > > example, the range "zh-TW" does not match the tag "zh-Hant-TW" using > > strict 3066 matching rules. > > Just a terminological note: I think these should be called HTTP or RFC > 2616 > matching rules, since RFC 2616 is the true and authoritative source for > them. [Addison Phillips] Agreed. > > > i. "Extended Range Matching" is an extension of RFR in which "missing" > > subtags are considered to be (or are expanded to be) wildcards. So > > "de-1901" is expanded to "de-*-*-1901" and matches "de-Latn-1901" and > > "de-AT-1901", not to mention "de-Latg-NA-1901". > > I think this should be mentioned in the matching I-D. [Addison Phillips] I believe it is, although not this specific example. See http://www.inter-locale.com/ID/draft-ietf-ltru-matching-00.html#extrange > > > NB> Probably we need to extend this scheme to allow users to specify > > that they do NOT want a specific field to be filled in. For example > > "de-!-1901" would match only "de-1901" and not a tag such as > > "de-Latn-1901". > > I'd like to see a use case for this (not involving boont). [Addison Phillips] Find all content in need of retagging with a script in my Traditional Chinese document using XPath: /*@[lang="zh-!-TW"] > > > ii. "Lookup" is the opposite of matching, in which subtags are removed > > from the tag rather than the range (i.e. locale-style) to fill in all > > slots in a dataset. This matches a very different content set. > > This too should be mentioned. [Addison Phillips] Being added. Mark supplied text that I haven't had time to insert. > > > iii. "Scored Matching" was proposed by John Cowan and produces content > > with a range of scores, allowing the content to be filtered by choosing > > a "quality level" (my words) for the match. The user can set a threshold > > for matching, presumably. > > As should this. [Addison Phillips] Agreed. > > > The problem here is that matching cannot be as simple as it was under > > RFC 3066 and still capture all possible cases. > > This is badly stated. Only matching of predefined tags in RFC 3066 > captures > all cases. [Addison Phillips] It is badly stated. But I'm not sure your version captures the nuances either. Perhaps: Only generative tags in RFC 3066 (i.e. those with only two possible subtags) are guaranteed to work with RFC 2616 defined matching. > > -- > Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. > Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) > Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, > hoopsa! > -- Joyce, Ulysses, "Oxen of the Sun" jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 17:24:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13154; Mon, 4 Apr 2005 17:24:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZBH-0001nN-Oi; Mon, 04 Apr 2005 17:32:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYOK-0001ax-Qe; Mon, 04 Apr 2005 16:41:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIYOI-0001aR-Cz for ltru@megatron.ietf.org; Mon, 04 Apr 2005 16:41:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04284 for ; Mon, 4 Apr 2005 16:41:44 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIYWH-0006ub-FT for ltru@ietf.org; Mon, 04 Apr 2005 16:50:02 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 4 Apr 2005 13:41:33 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 4 Apr 2005 13:41:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Registry in record-jar format Date: Mon, 4 Apr 2005 13:41:28 -0700 Message-ID: Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU5RvmDk1wZipwuR/Kz3O6Aw6bokgAD5GFw From: "Peter Constable" To: "John Cowan" , "Frank Ellermann" X-OriginalArrivalTime: 04 Apr 2005 20:41:38.0255 (UTC) FILETIME=[B2F8D5F0:01C53956] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of John Cowan > I have yet to receive any comments on my proposed alternative > (not replacement) matching algorithm... I like the basic idea. There are details that need further consideration, though, as Addison has pointed out. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 17:30:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13859; Mon, 4 Apr 2005 17:30:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIZHE-00021T-QB; Mon, 04 Apr 2005 17:38:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIZ8K-0008IH-3E; Mon, 04 Apr 2005 17:29:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIZ8I-0008H7-Iq for ltru@megatron.ietf.org; Mon, 04 Apr 2005 17:29:18 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13764 for ; Mon, 4 Apr 2005 17:29:15 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIZ5p-0008Pc-Mv for ltru@lists.ietf.org; Mon, 04 Apr 2005 23:26:45 +0200 Received: from 212.82.251.116 ([212.82.251.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 23:26:45 +0200 Received: from nobody by 212.82.251.116 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Apr 2005 23:26:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 04 Apr 2005 23:22:59 +0200 Organization: Lines: 40 Message-ID: <4251B033.624C@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.116 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in RDF/XML format. X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit McDonald, Ira wrote: > the ability to use the full range of Unicode characters [...] > is one of the strongest arguments _against_ the XML format > registry as the Normative one (because it cannot be published > in an initial registry RFC Appendix A - registry entries in XML format āāā no idea what "ess" is ;-) ... ... ... Sorry, I really don't see why XML is impossible in an RfC. :-( Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 18:31:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19988; Mon, 4 Apr 2005 18:31:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIaEP-0004Be-M4; Mon, 04 Apr 2005 18:39:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIa5W-000466-Qd; Mon, 04 Apr 2005 18:30:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIa5V-00045y-0C for ltru@megatron.ietf.org; Mon, 04 Apr 2005 18:30:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19926 for ; Mon, 4 Apr 2005 18:30:25 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIaDV-000483-IH for ltru@ietf.org; Mon, 04 Apr 2005 18:38:45 -0400 Received: from h-68-166-189-216.snvacaid.dynamic.covad.net ([68.166.189.216] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DIa5R-0007mc-00 for ltru@ietf.org; Mon, 04 Apr 2005 15:30:25 -0700 Message-ID: <010c01c53966$1158b200$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 4 Apr 2005 15:31:38 -0700 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: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Ltru] Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Hi - forwarded for your information.... The references in the registry i-d should be changed accordingly. Randy ----- Original Message ----- > From: "The IESG" > To: "IETF-Announce" > Cc: "Internet Architecture Board" ; "RFC Editor" > Sent: Monday, April 04, 2005 1:35 PM > Subject: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard > > The IESG has approved the following document: > > - 'Augmented BNF for Syntax Specifications: ABNF ' > as a Draft Standard > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Scott Hollenbeck. > > Technical Summary > > Internet technical specifications often need to define a format > syntax. Over the years a modified version of Backus-Naur Form (BNF), > called Augmented BNF (ABNF), has been popular among many Internet > specifications. The current specification documents ABNF. It > balances compactness and simplicity, with reasonable representational > power. The differences between standard BNF and ABNF involve naming > rules, repetition, alternatives, order-independence, and value > ranges. This specification also supplies additional rule definitions > and encoding for a core lexical analyzer of the type common to > several Internet specifications. > > This document obsoletes RFC 2234. > > Working Group Summary > > This document is the work of individual submitters. It was produced > to address comments received from the IESG when the IESG was asked > to elevate RFC 2234 to Draft Standard status. An IETF last call on > the request to elevate RFC 2234 was completed in June 2004. > > Protocol Quality > > Harald Alvestrand, Bill Fenner, and Scott Hollenbeck evaluated this > specification for the IESG. > > RFC Editor Note: > > Abstract and Section 1, first sentence: > OLD: > "Internet technical specifications often need to define a format" > ^^^^^^ > > NEW: > "Internet technical specifications often need to define a formal" > (change "format" to "formal") > > Section 1: > OLD: > "Changes in the latest version of this Internet Draft:" > > NEW: > "Changes Since RFC 2234:" > > Section 3.1: > OLD: > NOTE: > > NOTE: This specification for ABNF does not provide for implicit > specification of linear white space. > > NEW: > NOTE: This specification for ABNF does not provide for implicit > specification of linear white space. > (remove frist instance of "NOTE") > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 19:01:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22652; Mon, 4 Apr 2005 19:01:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIahS-0005Fd-8n; Mon, 04 Apr 2005 19:09:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIaWQ-0008Nh-E1; Mon, 04 Apr 2005 18:58:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIaWO-0008NR-T4 for ltru@megatron.ietf.org; Mon, 04 Apr 2005 18:58:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22408 for ; Mon, 4 Apr 2005 18:58:13 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIaeQ-00058s-1v for ltru@ietf.org; Mon, 04 Apr 2005 19:06:34 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j34Mw6ZL002143; Mon, 4 Apr 2005 18:58:06 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 4 Apr 2005 18:58:07 -0400 Date: Mon, 4 Apr 2005 18:58:07 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: Registry in record-jar format Message-ID: <20050404225807.GE7640@skunk.reutershealth.com> References: <004c01c5392c$b2b0c280$030aa8c0@DEWELL> <42517E0D.EF2@xyzzy.claranet.de> <20050404184906.GB7640@skunk.reutershealth.com> <4251AAB9.2BAA@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4251AAB9.2BAA@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Frank Ellermann scripsit: > > 4) Add {8, 4, 2, 1} to the figure of merit if the {lang, > > script, region, variant} matches. > > Nice. I'd prefer {4, 3, 1, 2}. If somebody goes to the > trouble of specifying a variant it could be more important > than the region (2 > 1). 4+3+2+1=10 because I like REXX ;-) I didn't choose powers of 2 capriciously. Your algorithm would prefer "ru-latn-1901" to "de" when matching against "de-Latn-1901". (We don't have enough variants yet to make a really compelling counterexample, but that indicates the general feel of it.) -- If you understand, John Cowan things are just as they are; http://www.ccil.org/~cowan if you do not understand, http://www.reutershealth.com things are just as they are. jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 19:04:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22931; Mon, 4 Apr 2005 19:04:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIak9-0005Kb-RD; Mon, 04 Apr 2005 19:12:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIaTe-0007ng-G7; Mon, 04 Apr 2005 18:55:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIaTd-0007nQ-99 for ltru@megatron.ietf.org; Mon, 04 Apr 2005 18:55:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22058 for ; Mon, 4 Apr 2005 18:55:22 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIabd-0004zm-Fs for ltru@ietf.org; Mon, 04 Apr 2005 19:03:42 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j34MtDL5002127; Mon, 4 Apr 2005 18:55:14 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 4 Apr 2005 18:55:13 -0400 Date: Mon, 4 Apr 2005 18:55:12 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] Re: Registry in record-jar format Message-ID: <20050404225512.GD7640@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0ADE7AF9@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0ADE7AF9@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Addison Phillips scripsit: > Extlang and variant can both be repeated and order is significant. Does > one variant matching from a list of variants count as "1 point" or as > a fraction? I'm not taking extlangs into account yet. I hadn't noted that variants can be repeated; I agree that that requires more thought. > Extensions are always ignored (good). What about private use subtags? Also ignored. You can supplement this algorithm with an "exact match gets 16" if you want. > Unless you receive a "perfect" score of 15, is it a match? What do I > do with tags with a score of 14, 13, 11, 2? The idea is to sort candidates in order of usefulness. What to do then is up to the matcher (return an ordered list of candidates, pick the top candidate, whatever). > Finally, how is this different in practice from the "extended language > range" matching currently proposed? Precisely because of this question of ordering. -- Values of beeta will give rise to dom! John Cowan (5th/6th edition 'mv' said this if you tried http://www.ccil.org/~cowan to rename '.' or '..' entries; see jcowan@reutershealth.com http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 19:50:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26838; Mon, 4 Apr 2005 19:50:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIbT8-0006rH-4u; Mon, 04 Apr 2005 19:58:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIbKW-0003Av-Oy; Mon, 04 Apr 2005 19:50:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIbKV-0003Ad-Ag for ltru@megatron.ietf.org; Mon, 04 Apr 2005 19:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26785 for ; Mon, 4 Apr 2005 19:50:00 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIbSW-0006qU-S2 for ltru@ietf.org; Mon, 04 Apr 2005 19:58:21 -0400 Received: from if12m4-235.d2.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DIbKR-0004Yf-6X for ltru@ietf.org; Mon, 04 Apr 2005 16:50:01 -0700 Message-Id: <6.1.2.0.2.20050405014928.037ea550@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 05 Apr 2005 01:49:46 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.2 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA26785 Subject: [Ltru] draft review X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c Content-Transfer-Encoding: quoted-printable Gentlemen, This is the review I made of the current draft : the text and the way it=20 addresses the Charter. I accept there is a challenge in the charter, whic= h=20 is to reconcile two of its assigned challenges. Its authors chose to=20 address one of them (to identify the role of the subtags in the langtag),= =20 while my approach is to start from the other (stability) to address both,= =20 in a more general way. The result is that my review has only a very limited number of positive=20 remarks. But that does not mean that I full oppose. It confirms the only=20 two possibilities already offered by the ietf@ietf.org mailing list: - either to accept the draft in the strict area quoted by the Charter (XM= L,=20 HTML and CLDR) to describe the language human readers should know to read= a=20 tagged text. - or to write another one, in a totally different perspective, to support= =20 the multilingual internet architectural consistency we need. In any case the first solution would only be a temporary patch until the=20 second one can support the world priority for a multilingual internet. I only hope this will permit Addison Philips and Mark Davis to improve=20 their text so it might make an RFC. DRATF RELATED COMMENTS AND QUESTIONS This review only concerns the points discussed in the proposed draft, not= =20 the points which are missing. 1. Abstract: "indicate the language" does that mean qualify (tell about) = or=20 define (show the way) or both? 2. Abstract: "information object": does that include programs, services,=20 users communities 3. Abstract: "interchange". Is there a special reason to use the word=20 "interchange" (quoted 13 times in the IETF RFC database) and not=20 "exchanges" (38 times). What are the differences intended? 4. Introduction: the word identify/identifier is used 6 times, while=20 indicate/indicating only 2 to avoid repetition of identify. Why not to us= e=20 the word "identify" in Abstract (cf. question 1)? 5. Introduction: the introduction describes the use of the tag to name a=20 menu of references (dictionaries) and documents that it is often necessar= y=20 to document style related elements (dialect, orthography) and writing=20 system. These are the 5 elements I want to see documented. 6. Introduction: documents that knowing the language is useful (qualifies= )=20 or required (defines) for some processes. What is the intended meaning? 7. Introduction: indicates that labels are one of the means of indicating= =20 (meaning?) languages used. No other means is alluded to, and no comments=20 about their common consistency is provided? 8. Introduction: identifies only two functions for the document: an=20 "identifier mechanism" and a "registration function". It does not talk of= =20 the dissemination of that information, nor of the way applications should= =20 use it. 9. Introduction: the sentence should say "This document intended to=20 replace RTC 3066 and as such to become the new RFC 047" if this is the in= tent. 10. The language Tag: introduction talks about labels. What is the=20 difference between the labels which have been documented as necessary and= =20 the languages tags now documented? 11. Syntax: the sentence "this makes it possible to construct a parser=20 =85even if specific subtag values are not recognised" is quite obscure. W= hat=20 is the exact meaning of "recognised": understood, known, accepted,=20 authoritative, canonical, identified? 12. Syntax: "a parser need not have an up-to-date copy .. to perform ..=20 most .. searching and matching", what tells the parser the values it uses= =20 are up-to-date? How can we quantify the "most" and the number of=20 occurrences of the remaining cases, for one billion users and more? 13. 2.1.1: how can the complex subtag sequence adding more precision can=20 "seldom add useful distinguishing information" they are obviously intende= d=20 to? Where is documented the authority of the following "because" saying=20 that more granular tags interfere with the meaning, etc.. intended by the= =20 user. I do not oppose that users can be clumsy, but I think that the idea= =20 they are seldom smart should be explained. I feel the problem is more wit= h=20 filtering/analysis limitations. 14. 2.1.1: that subtags SHOULD be limited to four subtags is not=20 documented. The allusion to the 2.3. for more information (which provides= =20 guidance about best choice of subtag content) does not seems to document=20 this at all. 15. 2.1.1: is accepted as a "conformant implementation" an application no= t=20 supporting a non specified length (1, 10, 100 chars?). The consequences o= n=20 usage are not documented. 16. 2.2: it is noted that the language used for the "language tags=20 namespace" and its registry is quite similar to the domain name system.=20 However the proposed semantic is not consistent with other Internet space= s=20 like DNS, IPv4, OID, etc. where the dot-separation is used, something use= rs=20 and parsers are accustomed to and existing processes have identified in=20 different scripts. It relies to the contrary on the "-" as a separator=20 which is more confusing and may have less identified homographs. 17. 2.2: the proposed design of language tags mixes identification of=20 subtags by their position unless it is by their length. It is probable th= at=20 in the particular case of the legacy and initial situation this can work.= =20 Such a two, possibly contradictory, systems format will never scale, is f= ar=20 too dependent from external changes and unable to support innovation. Thi= s=20 cannot be made a world-wide standard through an IETF BCP except in the=20 cases defined by the charter if the IESG wants to run into the risk of=20 endless conflicts and of a quick obsolescence. It is to be noted that the= =20 referred ISO standard to be used are less than 30 years old and yet ISO=20 3166-2 cannot be supported. 18. 2.2.1: primary language: fixed length identification starts with 2 or= 3=20 and possibly 8 but discouraged language ID coming this way only from ISO=20 639. This removes the possibility to consider computer related (non only=20 programming) languages, dialects, etc. nor to adapt to evolutions,=20 adjustments, and passed languages. For example, ISO 3166 could back to 18= 00=20 and possibly to 1000 and even to much before, either as a an ISO document= =20 or as a consistent table. Support of historic languages will be required.= =20 Blocking document historical consistency is unthinkable let just conside= r=20 the current effort by Google and various libraries. 19. 2.2.1.: the 2 letters code for language is an oddity inherited from=20 earlier times of RFC 1776 and ISO 639. Nothing against this being the=20 default in some legacy or private application. It is likely that at some=20 time it will be timed out by ISO or/and by usage may be even by=20 anti-racist laws Time is now to update existing applications rather than = to=20 increase complexity of the years/century to come. This makes me think to=20 "UK" instead of "GB". I know why Mr. Peter Jones made the world to use=20 ".uk": I will be also able to tell my grand-grand-son why they are to rio= t=20 against the 2/3 letters cultures discrimination. This seems also in=20 contradiction with the spirit of the quoted ISO 639/RA-JAC statement whic= h=20 says "users are directed in Internet applications to employ the alpha-3=20 code" which sounds as the part of the statement which will stay as=20 universal .. for a short while (?). 20. 2.2.2: language subtags are permitted only if they are 3 characters (= a=20 permanent rigid position) based the anticipation of a non documented ISO=20 639 works. This is also a violation of the Internet standard process: the= =20 document in reference should be quoted and cannot be a draft. Language=20 extended subtags are the most active part of languages, yet the rigidity=20 imposed by the chosen format obliges to prevent their registration by IAN= A=20 (what is the very purpose of the document: to permit flexibility to suppo= rt=20 real network life, where ISO would be too slow). 21. 2.2.3: Script subtags follow the same rigid logic and constraints fro= m=20 the format. What happens if the memory waste of ISO 15924 (3 bytes lost)= =20 is corrected, or if another code element has a fixed 4 characters length= =20 in the future? 22. 2.2.4: I understand that all the regional language differences of the= =20 world are to be supported by the ISO 3166 alpha-3/digit-3 list. This mean= s=20 that regions like NY, TX or California are not entitled a code but the 56= =20 persons of Pitcairn Island yes? I doubt that disparity can hold very long= ,=20 all the more than ISO 3166-2 provides all the possibilities for a far mor= e=20 adequate granularity. 23. 2.2.9: There is a MUST in "there MUST be an attempt to register" whic= h=20 cannot be enforced if there is not a non-delaying procedure to verify tha= t=20 a language was attempted to be registered with ISO 639. Otherwise this pa= rt=20 is to be understood as a disguised way, concerted with ISO, to block name= s.=20 The concern on this point is high enough to see the Draft blocked. It see= ms=20 that the second paragraph is a smoky verbose replay of the same idea,=20 without any procedural description nor request/provision of formal proof.= =20 The general idea is precisely in opposition with the purpose of the=20 proposed RFC: to be able to register names not registered by ISO. This=20 amount to a legitimisation of censoring, and censoring against the very=20 intent of this document. 24. 2.2.9: registrations are left to a decision of appropriateness by=20 someone debating with undefined others for a matter without any importan= ce=20 on the network stability and security (documented in in part 4) non on th= e=20 end to end interoperability. This seems to amount to pure intellectual=20 censoring. 25. 2.3: recommendation 3 seems inappropriate. Aliases are aliases. All t= he=20 aliases must be equally supported because (a) they are aliases (b) to mak= e=20 sure developers develops correct code. 26. 2.4. "language tags always define a language as spoken by human being= =20 for communications of information to other human beings. Computer languag= es=20 =85 are explicitly excluded" has no ground in the Charter and in reality.= Web=20 Services relations are excluded which may speak limited languages. Coded=20 human languages should be supported: they fit the definition. 27. 2.4.1: in the canonicalization part "" is reminded as a deprecation=20 indicator, yet this is not documented earlier. It seems this is an extern= al=20 ISO practice. This should be documented in the format description part. A= ll=20 the more than this practice is counter intuitive "" being understood=20 intuitively as "-(nul)-". And the "" being used in IDN there could be som= e=20 homograph confusion to investigate. 28. 3: the reference to RFC 2434 is correct but the rest of the part 3=20 seems inappropriate. RFC 2434 says "If the IANA is expected to play a ro= le=20 in the management of a name-space the IANA must be given clear and concis= e=20 instructions describing that role". The part 3 is neither clear and conci= se=20 and is contradictory with the document which describes a IANA file to be=20 maintained by an IESG reviewer. The IESG having authority on the IANA, th= e=20 role of the IANA is to store and disseminate the current file version as=20 maintained by the reviewer. 29. 3.1: Description of "description" is clueless. It is a description bu= t=20 does not intend to be an English description but it is one. The addition=20 made in the IANA file are intended to be additions to corresponding=20 documented ISO tables. They MUST comply with the format of these tables=20 otherwise they add a disparity between the table and their IANA "appendix= ". 30. 3.1. includes a registry format description (OK) but also=20 considerations on the way the tags should be formed which have nothing to= =20 do in a file description. They should be moved into 2.4.1 31. 3.1. also includes direction to the Reviewer which should be presente= d=20 in a separate part from the format description. 32. 3.2. this part is not a IANA procedure but a long guidance for the=20 Reviewer and the Reviewing process participants, limited to current=20 possible cases. 33. 3.3 : Understanding the meaning of "Subtags required for stability an= d=20 to keep the registry synchronised" will probably be a source of long=20 debates. It should be documented. 34. 3.3. why a "MAY" concerning the "description, note and prefix fields= "=20 is not documented by conditions? Is that not a "CAN". 35. 3.3. the registration procedure is of extreme confusion and mixes the= =20 form to use, the lack of definition of the requester, the iana.org list=20 which is not introduced, the registration request which must be guessed, = a=20 non commented MAY, registration tricks, comments on probable behaviour of= =20 the reviewing list, digression on Slovenian, designation of the reviewer = by=20 the IESG, what should happen when the review period has elapsed without a= ny=20 guidance to the reviewer, that a IANA list Members and an IESG designated= =20 reviewer make an IETF decision, that the initial registrant has some mora= l=20 pre-eminence (under the form of a comment) and that languages are not=20 considered for registration on the fact they actually exist, but on their= =20 own (non documented) merits. 36. 3.4. Difficult to understand. The first sentence is probably inherite= d=20 from the former versions of the draft. "compatible with applications that= =20 process language tags according to this specification" seems to refer to=20 filtering which should be part of the of the second document produced by=20 the WG-ltru. 37. 3.4. The description of information to be maintained is clear, but th= e=20 format is not described. This permits IANA to freely change it or to=20 present it in HTML form. This does not help its automated reading. 38. 4. security considerations should not deal with users political=20 security outside of their network usage. Otherwise tons of such=20 considerations should be presented. 39. 4. An important security consideration is homographs. It is certainly= =20 possible to include part of text in a foreign language which look printed= =20 as in another language or having a different meaning or printing=20 (phishing). Concerns are also the double "-" which is specifically used b= y=20 the IANA code "xn". 40. 4. Fourth paragraph tend to say that specification of valid sub-tags= =20 MUST be available over the internet but that applications should take=20 possible DoS into consideration. This is an important indication on the w= ay=20 the Draft proposes the registry file to be used and accessed. It can be=20 read that applications can freely access it and proposed mirrors: this ma= y=20 impose on the IANA a load which will result in its permanent inability of= =20 service. 41. 5. character set consideration are contradictory: they say that=20 character a-z exist in most character sets (good news) [what means that=20 there are some where they do not exist] so there should not be character=20 set presentation issue [in the character set where they do not exist?].=20 Also the consideration only concerns the "display" what has a limited=20 interest if the a-z characters do not exist on the keyboard. But may be=20 this supposes that "intelligent people" use ascii compatible keyboards (s= ee=20 below). 42. 6. compatibility is preserved with RFC 3066 but not with evolution of= =20 ISO code elements. The XML Schema version 1.0 requirements are quoted but= =20 not documented. 43. 6. Stability. Confusion between document. This document does not=20 provide a mechanism but a format that can be used by the mechanism=20 described in the next document. This text has not been adapted after the = split. 44. 6. Validity. This document should define the IQ of the "intelligent=20 people" being considered or the collective IQ augmentation necessary to=20 understand the system ?? Please see the ideas of the one who created the= =20 NIC and grand fathered the RFC system (http://bootstrap.org). 45. 6. Extensibility such as presented actually results (in a very limite= d=20 way) from the underlying ISO codes. This is not the target of Charter whi= ch=20 is to permit scalability even when a code element it is not supported by = ISO. 46. 6. the document uses several times the term "extlang" but does not=20 defines it. 47. 6. last: added text for "" is not sufficient enough, or is missing in= =20 my version. CHARTER VS DRATF RELATED COMMENTS AND QUESTIONS 48. language preferences are uniquely understood in HTML, XML only. CLDR=20 are quoted in the charter and not quoted in the Draft. The Charter does n= ot=20 prevent other applications, systems to be supported. The Draft does not=20 allude to them. 49. The charter lists RFC 3066 problems. These problems are: (a)=20 stability there is a paragraph on the matter; (b) accessibility to the=20 underlying ISO standard this is definitely impeached by the format (no I= SO=20 3166-2, no other ISO 639 format than 2 or 3 characters no other script=20 description format than 4 characters, etc. as if the current ISO=20 presentation will never improve); (c) difficulty with registration and=20 acceptance: this could be improved by the subtag registration system but = it=20 seems to be made worse, due to the censoring rules introduced to prevent=20 non-ISO entries to be entered in the IANA non-ISO table; (e) lack of clea= r=20 guidance to identify script and region: scripts are Unicode only, region=20 are 2 letter Telex codes; (f) lack of parseability and well-formedness :=20 this has certainly been addressed [it seems to be both the major=20 improvement of the Draft =85 and the source of most of its problems due t= o=20 the rigidity it introduces]. 50. The main purpose of this Draft from the charter is to describe the IA= NA=20 registry to support the resolution of the above problems, and how=20 transition from RFC 3066. This is to be in a clear and concise way. RFC=20 3066 represents roughly 17.000 characters and the draft 70.000 (out of th= e=20 IETF format and verbose). This makes it confuse. From what I understand i= t=20 includes 3 parts: (a) the subtags file with a clear format (b) the=20 accompanying registration/update forms (c) the variant tables with a clea= r,=20 yet less precise format. From what I understand (a)(b) are the real=20 responsibility of the old aliased distribution list and of a Reviewer=20 designated by IESG with unlimited veto powers; (c) of the IESG when=20 reviewing RFCs requesting entries, and of the updating mechanism defined = by=20 these RFC. 51. it lists challenges to be addressed. Stability: "how the language tag= s=20 remains stable even if the underlying references should change". This mea= ns=20 a process where the tag name is unrelated to its underlying components,=20 like a domain name is stable even if the underlying IP address changes.=20 This is not provided. 52. it lists challenges to be addressed. Accessibility: "a simple way to=20 determine if a subtag is valid as of a given date. Like receiving a 404=20 when calling an expired domain name". Such a mechanism is not provided. 53. it lists challenges to be addressed. extensibility: this meant not=20 having to record millions of combinations. This is provided. To the price= =20 of format rigidity, impossible use of foreseen or existing ISO code=20 elements, and a censoring of the non-ISO extensions which may lead to mor= e=20 harassment. It also meant addition of the script in language tags. This i= s=20 permitted by the proposed format but to the detriment of other 4 letters=20 entries. Registration of non ISO scripts is not permitted. 54. it lists challenges to be addressed. "provide mechanism to support th= e=20 evolution of the underlying standards, in particular ISO 693-3, mechanism= s=20 to support variant registration and format extensions, as well as allowin= g=20 generative private use when necessary": I am not sure what "generative" m= ay=20 mean in here but I feel it is not supported, the rest is certainly oppose= d=20 by the chosen format; 55. it lists challenges to be addressed: "to specify a mechanism for easi= ly=20 identifying the role of each subtag in the language tag". This is=20 addressed by the Draft. But this challenge is contradictory with stabilit= y=20 challenge above. If a language tag displays an identifiable subtag, it=20 becomes by nature dependent from the underlying value of the subtag. I will study carefully the responses to this review before introducing my= =20 own Draft, to try to build if possible on the largest possible number o= f=20 consensual elements. My current thinking is totally different. It is an open framework which=20 respects the XML, HTML, CLDR requirements in welcoming your own (adapted)= =20 Draft, the ISO evolution, the requirements of an Internet for the people = of=20 the world by the people of the world, at an affordable cost, with an high= ly=20 innovative technical approach, a great care for operation security and=20 stability and in total continuity with the funding concept which gave us=20 thirty years of international public network stability. But I think the issues it rises are important enough to call on an=20 understanding, comments, and a support by all those concerned by a=20 "multilingual cyberspace", an equal cultural dignity empowerment on the=20 digital ecosystem and an open e-commerce. This is because language tags a= re=20 by nature the basic building blocks of the multilingual internet which is= =20 also to be user centric, multitechnology (convergence), multicontent=20 (information society), multilateral, as the WSIS shows it. jfcm=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 4 21:34:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03888; Mon, 4 Apr 2005 21:34:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DId5X-0001pC-7P; Mon, 04 Apr 2005 21:42:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIctm-0005Oz-9k; Mon, 04 Apr 2005 21:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIbAc-0000Ez-82 for ltru@megatron.ietf.org; Mon, 04 Apr 2005 19:39:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26043 for ; Mon, 4 Apr 2005 19:39:46 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIbId-0006Vj-CH for ltru@ietf.org; Mon, 04 Apr 2005 19:48:08 -0400 Received: from if12m4-235.d2.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DIbAR-0007mw-CL for ltru@ietf.org; Mon, 04 Apr 2005 16:39:41 -0700 Message-Id: <6.1.2.0.2.20050405000927.03c88e10@pop.online.fr> X-Sender: jefsey@pop.online.fr X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 05 Apr 2005 00:10:23 +0200 To: ltru@ietf.org From: Jefsey Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - online.fr X-Spam-Score: 0.2 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA26043 X-Mailman-Approved-At: Mon, 04 Apr 2005 21:30:33 -0400 Subject: [Ltru] draft review X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c Content-Transfer-Encoding: quoted-printable Gentlemen, This is the review I made of the current draft : the text and the way it=20 addresses the Charter. I accept there is a challenge in the charter, whic= h=20 is to reconcile two of its assigned challenges. Its authors chose to=20 address one of them (to identify the role of the subtags in the langtag),= =20 while my approach is to start from the other (stability) to address both,= =20 in a more general way. The result is that my review has only a very limited number of positive=20 remarks. But that does not mean that I full oppose. It confirms the only=20 two possibilities already offered by the ietf@ietf.org mailing list: - either to accept the draft in the strict area quoted by the Charter (XM= L,=20 HTML and CLDR) to describe the language human readers should know to read= a=20 tagged text. - or to write another one, in a totally different perspective, to support= =20 the multilingual internet architectural consistency we need. In any case the first solution would only be a temporary patch until the=20 second one can support the world priority for a multilingual internet. I only hope this will permit Addison Philips and Mark Davis to improve=20 their text so it might make an RFC. DRATF RELATED COMMENTS AND QUESTIONS This review only concerns the points discussed in the proposed draft, not= =20 the points which are missing. 1. Abstract: "indicate the language" does that mean qualify (tell about) = or=20 define (show the way) or both? 2. Abstract: "information object": does that include programs, services,=20 users communities 3. Abstract: "interchange". Is there a special reason to use the word=20 "interchange" (quoted 13 times in the IETF RFC database) and not=20 "exchanges" (38 times). What are the differences intended? 4. Introduction: the word identify/identifier is used 6 times, while=20 indicate/indicating only 2 to avoid repetition of identify. Why not to us= e=20 the word "identify" in Abstract (cf. question 1)? 5. Introduction: the introduction describes the use of the tag to name a=20 menu of references (dictionaries) and documents that it is often necessar= y=20 to document style related elements (dialect, orthography) and writing=20 system. These are the 5 elements I want to see documented. 6. Introduction: documents that knowing the language is useful (qualifies= )=20 or required (defines) for some processes. What is the intended meaning? 7. Introduction: indicates that labels are one of the means of indicating= =20 (meaning?) languages used. No other means is alluded to, and no comments=20 about their common consistency is provided? 8. Introduction: identifies only two functions for the document: an=20 "identifier mechanism" and a "registration function". It does not talk of= =20 the dissemination of that information, nor of the way applications should= =20 use it. 9. Introduction: the sentence should say "This document intended to=20 replace RTC 3066 and as such to become the new RFC 047" if this is the in= tent. 10. The language Tag: introduction talks about labels. What is the=20 difference between the labels which have been documented as necessary and= =20 the languages tags now documented? 11. Syntax: the sentence "this makes it possible to construct a parser=20 =85even if specific subtag values are not recognised" is quite obscure. W= hat=20 is the exact meaning of "recognised": understood, known, accepted,=20 authoritative, canonical, identified? 12. Syntax: "a parser need not have an up-to-date copy .. to perform ..=20 most .. searching and matching", what tells the parser the values it uses= =20 are up-to-date? How can we quantify the "most" and the number of=20 occurrences of the remaining cases, for one billion users and more? 13. 2.1.1: how can the complex subtag sequence adding more precision can=20 "seldom add useful distinguishing information" they are obviously intende= d=20 to? Where is documented the authority of the following "because" saying=20 that more granular tags interfere with the meaning, etc.. intended by the= =20 user. I do not oppose that users can be clumsy, but I think that the idea= =20 they are seldom smart should be explained. I feel the problem is more wit= h=20 filtering/analysis limitations. 14. 2.1.1: that subtags SHOULD be limited to four subtags is not=20 documented. The allusion to the 2.3. for more information (which provides= =20 guidance about best choice of subtag content) does not seems to document=20 this at all. 15. 2.1.1: is accepted as a "conformant implementation" an application no= t=20 supporting a non specified length (1, 10, 100 chars?). The consequences o= n=20 usage are not documented. 16. 2.2: it is noted that the language used for the "language tags=20 namespace" and its registry is quite similar to the domain name system.=20 However the proposed semantic is not consistent with other Internet space= s=20 like DNS, IPv4, OID, etc. where the dot-separation is used, something use= rs=20 and parsers are accustomed to and existing processes have identified in=20 different scripts. It relies to the contrary on the "-" as a separator=20 which is more confusing and may have less identified homographs. 17. 2.2: the proposed design of language tags mixes identification of=20 subtags by their position unless it is by their length. It is probable th= at=20 in the particular case of the legacy and initial situation this can work.= =20 Such a two, possibly contradictory, systems format will never scale, is f= ar=20 too dependent from external changes and unable to support innovation. Thi= s=20 cannot be made a world-wide standard through an IETF BCP except in the=20 cases defined by the charter if the IESG wants to run into the risk of=20 endless conflicts and of a quick obsolescence. It is to be noted that the= =20 referred ISO standard to be used are less than 30 years old and yet ISO=20 3166-2 cannot be supported. 18. 2.2.1: primary language: fixed length identification starts with 2 or= 3=20 and possibly 8 but discouraged language ID coming this way only from ISO=20 639. This removes the possibility to consider computer related (non only=20 programming) languages, dialects, etc. nor to adapt to evolutions,=20 adjustments, and passed languages. For example, ISO 3166 could back to 18= 00=20 and possibly to 1000 and even to much before, either as a an ISO document= =20 or as a consistent table. Support of historic languages will be required.= =20 Blocking document historical consistency is unthinkable let just conside= r=20 the current effort by Google and various libraries. 19. 2.2.1.: the 2 letters code for language is an oddity inherited from=20 earlier times of RFC 1776 and ISO 639. Nothing against this being the=20 default in some legacy or private application. It is likely that at some=20 time it will be timed out by ISO or/and by usage may be even by=20 anti-racist laws Time is now to update existing applications rather than = to=20 increase complexity of the years/century to come. This makes me think to=20 "UK" instead of "GB". I know why Mr. Peter Jones made the world to use=20 ".uk": I will be also able to tell my grand-grand-son why they are to rio= t=20 against the 2/3 letters cultures discrimination. This seems also in=20 contradiction with the spirit of the quoted ISO 639/RA-JAC statement whic= h=20 says "users are directed in Internet applications to employ the alpha-3=20 code" which sounds as the part of the statement which will stay as=20 universal .. for a short while (?). 20. 2.2.2: language subtags are permitted only if they are 3 characters (= a=20 permanent rigid position) based the anticipation of a non documented ISO=20 639 works. This is also a violation of the Internet standard process: the= =20 document in reference should be quoted and cannot be a draft. Language=20 extended subtags are the most active part of languages, yet the rigidity=20 imposed by the chosen format obliges to prevent their registration by IAN= A=20 (what is the very purpose of the document: to permit flexibility to suppo= rt=20 real network life, where ISO would be too slow). 21. 2.2.3: Script subtags follow the same rigid logic and constraints fro= m=20 the format. What happens if the memory waste of ISO 15924 (3 bytes lost)= =20 is corrected, or if another code element has a fixed 4 characters length= =20 in the future? 22. 2.2.4: I understand that all the regional language differences of the= =20 world are to be supported by the ISO 3166 alpha-3/digit-3 list. This mean= s=20 that regions like NY, TX or California are not entitled a code but the 56= =20 persons of Pitcairn Island yes? I doubt that disparity can hold very long= ,=20 all the more than ISO 3166-2 provides all the possibilities for a far mor= e=20 adequate granularity. 23. 2.2.9: There is a MUST in "there MUST be an attempt to register" whic= h=20 cannot be enforced if there is not a non-delaying procedure to verify tha= t=20 a language was attempted to be registered with ISO 639. Otherwise this pa= rt=20 is to be understood as a disguised way, concerted with ISO, to block name= s.=20 The concern on this point is high enough to see the Draft blocked. It see= ms=20 that the second paragraph is a smoky verbose replay of the same idea,=20 without any procedural description nor request/provision of formal proof.= =20 The general idea is precisely in opposition with the purpose of the=20 proposed RFC: to be able to register names not registered by ISO. This=20 amount to a legitimisation of censoring, and censoring against the very=20 intent of this document. 24. 2.2.9: registrations are left to a decision of appropriateness by=20 someone debating with undefined others for a matter without any importan= ce=20 on the network stability and security (documented in in part 4) non on th= e=20 end to end interoperability. This seems to amount to pure intellectual=20 censoring. 25. 2.3: recommendation 3 seems inappropriate. Aliases are aliases. All t= he=20 aliases must be equally supported because (a) they are aliases (b) to mak= e=20 sure developers develops correct code. 26. 2.4. "language tags always define a language as spoken by human being= =20 for communications of information to other human beings. Computer languag= es=20 =85 are explicitly excluded" has no ground in the Charter and in reality.= Web=20 Services relations are excluded which may speak limited languages. Coded=20 human languages should be supported: they fit the definition. 27. 2.4.1: in the canonicalization part "" is reminded as a deprecation=20 indicator, yet this is not documented earlier. It seems this is an extern= al=20 ISO practice. This should be documented in the format description part. A= ll=20 the more than this practice is counter intuitive "" being understood=20 intuitively as "-(nul)-". And the "" being used in IDN there could be som= e=20 homograph confusion to investigate. 28. 3: the reference to RFC 2434 is correct but the rest of the part 3=20 seems inappropriate. RFC 2434 says "If the IANA is expected to play a ro= le=20 in the management of a name-space the IANA must be given clear and concis= e=20 instructions describing that role". The part 3 is neither clear and conci= se=20 and is contradictory with the document which describes a IANA file to be=20 maintained by an IESG reviewer. The IESG having authority on the IANA, th= e=20 role of the IANA is to store and disseminate the current file version as=20 maintained by the reviewer. 29. 3.1: Description of "description" is clueless. It is a description bu= t=20 does not intend to be an English description but it is one. The addition=20 made in the IANA file are intended to be additions to corresponding=20 documented ISO tables. They MUST comply with the format of these tables=20 otherwise they add a disparity between the table and their IANA "appendix= ". 30. 3.1. includes a registry format description (OK) but also=20 considerations on the way the tags should be formed which have nothing to= =20 do in a file description. They should be moved into 2.4.1 31. 3.1. also includes direction to the Reviewer which should be presente= d=20 in a separate part from the format description. 32. 3.2. this part is not a IANA procedure but a long guidance for the=20 Reviewer and the Reviewing process participants, limited to current=20 possible cases. 33. 3.3 : Understanding the meaning of "Subtags required for stability an= d=20 to keep the registry synchronised" will probably be a source of long=20 debates. It should be documented. 34. 3.3. why a "MAY" concerning the "description, note and prefix fields= "=20 is not documented by conditions? Is that not a "CAN". 35. 3.3. the registration procedure is of extreme confusion and mixes the= =20 form to use, the lack of definition of the requester, the iana.org list=20 which is not introduced, the registration request which must be guessed, = a=20 non commented MAY, registration tricks, comments on probable behaviour of= =20 the reviewing list, digression on Slovenian, designation of the reviewer = by=20 the IESG, what should happen when the review period has elapsed without a= ny=20 guidance to the reviewer, that a IANA list Members and an IESG designated= =20 reviewer make an IETF decision, that the initial registrant has some mora= l=20 pre-eminence (under the form of a comment) and that languages are not=20 considered for registration on the fact they actually exist, but on their= =20 own (non documented) merits. 36. 3.4. Difficult to understand. The first sentence is probably inherite= d=20 from the former versions of the draft. "compatible with applications that= =20 process language tags according to this specification" seems to refer to=20 filtering which should be part of the of the second document produced by=20 the WG-ltru. 37. 3.4. The description of information to be maintained is clear, but th= e=20 format is not described. This permits IANA to freely change it or to=20 present it in HTML form. This does not help its automated reading. 38. 4. security considerations should not deal with users political=20 security outside of their network usage. Otherwise tons of such=20 considerations should be presented. 39. 4. An important security consideration is homographs. It is certainly= =20 possible to include part of text in a foreign language which look printed= =20 as in another language or having a different meaning or printing=20 (phishing). Concerns are also the double "-" which is specifically used b= y=20 the IANA code "xn". 40. 4. Fourth paragraph tend to say that specification of valid sub-tags= =20 MUST be available over the internet but that applications should take=20 possible DoS into consideration. This is an important indication on the w= ay=20 the Draft proposes the registry file to be used and accessed. It can be=20 read that applications can freely access it and proposed mirrors: this ma= y=20 impose on the IANA a load which will result in its permanent inability of= =20 service. 41. 5. character set consideration are contradictory: they say that=20 character a-z exist in most character sets (good news) [what means that=20 there are some where they do not exist] so there should not be character=20 set presentation issue [in the character set where they do not exist?].=20 Also the consideration only concerns the "display" what has a limited=20 interest if the a-z characters do not exist on the keyboard. But may be=20 this supposes that "intelligent people" use ascii compatible keyboards (s= ee=20 below). 42. 6. compatibility is preserved with RFC 3066 but not with evolution of= =20 ISO code elements. The XML Schema version 1.0 requirements are quoted but= =20 not documented. 43. 6. Stability. Confusion between document. This document does not=20 provide a mechanism but a format that can be used by the mechanism=20 described in the next document. This text has not been adapted after the = split. 44. 6. Validity. This document should define the IQ of the "intelligent=20 people" being considered or the collective IQ augmentation necessary to=20 understand the system ?? Please see the ideas of the one who created the= =20 NIC and grand fathered the RFC system (http://bootstrap.org). 45. 6. Extensibility such as presented actually results (in a very limite= d=20 way) from the underlying ISO codes. This is not the target of Charter whi= ch=20 is to permit scalability even when a code element it is not supported by = ISO. 46. 6. the document uses several times the term "extlang" but does not=20 defines it. 47. 6. last: added text for "" is not sufficient enough, or is missing in= =20 my version. CHARTER VS DRATF RELATED COMMENTS AND QUESTIONS 48. language preferences are uniquely understood in HTML, XML only. CLDR=20 are quoted in the charter and not quoted in the Draft. The Charter does n= ot=20 prevent other applications, systems to be supported. The Draft does not=20 allude to them. 49. The charter lists RFC 3066 problems. These problems are: (a)=20 stability there is a paragraph on the matter; (b) accessibility to the=20 underlying ISO standard this is definitely impeached by the format (no I= SO=20 3166-2, no other ISO 639 format than 2 or 3 characters no other script=20 description format than 4 characters, etc. as if the current ISO=20 presentation will never improve); (c) difficulty with registration and=20 acceptance: this could be improved by the subtag registration system but = it=20 seems to be made worse, due to the censoring rules introduced to prevent=20 non-ISO entries to be entered in the IANA non-ISO table; (e) lack of clea= r=20 guidance to identify script and region: scripts are Unicode only, region=20 are 2 letter Telex codes; (f) lack of parseability and well-formedness :=20 this has certainly been addressed [it seems to be both the major=20 improvement of the Draft =85 and the source of most of its problems due t= o=20 the rigidity it introduces]. 50. The main purpose of this Draft from the charter is to describe the IA= NA=20 registry to support the resolution of the above problems, and how=20 transition from RFC 3066. This is to be in a clear and concise way. RFC=20 3066 represents roughly 17.000 characters and the draft 70.000 (out of th= e=20 IETF format and verbose). This makes it confuse. From what I understand i= t=20 includes 3 parts: (a) the subtags file with a clear format (b) the=20 accompanying registration/update forms (c) the variant tables with a clea= r,=20 yet less precise format. From what I understand (a)(b) are the real=20 responsibility of the old aliased distribution list and of a Reviewer=20 designated by IESG with unlimited veto powers; (c) of the IESG when=20 reviewing RFCs requesting entries, and of the updating mechanism defined = by=20 these RFC. 51. it lists challenges to be addressed. Stability: "how the language tag= s=20 remains stable even if the underlying references should change". This mea= ns=20 a process where the tag name is unrelated to its underlying components,=20 like a domain name is stable even if the underlying IP address changes.=20 This is not provided. 52. it lists challenges to be addressed. Accessibility: "a simple way to=20 determine if a subtag is valid as of a given date. Like receiving a 404=20 when calling an expired domain name". Such a mechanism is not provided. 53. it lists challenges to be addressed. extensibility: this meant not=20 having to record millions of combinations. This is provided. To the price= =20 of format rigidity, impossible use of foreseen or existing ISO code=20 elements, and a censoring of the non-ISO extensions which may lead to mor= e=20 harassment. It also meant addition of the script in language tags. This i= s=20 permitted by the proposed format but to the detriment of other 4 letters=20 entries. Registration of non ISO scripts is not permitted. 54. it lists challenges to be addressed. "provide mechanism to support th= e=20 evolution of the underlying standards, in particular ISO 693-3, mechanism= s=20 to support variant registration and format extensions, as well as allowin= g=20 generative private use when necessary": I am not sure what "generative" m= ay=20 mean in here but I feel it is not supported, the rest is certainly oppose= d=20 by the chosen format; 55. it lists challenges to be addressed: "to specify a mechanism for easi= ly=20 identifying the role of each subtag in the language tag". This is=20 addressed by the Draft. But this challenge is contradictory with stabilit= y=20 challenge above. If a language tag displays an identifiable subtag, it=20 becomes by nature dependent from the underlying value of the subtag. I will study carefully the responses to this review before introducing my= =20 own Draft, to try to build if possible on the largest possible number o= f=20 consensual elements. My current thinking is totally different. It is an open framework which=20 respects the XML, HTML, CLDR requirements in welcoming your own (adapted)= =20 Draft, the ISO evolution, the requirements of an Internet for the people = of=20 the world by the people of the world, at an affordable cost, with an high= ly=20 innovative technical approach, a great care for operation security and=20 stability and in total continuity with the funding concept which gave us=20 thirty years of international public network stability. But I think the issues it rises are important enough to call on an=20 understanding, comments, and a support by all those concerned by a=20 "multilingual cyberspace", an equal cultural dignity empowerment on the=20 digital ecosystem and an open e-commerce. This is because language tags a= re=20 by nature the basic building blocks of the multilingual internet which is= =20 also to be user centric, multitechnology (convergence), multicontent=20 (information society), multilateral, as the WSIS shows it. jfcm=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 01:05:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18250; Tue, 5 Apr 2005 01:05:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIgO0-0000Eh-M4; Tue, 05 Apr 2005 01:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIgFR-00020E-V8; Tue, 05 Apr 2005 01:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIgFP-0001z3-V5 for ltru@megatron.ietf.org; Tue, 05 Apr 2005 01:05:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18205 for ; Tue, 5 Apr 2005 01:05:06 -0400 (EDT) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIgNU-0000DY-0V for ltru@ietf.org; Tue, 05 Apr 2005 01:13:29 -0400 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050405050452.ZBBR2192.mta9.adelphia.net@DEWELL>; Tue, 5 Apr 2005 01:04:52 -0400 Message-ID: <004f01c5399c$fab6e9e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0ADE7998@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: Registry in record-jar format Date: Mon, 4 Apr 2005 22:04:42 -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.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > REGISTERED tags from the RFC 3066 registry that are deprecated will be > maintained as grandfathered entries. > > The current text was added in the current draft to prevent the variant > subtag 'lojban'. Adding the word in caps above would fix that, I > believe. Thanks; that makes a lot more sense. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 01:12:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18851; Tue, 5 Apr 2005 01:12:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIgUe-0000Rh-5s; Tue, 05 Apr 2005 01:20:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIgME-0002Uf-CA; Tue, 05 Apr 2005 01:12:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIgMC-0002T0-Si for ltru@megatron.ietf.org; Tue, 05 Apr 2005 01:12:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18798 for ; Tue, 5 Apr 2005 01:12:07 -0400 (EDT) Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIgUI-0000Qs-6O for ltru@ietf.org; Tue, 05 Apr 2005 01:20:30 -0400 Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050405051159.GCDB5402.mta11.adelphia.net@DEWELL>; Tue, 5 Apr 2005 01:11:59 -0400 Message-ID: <005401c5399d$fc442420$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0ADE79A3@irvmbxw01.quest.com> Subject: Re: [Ltru] Date of deprecation (was: Re: Registry in record-jar format) Date: Mon, 4 Apr 2005 22:11:54 -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.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Addison Phillips wrote: >> What is the perceived benefit, for language tagging purposes, of >> including a field that indicates the date a given subtag was >> deprecated? > > Compatibility. You can set your tag processor to produce or validate > tags as at a certain date. It also might help people updating their > implementation figure out what has changed since the last time they > looked (since all of the information is in the registry). I'd never thought that someone would want to generate tags that were valid as of some past date, but not necessarily as of today. But yes, the additional date field would certainly make that possible. As for figuring out what has changed, with all the talk about record-jar vs. XML, I'm surprised nobody has mentioned making incremental deltas available -- say, in "diff" format. That would certainly solve the problem of having to re-download a 600 KB file. Agreeing to do such a thing would be the important point; the exact mechanism would be a detail. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 01:27:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19747; Tue, 5 Apr 2005 01:27:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIgin-0000xa-KT; Tue, 05 Apr 2005 01:35:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIgU3-0004AU-Ua; Tue, 05 Apr 2005 01:20:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIgU1-0004AM-Mq for ltru@megatron.ietf.org; Tue, 05 Apr 2005 01:20:13 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19209 for ; Tue, 5 Apr 2005 01:20:12 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050405051942.XDZK7277.mta10.adelphia.net@DEWELL> for ; Tue, 5 Apr 2005 01:19:42 -0400 Message-ID: <006001c5399f$101dd120$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050404180341.UQMT2135.mta2.adelphia.net@megatron.ietf.org> Date: Mon, 4 Apr 2005 22:19:37 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Date of deprecation (was: Re: Registry in record-jar format) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> There have already been complaints about the size of the >> registry (maybe not now, but once the ISO 639-3 codes are >> added). > > And some possible solutions, like an A..Z organization. Scott > said that IANA won't try to be smart unless we tell them what > to do (or that's how I interpreted his remark). The registry *is* in alphabetic order, of course -- but by subtag, not description. > If the size is a problem, then the number of 7000+ entries is > the key, the size of individual entries is secondary. Remember, we don't have this 7000+ problem until (a) ISO 639-3 comes along and (b) we go through this process all over again to incorporate support for it. > [ Is this use of "secondary" en-DE or still en ? ;-) ] That's how I would have said it. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 01:33:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20338; Tue, 5 Apr 2005 01:33:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIgou-00019X-9V; Tue, 05 Apr 2005 01:41:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIgeG-0004mi-Nd; Tue, 05 Apr 2005 01:30:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIgeE-0004mb-IL for ltru@megatron.ietf.org; Tue, 05 Apr 2005 01:30:46 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20116 for ; Tue, 5 Apr 2005 01:30:45 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050405053015.GQXF5402.mta11.adelphia.net@DEWELL> for ; Tue, 5 Apr 2005 01:30:15 -0400 Message-ID: <000801c539a0$89317e80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050404200514.WWXD5424.mta6.adelphia.net@megatron.ietf.org> Date: Mon, 4 Apr 2005 22:30:09 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Alternative matching algorithms (was: Re: Registry in record-jar format) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit John Cowan wrote: > I have yet to receive any comments on my proposed alternative > (not replacement) matching algorithm. People seemed to get lost in > the details of Date A and Date B. Date A and Date B were a different matter and were also important. We finally got a major sticking point resolved thanks to that. > To recap in a way that doesn't reawaken that: > > 1) Normalize the tag. > > 2) Create a quadruple (lang, script, region, variant), filling in missing components with *s. > > 3) Subtags match if they are the same or if either is "*". > > 4) Add {8, 4, 2, 1} to the figure of merit if the {lang, script, > region, variant} matches. That's basically a better-thought-out version of what I had in mind. I was thinking more along the lines of language first and everything else second, instead of ranking all four in strict order, because we actually don't know whether script or region or variant is more "important." The key aspect that we agree on is the need to take apart the tag and compare the pieces. For any parser that is built to handle RFC 3066bis tags, simple prefix matching will NOT be sufficient. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 01:36:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20548; Tue, 5 Apr 2005 01:36:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIgrf-0001Hr-S6; Tue, 05 Apr 2005 01:44:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIgj1-0006ZX-Fe; Tue, 05 Apr 2005 01:35:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIgj0-0006ZS-6p for ltru@megatron.ietf.org; Tue, 05 Apr 2005 01:35:42 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20494 for ; Tue, 5 Apr 2005 01:35:40 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050405053508.JAPC4618.mta13.adelphia.net@DEWELL> for ; Tue, 5 Apr 2005 01:35:08 -0400 Message-ID: <000f01c539a1$34485280$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050404212221.FWFF4900.mta8.adelphia.net@megatron.ietf.org> Date: Mon, 4 Apr 2005 22:34:56 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in RDF/XML format. X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > We could thus define that the record-jar registry uses a \uxxxx (or > similar) syntax to get the same effect in the registry as using a > Unicode encoding. In fact, we should probably define the that values > outside the range U+0000..U+007E use \u escaped hex syntax. None of this is relevant unless we also do away with the requirement to convert all descriptions to ASCII (Section 3.1). Should we be discussing that first? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 01:50:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21416; Tue, 5 Apr 2005 01:50:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIh56-0001gt-O3; Tue, 05 Apr 2005 01:58:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIguP-0001GO-VA; Tue, 05 Apr 2005 01:47:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIguO-0001GC-6R for ltru@megatron.ietf.org; Tue, 05 Apr 2005 01:47:28 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21233 for ; Tue, 5 Apr 2005 01:47:26 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050405054657.JJAX4618.mta13.adelphia.net@DEWELL> for ; Tue, 5 Apr 2005 01:46:57 -0400 Message-ID: <001601c539a2$dd7d78c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050404212221.FWFF4900.mta8.adelphia.net@megatron.ietf.org> Date: Mon, 4 Apr 2005 22:46:49 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in RDF/XML format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Misha Wolf wrote: > I think that derivate registries are only plausible if they > are obtained through automated transformations from the normative > one. This makes the inclusion of any additional information > (eg names in other languages) difficult, though not impossible. > Such additional information would have to be held separately and > merged (automatically) with the transform. > > Anything else (ie human tampering) is asking for trouble. I agree 100% with Misha. All of the various "alternative" formats I've generated so far -- record-jar, two flavors of XML, the HTML version on my Web site, and the C++ header file used in my generator and validator -- are generated programmatically from the normative version, which is currently vertical-bar. Judging by everything I'm hearing, that will change soon and record-jar will become the normative format. At some point I'll change the conversion programs (those that are still relevant, anyway) to read RJ instead of vertical-bar. Of course, this is just what I'm doing during the WG process. What IANA does, once it's in their hands, is up to them. Update: With no objections so far, it looks like the Wednesday update (the first RJ version) will incorporate all the points in my post of March 29, except that region code 200 (Czechoslovakia) will *not* be removed (but 172 will be). If anyone has other suggestions, please try to send them by 13:00 UTC Wednesday. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 03:26:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17859; Tue, 5 Apr 2005 03:26:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIiaa-0004ig-W4; Tue, 05 Apr 2005 03:35:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIiRk-0003BI-5Z; Tue, 05 Apr 2005 03:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIiRi-0003B8-Ak for ltru@megatron.ietf.org; Tue, 05 Apr 2005 03:25:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17811 for ; Tue, 5 Apr 2005 03:25:56 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIiZo-0004hZ-EA for ltru@ietf.org; Tue, 05 Apr 2005 03:34:20 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j357Pme9004791 for ; Tue, 5 Apr 2005 03:25:48 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j357PmGh224310 for ; Tue, 5 Apr 2005 03:25:48 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j357PmGj001251 for ; Tue, 5 Apr 2005 02:25:48 -0500 Received: from markdavis (sig-9-48-127-233.mts.ibm.com [9.48.127.233]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with SMTP id j357PWQJ000974; Tue, 5 Apr 2005 02:25:46 -0500 Message-ID: <009201c539b0$a91bb5c0$e97f3009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <004f01c5392d$96b541e0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Date of deprecation (was: Re: Registry in record-jarformat) Date: Tue, 5 Apr 2005 00:25:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id j357Pme9004791 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable > There have already been complaints about the size of the registry (mayb= e > not now, but once the ISO 639-3 codes are added). We should have a > demonstrably good reason for adding more stuff to it. Let me be a bit clearer. Right a whole class of characters have a comment= , with a common structure. Making the items in that comment into fields doesn't essentially change the size of the registry; it just regularizes that part of the format to make it machine-readable. If we are so concerned with the size of the registry that we don't want t= he information in that comment, we would delete it. But we're not. =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Monday, April 04, 2005 08:47 Subject: [Ltru] Re: Date of deprecation (was: Re: Registry in record-jarformat) > Mark Davis wrote: > > > If it is worth putting in a comment for every instance, it is worth > > making it a field, because then it can be parsed. > > Similarly, Frank Ellermann wrote: > > > Having both could make sense, date of introduction and date of > > last update. Some "whois" databases do it this way. > > I know it would be physically possible to add these additional date > fields. My question was, what is the benefit for language tagging? Ho= w > are these fields to be used in practice? > > There have already been complaints about the size of the registry (mayb= e > not now, but once the ISO 639-3 codes are added). We should have a > demonstrably good reason for adding more stuff to it. > > > For a case like i-klingon the LTRU registry could give the date of > > the registration, and later the date of the deprecation. At > > the moment i-klingon is still an officially registered tag. > > Tags that are deprecated don't become un-registered, as this seems to > imply. They just have a note attached to them that says, "You shouldn'= t > use this." > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 05:30:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28778; Tue, 5 Apr 2005 05:30:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIkWE-0000yw-Ho; Tue, 05 Apr 2005 05:38:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIkNy-0000R7-Af; Tue, 05 Apr 2005 05:30:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIkNn-0000OF-15 for ltru@megatron.ietf.org; Tue, 05 Apr 2005 05:30:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28759 for ; Tue, 5 Apr 2005 05:30:00 -0400 (EDT) Received: from web42003.mail.yahoo.com ([66.218.93.171]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DIkVo-0000y4-4d for ltru@ietf.org; Tue, 05 Apr 2005 05:38:26 -0400 Received: (qmail 65439 invoked by uid 60001); 5 Apr 2005 09:29:46 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=fYcirivleS5i76dH0bPFt195FVUPYCEbRkap1DVXjZaMz7ZTYEvSQcAcwqkfvZexI7BkZc3fQb2lhLHuXqfvLXnznzG+xIAx2JDcFq99labn29EI8ZCiEwj1x7cn9EAkFHMwkBLQWpAl6/SJPJVRiPlOqZiauwoe5871/U6ZjtA= ; Message-ID: <20050405092946.65437.qmail@web42003.mail.yahoo.com> Received: from [158.169.9.14] by web42003.mail.yahoo.com via HTTP; Tue, 05 Apr 2005 10:29:46 BST Date: Tue, 5 Apr 2005 10:29:46 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: RE: [Ltru] Re: Language transformation To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 8bit Back from a long weekend ... Comments to posting by Cowan, Phillips, Constable and Ewell -----> 1) In short - Mentioning It is enough just to mention transliteration with an example. No need to explain it. - Transliteration Registry A separated "thing" (RFC, orgazition, extension, whatever) should take care of registering the transliteration; so one can find meaning to the tag. The "thing" will have to follow the rules in 3066bis; e.g., max size, availability of the subtag, variant registration procedure, etc. Hopefully (no guarantee), a transliteration tag already in the "thing" should be easier to register in 3066bis. I am working in this. -----> 2) In long >[Cowan] >This overstates the case. In order to make practical use of such orthographies, >they must be defined somewhere, and if the users of trans*tions find it >useful to have a registry of these things, then LTRU has nothing to say >about it. Yes. >[Phillips] >Would it be sufficient to modify this to say: > >Dialect or other divisions or variations within a language, its orthography, writing system, >regional or historical usage, transliteration, or other transformation or distinguishing >variation may be registered as variant subtags. An example is the 'scouse' subtag >(the Scouse dialect of English). > Yes. With example as suggested by Phillips below. >Phrased another way, why should the RFC draft attempt to explain transmogrification any more than >some other language variation? The draft as it sits is not very specific precisely to allow for a >wide range of variation to be considered or proposed for registration. It should not try to explain it. Just to mention it, so people know how to mark transliteration. [Constable] >I agree that it would be good to mention transliteration, but not to >explain it, both because other comparable things aren't explained, and >because -- as Tomas as pointed out several times -- trying to come up >with an explanation that everyone would agree to is inviting polemic >debates. Yes. [Phillips] >I think your suggestion to mention transliteration as a possible kind of >variant, and perhaps something like zh-wadegile as a hypothetical >example is adequate for now. Yes. [Ewell] >What concerns me is the idea of a Transliteration Board that maintains >its own registry of transliterations, and tells the Language Subtag >Reviewer and ietf-languages which variant subtags to register, based on >what they have already approved for their registry. > >If Tomas wants a separate organization to be responsible for vetting >these, he should pursue the extension-RFC path, which does exactly that, >but requires the use of a singleton such as -t-. If he wants to be able >to write "zh-wadegile" without the -t-, then he is talking about >variants, and those will be proposed and debated and approved (or >rejected) using the same process that will apply to all other variants. Yes. Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 06:22:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03266; Tue, 5 Apr 2005 06:22:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIlKL-0002ln-OS; Tue, 05 Apr 2005 06:30:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlBW-0002ZZ-Ir; Tue, 05 Apr 2005 06:21:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlBV-0002ZR-7n for ltru@megatron.ietf.org; Tue, 05 Apr 2005 06:21:25 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03214 for ; Tue, 5 Apr 2005 06:21:21 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIl8q-0007b6-1R for ltru@lists.ietf.org; Tue, 05 Apr 2005 12:18:40 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 12:18:40 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 12:18:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 06:25:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03433; Tue, 5 Apr 2005 06:25:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIlNT-0002wX-2X; Tue, 05 Apr 2005 06:33:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlDX-0002kK-5G; Tue, 05 Apr 2005 06:23:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlDV-0002kC-MY for ltru@megatron.ietf.org; Tue, 05 Apr 2005 06:23:29 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03306 for ; Tue, 5 Apr 2005 06:23:26 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DIlAy-0007sO-Ek for ltru@lists.ietf.org; Tue, 05 Apr 2005 12:20:52 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 12:20:52 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 12:20:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 06:37:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04441; Tue, 5 Apr 2005 06:37:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIlZT-0003Jo-7p; Tue, 05 Apr 2005 06:46:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlKH-0003QQ-70; Tue, 05 Apr 2005 06:30:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlKG-0003QL-Jw for ltru@megatron.ietf.org; Tue, 05 Apr 2005 06:30:28 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03859 for ; Tue, 5 Apr 2005 06:30:25 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIlI0-0000Px-PY for ltru@lists.ietf.org; Tue, 05 Apr 2005 12:28:08 +0200 Received: from du-001-068.access.de.clara.net ([212.82.227.68]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 12:28:08 +0200 Received: from nobody by du-001-068.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 12:28:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: du-001-068.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 06:41:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04622; Tue, 5 Apr 2005 06:41:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIlcq-0003PP-DK; Tue, 05 Apr 2005 06:49:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlMv-0003Wh-Lr; Tue, 05 Apr 2005 06:33:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlMu-0003Wc-4j for ltru@megatron.ietf.org; Tue, 05 Apr 2005 06:33:12 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04092 for ; Tue, 5 Apr 2005 06:33:08 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DIlKS-0000hF-MC for ltru@lists.ietf.org; Tue, 05 Apr 2005 12:30:40 +0200 Received: from du-001-068.access.de.clara.net ([212.82.227.68]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 12:30:40 +0200 Received: from nobody by du-001-068.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 12:30:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 11 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: du-001-068.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 06:43:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04836; Tue, 5 Apr 2005 06:43:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIlf3-0003S8-9u; Tue, 05 Apr 2005 06:51:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlWf-0004up-Rv; Tue, 05 Apr 2005 06:43:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlWe-0004sw-Ib for ltru@megatron.ietf.org; Tue, 05 Apr 2005 06:43:16 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04809 for ; Tue, 5 Apr 2005 06:43:13 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DIlU6-0001rz-Qy for ltru@lists.ietf.org; Tue, 05 Apr 2005 12:40:38 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 12:40:38 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 12:40:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 06:55:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05753; Tue, 5 Apr 2005 06:55:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIlqN-0003tr-9H; Tue, 05 Apr 2005 07:03:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlgM-00085q-Ey; Tue, 05 Apr 2005 06:53:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlgL-00085l-CY for ltru@megatron.ietf.org; Tue, 05 Apr 2005 06:53:17 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05608 for ; Tue, 5 Apr 2005 06:53:14 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DIldn-00037p-Mm for ltru@lists.ietf.org; Tue, 05 Apr 2005 12:50:39 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 12:50:39 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 12:50:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 07:08:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06640; Tue, 5 Apr 2005 07:08:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIm2v-0004IW-MT; Tue, 05 Apr 2005 07:16:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlq9-00010m-HP; Tue, 05 Apr 2005 07:03:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlq8-00010h-Mw for ltru@megatron.ietf.org; Tue, 05 Apr 2005 07:03:24 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06173 for ; Tue, 5 Apr 2005 07:03:21 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DIlnT-0004Ye-BM for ltru@lists.ietf.org; Tue, 05 Apr 2005 13:00:39 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 13:00:39 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 13:00:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 07:17:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07403; Tue, 5 Apr 2005 07:17:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DImC8-0004cR-DK; Tue, 05 Apr 2005 07:26:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlzw-0002TN-Bp; Tue, 05 Apr 2005 07:13:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIlzv-0002TH-1X for ltru@megatron.ietf.org; Tue, 05 Apr 2005 07:13:31 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07131 for ; Tue, 5 Apr 2005 07:13:27 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DIlxB-0005y7-0G for ltru@lists.ietf.org; Tue, 05 Apr 2005 13:10:41 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 13:10:40 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 13:10:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 07:26:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08521; Tue, 5 Apr 2005 07:26:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DImL3-0004xd-91; Tue, 05 Apr 2005 07:35:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIm86-0004J1-TO; Tue, 05 Apr 2005 07:21:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIm84-0004In-Qi for ltru@megatron.ietf.org; Tue, 05 Apr 2005 07:21:57 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07877 for ; Tue, 5 Apr 2005 07:21:50 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIm5w-0007I4-P9 for ltru@lists.ietf.org; Tue, 05 Apr 2005 13:19:44 +0200 Received: from du-001-102.access.de.clara.net ([212.82.227.102]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 13:19:44 +0200 Received: from nobody by du-001-102.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 13:19:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 12 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: du-001-102.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 07:30:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08698; Tue, 5 Apr 2005 07:30:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DImOU-000546-K2; Tue, 05 Apr 2005 07:38:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIm9L-0004YC-1N; Tue, 05 Apr 2005 07:23:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIm9J-0004Y2-0H for ltru@megatron.ietf.org; Tue, 05 Apr 2005 07:23:13 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08164 for ; Tue, 5 Apr 2005 07:23:09 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DIm6p-0007Mo-KA for ltru@lists.ietf.org; Tue, 05 Apr 2005 13:20:39 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 13:20:39 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 13:20:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 07:33:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08849; Tue, 5 Apr 2005 07:33:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DImRE-0005CS-NR; Tue, 05 Apr 2005 07:41:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImIs-0005TV-2E; Tue, 05 Apr 2005 07:33:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImIq-0005S3-7F for ltru@megatron.ietf.org; Tue, 05 Apr 2005 07:33:04 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08839 for ; Tue, 5 Apr 2005 07:33:02 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DImGV-0000BD-Sq for ltru@lists.ietf.org; Tue, 05 Apr 2005 13:30:39 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 13:30:39 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 13:30:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 07:39:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09204; Tue, 5 Apr 2005 07:39:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DImXE-0005Nu-Bo; Tue, 05 Apr 2005 07:47:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImO9-0008Cb-II; Tue, 05 Apr 2005 07:38:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImO9-0008CU-0J for ltru@megatron.ietf.org; Tue, 05 Apr 2005 07:38:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09124 for ; Tue, 5 Apr 2005 07:38:31 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DImWG-0005MV-PJ for ltru@ietf.org; Tue, 05 Apr 2005 07:46:57 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 05 Apr 2005 07:38:22 -0400 id 00590052.425278AE.00000A61 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for SyntaxSpecifications: ABNF' to Draft Standard Date: Tue, 5 Apr 2005 07:38:07 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749C97E@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <42526630.3FA9@xyzzy.claranet.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Frank Ellermann [mailto:nobody@xyzzy.claranet.de] > Sent: Tuesday, April 05, 2005 6:19 AM > To: ltru@ietf.org > Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for > SyntaxSpecifications: ABNF' to Draft Standard > > > Randy Presuhn wrote: > > > The references in the registry i-d should be changed > > accordingly. > > When 2234bis gets an RfC number, it's not yet in the in-queue: > It can (and should) be cited in its current form. It'll become an RFC before the LTRU documents do. The RFC Editor can then update the reference to use the RFC number when it's available. Here's an example reference to something that had been an I-D: [7] Arends, R., "Resource Records for the DNS Security Extensions", Internet-Draft draft-ietf-dnsext-dnssec-records-11, October 2004. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 07:40:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09268; Tue, 5 Apr 2005 07:40:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DImXr-0005OU-Qu; Tue, 05 Apr 2005 07:48:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImOc-0008D8-M1; Tue, 05 Apr 2005 07:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImOb-0008D3-TV for ltru@megatron.ietf.org; Tue, 05 Apr 2005 07:39:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09172 for ; Tue, 5 Apr 2005 07:39:00 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DImWj-0005NI-BV for ltru@ietf.org; Tue, 05 Apr 2005 07:47:26 -0400 Received: from lns-p19-8-idf-82-249-11-10.adsl.proxad.net ([82.249.11.10] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DImOY-0002sI-JW; Tue, 05 Apr 2005 04:38:59 -0700 Message-Id: <6.1.2.0.2.20050405122227.03f5beb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 05 Apr 2005 13:38:46 +0200 To: "Doug Ewell" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Registry in RDF/XML format In-Reply-To: <001601c539a2$dd7d78c0$030aa8c0@DEWELL> References: <20050404212221.FWFF4900.mta8.adelphia.net@megatron.ietf.org> <001601c539a2$dd7d78c0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 On 07:46 05/04/2005, Doug Ewell said: >Of course, this is just what I'm doing during the WG process. What IANA >does, once it's in their hands, is up to them. No. This is to us to specify. In the IANA consideration part. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 08:02:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11068; Tue, 5 Apr 2005 08:02:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DImtK-0006Lf-2N; Tue, 05 Apr 2005 08:10:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImcq-0001Yk-9b; Tue, 05 Apr 2005 07:53:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImcp-0001Ya-9f for ltru@megatron.ietf.org; Tue, 05 Apr 2005 07:53:43 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10245 for ; Tue, 5 Apr 2005 07:53:38 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DImZs-00033G-Tp for ltru@lists.ietf.org; Tue, 05 Apr 2005 13:50:40 +0200 Received: from du-001-068.access.de.clara.net ([212.82.227.68]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 13:50:40 +0200 Received: from nobody by du-001-068.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 13:50:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 11 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: du-001-068.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 08:04:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11247; Tue, 5 Apr 2005 08:04:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DImv5-0006Ol-BX; Tue, 05 Apr 2005 08:12:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImma-0002kT-B7; Tue, 05 Apr 2005 08:03:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImmZ-0002kO-Db for ltru@megatron.ietf.org; Tue, 05 Apr 2005 08:03:47 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11205 for ; Tue, 5 Apr 2005 08:03:45 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DImjX-0004T8-IT for ltru@lists.ietf.org; Tue, 05 Apr 2005 14:00:39 +0200 Received: from du-001-068.access.de.clara.net ([212.82.227.68]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 14:00:39 +0200 Received: from nobody by du-001-068.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 14:00:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: du-001-068.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 08:14:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12724; Tue, 5 Apr 2005 08:14:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIn50-0006zR-W8; Tue, 05 Apr 2005 08:22:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImw8-00052X-LA; Tue, 05 Apr 2005 08:13:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DImw7-00052S-0j for ltru@megatron.ietf.org; Tue, 05 Apr 2005 08:13:39 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12647 for ; Tue, 5 Apr 2005 08:13:37 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DImtF-00060C-5s for ltru@lists.ietf.org; Tue, 05 Apr 2005 14:10:41 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 14:10:41 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 14:10:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 08:23:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14047; Tue, 5 Apr 2005 08:23:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DInEH-0007Q7-Bm; Tue, 05 Apr 2005 08:32:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIn5u-0002T3-AV; Tue, 05 Apr 2005 08:23:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIn5s-0002RD-PI for ltru@megatron.ietf.org; Tue, 05 Apr 2005 08:23:45 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14031 for ; Tue, 5 Apr 2005 08:23:42 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DIn2t-0007QT-Lr for ltru@lists.ietf.org; Tue, 05 Apr 2005 14:20:40 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 14:20:39 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 14:20:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 08:34:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14806; Tue, 5 Apr 2005 08:34:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DInO4-0007kC-W1; Tue, 05 Apr 2005 08:42:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DInEr-0005tn-ES; Tue, 05 Apr 2005 08:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DInEp-0005ti-Mh for ltru@megatron.ietf.org; Tue, 05 Apr 2005 08:32:59 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14727 for ; Tue, 5 Apr 2005 08:32:57 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DInCd-0000WZ-Dv for ltru@lists.ietf.org; Tue, 05 Apr 2005 14:30:43 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 14:30:43 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 14:30:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 08:45:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15891; Tue, 5 Apr 2005 08:45:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DInYr-0008Dz-3Q; Tue, 05 Apr 2005 08:53:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DInP2-0006bO-19; Tue, 05 Apr 2005 08:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DInOx-0006bJ-Af for ltru@megatron.ietf.org; Tue, 05 Apr 2005 08:43:30 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15670 for ; Tue, 5 Apr 2005 08:43:24 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DInMG-0001qA-KJ for ltru@lists.ietf.org; Tue, 05 Apr 2005 14:40:40 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 14:40:40 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 14:40:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 12:19:28 +0200 Organization: Lines: 10 Message-ID: <42526630.3FA9@xyzzy.claranet.de> References: <010c01c53966$1158b200$7f1afea9@oemcomputer> 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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Fw: Protocol Action: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > The references in the registry i-d should be changed > accordingly. When 2234bis gets an RfC number, it's not yet in the in-queue: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 10:09:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23083; Tue, 5 Apr 2005 10:09:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIosQ-0002mg-PI; Tue, 05 Apr 2005 10:17:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIohK-0000gV-Hw; Tue, 05 Apr 2005 10:06:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIohI-0000gQ-9N for ltru@megatron.ietf.org; Tue, 05 Apr 2005 10:06:28 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22713 for ; Tue, 5 Apr 2005 10:06:25 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIoe0-0007FJ-3F for ltru@lists.ietf.org; Tue, 05 Apr 2005 16:03:04 +0200 Received: from du-001-102.access.de.clara.net ([212.82.227.102]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 16:03:04 +0200 Received: from nobody by du-001-102.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 16:03:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 16:03:55 +0200 Organization: Lines: 21 Message-ID: <42529ACB.7D7A@xyzzy.claranet.de> References: <20050404180341.UQMT2135.mta2.adelphia.net@megatron.ietf.org> <006001c5399f$101dd120$030aa8c0@DEWELL> 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: du-001-102.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Date of deprecation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Doug Ewell wrote: > The registry *is* in alphabetic order, of course -- but by > subtag, not description. Sure, but at the moment it's in one file. For 7000+ languages it might be better to have one file per tag, and an additional directory view sorted by date, not only by "filename" (= tag). Or maybe 26 A..Z files for the languages, plus another file for the rest (scripts, regions, variants, grandfathered entries). > we don't have this 7000+ problem until (a) ISO 639-3 comes > along and (b) we go through this process all over again to > incorporate support for it. One of our chairs proposed to prepare the LTRU registry as far as possible for this case. IMHO a good idea, of course not for what you plan to publish tomorrow. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 10:43:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26311; Tue, 5 Apr 2005 10:43:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIpOy-0003x5-M2; Tue, 05 Apr 2005 10:51:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIpEY-00069R-Kl; Tue, 05 Apr 2005 10:40:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIpEW-00069J-PO for ltru@megatron.ietf.org; Tue, 05 Apr 2005 10:40:48 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26169 for ; Tue, 5 Apr 2005 10:40:45 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050405144016.XILW4618.mta13.adelphia.net@DEWELL> for ; Tue, 5 Apr 2005 10:40:16 -0400 Message-ID: <003301c539ed$613012a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050404212221.FWFF4900.mta8.adelphia.net@megatron.ietf.org> <001601c539a2$dd7d78c0$030aa8c0@DEWELL> <6.1.2.0.2.20050405122227.03f5beb0@mail.jefsey.com> Date: Tue, 5 Apr 2005 07:40:13 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in RDF/XML format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: >> Of course, this is just what I'm doing during the WG process. What >> IANA does, once it's in their hands, is up to them. > > No. This is to us to specify. In the IANA consideration part. Can we specify *how* they build the alternative-format registry files? If so, great. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 10:50:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26818; Tue, 5 Apr 2005 10:50:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIpVx-00048y-WA; Tue, 05 Apr 2005 10:58:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIpL9-0006zu-Ev; Tue, 05 Apr 2005 10:47:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIpL7-0006zk-UC for ltru@megatron.ietf.org; Tue, 05 Apr 2005 10:47:38 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26618 for ; Tue, 5 Apr 2005 10:47:35 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050405144706.XTLI4618.mta13.adelphia.net@DEWELL> for ; Tue, 5 Apr 2005 10:47:06 -0400 Message-ID: <003901c539ee$55158300$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 5 Apr 2005 07:47:03 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Date of deprecation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> The registry *is* in alphabetic order, of course -- but by >> subtag, not description. > > Sure, but at the moment it's in one file. For 7000+ languages > it might be better to have one file per tag, and an additional > directory view sorted by date, not only by "filename" (= tag). > > Or maybe 26 A..Z files for the languages, plus another file for > the rest (scripts, regions, variants, grandfathered entries). OK, you switched directions on me. I didn't read "an A..Z organization" as a call to split the registry into multiple files. >> we don't have this 7000+ problem until (a) ISO 639-3 comes >> along and (b) we go through this process all over again to >> incorporate support for it. > > One of our chairs proposed to prepare the LTRU registry as far > as possible for this case. IMHO a good idea, of course not for > what you plan to publish tomorrow. I missed something there. Did Randy or Martin say something about working on the registry itself? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 12:07:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04153; Tue, 5 Apr 2005 12:07:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIqiw-00075I-1G; Tue, 05 Apr 2005 12:16:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIqZZ-0004I3-IG; Tue, 05 Apr 2005 12:06:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIqZW-0004Hy-QN for ltru@megatron.ietf.org; Tue, 05 Apr 2005 12:06:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04041 for ; Tue, 5 Apr 2005 12:06:31 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIqhg-00073F-Q3 for ltru@ietf.org; Tue, 05 Apr 2005 12:15:02 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 09:06:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Date of deprecation Date: Tue, 5 Apr 2005 09:06:23 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7F11@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Date of deprecation Thread-Index: AcU57sNjH8ak9pkCQkWIoPBMHKjyHgACo4aw From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 05 Apr 2005 16:06:24.0348 (UTC) FILETIME=[6A5459C0:01C539F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1347334379==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 --===============1347334379== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiA+IE9uZSBvZiBvdXIgY2hhaXJzIHByb3Bvc2VkIHRvIHByZXBhcmUgdGhlIExUUlUgcmVnaXN0 cnkgYXMgZmFyDQo+ID4gYXMgcG9zc2libGUgZm9yIHRoaXMgY2FzZS4gIElNSE8gYSBnb29kIGlk ZWEsIG9mIGNvdXJzZSBub3QgZm9yDQo+ID4gd2hhdCB5b3UgcGxhbiB0byBwdWJsaXNoIHRvbW9y cm93Lg0KPiANCj4gSSBtaXNzZWQgc29tZXRoaW5nIHRoZXJlLiAgRGlkIFJhbmR5IG9yIE1hcnRp biBzYXkgc29tZXRoaW5nIGFib3V0DQo+IHdvcmtpbmcgb24gdGhlIHJlZ2lzdHJ5IGl0c2VsZj8N Cg0KVG8gcHJlcGFyZSB0aGUgMzA2NmJpcyByZWdpbWUgdG8gaGFuZGxlIElTTyA2MzktMyBhcyBt dWNoIGFzIHBvc3NpYmxlIGlzIHdoYXQgSSBiZWxpZXZlIEZyYW5rIG1lYW5zLg0KDQpBZGRpc29u DQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBT b2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3Jv dXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFy Y2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRy dS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3RzLmlldGYu b3JnXSBPbg0KPiBCZWhhbGYgT2YgRG91ZyBFd2VsbA0KPiBTZW50OiBtYXJkaSA1IGF2cmlsIDIw MDUgMDc6NDcNCj4gVG86IExUUlUgV29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBbTHRydV0gUmU6 IERhdGUgb2YgZGVwcmVjYXRpb24NCj4gDQo+IEZyYW5rIEVsbGVybWFubiA8bm9ib2R5IGF0IHh5 enp5IGRvdCBjbGFyYW5ldCBkb3QgZGU+IHdyb3RlOg0KPiANCj4gPj4gVGhlIHJlZ2lzdHJ5ICpp cyogaW4gYWxwaGFiZXRpYyBvcmRlciwgb2YgY291cnNlIC0tIGJ1dCBieQ0KPiA+PiBzdWJ0YWcs IG5vdCBkZXNjcmlwdGlvbi4NCj4gPg0KPiA+IFN1cmUsIGJ1dCBhdCB0aGUgbW9tZW50IGl0J3Mg aW4gb25lIGZpbGUuICBGb3IgNzAwMCsgbGFuZ3VhZ2VzDQo+ID4gaXQgbWlnaHQgYmUgYmV0dGVy IHRvIGhhdmUgb25lIGZpbGUgcGVyIHRhZywgYW5kIGFuIGFkZGl0aW9uYWwNCj4gPiBkaXJlY3Rv cnkgdmlldyBzb3J0ZWQgYnkgZGF0ZSwgbm90IG9ubHkgYnkgImZpbGVuYW1lIiAoPSB0YWcpLg0K PiA+DQo+ID4gT3IgbWF5YmUgMjYgQS4uWiBmaWxlcyBmb3IgdGhlIGxhbmd1YWdlcywgcGx1cyBh bm90aGVyIGZpbGUgZm9yDQo+ID4gdGhlIHJlc3QgKHNjcmlwdHMsIHJlZ2lvbnMsIHZhcmlhbnRz LCBncmFuZGZhdGhlcmVkIGVudHJpZXMpLg0KPiANCj4gT0ssIHlvdSBzd2l0Y2hlZCBkaXJlY3Rp b25zIG9uIG1lLiAgSSBkaWRuJ3QgcmVhZCAiYW4gQS4uWiBvcmdhbml6YXRpb24iDQo+IGFzIGEg Y2FsbCB0byBzcGxpdCB0aGUgcmVnaXN0cnkgaW50byBtdWx0aXBsZSBmaWxlcy4NCj4gDQo+ID4+ IHdlIGRvbid0IGhhdmUgdGhpcyA3MDAwKyBwcm9ibGVtIHVudGlsIChhKSBJU08gNjM5LTMgY29t ZXMNCj4gPj4gYWxvbmcgYW5kIChiKSB3ZSBnbyB0aHJvdWdoIHRoaXMgcHJvY2VzcyBhbGwgb3Zl ciBhZ2FpbiB0bw0KPiA+PiBpbmNvcnBvcmF0ZSBzdXBwb3J0IGZvciBpdC4NCj4gPg0KPiA+IE9u ZSBvZiBvdXIgY2hhaXJzIHByb3Bvc2VkIHRvIHByZXBhcmUgdGhlIExUUlUgcmVnaXN0cnkgYXMg ZmFyDQo+ID4gYXMgcG9zc2libGUgZm9yIHRoaXMgY2FzZS4gIElNSE8gYSBnb29kIGlkZWEsIG9m IGNvdXJzZSBub3QgZm9yDQo+ID4gd2hhdCB5b3UgcGxhbiB0byBwdWJsaXNoIHRvbW9ycm93Lg0K PiANCj4gSSBtaXNzZWQgc29tZXRoaW5nIHRoZXJlLiAgRGlkIFJhbmR5IG9yIE1hcnRpbiBzYXkg c29tZXRoaW5nIGFib3V0DQo+IHdvcmtpbmcgb24gdGhlIHJlZ2lzdHJ5IGl0c2VsZj8NCj4gDQo+ IC1Eb3VnIEV3ZWxsDQo+ICBGdWxsZXJ0b24sIENhbGlmb3JuaWENCj4gIGh0dHA6Ly91c2Vycy5h ZGVscGhpYS5uZXQvfmRld2VsbC8NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBs aXN0cy5pZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s dHJ1DQoNCg== --===============1347334379== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1347334379==-- From ltru-bounces@ietf.org Tue Apr 5 12:08:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04180; Tue, 5 Apr 2005 12:08:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIqj8-00075Z-6K; Tue, 05 Apr 2005 12:16:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIqXE-0003z4-8i; Tue, 05 Apr 2005 12:04:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIqXD-0003yt-4n for ltru@megatron.ietf.org; Tue, 05 Apr 2005 12:04:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03915 for ; Tue, 5 Apr 2005 12:04:08 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIqfM-0006xv-RW for ltru@ietf.org; Tue, 05 Apr 2005 12:12:38 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 09:03:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Language transformation Date: Tue, 5 Apr 2005 09:03:52 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE7F0D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU5wiNYriyNjHFGR4uPl0v3vWX/OQANstbg From: "Addison Phillips" To: "M.T. Carrasco Benitez" , X-OriginalArrivalTime: 05 Apr 2005 16:03:52.0734 (UTC) FILETIME=[0FF5E3E0:01C539F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable These changes are going into the next editor's copy right now, along = with record-jar format and should be visible shortly for review. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of M.T. Carrasco Benitez > Sent: mardi 5 avril 2005 02:30 > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Language transformation >=20 > Back from a long weekend ... >=20 > Comments to posting by Cowan, Phillips, Constable and Ewell >=20 > -----> 1) In short >=20 > - Mentioning > It is enough just to mention transliteration with an example. No need = to > explain it. >=20 > - Transliteration Registry > A separated "thing" (RFC, orgazition, extension, whatever) should take > care of > registering the transliteration; so one can find meaning to the tag. > The "thing" will have to follow the rules in 3066bis; e.g., max size, > availability > of the subtag, variant registration procedure, etc. Hopefully (no > guarantee), a > transliteration tag already in the "thing" should be easier to = register in > 3066bis. > I am working in this. >=20 > -----> 2) In long >=20 > >[Cowan] > >This overstates the case. In order to make practical use of such > orthographies, > >they must be defined somewhere, and if the users of trans*tions find = it > >useful to have a registry of these things, then LTRU has nothing to = say > >about it. >=20 > Yes. >=20 > >[Phillips] > >Would it be sufficient to modify this to say: >=20 > > > >Dialect or other divisions or variations within a language, its > orthography, writing system, > >regional or historical usage, transliteration, or other = transformation or > distinguishing > >variation may be registered as variant subtags. An example is the > 'scouse' subtag > >(the Scouse dialect of English). > > >=20 > Yes. With example as suggested by Phillips below. >=20 > >Phrased another way, why should the RFC draft attempt to explain > transmogrification any more than >=20 > >some other language variation? The draft as it sits is not very = specific > precisely to allow for a >=20 > >wide range of variation to be considered or proposed for = registration. >=20 > It should not try to explain it. Just to mention it, so people know = how to > mark transliteration. >=20 > [Constable] > >I agree that it would be good to mention transliteration, but not to > >explain it, both because other comparable things aren't explained, = and > >because -- as Tomas as pointed out several times -- trying to come up > >with an explanation that everyone would agree to is inviting polemic > >debates. >=20 > Yes. >=20 > [Phillips] > >I think your suggestion to mention transliteration as a possible kind = of > >variant, and perhaps something like zh-wadegile as a hypothetical > >example is adequate for now. >=20 > Yes. >=20 > [Ewell] > >What concerns me is the idea of a Transliteration Board that = maintains > >its own registry of transliterations, and tells the Language Subtag > >Reviewer and ietf-languages which variant subtags to register, based = on > >what they have already approved for their registry. > > > >If Tomas wants a separate organization to be responsible for vetting > >these, he should pursue the extension-RFC path, which does exactly = that, > >but requires the use of a singleton such as -t-. If he wants to be = able > >to write "zh-wadegile" without the -t-, then he is talking about > >variants, and those will be proposed and debated and approved (or > >rejected) using the same process that will apply to all other = variants. >=20 > Yes. >=20 > Regards > Tomas >=20 >=20 > Send instant messages to your online friends = http://uk.messenger.yahoo.com >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 13:20:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10309; Tue, 5 Apr 2005 13:20:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIrrA-0001Ko-B1; Tue, 05 Apr 2005 13:28:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIrYw-0000k4-Ga; Tue, 05 Apr 2005 13:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIrYu-0000je-CD for ltru@megatron.ietf.org; Tue, 05 Apr 2005 13:10:01 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09485 for ; Tue, 5 Apr 2005 13:09:56 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIrVA-0007g8-5Z for ltru@lists.ietf.org; Tue, 05 Apr 2005 19:06:08 +0200 Received: from du-001-171.access.de.clara.net ([212.82.227.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 19:06:08 +0200 Received: from nobody by du-001-171.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 19:06:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 19:03:19 +0200 Organization: Lines: 72 Message-ID: <4252C4D7.5EDF@xyzzy.claranet.de> References: <004c01c5392c$b2b0c280$030aa8c0@DEWELL> <42517E0D.EF2@xyzzy.claranet.de> <20050404184906.GB7640@skunk.reutershealth.com> <4251AAB9.2BAA@xyzzy.claranet.de> <20050404225807.GE7640@skunk.reutershealth.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: du-001-171.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Matching metrics (was: Registry in record-jar format) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit John Cowan wrote: > I didn't choose powers of 2 capriciously. Yes, we have to test the effects of different metrics. I've created a very quick and very dirty script for this purpose, adding other metrics or more test cases would be easy, please tell me if you have some good candidates. At the moment I check four + five against four tags: column 1 is en-scouse column 2 is en-GB-scouse column 3 is en-Latn-GB-scouse column 4 is en-Latn-scouse Here's a result for your metrics: en-scouse 9 9 9 9 en-GB-scouse 9 11 11 9 en-Latn-GB-scouse 9 11 15 13 en-Latn-scouse 9 9 13 13 xx-Latn-GB-scouse 1 3 7 5 en-Latn-GB 8 10 14 12 en-Latn-US 8 8 12 12 en-Latn-US-scouse 9 9 13 13 en-Brai-GB-scouse 9 11 11 9 I've added 0 for '*' = '*' and no match. Otherwise 8/4/2/1, is this what you wanted ? Your metrics has apparently a problem with en-Latn-US-scouse: If one side wants en-GB-scouse, and the other side offers en-Latn-US-scouse (9) or en-Latn-GB (10), and it also has en-Brai-GB-scouse (11), then en-Brai-GB-scouse "wins". All in the 2nd column for en-GB-scouse. In the 3rd column for en-Latn-GB-scouse you see the expected but odd effect, where en-GB-Latn (14) would match before an also available en-Latn-US-scouse (13). > Your algorithm would prefer "ru-latn-1901" to "de" when > matching against "de-Latn-1901". Not okay, but not completely unintentional, for some languages I can guess what the text is about, as long as it's Latn: The combined power of forgotten school Latin plus miserable French sometimes helps with es or pt. But with ru I'd be lost - with luck I can decode some Cyrl. For fy my chances are lousy, for dk or nl it's better than zero. Here's the result with my metrics (as you have shown it's bad): en-scouse 5 5 5 5 en-GB-scouse 5 7 7 5 en-Latn-GB-scouse 5 7 10 8 en-Latn-scouse 5 5 8 8 xx-Latn-GB-scouse 1 3 6 4 en-Latn-GB 4 6 9 7 en-Latn-US 4 4 7 7 en-Latn-US-scouse 5 5 8 8 en-Brai-GB-scouse 5 7 7 5 One effect you see with both metrics; If one side wants en-scouse, and the other side has only en-Latn-US-scouse and en-Brai-GB-scouse, you get a draw. Apparently your algorithm cannot completely replace the "default script" approach. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 13:53:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12556; Tue, 5 Apr 2005 13:53:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIsN3-0002TA-Q9; Tue, 05 Apr 2005 14:01:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIsEc-0006im-4I; Tue, 05 Apr 2005 13:53:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIsEa-0006ih-T3 for ltru@megatron.ietf.org; Tue, 05 Apr 2005 13:53:05 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12528 for ; Tue, 5 Apr 2005 13:53:03 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIsBX-0005su-Ry for ltru@lists.ietf.org; Tue, 05 Apr 2005 19:49:55 +0200 Received: from du-001-171.access.de.clara.net ([212.82.227.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 19:49:55 +0200 Received: from nobody by du-001-171.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 19:49:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 19:47:24 +0200 Organization: Lines: 25 Message-ID: <4252CF2C.171F@xyzzy.claranet.de> References: <003901c539ee$55158300$030aa8c0@DEWELL> 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: du-001-171.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Date of deprecation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > Did Randy or Martin say something about working on the > registry itself? What I meant was Randy's (hat off) question in: | If we already have a good idea how the ISO specifications | will look, wouldn't it make sense to ensure that 3066bis | works correctly for those cases, so we don't have to bother | doing a 3066ter? | I think it would be really nice if we could put in text now | that would not need revision later. It sounds like all that | is needed is text that spells out precisely when using the | macro-language code is required. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 15:12:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20717; Tue, 5 Apr 2005 15:12:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DItbe-0005NS-Lu; Tue, 05 Apr 2005 15:20:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DItSe-0001s5-Pn; Tue, 05 Apr 2005 15:11:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DItSe-0001rz-43 for ltru@megatron.ietf.org; Tue, 05 Apr 2005 15:11:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20504 for ; Tue, 5 Apr 2005 15:11:37 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DItao-0005Lo-Dc for ltru@ietf.org; Tue, 05 Apr 2005 15:20:08 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 12:11:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Registry in record-jar format Date: Tue, 5 Apr 2005 12:11:24 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE807F@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU5UVfTMZw29EQ4R4GWBFjb2in+owAAMxLgADBCLjA= From: "Addison Phillips" To: "Addison Phillips" , "John Cowan" X-OriginalArrivalTime: 05 Apr 2005 19:11:25.0584 (UTC) FILETIME=[432E8900:01C53A13] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable Duh, location: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.html (or .txt or .xml) Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Addison Phillips > Sent: lundi 4 avril 2005 13:23 > To: 'John Cowan' > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Registry in record-jar format >=20 > See below. >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: John Cowan [mailto:jcowan@reutershealth.com] > > Sent: lundi 4 avril 2005 13:03 > > To: Addison Phillips > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Re: Registry in record-jar format > > > > Addison Phillips scripsit: > > > > > Answer: Yes, it is a problem, since users might have to specify = two > > > ranges or may get results inconsistent with their expectations. = For > > > example, the range "zh-TW" does not match the tag "zh-Hant-TW" = using > > > strict 3066 matching rules. > > > > Just a terminological note: I think these should be called HTTP or = RFC > > 2616 > > matching rules, since RFC 2616 is the true and authoritative source = for > > them. > [Addison Phillips] >=20 > Agreed. >=20 > > > > > i. "Extended Range Matching" is an extension of RFR in which = "missing" > > > subtags are considered to be (or are expanded to be) wildcards. So > > > "de-1901" is expanded to "de-*-*-1901" and matches "de-Latn-1901" = and > > > "de-AT-1901", not to mention "de-Latg-NA-1901". > > > > I think this should be mentioned in the matching I-D. > [Addison Phillips] >=20 > I believe it is, although not this specific example. See = http://www.inter- > locale.com/ID/draft-ietf-ltru-matching-00.html#extrange >=20 > > > > > NB> Probably we need to extend this scheme to allow users to = specify > > > that they do NOT want a specific field to be filled in. For = example > > > "de-!-1901" would match only "de-1901" and not a tag such as > > > "de-Latn-1901". > > > > I'd like to see a use case for this (not involving boont). > [Addison Phillips] >=20 > Find all content in need of retagging with a script in my Traditional > Chinese document using XPath: >=20 > /*@[lang=3D"zh-!-TW"] > > > > > ii. "Lookup" is the opposite of matching, in which subtags are = removed > > > from the tag rather than the range (i.e. locale-style) to fill in = all > > > slots in a dataset. This matches a very different content set. > > > > This too should be mentioned. > [Addison Phillips] >=20 > Being added. Mark supplied text that I haven't had time to insert. > > > > > iii. "Scored Matching" was proposed by John Cowan and produces = content > > > with a range of scores, allowing the content to be filtered by > choosing > > > a "quality level" (my words) for the match. The user can set a > threshold > > > for matching, presumably. > > > > As should this. > [Addison Phillips] >=20 > Agreed. > > > > > The problem here is that matching cannot be as simple as it was = under > > > RFC 3066 and still capture all possible cases. > > > > This is badly stated. Only matching of predefined tags in RFC 3066 > > captures > > all cases. > [Addison Phillips] >=20 > It is badly stated. But I'm not sure your version captures the nuances > either. Perhaps: >=20 > Only generative tags in RFC 3066 (i.e. those with only two possible > subtags) are guaranteed to work with RFC 2616 defined matching. > > > > -- > > Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. > > Send us, bright one, light one, Horhorn, quickening, and wombfruit. = (3x) > > Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, > > hoopsa! > > -- Joyce, Ulysses, "Oxen of the Sun" = jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 15:13:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20958; Tue, 5 Apr 2005 15:13:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DItcU-0005Tb-Me; Tue, 05 Apr 2005 15:21:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DItTx-00021f-Ds; Tue, 05 Apr 2005 15:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DItTw-00021U-4i for ltru@megatron.ietf.org; Tue, 05 Apr 2005 15:13:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20802 for ; Tue, 5 Apr 2005 15:12:58 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DItc8-0005OS-Nt for ltru@ietf.org; Tue, 05 Apr 2005 15:21:28 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 12:12:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Registry in record-jar format Date: Tue, 5 Apr 2005 12:12:50 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE8084@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU5UVfTMZw29EQ4R4GWBFjb2in+owAAMxLgADBCLjAAAAhqgA== From: "Addison Phillips" To: "Addison Phillips" , "John Cowan" X-OriginalArrivalTime: 05 Apr 2005 19:12:50.0897 (UTC) FILETIME=[76084410:01C53A13] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Whups. That was intended as a private response inquiring about = record-jar. Clicked on the wrong message. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 16:10:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08590; Tue, 5 Apr 2005 16:10:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIuVV-00031W-EL; Tue, 05 Apr 2005 16:18:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIuEk-0002GQ-50; Tue, 05 Apr 2005 16:01:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIuEh-0002Fk-I2 for ltru@megatron.ietf.org; Tue, 05 Apr 2005 16:01:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05031 for ; Tue, 5 Apr 2005 16:01:17 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIuMt-0001gN-AH for ltru@ietf.org; Tue, 05 Apr 2005 16:09:48 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 5 Apr 2005 13:01:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Registry in record-jar format Date: Tue, 5 Apr 2005 13:01:05 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0ADE80D9@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Registry in record-jar format Thread-Index: AcU6GafMPxR31XpdRnGksW1AYtCJbgAAEt8A From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 05 Apr 2005 20:01:06.0666 (UTC) FILETIME=[340B8CA0:01C53A1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable No, I'm pretty sure I don't want to say %x10 :-). I just typed ahead = rather quickly to get the framework into place and haven't looked at it = closely yet. Your tips are very much appreciated. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: mardi 5 avril 2005 12:52 > To: ltru@ietf.org > Subject: [Ltru] Re: Registry in record-jar format >=20 > Addison Phillips wrote: >=20 > > Whups. >=20 > Are you sure that you want to mention \n %x10, and if you > are sure, how about %x0A or %d10 ? I really thought that it's > more or less 2822 compatible, and then you'd have CrLf, not Lf. >=20 > How about: ...separated by a line "%%" ? > Or if you want ABNF: ...seaparated by a line "%%" CRLF. >=20 > Just copy what you need from RfC 2234bis (LF, CRLF, and LWSP > line folding instead of the ugly "\" line continuations). >=20 > Google says that "record-jar" is based on RfC 822, and then > it's CRLF and folding, not LF and "\". Thanks for the sneak > preview... ;-) > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 16:12:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09511; Tue, 5 Apr 2005 16:12:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIuXN-0003Ju-0H; Tue, 05 Apr 2005 16:20:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIu8I-0006mj-CM; Tue, 05 Apr 2005 15:54:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIu8G-0006mV-JN for ltru@megatron.ietf.org; Tue, 05 Apr 2005 15:54:40 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02393 for ; Tue, 5 Apr 2005 15:54:37 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DIu58-0000r3-TL for ltru@lists.ietf.org; Tue, 05 Apr 2005 21:51:27 +0200 Received: from du-001-171.access.de.clara.net ([212.82.227.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 21:51:26 +0200 Received: from nobody by du-001-171.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Apr 2005 21:51:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Apr 2005 21:51:45 +0200 Organization: Lines: 19 Message-ID: <4252EC51.72CD@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0ADE8084@irvmbxw01.quest.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: du-001-171.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > Whups. Are you sure that you want to mention \n %x10, and if you are sure, how about %x0A or %d10 ? I really thought that it's more or less 2822 compatible, and then you'd have CrLf, not Lf. How about: ...separated by a line "%%" ? Or if you want ABNF: ...seaparated by a line "%%" CRLF. Just copy what you need from RfC 2234bis (LF, CRLF, and LWSP line folding instead of the ugly "\" line continuations). Google says that "record-jar" is based on RfC 822, and then it's CRLF and folding, not LF and "\". Thanks for the sneak preview... ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 18:18:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24912; Tue, 5 Apr 2005 18:18:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIwVl-0000r8-Va; Tue, 05 Apr 2005 18:27:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIwMk-0006WL-It; Tue, 05 Apr 2005 18:17:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIwMj-0006PS-1x for ltru@megatron.ietf.org; Tue, 05 Apr 2005 18:17:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24808 for ; Tue, 5 Apr 2005 18:17:34 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIwUo-0000qC-KX for ltru@ietf.org; Tue, 05 Apr 2005 18:26:07 -0400 Received: from h-64-105-137-168.snvacaid.dynamic.covad.net ([64.105.137.168] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DIwMW-00047k-00 for ltru@ietf.org; Tue, 05 Apr 2005 15:17:32 -0700 Message-ID: <00ff01c53a2d$70ac3340$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050325125855.KUPU2135.mta2.adelphia.net@megatron.ietf.org><000801c53227$3ba04640$030aa8c0@DEWELL> <6.1.2.0.2.20050326210800.043a07e0@mail.jefsey.com> Date: Tue, 5 Apr 2005 15:18:48 -0700 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: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ltru] LTRU participation and warning X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi - > From: "JFC (Jefsey) Morfin" > To: "Doug Ewell" > Cc: > Sent: Saturday, March 26, 2005 2:06 PM > Subject: Re: [Ltru] Re: Registry in record-jar format ... > solution requested must be workable. I know that our Chairs do not want > Doug Barton to share in this WG, but we would certainly need to have ... Participation in this working group is open to all, unless they engage in disruptive behaviour, causing the WG co-chairs to suspend their posting privileges pursuant to RFC 3934. You have been warned. If Doug Barton (or anyone else) cares to join the working group mailing list, they're most welcome. Randy ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 19:50:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02327; Tue, 5 Apr 2005 19:50:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIxwe-00044s-1F; Tue, 05 Apr 2005 19:58:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIxnQ-00059i-1w; Tue, 05 Apr 2005 19:49:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIxnP-00059d-3n for ltru@megatron.ietf.org; Tue, 05 Apr 2005 19:49:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02283 for ; Tue, 5 Apr 2005 19:49:19 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIxvc-000443-2i for ltru@ietf.org; Tue, 05 Apr 2005 19:57:54 -0400 Received: from lns-p19-8-idf-82-249-11-10.adsl.proxad.net ([82.249.11.10] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DIxnK-00078V-KI; Tue, 05 Apr 2005 16:49:19 -0700 Message-Id: <6.1.2.0.2.20050406013048.05508b80@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 06 Apr 2005 01:48:49 +0200 To: "Randy Presuhn" , From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling In-Reply-To: <000601c52dd8$94334120$7f1afea9@oemcomputer> References: <20050321024502.GB15741@skunk.reutershealth.com> <000601c52dca$e1e126c0$7f1afea9@oemcomputer> <20050321044113.GG15741@skunk.reutershealth.com> <000601c52dd8$94334120$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 At 07:41 21/03/2005, Randy Presuhn wrote: >Hi - >(co-chair hat off) > > From: "John Cowan" > > To: "Randy Presuhn" > > Cc: > > Sent: Sunday, March 20, 2005 8:41 PM > > Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling >... > > From what I understand of the IETF process, this WG could go dormant > > until ISO 639-3 was released, and then wake up for a relatively brief > > period to incorporate the necessary few paragraphs in RFC 3066bis to > > create RFC 3066ter. >... > >I think it would be really nice if we could put in text now that would not >need revision later. I fully agree with that. In particular ISO 639-4, which should permits to make the BCP 047 consistent with ISO 639-3, ISO 639-6 and the IANA entries - and obviously ISO 3166-2. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 20:24:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04630; Tue, 5 Apr 2005 20:24:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIyTS-0005El-4n; Tue, 05 Apr 2005 20:32:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIyEM-0004Q7-Tq; Tue, 05 Apr 2005 20:17:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIyEM-0004Q2-5H for ltru@megatron.ietf.org; Tue, 05 Apr 2005 20:17:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04123 for ; Tue, 5 Apr 2005 20:17:10 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DIyMa-00051S-Uv for ltru@ietf.org; Tue, 05 Apr 2005 20:25:45 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 6 Apr 2005 01:16:50 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 01:16:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Date: Wed, 6 Apr 2005 01:16:49 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A2121A5937@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Thread-Index: AcU6OknC9ZTaHeHiTYWtYJcGmkbJ3AAAhbXE From: "L.Gillam" To: ltru X-OriginalArrivalTime: 06 Apr 2005 00:16:50.0102 (UTC) FILETIME=[ED721560:01C53A3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1208989683==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 This is a multi-part message in MIME format. --===============1208989683== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53A3D.ED4CDB24" This is a multi-part message in MIME format. ------_=_NextPart_001_01C53A3D.ED4CDB24 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 639-4 is going to be "a while" in process. N.B. 5 month DIS ballot for = 639-3, possible FDIS stage then publication (final editorial phase with = ISO central secretariat). Unless activity on -4 suddenly happens at the = Berlin metadata event next week, which it might or it might not, I'm not = aware of a current timescale for this document beyond ISO time limits = (the clock is certainly ticking). =20 Perhaps Peter Constable can comment on whether existing comments = received at CD ballot have resulted in any alteration of the essence of = -3, comments on the codes themselves (not part of the published = standard) aside. ________________________________ From: ltru-bounces@lists.ietf.org on behalf of JFC (Jefsey) Morfin Sent: Wed 06/04/2005 00:48 To: Randy Presuhn; ltru Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling At 07:41 21/03/2005, Randy Presuhn wrote: >Hi - >(co-chair hat off) > > From: "John Cowan" > > To: "Randy Presuhn" > > Cc: > > Sent: Sunday, March 20, 2005 8:41 PM > > Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling >... > > From what I understand of the IETF process, this WG could go dormant > > until ISO 639-3 was released, and then wake up for a relatively = brief > > period to incorporate the necessary few paragraphs in RFC 3066bis to > > create RFC 3066ter. >... > >I think it would be really nice if we could put in text now that would = not >need revision later. I fully agree with that. In particular ISO 639-4, which should permits = to make the BCP 047 consistent with ISO 639-3, ISO 639-6 and the IANA = entries - and obviously ISO 3166-2. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C53A3D.ED4CDB24 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling=0A= =0A= =0A=
=0A=
 
=0A=
639-4 is going to be "a = while" in process. =0A= N.B. 5 month DIS ballot for 639-3, possible FDIS stage then publication = (final =0A= editorial phase with ISO central secretariat). Unless activity on -4 = suddenly =0A= happens at the Berlin metadata event next week, which it might or it = might not, =0A= I'm not aware of a current timescale for this document beyond ISO = time =0A= limits (the clock is certainly ticking).
=0A=
 
=0A=
Perhaps Peter Constable can = comment on =0A= whether existing comments received at CD ballot have resulted in any = alteration =0A= of the essence of -3, comments on the codes themselves (not part of the =0A= published standard) aside.
=0A=

=0A=
=0A= From: ltru-bounces@lists.ietf.org on = behalf of =0A= JFC (Jefsey) Morfin
Sent: Wed 06/04/2005 00:48
To: = Randy =0A= Presuhn; ltru
Subject: Re: [Ltru] [semi-OT] ISO 639-3, = record-jars, =0A= and Boontling

=0A=
=0A=

At 07:41 21/03/2005, Randy Presuhn wrote:
>Hi =0A= -
>(co-chair hat off)
> > From: "John Cowan" =0A= <jcowan@reutershealth.com>
> > To: "Randy Presuhn" =0A= <randy_presuhn@mindspring.com>
> > Cc: =0A= <ltru@ietf.org>
> > Sent: Sunday, March 20, 2005 8:41 = PM
> =0A= > Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and =0A= Boontling
>...
> > From what I understand of the IETF = process, =0A= this WG could go dormant
> > until ISO 639-3 was released, and = then =0A= wake up for a relatively brief
> > period to incorporate the = necessary =0A= few paragraphs in RFC 3066bis to
> > create RFC =0A= 3066ter.
>...
>
>I think it would be really nice if we = could =0A= put in text now that would not
>need revision later.

I = fully agree =0A= with that. In particular ISO 639-4, which should permits to
make the = BCP 047 =0A= consistent with ISO 639-3, ISO 639-6 and the IANA entries
- and = obviously ISO =0A= 3166-2.
jfc


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

=0A= =0A= =0A= ------_=_NextPart_001_01C53A3D.ED4CDB24-- --===============1208989683== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1208989683==-- From ltru-bounces@ietf.org Tue Apr 5 22:05:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12594; Tue, 5 Apr 2005 22:05:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ033-00007A-TJ; Tue, 05 Apr 2005 22:13:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIzuZ-0007E4-US; Tue, 05 Apr 2005 22:04:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIzuQ-00077x-0R for ltru@megatron.ietf.org; Tue, 05 Apr 2005 22:04:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12507 for ; Tue, 5 Apr 2005 22:04:43 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ02f-00005v-29 for ltru@ietf.org; Tue, 05 Apr 2005 22:13:18 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3624XDR015950; Tue, 5 Apr 2005 22:04:34 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 5 Apr 2005 22:04:34 -0400 Date: Tue, 5 Apr 2005 22:04:33 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Matching metrics (was: Registry in record-jar format) Message-ID: <20050406020433.GA18951@skunk.reutershealth.com> References: <004c01c5392c$b2b0c280$030aa8c0@DEWELL> <42517E0D.EF2@xyzzy.claranet.de> <20050404184906.GB7640@skunk.reutershealth.com> <4251AAB9.2BAA@xyzzy.claranet.de> <20050404225807.GE7640@skunk.reutershealth.com> <4252C4D7.5EDF@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4252C4D7.5EDF@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Frank Ellermann scripsit: > I've added 0 for '*' = '*' and no match. Otherwise 8/4/2/1, > is this what you wanted ? Your metrics has apparently a > problem with en-Latn-US-scouse: I'm not clear on whether * = * should count as a match or a no-match. Originally I thought it should count as a match, but perhaps not. > If one side wants en-GB-scouse, and the other side offers > en-Latn-US-scouse (9) or en-Latn-GB (10), and it also has > en-Brai-GB-scouse (11), then en-Brai-GB-scouse "wins". All > in the 2nd column for en-GB-scouse. Fortunately en-US-scouse doesn't exist. > Not okay, but not completely unintentional, for some languages > I can guess what the text is about, as long as it's Latn: The > combined power of forgotten school Latin plus miserable French > sometimes helps with es or pt. But with ru I'd be lost - with > luck I can decode some Cyrl. For fy my chances are lousy, for > dk or nl it's better than zero. Fair enough. > One effect you see with both metrics; If one side wants > en-scouse, and the other side has only en-Latn-US-scouse and > en-Brai-GB-scouse, you get a draw. Apparently your algorithm > cannot completely replace the "default script" approach. Well, that problem applies at all levels: if you ask for en-AU, then no algorithm can choose between the offered en-GB and en-US (except RFC 2616, which will simply fail). For that matter, if you ask for de and nn and nb are all that's available, the matching algorithm won't help then either. -- Is a chair finely made tragic or comic? Is the John Cowan portrait of Mona Lisa good if I desire to see jcowan@reutershealth.com it? Is the bust of Sir Philip Crampton lyrical, www.ccil.org/~cowan epical or dramatic? If a man hacking in fury www.reutershealth.com at a block of wood make there an image of a cow, is that image a work of art? If not, why not? --Stephen Dedalus _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 22:56:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15651; Tue, 5 Apr 2005 22:56:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ0rA-0001f3-JM; Tue, 05 Apr 2005 23:05:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ0if-0002fk-S7; Tue, 05 Apr 2005 22:56:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ0ie-0002ff-24 for ltru@megatron.ietf.org; Tue, 05 Apr 2005 22:56:40 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15606 for ; Tue, 5 Apr 2005 22:56:37 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050406025608.GNPA5402.mta11.adelphia.net@DEWELL> for ; Tue, 5 Apr 2005 22:56:08 -0400 Message-ID: <009101c53a54$2d06a040$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050405200543.TRMV2124.mta7.adelphia.net@megatron.ietf.org> Date: Tue, 5 Apr 2005 19:56:04 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Date of deprecation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Addison Phillips wrote: >>> One of our chairs proposed to prepare the LTRU registry as far >>> as possible for this case. IMHO a good idea, of course not for >>> what you plan to publish tomorrow. >> >> I missed something there. Did Randy or Martin say something about >> working on the registry itself? > > To prepare the 3066bis regime to handle ISO 639-3 as much as possible > is what I believe Frank means. and Frank Ellermann wrote: > What I meant was Randy's (hat off) question... > > | If we already have a good idea how the ISO specifications > | will look, wouldn't it make sense to ensure that 3066bis > | works correctly for those cases, so we don't have to bother > | doing a 3066ter? > > | I think it would be really nice if we could put in text now > | that would not need revision later. It sounds like all that > | is needed is text that spells out precisely when using the > | macro-language code is required. Ah, you are right. Technically that's preparing the draft, not the registry per se, which is why I missed something. But I completely agree, and think we should include as much information as we can -- depending on how much confidence we have in the stability of the 639-3 draft between now and the time it's published -- about how extlangs will work, and which types of 639-3 codes will be primary language subtags and which will be extlangs. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 23:03:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16017; Tue, 5 Apr 2005 23:03:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ0xK-0001qM-5h; Tue, 05 Apr 2005 23:11:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ0lR-0002qI-7x; Tue, 05 Apr 2005 22:59:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ0lO-0002qD-46 for ltru@megatron.ietf.org; Tue, 05 Apr 2005 22:59:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15816 for ; Tue, 5 Apr 2005 22:59:27 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ0td-0001kI-G9 for ltru@ietf.org; Tue, 05 Apr 2005 23:08:02 -0400 Received: from h-64-105-137-168.snvacaid.dynamic.covad.net ([64.105.137.168] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJ0lK-00014u-00 for ltru@ietf.org; Tue, 05 Apr 2005 19:59:26 -0700 Message-ID: <00fa01c53a54$d1675080$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org><00c401c53754$cdfe41e0$030aa8c0@DEWELL> <424F03EB.C30@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Proposed changes to region subtags Date: Tue, 5 Apr 2005 20:00:40 -0700 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@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi - > From: "Frank Ellermann" > To: > Sent: Saturday, April 02, 2005 1:43 PM > Subject: [Ltru] Re: Proposed changes to region subtags ... > And one reason pro XML (clear support for Unicode character > references in an otherwise US-ASCII text). JFTR, I prefer > record-jar in the body of the I-D registry. ... Pardon the naive question: Couldn't we simply use Unicode character references (as needed) in a record-jar format? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 23:35:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18369; Tue, 5 Apr 2005 23:35:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ1SH-0002tW-AI; Tue, 05 Apr 2005 23:43:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ1Fo-0002PW-HW; Tue, 05 Apr 2005 23:30:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ1Fn-0002PO-QI for ltru@megatron.ietf.org; Tue, 05 Apr 2005 23:30:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17969 for ; Tue, 5 Apr 2005 23:30:52 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ1O3-0002lU-1K for ltru@ietf.org; Tue, 05 Apr 2005 23:39:28 -0400 Received: from h-64-105-137-168.snvacaid.dynamic.covad.net ([64.105.137.168] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJ1Fj-0005FT-00 for ltru@ietf.org; Tue, 05 Apr 2005 20:30:52 -0700 Message-ID: <015e01c53a59$34b67400$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050404212221.FWFF4900.mta8.adelphia.net@megatron.ietf.org><001601c539a2$dd7d78c0$030aa8c0@DEWELL><6.1.2.0.2.20050405122227.03f5beb0@mail.jefsey.com> <003301c539ed$613012a0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Registry in RDF/XML format Date: Tue, 5 Apr 2005 20:32:05 -0700 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: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Tuesday, April 05, 2005 7:40 AM > Subject: [Ltru] Re: Registry in RDF/XML format ... > Can we specify *how* they build the alternative-format registry files? > If so, great. ... Yes, I we could do that, but that would be a normative part of the document via the IANA considerations section, even if what is thereby generated is considered "informative". I suspect that the IESG would want to see a pretty good rationale for having IANA generate technically redundant representations of the registry content. Randy (as process-aware contributor) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 5 23:50:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19421; Tue, 5 Apr 2005 23:50:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ1gh-0003Nm-Dc; Tue, 05 Apr 2005 23:58:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ1YF-0006o0-D3; Tue, 05 Apr 2005 23:49:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ1YE-0006ll-7Z for ltru@megatron.ietf.org; Tue, 05 Apr 2005 23:49:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19411 for ; Tue, 5 Apr 2005 23:49:55 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ1gT-0003NY-Eg for ltru@ietf.org; Tue, 05 Apr 2005 23:58:31 -0400 Received: from h-64-105-137-168.snvacaid.dynamic.covad.net ([64.105.137.168] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJ1Y8-0000OR-00 for ltru@ietf.org; Tue, 05 Apr 2005 20:49:53 -0700 Message-ID: <006f01c53a5b$dc63f360$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050331144959.66075.qmail@web42004.mail.yahoo.com><091b01c53614$55a3c850$857e3009@sanjose.ibm.com> <6.1.2.0.2.20050331191828.0ca22ad0@mail.jefsey.com> Subject: Re: [Ltru] Re: Language transformation Date: Tue, 5 Apr 2005 20:51:05 -0700 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: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Hi - () > From: "JFC (Jefsey) Morfin" > To: "Mark Davis" > Cc: > Sent: Thursday, March 31, 2005 10:29 AM > Subject: Re: [Ltru] Re: Language transformation > > On 19:09 31/03/2005, Mark Davis said: > >The plan is for transliterations to be added to CLDR at some point, and > >that would provide stable, predictable IDs that could be used for > >variants. I suggest that we not try to incorporate transliteration > >variants prematurely. For some more formal, structured mechanism of > >describing the variants, it would a perfect case for the extension > >mechanism proposed in the draft, where some other RFC could have > >something like ru-Latn-t-ungegn-t-en. > > This kind of remark obviously make me react. Whose plan: IETF, IESG, IAB? Obviously not, since CLDR is a Unicode project. http://www.unicode.org/cldr/ > 1. this CLDR plan should be documented in the Draft as per Charter. At > least to explain why it is not supported now. ... There is no such requirement in the charter. The charter mentions CLDR as one of the users of RFC 3066. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 00:11:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21011; Wed, 6 Apr 2005 00:11:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ21s-0004BG-8k; Wed, 06 Apr 2005 00:20:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ1os-0001U0-SP; Wed, 06 Apr 2005 00:07:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ1or-0001Tv-PV for ltru@megatron.ietf.org; Wed, 06 Apr 2005 00:07:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20548 for ; Wed, 6 Apr 2005 00:07:06 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ1x8-00043J-3l for ltru@ietf.org; Wed, 06 Apr 2005 00:15:43 -0400 Received: from lns-p19-8-idf-82-249-11-10.adsl.proxad.net ([82.249.11.10] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJ1oo-0000ut-RC; Tue, 05 Apr 2005 21:07:07 -0700 Message-Id: <6.1.2.0.2.20050406055654.03fbe4c0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 06 Apr 2005 06:06:55 +0200 To: "Randy Presuhn" , From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Language transformation In-Reply-To: <006f01c53a5b$dc63f360$7f1afea9@oemcomputer> References: <20050331144959.66075.qmail@web42004.mail.yahoo.com> <091b01c53614$55a3c850$857e3009@sanjose.ibm.com> <6.1.2.0.2.20050331191828.0ca22ad0@mail.jefsey.com> <006f01c53a5b$dc63f360$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a At 05:51 06/04/2005, Randy Presuhn wrote: >This kind of remark obviously make me react. Whose plan: IETF, IESG, IAB? > >Obviously not, since CLDR is a Unicode project. >http://www.unicode.org/cldr/ > > > 1. this CLDR plan should be documented in the Draft as per Charter. At > > least to explain why it is not supported now. >... > >There is no such requirement in the charter. The charter mentions CLDR as >one of the users of RFC 3066. I dont think this is correct. The CLDR is not documented by any RFC. This is a copyrighted private project. There are other projects with comparable aims and different needs. The needs of the CLDR are parts of the needs calling a the BPC 047 review. In not quoting CLDR the current draft implies that the CLDR needs are satisfied what puts it ad advantage over other projects or projects studies the needs of which are not satisfied. I fully understand that CLDR IPRs should be respected, the same as other projects. But the Internet standard process calls for protected solutions to be considered after open ones. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 00:12:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21037; Wed, 6 Apr 2005 00:12:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ21y-0004BN-7H; Wed, 06 Apr 2005 00:20:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ1tB-0001wc-Sa; Wed, 06 Apr 2005 00:11:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ1tA-0001wW-J4 for ltru@megatron.ietf.org; Wed, 06 Apr 2005 00:11:36 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20951 for ; Wed, 6 Apr 2005 00:11:33 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050406041104.LXRF4618.mta13.adelphia.net@DEWELL> for ; Wed, 6 Apr 2005 00:11:04 -0400 Message-ID: <009601c53a5e$a4e783e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050405200543.TRMV2124.mta7.adelphia.net@megatron.ietf.org> Date: Tue, 5 Apr 2005 21:11:00 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Matching metrics (was: Registry in record-jar format) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > I've added 0 for '*' = '*' and no match. Otherwise 8/4/2/1, > is this what you wanted ? No, that's not right. '*' = '*' is a match, just the same as 'de' = 'de', and should be assigned the full complement of points, depending on which subtag it is. 'de' = 'en', by contrast, would be a zero. Suppose I request "sr-CS". The script is not specified, so in our matching syntax, this is equivalent to "sr-*-CS". Accordingly, this request should retrieve content labeled "sr-CS", "sr-Latn-CS", "sr-Cyrl-CS", or "sr-Yiii-CS" with equal success. '*' matches everything, and earns full points. Try your metrics again. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 00:19:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21459; Wed, 6 Apr 2005 00:19:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ28l-0004RA-F4; Wed, 06 Apr 2005 00:27:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ1zZ-0005Tn-Kj; Wed, 06 Apr 2005 00:18:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ1zY-0005RT-KS for ltru@megatron.ietf.org; Wed, 06 Apr 2005 00:18:12 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21442 for ; Wed, 6 Apr 2005 00:18:09 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050406041741.JKIV5402.mta11.adelphia.net@DEWELL> for ; Wed, 6 Apr 2005 00:17:41 -0400 Message-ID: <009b01c53a5f$911c9200$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050406041047.MUIA2140.mta3.adelphia.net@megatron.ietf.org> Date: Tue, 5 Apr 2005 21:17:36 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Matching metrics (was: Registry in record-jar format) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit John Cowan wrote: > I'm not clear on whether * = * should count as a match or a no-match. > Originally I thought it should count as a match, but perhaps not. It has to be a match. Otherwise, additional elements don't serve the purpose of narrowing down the scope (for either requested or tagged content). They just get in the way. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 00:21:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21569; Wed, 6 Apr 2005 00:21:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ2Ar-0004SZ-1i; Wed, 06 Apr 2005 00:29:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ22C-0005zb-5m; Wed, 06 Apr 2005 00:20:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ22A-0005zS-K3 for ltru@megatron.ietf.org; Wed, 06 Apr 2005 00:20:54 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21558 for ; Wed, 6 Apr 2005 00:20:51 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050406042023.JMVP5402.mta11.adelphia.net@DEWELL> for ; Wed, 6 Apr 2005 00:20:23 -0400 Message-ID: <00a501c53a5f$f185a960$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050406041047.MUIA2140.mta3.adelphia.net@megatron.ietf.org> Date: Tue, 5 Apr 2005 21:20:18 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Pardon the naive question: > Couldn't we simply use Unicode character references (as needed) > in a record-jar format? We can, and plan to, but they'll look like /u263A instead of ☺ . -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 00:32:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22164; Wed, 6 Apr 2005 00:32:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ2LV-0004ns-Cw; Wed, 06 Apr 2005 00:40:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ27f-0007Fz-8e; Wed, 06 Apr 2005 00:26:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ27e-0007Fu-Bx for ltru@megatron.ietf.org; Wed, 06 Apr 2005 00:26:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21797 for ; Wed, 6 Apr 2005 00:26:31 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ2Fu-0004cJ-W5 for ltru@ietf.org; Wed, 06 Apr 2005 00:35:08 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j364QNoM016499; Wed, 6 Apr 2005 00:26:23 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 6 Apr 2005 00:26:36 -0400 Date: Wed, 6 Apr 2005 00:26:36 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: Proposed changes to region subtags Message-ID: <20050406042635.GC18951@skunk.reutershealth.com> References: <20050406041047.MUIA2140.mta3.adelphia.net@megatron.ietf.org> <00a501c53a5f$f185a960$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a501c53a5f$f185a960$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Doug Ewell scripsit: > We can, and plan to, but they'll look like /u263A instead of ☺ I'm not very happy with this format, for two reasons: it's unique to this database, and it's unterminated. Either use Java-style UTF-16 escapes, \unnnn, or XML character references, which work at the codepoint level. In addition, it requires that / be escaped, which wouldn't be necessary otherwise. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan Rather than making ill-conceived suggestions for improvement based on uninformed guesses about established conventions in a field of study with which familiarity is limited, it is sometimes better to stick to merely observing the usage and listening to the explanations offered, inserting only questions as needed to fill in gaps in understanding. --Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 00:33:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22326; Wed, 6 Apr 2005 00:33:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ2MR-0004pV-Hf; Wed, 06 Apr 2005 00:41:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ2Bs-0007M9-F8; Wed, 06 Apr 2005 00:30:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ2Br-0007M4-Jt for ltru@megatron.ietf.org; Wed, 06 Apr 2005 00:30:55 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22069 for ; Wed, 6 Apr 2005 00:30:52 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050406043024.JVUZ5402.mta11.adelphia.net@DEWELL> for ; Wed, 6 Apr 2005 00:30:24 -0400 Message-ID: <00a601c53a61$5727ec00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 5 Apr 2005 21:30:18 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] CRLF vs. LF X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit I will post two versions of the All-New Improved record-jar-format registry, one with lines ending in CRLF and one with LF. This is to make sure as many people as possible can read it, as easily as possible. At some point in the process, it will become clear which line-ending convention should be adopted for the "final" registry. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 00:43:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23122; Wed, 6 Apr 2005 00:43:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ2WS-0005Ag-00; Wed, 06 Apr 2005 00:52:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ2Nh-0002FR-AE; Wed, 06 Apr 2005 00:43:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ2Nc-0002E2-9R for ltru@megatron.ietf.org; Wed, 06 Apr 2005 00:43:07 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23086 for ; Wed, 6 Apr 2005 00:43:00 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050406044233.MSEL4618.mta13.adelphia.net@DEWELL>; Wed, 6 Apr 2005 00:42:33 -0400 Message-ID: <00ab01c53a63$04491980$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050406041047.MUIA2140.mta3.adelphia.net@megatron.ietf.org> <00a501c53a5f$f185a960$030aa8c0@DEWELL> <20050406042635.GC18951@skunk.reutershealth.com> Subject: Re: [Ltru] Re: Proposed changes to region subtags Date: Tue, 5 Apr 2005 21:42:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id AAA23086 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable John Cowan wrote: >> We can, and plan to, but they'll look like /u263A instead of >> ☺ > > I'm not very happy with this format, for two reasons: it's unique to > this database, and it's unterminated. Either use Java-style UTF-16 > escapes, \unnnn, or XML character references, which work at the > codepoint level. In addition, it requires that / be escaped, which > wouldn't be necessary otherwise. We could reverse the slash to a backslash, Java-style. That way we would only need to escape the backslash (which we do anyway, if we use it for continuation) and not the forward slash (though at present there are no forward slashes to be escaped). Using XML references would require the ampersand to be escaped (there aren't any of those in the registry either), and poses an interesting problem with the semicolon, which is already escaped because of its role in separating lists (e.g. of recommended prefixes). The registry has several descriptions of the form "Occitan (post 1500); Provencal" where the semicolon, inherited from the ISO 639 description, needs to be escaped. If the 'c' in "Provencal" were a c-with-cedilla (=C3=A7), which= I think it's supposed to be anyway, then that would translated to the XML reference ç and I think you'd have to re-escape the trailing semicolon. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 00:56:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23852; Wed, 6 Apr 2005 00:56:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ2ik-0005aE-O7; Wed, 06 Apr 2005 01:04:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ2ZQ-0004Jt-CG; Wed, 06 Apr 2005 00:55:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ2ZN-0004Jo-7U for ltru@megatron.ietf.org; Wed, 06 Apr 2005 00:55:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23798 for ; Wed, 6 Apr 2005 00:55:09 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ2hf-0005ZQ-1D for ltru@ietf.org; Wed, 06 Apr 2005 01:03:47 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j364sxj3016594; Wed, 6 Apr 2005 00:54:59 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 6 Apr 2005 00:54:58 -0400 Date: Wed, 6 Apr 2005 00:54:58 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: Proposed changes to region subtags Message-ID: <20050406045458.GD18951@skunk.reutershealth.com> References: <20050406041047.MUIA2140.mta3.adelphia.net@megatron.ietf.org> <00a501c53a5f$f185a960$030aa8c0@DEWELL> <20050406042635.GC18951@skunk.reutershealth.com> <00ab01c53a63$04491980$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <00ab01c53a63$04491980$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.reutershealth.com id j364sxj3016594 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Doug Ewell scripsit: > We could reverse the slash to a backslash, Java-style. That way we > would only need to escape the backslash (which we do anyway, if we use > it for continuation) and not the forward slash (though at present there > are no forward slashes to be escaped). The annoyance is then that you need to use two of them to represent a non-BMP character, which artificially imports UTF-16 rules into the stream of characters. > Using XML references would require the ampersand to be escaped (there > aren't any of those in the registry either), and poses an interesting > problem with the semicolon, which is already escaped because of its rol= e > in separating lists (e.g. of recommended prefixes). The registry has > several descriptions of the form "Occitan (post 1500); Provencal" where > the semicolon, inherited from the ISO 639 description, needs to be > escaped. If the 'c' in "Provencal" were a c-with-cedilla (=E7), which = I > think it's supposed to be anyway, then that would translated to the XML > reference ç and I think you'd have to re-escape the trailing > semicolon. I don't understand any of this. Why does the existing format escape semicolons? They aren't used as record-jar delimiters. Furthermore, XML character references don't require escaped semicolons, because they are magic only inside a character (or entity) reference. --=20 John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org= /~cowan I come from under the hill, and under the hills and over the hills my pat= hs led. And through the air. I am he that walks unseen. I am the clue-finde= r, the web-cutter, the stinging fly. I was chosen for the lucky number. --B= ilbo _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 01:07:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24483; Wed, 6 Apr 2005 01:07:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ2tF-0005uN-5c; Wed, 06 Apr 2005 01:15:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ2il-0005kV-E0; Wed, 06 Apr 2005 01:04:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ2ij-0005kN-I1 for ltru@megatron.ietf.org; Wed, 06 Apr 2005 01:04:53 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24411 for ; Wed, 6 Apr 2005 01:04:52 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050406050422.FQBU7277.mta10.adelphia.net@DEWELL>; Wed, 6 Apr 2005 01:04:22 -0400 Message-ID: <00b401c53a66$118485a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: +ADw-20050406041047.MUIA2140.mta3.adelphia.net+AEA-megatron.ietf.org+AD4- +ADw-00a501c53a5f+ACQ-f185a960+ACQ-030aa8c0+AEA-DEWELL+AD4- +ADw-20050406042635.GC18951+AEA-skunk.reutershealth.com+AD4- +ADw-00ab01c53a63+ACQ-04491980+ACQ-030aa8c0+AEA-DEWELL+AD4- +ADw-20050406045458.GD18951+AEA-skunk.reutershealth.com+AD4- Date: Tue, 5 Apr 2005 22:04:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" 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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: +AFs-Ltru+AF0- Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit John Cowan +ADw-jcowan at reutershealth dot com+AD4- wrote: +AD4APg- We could reverse the slash to a backslash, Java-style... +AD4- +AD4- The annoyance is then that you need to use two of them to represent a +AD4- non-BMP character, which artificially imports UTF-16 rules into the +AD4- stream of characters. Other than the fact that there aren't likely to be many non-BMP characters in the registry, couldn't this be simply expanded to the capital-U form, thus +ACIAXA-U00010414+ACI-? +AD4APg- Using XML references would require the ampersand to be escaped (there +AD4APg- aren't any of those in the registry either), and poses an interesting +AD4APg- problem with the semicolon, which is already escaped because of its +AD4APg- role in separating lists (e.g. of recommended prefixes)... +AD4- +AD4- I don't understand any of this. Why does the existing format escape +AD4- semicolons? They aren't used as record-jar delimiters. Because of their role in separating lists (e.g. of recommended prefixes). +AD4- Furthermore, XML character references don't require escaped +AD4- semicolons, because they are magic only inside a character (or entity) +AD4- reference. I see your point. Then we would have: Description: Occitan (post 1500)+ACYAIw-x003B Proven+ACYAIw-x00E7+ADs-al Is that OK? Does the semicolon that terminates the character reference cause any problems that anyone can see? -Doug Ewell Fullerton, California http://users.adelphia.net/+AH4-dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 02:12:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10707; Wed, 6 Apr 2005 02:12:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ3uE-00086m-5b; Wed, 06 Apr 2005 02:20:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ3lG-0004ri-IQ; Wed, 06 Apr 2005 02:11:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ3lD-0004mq-1Q for ltru@megatron.ietf.org; Wed, 06 Apr 2005 02:11:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09989 for ; Wed, 6 Apr 2005 02:11:29 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ3tU-000853-9L for ltru@ietf.org; Wed, 06 Apr 2005 02:20:05 -0400 Received: from uknsprd1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 6 Apr 2005 06:11:11 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IEI00EERH6NY2@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 06 Apr 2005 07:11:11 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Wed, 06 Apr 2005 07:11:10 +0100 Date: Wed, 06 Apr 2005 07:11:09 +0100 From: Misha Wolf Subject: RE: [Ltru] Proposed changes to region subtags To: LTRU Working Group Message-id: <1987416CA83AC7499AC772F92E2DBF78036EEF61@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Proposed changes to region subtags Thread-Index: AcU6ZpXQONsV8fLqQRSlmb6ZRv9iMAACHflg content-class: urn:content-classes:message X-OriginalArrivalTime: 06 Apr 2005 06:11:10.0858 (UTC) FILETIME=[6DD7FEA0:01C53A6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Doug Ewell wrote: > Description: Occitan (post 1500); Provençal Don't you mean: Description: Occitan (post 1500); Provençal or: Description: Occitan (post 1500); Provençal ? Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 08:33:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06166; Wed, 6 Apr 2005 08:33:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ9qv-0005rp-RJ; Wed, 06 Apr 2005 08:41:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9c9-0006wQ-7K; Wed, 06 Apr 2005 08:26:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ9c5-0006qn-Fc for ltru@megatron.ietf.org; Wed, 06 Apr 2005 08:26:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05758 for ; Wed, 6 Apr 2005 08:26:27 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJ9kP-0005e5-HS for ltru@ietf.org; Wed, 06 Apr 2005 08:35:06 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 6 Apr 2005 13:21:17 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 13:21:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Apr 2005 13:21:16 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A2121A5939@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: Registry in record-jar format - smart matching? Thread-Index: AcU5XI5upuE9IsJHQxGEiAxrbU3TLwAaUOgAAALni1AAMF2epQ== From: "L.Gillam" To: ltru X-OriginalArrivalTime: 06 Apr 2005 12:21:16.0335 (UTC) FILETIME=[2156E3F0:01C53AA3] X-Spam-Score: 0.8 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [Ltru] Re: Registry in record-jar format - smart matching? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0137921162==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab This is a multi-part message in MIME format. --===============0137921162== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53AA3.212C7525" This is a multi-part message in MIME format. ------_=_NextPart_001_01C53AA3.212C7525 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Defaults + fallback =3D ? If "en" defaults to en-Latn, does en-Cyrl falls back to en and default = to en-Latn. Is it better to receive en-Latn rather than "nothing" in = response to en-Cyrl? What if more than one script is implicated by the 2 = letter language code, there is a default, but the fallback should = produce all available?=20 What do people think is the best result from this combination? > -----Original Message-----=20 > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On=20 > Behalf Of Frank Ellermann=20 > Sent: 04 April 2005 22:07=20 > To: ltru@ietf.org=20 > Subject: [Ltru] Re: Registry in record-jar format=20 >=20 >=20 > Debbie Garside wrote:=20 >=20 > > What do you -think- you would apply to the proposed 639-3 tags like=20 > > "ess" Central Siberian Yupik which is written in Cyrillic script in=20 > > Siberia and Latin script in Alaska?=20 >=20 > No default when it's unclear. This case sounds like the now=20 > deprecated sh (sr + hr). Bye, Frank=20 >=20 >=20 >=20 > _______________________________________________=20 > Ltru mailing list=20 > Ltru@lists.ietf.org=20 > https://www1.ietf.org/mailman/listinfo/ltru=20 >=20 ------_=_NextPart_001_01C53AA3.212C7525 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [Ltru] Re: Registry in record-jar format=0A= =0A= =0A=
=0A=
=0A=

Defaults + fallback =3D ?

=0A=

If "en" defaults to en-Latn, does en-Cyrl falls back = to en and =0A= default to en-Latn. Is it better to receive = en-Latn rather =0A= than "nothing" in response to en-Cyrl? What if more than one script = is =0A= implicated by the 2 letter language code, there is a default, but the = fallback =0A= should produce all available?

=0A=

What do people think is the best result from this =0A= combination?

=0A=

> -----Original Message-----
> =0A= From: ltru-bounces@lists.ietf.org
> [mailto:ltru-bounces@lists.iet= f.org]On =0A=
> Behalf Of Frank Ellermann
> =0A= Sent: 04 April 2005 22:07
> To: = ltru@ietf.org =0A=
> Subject: [Ltru] Re: Registry in record-jar = format =0A=
>
>
> =0A= Debbie Garside wrote:
>
> =0A= > What do you -think- you would apply to the proposed 639-3 tags like =0A=
> > "ess" Central Siberian Yupik which = is written =0A= in Cyrillic script in
> > Siberia and = Latin script =0A= in Alaska?
>
> = No default =0A= when it's unclear.  This case sounds like the now
> deprecated sh (sr + hr).  Bye, Frank
>
>
> =0A=
> =0A= _______________________________________________
> =0A= Ltru mailing list
> = Ltru@lists.ietf.org =0A=
> https://www1.ietf.or= g/mailman/listinfo/ltru =0A=
>

=0A= =0A= =0A= ------_=_NextPart_001_01C53AA3.212C7525-- --===============0137921162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0137921162==-- From ltru-bounces@ietf.org Wed Apr 6 09:36:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11275; Wed, 6 Apr 2005 09:36:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJAqE-0007iK-Lx; Wed, 06 Apr 2005 09:45:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJAh7-0006FX-II; Wed, 06 Apr 2005 09:35:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJAh6-0006DL-6d for ltru@megatron.ietf.org; Wed, 06 Apr 2005 09:35:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11217 for ; Wed, 6 Apr 2005 09:35:42 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJApS-0007hQ-7Y for ltru@ietf.org; Wed, 06 Apr 2005 09:44:22 -0400 Received: from lns-p19-19-idf-82-249-7-154.adsl.proxad.net ([82.249.7.154] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJAgf-0007Qy-KU; Wed, 06 Apr 2005 06:35:18 -0700 Message-Id: <6.1.2.0.2.20050406151907.035821d0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 06 Apr 2005 15:27:29 +0200 To: "L.Gillam" , ltru From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Registry in record-jar format - smart matching? In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A2121A5939@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A2121A5939@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1095854910==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --===============1095854910== Content-Type: multipart/alternative; boundary="=====================_10721106==.ALT" --=====================_10721106==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 14:21 06/04/2005, L.Gillam wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C53AA3.212C7525" > >Defaults + fallback = ? > >If "en" defaults to en-Latn, does en-Cyrl falls back to en and default to >en-Latn. Is it better to receive en-Latn rather than "nothing" in response >to en-Cyrl? What if more than one script is implicated by the 2 letter >language code, there is a default, but the fallback should produce all >available? > >What do people think is the best result from this combination? The question seems precisely that: what "people think". Because there can be different types of defaults depending of the types of people (educated or not, bi-scriptural,.. this is in part alluded to in the APMD Draft) or inter-application or man/machine. For example if the concerned page has a lot of visuals and language is only a help or is full text, this makes a real difference. This means that the same page may be better read by two different people with two different defaults. This kind of issue is precisely the purpose of the "context" we work on - which may include languages, locales, scripts, terminology etc. at low load (preloaded at boot in using the CRCD I documented). An XML page should be able to document its context tag and its elements to overide its langtag default. This corresponds to the mention of "preferences" in the Charter. jfc --=====================_10721106==.ALT Content-Type: text/html; charset="us-ascii" At 14:21 06/04/2005, L.Gillam wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
        boundary="----_=_NextPart_001_01C53AA3.212C7525"

Defaults + fallback = ?

If "en" defaults to en-Latn, does en-Cyrl falls back to en and default to en-Latn. Is it better to receive en-Latn rather than "nothing" in response to en-Cyrl? What if more than one script is implicated by the 2 letter language code, there is a default, but the fallback should produce all available?

What do people think is the best result from this combination?

The question seems precisely that: what "people think". Because there can be different types of defaults depending of the types of people (educated or not, bi-scriptural,.. this is in part alluded to in the  APMD Draft) or inter-application or man/machine. For example if the concerned page has a lot of visuals and language is only a help or  is full text, this makes a real difference.

This means that the same page may be better read by two different people with two different defaults. This kind of issue is precisely the purpose of the "context" we work on - which may include languages, locales, scripts, terminology etc. at low load (preloaded at boot in using the CRCD I documented). An XML page should be able to document its context tag and its elements to overide its langtag default. This corresponds to the mention of "preferences" in the Charter.

jfc

--=====================_10721106==.ALT-- --===============1095854910== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1095854910==-- From ltru-bounces@ietf.org Wed Apr 6 10:28:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16923; Wed, 6 Apr 2005 10:28:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJBTq-0000Qc-GE; Wed, 06 Apr 2005 10:26:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBGp-0002jQ-V8; Wed, 06 Apr 2005 10:12:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBGn-0002iC-Ef for ltru@megatron.ietf.org; Wed, 06 Apr 2005 10:12:37 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15635 for ; Wed, 6 Apr 2005 10:12:34 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050406141205.SMWV7277.mta10.adelphia.net@DEWELL> for ; Wed, 6 Apr 2005 10:12:05 -0400 Message-ID: <00c101c53ab2$991afe80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050406122800.HORV2135.mta2.adelphia.net@megatron.ietf.org> Date: Wed, 6 Apr 2005 07:11:58 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit I wrote: > John Cowan +ADw-jcowan at reutershealth dot com+AD4- wrote: > > +AD4APg- We could reverse the slash to a backslash, Java-style... I apologize profoundly for the UTF-7 garbage. Misha Wolf wrote: > Don't you mean: > > Description: Occitan (post 1500); Provençal > > or: > > Description: Occitan (post 1500); Provençal > > ? Yes, something like that. Both of these errors were brought to you by the Need for Sleep. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 10:31:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17505; Wed, 6 Apr 2005 10:31:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJBhq-00015Q-Ok; Wed, 06 Apr 2005 10:40:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBYA-00062N-2a; Wed, 06 Apr 2005 10:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBY7-00062F-TK for ltru@megatron.ietf.org; Wed, 06 Apr 2005 10:30:32 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17313 for ; Wed, 6 Apr 2005 10:30:27 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050406142957.TJYO7277.mta10.adelphia.net@DEWELL> for ; Wed, 6 Apr 2005 10:29:57 -0400 Message-ID: <00c701c53ab5$1a9b3cc0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 6 Apr 2005 07:29:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] New registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit The latest copy of the draft registry is now available: http://users.adelphia.net/~dewell/lstreg.txt (CRLF) http://users.adelphia.net/~dewell/lf/lstreg.txt (LF) In addition to the record-jar format, this version implements all of the content changes described over the past week. There is still some controversy over some technical details, such as the line continuation scheme and the /u escaping convention. Obviously these still need to be worked out among the group, and if any changes are decided upon, I will post a new version that reflects them. I haven't changed any of the links from my home page, and the HTML version and change-history page have not yet been updated. Please use only the links above to access the registry. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 10:52:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19295; Wed, 6 Apr 2005 10:52:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJC2B-0001gO-1o; Wed, 06 Apr 2005 11:01:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBoG-0004z9-Qb; Wed, 06 Apr 2005 10:47:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBoF-0004yk-Dp for ltru@megatron.ietf.org; Wed, 06 Apr 2005 10:47:11 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18761 for ; Wed, 6 Apr 2005 10:47:08 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050406144639.BHJJ4618.mta13.adelphia.net@DEWELL> for ; Wed, 6 Apr 2005 10:46:39 -0400 Message-ID: <00ce01c53ab7$6f7e46e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050406122800.HORV2135.mta2.adelphia.net@megatron.ietf.org> Date: Wed, 6 Apr 2005 07:46:36 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Registry in record-jar format - smart matching? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit L.Gillam wrote: > Defaults + fallback = ? > > If "en" defaults to en-Latn, does en-Cyrl falls back to en and default > to en-Latn. Is it better to receive en-Latn rather than "nothing" in > response to en-Cyrl? What if more than one script is implicated by the > 2 letter language code, there is a default, but the fallback should > produce all available? > > What do people think is the best result from this combination? If you request "en", that means you are willing to accept any English (i.e. anything tagged "en" or derivatives). If you request "en-Cyrl", you are specifically asking for Cyrillic-script English. I do not believe you should receive content tagged "en-Latn" in response to such a request. Adding the "default script" mechanism erases the distinction that was deliberately made by the user who requested "en-Cyrl." -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 10:56:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19938; Wed, 6 Apr 2005 10:56:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJC69-0001sK-1x; Wed, 06 Apr 2005 11:05:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBvZ-0006DF-L4; Wed, 06 Apr 2005 10:54:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBvY-0006Cw-KG for ltru@megatron.ietf.org; Wed, 06 Apr 2005 10:54:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19538 for ; Wed, 6 Apr 2005 10:54:42 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJC3u-0001k7-LK for ltru@ietf.org; Wed, 06 Apr 2005 11:03:24 -0400 Received: from eupig1 (unverified) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 6 Apr 2005 14:53:54 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IEJ003E75DRSG@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 06 Apr 2005 14:53:54 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Wed, 06 Apr 2005 14:53:51 +0000 Date: Wed, 06 Apr 2005 15:53:30 +0100 From: Misha Wolf Subject: RE: [Ltru] New registry To: ltru@ietf.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] New registry Thread-Index: AcU6tfUWUTeK9kTPTt+0jgdM5SyyuAAAQdwA content-class: urn:content-classes:message X-OriginalArrivalTime: 06 Apr 2005 14:53:51.0153 (UTC) FILETIME=[72094210:01C53AB8] X-Spam-Score: 0.8 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Hi Doug, Thanks for this. Some comments/questions/suggestions ... 1. Could we replace, eg: Description: Chichewa/u003B Chewa/u003B Nyanja with: Description: Chichewa Description: Chewa Description: Nyanja ? 2. I'm not happy with "Date". Consider "Deprecated". Is that not=20 a date? Could we change "Date" to something like "Added"? I'm not=20 sure what the field means (see below) so I can't give a clear=20 proposal. 3. What is the derivation/meaning of the date below? Type: region Subtag: CZ Description: Czech Republic Date: 2004-07-06 4. I hope we'll move to the XML-style NCRs. Many thanks, Misha -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Doug Ewell Sent: 06 April 2005 15:30 To: LTRU Working Group Subject: [Ltru] New registry The latest copy of the draft registry is now available: http://users.adelphia.net/~dewell/lstreg.txt (CRLF) http://users.adelphia.net/~dewell/lf/lstreg.txt (LF) In addition to the record-jar format, this version implements all of the content changes described over the past week. There is still some controversy over some technical details, such as the line continuation scheme and the /u escaping convention. Obviously these still need to be worked out among the group, and if any changes are decided upon, I will post a new version that reflects them. I haven't changed any of the links from my home page, and the HTML version and change-history page have not yet been updated. Please use only the links above to access the registry. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 12:21:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01211; Wed, 6 Apr 2005 12:21:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJDPZ-0005FD-7X; Wed, 06 Apr 2005 12:29:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDFH-0004SY-Si; Wed, 06 Apr 2005 12:19:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDFG-0004ST-RN for ltru@megatron.ietf.org; Wed, 06 Apr 2005 12:19:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01095 for ; Wed, 6 Apr 2005 12:19:07 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJDNb-0005DM-I3 for ltru@ietf.org; Wed, 06 Apr 2005 12:27:50 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 09:18:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed changes to region subtags Date: Wed, 6 Apr 2005 09:18:55 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEF6B3@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed changes to region subtags Thread-Index: AcU6VUGUhNG/finzTR27f+RP3eXh7wAa+XKA From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 06 Apr 2005 16:18:56.0781 (UTC) FILETIME=[553A43D0:01C53AC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable I put text to allow it into the editor's copy already. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: mardi 5 avril 2005 20:01 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: Proposed changes to region subtags >=20 > Hi - >=20 > > From: "Frank Ellermann" > > To: > > Sent: Saturday, April 02, 2005 1:43 PM > > Subject: [Ltru] Re: Proposed changes to region subtags > ... > > And one reason pro XML (clear support for Unicode character > > references in an otherwise US-ASCII text). JFTR, I prefer > > record-jar in the body of the I-D registry. > ... >=20 > Pardon the naive question: > Couldn't we simply use Unicode character references (as needed) > in a record-jar format? >=20 > Randy >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 12:36:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02274; Wed, 6 Apr 2005 12:36:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJDeC-0005aJ-RS; Wed, 06 Apr 2005 12:44:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDNq-00072y-RT; Wed, 06 Apr 2005 12:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDNp-00072o-5r for ltru@megatron.ietf.org; Wed, 06 Apr 2005 12:28:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01751 for ; Wed, 6 Apr 2005 12:27:58 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJDWC-0005Pv-2Y for ltru@ietf.org; Wed, 06 Apr 2005 12:36:41 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 09:27:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Language transformation Date: Wed, 6 Apr 2005 09:27:47 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEF6BB@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Language transformation Thread-Index: AcU6XsXkndfHL16LQROzE7S75uNuHQAZkQVQ From: "Addison Phillips" To: "JFC (Jefsey) Morfin" , "Randy Presuhn" , X-OriginalArrivalTime: 06 Apr 2005 16:27:48.0374 (UTC) FILETIME=[9214EB60:01C53AC5] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Apparently this wasn't explained simply enough the last few times? XML, HTML, CSS, CLDR, LDAP, XSLT, J2EE, .NET are all applications that = use RFC 3066 language tags. This is not an exhaustive list. Some of the = items are proprietary in nature and others are open standards widely = implemented. NONE of them need to be referenced in RFC 3066bis: they are examples of = (potential) consumers of that document, not the other way around. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of JFC (Jefsey) Morfin > Sent: mardi 5 avril 2005 21:07 > To: Randy Presuhn; ltru@ietf.org > Subject: Re: [Ltru] Re: Language transformation >=20 > At 05:51 06/04/2005, Randy Presuhn wrote: > >This kind of remark obviously make me react. Whose plan: IETF, IESG, = IAB? > > > >Obviously not, since CLDR is a Unicode project. > >http://www.unicode.org/cldr/ > > > > > 1. this CLDR plan should be documented in the Draft as per = Charter. At > > > least to explain why it is not supported now. > >... > > > >There is no such requirement in the charter. The charter mentions = CLDR > as > >one of the users of RFC 3066. >=20 > I dont think this is correct. The CLDR is not documented by any RFC. = This > is a copyrighted private project. There are other projects with = comparable > aims and different needs. The needs of the CLDR are parts of the needs > calling a the BPC 047 review. In not quoting CLDR the current draft > implies > that the CLDR needs are satisfied what puts it ad advantage over other > projects or projects studies the needs of which are not satisfied. >=20 > I fully understand that CLDR IPRs should be respected, the same as = other > projects. But the Internet standard process calls for protected = solutions > to be considered after open ones. > jfc >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 12:36:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02302; Wed, 6 Apr 2005 12:36:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJDeZ-0005ae-8V; Wed, 06 Apr 2005 12:45:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDVh-0007ae-Dk; Wed, 06 Apr 2005 12:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDVf-0007aC-8U for ltru@megatron.ietf.org; Wed, 06 Apr 2005 12:36:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02263 for ; Wed, 6 Apr 2005 12:36:04 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJDe3-0005Zl-6R for ltru@ietf.org; Wed, 06 Apr 2005 12:44:47 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 09:35:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed changes to region subtags Date: Wed, 6 Apr 2005 09:35:57 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEF6CD@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed changes to region subtags Thread-Index: AcU6ZQ9tfYVIoVheT+uXqeOt9R3L/gAYL2lA From: "Addison Phillips" To: "John Cowan" , "Doug Ewell" X-OriginalArrivalTime: 06 Apr 2005 16:35:57.0993 (UTC) FILETIME=[B5EAD990:01C53AC6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable > The annoyance is then that you need to use two of them to represent a > non-BMP character, which artificially imports UTF-16 rules into the > stream of characters. I'm sufficiently familiar with Unicode to avoid this. The text I wrote = was specifically chosen to mean Unicode Scalar Value. It is in = "Java-style" visually only: the escapes would be "/u1234" or "/u23456" = or "/u10FFFD", but not "/u123". All of which is moot: see below. > I don't understand any of this. Why does the existing format escape > semicolons? They aren't used as record-jar delimiters. Furthermore, > XML character references don't require escaped semicolons, because > they are magic only inside a character (or entity) reference. Semi-colons are mentioned in the text to separate multiple values in a = field. We could allow repeated fields, although Description strikes me = as a problem. Are you SURE you don't want an XML format? :-) I don't care if we use XML style NCRs instead of the escape format I = picked out (more or less at random) and will modify the text = appropriately to use the NCR style instead. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: mardi 5 avril 2005 21:55 > To: Doug Ewell > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Proposed changes to region subtags >=20 > Doug Ewell scripsit: >=20 > > We could reverse the slash to a backslash, Java-style. That way we > > would only need to escape the backslash (which we do anyway, if we = use > > it for continuation) and not the forward slash (though at present = there > > are no forward slashes to be escaped). >=20 > The annoyance is then that you need to use two of them to represent a > non-BMP character, which artificially imports UTF-16 rules into the > stream of characters. >=20 > > Using XML references would require the ampersand to be escaped = (there > > aren't any of those in the registry either), and poses an = interesting > > problem with the semicolon, which is already escaped because of its = role > > in separating lists (e.g. of recommended prefixes). The registry = has > > several descriptions of the form "Occitan (post 1500); Provencal" = where > > the semicolon, inherited from the ISO 639 description, needs to be > > escaped. If the 'c' in "Provencal" were a c-with-cedilla (=E7), = which I > > think it's supposed to be anyway, then that would translated to the = XML > > reference ç and I think you'd have to re-escape the trailing > > semicolon. >=20 > I don't understand any of this. Why does the existing format escape > semicolons? They aren't used as record-jar delimiters. Furthermore, > XML character references don't require escaped semicolons, because > they are magic only inside a character (or entity) reference. >=20 > -- > John Cowan jcowan@reutershealth.com www.reutershealth.com > www.ccil.org/~cowan > I come from under the hill, and under the hills and over the hills my > paths > led. And through the air. I am he that walks unseen. I am the = clue-finder, > the web-cutter, the stinging fly. I was chosen for the lucky number. = -- > Bilbo >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 12:39:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02887; Wed, 6 Apr 2005 12:39:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJDhc-0005hh-PO; Wed, 06 Apr 2005 12:48:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDYZ-0008TI-Ow; Wed, 06 Apr 2005 12:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDYY-0008Sb-5m for ltru@megatron.ietf.org; Wed, 06 Apr 2005 12:39:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02745 for ; Wed, 6 Apr 2005 12:39:03 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJDgw-0005ez-5m for ltru@ietf.org; Wed, 06 Apr 2005 12:47:46 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 09:38:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit Date: Wed, 6 Apr 2005 09:38:56 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEF6D5@irvmbxw01.quest.com> Thread-Topic: +AFs-Ltru+AF0- Re: +AFs-Ltru+AF0- Re: Proposed changes to region subtags Thread-Index: AcU6ZpO87CsKbw/vR1aUztho/eRMNwAYDRTw From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 06 Apr 2005 16:38:57.0023 (UTC) FILETIME=[20A0A8F0:01C53AC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Subject: [Ltru] RE: +AFs-Ltru+AF0- Re: +AFs-Ltru+AF0- Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit The trailing semi-colon is actually required when processing the NCRs back into characters. Consider this text: +ACYAIw-x10CDEF Is that: U+-10CD? U+-10CDE? U+-10CDEF? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. +AD4- -----Original Message----- +AD4- From: ltru-bounces+AEA-lists.ietf.org +AFs-mailto:ltru-bounces+AEA-lists.ietf.org+AF0- On +AD4- Behalf Of Doug Ewell +AD4- Sent: mardi 5 avril 2005 22:04 +AD4- To: LTRU Working Group +AD4- Subject: +AFs-Ltru+AF0- Re: +AFs-Ltru+AF0- Re: Proposed changes to region subtags +AD4- +AD4- John Cowan +ADw-jcowan at reutershealth dot com+AD4- wrote: +AD4- +AD4- +AD4APg- We could reverse the slash to a backslash, Java-style... +AD4- +AD4- +AD4- +AD4- The annoyance is then that you need to use two of them to represent a +AD4- +AD4- non-BMP character, which artificially imports UTF-16 rules into the +AD4- +AD4- stream of characters. +AD4- +AD4- Other than the fact that there aren't likely to be many non-BMP +AD4- characters in the registry, couldn't this be simply expanded to the +AD4- capital-U form, thus +ACIAXA-U00010414+ACI-? +AD4- +AD4- +AD4APg- Using XML references would require the ampersand to be escaped (there +AD4- +AD4APg- aren't any of those in the registry either), and poses an interesting +AD4- +AD4APg- problem with the semicolon, which is already escaped because of its +AD4- +AD4APg- role in separating lists (e.g. of recommended prefixes)... +AD4- +AD4- +AD4- +AD4- I don't understand any of this. Why does the existing format escape +AD4- +AD4- semicolons? They aren't used as record-jar delimiters. +AD4- +AD4- Because of their role in separating lists (e.g. of recommended +AD4- prefixes). +AD4- +AD4- +AD4- Furthermore, XML character references don't require escaped +AD4- +AD4- semicolons, because they are magic only inside a character (or entity) +AD4- +AD4- reference. +AD4- +AD4- I see your point. Then we would have: +AD4- +AD4- Description: Occitan (post 1500)+ACYAIw-x003B Proven+ACYAIw-x00E7+ADs-al +AD4- +AD4- Is that OK? Does the semicolon that terminates the character reference +AD4- cause any problems that anyone can see? +AD4- +AD4- -Doug Ewell +AD4- Fullerton, California +AD4- http://users.adelphia.net/+AH4-dewell/ +AD4- +AD4- +AD4- +AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- +AD4- Ltru mailing list +AD4- Ltru+AEA-lists.ietf.org +AD4- https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 13:01:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04965; Wed, 6 Apr 2005 13:01:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJE2H-0006JT-1m; Wed, 06 Apr 2005 13:09:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDqa-0001LV-V7; Wed, 06 Apr 2005 12:57:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDqZ-0001LN-O1 for ltru@megatron.ietf.org; Wed, 06 Apr 2005 12:57:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04704 for ; Wed, 6 Apr 2005 12:57:40 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJDyx-0006EK-Bf for ltru@ietf.org; Wed, 06 Apr 2005 13:06:23 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 09:57:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] New registry Date: Wed, 6 Apr 2005 09:57:33 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEF6EE@irvmbxw01.quest.com> Thread-Topic: [Ltru] New registry Thread-Index: AcU6tfUWUTeK9kTPTt+0jgdM5SyyuAAAQdwAAASKIeA= From: "Addison Phillips" To: "Misha Wolf" , X-OriginalArrivalTime: 06 Apr 2005 16:57:33.0829 (UTC) FILETIME=[BA4BBB50:01C53AC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable See comments below. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Misha Wolf > Sent: mercredi 6 avril 2005 07:54 > To: ltru@ietf.org > Subject: RE: [Ltru] New registry >=20 > Hi Doug, >=20 > Thanks for this. Some comments/questions/suggestions ... >=20 > 1. Could we replace, eg: >=20 > Description: Chichewa/u003B Chewa/u003B Nyanja >=20 > with: >=20 > Description: Chichewa > Description: Chewa > Description: Nyanja >=20 > ? [Addison Phillips]=20 Yes, we can allow fields to be repeated. BTW> Your example is incorrect, = since the semi-colon is only escaped in a value because the un-escaped = semi-colon is the separator character. >=20 > 2. I'm not happy with "Date". Consider "Deprecated". Is that not > a date? Could we change "Date" to something like "Added"? I'm not > sure what the field means (see below) so I can't give a clear > proposal. [Addison Phillips]=20 I didn't rename the fields. Previously, though, the names didn't appear = in the registry. I can change it to "Added" >=20 > 3. What is the derivation/meaning of the date below? >=20 > Type: region > Subtag: CZ > Description: Czech Republic > Date: 2004-07-06 [Addison Phillips]=20 That particular one? Or in general? The Date field is the date the value = became valid. That example might not be accurate, of course. >=20 > 4. I hope we'll move to the XML-style NCRs. [Addison Phillips]=20 I'm changing the editor's copy to do exactly that. >=20 > Many thanks, > Misha >=20 >=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On Behalf Of Doug Ewell > Sent: 06 April 2005 15:30 > To: LTRU Working Group > Subject: [Ltru] New registry >=20 > The latest copy of the draft registry is now available: >=20 > http://users.adelphia.net/~dewell/lstreg.txt (CRLF) > http://users.adelphia.net/~dewell/lf/lstreg.txt (LF) >=20 > In addition to the record-jar format, this version implements all of = the > content changes described over the past week. >=20 > There is still some controversy over some technical details, such as = the > line continuation scheme and the /u escaping convention. Obviously > these still need to be worked out among the group, and if any changes > are decided upon, I will post a new version that reflects them. >=20 > I haven't changed any of the links from my home page, and the HTML > version and change-history page have not yet been updated. Please use > only the links above to access the registry. >=20 > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 >=20 > ----------------------------------------------------------------- > Visit our Internet site at http://www.reuters.com >=20 > To find out more about Reuters Products and Services visit > http://www.reuters.com/productinfo >=20 > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be > the views of Reuters Ltd. >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 13:12:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06645; Wed, 6 Apr 2005 13:12:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJECx-0006jp-Om; Wed, 06 Apr 2005 13:20:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJE4M-0007Av-61; Wed, 06 Apr 2005 13:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJE4K-000777-G9 for ltru@megatron.ietf.org; Wed, 06 Apr 2005 13:11:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06609 for ; Wed, 6 Apr 2005 13:11:53 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJECh-0006jC-M3 for ltru@ietf.org; Wed, 06 Apr 2005 13:20:37 -0400 Received: from eupig1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 6 Apr 2005 17:11:42 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IEJ008FRBRIWF@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 06 Apr 2005 17:11:42 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Wed, 06 Apr 2005 17:11:41 +0000 Date: Wed, 06 Apr 2005 18:11:41 +0100 From: Misha Wolf Subject: RE: [Ltru] New registry To: ltru@ietf.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] New registry Thread-Index: AcU6tfUWUTeK9kTPTt+0jgdM5SyyuAAAQdwAAASKIeAAAGEdIA== content-class: urn:content-classes:message X-OriginalArrivalTime: 06 Apr 2005 17:11:41.0855 (UTC) FILETIME=[B3C23AF0:01C53ACB] X-Spam-Score: 0.8 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Hi Addison, > > 1. Could we replace, eg: > >=20 > > Description: Chichewa/u003B Chewa/u003B Nyanja > >=20 > > with: > >=20 > > Description: Chichewa > > Description: Chewa > > Description: Nyanja > >=20 > > ? > [Addison Phillips]=20 >=20 > Yes, we can allow fields to be repeated. Great. > BTW> Your example is incorrect, since the semi-colon is only=20 > escaped in a value because the un-escaped semi-colon is the=20 > separator character. The example is taken from the draft registry. > > 2. I'm not happy with "Date". Consider "Deprecated". Is that not > > a date? Could we change "Date" to something like "Added"? I'm not > > sure what the field means (see below) so I can't give a clear > > proposal. > [Addison Phillips]=20 >=20 > I didn't rename the fields. Previously, though, the names didn't=20 > appear in the registry. I can change it to "Added" Great. > > 3. What is the derivation/meaning of the date below? > >=20 > > Type: region > > Subtag: CZ > > Description: Czech Republic > > Date: 2004-07-06 > [Addison Phillips]=20 >=20 > That particular one? Or in general? The Date field is the date the=20 > value became valid. That example might not be accurate, of course. Do you mean valid? Doug wrote that it is the date when the item was=20 added to the registry. > > 4. I hope we'll move to the XML-style NCRs. > [Addison Phillips]=20 >=20 > I'm changing the editor's copy to do exactly that. Great. Thanks, Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 13:31:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08717; Wed, 6 Apr 2005 13:31:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEVw-0007MA-4Z; Wed, 06 Apr 2005 13:40:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEMC-0007BA-3Z; Wed, 06 Apr 2005 13:30:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJEMA-0007B5-Om for ltru@megatron.ietf.org; Wed, 06 Apr 2005 13:30:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08604 for ; Wed, 6 Apr 2005 13:30:19 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJEUX-0007Jh-Uk for ltru@ietf.org; Wed, 06 Apr 2005 13:39:03 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j36HUA06019832; Wed, 6 Apr 2005 13:30:10 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 6 Apr 2005 13:30:10 -0400 Date: Wed, 6 Apr 2005 13:30:09 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] Re: Proposed changes to region subtags Message-ID: <20050406173009.GF19578@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AEEF6CD@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AEEF6CD@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Addison Phillips scripsit: > I'm sufficiently familiar with Unicode to avoid this. The text I > wrote was specifically chosen to mean Unicode Scalar Value. It is in > "Java-style" visually only: the escapes would be "/u1234" or "/u23456" > or "/u10FFFD", but not "/u123". All of which is moot: see below. Ah, but in that case /u10FFFD could mean /u10FF followed by F followed by D. Non-delimited formats have to be fixed length (as Java's is). > Semi-colons are mentioned in the text to separate multiple values in > a field. Which is just what they are doing in the language entries. So why escape them there? > I don't care if we use XML style NCRs instead of the escape format > I picked out (more or less at random) and will modify the text > appropriately to use the NCR style instead. Good. It's variable length and delimited. -- John Cowan jcowan@reutershealth.com www.reutershealth.com ccil.org/~cowan Dievas dave dantis; Dievas duos duonos --Lithuanian proverb Deus dedit dentes; deus dabit panem --Latin version thereof Deity donated dentition; deity'll donate doughnuts --English version by Muke Tever God gave gums; God'll give granary --Version by Mat McVeagh _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 14:13:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12110; Wed, 6 Apr 2005 14:13:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJFAU-0008Or-Ii; Wed, 06 Apr 2005 14:22:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJF1C-0004Zj-Vu; Wed, 06 Apr 2005 14:12:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJF1A-0004Za-OG for ltru@megatron.ietf.org; Wed, 06 Apr 2005 14:12:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12028 for ; Wed, 6 Apr 2005 14:12:43 -0400 (EDT) Received: from boole.openldap.org ([204.152.186.50] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJF9Z-0008Ms-3S for ltru@ietf.org; Wed, 06 Apr 2005 14:21:25 -0400 Received: from gyspy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j36ICf4w086043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Apr 2005 18:12:41 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <6.2.1.2.0.20050406103739.05f45d60@mail.openldap.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 06 Apr 2005 11:12:15 -0700 To: "McDonald, Ira" From: "Kurt D. Zeilenga" Subject: Compatibility with existing use (LDAP) (RE: [Ltru] Re: Registry in record-jar format) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.1 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Ira, and other LTRU'ers: I am thinking that the LTRU effort should be considered more of a "replacement" effort than a "revision" effort, at least in its present form. If you change the syntax and semantics of RFC 3066 tags, you will break everything that relies on them. It would be better, in my opinion, to develop a new kind of tag which had a new syntax and semantics. That new kind of tag could be used in new things, possibly with support for existing RFC 3066 tags, but not in old things (at least not without revision of the old thing). I note that LDAP relies heavy on a number of aspects of RFC 3066 tags, most importantly that there is a well-defined syntactical tag hierarchy that doesn't require the implementation to know the tag's validity nor semantics to make use of tags in providing service. For instance, an LDAP server need not care if "FOO-BAR" is a valid tag to allow a client to add (a CN value tagged with "FOO-BAR"): cn;lang-FOO-BAR: foo bar nor provide results a client requesting the return of all subtags of "FOO", e.g., (cn;lang-FOO-=*). The only requirement (and I believe its a SHOULD, not a MUST) is for the directory client adding values to use the most specific tag known to it and for requesting clients to use the least specific tag that will return acceptable (or desirable) stored values. It is noted that the client itself generally doesn't valid tags either, as tag (and range) knowledge generally comes from the user. So, not only does it concern me that these new tags don't follow the same syntactical hierarchy (and may require fuzzy matching), it concerns me that the new specification mandates that implementations be aware of what tags/subtags are registered (at some time). That, to me, is like requiring SMTP implementations to know what MIME types are registered. Just as the SMTP is just a transport for MIME type information, protocols like LDAP are (primarily) just a transport for language information. (LDAP also support lookups based on syntactical hierarchy, not the semantical hierarchy.) I think it unwise for protocols to, themselves, rely on value registries as this leads to fragile interoperability. Registeries are better used to ensure that values in specifications are unique. Apologies for commenting without fully digesting the WG's draft in this area, or list archives, but it seems more appropriate for me to comment sooner than later. Kurt At 10:27 AM 4/6/2005, McDonald, Ira wrote: >Hi Kurt, > >Thanks very much - what LTRU is doing is rewriting >RFC 3066 and _greatly_ extending it to formally >address variants and scripts and other subtags. > >The nature and scope of the extensions breaks classic >left-to-right language tag matching completely. The >phrase being used on the list for the replacement >is 'smart matching'. Just how smart a piece of s/w >can be is the crux of the problem. And there is no >concensus on the list about what algorithm should be >used for 'smart matching'. > >Also, LTRU is developing an IANA registry of EVERY >possible valid language tag. Which is a noble ideal, >but... (the logic is that this frees language tags >from dependency on possibly incompatible changes in >ISO 639-x and ISO 3166-x, which have in fact occurred) > >Cheers, >- Ira > > >Ira McDonald (Musician / Software Architect) >Blue Roof Music / High North Inc >PO Box 221 Grand Marais, MI 49839 >phone: +1-906-494-2434 >email: imcdonald@sharplabs.com > >-----Original Message----- >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] >Sent: Tuesday, April 05, 2005 3:40 PM >To: McDonald, Ira >Subject: RE: [Ltru] Re: Registry in record-jar format > > >Ira, > >I'm not in a position to comment on this thread as I haven't >caught up on what LTRU is or isn't trying to do to language >tags and language ranges. I'm now subscribed to the LTRU >list and after I read up (not soon), I'll comment (likely >starting with a summary of how language tags and ranges >are used in LDAP, and why). > >Kurt > >At 02:17 PM 4/4/2005, you wrote: >>Hi, >> >>Relative to 'RFC 2616' matching rules below: >> >>It would be well to _explicitly_ address the impact of RFC3066bis >>matching rules on the recently published standards-track RFC 3866 >>"Language Tags and Ranges in the LDAP" (July 2004). If directory >>entries and/or directory attributes are returned 'incorrectly' by >>following RFC3066bis versus RFC3066, then this will have a visible >>impact on many enterprise applications. >> >>And to answer the immediate criticism, no I don't know the precise >>text to be added. Perhaps Kurt Zeilenga (editor of RFC 3866) can >>comment? I copied him on this reply. >> >>Cheers, >>- Ira >> >>Ira McDonald (Musician / Software Architect) >>Blue Roof Music / High North Inc >>PO Box 221 Grand Marais, MI 49839 >>phone: +1-906-494-2434 >>email: imcdonald@sharplabs.com >> >>-----Original Message----- >>From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On >>Behalf Of Addison Phillips >>Sent: Monday, April 04, 2005 4:23 PM >>To: John Cowan >>Cc: ltru@ietf.org >>Subject: RE: [Ltru] Re: Registry in record-jar format >> >> >>See below. >> >>Addison P. Phillips >>Globalization Architect, Quest Software >>Chair, W3C Internationalization Core Working Group >> >>Internationalization is not a feature. >>It is an architecture. >> >>> -----Original Message----- >>> From: John Cowan [mailto:jcowan@reutershealth.com] >>> Sent: lundi 4 avril 2005 13:03 >>> To: Addison Phillips >>> Cc: ltru@ietf.org >>> Subject: Re: [Ltru] Re: Registry in record-jar format >>> >>> Addison Phillips scripsit: >>> >>> > Answer: Yes, it is a problem, since users might have to specify two >>> > ranges or may get results inconsistent with their expectations. For >>> > example, the range "zh-TW" does not match the tag "zh-Hant-TW" using >>> > strict 3066 matching rules. >>> >>> Just a terminological note: I think these should be called HTTP or RFC >>> 2616 >>> matching rules, since RFC 2616 is the true and authoritative source for >>> them. >>[Addison Phillips] >> >>Agreed. >> >>> >>> > i. "Extended Range Matching" is an extension of RFR in which "missing" >>> > subtags are considered to be (or are expanded to be) wildcards. So >>> > "de-1901" is expanded to "de-*-*-1901" and matches "de-Latn-1901" and >>> > "de-AT-1901", not to mention "de-Latg-NA-1901". >>> >>> I think this should be mentioned in the matching I-D. >>[Addison Phillips] >> >>I believe it is, although not this specific example. See >>http://www.inter-locale.com/ID/draft-ietf-ltru-matching-00.html#extrange >> >>> >>> > NB> Probably we need to extend this scheme to allow users to specify >>> > that they do NOT want a specific field to be filled in. For example >>> > "de-!-1901" would match only "de-1901" and not a tag such as >>> > "de-Latn-1901". >>> >>> I'd like to see a use case for this (not involving boont). >>[Addison Phillips] >> >>Find all content in need of retagging with a script in my Traditional >>Chinese document using XPath: >> >>/*@[lang="zh-!-TW"] >>> >>> > ii. "Lookup" is the opposite of matching, in which subtags are removed >>> > from the tag rather than the range (i.e. locale-style) to fill in all >>> > slots in a dataset. This matches a very different content set. >>> >>> This too should be mentioned. >>[Addison Phillips] >> >>Being added. Mark supplied text that I haven't had time to insert. >>> >>> > iii. "Scored Matching" was proposed by John Cowan and produces content >>> > with a range of scores, allowing the content to be filtered by choosing >>> > a "quality level" (my words) for the match. The user can set a >threshold >>> > for matching, presumably. >>> >>> As should this. >>[Addison Phillips] >> >>Agreed. >>> >>> > The problem here is that matching cannot be as simple as it was under >>> > RFC 3066 and still capture all possible cases. >>> >>> This is badly stated. Only matching of predefined tags in RFC 3066 >>> captures >>> all cases. >>[Addison Phillips] >> >>It is badly stated. But I'm not sure your version captures the nuances >>either. Perhaps: >> >>Only generative tags in RFC 3066 (i.e. those with only two possible >subtags) >>are guaranteed to work with RFC 2616 defined matching. >>> >>> -- >>> Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. >>> Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) >>> Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, >>> hoopsa! >>> -- Joyce, Ulysses, "Oxen of the Sun" jcowan@reutershealth.com >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 14:32:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13962; Wed, 6 Apr 2005 14:32:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJFT6-0000UY-Jh; Wed, 06 Apr 2005 14:41:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJFIV-0001tV-DK; Wed, 06 Apr 2005 14:30:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJFIU-0001tQ-Jx for ltru@megatron.ietf.org; Wed, 06 Apr 2005 14:30:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13650 for ; Wed, 6 Apr 2005 14:30:36 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJFQt-0000NN-4j for ltru@ietf.org; Wed, 06 Apr 2005 14:39:19 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 11:30:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Compatibility with existing use (LDAP) (RE: [Ltru] Re:Registry in record-jar format) Date: Wed, 6 Apr 2005 11:30:24 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEF789@irvmbxw01.quest.com> Thread-Topic: Compatibility with existing use (LDAP) (RE: [Ltru] Re:Registry in record-jar format) Thread-Index: AcU61FmNs133VlX1RMGnPh3NoyRPRgAAFG6w From: "Addison Phillips" To: "Kurt D. Zeilenga" , "McDonald, Ira" X-OriginalArrivalTime: 06 Apr 2005 18:30:25.0796 (UTC) FILETIME=[B3726C40:01C53AD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Content-Transfer-Encoding: quoted-printable Hi Kurt, Actually, the tags defined by LTRU's draft were specifically defined so = that they do exactly what you say: they are hierarchical in the same way = and use the same structure as the existing RFC 3066 tags. Applications = such as LDAP that rely on prefix-matching will continue to work exactly = as they have before. The problem here is that we introduce some subtags into the middle of = the existing generative syntax. That is, if you previously had entries = in the form: cn;lang-en-US You might now get entries of the form: cn;lang-en-Latn-US Prefix matching still works as advertised. The question is: what happens = when users request "en-US"? In RFC 3866, the answer is you don't get any = "en-Latn-US" entries. This is also true of other applications, such as = CSS, XML, HTTP, and so forth. It is how prefix matching works, after = all. In practice many of us don't think this will present an insuperable = problem, since specific languages need script subtags (that's what the = inserted thing is) and those languages will use them all the time. LDAP = administrators and users would have to modify their existing records to = transition these languages, of course, to gain the script recognition. The alternative is to place all the new subtags at the end of the = existing RFC 3066 form. The problem here is that this *does* break the = simple prefix matching for the new tags (script is more closely related = to language than variants and regions are) and it complicates handling = and parsing tags in which multiple variants can occur. Another way to say this is that you only have a problem with 3066bis as = written when transitioning the contents of an LDAP registry to it, = whereas the alternative design requires a change in your algorithm. It should be noted that language tags defined by 3066bis are all legal = tags for registration under 3066 and that this kind of problem already = exists with a selected subclass of valid 3066 tags. What we are discussing with regard to fuzzy matching is what one does = when one wants finer grained control over matching than what prefix = matching can provide. That's something you might want to consider for a = future version of 3866, but it isn't a requirement either. Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Kurt D. Zeilenga > Sent: mercredi 6 avril 2005 11:12 > To: McDonald, Ira > Cc: ltru@ietf.org > Subject: Compatibility with existing use (LDAP) (RE: [Ltru] = Re:Registry in > record-jar format) >=20 > Ira, and other LTRU'ers: >=20 > I am thinking that the LTRU effort should be considered > more of a "replacement" effort than a "revision" effort, > at least in its present form. If you change the syntax > and semantics of RFC 3066 tags, you will break everything > that relies on them. It would be better, in my opinion, > to develop a new kind of tag which had a new syntax and > semantics. That new kind of tag could be used in new > things, possibly with support for existing RFC 3066 tags, > but not in old things (at least not without revision of > the old thing). >=20 > I note that LDAP relies heavy on a number of aspects of > RFC 3066 tags, most importantly that there is a > well-defined syntactical tag hierarchy that doesn't > require the implementation to know the tag's validity > nor semantics to make use of tags in providing service. >=20 > For instance, an LDAP server need not care if > "FOO-BAR" is a valid tag to allow a client to add > (a CN value tagged with "FOO-BAR"): > cn;lang-FOO-BAR: foo bar >=20 > nor provide results a client requesting the return of all > subtags of "FOO", e.g., (cn;lang-FOO-=3D*). >=20 > The only requirement (and I believe its a SHOULD, > not a MUST) is for the directory client adding values > to use the most specific tag known to it and for > requesting clients to use the least specific tag that > will return acceptable (or desirable) stored values. > It is noted that the client itself generally doesn't > valid tags either, as tag (and range) knowledge > generally comes from the user. >=20 > So, not only does it concern me that these new tags > don't follow the same syntactical hierarchy (and may > require fuzzy matching), it concerns me that > the new specification mandates that implementations > be aware of what tags/subtags are registered (at > some time). That, to me, is like requiring SMTP > implementations to know what MIME types are registered. > Just as the SMTP is just a transport for MIME type > information, protocols like LDAP are (primarily) just > a transport for language information. (LDAP also > support lookups based on syntactical hierarchy, not > the semantical hierarchy.) >=20 > I think it unwise for protocols to, themselves, > rely on value registries as this leads to fragile > interoperability. Registeries are better used to > ensure that values in specifications are unique. >=20 > Apologies for commenting without fully digesting > the WG's draft in this area, or list archives, but > it seems more appropriate for me to comment sooner > than later. >=20 > Kurt >=20 >=20 > At 10:27 AM 4/6/2005, McDonald, Ira wrote: > >Hi Kurt, > > > >Thanks very much - what LTRU is doing is rewriting > >RFC 3066 and _greatly_ extending it to formally > >address variants and scripts and other subtags. > > > >The nature and scope of the extensions breaks classic > >left-to-right language tag matching completely. The > >phrase being used on the list for the replacement > >is 'smart matching'. Just how smart a piece of s/w > >can be is the crux of the problem. And there is no > >concensus on the list about what algorithm should be > >used for 'smart matching'. > > > >Also, LTRU is developing an IANA registry of EVERY > >possible valid language tag. Which is a noble ideal, > >but... (the logic is that this frees language tags > >from dependency on possibly incompatible changes in > >ISO 639-x and ISO 3166-x, which have in fact occurred) > > > >Cheers, > >- Ira > > > > > >Ira McDonald (Musician / Software Architect) > >Blue Roof Music / High North Inc > >PO Box 221 Grand Marais, MI 49839 > >phone: +1-906-494-2434 > >email: imcdonald@sharplabs.com > > > >-----Original Message----- > >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > >Sent: Tuesday, April 05, 2005 3:40 PM > >To: McDonald, Ira > >Subject: RE: [Ltru] Re: Registry in record-jar format > > > > > >Ira, > > > >I'm not in a position to comment on this thread as I haven't > >caught up on what LTRU is or isn't trying to do to language > >tags and language ranges. I'm now subscribed to the LTRU > >list and after I read up (not soon), I'll comment (likely > >starting with a summary of how language tags and ranges > >are used in LDAP, and why). > > > >Kurt > > > >At 02:17 PM 4/4/2005, you wrote: > >>Hi, > >> > >>Relative to 'RFC 2616' matching rules below: > >> > >>It would be well to _explicitly_ address the impact of RFC3066bis > >>matching rules on the recently published standards-track RFC 3866 > >>"Language Tags and Ranges in the LDAP" (July 2004). If directory > >>entries and/or directory attributes are returned 'incorrectly' by > >>following RFC3066bis versus RFC3066, then this will have a visible > >>impact on many enterprise applications. > >> > >>And to answer the immediate criticism, no I don't know the precise > >>text to be added. Perhaps Kurt Zeilenga (editor of RFC 3866) can > >>comment? I copied him on this reply. > >> > >>Cheers, > >>- Ira > >> > >>Ira McDonald (Musician / Software Architect) > >>Blue Roof Music / High North Inc > >>PO Box 221 Grand Marais, MI 49839 > >>phone: +1-906-494-2434 > >>email: imcdonald@sharplabs.com > >> > >>-----Original Message----- > >>From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org]On > >>Behalf Of Addison Phillips > >>Sent: Monday, April 04, 2005 4:23 PM > >>To: John Cowan > >>Cc: ltru@ietf.org > >>Subject: RE: [Ltru] Re: Registry in record-jar format > >> > >> > >>See below. > >> > >>Addison P. Phillips > >>Globalization Architect, Quest Software > >>Chair, W3C Internationalization Core Working Group > >> > >>Internationalization is not a feature. > >>It is an architecture. > >> > >>> -----Original Message----- > >>> From: John Cowan [mailto:jcowan@reutershealth.com] > >>> Sent: lundi 4 avril 2005 13:03 > >>> To: Addison Phillips > >>> Cc: ltru@ietf.org > >>> Subject: Re: [Ltru] Re: Registry in record-jar format > >>> > >>> Addison Phillips scripsit: > >>> > >>> > Answer: Yes, it is a problem, since users might have to specify = two > >>> > ranges or may get results inconsistent with their expectations. = For > >>> > example, the range "zh-TW" does not match the tag "zh-Hant-TW" = using > >>> > strict 3066 matching rules. > >>> > >>> Just a terminological note: I think these should be called HTTP or = RFC > >>> 2616 > >>> matching rules, since RFC 2616 is the true and authoritative = source > for > >>> them. > >>[Addison Phillips] > >> > >>Agreed. > >> > >>> > >>> > i. "Extended Range Matching" is an extension of RFR in which > "missing" > >>> > subtags are considered to be (or are expanded to be) wildcards. = So > >>> > "de-1901" is expanded to "de-*-*-1901" and matches = "de-Latn-1901" > and > >>> > "de-AT-1901", not to mention "de-Latg-NA-1901". > >>> > >>> I think this should be mentioned in the matching I-D. > >>[Addison Phillips] > >> > >>I believe it is, although not this specific example. See > = >>http://www.inter-locale.com/ID/draft-ietf-ltru-matching-00.html#extrang= e > >> > >>> > >>> > NB> Probably we need to extend this scheme to allow users to = specify > >>> > that they do NOT want a specific field to be filled in. For = example > >>> > "de-!-1901" would match only "de-1901" and not a tag such as > >>> > "de-Latn-1901". > >>> > >>> I'd like to see a use case for this (not involving boont). > >>[Addison Phillips] > >> > >>Find all content in need of retagging with a script in my = Traditional > >>Chinese document using XPath: > >> > >>/*@[lang=3D"zh-!-TW"] > >>> > >>> > ii. "Lookup" is the opposite of matching, in which subtags are > removed > >>> > from the tag rather than the range (i.e. locale-style) to fill = in > all > >>> > slots in a dataset. This matches a very different content set. > >>> > >>> This too should be mentioned. > >>[Addison Phillips] > >> > >>Being added. Mark supplied text that I haven't had time to insert. > >>> > >>> > iii. "Scored Matching" was proposed by John Cowan and produces > content > >>> > with a range of scores, allowing the content to be filtered by > choosing > >>> > a "quality level" (my words) for the match. The user can set a > >threshold > >>> > for matching, presumably. > >>> > >>> As should this. > >>[Addison Phillips] > >> > >>Agreed. > >>> > >>> > The problem here is that matching cannot be as simple as it was > under > >>> > RFC 3066 and still capture all possible cases. > >>> > >>> This is badly stated. Only matching of predefined tags in RFC = 3066 > >>> captures > >>> all cases. > >>[Addison Phillips] > >> > >>It is badly stated. But I'm not sure your version captures the = nuances > >>either. Perhaps: > >> > >>Only generative tags in RFC 3066 (i.e. those with only two possible > >subtags) > >>are guaranteed to work with RFC 2616 defined matching. > >>> > >>> -- > >>> Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. > >>> Send us, bright one, light one, Horhorn, quickening, and = wombfruit. > (3x) > >>> Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, = boyaboy, > >>> hoopsa! > >>> -- Joyce, Ulysses, "Oxen of the Sun" = jcowan@reutershealth.com > >> > >> > >>_______________________________________________ > >>Ltru mailing list > >>Ltru@lists.ietf.org > >>https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 15:00:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16266; Wed, 6 Apr 2005 15:00:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJFtS-0001JS-Jg; Wed, 06 Apr 2005 15:08:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJFkx-0004X6-7Y; Wed, 06 Apr 2005 15:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJFkw-0004UX-6G for ltru@megatron.ietf.org; Wed, 06 Apr 2005 15:00:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16193 for ; Wed, 6 Apr 2005 15:00:00 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJFtL-0001II-7l for ltru@ietf.org; Wed, 06 Apr 2005 15:08:43 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 11:59:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Apr 2005 11:59:52 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEF7B5@irvmbxw01.quest.com> Thread-Topic: updated editor's copies... Thread-Index: AcU62szAKVSIS8yKQkqUa4y7jfiShg== From: "Addison Phillips" To: X-OriginalArrivalTime: 06 Apr 2005 18:59:52.0823 (UTC) FILETIME=[D0AD5870:01C53ADA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ltru] updated editor's copies... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0202955850==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 --===============0202955850== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXJlIG5vdyBhdmFpbGFibGUgb246DQoNCmh0dHA6Ly93d3cuaW50ZXItbG9jYWxlLmNvbS9JRC9k cmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMDEuaHRtbA0KaHR0cDovL3d3dy5pbnRlci1sb2NhbGUu Y29tL0lEL2RyYWZ0LWlldGYtbHRydS1yZWdpc3RyeS0wMS50eHQNCmh0dHA6Ly93d3cuaW50ZXIt bG9jYWxlLmNvbS9JRC9kcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMDEueG1sDQoNCk1vcmUgdGV4 dHVhbCB3b3JrIGlzIG5lY2Vzc2FyeSBiZWZvcmUgdGhlc2UgYXJlIHN1Ym1pdHRlZCwgYnV0IGNv bW1lbnRzIGFyZSBlc3BlY2lhbGx5IHdlbGNvbWUgYXQgdGhpcyBwb2ludC4gU2VjdGlvbnMgdGhh dCBoYXZlIGJlZW4gaGVhdmlseSBtb2RpZmllZCBpbmNsdWRlIDMuMSAocmVnaXN0cnkgZm9ybWF0 KSwgMy4zIChyZWdpc3RyYXRpb24gcHJvY2VzcyksIGFuZCBBcHBlbmRpeCBDIChyZWdpc3RyeSBj b252ZXJzaW9uKS4gT3RoZXIgY2hhbmdlcyBhcmUgbm90ZWQgaW4gdGhlIGNoYW5nZXMgc2VjdGlv bi4NCg0KQWRkaXNvbiAoZm9yIHRoZSBlZGl0b3JzKQ0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpH bG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3Qu Y29tDQoNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3Vw DQpodHRwOi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9u IGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQoNCg== --===============0202955850== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0202955850==-- From ltru-bounces@ietf.org Wed Apr 6 15:13:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18091; Wed, 6 Apr 2005 15:13:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJG6g-0001gP-Oy; Wed, 06 Apr 2005 15:22:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJFvd-0001ce-HY; Wed, 06 Apr 2005 15:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJFvc-0001cZ-78 for ltru@megatron.ietf.org; Wed, 06 Apr 2005 15:11:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17676 for ; Wed, 6 Apr 2005 15:11:02 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJG3z-0001bZ-Fo for ltru@ietf.org; Wed, 06 Apr 2005 15:19:45 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Wed, 06 Apr 2005 15:10:52 -0400 id 005900A8.4254343C.000057B9 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Addison Phillips'" , ltru@ietf.org Subject: RE: [Ltru] updated editor's copies... Date: Wed, 6 Apr 2005 15:10:34 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749C9AB@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AEEF7B5@irvmbxw01.quest.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit One quick comment: RFC 2234 (the ABNF spec) is being obsoleted. Please reference draft-crocker-abnf-rfc2234bis-00.txt instead of RFC 2234 and confirm that everything that was valid before is still valid. The IESG approved this document as a Draft Standard last week. -Scott- > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Wednesday, April 06, 2005 3:00 PM > To: ltru@ietf.org > Subject: [Ltru] updated editor's copies... > > > Are now available on: > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.html > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.txt > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.xml > > More textual work is necessary before these are submitted, > but comments are especially welcome at this point. Sections > that have been heavily modified include 3.1 (registry > format), 3.3 (registration process), and Appendix C (registry > conversion). Other changes are noted in the changes section. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 15:24:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19445; Wed, 6 Apr 2005 15:24:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJGGv-0001yN-Cd; Wed, 06 Apr 2005 15:33:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJG8J-0005bW-Md; Wed, 06 Apr 2005 15:24:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJG8H-0005Ux-Lu for ltru@megatron.ietf.org; Wed, 06 Apr 2005 15:24:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19420 for ; Wed, 6 Apr 2005 15:24:07 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJGGe-0001wz-1F for ltru@ietf.org; Wed, 06 Apr 2005 15:32:51 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 12:23:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] updated editor's copies... Date: Wed, 6 Apr 2005 12:23:49 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEF7D9@irvmbxw01.quest.com> Thread-Topic: [Ltru] updated editor's copies... Thread-Index: AcU63Fuspx09yY0bSjKbAAsk51zLeAAAbHrQ From: "Addison Phillips" To: "Scott Hollenbeck" , X-OriginalArrivalTime: 06 Apr 2005 19:23:50.0585 (UTC) FILETIME=[29A66A90:01C53ADE] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Randy informed me. I'm waiting for the updated xml2rfc to be final = before making that change. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Scott Hollenbeck [mailto:sah@428cobrajet.net] > Sent: mercredi 6 avril 2005 12:11 > To: Addison Phillips; ltru@ietf.org > Subject: RE: [Ltru] updated editor's copies... >=20 > One quick comment: RFC 2234 (the ABNF spec) is being obsoleted. = Please > reference draft-crocker-abnf-rfc2234bis-00.txt instead of RFC 2234 and > confirm that everything that was valid before is still valid. The = IESG > approved this document as a Draft Standard last week. >=20 > -Scott- >=20 > > -----Original Message----- > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > Sent: Wednesday, April 06, 2005 3:00 PM > > To: ltru@ietf.org > > Subject: [Ltru] updated editor's copies... > > > > > > Are now available on: > > > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.html > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.txt > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.xml > > > > More textual work is necessary before these are submitted, > > but comments are especially welcome at this point. Sections > > that have been heavily modified include 3.1 (registry > > format), 3.3 (registration process), and Appendix C (registry > > conversion). Other changes are noted in the changes section. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 16:07:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28601; Wed, 6 Apr 2005 16:07:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJGwO-00054d-S2; Wed, 06 Apr 2005 16:15:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJGna-000707-EE; Wed, 06 Apr 2005 16:06:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJGnX-0006xh-QE for ltru@megatron.ietf.org; Wed, 06 Apr 2005 16:06:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28484 for ; Wed, 6 Apr 2005 16:06:45 -0400 (EDT) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJGvw-00050y-HY for ltru@ietf.org; Wed, 06 Apr 2005 16:15:29 -0400 Received: from h-68-166-189-56.snvacaid.dynamic.covad.net ([68.166.189.56] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJGnO-0005h6-00 for ltru@ietf.org; Wed, 06 Apr 2005 13:06:39 -0700 Message-ID: <008c01c53ae4$52b56020$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0ADE79A3@irvmbxw01.quest.com> <005401c5399d$fc442420$030aa8c0@DEWELL> Subject: Re: [Ltru] Date of deprecation (was: Re: Registry in record-jarformat) Date: Wed, 6 Apr 2005 13:07:24 -0700 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: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Monday, April 04, 2005 10:11 PM > Subject: Re: [Ltru] Date of deprecation (was: Re: Registry in record-jarformat) ... > As for figuring out what has changed, with all the talk about record-jar > vs. XML, I'm surprised nobody has mentioned making incremental deltas > available -- say, in "diff" format. That would certainly solve the > problem of having to re-download a 600 KB file. Agreeing to do such a > thing would be the important point; the exact mechanism would be a > detail. ... Actually, I think you raised the question in http://www.ietf.org/mail-archive/web/ltru/current/msg00302.html If this stuff is published via http, then, as a technical contributor, I'd suggest that WebDAV (e.g. RFC 3253) might be worth considering as a means to accomplish this goal, if there is agreement that it should be a goal. Note that this mechanism doesn't depend on the choice of XML, plain text, record-jar, or whatever. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 16:50:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02993; Wed, 6 Apr 2005 16:50:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHcG-0006V1-6T; Wed, 06 Apr 2005 16:59:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHSl-0003dc-Vx; Wed, 06 Apr 2005 16:49:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJHSk-0003an-0I for ltru@megatron.ietf.org; Wed, 06 Apr 2005 16:49:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02911 for ; Wed, 6 Apr 2005 16:49:19 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJHb9-0006Sa-M2 for ltru@ietf.org; Wed, 06 Apr 2005 16:58:04 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 13:49:11 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 6 Apr 2005 13:49:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Date: Wed, 6 Apr 2005 13:49:08 -0700 Message-ID: Thread-Topic: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Thread-Index: AcU6OknC9ZTaHeHiTYWtYJcGmkbJ3AAAhbXEACrmJ+A= From: "Peter Constable" To: "ltru" X-OriginalArrivalTime: 06 Apr 2005 20:49:12.0995 (UTC) FILETIME=[16D82730:01C53AEA] X-Spam-Score: 0.6 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1808086012==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef This is a multi-part message in MIME format. --===============1808086012== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53AE9.F8F00B6A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C53AE9.F8F00B6A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would characterize the changes that resulted from the CD ballot comments for ISO 639-3 as being mainly editorial in nature. The biggest technical change was to include macrolanguages in the ISO 639-3 code table (in the CD, I had proposed that *only* individual language categories would be included in the 639-3 code tables). The other main technical changes had to do with adding more definitions for terminology, clarifying certain details related to how changes would be handled, and a very small number of changes in the draft code table. =20 I expect that the DIS ballot comments will result in fewer changes, though I cannot predict that with any certainty. IIRC, a CD does not get distributed as widely as a DIS, so there may be comments from countries that are seeing a draft for the first time during this ballot period. =20 =20 Peter Constable =20 ________________________________ From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of L.Gillam Sent: Tuesday, April 05, 2005 5:17 PM To: ltru Subject: RE: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling =20 =20 639-4 is going to be "a while" in process. N.B. 5 month DIS ballot for 639-3, possible FDIS stage then publication (final editorial phase with ISO central secretariat). Unless activity on -4 suddenly happens at the Berlin metadata event next week, which it might or it might not, I'm not aware of a current timescale for this document beyond ISO time limits (the clock is certainly ticking). =20 Perhaps Peter Constable can comment on whether existing comments received at CD ballot have resulted in any alteration of the essence of -3, comments on the codes themselves (not part of the published standard) aside. =20 ________________________________ From: ltru-bounces@lists.ietf.org on behalf of JFC (Jefsey) Morfin Sent: Wed 06/04/2005 00:48 To: Randy Presuhn; ltru Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling At 07:41 21/03/2005, Randy Presuhn wrote: >Hi - >(co-chair hat off) > > From: "John Cowan" > > To: "Randy Presuhn" > > Cc: > > Sent: Sunday, March 20, 2005 8:41 PM > > Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling >... > > From what I understand of the IETF process, this WG could go dormant > > until ISO 639-3 was released, and then wake up for a relatively brief > > period to incorporate the necessary few paragraphs in RFC 3066bis to > > create RFC 3066ter. >... > >I think it would be really nice if we could put in text now that would not >need revision later. I fully agree with that. In particular ISO 639-4, which should permits to make the BCP 047 consistent with ISO 639-3, ISO 639-6 and the IANA entries - and obviously ISO 3166-2. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C53AE9.F8F00B6A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and = Boontling

I would characterize the changes = that resulted from the CD ballot comments for ISO 639-3 as being mainly = editorial in nature. The biggest technical change was to include macrolanguages in = the ISO 639-3 code table (in the CD, I had proposed that *only* individual language categories would be included = in the 639-3 code tables). The other main technical changes had to do with = adding more definitions for terminology, clarifying certain details related to how = changes would be handled, and a very small number of changes in the draft code = table.

 

I expect that the DIS ballot = comments will result in fewer changes, though I cannot predict that with any = certainty. IIRC, a CD does not get distributed as widely as a DIS, so there may be = comments from countries that are seeing a draft for the first time during this ballot = period.

 

 

Peter Constable

 

From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On Behalf Of L.Gillam
Sent: Tuesday, April 05, = 2005 5:17 PM
To: ltru
Subject: RE: [Ltru] = [semi-OT] ISO 639-3, record-jars, and Boontling

 

 

639-4 is going to be "a while" in process. = N.B. 5 month DIS ballot for 639-3, possible FDIS stage then publication (final editorial phase with ISO central secretariat). Unless activity on -4 = suddenly happens at the Berlin metadata event next week, which it might or it might not, = I'm not aware of a current timescale for this document beyond ISO time = limits (the clock is certainly ticking).

 

Perhaps Peter Constable can comment on whether = existing comments received at CD ballot have resulted in any alteration of the = essence of -3, comments on the codes themselves (not part of the published = standard) aside.

 

From: ltru-bounces@lists.ietf.org on behalf of JFC (Jefsey) Morfin
Sent: Wed 06/04/2005 = 00:48
To: Randy Presuhn; = ltru
Subject: Re: [Ltru] = [semi-OT] ISO 639-3, record-jars, and Boontling

At 07:41 21/03/2005, Randy Presuhn wrote:
>Hi -
>(co-chair hat off)
> > From: "John Cowan" = <jcowan@reutershealth.com>
> > To: "Randy Presuhn" = <randy_presuhn@mindspring.com>
> > Cc: <ltru@ietf.org>
> > Sent: Sunday, March 20, 2005 8:41 PM
> > Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and = Boontling
>...
> > From what I understand of the IETF process, this WG could go = dormant
> > until ISO 639-3 was released, and then wake up for a = relatively brief
> > period to incorporate the necessary few paragraphs in RFC = 3066bis to
> > create RFC 3066ter.
>...
>
>I think it would be really nice if we could put in text now that = would not
>need revision later.

I fully agree with that. In particular ISO 639-4, which should permits = to
make the BCP 047 consistent with ISO 639-3, ISO 639-6 and the IANA = entries
- and obviously ISO 3166-2.
jfc


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

------_=_NextPart_001_01C53AE9.F8F00B6A-- --===============1808086012== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1808086012==-- From ltru-bounces@ietf.org Wed Apr 6 17:42:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07493; Wed, 6 Apr 2005 17:42:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJIQk-0007wp-PX; Wed, 06 Apr 2005 17:51:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIFV-0007Ts-TF; Wed, 06 Apr 2005 17:39:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIFU-0007TW-Pb for ltru@megatron.ietf.org; Wed, 06 Apr 2005 17:39:45 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07243 for ; Wed, 6 Apr 2005 17:39:41 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJIC5-00049E-EZ for ltru@lists.ietf.org; Wed, 06 Apr 2005 23:36:13 +0200 Received: from du-001-145.access.de.clara.net ([212.82.227.145]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Apr 2005 23:36:13 +0200 Received: from nobody by du-001-145.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Apr 2005 23:36:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 06 Apr 2005 23:35:52 +0200 Organization: Lines: 52 Message-ID: <42545638.29E1@xyzzy.claranet.de> References: <20050405200543.TRMV2124.mta7.adelphia.net@megatron.ietf.org> <009601c53a5e$a4e783e0$030aa8c0@DEWELL> 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: du-001-145.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Matching metrics X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > that's not right. '*' = '*' is a match [...] > Try your metrics again. column 1 is en-scouse column 2 is en-GB-scouse column 3 is en-Latn-GB-scouse column 4 is en-Latn-scouse Test 8-4-2-1 weights en-scouse 15 13 9 11 en-GB-scouse 13 15 11 9 en-Latn-GB-scouse 9 11 15 13 en-Latn-scouse 11 9 13 15 xx-Latn-GB-scouse 1 3 7 5 en-Latn-GB 8 10 14 12 en-Latn-US 8 8 12 12 en-Latn-US-scouse 9 9 13 13 en-Brai-GB-scouse 9 11 11 9 In column 2 (en-GB-scouse) en-Brai-GB-scouse beats en-GB-Latn and en-Latn-US-scouse. In column 3 (en-Latn-GB-scouse) en-GB-Latn beats en-Latn-US-scouse. Of course still a draw in column 1. Test 4-3-1-2 weights en-scouse 10 9 6 7 en-GB-scouse 9 10 7 6 en-Latn-GB-scouse 6 7 10 9 en-Latn-scouse 7 6 9 10 xx-Latn-GB-scouse 2 3 6 5 en-Latn-GB 4 5 8 7 en-Latn-US 4 4 7 7 en-Latn-US-scouse 6 6 9 9 en-Brai-GB-scouse 6 7 7 6 Here colums 3 and 4 are "sane", column 1 is of course a draw, and column 2 is minimally "better" than John's metrics, but it still prefers en-Brai-GB-scouse before en-Latn-US-scouse. Maybe 4-2-1-3 would do the trick for these examples, but then we need a new set of test cases, w(variant) > w(script) can't be a generally good idea. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 17:45:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07726; Wed, 6 Apr 2005 17:45:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJITa-00080Y-R1; Wed, 06 Apr 2005 17:54:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIF3-0007Jx-Nn; Wed, 06 Apr 2005 17:39:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIF2-0007Jr-DI for ltru@megatron.ietf.org; Wed, 06 Apr 2005 17:39:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07177 for ; Wed, 6 Apr 2005 17:39:11 -0400 (EDT) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJINQ-0007sT-99 for ltru@ietf.org; Wed, 06 Apr 2005 17:47:57 -0400 Received: from h-68-166-189-56.snvacaid.dynamic.covad.net ([68.166.189.56] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJIEw-0001kk-00 for ltru@ietf.org; Wed, 06 Apr 2005 14:39:10 -0700 Message-ID: <005201c53af1$3fbff040$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "ltru" References: <4A7C6FA2AB31194E80E13FE585F6A2121A5939@EVS-EC1-NODE1.surrey.ac.uk> Subject: Re: [Ltru] Re: Registry in record-jar format - smart matching? Date: Wed, 6 Apr 2005 14:40:27 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi - > From: "L.Gillam" > To: "ltru" > Sent: Wednesday, April 06, 2005 5:21 AM > Subject: [Ltru] Re: Registry in record-jar format - smart matching? > > Defaults + fallback = ? > > If "en" defaults to en-Latn, does en-Cyrl falls back to en and default to en-Latn. > Is it better to receive en-Latn rather than "nothing" in response to en-Cyrl? > What if more than one script is implicated by the 2 letter language code, > there is a default, but the fallback should produce all available? > > What do people think is the best result from this combination? ... (as contributor) I think questions like these demonstrate the need for multiple matching algorithms (or a very general, parameterised matching algorithm), which is what we are chartered to produce. The "best" result would depend on the application. For some applications, "fallback" is desirable. For others, it is not. I think they also show why the concept of "default script" (distinct from "script not specified") has received little support. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 18:24:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12109; Wed, 6 Apr 2005 18:24:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJJ5X-0000VL-G3; Wed, 06 Apr 2005 18:33:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIwJ-0001b8-BY; Wed, 06 Apr 2005 18:23:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJIwH-0001b3-Ju for ltru@megatron.ietf.org; Wed, 06 Apr 2005 18:23:57 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12067 for ; Wed, 6 Apr 2005 18:23:54 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJIsu-0001I6-Dz for ltru@lists.ietf.org; Thu, 07 Apr 2005 00:20:28 +0200 Received: from du-001-145.access.de.clara.net ([212.82.227.145]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 00:20:28 +0200 Received: from nobody by du-001-145.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 00:20:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 00:19:11 +0200 Organization: Lines: 16 Message-ID: <4254605F.6639@xyzzy.claranet.de> References: <20050401205735.MVSI2135.mta2.adelphia.net@megatron.ietf.org><00c401c53754$cdfe41e0$030aa8c0@DEWELL> <424F03EB.C30@xyzzy.claranet.de> <00fa01c53a54$d1675080$7f1afea9@oemcomputer> 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: du-001-145.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Couldn't we simply use Unicode character references (as > needed) in a record-jar format? That would be an ad-hoc format, an ABNF for the complete record-jar format with this idea is of course possible. Essentially we'd need ꯍ or 򫳞 - let's ignore � Anything else not starting with &#x is ASCII. But there are no Unicode points above 126 in the draft registry at the moment, so why do we discuss this now ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 18:59:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15067; Wed, 6 Apr 2005 18:59:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJJcw-0001G5-Nb; Wed, 06 Apr 2005 19:08:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJJT5-0004xQ-V1; Wed, 06 Apr 2005 18:57:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJJT2-0004xL-R2 for ltru@megatron.ietf.org; Wed, 06 Apr 2005 18:57:49 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14967 for ; Wed, 6 Apr 2005 18:57:44 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJJQD-0005WA-IM for ltru@lists.ietf.org; Thu, 07 Apr 2005 00:54:53 +0200 Received: from du-001-145.access.de.clara.net ([212.82.227.145]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 00:54:53 +0200 Received: from nobody by du-001-145.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 00:54:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 00:55:44 +0200 Organization: Lines: 12 Message-ID: <425468F0.59C9@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AEEF7D9@irvmbxw01.quest.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: du-001-145.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: updated editor's copies... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Addison Phillips wrote: > waiting for the updated xml2rfc to be final It works, ipr="full3978". There's also a new nice validator: No idea why Scott is so adamant about 2234bis, the bibxml is: Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 20:11:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24399; Wed, 6 Apr 2005 20:11:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJKkT-00031M-HA; Wed, 06 Apr 2005 20:19:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJKaT-0007if-4a; Wed, 06 Apr 2005 20:09:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJKaR-0007iX-Nr for ltru@megatron.ietf.org; Wed, 06 Apr 2005 20:09:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24301 for ; Wed, 6 Apr 2005 20:09:28 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJKit-0002yk-J7 for ltru@ietf.org; Wed, 06 Apr 2005 20:18:15 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3709M9O021717 for ; Wed, 6 Apr 2005 20:09:22 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 6 Apr 2005 20:09:30 -0400 Date: Wed, 6 Apr 2005 20:09:30 -0400 From: John Cowan To: ltru@ietf.org Message-ID: <20050407000930.GB407@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Subject: [Ltru] John Cowan's substantive comments on draft-ietf-ltru-registry-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Proposal registry-cowan-01: Alpha order in extension subtags CURRENT: Extension subtags MAY appear in any order in a language tag. It is not clear whether the order matters, but probably not, since tag canonicalization requires them to be sorted into case-insensitive alphabetic order by singleton. PROPOSED: Require that extension subtags already be sorted by singleton order in well-formed tags. RATIONALE: Extension subtags are novel, so there is no previous practice. Alphabeticalness of singletons is easy to check for. Meaningless variability is reduced. Proposal registry-cowan-02: Ban singleton "i" CURRENT: "i" MAY be used as a singleton in extension subtags. PROPOSED: "i" MUST NOT be used as a singleton. RATIONALE: The single-character subtag "i" is already used in grandfathered tags in a different sense. Although mechanical processes will not confuse the two senses (grandfathered "i" is always initial, singleton "i" is never initial), human beings may. Eliminating "i" does not significantly reduce the space of singletons available for registration. Proposal registry-cowan-03: Ban singletons "y" and "z" CURRENT: "y" and "z" MAY be used as singletons in extension subtags. PROPOSED: "y" and "z" MUST NOT be used as singletons. RATIONALE: If cowan-registry-01 is accepted, then accepting this proposal as well would allow a simplification of well-formedness checking in that the singleton "x" in a non-initial position need not be treated specially. Otherwise, the canonical order is "a", "b", ..., "w", "y", "z", "x". Eliminating "x" and "y" does not greatly reduce the space of singletons available for registration. Proposal registry-cowan-04: Specify case rules for canonical tags CURRENT: Canonicalizing a tag does not affect the case of the letters in it. PROPOSED: Canonicalizing a tag adjusts the case of the letters as follows: 1) The first letter of a script subtag is upper case; 2) Both letters of an alpha region subtag are upper case; 3) All other letters are lower case. RATIONALE: These are the de facto canonicalization rules for ISO 639, ISO 3166, and ISO 15924 codes. Since we have not had canonical tags before, there is no previous practice to contradict. The requirement for case-insensitive matching may be eliminated if all tags being matched are known to be canonical. Proposal registry-cowan-05: RFC 822 line wrapping in the registry CURRENT: Line wrapping is done with a trailing backslash. PROPOSED: Line wrapping is done by replacing a chosen sequence of horizontal whitespace with a line terminator followed by horizontal whitespace. (See RFC 2822 for specific text.) RATIONALE: Compatibility with RFC (2)822. Proposal registry-cowan-06: Remove leading zeros from character references CURRENT: Every character reference MUST contain at least four digits. PROPOSED: Character references MUST contain between one and six digits inclusive. ALTERNATIVE: Character references MUST contain between one and six digits inclusive, and MUST NOT have leading zeros. RATIONALE: The proposal is compatible with XML. The alternative proposal is also compatible with XML and allows only one possible encoding for each codepoint. Proposal registry-cowan-07: Remove private use tags from the registry and sample registry. CURRENT: The private use codes of the ISO standards are included in the registry. PROPOSED: Remove them from the registry. Also remove the concept of value ranges from Section 3.1, which is needed only for private use tags. RATIONALE: Private use tags are for private use, and private agreements about them do not scale. They ought not to be contained in a public registry. Those who wish to use them can look at the RFC. Proposal registry-cowan-08: Simplify the language tag registration form CURRENT: See Section 3.3. PROPOSED: The numbered items 1-3 and 4-8 should be replaced by the following new or existing fields in the registry: Requester, Requester-Email, Description, Meaning, Native-Name, Reference, Comments. RATIONALE: These registration forms will not be readily available to enquirers after the meaning of a specific language or variant tag. Making sure that all the information is included in the registry is therefore important, even at the cost of a larger registry. Registered languages will be very rare, and registered variants fairly rare, based on existing experience, so the cost will not be very great. -- usage: mt [-v] [--version] [-h] [ -f device ] command [ count ] A rabbi whose congregation doesn't want John Cowan to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan and a rabbi who lets them do it jcowan@reutershealth.com isn't a man. --Jewish saying http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 20:14:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24727; Wed, 6 Apr 2005 20:14:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJKna-000374-Dw; Wed, 06 Apr 2005 20:23:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJKeJ-0000RF-Rt; Wed, 06 Apr 2005 20:13:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJKeI-0000Qc-Tc for ltru@megatron.ietf.org; Wed, 06 Apr 2005 20:13:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24635 for ; Wed, 6 Apr 2005 20:13:27 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJKmk-000358-Rx for ltru@ietf.org; Wed, 06 Apr 2005 20:22:15 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j370DKEW021759; Wed, 6 Apr 2005 20:13:21 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 6 Apr 2005 20:13:26 -0400 Date: Wed, 6 Apr 2005 20:13:26 -0400 From: John Cowan To: Peter Constable Subject: Re: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Message-ID: <20050407001326.GC407@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Peter Constable scripsit: > I would characterize the changes that resulted from the CD ballot > comments for ISO 639-3 as being mainly editorial in nature. The biggest > technical change was to include macrolanguages in the ISO 639-3 code > table (in the CD, I had proposed that *only* individual language > categories would be included in the 639-3 code tables). Marked as such, or not marked separately from the pure individual languages? > very small number of changes in the draft code table. Can I reiterate my long-standing request for a list of codes changed between Ethnologue and the current ISO 639-3 draft? Thanks. -- He played King Lear as though John Cowan someone had played the ace. http://www.ccil.org/~cowan --Eugene Field http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 20:26:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25389; Wed, 6 Apr 2005 20:26:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJKyy-0003KV-CE; Wed, 06 Apr 2005 20:34:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJKlh-0004sa-Eq; Wed, 06 Apr 2005 20:21:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJKlf-0004sJ-Sf for ltru@megatron.ietf.org; Wed, 06 Apr 2005 20:21:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25114 for ; Wed, 6 Apr 2005 20:21:06 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJKu7-0003El-I8 for ltru@ietf.org; Wed, 06 Apr 2005 20:29:52 -0400 Received: from lns-p19-19-idf-82-65-139-159.adsl.proxad.net ([82.65.139.159] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJKlX-00042p-4b; Wed, 06 Apr 2005 17:21:00 -0700 Message-Id: <6.1.2.0.2.20050406235147.0d8cc550@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 07 Apr 2005 00:51:59 +0200 To: "Kurt D. Zeilenga" , "McDonald, Ira" From: "JFC (Jefsey) Morfin" Subject: Re: Compatibility with existing use (LDAP) (RE: [Ltru] Re: Registry in record-jar format) In-Reply-To: <6.2.1.2.0.20050406103739.05f45d60@mail.openldap.org> References: <6.2.1.2.0.20050406103739.05f45d60@mail.openldap.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Kurt, this suggestion is quite interesting. However as Addison documents it, the format does not make it as easy. It would be really interesting if you could respond his objections using real langtags examples. Also if you could document a little more how you see the global LDAP system how imagine. I suppose that the DNS (along with STD 013) would be a simpler management system. But Randy's webdav and your LTAP ideas should certainly be investigated. CSV could also be discussed. But there are not much difference between an LDAP meta system and a DNS based database system. All the more if coupled with an access engine. But I suppose LDAP could have a similar way to manage various formats. jfc At 20:12 06/04/2005, Kurt D. Zeilenga wrote: >Ira, and other LTRU'ers: > >I am thinking that the LTRU effort should be considered >more of a "replacement" effort than a "revision" effort, >at least in its present form. If you change the syntax >and semantics of RFC 3066 tags, you will break everything >that relies on them. It would be better, in my opinion, >to develop a new kind of tag which had a new syntax and >semantics. That new kind of tag could be used in new >things, possibly with support for existing RFC 3066 tags, >but not in old things (at least not without revision of >the old thing). > >I note that LDAP relies heavy on a number of aspects of >RFC 3066 tags, most importantly that there is a >well-defined syntactical tag hierarchy that doesn't >require the implementation to know the tag's validity >nor semantics to make use of tags in providing service. > >For instance, an LDAP server need not care if >"FOO-BAR" is a valid tag to allow a client to add >(a CN value tagged with "FOO-BAR"): > cn;lang-FOO-BAR: foo bar > >nor provide results a client requesting the return of all >subtags of "FOO", e.g., (cn;lang-FOO-=*). > >The only requirement (and I believe its a SHOULD, >not a MUST) is for the directory client adding values >to use the most specific tag known to it and for >requesting clients to use the least specific tag that >will return acceptable (or desirable) stored values. >It is noted that the client itself generally doesn't >valid tags either, as tag (and range) knowledge >generally comes from the user. > >So, not only does it concern me that these new tags >don't follow the same syntactical hierarchy (and may >require fuzzy matching), it concerns me that >the new specification mandates that implementations >be aware of what tags/subtags are registered (at >some time). That, to me, is like requiring SMTP >implementations to know what MIME types are registered. >Just as the SMTP is just a transport for MIME type >information, protocols like LDAP are (primarily) just >a transport for language information. (LDAP also >support lookups based on syntactical hierarchy, not >the semantical hierarchy.) > >I think it unwise for protocols to, themselves, >rely on value registries as this leads to fragile >interoperability. Registeries are better used to >ensure that values in specifications are unique. > >Apologies for commenting without fully digesting >the WG's draft in this area, or list archives, but >it seems more appropriate for me to comment sooner >than later. > >Kurt > > >At 10:27 AM 4/6/2005, McDonald, Ira wrote: > >Hi Kurt, > > > >Thanks very much - what LTRU is doing is rewriting > >RFC 3066 and _greatly_ extending it to formally > >address variants and scripts and other subtags. > > > >The nature and scope of the extensions breaks classic > >left-to-right language tag matching completely. The > >phrase being used on the list for the replacement > >is 'smart matching'. Just how smart a piece of s/w > >can be is the crux of the problem. And there is no > >concensus on the list about what algorithm should be > >used for 'smart matching'. > > > >Also, LTRU is developing an IANA registry of EVERY > >possible valid language tag. Which is a noble ideal, > >but... (the logic is that this frees language tags > >from dependency on possibly incompatible changes in > >ISO 639-x and ISO 3166-x, which have in fact occurred) > > > >Cheers, > >- Ira > > > > > >Ira McDonald (Musician / Software Architect) > >Blue Roof Music / High North Inc > >PO Box 221 Grand Marais, MI 49839 > >phone: +1-906-494-2434 > >email: imcdonald@sharplabs.com > > > >-----Original Message----- > >From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] > >Sent: Tuesday, April 05, 2005 3:40 PM > >To: McDonald, Ira > >Subject: RE: [Ltru] Re: Registry in record-jar format > > > > > >Ira, > > > >I'm not in a position to comment on this thread as I haven't > >caught up on what LTRU is or isn't trying to do to language > >tags and language ranges. I'm now subscribed to the LTRU > >list and after I read up (not soon), I'll comment (likely > >starting with a summary of how language tags and ranges > >are used in LDAP, and why). > > > >Kurt > > > >At 02:17 PM 4/4/2005, you wrote: > >>Hi, > >> > >>Relative to 'RFC 2616' matching rules below: > >> > >>It would be well to _explicitly_ address the impact of RFC3066bis > >>matching rules on the recently published standards-track RFC 3866 > >>"Language Tags and Ranges in the LDAP" (July 2004). If directory > >>entries and/or directory attributes are returned 'incorrectly' by > >>following RFC3066bis versus RFC3066, then this will have a visible > >>impact on many enterprise applications. > >> > >>And to answer the immediate criticism, no I don't know the precise > >>text to be added. Perhaps Kurt Zeilenga (editor of RFC 3866) can > >>comment? I copied him on this reply. > >> > >>Cheers, > >>- Ira > >> > >>Ira McDonald (Musician / Software Architect) > >>Blue Roof Music / High North Inc > >>PO Box 221 Grand Marais, MI 49839 > >>phone: +1-906-494-2434 > >>email: imcdonald@sharplabs.com > >> > >>-----Original Message----- > >>From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org]On > >>Behalf Of Addison Phillips > >>Sent: Monday, April 04, 2005 4:23 PM > >>To: John Cowan > >>Cc: ltru@ietf.org > >>Subject: RE: [Ltru] Re: Registry in record-jar format > >> > >> > >>See below. > >> > >>Addison P. Phillips > >>Globalization Architect, Quest Software > >>Chair, W3C Internationalization Core Working Group > >> > >>Internationalization is not a feature. > >>It is an architecture. > >> > >>> -----Original Message----- > >>> From: John Cowan [mailto:jcowan@reutershealth.com] > >>> Sent: lundi 4 avril 2005 13:03 > >>> To: Addison Phillips > >>> Cc: ltru@ietf.org > >>> Subject: Re: [Ltru] Re: Registry in record-jar format > >>> > >>> Addison Phillips scripsit: > >>> > >>> > Answer: Yes, it is a problem, since users might have to specify two > >>> > ranges or may get results inconsistent with their expectations. For > >>> > example, the range "zh-TW" does not match the tag "zh-Hant-TW" using > >>> > strict 3066 matching rules. > >>> > >>> Just a terminological note: I think these should be called HTTP or RFC > >>> 2616 > >>> matching rules, since RFC 2616 is the true and authoritative source for > >>> them. > >>[Addison Phillips] > >> > >>Agreed. > >> > >>> > >>> > i. "Extended Range Matching" is an extension of RFR in which "missing" > >>> > subtags are considered to be (or are expanded to be) wildcards. So > >>> > "de-1901" is expanded to "de-*-*-1901" and matches "de-Latn-1901" and > >>> > "de-AT-1901", not to mention "de-Latg-NA-1901". > >>> > >>> I think this should be mentioned in the matching I-D. > >>[Addison Phillips] > >> > >>I believe it is, although not this specific example. See > >>http://www.inter-locale.com/ID/draft-ietf-ltru-matching-00.html#extrange > >> > >>> > >>> > NB> Probably we need to extend this scheme to allow users to specify > >>> > that they do NOT want a specific field to be filled in. For example > >>> > "de-!-1901" would match only "de-1901" and not a tag such as > >>> > "de-Latn-1901". > >>> > >>> I'd like to see a use case for this (not involving boont). > >>[Addison Phillips] > >> > >>Find all content in need of retagging with a script in my Traditional > >>Chinese document using XPath: > >> > >>/*@[lang="zh-!-TW"] > >>> > >>> > ii. "Lookup" is the opposite of matching, in which subtags are removed > >>> > from the tag rather than the range (i.e. locale-style) to fill in all > >>> > slots in a dataset. This matches a very different content set. > >>> > >>> This too should be mentioned. > >>[Addison Phillips] > >> > >>Being added. Mark supplied text that I haven't had time to insert. > >>> > >>> > iii. "Scored Matching" was proposed by John Cowan and produces content > >>> > with a range of scores, allowing the content to be filtered by choosing > >>> > a "quality level" (my words) for the match. The user can set a > >threshold > >>> > for matching, presumably. > >>> > >>> As should this. > >>[Addison Phillips] > >> > >>Agreed. > >>> > >>> > The problem here is that matching cannot be as simple as it was under > >>> > RFC 3066 and still capture all possible cases. > >>> > >>> This is badly stated. Only matching of predefined tags in RFC 3066 > >>> captures > >>> all cases. > >>[Addison Phillips] > >> > >>It is badly stated. But I'm not sure your version captures the nuances > >>either. Perhaps: > >> > >>Only generative tags in RFC 3066 (i.e. those with only two possible > >subtags) > >>are guaranteed to work with RFC 2616 defined matching. > >>> > >>> -- > >>> Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. > >>> Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) > >>> Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, > >>> hoopsa! > >>> -- Joyce, Ulysses, "Oxen of the Sun" jcowan@reutershealth.com > >> > >> > >>_______________________________________________ > >>Ltru mailing list > >>Ltru@lists.ietf.org > >>https://www1.ietf.org/mailman/listinfo/ltru > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 20:42:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26286; Wed, 6 Apr 2005 20:42:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJLEk-0003cC-Bm; Wed, 06 Apr 2005 20:51:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJL5E-0004dk-UJ; Wed, 06 Apr 2005 20:41:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJL5C-0004bA-Ul for ltru@megatron.ietf.org; Wed, 06 Apr 2005 20:41:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26237 for ; Wed, 6 Apr 2005 20:41:17 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJLDe-0003bM-94 for ltru@ietf.org; Wed, 06 Apr 2005 20:50:03 -0400 Received: from lns-p19-19-idf-82-65-139-159.adsl.proxad.net ([82.65.139.159] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJL5A-0000TV-I5 for ltru@ietf.org; Wed, 06 Apr 2005 17:41:17 -0700 Message-Id: <6.1.2.0.2.20050407024039.03522820@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 07 Apr 2005 02:41:04 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Date of deprecation (was: Re: Registry in record-jarformat) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 On 22:07 06/04/2005, Randy Presuhn said: >Hi - > > > From: "Doug Ewell" > > To: "LTRU Working Group" > > Sent: Monday, April 04, 2005 10:11 PM > > Subject: Re: [Ltru] Date of deprecation (was: Re: Registry in > record-jarformat) >... > > As for figuring out what has changed, with all the talk about record-jar > > vs. XML, I'm surprised nobody has mentioned making incremental deltas > > available -- say, in "diff" format. That would certainly solve the > > problem of having to re-download a 600 KB file. Agreeing to do such a > > thing would be the important point; the exact mechanism would be a > > detail. >... > >Actually, I think you raised the question in >http://www.ietf.org/mail-archive/web/ltru/current/msg00302.html Glad to see that we approach a consensus now on this ! This is what I explain for a long. My approach is based on a DNS based database. (http://langtags.org) Obviously an LDAP proposition can also be of interest. What is of interest is: - flexbility of management by the concerned referents (meta directory) - immediate availability to an XML parser - they know what an URL is. With minium incremental data. My approach is a priority to the tag, next to version. In webdav you give a priority to version. Obviously my approach is name dependent to support independence from the subtag variations. But I feel the number of variations to document is quite low. >If this stuff is published via http, then, as a technical contributor, I'd >suggest that WebDAV (e.g. RFC 3253) might be worth considering as >a means to accomplish this goal, if there is agreement that it should be >a goal. Note that this mechanism doesn't depend on the choice of XML, >plain text, record-jar, or whatever. > >Randy > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 23:49:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09562; Wed, 6 Apr 2005 23:49:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJO9X-0007NP-MY; Wed, 06 Apr 2005 23:57:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJNsu-0008LB-3V; Wed, 06 Apr 2005 23:40:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJNss-0008L6-PS for ltru@megatron.ietf.org; Wed, 06 Apr 2005 23:40:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09199 for ; Wed, 6 Apr 2005 23:40:43 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJO1L-0007Ea-Hm for ltru@ietf.org; Wed, 06 Apr 2005 23:49:32 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 20:40:36 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 6 Apr 2005 20:40:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [semi-OT] ISO 639-3, record-jars, and Boontling Date: Wed, 6 Apr 2005 20:40:34 -0700 Message-ID: Thread-Topic: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Thread-Index: AcU7Bn7F7icPIRVJR2OLJeoOo/yVjgAHH3Dw From: "Peter Constable" To: X-OriginalArrivalTime: 07 Apr 2005 03:40:37.0436 (UTC) FILETIME=[8FEAEFC0:01C53B23] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable > From: John Cowan [mailto:jcowan@reutershealth.com] > > The biggest > > technical change was to include macrolanguages in the ISO 639-3 code > > table (in the CD, I had proposed that *only* individual language > > categories would be included in the 639-3 code tables). >=20 > Marked as such, or not marked separately from the pure individual > languages? In the CD, macrolanguage entries were not included, but are to be included as of the DIS. The code tables I included in the draft (the current intention is that tables will *not* be included in the final publication) indicate the scope for each entry, and the designated RA intends to indicate this as well in the Web-published code tables. > Can I reiterate my long-standing request for a list of codes changed > between Ethnologue and the current ISO 639-3 draft? Thanks. Um... [blush] Ok, I'll look into that right now. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 6 23:55:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09949; Wed, 6 Apr 2005 23:55:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJOFJ-0007e5-KW; Thu, 07 Apr 2005 00:03:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJO2J-0000HH-B7; Wed, 06 Apr 2005 23:50:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJO2H-0000HB-7Q for ltru@megatron.ietf.org; Wed, 06 Apr 2005 23:50:29 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09603 for ; Wed, 6 Apr 2005 23:50:25 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJNzp-000494-Ks for ltru@lists.ietf.org; Thu, 07 Apr 2005 05:47:57 +0200 Received: from du-001-145.access.de.clara.net ([212.82.227.145]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 05:47:57 +0200 Received: from nobody by du-001-145.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 05:47:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 05:45:40 +0200 Organization: Lines: 72 Message-ID: <4254ACE4.2994@xyzzy.claranet.de> References: <20050407000930.GB407@skunk.reutershealth.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: du-001-145.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: John Cowan's substantive comments on draft-ietf-ltru-registry-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit John Cowan wrote: > registry-cowan-01: Alpha order in extension subtags [...] > Meaningless variability is reduced. Sounds like a good idea. > registry-cowan-02: Ban singleton "i" [,,,] > Eliminating "i" does not significantly reduce the space of > singletons available for registration. True, besides two out of ijl are enough, let's reserve i for grandfathered iana tags. > registry-cowan-03: Ban singletons "y" and "z" [...]. > Eliminating "x" and "y" does not greatly reduce the space > of singletons available for registration. Why not just add "y" and "z" to the priate-use singletons ? > registry-cowan-04: Specify case rules for canonical tags NAK, no case-sensitive tags. It's okay if the registry adopts the style of its sources, and if 3066bis documents this, but otherwise tags are case-insensitive. Come on, it's only ASCII, no stringprep headaches. > registry-cowan-05: RFC 822 line wrapping in the registry Yes, record-jar as "documented by Google". RfC 2822 has FWS: | FWS = ([*WSP CRLF] 1*WSP) ; Folding white space We don't want obs-FWS, that's a variant of 2234bis LWSP, if I got it right, it could result in blank lines (trailing blanks). > registry-cowan-06: Remove leading zeros from character > references Apparently XML does this, and charmod says "one form" + "hex.", sigh. Please don't try this in (X)HTML, but here it's okay. > registry-cowan-07: Remove private use tags from the registry > and sample registry. [...] > remove the concept of value ranges from Section 3.1, which is > is needed only for private use tags. How about listing the first and last tags of private ranges ? > Those who wish to use them can look at the RFC. If I see something I don't know it could be "new". If I see a private tag it's "bad" from my POV, otherwise I would know it. That's a (small) difference. > Requester, Requester-Email, Description, Meaning, > Native-Name, Reference, Comments. Okay, but I'd prefer to have a URL with the (verbose) form, or maybe individual files for each tag with the details, and a compact registry incl. URLs for these files. Now we would need a "Content-Base", some more rounds and we reinvent MIME or XML or both. > even at the cost of a larger registry. IBTD, huge documents are evil. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 00:12:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11256; Thu, 7 Apr 2005 00:12:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJOWB-0007zN-7j; Thu, 07 Apr 2005 00:21:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOMo-0001E8-Hn; Thu, 07 Apr 2005 00:11:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOMm-0001E3-LN for ltru@megatron.ietf.org; Thu, 07 Apr 2005 00:11:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11096 for ; Thu, 7 Apr 2005 00:11:35 -0400 (EDT) Received: from postie2.hosting365.ie ([82.195.128.120]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJOVD-0007yR-JL for ltru@ietf.org; Thu, 07 Apr 2005 00:20:24 -0400 Received: from Lugh (unknown [83.70.34.168]) by postie2.hosting365.ie (Postfix) with ESMTP id ED0F32976281F for ; Thu, 7 Apr 2005 05:11:23 +0100 (IST) From: "Jon Hanna" To: Date: Thu, 7 Apr 2005 05:11: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.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU7JZiajxuyo34jTbihIKA44DgPBQAAgMww In-Reply-To: <4254ACE4.2994@xyzzy.claranet.de> Message-Id: <20050407041123.ED0F32976281F@postie2.hosting365.ie> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Ltru] Case-sensitive canonicalisation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit > NAK, no case-sensitive tags. It's okay if the registry adopts > the style of its sources, and if 3066bis documents this, but > otherwise tags are case-insensitive. Come on, it's only ASCII, > no stringprep headaches. Canonicalisation rules can sometimes be usefully mandated in narrow cases even if they are purely an informal (but documented) style in the source standard. Regards, Jon Hanna Work: Play: Chat: _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 00:49:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18918; Thu, 7 Apr 2005 00:49:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJP6L-0001Bu-0H; Thu, 07 Apr 2005 00:58:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOt4-0000mk-CX; Thu, 07 Apr 2005 00:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJOsz-0000lX-IC for ltru@megatron.ietf.org; Thu, 07 Apr 2005 00:44:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18485 for ; Thu, 7 Apr 2005 00:44:53 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJOp4-0000XT-DJ for ltru@ietf.org; Thu, 07 Apr 2005 00:40:55 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 21:31:58 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 6 Apr 2005 21:31:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [semi-OT] ISO 639-3, record-jars, and Boontling Date: Wed, 6 Apr 2005 21:31:56 -0700 Message-ID: Thread-Topic: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Thread-Index: AcU7Bn7F7icPIRVJR2OLJeoOo/yVjgAIwukg From: "Peter Constable" To: X-OriginalArrivalTime: 07 Apr 2005 04:31:59.0664 (UTC) FILETIME=[BD119B00:01C53B2A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable > From: John Cowan [mailto:jcowan@reutershealth.com] > Can I reiterate my long-standing request for a list of codes changed > between Ethnologue and the current ISO 639-3 draft? Thanks. One reason I put this off is that I was concerned it would be a non-trivial operation for me due to changes in the Ethnologue between the 14th and 15th edns (the latter was the starting point for 639-3). The good news for you is that it turned out to be a trivial process, so I can provide this right away; the bad news for you is that this is because the info I have reflects post-14th edn values, meaning that the mapping info I can provide doesn't include everything in the 14th edn of Ethnologue, which I'm guessing is what you were interested in.=20 Anyway, I'll send you what I have (off-list, since I haven't seen indication that this is of general interest). Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 00:59:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19797; Thu, 7 Apr 2005 00:59:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJPG1-0001d1-KK; Thu, 07 Apr 2005 01:08:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJP6u-0002fl-5Z; Thu, 07 Apr 2005 00:59:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJP6r-0002fY-V1 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 00:59:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19722 for ; Thu, 7 Apr 2005 00:59:14 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJPFL-0001bn-H8 for ltru@ietf.org; Thu, 07 Apr 2005 01:08:04 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j374x7sN023054; Thu, 7 Apr 2005 00:59:07 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 00:59:15 -0400 Date: Thu, 7 Apr 2005 00:59:15 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: John Cowan's substantive comments on draft-ietf-ltru-registry-01 Message-ID: <20050407045915.GD1795@skunk.reutershealth.com> References: <20050407000930.GB407@skunk.reutershealth.com> <4254ACE4.2994@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4254ACE4.2994@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Frank Ellermann scripsit: > Why not just add "y" and "z" to the priate-use singletons ? One private-use singleton is plenty. > NAK, no case-sensitive tags. It's okay if the registry adopts > the style of its sources, and if 3066bis documents this, but > otherwise tags are case-insensitive. Come on, it's only ASCII, > no stringprep headaches. I am *not* proposing case-sensitive tags, simply a uniform casing style for *canonical* tags. (I'd prefer all lower case myself, but that doesn't seem to be customary.) > > registry-cowan-06: Remove leading zeros from character > > references > > Apparently XML does this, and charmod says "one form" + "hex.", > sigh. Please don't try this in (X)HTML, but here it's okay. In fact both HTML and XML now accept hex character references with or without leading zeros. The only difference between current and earlier HTML is that older HTML systems accepted only decimal character references with or without leading zeros. > How about listing the first and last tags of private ranges ? That's in effect what is done now. > Okay, but I'd prefer to have a URL with the (verbose) form, or > maybe individual files for each tag with the details, and a > compact registry incl. URLs for these files. Now we would need > a "Content-Base", some more rounds and we reinvent MIME or XML > or both. IANA will already publish the verbose forms, as it does today. > > even at the cost of a larger registry. > > IBTD, huge documents are evil. Bye, Frank "Larger" doesn't necessarily mean "huge". -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan I am he that buries his friends alive and drowns them and draws them alive again from the water. I came from the end of a bag, but no bag went over me. I am the friend of bears and the guest of eagles. I am Ringwinner and Luckwearer; and I am Barrel-rider. --Bilbo to Smaug _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 01:38:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22484; Thu, 7 Apr 2005 01:38:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJPrC-0002kw-J6; Thu, 07 Apr 2005 01:47:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJPhv-0005Io-E9; Thu, 07 Apr 2005 01:37:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJPhu-0005Ig-9B for ltru@megatron.ietf.org; Thu, 07 Apr 2005 01:37:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22369 for ; Thu, 7 Apr 2005 01:37:32 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJPqO-0002k9-0l for ltru@ietf.org; Thu, 07 Apr 2005 01:46:21 -0400 Received: from h-68-166-188-228.snvacaid.dynamic.covad.net ([68.166.188.228] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJPhm-0005Dv-00 for ltru@ietf.org; Wed, 06 Apr 2005 22:37:26 -0700 Message-ID: <000701c53b34$106acca0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Wed, 6 Apr 2005 22:38:44 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ltru] Prepare for a burst of issue-tracker messages X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi - (Co-chair hat ON) Due to the large number of issues that have come up on this list, and due to the terrible job we've all been doing of starting new subject lines when we raise new issues, we'll try using an issue tracker. I've gone through the archives to identify issues. I have not yet included Jefsey's April 4 comments and John Cowan's comments of April 6. Fear not, I'll get to them. In the meantime, there will be a burst of email messages from the issue tracker. If you would kindly post your comments on each issue AND ONLY THAT ISSUE in the corresponding thread, it will make life easier for all concerned. Please post one message per issue for any issues I've overlooked, ideally including a pointer to the message in which the issue was originally raised, and, if possible, a proposed course of action to rectify that issue. I believe there is already consensus on many of these issues, so we should be able to close those in the next few days. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 01:43:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22780; Thu, 7 Apr 2005 01:43:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJPvq-0002u6-Ko; Thu, 07 Apr 2005 01:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJPlY-0006GY-CY; Thu, 07 Apr 2005 01:41:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJPDR-0005bX-1W for ltru@megatron.ietf.org; Thu, 07 Apr 2005 01:06:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20360 for ; Thu, 7 Apr 2005 01:06:03 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJPLv-0001py-JC for ltru@ietf.org; Thu, 07 Apr 2005 01:14:51 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJPDP-000K9p-T0 for ltru@ietf.org; Thu, 07 Apr 2005 05:06:03 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #892 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 05:06:03 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Thu, 07 Apr 2005 01:41:18 -0400 Subject: [Ltru] [psg.com #892] instructions for IANA if registry becomes "too large" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Thu Apr 07 05:06:03 2005: Request 892 was acted upon. Transaction: Ticket created by randy_presuhn@mindspring.com Queue: ltru-registry Subject: instructions for IANA if registry becomes "too large" Owner: addison.phillips@quest.com Requestors: randy_presuhn@mindspring.com Status: new Ticket Issue raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00275.html _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 02:28:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16747; Thu, 7 Apr 2005 02:28:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJQdM-0004Ka-VL; Thu, 07 Apr 2005 02:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQUP-0002j7-Fr; Thu, 07 Apr 2005 02:27:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQUM-0002gy-2U for ltru@megatron.ietf.org; Thu, 07 Apr 2005 02:27:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16688 for ; Thu, 7 Apr 2005 02:27:36 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJQcm-0004Gv-Sg for ltru@ietf.org; Thu, 07 Apr 2005 02:36:25 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j376RCTj006793 for ; Thu, 7 Apr 2005 02:27:12 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j376RCZW251376 for ; Thu, 7 Apr 2005 02:27:12 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j376R2B3012678 for ; Thu, 7 Apr 2005 02:27:02 -0400 Received: from markdavis (sig-9-48-115-190.mts.ibm.com [9.48.115.190]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j376Qw6u012492; Thu, 7 Apr 2005 02:27:01 -0400 Message-ID: <006e01c53b3a$cdeadb70$be733009@sanjose.ibm.com> From: "Mark Davis" To: "John Cowan" , References: <20050407000930.GB407@skunk.reutershealth.com> Subject: Re: [Ltru] John Cowan's substantive comments ondraft-ietf-ltru-registry-01 Date: Wed, 6 Apr 2005 23:26:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e1.ny.us.ibm.com id j376RCTj006793 X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable My comments on John's =E2=80=8EMark ----- Original Message -----=20 From: "John Cowan" To: Sent: Wednesday, April 06, 2005 17:09 Subject: [Ltru] John Cowan's substantive comments ondraft-ietf-ltru-registry-01 > Proposal registry-cowan-01: Alpha order in extension subtags > > CURRENT: Extension subtags MAY appear in any order in a language tag. > It is not clear whether the order matters, but probably not, since > tag canonicalization requires them to be sorted into case-insensitive > alphabetic order by singleton. > > PROPOSED: Require that extension subtags already be sorted by singleto= n > order in well-formed tags. > > RATIONALE: Extension subtags are novel, so there is no previous > practice. Alphabeticalness of singletons is easy to check for. > Meaningless variability is reduced. Ok by me. > > > Proposal registry-cowan-02: Ban singleton "i" > > CURRENT: "i" MAY be used as a singleton in extension subtags. > > PROPOSED: "i" MUST NOT be used as a singleton. > > RATIONALE: The single-character subtag "i" is already used in > grandfathered tags in a different sense. Although mechanical processes > will not confuse the two senses (grandfathered "i" is always initial, > singleton "i" is never initial), human beings may. Eliminating "i" > does not significantly reduce the space of singletons available for > registration. No. This is no reason to reduce the extension space. > > > Proposal registry-cowan-03: Ban singletons "y" and "z" > > CURRENT: "y" and "z" MAY be used as singletons in extension subtags. > > PROPOSED: "y" and "z" MUST NOT be used as singletons. > > RATIONALE: If cowan-registry-01 is accepted, then accepting this propos= al > as well would allow a simplification of well-formedness checking in tha= t > the singleton "x" in a non-initial position need not be treated special= ly. > Otherwise, the canonical order is "a", "b", ..., "w", "y", "z", "x". > Eliminating "x" and "y" does not greatly reduce the space of singletons > available for registration. No. This is no reason to reduce the extension space. And the extra effort= to sort x at the end, given the other work in canonicalizing, is in the nois= e. > > > Proposal registry-cowan-04: Specify case rules for canonical tags > > CURRENT: Canonicalizing a tag does not affect the case of the letters > in it. > > PROPOSED: Canonicalizing a tag adjusts the case of the letters as follo= ws: > > 1) The first letter of a script subtag is upper case; 2) Both > letters of an alpha region subtag are upper case; 3) All other > letters are lower case. > > RATIONALE: These are the de facto canonicalization rules for ISO 639, > ISO 3166, and ISO 15924 codes. Since we have not had canonical tags > before, there is no previous practice to contradict. The requirement > for case-insensitive matching may be eliminated if all tags being match= ed > are known to be canonical. Ok by me. > > > Proposal registry-cowan-05: RFC 822 line wrapping in the registry > > CURRENT: Line wrapping is done with a trailing backslash. > > PROPOSED: Line wrapping is done by replacing a chosen sequence of > horizontal whitespace with a line terminator followed by horizontal > whitespace. (See RFC 2822 for specific text.) > > RATIONALE: Compatibility with RFC (2)822. Don't care either way. > > > Proposal registry-cowan-06: Remove leading zeros from character referen= ces > > CURRENT: Every character reference MUST contain at least four digits. > > PROPOSED: Character references MUST contain between one and six digits > inclusive. > > ALTERNATIVE: Character references MUST contain between one and six digi= ts > inclusive, and MUST NOT have leading zeros. > > RATIONALE: The proposal is compatible with XML. The alternative propo= sal > is also compatible with XML and allows only one possible encoding for > each codepoint. Don't care either way. > > > Proposal registry-cowan-07: Remove private use tags from the registry > and sample registry. > > CURRENT: The private use codes of the ISO standards are included in > the registry. > > PROPOSED: Remove them from the registry. Also remove the concept of > value ranges from Section 3.1, which is needed only for private use tag= s. > > RATIONALE: Private use tags are for private use, and private agreement= s > about them do not scale. They ought not to be contained in a public > registry. Those who wish to use them can look at the RFC. Absolutely not. There is a place for private use codes, and they are easy= to check for. (Moreover, I believe this breaks compatibility with 1766, although that is not the chief reason for retaining them.) > > > Proposal registry-cowan-08: Simplify the language tag registration form > > CURRENT: See Section 3.3. > > PROPOSED: The numbered items 1-3 and 4-8 should be replaced by > the following new or existing fields in the registry: Requester, > Requester-Email, Description, Meaning, Native-Name, Reference, Comments. > > RATIONALE: These registration forms will not be readily available to > enquirers after the meaning of a specific language or variant tag. > Making sure that all the information is included in the registry is > therefore important, even at the cost of a larger registry. Registered > languages will be very rare, and registered variants fairly rare, based > on existing experience, so the cost will not be very great. Don't care much, but having the registration form be a superset of the registration entry is a good feature. > > -- > usage: mt [-v] [--version] [-h] [ -f device ] command [ count ] > A rabbi whose congregation doesn't want John Cowan > to drive him out of town isn't a rabbi, http://www.ccil.org/~co= wan > and a rabbi who lets them do it jcowan@reutershealth.co= m > isn't a man. --Jewish saying http://www.reutershealth.com > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 02:39:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17952; Thu, 7 Apr 2005 02:39:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJQoJ-0004hv-BB; Thu, 07 Apr 2005 02:48:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQfP-0008QA-Io; Thu, 07 Apr 2005 02:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJQfM-0008Q1-3Y for ltru@megatron.ietf.org; Thu, 07 Apr 2005 02:39:00 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17893 for ; Thu, 7 Apr 2005 02:38:57 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJQcZ-0000jz-FU for ltru@lists.ietf.org; Thu, 07 Apr 2005 08:36:07 +0200 Received: from du-001-145.access.de.clara.net ([212.82.227.145]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 08:36:07 +0200 Received: from nobody by du-001-145.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 08:36:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 08:37:55 +0200 Organization: Lines: 12 Message-ID: <4254D543.7373@xyzzy.claranet.de> References: <4254ACE4.2994@xyzzy.claranet.de> <20050407041123.ED0F32976281F@postie2.hosting365.ie> 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: du-001-145.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Case-sensitive canonicalisation X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Jon Hanna wrote: > Canonicalisation rules can sometimes be usefully mandated in > narrow cases even if they are purely an informal (but > documented) style in the source standard. Okay, probably I got John's idea wrong. As long as it doesn't affect matching, parsers, or Addisons's ABNF it's acceptable - Doug and later the tag reviewer can live with "canonical tags". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 03:10:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20959; Thu, 7 Apr 2005 03:10:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJRIG-0005my-Fo; Thu, 07 Apr 2005 03:19:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJR8a-0008JS-Pf; Thu, 07 Apr 2005 03:09:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJR8Z-0008J2-F8 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 03:09:11 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20914 for ; Thu, 7 Apr 2005 03:09:08 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050407070838.NSMQ7277.mta10.adelphia.net@DEWELL> for ; Thu, 7 Apr 2005 03:08:38 -0400 Message-ID: <002c01c53b40$9b68a780$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050406191319.GBPY2135.mta2.adelphia.net@megatron.ietf.org> Date: Thu, 7 Apr 2005 00:08:30 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Kurt D. Zeilenga wrote: > If you change the syntax and semantics of RFC 3066 tags, > you will break everything that relies on them. Fortunately, we're not doing that. Ira McDonald had written: > Also, LTRU is developing an IANA registry of EVERY > possible valid language tag. We're not doing that either. Important distinction: we are developing a registry of every possible valid *subtag*, not tag. The former adds up to just under a thousand items; the latter (including all the ridiculous ones) would be about 15 million. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 03:22:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21791; Thu, 7 Apr 2005 03:22:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJRTV-00068i-66; Thu, 07 Apr 2005 03:30:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRFR-0001qj-9S; Thu, 07 Apr 2005 03:16:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRFO-0001qV-7y for ltru@megatron.ietf.org; Thu, 07 Apr 2005 03:16:14 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21565 for ; Thu, 7 Apr 2005 03:16:12 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050407071542.TYFX2192.mta9.adelphia.net@DEWELL> for ; Thu, 7 Apr 2005 03:15:42 -0400 Message-ID: <003301c53b41$9a706f60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050406230055.RFBE2132.mta5.adelphia.net@megatron.ietf.org> Date: Thu, 7 Apr 2005 00:15:38 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Matching metrics X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > In column 2 (en-GB-scouse) en-Brai-GB-scouse beats > en-GB-Latn and en-Latn-US-scouse. Well, it should, shouldn't it? John's algorithm will work fine for some cases. Yours, with weights of 4-3-1-2 or 4-2-1-3 or whatever, might work better in some cases and not as well in others. There is no one solution, because sometimes script will be more important than region and variant, and sometimes one of the other two will be the most important. The charter acknowledges this: "it is not expected that any single matching algorithm will fit all needs." -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 03:24:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22047; Thu, 7 Apr 2005 03:24:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJRWE-0006G3-6y; Thu, 07 Apr 2005 03:33:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRMw-0003KY-8m; Thu, 07 Apr 2005 03:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRMu-0003KT-Q4 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 03:24:01 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21946 for ; Thu, 7 Apr 2005 03:23:58 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050407072329.OVNR5402.mta11.adelphia.net@DEWELL> for ; Thu, 7 Apr 2005 03:23:29 -0400 Message-ID: <003601c53b42$b016ed20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050406230055.RFBE2132.mta5.adelphia.net@megatron.ietf.org> Date: Thu, 7 Apr 2005 00:23:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA21946 Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Frank Ellermann wrote: > But there are no Unicode points above 126 in the draft > registry at the moment, so why do we discuss this now ? Actually, if you look again at http://users.adelphia.net/~dewell/lstreg.txt you will see three "/u" sequences that represent characters above the ASCII range. These are the names of regions: =C3=85land Islands, C=C3=B4te d'Ivoire, and R=C3=A9= union. (There are about to be a few more, as I add back the accented characters for script and language names that were previously converted to ASCII, as required by previous drafts.) We're discussing a lot of issues that aren't necessarily problems "at the moment." -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 03:27:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22496; Thu, 7 Apr 2005 03:27:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJRYg-0006Jd-Ru; Thu, 07 Apr 2005 03:36:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRPG-0004FC-0P; Thu, 07 Apr 2005 03:26:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJRPD-0004Ck-J1 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 03:26:23 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22306 for ; Thu, 7 Apr 2005 03:26:21 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJRMD-0005wd-2q for ltru@lists.ietf.org; Thu, 07 Apr 2005 09:23:17 +0200 Received: from du-001-145.access.de.clara.net ([212.82.227.145]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 09:23:17 +0200 Received: from nobody by du-001-145.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 09:23:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 09:23:58 +0200 Organization: Lines: 30 Message-ID: <4254E00E.2E4C@xyzzy.claranet.de> References: <20050407000930.GB407@skunk.reutershealth.com> <4254ACE4.2994@xyzzy.claranet.de> <20050407045915.GD1795@skunk.reutershealth.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: du-001-145.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] cowan-03 / cowan-06 (was: John Cowan's substantive comments on draft-ietf-ltru-registry-01) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit John Cowan wrote: >> Why not just add "y" and "z" to the priate-use singletons ? > One private-use singleton is plenty. Probably, but completely excluding "y" and "z" is strange. How about reserving "y" and "z" like "i" for alternate schemes at the begin of a tag, e.g. for Debbie's ISO 639-4 alpha-4 codes ? > In fact both HTML and XML now accept hex character references > with or without leading zeros. In theory, in practice 2 of my 4 browsers hate hex. references. I really tried that the W3C mentions this in "charmod". But here we could use your notation for &#A0; up to 􏿿 hcr = "&#x" ( h6 / h5 / h4 / h3 / h2 ) ";" h6 = "10" hex hex hex hex h5 = h1 hex hex hex hex h4 = h1 hex hex hex h3 = h1 hex hex h2 = ha hex ha = "A" / "B" / "C" / "D" / "E" / "F" h1 = %x31-39 / ha hex = %x30-39 / ha If somebody really insists on … it's time to close LTRU. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 04:13:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25899; Thu, 7 Apr 2005 04:13:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJSHj-00083x-VF; Thu, 07 Apr 2005 04:22:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJS43-0007mT-3m; Thu, 07 Apr 2005 04:08:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJS41-0007m9-FI for ltru@megatron.ietf.org; Thu, 07 Apr 2005 04:08:33 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25331 for ; Thu, 7 Apr 2005 04:08:30 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJS1B-0002an-G1 for ltru@lists.ietf.org; Thu, 07 Apr 2005 10:05:37 +0200 Received: from du-001-145.access.de.clara.net ([212.82.227.145]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 10:05:37 +0200 Received: from nobody by du-001-145.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 10:05:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 10:06:03 +0200 Organization: Lines: 20 Message-ID: <4254E9EB.7EF0@xyzzy.claranet.de> References: <20050406230055.RFBE2132.mta5.adelphia.net@megatron.ietf.org> <003301c53b41$9a706f60$030aa8c0@DEWELL> 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: du-001-145.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Matching metrics X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Doug Ewell wrote: >> In column 2 (en-GB-scouse) en-Brai-GB-scouse beats >> en-GB-Latn and en-Latn-US-scouse. > Well, it should, shouldn't it? No, I wanted en-Latn-US-scouse, but it doesn't work without a "default script" concept, no matter which metrics I use, I need the info that something like a "default script" exists for some languages. Or maybe only for variants (as "recommended prefix"), because these are the difficult cases. For a matching metrics we should use the "recommended prefix": If a variant comes with its recommended e.g. language, then it could get some bonus points. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 04:34:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27474; Thu, 7 Apr 2005 04:34:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJSbw-0000O3-28; Thu, 07 Apr 2005 04:43:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJSSZ-00067z-1e; Thu, 07 Apr 2005 04:33:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJSSW-00067u-HB for ltru@megatron.ietf.org; Thu, 07 Apr 2005 04:33:52 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27431 for ; Thu, 7 Apr 2005 04:33:49 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJSPr-0005lc-Fx for ltru@lists.ietf.org; Thu, 07 Apr 2005 10:31:07 +0200 Received: from du-001-145.access.de.clara.net ([212.82.227.145]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 10:31:07 +0200 Received: from nobody by du-001-145.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 10:31:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 10:30:03 +0200 Organization: Lines: 9 Message-ID: <4254EF8B.6753@xyzzy.claranet.de> References: <20050406230055.RFBE2132.mta5.adelphia.net@megatron.ietf.org> <003601c53b42$b016ed20$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-145.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: quoted-printable Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Doug Ewell wrote: > =C5land Islands, C=F4te d'Ivoire, and R=E9union. Odd, yes, also on their Web page, apparently only these 3 cases. What happened below Luxembourg and below Oman, the extra line ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 07:44:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11978; Thu, 7 Apr 2005 07:44:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJVZD-0006aH-Jf; Thu, 07 Apr 2005 07:52:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJVFi-0002EO-Se; Thu, 07 Apr 2005 07:32:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJVFg-0002EJ-Dq for ltru@megatron.ietf.org; Thu, 07 Apr 2005 07:32:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10566 for ; Thu, 7 Apr 2005 07:32:47 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJVOB-00063u-CI for ltru@ietf.org; Thu, 07 Apr 2005 07:41:38 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 07 Apr 2005 07:32:39 -0400 id 005900C8.42551A57.00004070 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: updated editor's copies... Date: Thu, 7 Apr 2005 07:32:18 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749C9AF@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <425468F0.59C9@xyzzy.claranet.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable > No idea why Scott is so adamant about 2234bis, the bibxml is: > ker-abnf-rfc2234bis.xml> Scott is adamant about it because 2234 is being obsoleted, and you can't = use obsolete specs as normative references. Pay me now or pay me later, new docs will not get approved by the IESG if you cite obsolete specs. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 08:21:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15567; Thu, 7 Apr 2005 08:21:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJW8y-00084z-1u; Thu, 07 Apr 2005 08:29:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJVt0-0005gM-IV; Thu, 07 Apr 2005 08:13:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJVsz-0005gC-MM for ltru@megatron.ietf.org; Thu, 07 Apr 2005 08:13:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14918 for ; Thu, 7 Apr 2005 08:13:24 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJW1W-0007qG-QP for ltru@ietf.org; Thu, 07 Apr 2005 08:22:16 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37CDAL1024865; Thu, 7 Apr 2005 08:13:10 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 08:13:18 -0400 Date: Thu, 7 Apr 2005 08:13:17 -0400 From: John Cowan To: Mark Davis Subject: Re: [Ltru] John Cowan's substantive comments ondraft-ietf-ltru-registry-01 Message-ID: <20050407121317.GE1795@skunk.reutershealth.com> References: <20050407000930.GB407@skunk.reutershealth.com> <006e01c53b3a$cdeadb70$be733009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006e01c53b3a$cdeadb70$be733009@sanjose.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Mark Davis scripsit: > Absolutely not. There is a place for private use codes, and they are easy to > check for. (Moreover, I believe this breaks compatibility with 1766, > although that is not the chief reason for retaining them.) To clarify: I am not proposing the elimination of private-use codes from the set of valid subtags, merely their elimination from the *registry*. > Don't care much, but having the registration form be a superset of the > registration entry is a good feature. Why? -- Winter: MIT, John Cowan Keio, INRIA, jcowan@reutershealth.com Issue lots of Drafts. http://www.ccil.org/~cowan So much more to understand! http://www.reutershealth.com Might simplicity return? (A "tanka", or extended haiku) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 08:22:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15647; Thu, 7 Apr 2005 08:22:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJWA4-00088v-0R; Thu, 07 Apr 2005 08:31:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJVyM-00060J-NP; Thu, 07 Apr 2005 08:18:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJVyK-00060B-Oc for ltru@megatron.ietf.org; Thu, 07 Apr 2005 08:18:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15365 for ; Thu, 7 Apr 2005 08:18:55 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJW6r-00082i-T2 for ltru@ietf.org; Thu, 07 Apr 2005 08:27:47 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37CIjkk024898; Thu, 7 Apr 2005 08:18:45 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 08:18:47 -0400 Date: Thu, 7 Apr 2005 08:18:46 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: Matching metrics Message-ID: <20050407121846.GF1795@skunk.reutershealth.com> References: <20050406230055.RFBE2132.mta5.adelphia.net@megatron.ietf.org> <003301c53b41$9a706f60$030aa8c0@DEWELL> <4254E9EB.7EF0@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4254E9EB.7EF0@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Frank Ellermann scripsit: > No, I wanted en-Latn-US-scouse, but it doesn't work without a > "default script" concept, no matter which metrics I use, I need > the info that something like a "default script" exists for some > languages. In fact what you need is the knowledge that Scouse is a dialect of en-GB. You are asking for something that doesn't exist, and the algorithm is coughing up a hairball of possibilities trying to help you. > Or maybe only for variants (as "recommended prefix"), because > these are the difficult cases. > > For a matching metrics we should use the "recommended prefix": > If a variant comes with its recommended e.g. language, then it > could get some bonus points. That's a possibility. -- After fixing the Y2K bug in an application: John Cowan WELCOME TO jcowan@reutershealth.com DATE: MONDAK, JANUARK 1, 1900 http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 09:55:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24260; Thu, 7 Apr 2005 09:55:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJXbx-0003PZ-7m; Thu, 07 Apr 2005 10:03:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJXQO-0007km-Sw; Thu, 07 Apr 2005 09:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJXQN-0007kh-BZ for ltru@megatron.ietf.org; Thu, 07 Apr 2005 09:52:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24008 for ; Thu, 7 Apr 2005 09:51:56 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJXYt-0003GZ-6i for ltru@ietf.org; Thu, 07 Apr 2005 10:00:50 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37DpiJr025316; Thu, 7 Apr 2005 09:51:45 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 09:51:46 -0400 Date: Thu, 7 Apr 2005 09:51:46 -0400 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] draft review Message-ID: <20050407135146.GI1795@skunk.reutershealth.com> References: <6.1.2.0.2.20050405014928.037ea550@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <6.1.2.0.2.20050405014928.037ea550@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2 Content-Transfer-Encoding: quoted-printable I apologize in advance for the length of this document. It is a formal, but entirely personal, reply to M. Morfin's draft review. The points which I consider valuable in that review are not taken up here; I have concerned myself in this particular message only with M. Morfin's errors, misapprehensions, and insinuations, in the faint hope that they can be disposed of once and for all. JFC (Jefsey) Morfin scripsit: > DRATF RELATED COMMENTS AND QUESTIONS Comments 1-15 are editorial in nature and I have addressed them elsewhere. > 16. 2.2: it is noted that the language used for the "language tags > namespace" and its registry is quite similar to the domain name system. The analogy is vague and specious, and utterly ungrounded in the text, which does not even contain the phrases "domain name system" or "DNS". > However the proposed semantic is not consistent with other Internet > spaces like DNS, IPv4, OID, etc. where the dot-separation is used, > something users and parsers are accustomed to and existing processes > have identified in different scripts. It relies to the contrary on the > "-" as a separator which is more confusing and may have less identified > homographs. What is more confusing about "-" than "."? In any case, "-" has been used in all language tags until now, and is required for backward compatibility. > 17. [...] Such a two, possibly contradictory, systems format will > never scale, is far too dependent from external changes and unable to > support innovation. This is handwaving. Scale to what, millions of countries and trillions of languages? Of course it is dependent on external changes, or rather the lack of them. A format that is designed to depend on anything external cannot possibly adjust in advance to radical changes of an unknown nature. > This cannot be made a world-wide standard through an IETF BCP except > in the cases defined by the charter if the IESG wants to run into the > risk of endless conflicts and of a quick obsolescence. The alleged risk is not supported by the history of RFC 1766/3066 in the last ten years. > It is to be noted that the referred ISO standard to be used are less > than 30 years old and yet ISO 3166-2 cannot be supported. ISO 3166-2 (subnational regions) is not freely available; it costs CHF 200 for a copy without even update service. (Approx. EUR 129 or USD 167.) It has never been proposed or used for language tagging. In addition, it is extremely unstable, because countries are allowed to rewrite their parts of it pretty much ad lib as they reorganize their internal subdivisions from time to time. > 18. 2.2.1: primary language: fixed length identification starts > with 2 or 3 and possibly 8 but discouraged language ID coming this way > only from ISO 639. This removes the possibility to consider computer > related (non only programming) languages, dialects, etc. nor to adapt > to evolutions, adjustments, and passed languages. Untrue. 36^8 possible language tags is more than enough. Discouraging something does not imply removing the possibility of it. > 19. 2.2.1.: the 2 letters code for language is an oddity inherited > from earlier times of RFC 1776 and ISO 639. It is unquestionably a theoretical wart, but is absolutely required for backward compatibility. > It is likely that at some time it will be timed out by ISO or/and by > usage may be even by anti-racist laws. This is a truly amazing bit of prophecy worthy of Michel de Notredame. > Time is now to update existing applications rather than to increase > complexity of the years/century to come. Applications are not at issue; data is. Where is the money going to come from to re-mark-up the billions of existing documents and metadata repositories worldwide that rely on ISO 639-1 codes? > This makes me think > to "UK" instead of "GB". Words like "united" and "kingdom" are avoided when possible in ISO 3166-1 codes because they are shared by many nations. You would be better off pressing for GN (Great Britain and Northern Ireland) or for changing US to some other code. > 20. 2.2.2: language [extended] subtags are permitted only if they > are 3 characters (a permanent rigid position) based the anticipation > of a non documented ISO 639 works. This is also a violation of the > Internet standard process: the document in reference should be quoted > and cannot be a draft. ltru-registry is also only a draft at present. > Language extended subtags are the most active part of languages, Where is the evidence for this claim? Are you confusing the function of extended language subtags with that of variant subtags? > 21. 2.2.3: Script subtags follow the same rigid logic and constraints > from the format. What happens if the memory waste of ISO 15924 (3 > bytes lost) is corrected, or if another code element has a fixed 4 > characters length in the future? We cannot design the draft to adapt to unpredictable massive changes in the format of ISO codes, especially when there is not the slightest evidence that such a thing will ever happen. > 22. 2.2.4: I understand that all the regional language differences > of the world are to be supported by the ISO 3166 alpha-3/digit-3 list. Incorrect. National and supranational regions are supported by ISO 3166-1 alpha-2 and UN M.49 digit-3 codes. > This means that regions like NY, TX or California are not entitled a > code but the 56 persons of Pitcairn Island yes? I doubt that disparity > can hold very long, all the more than ISO 3166-2 provides all the > possibilities for a far more adequate granularity. See above. > 23. 2.2.9: There is a MUST in "there MUST be an attempt to register" > which cannot be enforced if there is not a non-delaying procedure to > verify that a language was attempted to be registered with ISO 639. Forward verification would surely suffice; a copy of a dated email to ISO 639/RA showing an ignored registration would suffice. In facct, however, the RA is quite responsive. > Otherwise this part is to be understood as a disguised way, concerted > with ISO, to block names. There is no evidence for this allegation. > The concern on this point is high enough to see the Draft blocked. Whose concern? Blocked by whom? Vague and unfounded. > It seems that the second paragraph is a smoky verbose replay of the > same idea, without any procedural description nor request/provision > of formal proof. It may *seem* so to you. We deal here in what is so, not in what seems so. > The general idea is precisely in opposition with the purpose of the > proposed RFC: to be able to register names not registered by ISO. This > amount to a legitimisation of censoring, and censoring against the > very intent of this document. Libelous nonsense. The general idea is of course to avoid duplication of effort, so that ISO and ietf-languages are not considering the same language at the same time. > 24. 2.2.9: registrations are left to a decision of appropriateness > by someone debating with undefined others for a matter without any > importance on the network stability and security (documented in in > part 4) non on the end to end interoperability. This seems to amount > to pure intellectual censoring. Non sequitur. > 25. 2.3: recommendation 3 seems inappropriate. Aliases are aliases. > All the aliases must be equally supported because (a) they are aliases > (b) to make sure developers develops correct code. All aliases are equally supported. Not all aliases are equally recommended. > 26. 2.4. "language tags always define a language as spoken by human > being for communications of information to other human beings. Computer > languages are explicitly excluded" has no ground in the Charter and > in reality. Computer languages are not languages, save metaphorically. See ISO 639. > Web Services relations are excluded which may speak limited languages. Do you suppose that SOAP is a language? > Coded human languages should be supported: they fit the definition. What is a coded human language? > 27. 2.4.1: in the canonicalization part "" is reminded as a > deprecation indicator, yet this is not documented earlier. It seems this > is an external ISO practice. This should be documented in the format > description part. All the more than this practice is counter intuitive > "" being understood intuitively as "-(nul)-". And the "" being used > in IDN there could be some homograph confusion to investigate. I suppose that by "" you mean "--". This is not a deprecation indicator, as the draft clearly explains. I will address comments 28-33 elsewhere. > 34. 3.3. why a "MAY" concerning the "description, note and prefix > fields" is not documented by conditions? Is that not a "CAN". CAN does not appear in RFC 2119. I will address comment 35 elsewhere. Comment 36 is editorial in nature and has already been addressed elsewhere. > 37. 3.4. The description of information to be maintained is clear, > but the format is not described. This permits IANA to freely change it > or to present it in HTML form. This does not help its automated reading. 3.4 is about extensions, which are documented through the RFC process and only through the RFC process, as is plainly stated. There is no expectation that information about extensions will be machine-processable. > 38. 4. security considerations should not deal with users political > security outside of their network usage. Otherwise tons of such > considerations should be presented. The point has been raised and is documented. > 39. 4. An important security consideration is homographs. It is > certainly possible to include part of text in a foreign language which > look printed as in another language or having a different meaning or > printing (phishing). This is a security consideration related to the existence of text altogether, not to the tagging of it. Or at most it is related to the absence of tagging. > Concerns are also the double "-" which is specifically used by the > IANA code "xn". The IDN code space is unrelated in any way to the language tag code space. > 40. 4. Fourth paragraph tend to say that specification of valid > sub-tags MUST be available over the internet but that applications > should take possible DoS into consideration. This is an important > indication on the way the Draft proposes the registry file to be used > and accessed. It can be read that applications can freely access it > and proposed mirrors: this may impose on the IANA a load which will > result in its permanent inability of service. There are several possible solutions, including mirrors, upgrades to IANA infrastructure, and load throttling by IANA. Which of these is done, if any, is an internal IANA question and off-topic here. Comments 41-42 are editorial in nature and will be addressed elsewhere. > 43. 6. Stability. Confusion between document. This document does > not provide a mechanism but a format that can be used by the mechanism > described in the next document. This text has not been adapted after > the split. This does not seem to reflect draft-ietf-ltru-registry-01. > 44. 6. Validity. This document should define the IQ of > the "intelligent people" being considered or the collective IQ > augmentation necessary to understand the system ?? Please see the > ideas of the one who created the NIC and grand fathered the RFC system > (http://bootstrap.org). Irrelevant. The draft says that *even* intelligent people may do inconsistent things in the absence of guidance. > 45. 6. Extensibility such as presented actually results (in a very > limited way) from the underlying ISO codes. This is not the target of > Charter which is to permit scalability even when a code element it is > not supported by ISO. That is one of many points mentioned in the charter. It is not the singular goal of the draft. Comment 46 is editorial in nature and will be addressed elsewhere. > 47. 6. last: added text for "" is not sufficient enough, or is > missing in my version. Unintelligible. > CHARTER VS DRATF RELATED COMMENTS AND QUESTIONS 48. language > preferences are uniquely understood in HTML, XML only. CLDR are > quoted in the charter and not quoted in the Draft. The Charter does > not prevent other applications, systems to be supported. The Draft > does not allude to them. As stated in earlier postings, these are merely consumers of RFC 3066 language tags. There are others. There is no reason for the draft to mention its consumers; rather they mention it. > 49. The charter lists RFC 3066 problems. These problems are: (a) > stability there is a paragraph on the matter; (b) accessibility to the > underlying ISO standard this is definitely impeached by the format > (no ISO 3166-2, no other ISO 639 format than 2 or 3 characters no > other script description format than 4 characters, etc. as if the > current ISO presentation will never improve); Answered above. There is no reason to expect such changes, and no evidence is given that they constitute improvements. > (c) difficulty with registration and acceptance: this could be improved > by the subtag registration system but it seems to be made worse, > due to the censoring rules introduced to prevent non-ISO entries to > be entered in the IANA non-ISO table; "Prevent" is a malicious falsehood. > (e) lack of clear guidance to identify script and region: scripts are > Unicode only, Untrue. See the ISO 15924/RA registry, which lists many non-Unicode scripts. > region are 2 letter Telex codes; They are part of an international standard, whether originally derived from Telex codes or not. > (f) lack of parseability and well-formedness : this has certainly been > addressed [it seems to be both the major improvement of the Draft > =1B)B=85 and the source of most of its problems due to the rigidity > it introduces]. Rigidity about matters which cannot be expected to change is not only reasonable but desirable. > 50. The main purpose of this Draft from the charter is to describe > the IANA registry to support the resolution of the above problems, > and how transition from RFC 3066. This is to be in a clear and concise > way. RFC 3066 represents roughly 17.000 characters and the draft 70.000 > (out of the IETF format and verbose). Out of the IETF format in what way? > This makes it confuse. From what I understand it includes 3 parts: > (a) the subtags file with a clear format (b) the accompanying > registration/update forms (c) the variant tables with a clear, yet > less precise format. What "variant tables"? This expression does not appear in the draft, nor is anything described that could be so designated. > From what I understand (a)(b) are the real responsibility of the old > aliased distribution list and of a Reviewer designated by IESG with > unlimited veto powers; As the draft (and RFC 3066 and 1766) clearly state, the Reviewer's decisions may be appealed to IESG. That is not an unlimited veto. > 51. it lists challenges to be addressed. Stability: "how the language > tags remains stable even if the underlying references should change". > This means a process where the tag name is unrelated to its underlying > components, like a domain name is stable even if the underlying IP > address changes. This is not provided. The analogy to the DNS is specious. A more correct analogy would be attemping to keep a domain name stable when one of its enclosing domains changes its name. > 52. it lists challenges to be addressed. Accessibility: "a simple way > to determine if a subtag is valid as of a given date. Like receiving > a 404 when calling an expired domain name". Such a mechanism is not > provided. The expression in quotation marks is not, in fact, a quotation from the charter, and so need not be addressed. > 53. it lists challenges to be addressed. extensibility: this meant > not having to record millions of combinations. This is provided. To > the price of format rigidity, impossible use of foreseen or existing > ISO code elements, and a censoring of the non-ISO extensions which > may lead to more harassment. It also meant addition of the script in > language tags. This is permitted by the proposed format but to the > detriment of other 4 letters entries. Registration of non ISO scripts > is not permitted. Answered above. > 54. it lists challenges to be addressed. "provide mechanism to support > the evolution of the underlying standards, in particular ISO 693-3, > mechanisms to support variant registration and format extensions, > as well as allowing generative private use when necessary": I am not > sure what "generative" may mean in here but I feel it is not supported, > the rest is certainly opposed by the chosen format; "Generative" refers to the ability to create complex elements from the systematic assembly of simpler elements. ISO 639-3 concerns have been taken into account from the start. Variant registration is directly supported. Format extensions are provided for. > 55. it lists challenges to be addressed: "to specify a mechanism for > easily identifying the role of each subtag in the language tag". This > is addressed by the Draft. But this challenge is contradictory with > stability challenge above. If a language tag displays an identifiable > subtag, it becomes by nature dependent from the underlying value of > the subtag. It certainly does. To use your favorite analogy, a domain name is not independent of the name of its enclosing domains; were the .fr TLD to change its name to .gaul tomorrow, all subdomains of .fr would have to change likewise. --=20 As you read this, I don't want you to feel John Cowan=20 sorry for me, because, I believe everyone jcowan@reutershealth.com will die someday. http://www.reutershealth.com --From a Nigerian-type scam spam http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 11:45:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06496; Thu, 7 Apr 2005 11:45:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZLD-0007vN-Nw; Thu, 07 Apr 2005 11:54:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZBI-0005xq-Ba; Thu, 07 Apr 2005 11:44:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZBG-0005x7-Gs for ltru@megatron.ietf.org; Thu, 07 Apr 2005 11:44:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06402 for ; Thu, 7 Apr 2005 11:44:20 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZJi-0007r4-2B for ltru@ietf.org; Thu, 07 Apr 2005 11:53:15 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j37Fi2JE007697; Thu, 7 Apr 2005 08:44:02 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Apr 2005 08:44:02 -0700 Message-ID: From: "McDonald, Ira" To: "'Doug Ewell'" , LTRU Working Group Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) Date: Thu, 7 Apr 2005 08:43:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Hi, Inline below. Cheers, - Ira Doug Ewell wrote: > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Doug Ewell > Sent: Thursday, April 07, 2005 3:09 AM > To: LTRU Working Group > Subject: [Ltru] Re: Compatibility with existing use (LDAP) > > > Kurt D. Zeilenga wrote: > > > If you change the syntax and semantics of RFC 3066 tags, > > you will break everything that relies on them. > > Fortunately, we're not doing that. > I don't believe that this quiet insertion of script between language and region is harmless to RFC 3066 implementations. It's true that such tags were allowed to be registered by RFC 3066. But there are literally millions of documents currently language tagged on the Internet in the style of 'language-REGION-whatever' and lots of naive software thinks that's the only valid form of a language tag. The linguistic purity of infixing 'script' (between language and region) is unwise. The recent (all unsuccessful) numeric weighting algorithms for 'smart matching' make this point eloquently. > Ira McDonald had written: > > > Also, LTRU is developing an IANA registry of EVERY > > possible valid language tag. > > We're not doing that either. Important distinction: we are > developing a > registry of every possible valid *subtag*, not tag. The > former adds up > to just under a thousand items; the latter (including all the > ridiculous > ones) would be about 15 million. > Oops! My silly mistake. Tired fingers. > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 11:59:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08183; Thu, 7 Apr 2005 11:59:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZYj-0008Sb-PM; Thu, 07 Apr 2005 12:08:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZOI-0003ec-9B; Thu, 07 Apr 2005 11:57:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZOG-0003eX-SG for ltru@megatron.ietf.org; Thu, 07 Apr 2005 11:57:57 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08007 for ; Thu, 7 Apr 2005 11:57:53 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJZKV-00033n-Mx for ltru@lists.ietf.org; Thu, 07 Apr 2005 17:54:03 +0200 Received: from c-134-89-44.hh.dial.de.ignite.net ([62.134.89.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 17:54:03 +0200 Received: from nobody by c-134-89-44.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 17:54:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 17:55:23 +0200 Organization: Lines: 17 Message-ID: <425557EB.6BBE@xyzzy.claranet.de> References: <20050406230055.RFBE2132.mta5.adelphia.net@megatron.ietf.org> <003301c53b41$9a706f60$030aa8c0@DEWELL> <4254E9EB.7EF0@xyzzy.claranet.de> <20050407121846.GF1795@skunk.reutershealth.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: c-134-89-44.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] e-GB-scouse (was: Matching metrics) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit John Cowan wrote: > In fact what you need is the knowledge that Scouse is a > dialect of en-GB. Not used elsewhere ? That would be very different from some de-dialects found in places like Pennsylvania, Paraguay, or Kazakhstan, all different from their oounterparts in Germany today. No chance of "en-scouse" communities in the US or in other parts of the world excl. GB ? If that's the case we just found another problem of squeezing four dimensions into one: "scouse" would need a "recommended prefix" en-GB (implicitly en-*-GB), not only en. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 12:09:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08945; Thu, 7 Apr 2005 12:09:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZhu-0000La-44; Thu, 07 Apr 2005 12:18:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZWi-0004tV-7O; Thu, 07 Apr 2005 12:06:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZWg-0004tL-PJ for ltru@megatron.ietf.org; Thu, 07 Apr 2005 12:06:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08800 for ; Thu, 7 Apr 2005 12:06:35 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZfG-0000Fw-1O for ltru@ietf.org; Thu, 07 Apr 2005 12:15:31 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 09:06:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed changes to region subtags Date: Thu, 7 Apr 2005 09:06:24 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFC48@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed changes to region subtags Thread-Index: AcU692GqjcQcFK/8Q3CGerrQb7nfSwAlAJ4g From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 07 Apr 2005 16:06:25.0114 (UTC) FILETIME=[BF9CBBA0:01C53B8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable It isn't the draft registry, but the rules in the registry draft that we = care about. They need to be comprehensive. It is easier to spec the escape format widely and then limit the range = permitted than to be narrow in our definitions. Finally, there may be good reason to put in comments (i.e. non-normative = material) that contain non-ASCII and non-Latin code points (pointing out = differences in usage or names in some specific language---Chinese comes = immediately to mind). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: mercredi 6 avril 2005 15:19 > To: ltru@ietf.org > Subject: [Ltru] Re: Proposed changes to region subtags >=20 > Randy Presuhn wrote: >=20 > > Couldn't we simply use Unicode character references (as > > needed) in a record-jar format? >=20 > That would be an ad-hoc format, an ABNF for the complete > record-jar format with this idea is of course possible. >=20 > Essentially we'd need ꯍ or 򫳞 - let's ignore > � Anything else not starting with &#x is ASCII. >=20 > But there are no Unicode points above 126 in the draft > registry at the moment, so why do we discuss this now ? >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 12:28:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11214; Thu, 7 Apr 2005 12:28:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJa07-0001Ed-Eu; Thu, 07 Apr 2005 12:37:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZnt-0007zf-Hc; Thu, 07 Apr 2005 12:24:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZnr-0007zL-CR for ltru@megatron.ietf.org; Thu, 07 Apr 2005 12:24:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10812 for ; Thu, 7 Apr 2005 12:24:20 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZwR-000131-F9 for ltru@ietf.org; Thu, 07 Apr 2005 12:33:16 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 09:24:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Date: Thu, 7 Apr 2005 09:24:11 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFC68@irvmbxw01.quest.com> Thread-Topic: [Ltru] John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Thread-Index: AcU7OvTVA9Jmm378SzCJX8d+V7rn9AAUdTpQ From: "Addison Phillips" To: "Mark Davis" , "John Cowan" , X-OriginalArrivalTime: 07 Apr 2005 16:24:13.0592 (UTC) FILETIME=[3C798980:01C53B8E] X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0491968580==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 --===============0491968580== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdtIGluIGNvbXBsZXRlIGFncmVlbWVudCB3aXRoIE1hcmssIHdpdGggdGhlIHByb3Zpc29zIHNo b3duIGludGVybGluZWFybHkgYmVsb3cuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlw cw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIElu dGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXph dGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5v cmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBN YXJrIERhdmlzDQo+IFNlbnQ6IG1lcmNyZWRpIDYgYXZyaWwgMjAwNSAyMzoyNw0KPiBUbzogSm9o biBDb3dhbjsgbHRydUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0x0cnVdIEpvaG4gQ293YW4n cyBzdWJzdGFudGl2ZSBjb21tZW50c29uZHJhZnQtaWV0Zi1sdHJ1LQ0KPiByZWdpc3RyeS0wMQ0K PiANCj4gTXkgY29tbWVudHMgb24gSm9obidzDQo+IA0KPiDigI5NYXJrDQo+IA0KPiAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJKb2huIENvd2FuIiA8amNvd2FuQHJldXRl cnNoZWFsdGguY29tPg0KPiBUbzogPGx0cnVAaWV0Zi5vcmc+DQo+IFNlbnQ6IFdlZG5lc2RheSwg QXByaWwgMDYsIDIwMDUgMTc6MDkNCj4gU3ViamVjdDogW0x0cnVdIEpvaG4gQ293YW4ncyBzdWJz dGFudGl2ZSBjb21tZW50cw0KPiBvbmRyYWZ0LWlldGYtbHRydS1yZWdpc3RyeS0wMQ0KPiANCj4g DQo+ID4gUHJvcG9zYWwgcmVnaXN0cnktY293YW4tMDE6IEFscGhhIG9yZGVyIGluIGV4dGVuc2lv biBzdWJ0YWdzDQo+ID4NCj4gPiBDVVJSRU5UOiBFeHRlbnNpb24gc3VidGFncyBNQVkgYXBwZWFy IGluIGFueSBvcmRlciBpbiBhIGxhbmd1YWdlIHRhZy4NCj4gPiBJdCBpcyBub3QgY2xlYXIgd2hl dGhlciB0aGUgb3JkZXIgbWF0dGVycywgYnV0IHByb2JhYmx5IG5vdCwgc2luY2UNCj4gPiB0YWcg Y2Fub25pY2FsaXphdGlvbiByZXF1aXJlcyB0aGVtIHRvIGJlIHNvcnRlZCBpbnRvIGNhc2UtaW5z ZW5zaXRpdmUNCj4gPiBhbHBoYWJldGljIG9yZGVyIGJ5IHNpbmdsZXRvbi4NCj4gPg0KPiA+IFBS T1BPU0VEOiAgUmVxdWlyZSB0aGF0IGV4dGVuc2lvbiBzdWJ0YWdzIGFscmVhZHkgYmUgc29ydGVk IGJ5IHNpbmdsZXRvbg0KPiA+IG9yZGVyIGluIHdlbGwtZm9ybWVkIHRhZ3MuDQo+ID4NCj4gPiBS QVRJT05BTEU6ICBFeHRlbnNpb24gc3VidGFncyBhcmUgbm92ZWwsIHNvIHRoZXJlIGlzIG5vIHBy ZXZpb3VzDQo+ID4gcHJhY3RpY2UuICBBbHBoYWJldGljYWxuZXNzIG9mIHNpbmdsZXRvbnMgaXMg ZWFzeSB0byBjaGVjayBmb3IuDQo+ID4gTWVhbmluZ2xlc3MgdmFyaWFiaWxpdHkgaXMgcmVkdWNl ZC4NCj4gDQo+IE9rIGJ5IG1lLg0KPiANCj4gPg0KPiA+DQo+ID4gUHJvcG9zYWwgcmVnaXN0cnkt Y293YW4tMDI6IEJhbiBzaW5nbGV0b24gImkiDQo+ID4NCj4gPiBDVVJSRU5UOiAiaSIgTUFZIGJl IHVzZWQgYXMgYSBzaW5nbGV0b24gaW4gZXh0ZW5zaW9uIHN1YnRhZ3MuDQo+ID4NCj4gPiBQUk9Q T1NFRDogImkiIE1VU1QgTk9UIGJlIHVzZWQgYXMgYSBzaW5nbGV0b24uDQo+ID4NCj4gPiBSQVRJ T05BTEU6ICBUaGUgc2luZ2xlLWNoYXJhY3RlciBzdWJ0YWcgImkiIGlzIGFscmVhZHkgdXNlZCBp bg0KPiA+IGdyYW5kZmF0aGVyZWQgdGFncyBpbiBhIGRpZmZlcmVudCBzZW5zZS4gIEFsdGhvdWdo IG1lY2hhbmljYWwgcHJvY2Vzc2VzDQo+ID4gd2lsbCBub3QgY29uZnVzZSB0aGUgdHdvIHNlbnNl cyAoZ3JhbmRmYXRoZXJlZCAiaSIgaXMgYWx3YXlzIGluaXRpYWwsDQo+ID4gc2luZ2xldG9uICJp IiBpcyBuZXZlciBpbml0aWFsKSwgaHVtYW4gYmVpbmdzIG1heS4gIEVsaW1pbmF0aW5nICJpIg0K PiA+IGRvZXMgbm90IHNpZ25pZmljYW50bHkgcmVkdWNlIHRoZSBzcGFjZSBvZiBzaW5nbGV0b25z IGF2YWlsYWJsZSBmb3INCj4gPiByZWdpc3RyYXRpb24uDQo+IA0KPiBOby4gVGhpcyBpcyBubyBy ZWFzb24gdG8gcmVkdWNlIHRoZSBleHRlbnNpb24gc3BhY2UuDQo+IA0KPiA+DQo+ID4NCj4gPiBQ cm9wb3NhbCByZWdpc3RyeS1jb3dhbi0wMzogIEJhbiBzaW5nbGV0b25zICJ5IiBhbmQgInoiDQo+ ID4NCj4gPiBDVVJSRU5UOiAgInkiIGFuZCAieiIgTUFZIGJlIHVzZWQgYXMgc2luZ2xldG9ucyBp biBleHRlbnNpb24gc3VidGFncy4NCj4gPg0KPiA+IFBST1BPU0VEOiAgInkiIGFuZCAieiIgTVVT VCBOT1QgYmUgdXNlZCBhcyBzaW5nbGV0b25zLg0KPiA+DQo+ID4gUkFUSU9OQUxFOiBJZiBjb3dh bi1yZWdpc3RyeS0wMSBpcyBhY2NlcHRlZCwgdGhlbiBhY2NlcHRpbmcgdGhpcw0KPiBwcm9wb3Nh bA0KPiA+IGFzIHdlbGwgd291bGQgYWxsb3cgYSBzaW1wbGlmaWNhdGlvbiBvZiB3ZWxsLWZvcm1l ZG5lc3MgY2hlY2tpbmcgaW4gdGhhdA0KPiA+IHRoZSBzaW5nbGV0b24gIngiIGluIGEgbm9uLWlu aXRpYWwgcG9zaXRpb24gbmVlZCBub3QgYmUgdHJlYXRlZA0KPiBzcGVjaWFsbHkuDQo+ID4gT3Ro ZXJ3aXNlLCB0aGUgY2Fub25pY2FsIG9yZGVyIGlzICJhIiwgImIiLCAuLi4sICJ3IiwgInkiLCAi eiIsICJ4Ii4NCj4gPiBFbGltaW5hdGluZyAieCIgYW5kICJ5IiBkb2VzIG5vdCBncmVhdGx5IHJl ZHVjZSB0aGUgc3BhY2Ugb2Ygc2luZ2xldG9ucw0KPiA+IGF2YWlsYWJsZSBmb3IgcmVnaXN0cmF0 aW9uLg0KPiANCj4gTm8uIFRoaXMgaXMgbm8gcmVhc29uIHRvIHJlZHVjZSB0aGUgZXh0ZW5zaW9u IHNwYWNlLiBBbmQgdGhlIGV4dHJhIGVmZm9ydA0KPiB0bw0KPiBzb3J0IHggYXQgdGhlIGVuZCwg Z2l2ZW4gdGhlIG90aGVyIHdvcmsgaW4gY2Fub25pY2FsaXppbmcsIGlzIGluIHRoZSBub2lzZS4N Cj4gDQo+ID4NCj4gPg0KPiA+IFByb3Bvc2FsIHJlZ2lzdHJ5LWNvd2FuLTA0OiBTcGVjaWZ5IGNh c2UgcnVsZXMgZm9yIGNhbm9uaWNhbCB0YWdzDQo+ID4NCj4gPiBDVVJSRU5UOiAgQ2Fub25pY2Fs aXppbmcgYSB0YWcgZG9lcyBub3QgYWZmZWN0IHRoZSBjYXNlIG9mIHRoZSBsZXR0ZXJzDQo+ID4g aW4gaXQuDQo+ID4NCj4gPiBQUk9QT1NFRDogQ2Fub25pY2FsaXppbmcgYSB0YWcgYWRqdXN0cyB0 aGUgY2FzZSBvZiB0aGUgbGV0dGVycyBhcw0KPiBmb2xsb3dzOg0KPiA+DQo+ID4gMSkgVGhlIGZp cnN0IGxldHRlciBvZiBhIHNjcmlwdCBzdWJ0YWcgaXMgdXBwZXIgY2FzZTsgMikgQm90aA0KPiA+ IGxldHRlcnMgb2YgYW4gYWxwaGEgcmVnaW9uIHN1YnRhZyBhcmUgdXBwZXIgY2FzZTsgMykgQWxs IG90aGVyDQo+ID4gbGV0dGVycyBhcmUgbG93ZXIgY2FzZS4NCj4gPg0KPiA+IFJBVElPTkFMRTog IFRoZXNlIGFyZSB0aGUgZGUgZmFjdG8gY2Fub25pY2FsaXphdGlvbiBydWxlcyBmb3IgSVNPIDYz OSwNCj4gPiBJU08gMzE2NiwgYW5kIElTTyAxNTkyNCBjb2Rlcy4gU2luY2Ugd2UgaGF2ZSBub3Qg aGFkIGNhbm9uaWNhbCB0YWdzDQo+ID4gYmVmb3JlLCB0aGVyZSBpcyBubyBwcmV2aW91cyBwcmFj dGljZSB0byBjb250cmFkaWN0LiAgVGhlIHJlcXVpcmVtZW50DQo+ID4gZm9yIGNhc2UtaW5zZW5z aXRpdmUgbWF0Y2hpbmcgbWF5IGJlIGVsaW1pbmF0ZWQgaWYgYWxsIHRhZ3MgYmVpbmcNCj4gbWF0 Y2hlZA0KPiA+IGFyZSBrbm93biB0byBiZSBjYW5vbmljYWwuDQo+IA0KPiBPayBieSBtZS4NCltB ZGRpc29uIFBoaWxsaXBzXSANCg0KT2theSBieSBtZSwgYnV0IEknZCBwcmVmZXIgbm90IHRvIGRv IHRoaXMuIEl0IGRvZXNuJ3QgYWRkIGFueXRoaW5nIHN1YnN0YW50aWFsIGVpdGhlci4gV2h5IG1h a2UgYSBmZXcgaW1wbGVtZW50YXRpb25zIHRoYXQgZW1pdCB0YWdzIGluIG9uZSBjYXNlIG9yIGFu b3RoZXIgbm9uLWNhbm9uaWNhbD8NCj4gDQo+ID4NCj4gPg0KPiA+IFByb3Bvc2FsIHJlZ2lzdHJ5 LWNvd2FuLTA1OiBSRkMgODIyIGxpbmUgd3JhcHBpbmcgaW4gdGhlIHJlZ2lzdHJ5DQo+ID4NCj4g PiBDVVJSRU5UOiBMaW5lIHdyYXBwaW5nIGlzIGRvbmUgd2l0aCBhIHRyYWlsaW5nIGJhY2tzbGFz aC4NCj4gPg0KPiA+IFBST1BPU0VEOiBMaW5lIHdyYXBwaW5nIGlzIGRvbmUgYnkgcmVwbGFjaW5n IGEgY2hvc2VuIHNlcXVlbmNlIG9mDQo+ID4gaG9yaXpvbnRhbCB3aGl0ZXNwYWNlIHdpdGggYSBs aW5lIHRlcm1pbmF0b3IgZm9sbG93ZWQgYnkgaG9yaXpvbnRhbA0KPiA+IHdoaXRlc3BhY2UuICAo U2VlIFJGQyAyODIyIGZvciBzcGVjaWZpYyB0ZXh0LikNCj4gPg0KPiA+IFJBVElPTkFMRTogQ29t cGF0aWJpbGl0eSB3aXRoIFJGQyAoMik4MjIuDQo+IA0KPiBEb24ndCBjYXJlIGVpdGhlciB3YXku DQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCkRpdHRvLiBOb3RpY2UgdGhhdCBieSBwdXR0aW5nIGEg c3Rha2UgaW4gdGhlIGdyb3VuZCB3ZSBjYW4gbWFrZSBwcm9ncmVzcy4uLg0KPiANCj4gPg0KPiA+ DQo+ID4gUHJvcG9zYWwgcmVnaXN0cnktY293YW4tMDY6IFJlbW92ZSBsZWFkaW5nIHplcm9zIGZy b20gY2hhcmFjdGVyDQo+IHJlZmVyZW5jZXMNCj4gPg0KPiA+IENVUlJFTlQ6IEV2ZXJ5IGNoYXJh Y3RlciByZWZlcmVuY2UgTVVTVCBjb250YWluIGF0IGxlYXN0IGZvdXIgZGlnaXRzLg0KPiA+DQo+ ID4gUFJPUE9TRUQ6IENoYXJhY3RlciByZWZlcmVuY2VzIE1VU1QgY29udGFpbiBiZXR3ZWVuIG9u ZSBhbmQgc2l4IGRpZ2l0cw0KPiA+IGluY2x1c2l2ZS4NCj4gPg0KPiA+IEFMVEVSTkFUSVZFOiBD aGFyYWN0ZXIgcmVmZXJlbmNlcyBNVVNUIGNvbnRhaW4gYmV0d2VlbiBvbmUgYW5kIHNpeA0KPiBk aWdpdHMNCj4gPiBpbmNsdXNpdmUsIGFuZCBNVVNUIE5PVCBoYXZlIGxlYWRpbmcgemVyb3MuDQo+ ID4NCj4gPiBSQVRJT05BTEU6ICBUaGUgcHJvcG9zYWwgaXMgY29tcGF0aWJsZSB3aXRoIFhNTC4g IFRoZSBhbHRlcm5hdGl2ZQ0KPiBwcm9wb3NhbA0KPiA+IGlzIGFsc28gY29tcGF0aWJsZSB3aXRo IFhNTCBhbmQgYWxsb3dzIG9ubHkgb25lIHBvc3NpYmxlIGVuY29kaW5nIGZvcg0KPiA+IGVhY2gg Y29kZXBvaW50Lg0KPiANCj4gRG9uJ3QgY2FyZSBlaXRoZXIgd2F5Lg0KW0FkZGlzb24gUGhpbGxp cHNdIA0KDQpJIGRvbid0IGNhcmUsIGJ1dCBJIHN0cm9uZ2x5IHByZWZlciBlbnRpdGllcyB0aGF0 IGFyZSByZWd1bGFyIGluIGZvcm0uIFRoZSBlbnRpdHkgJiN4YzA7IGlzIGxlc3Mgb2J2aW91c2x5 IGEgVW5pY29kZSB2YWx1ZSB0aGFuIHRoZSBlbnRpdHkgJiN4MDBDMDsNCj4gDQo+ID4NCj4gPg0K PiA+IFByb3Bvc2FsIHJlZ2lzdHJ5LWNvd2FuLTA3OiBSZW1vdmUgcHJpdmF0ZSB1c2UgdGFncyBm cm9tIHRoZSByZWdpc3RyeQ0KPiA+IGFuZCBzYW1wbGUgcmVnaXN0cnkuDQo+ID4NCj4gPiBDVVJS RU5UOiAgVGhlIHByaXZhdGUgdXNlIGNvZGVzIG9mIHRoZSBJU08gc3RhbmRhcmRzIGFyZSBpbmNs dWRlZCBpbg0KPiA+IHRoZSByZWdpc3RyeS4NCj4gPg0KPiA+IFBST1BPU0VEOiAgUmVtb3ZlIHRo ZW0gZnJvbSB0aGUgcmVnaXN0cnkuICBBbHNvIHJlbW92ZSB0aGUgY29uY2VwdCBvZg0KPiA+IHZh bHVlIHJhbmdlcyBmcm9tIFNlY3Rpb24gMy4xLCB3aGljaCBpcyBuZWVkZWQgb25seSBmb3IgcHJp dmF0ZSB1c2UgdGFncy4NCj4gPg0KPiA+IFJBVElPTkFMRTogIFByaXZhdGUgdXNlIHRhZ3MgYXJl IGZvciBwcml2YXRlIHVzZSwgYW5kIHByaXZhdGUgYWdyZWVtZW50cw0KPiA+IGFib3V0IHRoZW0g ZG8gbm90IHNjYWxlLiAgVGhleSBvdWdodCBub3QgdG8gYmUgY29udGFpbmVkIGluIGEgcHVibGlj DQo+ID4gcmVnaXN0cnkuICBUaG9zZSB3aG8gd2lzaCB0byB1c2UgdGhlbSBjYW4gbG9vayBhdCB0 aGUgUkZDLg0KPiANCj4gQWJzb2x1dGVseSBub3QuIFRoZXJlIGlzIGEgcGxhY2UgZm9yIHByaXZh dGUgdXNlIGNvZGVzLCBhbmQgdGhleSBhcmUgZWFzeQ0KPiB0bw0KPiBjaGVjayBmb3IuIChNb3Jl b3ZlciwgSSBiZWxpZXZlIHRoaXMgYnJlYWtzIGNvbXBhdGliaWxpdHkgd2l0aCAxNzY2LA0KPiBh bHRob3VnaCB0aGF0IGlzIG5vdCB0aGUgY2hpZWYgcmVhc29uIGZvciByZXRhaW5pbmcgdGhlbS4p DQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCkkgdmVyeSBtdWNoIHN1cHBvcnQgdGhpcy4gSSB0aGlu ayBKb2huJ3MgbWVzc2FnZSB3YXNuJ3QgdGhhdCB0aGUgcHJpdmF0ZSB1c2UgY29kZXMgd291bGQg YmUgb3V0bGF3ZWQsIG9ubHkgdGhhdCB0aGV5J2QgYmUgcmVtb3ZlZCBmcm9tIHRoZSByZWdpc3Ry eS4gSG93ZXZlciwgbm90IGhhdmluZyB0aGVtIGluIHRoZSByZWdpc3RyeSBtaWdodCBjb25mdXNl IGltcGxlbWVudGVycyBpbnRvIHRoaW5raW5nIHRoYXQgdGhleSBkaWRuJ3QgaGF2ZSB0byBzdXBw b3J0IHRob3NlIHZhbHVlcy4gUmF0aW9uYWxlIGZvciBpbmNsdWRpbmcgdGhlc2UgdmFsdWVzIGlz IGluIHRoZSBkcmFmdC4gVGhleSBzaG91bGQgYXBwZWFyIGluIHRoZSByZWdpc3RyeSB0b28uDQo+ IA0KPiA+DQo+ID4NCj4gPiBQcm9wb3NhbCByZWdpc3RyeS1jb3dhbi0wODogU2ltcGxpZnkgdGhl IGxhbmd1YWdlIHRhZyByZWdpc3RyYXRpb24gZm9ybQ0KPiA+DQo+ID4gQ1VSUkVOVDogU2VlIFNl Y3Rpb24gMy4zLg0KPiA+DQo+ID4gUFJPUE9TRUQ6IFRoZSBudW1iZXJlZCBpdGVtcyAxLTMgYW5k IDQtOCBzaG91bGQgYmUgcmVwbGFjZWQgYnkNCj4gPiB0aGUgZm9sbG93aW5nIG5ldyBvciBleGlz dGluZyBmaWVsZHMgaW4gdGhlIHJlZ2lzdHJ5OiAgUmVxdWVzdGVyLA0KPiA+IFJlcXVlc3Rlci1F bWFpbCwgRGVzY3JpcHRpb24sIE1lYW5pbmcsIE5hdGl2ZS1OYW1lLCBSZWZlcmVuY2UsIENvbW1l bnRzLg0KPiA+DQo+ID4gUkFUSU9OQUxFOiBUaGVzZSByZWdpc3RyYXRpb24gZm9ybXMgd2lsbCBu b3QgYmUgcmVhZGlseSBhdmFpbGFibGUgdG8NCj4gPiBlbnF1aXJlcnMgYWZ0ZXIgdGhlIG1lYW5p bmcgb2YgYSBzcGVjaWZpYyBsYW5ndWFnZSBvciB2YXJpYW50IHRhZy4NCj4gPiBNYWtpbmcgc3Vy ZSB0aGF0IGFsbCB0aGUgaW5mb3JtYXRpb24gaXMgaW5jbHVkZWQgaW4gdGhlIHJlZ2lzdHJ5IGlz DQo+ID4gdGhlcmVmb3JlIGltcG9ydGFudCwgZXZlbiBhdCB0aGUgY29zdCBvZiBhIGxhcmdlciBy ZWdpc3RyeS4gIFJlZ2lzdGVyZWQNCj4gPiBsYW5ndWFnZXMgd2lsbCBiZSB2ZXJ5IHJhcmUsIGFu ZCByZWdpc3RlcmVkIHZhcmlhbnRzIGZhaXJseSByYXJlLCBiYXNlZA0KPiA+IG9uIGV4aXN0aW5n IGV4cGVyaWVuY2UsIHNvIHRoZSBjb3N0IHdpbGwgbm90IGJlIHZlcnkgZ3JlYXQuDQo+IA0KPiBE b24ndCBjYXJlIG11Y2gsIGJ1dCBoYXZpbmcgdGhlIHJlZ2lzdHJhdGlvbiBmb3JtIGJlIGEgc3Vw ZXJzZXQgb2YgdGhlDQo+IHJlZ2lzdHJhdGlvbiBlbnRyeSBpcyBhIGdvb2QgZmVhdHVyZS4NCltB ZGRpc29uIFBoaWxsaXBzXSANCg0KRmluZSBieSBtZS4gUHJhY3RpY2FsIHF1ZXN0aW9uczoNCg0K MS4gU2hvdWxkIHRoZSBlbWFpbCBiZSBvYmZ1c2NhdGVkPyAoYWRkaXNvbiBkb3QgcGhpbGxpcHMg YXQgcXVlc3QgZG90IGNvbT8/KQ0KDQoyLiBTaG91bGQgaXQgYmUgYW4gKEFTQ0lJKSBVUkk/IElu IG90aGVyIHdvcmRzLCBob3cgc2hvdWxkIElETidzIGJlIGhhbmRsZWQ/DQoNCjMuIFJlZmVyZW5j ZSBpcyBhIHRleHQgZmllbGQgbmFtaW5nIGRvY3VtZW50cy4gU2hvdWxkIHRoZXJlIGJlIHJ1bGVz IGZvciBuYW1pbmcgVVJJcz8gV2hhdCBvdGhlciByZXN0cmljdGlvbnMgYXBwbHk/DQoNCjQuIEFy ZSB0aGUgbmF0aXZlIG5hbWUgcnVsZXMgSSBoYXZlIGluIHRoZSBkcmFmdCBzdWZmaWNpZW50Pw0K PiANCj4gPg0KPiA+IC0tDQo+ID4gdXNhZ2U6IG10IFstdl0gWy0tdmVyc2lvbl0gWy1oXSBbIC1m IGRldmljZSBdIGNvbW1hbmQgWyBjb3VudCBdDQo+ID4gQSByYWJiaSB3aG9zZSBjb25ncmVnYXRp b24gZG9lc24ndCB3YW50ICAgICAgICAgSm9obiBDb3dhbg0KPiA+IHRvIGRyaXZlIGhpbSBvdXQg b2YgdG93biBpc24ndCBhIHJhYmJpLA0KPiBodHRwOi8vd3d3LmNjaWwub3JnL35jb3dhbg0KPiA+ IGFuZCBhIHJhYmJpIHdobyBsZXRzIHRoZW0gZG8gaXQgICAgICAgICAgICAgICAgIGpjb3dhbkBy ZXV0ZXJzaGVhbHRoLmNvbQ0KPiA+IGlzbid0IGEgbWFuLiAgICAtLUpld2lzaCBzYXlpbmcNCj4g aHR0cDovL3d3dy5yZXV0ZXJzaGVhbHRoLmNvbQ0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiA+ IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9sdHJ1DQo+ID4NCj4gPg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1 QGxpc3RzLmlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2x0cnUNCg0K --===============0491968580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0491968580==-- From ltru-bounces@ietf.org Thu Apr 7 12:34:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12086; Thu, 7 Apr 2005 12:34:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJa64-0001Zm-AN; Thu, 07 Apr 2005 12:43:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZuy-0001aL-BS; Thu, 07 Apr 2005 12:31:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZuw-0001Zi-Fc for ltru@megatron.ietf.org; Thu, 07 Apr 2005 12:31:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11784 for ; Thu, 7 Apr 2005 12:31:39 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJa3W-0001R4-0p for ltru@ietf.org; Thu, 07 Apr 2005 12:40:35 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37GVV3x026180; Thu, 7 Apr 2005 12:31:31 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 12:31:34 -0400 Date: Thu, 7 Apr 2005 12:31:33 -0400 From: John Cowan To: "McDonald, Ira" Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Message-ID: <20050407163133.GH31242@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.reutershealth.com id j37GVV3x026180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable McDonald, Ira scripsit: > I don't believe that this quiet insertion of script between > language and region is harmless to RFC 3066 implementations. >=20 > It's true that such tags were allowed to be registered by > RFC 3066. But there are literally millions of documents=20 > currently language tagged on the Internet in the style of=20 > 'language-REGION-whatever' and lots of naive software thinks > that's the only valid form of a language tag. Buggy and nonconformant software, I think you mean. In any case, the expectation is that such tags will be relatively rare, and only used where needed. > The linguistic purity of infixing 'script' (between language > and region) is unwise. The recent (all unsuccessful) numeric=20 > weighting algorithms for 'smart matching' make this point=20 > eloquently. It's not linguistic purity, it's practicality. A language in a script yo= u can't read, like en-Brai, is much worse than one from a different region. --=20 H=EDggledy-p=ECggledy / XML programmers John Cowan Try to escape those / I-eighteen-N woes; http://www.ccil.org/~cowa= n Incontrovertibly / What we need more of is http://www.reutershealth.= com Unicode weenies and / Fran=E7ois Yergeaus. jcowan@reutershealth.co= m _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 12:34:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12197; Thu, 7 Apr 2005 12:34:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJa6X-0001af-Oo; Thu, 07 Apr 2005 12:43:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZrs-00008w-AV; Thu, 07 Apr 2005 12:28:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZrr-00008l-1V for ltru@megatron.ietf.org; Thu, 07 Apr 2005 12:28:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11243 for ; Thu, 7 Apr 2005 12:28:27 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJa0R-0001Et-Ft for ltru@ietf.org; Thu, 07 Apr 2005 12:37:23 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j37GSKh0011610; Thu, 7 Apr 2005 09:28:20 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Apr 2005 09:28:21 -0700 Message-ID: From: "McDonald, Ira" To: "'John Cowan'" , ltru@ietf.org Subject: RE: [Ltru] John Cowan's substantive comments on draft-ietf-ltru-r egistry-01 Date: Thu, 7 Apr 2005 09:28:16 -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: b8f3559805f7873076212d6f63ee803e X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Hi, My comments inline below. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of John Cowan > Sent: Wednesday, April 06, 2005 8:10 PM > To: ltru@ietf.org > Subject: [Ltru] John Cowan's substantive comments on > draft-ietf-ltru-registry-01 > > > Proposal registry-cowan-01: Alpha order in extension subtags > > CURRENT: Extension subtags MAY appear in any order in a language tag. > It is not clear whether the order matters, but probably not, since > tag canonicalization requires them to be sorted into case-insensitive > alphabetic order by singleton. > > PROPOSED: Require that extension subtags already be sorted > by singleton > order in well-formed tags. > > RATIONALE: Extension subtags are novel, so there is no previous > practice. Alphabeticalness of singletons is easy to check for. > Meaningless variability is reduced. > Agree - but only when a tag is claimed to be canonicalized (and we should recommend that applications display tags in canonicalized form for best understanding by mere humans). > > Proposal registry-cowan-02: Ban singleton "i" > > CURRENT: "i" MAY be used as a singleton in extension subtags. > > PROPOSED: "i" MUST NOT be used as a singleton. > > RATIONALE: The single-character subtag "i" is already used in > grandfathered tags in a different sense. Although mechanical > processes > will not confuse the two senses (grandfathered "i" is always initial, > singleton "i" is never initial), human beings may. Eliminating "i" > does not significantly reduce the space of singletons available for > registration. > Agree - simpler is better. > > Proposal registry-cowan-03: Ban singletons "y" and "z" > > CURRENT: "y" and "z" MAY be used as singletons in extension subtags. > > PROPOSED: "y" and "z" MUST NOT be used as singletons. > > RATIONALE: If cowan-registry-01 is accepted, then accepting > this proposal > as well would allow a simplification of well-formedness > checking in that > the singleton "x" in a non-initial position need not be > treated specially. > Otherwise, the canonical order is "a", "b", ..., "w", "y", "z", "x". > Eliminating "x" and "y" does not greatly reduce the space of > singletons > available for registration. > Agree - simpler is better - extension space is not at a premium. > > Proposal registry-cowan-04: Specify case rules for canonical tags > > CURRENT: Canonicalizing a tag does not affect the case of the letters > in it. > > PROPOSED: Canonicalizing a tag adjusts the case of the > letters as follows: > > 1) The first letter of a script subtag is upper case; 2) Both > letters of an alpha region subtag are upper case; 3) All other > letters are lower case. > > RATIONALE: These are the de facto canonicalization rules for ISO 639, > ISO 3166, and ISO 15924 codes. Since we have not had > canonical tags > before, there is no previous practice to contradict. The requirement > for case-insensitive matching may be eliminated if all tags > being matched > are known to be canonical. > Agree - but specify canonicalization as a display technique for applications and servers, not as a protocol requirement. > > Proposal registry-cowan-05: RFC 822 line wrapping in the registry > > CURRENT: Line wrapping is done with a trailing backslash. > > PROPOSED: Line wrapping is done by replacing a chosen sequence of > horizontal whitespace with a line terminator followed by horizontal > whitespace. (See RFC 2822 for specific text.) > > RATIONALE: Compatibility with RFC (2)822. > Agree - let's not reinvent RFC 2822. > > Proposal registry-cowan-06: Remove leading zeros from > character references > > CURRENT: Every character reference MUST contain at least four digits. > > PROPOSED: Character references MUST contain between one and six digits > inclusive. > > ALTERNATIVE: Character references MUST contain between one > and six digits > inclusive, and MUST NOT have leading zeros. > > RATIONALE: The proposal is compatible with XML. The > alternative proposal > is also compatible with XML and allows only one possible encoding for > each codepoint. > I prefer the Alternative best - I like only one possible encoding. > > Proposal registry-cowan-07: Remove private use tags from the registry > and sample registry. > > CURRENT: The private use codes of the ISO standards are included in > the registry. > > PROPOSED: Remove them from the registry. Also remove the concept of > value ranges from Section 3.1, which is needed only for > private use tags. > > RATIONALE: Private use tags are for private use, and private > agreements > about them do not scale. They ought not to be contained in a public > registry. Those who wish to use them can look at the RFC. > Let's keep them as ranges in the registry to make clear their use. > > Proposal registry-cowan-08: Simplify the language tag > registration form > > CURRENT: See Section 3.3. > > PROPOSED: The numbered items 1-3 and 4-8 should be replaced by > the following new or existing fields in the registry: Requester, > Requester-Email, Description, Meaning, Native-Name, > Reference, Comments. > > RATIONALE: These registration forms will not be readily available to > enquirers after the meaning of a specific language or variant tag. > Making sure that all the information is included in the registry is > therefore important, even at the cost of a larger registry. > Registered > languages will be very rare, and registered variants fairly > rare, based > on existing experience, so the cost will not be very great. > No - digital ink's not a sparse resource - experience with MIME, Charset, and other registries implies a more complete registration form is always better. Also, the actual registration form _is_ available online for every MIME type - why shouldn't these language tag forms also be online (but not in the Registry proper)? > -- > usage: mt [-v] [--version] [-h] [ -f device ] command [ count ] > A rabbi whose congregation doesn't want John Cowan > to drive him out of town isn't a rabbi, http://www.ccil.org/~cowan and a rabbi who lets them do it jcowan@reutershealth.com isn't a man. --Jewish saying http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 12:36:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12466; Thu, 7 Apr 2005 12:36:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJa7n-0001ek-K8; Thu, 07 Apr 2005 12:45:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZyt-0004ub-8m; Thu, 07 Apr 2005 12:35:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZyq-0004t3-WD for ltru@megatron.ietf.org; Thu, 07 Apr 2005 12:35:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12417 for ; Thu, 7 Apr 2005 12:35:41 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJa7R-0001dc-Kb for ltru@ietf.org; Thu, 07 Apr 2005 12:44:37 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 09:35:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Matching metrics Date: Thu, 7 Apr 2005 09:35:35 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFC88@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Matching metrics Thread-Index: AcU7QolZmkSDBxkVT7yR/KRgkAaxoQAS9RwA From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 07 Apr 2005 16:35:35.0744 (UTC) FILETIME=[D311AC00:01C53B8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0201731887==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 --===============0201731887== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGVyZSBpcyBubyBvbmUgc29sdXRpb24sIGJlY2F1c2Ugc29tZXRpbWVzIHNjcmlwdCB3aWxs IGJlIG1vcmUNCj4gaW1wb3J0YW50IHRoYW4gcmVnaW9uIGFuZCB2YXJpYW50LCBhbmQgc29tZXRp bWVzIG9uZSBvZiB0aGUgb3RoZXIgdHdvDQo+IHdpbGwgYmUgdGhlIG1vc3QgaW1wb3J0YW50LiAg VGhlIGNoYXJ0ZXIgYWNrbm93bGVkZ2VzIHRoaXM6ICJpdCBpcyBub3QNCj4gZXhwZWN0ZWQgdGhh dCBhbnkgc2luZ2xlIG1hdGNoaW5nIGFsZ29yaXRobSB3aWxsIGZpdCBhbGwgbmVlZHMuIg0KDQpS RkMgMzA2NiBhbHJlYWR5IHJlY29nbml6ZXMgdGhhdCBpdHMgaGllcmFyY2h5IGFuZCByZWFsIGxh bmd1YWdlcyBpbiB0aGUgd29ybGQgYXQgbGFyZ2UgbWF5IG5vdCBtYXAgc21vb3RobHkgdG9nZXRo ZXIuIFR3byBsYW5ndWFnZXMgdGhhdCBzaGFyZSBwcmVmaXhlcyBtYXkgbm90IGJlIG11dHVhbGx5 IGludGVsbGlnaWJsZSwgZm9yIGV4YW1wbGUuDQoNCldoaWxlIGl0IGlzIHBvc3NpYmxlIHRoYXQg YSBodW1hbiBiZWluZyBjYW4gbG9vayBhdCBhIGxhbmd1YWdlIHRhZyBhbmQgImludHVpdCIgdGhl IGF1dGhvcidzIGludGVuZGVkIG1lYW5pbmcgZnJvbSBpdCwgdGhpcyBpc24ndCBzb21ldGhpbmcg YW4gYWxnb3JpdGhtIGNhbiBkby4NCg0KSSB0aGluayB0aGF0IFJGQyAyNjE2IHByZWZpeCBtYXRj aGluZyBpcyBhY3R1YWxseSBzdWZmaWNpZW50IGZvciBtb3N0IG5lZWRzLiBJbnRyb2R1Y2luZyAi ZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2VzIiBjb3VwbGVkLCBwb3NzaWJseSwgd2l0aCBKb2huJ3Mg bWF0Y2hpbmcgc2NoZW1lIHdpbGwgaGVscCBlYXNlIHRoZSB0cmFuc2l0aW9uLCBidXQgaXQgaXNu J3Qgc3RyaWN0bHkgbmVjZXNzYXJ5LiBDb25zaWRlcjoNCg0KICBBY2NlcHQtTGFuZ3VhZ2U6IGVu LVVTOyBxPTEuMCwgZW4tTGF0bi1VUzsgcT0wLjkNCg0KWW91IGNhbiBkbyB0aGUgcmlnaHQgdGhp bmcgdXNpbmcgUkZDIDI2MTYgd2l0aG91dCBhbnkgZmFuY3kgd2lsZGNhcmRzIG9yIGV4cGFuc2lv bnMuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNo aXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENv cmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJl Lg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5j ZXNAbGlzdHMuaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBEb3VnIEV3ZWxsDQo+IFNlbnQ6IGpl dWRpIDcgYXZyaWwgMjAwNSAwMDoxNg0KPiBUbzogTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1Ympl Y3Q6IFtMdHJ1XSBSZTogTWF0Y2hpbmcgbWV0cmljcw0KPiANCj4gRnJhbmsgRWxsZXJtYW5uIDxu b2JvZHkgYXQgeHl6enkgZG90IGNsYXJhbmV0IGRvdCBkZT4gd3JvdGU6DQo+IA0KPiA+IEluIGNv bHVtbiAyIChlbi1HQi1zY291c2UpIGVuLUJyYWktR0Itc2NvdXNlIGJlYXRzDQo+ID4gZW4tR0It TGF0biBhbmQgZW4tTGF0bi1VUy1zY291c2UuDQo+IA0KPiBXZWxsLCBpdCBzaG91bGQsIHNob3Vs ZG4ndCBpdD8NCj4gDQo+IEpvaG4ncyBhbGdvcml0aG0gd2lsbCB3b3JrIGZpbmUgZm9yIHNvbWUg Y2FzZXMuICBZb3Vycywgd2l0aCB3ZWlnaHRzIG9mDQo+IDQtMy0xLTIgb3IgNC0yLTEtMyBvciB3 aGF0ZXZlciwgbWlnaHQgd29yayBiZXR0ZXIgaW4gc29tZSBjYXNlcyBhbmQgbm90DQo+IGFzIHdl bGwgaW4gb3RoZXJzLg0KPiANCj4gDQo+IC1Eb3VnIEV3ZWxsDQo+ICBGdWxsZXJ0b24sIENhbGlm b3JuaWENCj4gIGh0dHA6Ly91c2Vycy5hZGVscGhpYS5uZXQvfmRld2VsbC8NCj4gDQo+IA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRy dSBtYWlsaW5nIGxpc3QNCj4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --===============0201731887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0201731887==-- From ltru-bounces@ietf.org Thu Apr 7 12:45:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13501; Thu, 7 Apr 2005 12:45:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaGp-00020c-Mr; Thu, 07 Apr 2005 12:54:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJa7X-0002Lg-4D; Thu, 07 Apr 2005 12:44:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJa7V-0002Lb-4g for ltru@megatron.ietf.org; Thu, 07 Apr 2005 12:44:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13447 for ; Thu, 7 Apr 2005 12:44:37 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaG5-0001zW-3i for ltru@ietf.org; Thu, 07 Apr 2005 12:53:33 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j37GiQOX013048; Thu, 7 Apr 2005 09:44:27 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Apr 2005 09:44:27 -0700 Message-ID: From: "McDonald, Ira" To: "'John Cowan'" , ltru@ietf.org Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) Date: Thu, 7 Apr 2005 09:44:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Hi, Buggy and nonconformant? Most matching software dates to RFC 1766 days and the 'language-REGION' form was clearly the intended/expected style. I don't buy the importance of 'en-Brai' versus 'en-US-Brai'. Very few existing Internet resources are tagged with script. =20 Compatibility really is important.=20 Human users currently know that 'en-GB' _means_ 'en-Latn-GB', unless they've changed their browser options. Cheers, - Ira PS - I know I'm going to lose this argument, but I feel honor bound to point out the pain these script tags in the 'right' place are going to cause. All old matching software won't know what to do with them. And upgrading both servers and clients simultaneously (e.g, for LDAP directories in enterprises) will simply never happen. =20 Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] > Sent: Thursday, April 07, 2005 12:32 PM > To: McDonald, Ira > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) >=20 >=20 > McDonald, Ira scripsit: >=20 > > I don't believe that this quiet insertion of script between > > language and region is harmless to RFC 3066 implementations. > >=20 > > It's true that such tags were allowed to be registered by > > RFC 3066. But there are literally millions of documents=20 > > currently language tagged on the Internet in the style of=20 > > 'language-REGION-whatever' and lots of naive software thinks > > that's the only valid form of a language tag. >=20 > Buggy and nonconformant software, I think you mean. In any case, the > expectation is that such tags will be relatively rare, and only used > where needed. >=20 > > The linguistic purity of infixing 'script' (between language > > and region) is unwise. The recent (all unsuccessful) numeric=20 > > weighting algorithms for 'smart matching' make this point=20 > > eloquently. >=20 > It's not linguistic purity, it's practicality. A language in=20 > a script you > can't read, like en-Brai, is much worse than one from a=20 > different region. >=20 > --=20 > H=EDggledy-p=ECggledy / XML programmers John Cowan > Try to escape those / I-eighteen-N woes; =20 http://www.ccil.org/~cowan Incontrovertibly / What we need more of is = http://www.reutershealth.com Unicode weenies and / Fran=E7ois Yergeaus. = jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 12:54:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14011; Thu, 7 Apr 2005 12:54:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaPY-0002IU-Ui; Thu, 07 Apr 2005 13:03:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaCe-0003WP-AA; Thu, 07 Apr 2005 12:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaCc-0003WK-JO for ltru@megatron.ietf.org; Thu, 07 Apr 2005 12:49:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13818 for ; Thu, 7 Apr 2005 12:49:55 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaLD-0002Aa-BE for ltru@ietf.org; Thu, 07 Apr 2005 12:58:51 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j37GnbL2013469; Thu, 7 Apr 2005 09:49:42 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Apr 2005 09:49:38 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Doug Ewell , LTRU Working Group Subject: RE: [Ltru] Re: Matching metrics Date: Thu, 7 Apr 2005 09:49:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi, Inline. Cheers, - Ira > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Thursday, April 07, 2005 12:36 PM > To: Doug Ewell; LTRU Working Group > Subject: RE: [Ltru] Re: Matching metrics > > > > There is no one solution, because sometimes script will be more > > important than region and variant, and sometimes one of the > other two > > will be the most important. The charter acknowledges this: > "it is not > > expected that any single matching algorithm will fit all needs." > > RFC 3066 already recognizes that its hierarchy and real > languages in the world at large may not map smoothly > together. Two languages that share prefixes may not be > mutually intelligible, for example. > > While it is possible that a human being can look at a > language tag and "intuit" the author's intended meaning from > it, this isn't something an algorithm can do. > > I think that RFC 2616 prefix matching is actually sufficient > for most needs. Introducing "extended language ranges" > coupled, possibly, with John's matching scheme will help ease > the transition, but it isn't strictly necessary. Consider: > > Accept-Language: en-US; q=1.0, en-Latn-US; q=0.9 > > You can do the right thing using RFC 2616 without any fancy > wildcards or expansions. > But most browsers and servers still don't properly support 'q' factors. And most non-HTTP applications using language tags (or all?) don't have anything like 'Accept-Language' with 'q' factors. > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 12:57:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14153; Thu, 7 Apr 2005 12:57:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaSD-0002ND-00; Thu, 07 Apr 2005 13:06:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJa9x-0003Q1-Vb; Thu, 07 Apr 2005 12:47:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJa9x-0003Pw-4Z for ltru@megatron.ietf.org; Thu, 07 Apr 2005 12:47:13 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13667 for ; Thu, 7 Apr 2005 12:47:09 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJa6c-00038N-Uv for ltru@lists.ietf.org; Thu, 07 Apr 2005 18:43:46 +0200 Received: from c-134-89-44.hh.dial.de.ignite.net ([62.134.89.44]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 18:43:46 +0200 Received: from nobody by c-134-89-44.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 18:43:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 18:43:33 +0200 Organization: Lines: 35 Message-ID: <42556335.41FB@xyzzy.claranet.de> References: <425468F0.59C9@xyzzy.claranet.de> <046F43A8D79C794FA4733814869CDF0749C9AF@dul1wnexmb01.vcorp.ad.vrsn.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: c-134-89-44.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: updated editor's copies... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Scott Hollenbeck wrote: > Pay me now or pay me later Later could be less expensive, changing the reference in the XML source once when 2234bis got a number. And the xml2rfc output for I-Ds in an is rather ugly. I'm "almost sure "that the minor differences between 2234bis and 2234 are irrelevant for the LTRU ABNF. But "almost sure" is not necessarily good enough if it contains vague factors like "Bruce checked it". > new docs will not get approved by the IESG if you cite > obsolete specs. There's no serious problem with 2234, otherwise you'd be very busy to update numerous RfCs using the "old" ABNF. And it's not always illegal to cite old specs as normative reference: I could use 822 instead of 2822 (relevant here for the folding of registry lines - I've checked LWSP in 2234 and 2234bis, it's not what we need). Ok., 2243bis vs. 2234 is not exatly the same as 2822 vs. 822, because their status is different. For me that's all still "esoteric", like the fine points of "experimental RfCs" created by a WG vs. "experimental RfCs" as individual submission. Normally I'd prefer to say "RfC 2234" if that's what I checked, and not to pretend that I checked "2234bis" when that's simply not true. "Almost sure" can be very dangerous. In that case I risk it because I trust that Dave, you, and Bruce got it right. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 13:00:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14424; Thu, 7 Apr 2005 13:00:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaVN-0002Td-LP; Thu, 07 Apr 2005 13:09:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaBB-0003Tf-2K; Thu, 07 Apr 2005 12:48:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaBA-0003Ta-NP for ltru@megatron.ietf.org; Thu, 07 Apr 2005 12:48:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13731 for ; Thu, 7 Apr 2005 12:48:25 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaJl-00026t-Hi for ltru@ietf.org; Thu, 07 Apr 2005 12:57:21 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37GmJMi026267; Thu, 7 Apr 2005 12:48:19 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 12:48:18 -0400 Date: Thu, 7 Apr 2005 12:48:17 -0400 From: John Cowan To: "McDonald, Ira" Subject: Re: [Ltru] John Cowan's substantive comments on draft-ietf-ltru-r egistry-01 Message-ID: <20050407164817.GJ31242@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 McDonald, Ira scripsit: > > Proposal registry-cowan-01: Alpha order in extension subtags > > > > CURRENT: Extension subtags MAY appear in any order in a language tag. > > It is not clear whether the order matters, but probably not, since > > tag canonicalization requires them to be sorted into case-insensitive > > alphabetic order by singleton. > > > > PROPOSED: Require that extension subtags already be sorted > > by singleton > > order in well-formed tags. > > > > RATIONALE: Extension subtags are novel, so there is no previous > > practice. Alphabeticalness of singletons is easy to check for. > > Meaningless variability is reduced. > > Agree - but only when a tag is claimed to be canonicalized This is actually a disagreement. Currently canonicalized tags are required to use alpha order for extensions, tags in general are not. I'm proposing that we require alpha order in all cases, because there is no reason not to. "Provide every way, one way, or no way to do something." I'm recommending one way: alpha order. > (and we should recommend that applications display tags in > canonicalized form for best understanding by mere humans). Most of the time there is no reason to display language tags at all: properly localized language names make more sense. > No - digital ink's not a sparse resource - experience with MIME, > Charset, and other registries implies a more complete registration > form is always better. I am not recommending that the amount of data on the form be shrunk, merely that all that data be included in the registry as well. > Also, the actual registration form _is_ available online for every > MIME type - why shouldn't these language tag forms also be online > (but not in the Registry proper)? They will be, but will probably not be copied to all systems they way (we hope) the registry will be. -- De plichten van een docent zijn divers, John Cowan die van het gehoor ook. jcowan@reutershealth.com --Edsger Dijkstra http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 13:01:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14532; Thu, 7 Apr 2005 13:01:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaWL-0002VU-7R; Thu, 07 Apr 2005 13:10:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaN9-0004Iz-M6; Thu, 07 Apr 2005 13:00:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaN8-0004Ii-L7 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 13:00:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14474 for ; Thu, 7 Apr 2005 13:00:47 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaVV-0002Tc-6O for ltru@ietf.org; Thu, 07 Apr 2005 13:09:43 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j37H0KMh014482; Thu, 7 Apr 2005 10:00:25 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 7 Apr 2005 10:00:20 -0700 Message-ID: From: "McDonald, Ira" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: updated editor's copies... Date: Thu, 7 Apr 2005 10:00:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Hi, Tempest in a teapot - there are no substantive changes at all in , according to that document. Quoting from the Introduction: "Changes in the latest version of this Internet Draft: In Section 3.7 the phrase: "That is, exactly ?=E1occurrences of ." was correct to: "That is, exactly ?=E1occurrences of ." Some continuation comment lines needed to be corrected to begin with comment character (";")." (those non-ASCII are actually in this document, by the way). There is no appendix called 'Changes from RFC 2234' (which strikes me as unwise). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Frank Ellermann > Sent: Thursday, April 07, 2005 12:44 PM > To: ltru@ietf.org > Subject: [Ltru] Re: updated editor's copies... >=20 >=20 > Scott Hollenbeck wrote: >=20 > > Pay me now or pay me later >=20 > Later could be less expensive, changing the reference in the > XML source once when 2234bis got a number. And the xml2rfc > output for I-Ds in an is rather ugly. >=20 > <...snip...> >=20 > Bye, Frank >=20 > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 13:03:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14725; Thu, 7 Apr 2005 13:03:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaY5-0002Yp-Cy; Thu, 07 Apr 2005 13:12:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaOW-0004pG-R0; Thu, 07 Apr 2005 13:02:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaOV-0004p6-UH for ltru@megatron.ietf.org; Thu, 07 Apr 2005 13:02:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14618 for ; Thu, 7 Apr 2005 13:02:12 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaX5-0002Wc-LH for ltru@ietf.org; Thu, 07 Apr 2005 13:11:09 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37H24qa026336; Thu, 7 Apr 2005 13:02:05 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 13:02:09 -0400 Date: Thu, 7 Apr 2005 13:02:09 -0400 From: John Cowan To: "McDonald, Ira" Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Message-ID: <20050407170209.GK31242@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 McDonald, Ira scripsit: > Buggy and nonconformant? Most matching software dates to > RFC 1766 days and the 'language-REGION' form was clearly > the intended/expected style. Even in RFC 1766, language-tag processors had to be able to accept registered tags. The main difference between 1766 and 3066 is that 3066 allows 3-alpha ISO 639-2 subtags. Note that the differences can be huge: if you request zh content, you typically only want Mandarin, and if you get zh-yue instead, you will be in the same position as someone requesting fr and getting ro. > I don't buy the importance of 'en-Brai' versus 'en-US-Brai'. > Very few existing Internet resources are tagged with script. > Compatibility really is important. IIRC, Braille level 2 is actually different between en-US and en-GB in ways that interfere with intelligibility. (Level 1 Braille, just the letters, is compatible.) However, the intended application of script tags is in languages that are routinely written in more than one script. So far, this has either been pushed under the rug or handled (in the case of zh) by abusing the region code. Separating out script from region is essential for reliable discrimination in these cases. The vast majority of content will probably never use a tag that has a script subtag, and the overuse of subtags is specifically discouraged. > Human users currently know that 'en-GB' _means_ 'en-Latn-GB', > unless they've changed their browser options. Absolutely. It's the people who are trying to work in Azerbaijani that need to care about this. > PS - I know I'm going to lose this argument, but I feel > honor bound to point out the pain these script tags in > the 'right' place are going to cause. All old matching > software won't know what to do with them. And upgrading > both servers and clients simultaneously (e.g, for LDAP > directories in enterprises) will simply never happen. Most of the time it shouldn't need to happen. -- John Cowan jcowan@reutershealth.com www.reutershealth.com ccil.org/~cowan Dievas dave dantis; Dievas duos duonos --Lithuanian proverb Deus dedit dentes; deus dabit panem --Latin version thereof Deity donated dentition; deity'll donate doughnuts --English version by Muke Tever God gave gums; God'll give granary --Version by Mat McVeagh _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 13:06:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15153; Thu, 7 Apr 2005 13:06:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJabB-0002lY-P7; Thu, 07 Apr 2005 13:15:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaRG-0006OL-AO; Thu, 07 Apr 2005 13:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaRF-0006OG-5F for ltru@megatron.ietf.org; Thu, 07 Apr 2005 13:05:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14981 for ; Thu, 7 Apr 2005 13:05:01 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaZo-0002hF-PO for ltru@ietf.org; Thu, 07 Apr 2005 13:13:58 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 10:04:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) Date: Thu, 7 Apr 2005 10:04:49 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFCDA@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU7iNE5IsLV6mM2Qt63+82gTi5NyQACg/bQ From: "Addison Phillips" To: "McDonald, Ira" , "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 07 Apr 2005 17:04:50.0241 (UTC) FILETIME=[E8D4AB10:01C53B93] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1865079744==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 --===============1865079744== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW50ZXJsaW5lYXIgYmVsb3csIGVsaXNpb24gYXMgbmVjZXNzYXJ5Lg0KDQpBZGRpc29uIFAuIFBo aWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBX M0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9u YWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5p ZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxm IE9mIE1jRG9uYWxkLCBJcmENCj4gDQo+IA0KPiBJIGRvbid0IGJlbGlldmUgdGhhdCB0aGlzIHF1 aWV0IGluc2VydGlvbiBvZiBzY3JpcHQgYmV0d2Vlbg0KPiBsYW5ndWFnZSBhbmQgcmVnaW9uIGlz IGhhcm1sZXNzIHRvIFJGQyAzMDY2IGltcGxlbWVudGF0aW9ucy4NCltBZGRpc29uIFBoaWxsaXBz XSANCg0KSXQgaXMgaGFybWxlc3Mgc28gbG9uZyBhcyB1c2VycyBhbmQgY29udGVudCBhdXRob3Jz IHVuZGVyc3RhbmQgdGhlIHJhbWlmaWNhdGlvbnMgb2Ygc3RyaWN0IFJGQyAyNjE2IHByZWZpeCBt YXRjaGluZy4gQ29udGVudCBhdXRob3JzIHdobyBzdGFydCB0byB1c2Ugc2NyaXB0IHN1YnRhZ3Mg d2lsbCBoYXZlIHRvIGRlYWwgd2l0aCB0aGUgcG9zc2liaWxpdHkgdGhhdCBjZXJ0YWluIGltcGxl bWVudGF0aW9ucyB3aWxsIG5vdCBtYXRjaCBlLmcuICJlbi1MYXRuLVVTIiB0byBlLmcuIHRoZSBy YW5nZSAiZW4tVVMiLg0KPiANCj4gSXQncyB0cnVlIHRoYXQgc3VjaCB0YWdzIHdlcmUgYWxsb3dl ZCB0byBiZSByZWdpc3RlcmVkIGJ5DQo+IFJGQyAzMDY2LiAgQnV0IHRoZXJlIGFyZSBsaXRlcmFs bHkgbWlsbGlvbnMgb2YgZG9jdW1lbnRzDQo+IGN1cnJlbnRseSBsYW5ndWFnZSB0YWdnZWQgb24g dGhlIEludGVybmV0IGluIHRoZSBzdHlsZSBvZg0KPiAnbGFuZ3VhZ2UtUkVHSU9OLXdoYXRldmVy JyBhbmQgbG90cyBvZiBuYWl2ZSBzb2Z0d2FyZSB0aGlua3MNCj4gdGhhdCdzIHRoZSBvbmx5IHZh bGlkIGZvcm0gb2YgYSBsYW5ndWFnZSB0YWcuDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCk5hw692 ZSBpbXBsZW1lbnRhdGlvbnMgZ2VuZXJhbGx5IGFzc3VtZSAnbGFuZ3VhZ2UtUkVHSU9OJyBhbmQg bm90aGluZyBtb3JlLS1hbmQgbm8gcmVnaXN0cmF0aW9ucy4gVGhlc2Ugd2lsbCBoYXZlIHRoZSB0 cm91YmxlcyB0aGV5IGhhdmUuDQoNCk1vc3QgbmHDr3ZlIGltcGxlbWVudGF0aW9ucyBhY3R1YWxs eSBhc3N1bWUgbGlrZSBSRkMgMzY4OCBkb2VzOiBhIHNlcXVlbmNlIG9mIHN1YnRhZ3MgaW4gYSBz dHJpY3Qgb3JkZXIuIFNlZSBjb21tZW50IGFib3ZlIGZvciB3aHkgdGhvc2UgaW1wbGVtZW50YXRp b25zIGNhbiBiZSBkZWZlbmRlZCBhcyB2YWxpZCBhbmQgYXJlIG5vdCBicm9rZW4gYnkgMzA2NmJp cyBhcyBsb25nIGFzIHVzZXJzIGFuZCBjb250ZW50IGF1dGhvcnMgYWdyZWUgdG8gZWl0aGVyIHVz ZSBvciBub3QgdXNlIHRoZSBzY3JpcHQgc3VidGFncyBmb3IgYSBwYXJ0aWN1bGFyIGxhbmd1YWdl Lg0KDQo+IA0KPiBUaGUgbGluZ3Vpc3RpYyBwdXJpdHkgb2YgaW5maXhpbmcgJ3NjcmlwdCcgKGJl dHdlZW4gbGFuZ3VhZ2UNCj4gYW5kIHJlZ2lvbikgaXMgdW53aXNlLiAgVGhlIHJlY2VudCAoYWxs IHVuc3VjY2Vzc2Z1bCkgbnVtZXJpYw0KPiB3ZWlnaHRpbmcgYWxnb3JpdGhtcyBmb3IgJ3NtYXJ0 IG1hdGNoaW5nJyBtYWtlIHRoaXMgcG9pbnQNCj4gZWxvcXVlbnRseS4NCltBZGRpc29uIFBoaWxs aXBzXSANCg0KSXQgaXNuJ3QgImxpbmd1aXN0aWMgcHVyaXR5Ii4gTm8gb25lIGhhcyByZXNwb25k ZWQgdG8gdGhlIHBvaW50IHRoYXQgcHV0dGluZyBzY3JpcHQgbGFzdCBET0VTTidUIEZJWCBBTllU SElORzoNCg0KVGFnOiAgImVuLVVTLUxhdG4iDQpSYW5nZTogImVuLUxhdG4iDQoNClVoIG9oLg0K DQpUYWc6ICJ6aC1DTi1IYW5zIg0KUmFuZ2U6ICJ6aC1IYW5zIg0KDQpVaCBvaC4NCg0KSXQgZG9l c24ndCBtYXR0ZXIgd2hhdCBvcmRlciB5b3UgcGljaywgc29tZSB1c2VycyB3aWxsIGdldCByZXN1 bHRzIHRoYXQgZG9uJ3Qgd29yayBvdXQgdXNpbmcgc3RyaWN0IHByZWZpeCBtYXRjaGluZyBhcyBs b25nIGFzIHlvdSBhbGxvdyBzdWJ0YWdzIHRvIGJlIG9taXR0ZWQgKGFzIHdlIGRvKS4NCg0KVXNl cnMgYW5kIGNvbnRlbnQgYXV0aG9ycyB0aGF0IHVzZSBzY3JpcHQgd2lsbCBoYXZlIHRvIGRlY2lk ZS4gVXNpbmcgZXh0ZW5kZWQgbGFuZ3VhZ2UgcmFuZ2VzIHdpbGwgaGVscCBieSBtYWtpbmcgdGhl IG1hdGNoaW5nIHdvcmsgaW4gbW9yZSBjYXNlcy4NCg0KPiANCj4gPiBJcmEgTWNEb25hbGQgaGFk IHdyaXR0ZW46DQo+ID4NCj4gPiA+IEFsc28sIExUUlUgaXMgZGV2ZWxvcGluZyBhbiBJQU5BIHJl Z2lzdHJ5IG9mIEVWRVJZDQo+ID4gPiBwb3NzaWJsZSB2YWxpZCBsYW5ndWFnZSB0YWcuDQo+ID4N Cj4gPiBXZSdyZSBub3QgZG9pbmcgdGhhdCBlaXRoZXIuICBJbXBvcnRhbnQgZGlzdGluY3Rpb246 IHdlIGFyZQ0KPiA+IGRldmVsb3BpbmcgYQ0KPiA+IHJlZ2lzdHJ5IG9mIGV2ZXJ5IHBvc3NpYmxl IHZhbGlkICpzdWJ0YWcqLCBub3QgdGFnLiAgVGhlDQo+ID4gZm9ybWVyIGFkZHMgdXANCj4gPiB0 byBqdXN0IHVuZGVyIGEgdGhvdXNhbmQgaXRlbXM7IHRoZSBsYXR0ZXIgKGluY2x1ZGluZyBhbGwg dGhlDQo+ID4gcmlkaWN1bG91cw0KPiA+IG9uZXMpIHdvdWxkIGJlIGFib3V0IDE1IG1pbGxpb24u DQo+ID4NCj4gDQo+IE9vcHMhICBNeSBzaWxseSBtaXN0YWtlLiAgVGlyZWQgZmluZ2Vycy4NCj4g DQo+ID4gLURvdWcgRXdlbGwNCj4gPiAgRnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+ID4gIGh0dHA6 Ly91c2Vycy5hZGVscGhpYS5uZXQvfmRld2VsbC8NCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEx0cnUgbWFpbGlu ZyBsaXN0DQo+ID4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBs aXN0cy5pZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s dHJ1DQoNCg== --===============1865079744== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1865079744==-- From ltru-bounces@ietf.org Thu Apr 7 13:14:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15893; Thu, 7 Apr 2005 13:14:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJajJ-00035p-Ea; Thu, 07 Apr 2005 13:23:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaZm-0002CK-Rr; Thu, 07 Apr 2005 13:13:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaZk-0002CC-Ik for ltru@megatron.ietf.org; Thu, 07 Apr 2005 13:13:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15819 for ; Thu, 7 Apr 2005 13:13:49 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJaiK-00034e-CV for ltru@ietf.org; Thu, 07 Apr 2005 13:22:45 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37HDfmm026400; Thu, 7 Apr 2005 13:13:41 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 13:13:49 -0400 Date: Thu, 7 Apr 2005 13:13:49 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Message-ID: <20050407171349.GA9134@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFC68@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AEEFC68@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Addison Phillips scripsit: > Okay by me, but I'd prefer not to do this. It doesn't add anything > substantial either. Why make a few implementations that emit tags in > one case or another non-canonical? The point of canonicalization is to get rid of meaningless differences. Case is a meaningless difference. Let's get rid of it. Implementations that prefer not to smash case need not claim their tags are canonical. > Ditto. Notice that by putting a stake in the ground we can make progress... I have done so. > I strongly prefer entities that are regular in > form. The entity À is less obviously a Unicode value than the > entity À It's pretty obvious to me. But in that case, at least standardize on a fixed convention (at least four digits, five only if required, six only if required, say). > Fine by me. Practical questions: > > 1. Should the email be obfuscated? (addison dot phillips at quest dot com??) Up to the proposer, I'd say. > 2. Should it be an (ASCII) URI? In other words, how should IDN's be handled? URIs are ASCII by definition. I am not proposing an IRI. > 3. Reference is a text field naming documents. Should there be rules > for naming URIs? What other restrictions apply? Typically references are to books in hard copy: grammars, dictionaries, etc. > 4. Are the native name rules I have in the draft sufficient? I think so. -- On the Semantic Web, it's too hard to prove John Cowan jcowan@reutershealth.com you're not a dog. --Bill de hOra http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 13:15:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16028; Thu, 7 Apr 2005 13:15:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJajm-00036O-9Y; Thu, 07 Apr 2005 13:24:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaan-0002ac-7E; Thu, 07 Apr 2005 13:14:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaak-0002aV-Tb for ltru@megatron.ietf.org; Thu, 07 Apr 2005 13:14:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15929 for ; Thu, 7 Apr 2005 13:14:51 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJajK-00035b-Ue for ltru@ietf.org; Thu, 07 Apr 2005 13:23:48 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 10:14:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: updated editor's copies... Date: Thu, 7 Apr 2005 10:14:41 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFCEE@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: updated editor's copies... Thread-Index: AcU7k2hRD4q7Aw/aQzqeWUwq/Uyd0QAAZrkQ From: "Addison Phillips" To: "McDonald, Ira" , "Frank Ellermann" , X-OriginalArrivalTime: 07 Apr 2005 17:14:44.0026 (UTC) FILETIME=[4AC111A0:01C53B95] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable I have updated the reference in my off-line copy. The next posting of = the editor's copy (which I'll announce, so don't go look at it now) will = contain the new reference. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of McDonald, Ira > Sent: jeudi 7 avril 2005 10:00 > To: 'Frank Ellermann'; ltru@ietf.org > Subject: RE: [Ltru] Re: updated editor's copies... >=20 > Hi, >=20 > Tempest in a teapot - there are no substantive changes at all in > , according to that document. >=20 > Quoting from the Introduction: >=20 > "Changes in the latest version of this Internet Draft: >=20 > In Section 3.7 the phrase: "That is, exactly ?=E1occurrences of > ." was correct to: "That is, exactly ?=E1occurrences of > ." >=20 > Some continuation comment lines needed to be corrected to begin > with comment character (";")." >=20 > (those non-ASCII are actually in this document, by the way). >=20 > There is no appendix called 'Changes from RFC 2234' (which strikes > me as unwise). >=20 > Cheers, > - Ira >=20 > 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 >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of Frank Ellermann > > Sent: Thursday, April 07, 2005 12:44 PM > > To: ltru@ietf.org > > Subject: [Ltru] Re: updated editor's copies... > > > > > > Scott Hollenbeck wrote: > > > > > Pay me now or pay me later > > > > Later could be less expensive, changing the reference in the > > XML source once when 2234bis got a number. And the xml2rfc > > output for I-Ds in an is rather ugly. > > > > <...snip...> > > > > Bye, Frank > > > > >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 13:25:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16661; Thu, 7 Apr 2005 13:25:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJatJ-0003RO-OM; Thu, 07 Apr 2005 13:34:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJagv-0003PF-38; Thu, 07 Apr 2005 13:21:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJagt-0003PA-Uk for ltru@megatron.ietf.org; Thu, 07 Apr 2005 13:21:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16374 for ; Thu, 7 Apr 2005 13:21:12 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJapS-0003Hj-07 for ltru@ietf.org; Thu, 07 Apr 2005 13:30:09 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Thu, 07 Apr 2005 13:21:03 -0400 id 005900A8.42556BFF.00000F83 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'McDonald, Ira'" , "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: updated editor's copies... Date: Thu, 7 Apr 2005 13:20:42 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749C9B7@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit > There is no appendix called 'Changes from RFC 2234' (which strikes > me as unwise). Yes there is. It's at the end of section 1. The approval announcement included a note to the RFC Editor requesting a change of "Changes in the latest version of this Internet Draft:" to "Changes Since RFC 2234:". -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 13:26:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16812; Thu, 7 Apr 2005 13:26:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJav2-0003Tm-WD; Thu, 07 Apr 2005 13:35:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJalx-0003cN-9A; Thu, 07 Apr 2005 13:26:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJalv-0003cI-Ps for ltru@megatron.ietf.org; Thu, 07 Apr 2005 13:26:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16771 for ; Thu, 7 Apr 2005 13:26:24 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJauW-0003T8-Qi for ltru@ietf.org; Thu, 07 Apr 2005 13:35:21 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 10:26:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Date: Thu, 7 Apr 2005 10:26:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFD0B@irvmbxw01.quest.com> Thread-Topic: [Ltru] John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Thread-Index: AcU7lS+aqa1PN/0eSCC+l6L1xGmEWwAAFNpA From: "Addison Phillips" To: "John Cowan" X-OriginalArrivalTime: 07 Apr 2005 17:26:18.0177 (UTC) FILETIME=[E8801B10:01C53B96] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable > > 2. Should it be an (ASCII) URI? In other words, how should IDN's be > handled? >=20 > URIs are ASCII by definition. I am not proposing an IRI. You're not, but it is rapidly becoming reflexive for me to do so (he = said, nudging his W3C chair's hat back and then switching to the = editor's hat). How about if I put in the appropriate reference to = Section 3.1 of RFC 3987 (that is, requiring that non-ASCII values in an = IRI be mapped to a URI according to the rules therein and not for = example using some other random legacy encoding, etc.)? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] > Sent: jeudi 7 avril 2005 10:14 > To: Addison Phillips > Cc: Mark Davis; ltru@ietf.org > Subject: Re: [Ltru] John Cowan's substantive = commentsondraft-ietf-ltru- > registry-01 >=20 > Addison Phillips scripsit: >=20 > > Okay by me, but I'd prefer not to do this. It doesn't add anything > > substantial either. Why make a few implementations that emit tags in > > one case or another non-canonical? >=20 > The point of canonicalization is to get rid of meaningless = differences. > Case > is a meaningless difference. Let's get rid of it. Implementations = that > prefer not to smash case need not claim their tags are canonical. >=20 > > Ditto. Notice that by putting a stake in the ground we can make > progress... >=20 > I have done so. >=20 > > I strongly prefer entities that are regular in > > form. The entity À is less obviously a Unicode value than the > > entity À >=20 > It's pretty obvious to me. But in that case, at least standardize on > a fixed convention (at least four digits, five only if required, six > only if required, say). >=20 > > Fine by me. Practical questions: > > > > 1. Should the email be obfuscated? (addison dot phillips at quest = dot > com??) >=20 > Up to the proposer, I'd say. >=20 > > 2. Should it be an (ASCII) URI? In other words, how should IDN's be > handled? >=20 > URIs are ASCII by definition. I am not proposing an IRI. >=20 > > 3. Reference is a text field naming documents. Should there be rules > > for naming URIs? What other restrictions apply? >=20 > Typically references are to books in hard copy: grammars, = dictionaries, > etc. >=20 > > 4. Are the native name rules I have in the draft sufficient? >=20 > I think so. >=20 > -- > On the Semantic Web, it's too hard to prove John Cowan > jcowan@reutershealth.com > you're not a dog. --Bill de hOra = http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 13:28:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16982; Thu, 7 Apr 2005 13:28:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJawR-0003Yl-G0; Thu, 07 Apr 2005 13:37:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaiV-0003TR-7Q; Thu, 07 Apr 2005 13:22:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJaiT-0003TL-K0 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 13:22:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16491 for ; Thu, 7 Apr 2005 13:22:50 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime01.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJar3-0003Ly-Hf for ltru@ietf.org; Thu, 07 Apr 2005 13:31:46 -0400 Received: from eupig1 (unverified) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 7 Apr 2005 17:22:38 +0000 Message-ID: Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IEL00A3E6XP1Z@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 07 Apr 2005 17:22:37 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Thu, 07 Apr 2005 18:22:36 +0100 Date: Thu, 07 Apr 2005 18:22:36 +0100 From: Misha Wolf Subject: RE: [Ltru] John Cowan's substantive commentsondraft-ietf-ltru-registry-01 To: ltru@ietf.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Thread-Index: AcU7lUuienWRci0IQVGlhhRy77RoBAAAPPYg content-class: urn:content-classes:message X-OriginalArrivalTime: 07 Apr 2005 17:22:37.0047 (UTC) FILETIME=[64B25870:01C53B96] X-Spam-Score: 0.8 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable > I strongly prefer entities that are regular in > form. The entity À is less obviously a Unicode value than the > entity À *Please* let's follow the XML rules rather than invent our own. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 13:52:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19139; Thu, 7 Apr 2005 13:52:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbJr-0004PM-6d; Thu, 07 Apr 2005 14:01:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbAt-0001kj-4G; Thu, 07 Apr 2005 13:52:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJatS-0007Bx-MZ for ltru@megatron.ietf.org; Thu, 07 Apr 2005 13:34:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17491 for ; Thu, 7 Apr 2005 13:34:11 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJb22-0003lV-Qd for ltru@ietf.org; Thu, 07 Apr 2005 13:43:08 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=ISO-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMRWPF54IO00005R@mauve.mrochek.com> for ltru@ietf.org; Thu, 07 Apr 2005 10:34:07 -0700 (PDT) Date: Thu, 07 Apr 2005 10:22:35 -0700 (PDT) In-reply-to: "Your message dated Thu, 07 Apr 2005 09:44:26 -0700" Message-id: <01LMT5FFC4MO00005R@mauve.mrochek.com> References: Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) To: McDonald Ira X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Thu, 07 Apr 2005 13:52:14 -0400 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7BIT > Buggy and nonconformant? Most matching software dates to > RFC 1766 days and the 'language-REGION' form was clearly > the intended/expected style. > I don't buy the importance of 'en-Brai' versus 'en-US-Brai'. > Very few existing Internet resources are tagged with script. > Compatibility really is important. > Human users currently know that 'en-GB' _means_ 'en-Latn-GB', > unless they've changed their browser options. > Cheers, > - Ira > PS - I know I'm going to lose this argument, but I feel > honor bound to point out the pain these script tags in > the 'right' place are going to cause. All old matching > software won't know what to do with them. And upgrading > both servers and clients simultaneously (e.g, for LDAP > directories in enterprises) will simply never happen. As you might expect, I am in complete agreement with Ira here. This break with backwards compatibility is going to cause a bunch of problems. I also find the assertion that implementations done in good faith to what was specified in RFC 1766 are "buggy and nonconformant" to be a bit disturbing. Speaking as a coauthor of MIME, I know better than most what sorts of compromises are required to make things backwards compatible. But having watched various attempts to do multimedia email prior to MIME fail due in large part to their lack of backwards compatibility, I also know what can happen if you don't hit the sweet spot on these matters. Balkanization of how language tags are used is the last thing we want, and I think this is where we're going to end up if we break compatibility. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 13:53:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19247; Thu, 7 Apr 2005 13:53:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbKX-0004R5-0N; Thu, 07 Apr 2005 14:02:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbB3-0001op-8H; Thu, 07 Apr 2005 13:52:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbB1-0001ok-Bh for ltru@megatron.ietf.org; Thu, 07 Apr 2005 13:52:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19132 for ; Thu, 7 Apr 2005 13:52:20 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbJc-0004P3-Ll for ltru@ietf.org; Thu, 07 Apr 2005 14:01:16 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37HqD8j026629; Thu, 7 Apr 2005 13:52:14 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 13:52:16 -0400 Date: Thu, 7 Apr 2005 13:52:16 -0400 From: John Cowan To: ned.freed@mrochek.com Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Message-ID: <20050407175216.GE9134@skunk.reutershealth.com> References: <01LMT5FFC4MO00005R@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01LMT5FFC4MO00005R@mauve.mrochek.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb ned.freed@mrochek.com scripsit: > As you might expect, I am in complete agreement with Ira here. This break with > backwards compatibility is going to cause a bunch of problems. I also find the > assertion that implementations done in good faith to what was specified in RFC > 1766 are "buggy and nonconformant" to be a bit disturbing. Implementing RFC 1766 while ignoring IANA-registered tags is about like implementing C while ignoring the "goto" statement. Most programs compile. > Speaking as a coauthor of MIME, I know better than most what sorts of > compromises are required to make things backwards compatible. But having > watched various attempts to do multimedia email prior to MIME fail due in large > part to their lack of backwards compatibility, I also know what can happen if > you don't hit the sweet spot on these matters. The only way to ensure 100% backward compatibility is to change nothing. Putting the script subtag after the region subtag exchanges one incompatibility for another, as Doug points out. What is more, we already have some language-script-region tags registered under RFC 3066 (IANA hasn't posted them yet), so it's a fait accompli. > Balkanization of how language tags are used is the last thing we want, and I > think this is where we're going to end up if we break compatibility. We are not breaking compatibility. -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com And now here I was, in a country where a right to say how the country should be governed was restricted to six persons in each thousand of its population. For the nine hundred and ninety-four to express dissatisfaction with the regnant system and propose to change it, would have made the whole six shudder as one man, it would have been so disloyal, so dishonorable, such putrid black treason. --Mark Twain's Connecticut Yankee _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 14:12:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22215; Thu, 7 Apr 2005 14:12:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbcn-00058N-Fb; Thu, 07 Apr 2005 14:21:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbTa-000899-Qe; Thu, 07 Apr 2005 14:11:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbTZ-000894-B8 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 14:11:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22166 for ; Thu, 7 Apr 2005 14:11:31 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbc9-00057W-LE for ltru@ietf.org; Thu, 07 Apr 2005 14:20:27 -0400 Received: from uknsprd1 (unverified) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 7 Apr 2005 18:11:20 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IEL00B1X96VIG@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 07 Apr 2005 19:11:19 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Thu, 07 Apr 2005 18:11:19 +0000 Date: Thu, 07 Apr 2005 19:11:19 +0100 From: Misha Wolf Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) To: ltru@ietf.org Message-id: <1987416CA83AC7499AC772F92E2DBF78037C9771@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU7mq0+KQz6pPDtRr6g9/0F3BJ8EgAAQ/wQ content-class: urn:content-classes:message X-OriginalArrivalTime: 07 Apr 2005 18:11:19.0838 (UTC) FILETIME=[32D0DBE0:01C53B9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Consider the "zh" case. Existing practice is a mess: zh-cn zh-hk zh-mo zh-sg zh-tw zh [from IE 6] It's up to each user to guess what the tagger meant by each of these=20 tags. If a user wants just Simplified Chinese what should s/he request? =20 If s/he wants just Traditional Chinese what should s/he request? If we replace the above mess with zh-Hans and zh-Hant, the situation=20 becomes much clearer. As far as legacy tags matched by legacy applications are concerned,=20 in both cases, if the user requests "zh" they will get the lot and=20 it's up to them to select. It's true that such an application won't=20 match zh-Hant with zh-TW, but that seems like a price worth paying. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 14:13:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22308; Thu, 7 Apr 2005 14:13:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbe9-0005CQ-Ae; Thu, 07 Apr 2005 14:22:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbUC-0008Ak-4y; Thu, 07 Apr 2005 14:12:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbUA-0008A2-Ss for ltru@megatron.ietf.org; Thu, 07 Apr 2005 14:12:11 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22211 for ; Thu, 7 Apr 2005 14:12:08 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJbQC-0008Jf-Qs for ltru@lists.ietf.org; Thu, 07 Apr 2005 20:08:05 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 20:08:04 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 20:08:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 19:57:52 +0200 Organization: Lines: 48 Message-ID: <425574A0.3B09@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFC68@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: quoted-printable Subject: [Ltru] Re: John Cowan's substantive commentsondraft-ietf-ltru-registry-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Addison Phillips wrote: [character references] > I don't care, but I strongly prefer entities that are regular > in form. The entity À is less obviously a Unicode value > than the entity À Let's use up to C048. It says "use hex." (C045, C048) and "one form" (C043). We can use John's "no leading zeros" or your "4 or 6 digits", but we better don't allow both. Your format is not very nice for cases like R=E9union and C=F4te, and John's format is odd for an odd number of hex. digits. The syntax for your format would be somewhat simpler: hrc =3D "&#x" ( h4 / h5 / h6 ) ";" h4 =3D hex hex hex hex h5 =3D "0" hex h4 h6 =3D "10" h4 hex =3D DIGIT / "A" / "B" / "C" / "D" / "E" / "F" Whatever we do, let's not encode ";" or other printable ASCII characters, unless it's "&" (& or & resp.) [Registration details] > 1. Should the email be obfuscated? (addison dot phillips at > quest dot com??) Yes. > 2. Should it be an (ASCII) URI? In other words, how should > IDN's be handled? As specified in RfC 3987, or are you talking about Martin's mailto I-D ? I vaguely recall some unanswered questions about the latter on the URI list. > 3. Reference is a text field naming documents. Should there > be rules for naming URIs? What other restrictions apply? Are angle brackets not good enough, or what is the problem ? Just in case. Actually I don't like the proposal to add all registration details to the registry. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 14:26:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23507; Thu, 7 Apr 2005 14:26:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbqK-0005cI-1e; Thu, 07 Apr 2005 14:35:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbgV-00017z-VU; Thu, 07 Apr 2005 14:24:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJbgU-00017t-1J for ltru@megatron.ietf.org; Thu, 07 Apr 2005 14:24:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23404 for ; Thu, 7 Apr 2005 14:24:52 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJbp5-0005ak-Ea for ltru@ietf.org; Thu, 07 Apr 2005 14:33:47 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 11:24:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Date: Thu, 7 Apr 2005 11:24:40 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFD99@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Thread-Index: AcU7nYaVwnqdqIM2SfuyhiuduM8gcAAACptQ From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 07 Apr 2005 18:24:41.0771 (UTC) FILETIME=[10CE1FB0:01C53B9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable See inline. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: jeudi 7 avril 2005 10:58 > To: ltru@ietf.org > Subject: [Ltru] Re: John Cowan's substantive = commentsondraft-ietf-ltru- > registry-01 >=20 > Addison Phillips wrote: >=20 > [character references] > > I don't care, but I strongly prefer entities that are regular > > in form. The entity À is less obviously a Unicode value > > than the entity À >=20 > Let's use up to C048. It > says "use hex." (C045, C048) and "one form" (C043).=20 [Addison Phillips]=20 Yes, of course. But that doesn't make any different here. > We can use > John's "no leading zeros" or your "4 or 6 digits", but we better > don't allow both. [Addison Phillips]=20 Per general consensus so far, I changed the text to follow XML = explicitly. >=20 > Your format is not very nice for cases like R=E9union and C=F4te, > and John's format is odd for an odd number of hex. digits. > The syntax for your format would be somewhat simpler: >=20 > hrc =3D "&#x" ( h4 / h5 / h6 ) ";" > h4 =3D hex hex hex hex > h5 =3D "0" hex h4 > h6 =3D "10" h4 > hex =3D DIGIT / "A" / "B" / "C" / "D" / "E" / "F" >=20 > Whatever we do, let's not encode ";" or other printable ASCII > characters, unless it's "&" (& or & resp.) [Addison Phillips]=20 The text now says: Characters from outside the US-ASCII repertoire, as well as the = following characters when they occur inside a value: ":" (%x3A), "&" = (%x26), "\" (%x5C), and "%" (%x25) are represented by a "Numeric = Character Reference" using hexadecimal notation in the style used by = XML 1.0 (see = ). This consists of the sequence "&#x" (%x26%x23%x78) followed by a = hexadecimal representation of the character's code point in ISO/IEC 10646 followed by a closing semicolon = (%x3B). For example, the EURO SIGN, U+20AC, would be represented by the = sequence "&#x20AC;". Note that the hexadecimal notation may have = between two and six digits. I require these escapes: COLON (the name/value separator, can remove this, just being overly = cautious) AMPERSAND (the escape character) REVERSE SOLIDUS (the continuation character; can remove if we go with = the other continuation syntax) PERCENT SIGN (half of an end-of-record character as a courtesy to = badly written parsers everywhere: this one can be junked) >=20 > [Registration details] > > 1. Should the email be obfuscated? (addison dot phillips at > > quest dot com??) >=20 > Yes. >=20 > > 2. Should it be an (ASCII) URI? In other words, how should > > IDN's be handled? >=20 > As specified in RfC 3987, or are you talking about Martin's > mailto I-D ? I vaguely recall some unanswered questions about > the latter on the URI list. [Addison Phillips]=20 Yep. >=20 > > 3. Reference is a text field naming documents. Should there > > be rules for naming URIs? What other restrictions apply? >=20 > Are angle brackets not good enough, or what is the problem ? [Addison Phillips]=20 RFC 3987 or RFC 3986? Angle brackets are good enough to indicate an IRI. >=20 > Just in case. Actually I don't like the proposal to add all > registration details to the registry. >=20 [Addison Phillips]=20 Which would you put in and which leave out? _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 14:46:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25675; Thu, 7 Apr 2005 14:46:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJc9l-0006Md-HF; Thu, 07 Apr 2005 14:55:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJc0c-0007mA-Gi; Thu, 07 Apr 2005 14:45:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJc0a-0007m5-9x for ltru@megatron.ietf.org; Thu, 07 Apr 2005 14:45:40 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25593 for ; Thu, 7 Apr 2005 14:45:38 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJbwR-0005bT-Sx for ltru@lists.ietf.org; Thu, 07 Apr 2005 20:41:24 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 20:41:23 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 20:41:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 20:40:56 +0200 Organization: Lines: 7 Message-ID: <42557EB7.46EC@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: John Cowan's substantive commentsondraft-ietf-ltru-registry-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Misha Wolf wrote: > *Please* > let's follow the XML rules rather than invent our own. That's Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 15:04:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27610; Thu, 7 Apr 2005 15:04:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJcR2-0006yL-S6; Thu, 07 Apr 2005 15:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcGR-0001mH-6j; Thu, 07 Apr 2005 15:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcGO-0001mA-Qu for ltru@megatron.ietf.org; Thu, 07 Apr 2005 15:02:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27402 for ; Thu, 7 Apr 2005 15:01:58 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJcOx-0006tU-SE for ltru@ietf.org; Thu, 07 Apr 2005 15:10:55 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37J1mEM027033; Thu, 7 Apr 2005 15:01:48 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 15:01:51 -0400 Date: Thu, 7 Apr 2005 15:01:50 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] Re: John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Message-ID: <20050407190150.GD9631@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFD99@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AEEFD99@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Addison Phillips scripsit: > I require these escapes: > > COLON (the name/value separator, can remove this, just being overly cautious) > AMPERSAND (the escape character) > REVERSE SOLIDUS (the continuation character; can remove if we go with the other continuation syntax) > PERCENT SIGN (half of an end-of-record character as a courtesy to badly written parsers everywhere: this one can be junked) Junk all but the ampersand, I say. -- John Cowan jcowan@reutershealth.com http://www.ccil.org/~cowan O beautiful for patriot's dream that sees beyond the years Thine alabaster cities gleam undimmed by human tears! America! America! God mend thine every flaw, Confirm thy soul in self-control, thy liberty in law! -- one of the verses not usually taught in U.S. schools _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 15:18:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29342; Thu, 7 Apr 2005 15:18:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJcev-0007NI-9e; Thu, 07 Apr 2005 15:27:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcVb-0006eI-Aw; Thu, 07 Apr 2005 15:17:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcVZ-0006eD-VY for ltru@megatron.ietf.org; Thu, 07 Apr 2005 15:17:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29232 for ; Thu, 7 Apr 2005 15:17:38 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJce9-0007MH-W2 for ltru@ietf.org; Thu, 07 Apr 2005 15:26:35 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJcVR-0005VN-00 for ltru@ietf.org; Thu, 07 Apr 2005 12:17:33 -0700 Message-ID: <00be01c53ba6$a2b7eda0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 7 Apr 2005 12:18:52 -0700 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: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ltru] Using RT to view ltru issues X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi - To access the issue tracker, use the URL https://rt.psg.com To find out how to use it, use the URL http://rt.psg.com That same page will also tell you what username and password to use if you haven't been assigned one. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 15:19:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29461; Thu, 7 Apr 2005 15:19:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJcfz-0007Qg-Gr; Thu, 07 Apr 2005 15:28:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcWU-0006hs-G9; Thu, 07 Apr 2005 15:18:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcWS-0006hn-P4 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 15:18:37 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29371 for ; Thu, 7 Apr 2005 15:18:34 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJcTC-0002mj-QQ for ltru@lists.ietf.org; Thu, 07 Apr 2005 21:15:14 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 21:15:14 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 21:15:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 21:13:53 +0200 Organization: Lines: 37 Message-ID: <42558671.1AB4@xyzzy.claranet.de> References: <01LMT5FFC4MO00005R@mauve.mrochek.com> <20050407175216.GE9134@skunk.reutershealth.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.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit John Cowan wrote: > The only way to ensure 100% backward compatibility is to > change nothing. IMHO that's wrong, MIME is ingenious (excl. 2231). > Putting the script subtag after the region subtag exchanges > one incompatibility for another, as Doug points out. If it makes no big difference for 3066bis implementations and helps 3066 implementations I'd like it. Or if it's better for the interoperability of "old" (all) and "new" (future) implementations. > What is more, we already have some language-script-region > tags registered under RFC 3066 (IANA hasn't posted them yet), > so it's a fait accompli. That's no argument, "not-yet-posted" grandfathered tags could be deprecated and replaced by a better solution, there won't be millions of say iu-Cans pages. > We are not breaking compatibility. Maybe we're not breaking it radically enough - pretending that all is fine where in fact the new scheme has problems with the old scheme. I'd be interested to see different schemes like Debbie's 639-4. Maybe it's better than this obscure "don't use script tags unless you must, but we don't tell you when you must and when you shouldn't" (= no default script) rule. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 15:32:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00312; Thu, 7 Apr 2005 15:32:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJcsH-0007o2-1o; Thu, 07 Apr 2005 15:41:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJceD-0008My-Bq; Thu, 07 Apr 2005 15:26:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJceB-0008Mt-PC for ltru@megatron.ietf.org; Thu, 07 Apr 2005 15:26:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00031 for ; Thu, 7 Apr 2005 15:26:33 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJcmm-0007cB-Td for ltru@ietf.org; Thu, 07 Apr 2005 15:35:30 -0400 Received: from eupig1 (unverified) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 7 Apr 2005 19:26:21 +0000 Message-ID: Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IEL00C74CNXI3@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 07 Apr 2005 19:26:21 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Thu, 07 Apr 2005 20:26:20 +0100 Date: Thu, 07 Apr 2005 20:26:20 +0100 From: Misha Wolf Subject: RE: [Ltru] Compatibility with existing use (LDAP) To: ltru@ietf.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Compatibility with existing use (LDAP) Thread-Index: AcU7prZ43ApH4i/vTISU4clzkiODpgAAEJiA content-class: urn:content-classes:message X-OriginalArrivalTime: 07 Apr 2005 19:26:20.0922 (UTC) FILETIME=[ADABC5A0:01C53BA7] X-Spam-Score: 0.8 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Frank Ellermann wrote:=20 > > Putting the script subtag after the region subtag exchanges > > one incompatibility for another, as Doug points out. >=20 > If it makes no big difference for 3066bis implementations and > helps 3066 implementations I'd like it. It would break access to resources using new tags (eg zh-Han?) when=20 faced with applications which use remove-from-right matching. Many (most?) applications use and will continue to use such matching. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 15:32:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00333; Thu, 7 Apr 2005 15:32:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJcsJ-0007o6-9Q; Thu, 07 Apr 2005 15:41:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJch4-0008P5-GA; Thu, 07 Apr 2005 15:29:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJch3-0008P0-5d for ltru@megatron.ietf.org; Thu, 07 Apr 2005 15:29:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00154 for ; Thu, 7 Apr 2005 15:29:31 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJcpe-0007jg-9n for ltru@ietf.org; Thu, 07 Apr 2005 15:38:27 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJcgz-0001ji-00; Thu, 07 Apr 2005 12:29:29 -0700 Message-ID: <00c201c53ba8$4d08e420$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Date: Thu, 7 Apr 2005 12:30:47 -0700 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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: rt+ltru-registry@rt.psg.com Subject: [Ltru] Re: [psg.com #872]: are grandfathered tags allowed to have canonical value? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi - (co-chair hat on) In http://www1.ietf.org/mail-archive/web/ltru/current/msg00010.html I think the WG consensus is YES, grandfathered tags are indeed allowed to have a canonical value. If there are no serious objections, the editors should make any appropriate changes and we'll mark this issue "resolved". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 15:33:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00487; Thu, 7 Apr 2005 15:33:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJctm-0007sl-RB; Thu, 07 Apr 2005 15:42:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJckV-0000E5-PG; Thu, 07 Apr 2005 15:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJckU-0000Dz-SM for ltru@megatron.ietf.org; Thu, 07 Apr 2005 15:33:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00423 for ; Thu, 7 Apr 2005 15:33:04 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJct5-0007p5-Vm for ltru@ietf.org; Thu, 07 Apr 2005 15:42:01 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJckQ-0002wZ-00; Thu, 07 Apr 2005 12:33:02 -0700 Message-ID: <00c701c53ba8$cc4a67e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Date: Thu, 7 Apr 2005 12:34:21 -0700 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: cf4fa59384e76e63313391b70cd0dd25 Cc: rt+ltru-registry@rt.psg.com Subject: [Ltru] Re: [psg.com #873]: wording about grandfathered tags' canonical values inconsistent X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi - (co-chair hat ON) In http://www1.ietf.org/mail-archive/web/ltru/current/msg00010.html it was observer that the wording about grandfathered tags' canonical values was inconsistent. I believe there is consensus to make the wording consistent, and the editors should make the necessary changes based on the mailing list discussion. If there is no serious objection, we'll mark this issue "resolved". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 15:36:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00826; Thu, 7 Apr 2005 15:36:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJcwo-00081J-Qt; Thu, 07 Apr 2005 15:45:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcmm-00012b-DC; Thu, 07 Apr 2005 15:35:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcml-00012W-8s for ltru@megatron.ietf.org; Thu, 07 Apr 2005 15:35:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00672 for ; Thu, 7 Apr 2005 15:35:24 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJcvK-0007vJ-4a for ltru@ietf.org; Thu, 07 Apr 2005 15:44:21 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37JZET2027254; Thu, 7 Apr 2005 15:35:14 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 15:35:21 -0400 Date: Thu, 7 Apr 2005 15:35:21 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Message-ID: <20050407193520.GB10046@skunk.reutershealth.com> References: <01LMT5FFC4MO00005R@mauve.mrochek.com> <20050407175216.GE9134@skunk.reutershealth.com> <42558671.1AB4@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42558671.1AB4@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Frank Ellermann scripsit: > > The only way to ensure 100% backward compatibility is to > > change nothing. > > IMHO that's wrong, MIME is ingenious (excl. 2231). How so? Pre-MIME MUAs will display rubbish when sent MIME messages, and nothing can stop it. > > Putting the script subtag after the region subtag exchanges > > one incompatibility for another, as Doug points out. > > If it makes no big difference for 3066bis implementations and > helps 3066 implementations I'd like it. It does make a big difference: incompatible script is much worse than incompatible region, as you yourself pointed out in a different connection. 3066 implementations will not be helped, because it's already the case under existing 3066 tags that a request for az-Cyrl will not match az-AZ. > Or if it's better for the interoperability of "old" (all) and > "new" (future) implementations. > > > What is more, we already have some language-script-region > > tags registered under RFC 3066 (IANA hasn't posted them yet), > > so it's a fait accompli. > > That's no argument, "not-yet-posted" grandfathered tags could > be deprecated and replaced by a better solution, there won't > be millions of say iu-Cans pages. There won't be millions of az-Arab or az-Latn pages either. > > We are not breaking compatibility. > > Maybe we're not breaking it radically enough - pretending that > all is fine where in fact the new scheme has problems with the > old scheme. I'd be interested to see different schemes like > Debbie's 639-4. 639-6, you mean. No fallback at all: each language variety has a four-letter tag, and you *have* to have the fallback tables to interpret one that you don't know directly. > Maybe it's better than this obscure "don't use script tags > unless you must, but we don't tell you when you must and when > you shouldn't" (= no default script) rule. Not the same thing. Perhaps we should indeed add a non-normative Recommended_Script field to those few languages that will normally use script tags. -- Long-short-short, long-short-short / Dactyls in dimeter, Verse form with choriambs / (Masculine rhyme): jcowan@reutershealth.com One sentence (two stanzas) / Hexasyllabically http://www.reutershealth.com Challenges poets who / Don't have the time. --robison who's at texas dot net _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 15:44:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01302; Thu, 7 Apr 2005 15:44:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJd4S-0008Dh-TO; Thu, 07 Apr 2005 15:53:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJctL-0001zu-JK; Thu, 07 Apr 2005 15:42:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJctL-0001zp-4I for ltru@megatron.ietf.org; Thu, 07 Apr 2005 15:42:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01094 for ; Thu, 7 Apr 2005 15:42:12 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJd1w-00088N-VB for ltru@ietf.org; Thu, 07 Apr 2005 15:51:09 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJctI-00061e-00; Thu, 07 Apr 2005 12:42:12 -0700 Message-ID: <00e401c53baa$14100340$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Date: Thu, 7 Apr 2005 12:43:31 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: rt+ltru-registry@rt.psg.com Subject: [Ltru] Re: [psg.com #874] propagation of parent organization deprecations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - In messages http://www1.ietf.org/mail-archive/web/ltru/current/msg00011.html http://www1.ietf.org/mail-archive/web/ltru/current/msg00025.html it was suggested that codes deprecated by their parent organizations should also be deprecated in the registry. It seems that the discussion of this point evolved into discussions of dealing with legacy data, tracking the dates of deprecations, and several other questions. Would someone like to take a stab at making a concise statement of consensus on the basic question of how to deal with deprecations, both past and future? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 15:48:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01661; Thu, 7 Apr 2005 15:48:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJd7n-0008LS-JY; Thu, 07 Apr 2005 15:57:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcyU-000497-JA; Thu, 07 Apr 2005 15:47:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJcyT-000492-2c for ltru@megatron.ietf.org; Thu, 07 Apr 2005 15:47:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01571 for ; Thu, 7 Apr 2005 15:47:30 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJd75-0008K3-0Y for ltru@ietf.org; Thu, 07 Apr 2005 15:56:27 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJcyQ-0007j4-00; Thu, 07 Apr 2005 12:47:30 -0700 Message-ID: <00e901c53baa$d18d3aa0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Date: Thu, 7 Apr 2005 12:48:49 -0700 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 Cc: rt+ltru-initial@rt.psg.com Subject: [Ltru] Re: [psg.com #875] should initial registry contents be made into an internet-draft? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi - (co-chair hat ON) The question of whether the initial registry contents should be posted as an internet draft (not to be confused with the question of publication as an RFC) was raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00013.html The discussion hasn't shown overwhelming support or opposition, but I believe that there is a rough consensus to post the initial registry contents in an i-d. I'd like to get confirmation or this reading, so if you have strong arguments pro or contra, now is the time to make them before we mark this issue "resolved". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 15:59:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02631; Thu, 7 Apr 2005 15:59:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdIj-0000Rx-FI; Thu, 07 Apr 2005 16:08:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJd9M-00074X-8f; Thu, 07 Apr 2005 15:58:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJd9K-00073I-9a for ltru@megatron.ietf.org; Thu, 07 Apr 2005 15:58:46 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02607 for ; Thu, 7 Apr 2005 15:58:43 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJd68-0000xi-CH for ltru@lists.ietf.org; Thu, 07 Apr 2005 21:55:28 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 21:55:28 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 21:55:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 21:55:13 +0200 Organization: Lines: 56 Message-ID: <42559021.6FFE@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFD99@irvmbxw01.quest.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.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: John Cowan's substantive commentsondraft-ietf-ltru-registry-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > I changed the text to follow XML explicitly. Why do you use XML 1.0 3rd ed. instead of XML 1.1 ? I'm only curious, is apparently the same as or your > COLON (the name/value separator, can remove this Get rid of it, header names and header bodies are separated by the first colon in a (2)822 header field. > REVERSE SOLIDUS (the continuation character Unnecessary for normal RfC 2822 folding (= FWS minus obs-FWS). > PERCENT SIGN (half of an end-of-record character as a > courtesy to badly written parsers everywhere: this one can > be junked) Then junk it, & is enough. >> As specified in RfC 3987, or are you talking about Martin's >> mailto I-D ? I vaguely recall some unanswered questions >> about the latter on the URI list. > Yep. First part or second part ? For the second part Martin is the expert, I only asked him about some details in his mailto I-D. And his Archived-At I-D, some problems to grok 3986 on my side. >> Are angle brackets not good enough, or what is the problem ? > RFC 3987 or RFC 3986? Angle brackets are good enough to > indicate an IRI. If you'd want to enforce an URL you could say - but AFAiK that's never necessary for today's URLs, if you're not trying to use some very obscure legacy ftp-URLs. For 3987 it's simply IDNA + %-encoded UTF-8, Sorry, I probably miss your point. [registration details] > Which would you put in and which leave out? What Doug has plus an URL to the IANA registration file, e.g. URI: John said that this is only relevant for variants, therfore we probably don't need relative URLs to compresss the registry. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 16:07:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03345; Thu, 7 Apr 2005 16:07:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdQP-0000kb-G2; Thu, 07 Apr 2005 16:16:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdHM-00084g-Qn; Thu, 07 Apr 2005 16:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdHM-00084b-AS for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:07:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03281 for ; Thu, 7 Apr 2005 16:07:01 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdPx-0000j1-Tn for ltru@ietf.org; Thu, 07 Apr 2005 16:15:59 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 13:06:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: [psg.com #875] should initial registry contents be madeinto an internet-draft? Date: Thu, 7 Apr 2005 13:06:48 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFE8E@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #875] should initial registry contents be madeinto an internet-draft? Thread-Index: AcU7qrr+oM8sKv6GTXWODcaautBq6gAAie8Q From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 07 Apr 2005 20:06:49.0423 (UTC) FILETIME=[552B9DF0:01C53BAD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: rt+ltru-initial@rt.psg.com X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable It is apparently an accepted practice, so I'm okay with it. I think it = is somewhat silly, personally, since turning the registry file into the = I-D format strikes me as a waste of time. Certainly a file can be under = revision control without being an ID. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: jeudi 7 avril 2005 12:49 > To: LTRU Working Group > Cc: rt+ltru-initial@rt.psg.com > Subject: [Ltru] Re: [psg.com #875] should initial registry contents be > madeinto an internet-draft? >=20 > Hi - >=20 > (co-chair hat ON) >=20 > The question of whether the initial registry contents should be posted = as > an internet draft (not to be confused with the question of publication = as > an RFC) was raised in > http://www1.ietf.org/mail-archive/web/ltru/current/msg00013.html >=20 > The discussion hasn't shown overwhelming support or opposition, but > I believe that there is a rough consensus to post the initial registry > contents > in an i-d. I'd like to get confirmation or this reading, so if you = have > strong arguments pro or contra, now is the time to make them before > we mark this issue "resolved". >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 16:08:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03400; Thu, 7 Apr 2005 16:08:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdR2-0000lU-1i; Thu, 07 Apr 2005 16:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdCE-0007sb-8v; Thu, 07 Apr 2005 16:01:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdCD-0007sW-8i for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:01:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02803 for ; Thu, 7 Apr 2005 16:01:42 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdKp-0000X5-Le for ltru@ietf.org; Thu, 07 Apr 2005 16:10:40 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 13:01:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Compatibility with existing use (LDAP) Date: Thu, 7 Apr 2005 13:01:34 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFE84@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU7pq+/bi3Jan+tSkqlNU8pNoyyNwABHc8g From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 07 Apr 2005 20:01:34.0863 (UTC) FILETIME=[99AD91F0:01C53BAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable > Maybe it's better than this obscure "don't use script tags > unless you must, but we don't tell you when you must and when > you shouldn't" (=3D no default script) rule. How about a useful compromise? We seem to be going around in circles = with no way out. It seems to me that our options are limited if we need = scripts (and we do).=20 In thinking about how you might move scripts down towards the end of the = tag, one of the thoughts I had was: gee, if scripts were just variants, = then we could put a Recommended Prefix on them. Hmm... a recommended prefix... What if we put Recommended Prefix fields onto script subtags in the = registry?=20 This solves the default script problem because we are recommending when = to use the subtag (when your language is in the list for that subtag).=20 We don't have to identify them all on Day One, since we can add prefixes = for those we don't know over time using registration. Guidance can be = provided that script recommended prefixes should usually be added in = groups of two or more (that is, you don't want a prefix for a specific = language unless the language is commonly written in more than on = script).=20 It doesn't break 3066 processing (still), but does help these = implementations by having users avoid creating tags such as "en-Latn-US" = that don't have much additional utility. It doesn't break implementations that choose, wisely or unwisely, to = implement those tags either. For example, if using the Brai/Latn subtag = pair with "en-*-US" is sensible for a certain application, then it isn't = forbidden and works with 3066-like implementations as long as users = realize that they must be consistent in the body of work. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: jeudi 7 avril 2005 12:14 > To: ltru@ietf.org > Subject: [Ltru] Re: Compatibility with existing use (LDAP) >=20 > John Cowan wrote: >=20 > > The only way to ensure 100% backward compatibility is to > > change nothing. >=20 > IMHO that's wrong, MIME is ingenious (excl. 2231). >=20 > > Putting the script subtag after the region subtag exchanges > > one incompatibility for another, as Doug points out. >=20 > If it makes no big difference for 3066bis implementations and > helps 3066 implementations I'd like it. >=20 > Or if it's better for the interoperability of "old" (all) and > "new" (future) implementations. >=20 > > What is more, we already have some language-script-region > > tags registered under RFC 3066 (IANA hasn't posted them yet), > > so it's a fait accompli. >=20 > That's no argument, "not-yet-posted" grandfathered tags could > be deprecated and replaced by a better solution, there won't > be millions of say iu-Cans pages. >=20 > > We are not breaking compatibility. >=20 > Maybe we're not breaking it radically enough - pretending that > all is fine where in fact the new scheme has problems with the > old scheme. I'd be interested to see different schemes like > Debbie's 639-4. >=20 > Maybe it's better than this obscure "don't use script tags > unless you must, but we don't tell you when you must and when > you shouldn't" (=3D no default script) rule. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 16:17:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04126; Thu, 7 Apr 2005 16:17:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJda9-00013m-Hx; Thu, 07 Apr 2005 16:26:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdNu-0002WH-24; Thu, 07 Apr 2005 16:13:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdNs-0002Vy-2P for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:13:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03795 for ; Thu, 7 Apr 2005 16:13:45 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdWU-0000wW-PW for ltru@ietf.org; Thu, 07 Apr 2005 16:22:43 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJdNr-0004aG-0x; Thu, 07 Apr 2005 20:13:47 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #876 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Thu, 07 Apr 2005 20:13:47 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #876] what whould the format of the initial registry be? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - (Co-chair hat ON) It looks like we have a rough consensus to use record-jar format for the initial registry. Any serious objections? If not, we'll mark this issue "resolved". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 16:17:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04168; Thu, 7 Apr 2005 16:17:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdaa-00014E-1A; Thu, 07 Apr 2005 16:26:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdNu-0002WN-7q; Thu, 07 Apr 2005 16:13:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdNs-0002W5-Rq for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:13:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03798 for ; Thu, 7 Apr 2005 16:13:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdWU-0000wV-HH for ltru@ietf.org; Thu, 07 Apr 2005 16:22:43 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJdNq-0004aB-Lh for ltru@ietf.org; Thu, 07 Apr 2005 20:13:46 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #876 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Thu, 07 Apr 2005 20:13:46 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #876] what whould the format of the initial registry be? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - (Co-chair hat ON) It looks like we have a rough consensus to use record-jar format for the initial registry. Any serious objections? If not, we'll mark this issue "resolved". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 16:18:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04219; Thu, 7 Apr 2005 16:18:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdat-00014z-QY; Thu, 07 Apr 2005 16:27:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdQ6-0002hd-QU; Thu, 07 Apr 2005 16:16:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdQ5-0002hY-NI for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:16:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03957 for ; Thu, 7 Apr 2005 16:16:03 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdYi-00011E-AX for ltru@ietf.org; Thu, 07 Apr 2005 16:25:00 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 13:15:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: John Cowan's substantivecommentsondraft-ietf-ltru-registry-01 Date: Thu, 7 Apr 2005 13:15:55 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFE9B@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: John Cowan's substantivecommentsondraft-ietf-ltru-registry-01 Thread-Index: AcU7rF6CmNXmFMRGTgefSZxlLsw/wAAASCBQ From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 07 Apr 2005 20:15:56.0513 (UTC) FILETIME=[9B42ED10:01C53BAE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable See below. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: jeudi 7 avril 2005 12:55 > To: ltru@ietf.org > Subject: [Ltru] Re: John Cowan's substantivecommentsondraft-ietf-ltru- > registry-01 >=20 > Addison Phillips wrote: >=20 > > I changed the text to follow XML explicitly. >=20 > Why do you use XML 1.0 3rd ed. instead of XML 1.1 ? I'm only > curious, is apparently > the same as or your > [Addison Phillips]=20 No reason, except that XML 1.1 is slightly controversial as XML 1.0 is = not. Personally, I support XML 1.1 and would reference it, except that = there isn't any real difference. For that matter, we don't have to = reference it at all, since we fully describe the format here. The = reference I inserted is merely informative and not normative. >=20 > > COLON (the name/value separator, can remove this >=20 > Get rid of it, header names and header bodies are separated by > the first colon in a (2)822 header field. [Addison Phillips]=20 Gone. >=20 > > REVERSE SOLIDUS (the continuation character >=20 > Unnecessary for normal RfC 2822 folding (=3D FWS minus obs-FWS). [Addison Phillips]=20 I don't personally like the RFC 2822 folding. I'll be guided by = consensus on this topic, but as long as the draft includes line wrapping = in my preferred style :-) we should escape the continuation character. >=20 > > PERCENT SIGN (half of an end-of-record character as a > > courtesy to badly written parsers everywhere: this one can > > be junked) >=20 > Then junk it, & is enough. [Addison Phillips]=20 Junked. >=20 > >> As specified in RfC 3987, or are you talking about Martin's > >> mailto I-D ? I vaguely recall some unanswered questions > >> about the latter on the URI list. >=20 > > Yep. >=20 > First part or second part ? For the second part Martin is the > expert, I only asked him about some details in his mailto I-D. > And his Archived-At I-D, some problems to grok 3986 on my side. [Addison Phillips]=20 As specified in 3987. The mailto I-D is new and not fully baked. Never = mind, let me plop some text in and we'll review it. >=20 > >> Are angle brackets not good enough, or what is the problem ? >=20 > > RFC 3987 or RFC 3986? Angle brackets are good enough to > > indicate an IRI. >=20 > If you'd want to enforce an URL you could say > - but AFAiK that's never necessary for today's URLs, if you're > not trying to use some very obscure legacy ftp-URLs. For 3987 > it's simply IDNA + %-encoded UTF-8, Sorry, I probably miss > your point. [Addison Phillips]=20 Actually for 3987, it is JUST %-encoded UTF-8. Don't worry about it. = I'll write some text and let everyone comment on it. Much more = productive. >=20 > [registration details] > > Which would you put in and which leave out? >=20 > What Doug has plus an URL to the IANA registration file, e.g. > URI: >=20 > John said that this is only relevant for variants, therfore we > probably don't need relative URLs to compresss the registry. [Addison Phillips]=20 It isn't relevant for just variants any more. All changes will be = forwarded using the process. New assignments of the type 'variant' will = have registration forms, but other changes can be requested (prefixes, = comments, deprecations, etc.) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 16:20:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04344; Thu, 7 Apr 2005 16:20:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdck-00019n-PF; Thu, 07 Apr 2005 16:29:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdTv-00045G-97; Thu, 07 Apr 2005 16:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdTu-00045B-08 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:20:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04307 for ; Thu, 7 Apr 2005 16:19:59 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdcV-00018v-GB for ltru@ietf.org; Thu, 07 Apr 2005 16:28:56 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37KJpoR027453; Thu, 7 Apr 2005 16:19:51 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 16:19:51 -0400 Date: Thu, 7 Apr 2005 16:19:51 -0400 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] Re: [psg.com #874] propagation of parent organization deprecations Message-ID: <20050407201951.GD10046@skunk.reutershealth.com> References: <00e401c53baa$14100340$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00e401c53baa$14100340$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Randy Presuhn scripsit: > It seems that the discussion of this point evolved into discussions of > dealing with legacy data, tracking the dates of deprecations, and several > other questions. Would someone like to take a stab at making a > concise statement of consensus on the basic question of how to deal > with deprecations, both past and future? Here's my attempt: 1) When a code is deprecated before Date A, it never gets into the registry at all. 2) When a code is deprecated between Dates A and B, and a replacement code is provided, the new code goes into the registry as canonical, and the old code goes into the registry as deprecated with the canonical form given. 3) When a code is deprecated between Dates A and B, and a replacement code is not provided, the old code goes into the registry as deprecated with no canonical form. 4) When a code is deprecated after Date B, and a replacement code is provided, the old code remains unchanged in the registry, and the new code goes into the registry as deprecated with the canonical form given. 5) When a code is deprecated after Date B, and a replacement code is not provided, the old code remains unchanged in the registry. This does not address the question of what happens when the new code is a recycled old code. -- Mos Eisley spaceport. You will never John Cowan see a more wretched hive of scum and jcowan@reutershealth.com villainy -- unless you watch the http://www.ccil.org/~cowan Jerry Springer Show. --georgettesworld.com http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 16:24:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04697; Thu, 7 Apr 2005 16:24:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdhC-0001Jo-0j; Thu, 07 Apr 2005 16:33:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdXE-0004M2-C4; Thu, 07 Apr 2005 16:23:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdXD-0004Lx-8t for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:23:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04593 for ; Thu, 7 Apr 2005 16:23:24 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdfp-0001FS-2r for ltru@ietf.org; Thu, 07 Apr 2005 16:32:22 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37KNGbr027487; Thu, 7 Apr 2005 16:23:17 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 16:23:20 -0400 Date: Thu, 7 Apr 2005 16:23:20 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Message-ID: <20050407202320.GE10046@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFE84@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AEEFE84@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Addison Phillips scripsit: > What if we put Recommended Prefix fields onto script subtags in the > registry? > > This solves the default script problem because we are recommending when > to use the subtag (when your language is in the list for that subtag). Excellent! So Latn would have a Recommended Prefix of az (among others) but not en. We might want Brai to have a recommended prefix of *, since brai could be attached to almost any language, or at least any language that is written. -- Mark Twain on Cecil Rhodes: John Cowan I admire him, I freely admit it, http://www.ccil.org/~cowan and when his time comes I shall http://www.reutershealth.com buy a piece of the rope for a keepsake. jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 16:32:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05158; Thu, 7 Apr 2005 16:32:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdoK-0001Wc-12; Thu, 07 Apr 2005 16:41:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdex-0005Sx-Mv; Thu, 07 Apr 2005 16:31:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdew-0005Ss-Uh for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:31:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05122 for ; Thu, 7 Apr 2005 16:31:24 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdnZ-0001VW-Eo for ltru@ietf.org; Thu, 07 Apr 2005 16:40:21 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 13:30:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Compatibility with existing use (LDAP) Date: Thu, 7 Apr 2005 13:30:55 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFEAE@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU7r6jd7hjwlnceSJaOCF0BirD23AAALyeQ From: "Addison Phillips" To: "John Cowan" X-OriginalArrivalTime: 07 Apr 2005 20:30:56.0320 (UTC) FILETIME=[B3969400:01C53BB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Yes, exactly so. For the Brai case, I don't think that's necessary. A script without a = Recommended Prefix can be used to form any subtag with no constraint on = validating processors. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] > Sent: jeudi 7 avril 2005 13:23 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) >=20 > Addison Phillips scripsit: >=20 > > What if we put Recommended Prefix fields onto script subtags in the > > registry? > > > > This solves the default script problem because we are recommending = when > > to use the subtag (when your language is in the list for that = subtag). >=20 > Excellent! So Latn would have a Recommended Prefix of az (among = others) > but > not en. >=20 > We might want Brai to have a recommended prefix of *, since brai could = be > attached to almost any language, or at least any language that is = written. >=20 > -- > Mark Twain on Cecil Rhodes: John Cowan > I admire him, I freely admit it, = http://www.ccil.org/~cowan > and when his time comes I shall > http://www.reutershealth.com > buy a piece of the rope for a keepsake. = jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 16:37:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05705; Thu, 7 Apr 2005 16:37:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdt1-0001iE-4O; Thu, 07 Apr 2005 16:46:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdfx-0005XP-V7; Thu, 07 Apr 2005 16:32:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdfv-0005VZ-Lf for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:32:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05189 for ; Thu, 7 Apr 2005 16:32:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdoY-0001XF-FZ for ltru@ietf.org; Thu, 07 Apr 2005 16:41:22 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJdfu-00074o-IP; Thu, 07 Apr 2005 20:32:26 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #877 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 20:32:26 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #877] move section (appendix C) on registry initialization to IANA considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi - (co-chair hat ON) I haven't seen any discussion of http://www1.ietf.org/mail-archive/web/ltru/current/msg00015.html If there are no objections, the editors will move the material on registry initialization (subject to any other modifications per other issues), and we'll mark this issue "resolved". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 16:37:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05740; Thu, 7 Apr 2005 16:37:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdtV-0001iU-ML; Thu, 07 Apr 2005 16:46:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdfx-0005XE-Qk; Thu, 07 Apr 2005 16:32:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdfw-0005WI-AI for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:32:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05192 for ; Thu, 7 Apr 2005 16:32:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJdoY-0001XE-6Q for ltru@ietf.org; Thu, 07 Apr 2005 16:41:23 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJdfu-00074h-6D for ltru@ietf.org; Thu, 07 Apr 2005 20:32:26 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #877 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 20:32:26 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #877] move section (appendix C) on registry initialization to IANA considerations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi - (co-chair hat ON) I haven't seen any discussion of http://www1.ietf.org/mail-archive/web/ltru/current/msg00015.html If there are no objections, the editors will move the material on registry initialization (subject to any other modifications per other issues), and we'll mark this issue "resolved". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 16:45:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06371; Thu, 7 Apr 2005 16:45:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJe11-0001x3-D1; Thu, 07 Apr 2005 16:54:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdrY-00008t-0w; Thu, 07 Apr 2005 16:44:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdrU-00008F-Jq for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:44:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06273 for ; Thu, 7 Apr 2005 16:44:22 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJe05-0001v7-Ax for ltru@ietf.org; Thu, 07 Apr 2005 16:53:19 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 13:44:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: [psg.com #874] propagation of parent organizationdeprecations Date: Thu, 7 Apr 2005 13:44:10 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFEC6@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #874] propagation of parent organizationdeprecations Thread-Index: AcU7r0pxUIZvMgu0Tje9bq3g5VmiMAAACKHw From: "Addison Phillips" To: "John Cowan" , "Randy Presuhn" X-OriginalArrivalTime: 07 Apr 2005 20:44:11.0034 (UTC) FILETIME=[8D464FA0:01C53BB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable One small clarification and a difference: Clarification: The draft already deals with collisions of new = assignments with existing entries (deprecated or not). A withdrawal = coupled with an assignment is TWO actions by the standards body, = separately considered. Rules govern both actions independently (i.e. if = Code A is withdrawn in favor of Code B and Code B already exists as = Subtag B, Code A remains and is canonical, Subtag B remains and is = canonical/deprecated as it sits with no changes and Code B is not = inserted). Difference: At present the editor's copy is different from #4 below, in = that it allows a code to be deprecated when it is withdrawn. This would = have an effect on stability of validation (in that a currently = non-deprecated tag can become deprecated) but not on stability of = validity (the tag is still valid and is in canonical form). Another way to look at this is: Previously we had only one field, "Canonical", and it served both for = mapping and indicating deprecation.=20 Now we have TWO fields, "Canonical" and "Deprecated" and these can be = assigned independently and have separate stability guarantees. Thus a subtag can be deprecated (because it was withdrawn) without = mapping it to a new tag. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: jeudi 7 avril 2005 13:20 > To: Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: [psg.com #874] propagation of parent > organizationdeprecations >=20 > Randy Presuhn scripsit: >=20 > > It seems that the discussion of this point evolved into discussions = of > > dealing with legacy data, tracking the dates of deprecations, and > several > > other questions. Would someone like to take a stab at making a > > concise statement of consensus on the basic question of how to deal > > with deprecations, both past and future? >=20 > Here's my attempt: >=20 > 1) When a code is deprecated before Date A, it never gets into the > registry at all. >=20 > 2) When a code is deprecated between Dates A and B, and a replacement = code > is provided, the new code goes into the registry as canonical, and the = old > code goes into the registry as deprecated with the canonical form = given. >=20 >=20 > 3) When a code is deprecated between Dates A and B, and a replacement > code is not provided, the old code goes into the registry as = deprecated > with no canonical form. >=20 > 4) When a code is deprecated after Date B, and a replacement code is > provided, the old code remains unchanged in the registry, and the new > code goes into the registry as deprecated with the canonical form = given. >=20 > 5) When a code is deprecated after Date B, and a replacement code is > not provided, the old code remains unchanged in the registry. >=20 > This does not address the question of what happens when the new code = is a > recycled old code. >=20 > -- > Mos Eisley spaceport. You will never John Cowan > see a more wretched hive of scum and = jcowan@reutershealth.com > villainy -- unless you watch the = http://www.ccil.org/~cowan > Jerry Springer Show. --georgettesworld.com > http://www.reutershealth.com >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 16:53:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06904; Thu, 7 Apr 2005 16:53:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJe8e-0002FU-L9; Thu, 07 Apr 2005 17:02:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdzP-0002EL-IA; Thu, 07 Apr 2005 16:52:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJdzJ-0002CR-IZ for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:52:29 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06863 for ; Thu, 7 Apr 2005 16:52:26 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJdwA-0000ne-UT for ltru@lists.ietf.org; Thu, 07 Apr 2005 22:49:14 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 22:49:14 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 22:49:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 22:49:43 +0200 Organization: Lines: 21 Message-ID: <42559CE7.2010@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Misha Wolf wrote: > It would break access to resources using new tags (eg > zh-Han?) when faced with applications which use > remove-from-right matching. > Many (most?) applications use and will continue to > use such matching. Let's say that all "old" implementations try RTL expecting lang-region-more-stuff. So that's by definition hopeless, we can only pray that they understand at least lang-region. But "new" implementations are "new" and not forced to use RTL if we say that it's a bad idea for lang-region-script. Or in John's terms we could say 8-2-4-1 instead of 8-4-2-1 for new implementations and a lang-region-script-variant(s) scheme. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:02:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07694; Thu, 7 Apr 2005 17:02:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeHw-0002YJ-IB; Thu, 07 Apr 2005 17:11:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJe7w-0003JT-0n; Thu, 07 Apr 2005 17:01:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJe7u-0003JJ-VX for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:01:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07617 for ; Thu, 7 Apr 2005 17:01:20 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeGY-0002Wg-3s for ltru@ietf.org; Thu, 07 Apr 2005 17:10:18 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJe7t-000B1q-UU; Thu, 07 Apr 2005 21:01:21 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #879 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:01:21 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #879] clarify "i-default" and "und" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi - (co-chair hat ON) This issue was raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00029.html I believe there is a rough consensus to clarify, see http://www1.ietf.org/mail-archive/web/ltru/current/msg00036.html The editors should make the appropriate edits, and we can mark this issue "resolved" Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:05:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07887; Thu, 7 Apr 2005 17:05:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeKn-0002e6-Ms; Thu, 07 Apr 2005 17:14:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeAl-0003Tf-Qn; Thu, 07 Apr 2005 17:04:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeAj-0003TJ-Ts for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:04:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07803 for ; Thu, 7 Apr 2005 17:04:15 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeJN-0002c5-2w for ltru@ietf.org; Thu, 07 Apr 2005 17:13:13 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeAi-000BJR-Sq for ltru@ietf.org; Thu, 07 Apr 2005 21:04:16 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #880 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:04:16 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #880] fix ABNF bugs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi - (co-chair hat ON) Some ABNF problems were identified in the thread starting at http://www1.ietf.org/mail-archive/web/ltru/current/msg00074.html I believe there is a rough consensus to fix these, per http://www1.ietf.org/mail-archive/web/ltru/current/msg00075.html and as confirmed in http://www1.ietf.org/mail-archive/web/ltru/current/msg00084.html When the editors have made the appropriate edits, we can mark this issue "resolved". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:06:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08026; Thu, 7 Apr 2005 17:06:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeLi-0002im-9u; Thu, 07 Apr 2005 17:15:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCE-0003hm-Lz; Thu, 07 Apr 2005 17:05:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCD-0003hR-Ag for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:05:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07923 for ; Thu, 7 Apr 2005 17:05:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeKq-0002eG-Eg for ltru@ietf.org; Thu, 07 Apr 2005 17:14:44 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeCC-000BX3-7M for ltru@ietf.org; Thu, 07 Apr 2005 21:05:48 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #879 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:05:48 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ltru@ietf.org Subject: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 (editor hat on) I don't know what to do this with resolution. What am I supposed to clarify? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: World Wide Web Owner [mailto:www@psg.com] On Behalf Of rt+ltru- > registry@rt.psg.com > Sent: jeudi 7 avril 2005 14:01 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [psg.com #879] clarify "i-default" and "und" > > Hi - > > (co-chair hat ON) > > This issue was raised in http://www1.ietf.org/mail- > archive/web/ltru/current/msg00029.html > > I believe there is a rough consensus to clarify, see > http://www1.ietf.org/mail-archive/web/ltru/current/msg00036.html > > The editors should make the appropriate edits, and we can mark this issue > "resolved" > > Randy > > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:07:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08155; Thu, 7 Apr 2005 17:07:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeMd-0002kq-II; Thu, 07 Apr 2005 17:16:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCE-0003hi-Ie; Thu, 07 Apr 2005 17:05:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCC-0003hM-Ul for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:05:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07920 for ; Thu, 7 Apr 2005 17:05:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeKq-0002eF-3T for ltru@ietf.org; Thu, 07 Apr 2005 17:14:44 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeCB-000BWy-Su for ltru@ietf.org; Thu, 07 Apr 2005 21:05:47 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #879 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:05:47 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ltru@ietf.org Subject: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 (editor hat on) I don't know what to do this with resolution. What am I supposed to clarify? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: World Wide Web Owner [mailto:www@psg.com] On Behalf Of rt+ltru- > registry@rt.psg.com > Sent: jeudi 7 avril 2005 14:01 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [psg.com #879] clarify "i-default" and "und" > > Hi - > > (co-chair hat ON) > > This issue was raised in http://www1.ietf.org/mail- > archive/web/ltru/current/msg00029.html > > I believe there is a rough consensus to clarify, see > http://www1.ietf.org/mail-archive/web/ltru/current/msg00036.html > > The editors should make the appropriate edits, and we can mark this issue > "resolved" > > Randy > > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:07:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08195; Thu, 7 Apr 2005 17:07:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeMj-0002l0-LU; Thu, 07 Apr 2005 17:16:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeD7-0003qk-Po; Thu, 07 Apr 2005 17:06:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeD2-0003oO-MQ for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:06:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08023 for ; Thu, 7 Apr 2005 17:06:38 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeLf-0002i8-RK for ltru@ietf.org; Thu, 07 Apr 2005 17:15:36 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 14:06:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Apr 2005 14:06:30 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFEE1@irvmbxw01.quest.com> Thread-Topic: [psg.com #880] fix ABNF bugs Thread-Index: AcU7tV1d8ZrvM5pEQrKBjfxkGLzZwgAAEbww From: "Addison Phillips" To: X-OriginalArrivalTime: 07 Apr 2005 21:06:31.0384 (UTC) FILETIME=[AC2F7D80:01C53BB5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] RE: [psg.com #880] fix ABNF bugs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0379094032==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d --===============0379094032== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxyZWFkeSBkb25lLg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6 YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFs aXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90 IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogV29ybGQgV2lkZSBXZWIgT3duZXIgW21haWx0bzp3d3dAcHNn LmNvbV0gT24gQmVoYWxmIE9mIHJ0K2x0cnUtDQo+IHJlZ2lzdHJ5QHJ0LnBzZy5jb20NCj4gU2Vu dDogamV1ZGkgNyBhdnJpbCAyMDA1IDE0OjA0DQo+IFRvOiBBZGRpc29uIFBoaWxsaXBzDQo+IENj OiBsdHJ1QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbcHNnLmNvbSAjODgwXSBmaXggQUJORiBi dWdzDQo+IA0KPiBIaSAtDQo+IA0KPiAoY28tY2hhaXIgaGF0IE9OKQ0KPiANCj4gU29tZSBBQk5G IHByb2JsZW1zIHdlcmUgaWRlbnRpZmllZCBpbiB0aGUgdGhyZWFkIHN0YXJ0aW5nIGF0DQo+ICBo dHRwOi8vd3d3MS5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2x0cnUvY3VycmVudC9tc2cwMDA3 NC5odG1sDQo+IA0KPiBJIGJlbGlldmUgdGhlcmUgaXMgYSByb3VnaCBjb25zZW5zdXMgdG8gZml4 IHRoZXNlLCBwZXINCj4gIGh0dHA6Ly93d3cxLmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbHRy dS9jdXJyZW50L21zZzAwMDc1Lmh0bWwNCj4gYW5kIGFzIGNvbmZpcm1lZCBpbg0KPiBodHRwOi8v d3d3MS5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2x0cnUvY3VycmVudC9tc2cwMDA4NC5odG1s DQo+IA0KPiBXaGVuIHRoZSBlZGl0b3JzIGhhdmUgbWFkZSB0aGUgYXBwcm9wcmlhdGUgZWRpdHMs IHdlIGNhbiBtYXJrIHRoaXMNCj4gaXNzdWUgInJlc29sdmVkIi4NCj4gDQo+IFJhbmR5DQo+IA0K PiANCj4gDQo+IA0KDQoNCg== --===============0379094032== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0379094032==-- From ltru-bounces@ietf.org Thu Apr 7 17:08:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08265; Thu, 7 Apr 2005 17:08:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeNL-0002lt-OR; Thu, 07 Apr 2005 17:17:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCz-0003oK-L7; Thu, 07 Apr 2005 17:06:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCy-0003o3-UT for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:06:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08017 for ; Thu, 7 Apr 2005 17:06:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeLc-0002iH-0r for ltru@ietf.org; Thu, 07 Apr 2005 17:15:32 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeCx-000BlM-PS for ltru@ietf.org; Thu, 07 Apr 2005 21:06:35 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #880 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:06:35 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ltru@ietf.org Subject: [Ltru] RE: [psg.com #880] fix ABNF bugs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Already done. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: World Wide Web Owner [mailto:www@psg.com] On Behalf Of rt+ltru- > registry@rt.psg.com > Sent: jeudi 7 avril 2005 14:04 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [psg.com #880] fix ABNF bugs > > Hi - > > (co-chair hat ON) > > Some ABNF problems were identified in the thread starting at > http://www1.ietf.org/mail-archive/web/ltru/current/msg00074.html > > I believe there is a rough consensus to fix these, per > http://www1.ietf.org/mail-archive/web/ltru/current/msg00075.html > and as confirmed in > http://www1.ietf.org/mail-archive/web/ltru/current/msg00084.html > > When the editors have made the appropriate edits, we can mark this > issue "resolved". > > Randy > > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:08:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08286; Thu, 7 Apr 2005 17:08:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeNO-0002m1-PD; Thu, 07 Apr 2005 17:17:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJe80-0003Ja-4h; Thu, 07 Apr 2005 17:01:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJe7v-0003JO-JL for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:01:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07620 for ; Thu, 7 Apr 2005 17:01:20 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeGX-0002Wf-Ni for ltru@ietf.org; Thu, 07 Apr 2005 17:10:18 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJe7t-000B1h-IW for ltru@ietf.org; Thu, 07 Apr 2005 21:01:21 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #879 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:01:21 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #879] clarify "i-default" and "und" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi - (co-chair hat ON) This issue was raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00029.html I believe there is a rough consensus to clarify, see http://www1.ietf.org/mail-archive/web/ltru/current/msg00036.html The editors should make the appropriate edits, and we can mark this issue "resolved" Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:08:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08317; Thu, 7 Apr 2005 17:08:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeNb-0002mB-Ee; Thu, 07 Apr 2005 17:17:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCz-0003oG-G0; Thu, 07 Apr 2005 17:06:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCy-0003ny-Nq for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:06:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08014 for ; Thu, 7 Apr 2005 17:06:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeLb-0002iD-RV for ltru@ietf.org; Thu, 07 Apr 2005 17:15:32 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeCx-000BlI-Jd; Thu, 07 Apr 2005 21:06:35 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #881 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:06:35 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #881] remove registrant information from registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - (co-chair hat on) It was proposed to remove registrant information from the registry in http://www1.ietf.org/mail-archive/web/ltru/current/msg00083.html I think that the rough consensus is that no change is needed, and that this issue should be marked "rejected". If further discussion is necessary, or you think this conclusion would be incorrect, please follow up on this thread. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:08:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08340; Thu, 7 Apr 2005 17:08:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeNk-0002mJ-I0; Thu, 07 Apr 2005 17:17:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCM-0003iS-1f; Thu, 07 Apr 2005 17:05:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCJ-0003iH-TS for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:05:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07935 for ; Thu, 7 Apr 2005 17:05:53 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeKw-0002e5-22 for ltru@ietf.org; Thu, 07 Apr 2005 17:14:51 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 14:05:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Apr 2005 14:05:43 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFEDD@irvmbxw01.quest.com> Thread-Topic: [psg.com #879] clarify "i-default" and "und" Thread-Index: AcU7tPR2G9LYDjKfTpOPYZ7r2bOJRAAAEWlA From: "Addison Phillips" To: X-OriginalArrivalTime: 07 Apr 2005 21:05:44.0682 (UTC) FILETIME=[905954A0:01C53BB5] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org Subject: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0650408488==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 --===============0650408488== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KGVkaXRvciBoYXQgb24pIEkgZG9uJ3Qga25vdyB3aGF0IHRvIGRvIHRoaXMgd2l0aCByZXNvbHV0 aW9uLiBXaGF0IGFtIEkgc3VwcG9zZWQgdG8gY2xhcmlmeT8NCg0KQWRkaXNvbg0KDQpBZGRpc29u IFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNo YWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVy bmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUu IA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvcmxkIFdpZGUgV2Vi IE93bmVyIFttYWlsdG86d3d3QHBzZy5jb21dIE9uIEJlaGFsZiBPZiBydCtsdHJ1LQ0KPiByZWdp c3RyeUBydC5wc2cuY29tDQo+IFNlbnQ6IGpldWRpIDcgYXZyaWwgMjAwNSAxNDowMQ0KPiBUbzog QWRkaXNvbiBQaGlsbGlwcw0KPiBDYzogbHRydUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Bz Zy5jb20gIzg3OV0gY2xhcmlmeSAiaS1kZWZhdWx0IiBhbmQgInVuZCINCj4gDQo+IEhpIC0NCj4g DQo+IChjby1jaGFpciBoYXQgT04pDQo+IA0KPiBUaGlzIGlzc3VlIHdhcyByYWlzZWQgaW4gaHR0 cDovL3d3dzEuaWV0Zi5vcmcvbWFpbC0NCj4gYXJjaGl2ZS93ZWIvbHRydS9jdXJyZW50L21zZzAw MDI5Lmh0bWwNCj4gDQo+IEkgYmVsaWV2ZSB0aGVyZSBpcyBhIHJvdWdoIGNvbnNlbnN1cyB0byBj bGFyaWZ5LCBzZWUNCj4gIGh0dHA6Ly93d3cxLmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbHRy dS9jdXJyZW50L21zZzAwMDM2Lmh0bWwNCj4gDQo+IFRoZSBlZGl0b3JzIHNob3VsZCBtYWtlIHRo ZSBhcHByb3ByaWF0ZSBlZGl0cywgYW5kIHdlIGNhbiBtYXJrIHRoaXMgaXNzdWUNCj4gInJlc29s dmVkIg0KPiANCj4gUmFuZHkNCj4gDQo+IA0KPiANCj4gDQoNCg0K --===============0650408488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0650408488==-- From ltru-bounces@ietf.org Thu Apr 7 17:09:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08366; Thu, 7 Apr 2005 17:09:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeO6-0002mi-9t; Thu, 07 Apr 2005 17:18:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCz-0003o8-73; Thu, 07 Apr 2005 17:06:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCy-0003no-3x for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:06:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08006 for ; Thu, 7 Apr 2005 17:06:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeLb-0002iA-9J for ltru@ietf.org; Thu, 07 Apr 2005 17:15:31 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeCx-000Bl5-1q for ltru@ietf.org; Thu, 07 Apr 2005 21:06:35 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #881 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:06:35 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #881] remove registrant information from registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - (co-chair hat on) It was proposed to remove registrant information from the registry in http://www1.ietf.org/mail-archive/web/ltru/current/msg00083.html I think that the rough consensus is that no change is needed, and that this issue should be marked "rejected". If further discussion is necessary, or you think this conclusion would be incorrect, please follow up on this thread. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:09:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08385; Thu, 7 Apr 2005 17:09:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeO7-0002mn-0q; Thu, 07 Apr 2005 17:18:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCz-0003oC-Br; Thu, 07 Apr 2005 17:06:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeCy-0003nt-GG for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:06:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08009 for ; Thu, 7 Apr 2005 17:06:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeLb-0002iB-Gb for ltru@ietf.org; Thu, 07 Apr 2005 17:15:31 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeCx-000Bl9-9K for ltru@ietf.org; Thu, 07 Apr 2005 21:06:35 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #880 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:06:35 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ltru@ietf.org Subject: [Ltru] RE: [psg.com #880] fix ABNF bugs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Already done. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: World Wide Web Owner [mailto:www@psg.com] On Behalf Of rt+ltru- > registry@rt.psg.com > Sent: jeudi 7 avril 2005 14:04 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [psg.com #880] fix ABNF bugs > > Hi - > > (co-chair hat ON) > > Some ABNF problems were identified in the thread starting at > http://www1.ietf.org/mail-archive/web/ltru/current/msg00074.html > > I believe there is a rough consensus to fix these, per > http://www1.ietf.org/mail-archive/web/ltru/current/msg00075.html > and as confirmed in > http://www1.ietf.org/mail-archive/web/ltru/current/msg00084.html > > When the editors have made the appropriate edits, we can mark this > issue "resolved". > > Randy > > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:09:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08419; Thu, 7 Apr 2005 17:09:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeON-0002nB-Eb; Thu, 07 Apr 2005 17:18:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJe6U-0003BD-8R; Thu, 07 Apr 2005 16:59:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJe6T-0003B1-7Z for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:59:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07519 for ; Thu, 7 Apr 2005 16:59:50 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeF5-0002S2-A8 for ltru@ietf.org; Thu, 07 Apr 2005 17:08:48 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJe6R-000ApI-5F for ltru@ietf.org; Thu, 07 Apr 2005 20:59:51 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #878 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Thu, 07 Apr 2005 20:59:51 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #878] should the initial registry contents i-d be published as an RFC? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi - (co-chair hat ON) In http://www1.ietf.org/mail-archive/web/ltru/current/msg00023.html the question was raised whether the initial registry contents, if posted as an i-d, should be published as an RFC. The discussion so far has not been conclusive, in my judgement. I believe the WG feels there to be no particular value in publishing it as an RFC, so the question boils down to whether providing an i-d to IANA would be sufficient. I'd like clarification from our AD on this point. Unless our AD indicates that there is a clear preference on the part of IANA to use an RFC, rather than a WG-controlled i-d, as a starting point, I'm inclined towards the view the the WG should not request publication of the initial registry contents in the form of an RFC. Comments appreciated. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:09:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08469; Thu, 7 Apr 2005 17:09:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeOd-0002q5-JB; Thu, 07 Apr 2005 17:18:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJe6U-0003B9-3r; Thu, 07 Apr 2005 16:59:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJe6S-0003Aw-JL for ltru@megatron.ietf.org; Thu, 07 Apr 2005 16:59:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07516 for ; Thu, 7 Apr 2005 16:59:49 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeF5-0002S3-MX for ltru@ietf.org; Thu, 07 Apr 2005 17:08:47 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJe6R-000ApQ-Hi; Thu, 07 Apr 2005 20:59:51 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #878 Precedence: bulk To: dewell@adelphia.net X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Thu, 07 Apr 2005 20:59:51 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #878] should the initial registry contents i-d be published as an RFC? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi - (co-chair hat ON) In http://www1.ietf.org/mail-archive/web/ltru/current/msg00023.html the question was raised whether the initial registry contents, if posted as an i-d, should be published as an RFC. The discussion so far has not been conclusive, in my judgement. I believe the WG feels there to be no particular value in publishing it as an RFC, so the question boils down to whether providing an i-d to IANA would be sufficient. I'd like clarification from our AD on this point. Unless our AD indicates that there is a clear preference on the part of IANA to use an RFC, rather than a WG-controlled i-d, as a starting point, I'm inclined towards the view the the WG should not request publication of the initial registry contents in the form of an RFC. Comments appreciated. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:09:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08512; Thu, 7 Apr 2005 17:09:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeOs-0002qY-FF; Thu, 07 Apr 2005 17:18:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeAm-0003Tj-15; Thu, 07 Apr 2005 17:04:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeAk-0003TR-By for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:04:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07806 for ; Thu, 7 Apr 2005 17:04:15 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeJN-0002c6-GP for ltru@ietf.org; Thu, 07 Apr 2005 17:13:13 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeAj-000BJh-9c; Thu, 07 Apr 2005 21:04:17 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #880 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:04:17 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #880] fix ABNF bugs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi - (co-chair hat ON) Some ABNF problems were identified in the thread starting at http://www1.ietf.org/mail-archive/web/ltru/current/msg00074.html I believe there is a rough consensus to fix these, per http://www1.ietf.org/mail-archive/web/ltru/current/msg00075.html and as confirmed in http://www1.ietf.org/mail-archive/web/ltru/current/msg00084.html When the editors have made the appropriate edits, we can mark this issue "resolved". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:12:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08767; Thu, 7 Apr 2005 17:12:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeRb-0002yC-4e; Thu, 07 Apr 2005 17:21:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeIe-0005GN-Fp; Thu, 07 Apr 2005 17:12:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeIZ-0005G8-HT for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:12:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08716 for ; Thu, 7 Apr 2005 17:12:20 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeRB-0002un-Od for ltru@ietf.org; Thu, 07 Apr 2005 17:21:19 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeIX-000CWh-GM for ltru@ietf.org; Thu, 07 Apr 2005 21:12:21 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: Re: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" RT-Ticket: psg.com #879 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:12:21 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi - > From: > Cc: > Sent: Thursday, April 07, 2005 2:05 PM > Subject: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" > > (editor hat on) I don't know what to do this with resolution. What am I supposed to clarify? ... I think the exchange at the end of http://www1.ietf.org/mail-archive/web/ltru/current/msg00036.html is as specific as it got: > Is that the idea ? A pointer to BCP 18 in the comment column > for i-default could help. Or IANA should keep the existing > i-files with the grandfathered details. IANA should also keep > the details for all future registered variants, if they don't > fit in the comments column of the future registry. Should we handle this as a comment on the initial regsitry content? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:16:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09091; Thu, 7 Apr 2005 17:16:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeUt-00036Y-AO; Thu, 07 Apr 2005 17:25:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeIa-0005GD-Bi; Thu, 07 Apr 2005 17:12:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeIY-0005G3-Tz for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:12:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08713 for ; Thu, 7 Apr 2005 17:12:20 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeRC-0002up-4t for ltru@ietf.org; Thu, 07 Apr 2005 17:21:18 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeIX-000CWo-Sg; Thu, 07 Apr 2005 21:12:21 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: Re: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" RT-Ticket: psg.com #879 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:12:21 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi - > From: > Cc: > Sent: Thursday, April 07, 2005 2:05 PM > Subject: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" > > (editor hat on) I don't know what to do this with resolution. What am I supposed to clarify? ... I think the exchange at the end of http://www1.ietf.org/mail-archive/web/ltru/current/msg00036.html is as specific as it got: > Is that the idea ? A pointer to BCP 18 in the comment column > for i-default could help. Or IANA should keep the existing > i-files with the grandfathered details. IANA should also keep > the details for all future registered variants, if they don't > fit in the comments column of the future registry. Should we handle this as a comment on the initial regsitry content? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:16:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09154; Thu, 7 Apr 2005 17:16:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeV5-00037V-JB; Thu, 07 Apr 2005 17:25:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeFc-0004ZE-PG; Thu, 07 Apr 2005 17:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeFb-0004YC-Lc for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:09:19 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08411 for ; Thu, 7 Apr 2005 17:09:16 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJeBl-0003Zf-Ar for ltru@lists.ietf.org; Thu, 07 Apr 2005 23:05:21 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 23:05:21 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 23:05:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 23:04:39 +0200 Organization: Lines: 28 Message-ID: <4255A067.486E@xyzzy.claranet.de> References: <01LMT5FFC4MO00005R@mauve.mrochek.com> <20050407175216.GE9134@skunk.reutershealth.com> <42558671.1AB4@xyzzy.claranet.de> <20050407193520.GB10046@skunk.reutershealth.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.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit John Cowan wrote: >> IMHO that's wrong, MIME is ingenious (excl. 2231). > How so? Pre-MIME MUAs will display rubbish when sent MIME > messages, and nothing can stop it. No, they will display plain text US-ASCII, that's not rubbish. And pre-MIME MTAs can completely ignore the "rubbish" like the weird Subject: in this article (intentionally something your MUA most probably doesn't know, for a pre-MIME experience). MIME is really ingenious, only RfC 2231 has some dark corners. > incompatible script is much worse than incompatible region Sure, but only "new" implementations support it at all, and so they can do the right thing no matter where the script tag is. >> different schemes like Debbie's 639-4. > 639-6, you mean. Yes. I've no clear idea what it's about, but there can't be compatibility issues with 3066 if it's radically incompatible. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:19:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09438; Thu, 7 Apr 2005 17:19:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeXs-0003Ed-6M; Thu, 07 Apr 2005 17:28:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJePA-0008OJ-UE; Thu, 07 Apr 2005 17:19:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeP9-0008O5-M7 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:19:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09427 for ; Thu, 7 Apr 2005 17:19:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeXm-0003ES-TP for ltru@ietf.org; Thu, 07 Apr 2005 17:28:07 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeP8-000D02-J6 for ltru@ietf.org; Thu, 07 Apr 2005 21:19:10 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: RE: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" RT-Ticket: psg.com #879 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:19:10 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 I would say: reject the comment if it doesn't result in something concrete. If we're going to deal with the UND and MUL rules (and pull in i-default at the same time) then we should propose specific text or at least tell the editor what is supposed to be modified so that person has a fighting chance of doing something useful. Comments on the initial registry contents, by the way, go into the now former Appendix C: instructions on creating the registry. I can put a note in about i-default and BCP 18, if there is consensus to do so. I'll point out that the IANA instructions already direct IANA to keep the existing registration files. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of rt+ltru-registry@rt.psg.com > Sent: jeudi 7 avril 2005 14:12 > Cc: ltru@ietf.org > Subject: Re: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" > > Hi - > > > From: > > Cc: > > Sent: Thursday, April 07, 2005 2:05 PM > > Subject: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" > > > > > (editor hat on) I don't know what to do this with resolution. What am I > supposed to clarify? > ... > > I think the exchange at the end of > http://www1.ietf.org/mail-archive/web/ltru/current/msg00036.html > is as specific as it got: > > > Is that the idea ? A pointer to BCP 18 in the comment column > > for i-default could help. Or IANA should keep the existing > > i-files with the grandfathered details. IANA should also keep > > the details for all future registered variants, if they don't > > fit in the comments column of the future registry. > > Should we handle this as a comment on the initial regsitry content? > > Randy > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:19:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09478; Thu, 7 Apr 2005 17:19:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeY6-0003FF-2x; Thu, 07 Apr 2005 17:28:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJePG-0008Pd-HG; Thu, 07 Apr 2005 17:19:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJePE-0008P3-I3 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:19:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09434 for ; Thu, 7 Apr 2005 17:19:13 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeXr-0003ER-Pd for ltru@ietf.org; Thu, 07 Apr 2005 17:28:12 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 14:19:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" Date: Thu, 7 Apr 2005 14:19:06 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFEF1@irvmbxw01.quest.com> Thread-Topic: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" Thread-Index: AcU7tprDZa+1UcCZQhm03GPN70D/EwAABakQ From: "Addison Phillips" To: X-OriginalArrivalTime: 07 Apr 2005 21:19:07.0036 (UTC) FILETIME=[6E96D5C0:01C53BB7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1146909972==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab --===============1146909972== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBzYXk6IHJlamVjdCB0aGUgY29tbWVudCBpZiBpdCBkb2Vzbid0IHJlc3VsdCBpbiBz b21ldGhpbmcgY29uY3JldGUuIElmIHdlJ3JlIGdvaW5nIHRvIGRlYWwgd2l0aCB0aGUgVU5EIGFu ZCBNVUwgcnVsZXMgKGFuZCBwdWxsIGluIGktZGVmYXVsdCBhdCB0aGUgc2FtZSB0aW1lKSB0aGVu IHdlIHNob3VsZCBwcm9wb3NlIHNwZWNpZmljIHRleHQgb3IgYXQgbGVhc3QgdGVsbCB0aGUgZWRp dG9yIHdoYXQgaXMgc3VwcG9zZWQgdG8gYmUgbW9kaWZpZWQgc28gdGhhdCBwZXJzb24gaGFzIGEg ZmlnaHRpbmcgY2hhbmNlIG9mIGRvaW5nIHNvbWV0aGluZyB1c2VmdWwuDQoNCkNvbW1lbnRzIG9u IHRoZSBpbml0aWFsIHJlZ2lzdHJ5IGNvbnRlbnRzLCBieSB0aGUgd2F5LCBnbyBpbnRvIHRoZSBu b3cgZm9ybWVyIEFwcGVuZGl4IEM6IGluc3RydWN0aW9ucyBvbiBjcmVhdGluZyB0aGUgcmVnaXN0 cnkuIEkgY2FuIHB1dCBhIG5vdGUgaW4gYWJvdXQgaS1kZWZhdWx0IGFuZCBCQ1AgMTgsIGlmIHRo ZXJlIGlzIGNvbnNlbnN1cyB0byBkbyBzby4NCg0KSSdsbCBwb2ludCBvdXQgdGhhdCB0aGUgSUFO QSBpbnN0cnVjdGlvbnMgYWxyZWFkeSBkaXJlY3QgSUFOQSB0byBrZWVwIHRoZSBleGlzdGluZyBy ZWdpc3RyYXRpb24gZmlsZXMuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xv YmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVybmF0 aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBp cyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmcgW21h aWx0bzpsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBydCtsdHJ1 LXJlZ2lzdHJ5QHJ0LnBzZy5jb20NCj4gU2VudDogamV1ZGkgNyBhdnJpbCAyMDA1IDE0OjEyDQo+ IENjOiBsdHJ1QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gUkU6IFtwc2cuY29tICM4 NzldIGNsYXJpZnkgImktZGVmYXVsdCIgYW5kICJ1bmQiDQo+IA0KPiBIaSAtDQo+IA0KPiA+IEZy b206IDxydCtsdHJ1LXJlZ2lzdHJ5QHJ0LnBzZy5jb20+DQo+ID4gQ2M6IDxsdHJ1QGlldGYub3Jn Pg0KPiA+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAwNywgMjAwNSAyOjA1IFBNDQo+ID4gU3ViamVj dDogW0x0cnVdIFJFOiBbcHNnLmNvbSAjODc5XSBjbGFyaWZ5ICJpLWRlZmF1bHQiIGFuZCAidW5k Ig0KPiA+DQo+IA0KPiA+IChlZGl0b3IgaGF0IG9uKSBJIGRvbid0IGtub3cgd2hhdCB0byBkbyB0 aGlzIHdpdGggcmVzb2x1dGlvbi4gV2hhdCBhbSBJDQo+IHN1cHBvc2VkIHRvIGNsYXJpZnk/DQo+ IC4uLg0KPiANCj4gSSB0aGluayB0aGUgZXhjaGFuZ2UgYXQgdGhlIGVuZCBvZg0KPiBodHRwOi8v d3d3MS5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2x0cnUvY3VycmVudC9tc2cwMDAzNi5odG1s DQo+IGlzIGFzIHNwZWNpZmljIGFzIGl0IGdvdDoNCj4gDQo+ID4gSXMgdGhhdCB0aGUgaWRlYSA/ ICBBIHBvaW50ZXIgdG8gQkNQIDE4IGluIHRoZSBjb21tZW50IGNvbHVtbg0KPiA+IGZvciBpLWRl ZmF1bHQgY291bGQgaGVscC4gIE9yIElBTkEgc2hvdWxkIGtlZXAgdGhlIGV4aXN0aW5nDQo+ID4g aS1maWxlcyB3aXRoIHRoZSBncmFuZGZhdGhlcmVkIGRldGFpbHMuICBJQU5BIHNob3VsZCBhbHNv IGtlZXANCj4gPiB0aGUgZGV0YWlscyBmb3IgYWxsIGZ1dHVyZSByZWdpc3RlcmVkIHZhcmlhbnRz LCBpZiB0aGV5IGRvbid0DQo+ID4gZml0IGluIHRoZSBjb21tZW50cyBjb2x1bW4gb2YgdGhlIGZ1 dHVyZSByZWdpc3RyeS4NCj4gDQo+IFNob3VsZCB3ZSBoYW5kbGUgdGhpcyBhcyBhIGNvbW1lbnQg b24gdGhlIGluaXRpYWwgcmVnc2l0cnkgY29udGVudD8NCj4gDQo+IFJhbmR5DQo+IA0KPiANCj4g DQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQo= --===============1146909972== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1146909972==-- From ltru-bounces@ietf.org Thu Apr 7 17:19:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09502; Thu, 7 Apr 2005 17:19:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeYD-0003FJ-0J; Thu, 07 Apr 2005 17:28:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJePE-0008ON-2m; Thu, 07 Apr 2005 17:19:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeP9-0008OA-WC for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:19:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09431 for ; Thu, 7 Apr 2005 17:19:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeXn-0003ET-7V for ltru@ietf.org; Thu, 07 Apr 2005 17:28:07 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeP8-000D07-TK for ltru@ietf.org; Thu, 07 Apr 2005 21:19:10 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: RE: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" RT-Ticket: psg.com #879 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:19:10 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 I would say: reject the comment if it doesn't result in something concrete. If we're going to deal with the UND and MUL rules (and pull in i-default at the same time) then we should propose specific text or at least tell the editor what is supposed to be modified so that person has a fighting chance of doing something useful. Comments on the initial registry contents, by the way, go into the now former Appendix C: instructions on creating the registry. I can put a note in about i-default and BCP 18, if there is consensus to do so. I'll point out that the IANA instructions already direct IANA to keep the existing registration files. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of rt+ltru-registry@rt.psg.com > Sent: jeudi 7 avril 2005 14:12 > Cc: ltru@ietf.org > Subject: Re: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" > > Hi - > > > From: > > Cc: > > Sent: Thursday, April 07, 2005 2:05 PM > > Subject: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" > > > > > (editor hat on) I don't know what to do this with resolution. What am I > supposed to clarify? > ... > > I think the exchange at the end of > http://www1.ietf.org/mail-archive/web/ltru/current/msg00036.html > is as specific as it got: > > > Is that the idea ? A pointer to BCP 18 in the comment column > > for i-default could help. Or IANA should keep the existing > > i-files with the grandfathered details. IANA should also keep > > the details for all future registered variants, if they don't > > fit in the comments column of the future registry. > > Should we handle this as a comment on the initial regsitry content? > > Randy > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:21:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09726; Thu, 7 Apr 2005 17:21:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeaP-0003Kp-Ln; Thu, 07 Apr 2005 17:30:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeRE-0001RA-Go; Thu, 07 Apr 2005 17:21:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeRC-0001Ph-Vp for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:21:19 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09618 for ; Thu, 7 Apr 2005 17:21:15 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJeO8-0005cP-Tc for ltru@lists.ietf.org; Thu, 07 Apr 2005 23:18:08 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 23:18:08 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 23:18:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 23:19:40 +0200 Organization: Lines: 12 Message-ID: <4255A3EC.377C@xyzzy.claranet.de> References: <00e401c53baa$14100340$7f1afea9@oemcomputer> <20050407201951.GD10046@skunk.reutershealth.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.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #874] propagation of parent organization deprecations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit John Cowan wrote: > 4) When a code is deprecated after Date B, and a replacement > code is provided, the old code remains unchanged in the > registry, and the new code goes into the registry as > deprecated with the canonical form given. Why not simply add the new code, and change the old code to "deprecated" with the new code as canonical value ? (= as in 2) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:33:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10718; Thu, 7 Apr 2005 17:33:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJem1-0003l3-LH; Thu, 07 Apr 2005 17:42:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJed8-0004gC-6r; Thu, 07 Apr 2005 17:33:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJed6-0004g2-Q7 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:33:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10678 for ; Thu, 7 Apr 2005 17:33:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJelj-0003kK-6H for ltru@ietf.org; Thu, 07 Apr 2005 17:42:32 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJed4-000ERf-O2 for ltru@ietf.org; Thu, 07 Apr 2005 21:33:34 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #882 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:33:34 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@ietf.org Subject: [Ltru] RE: [psg.com #882] registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa I concur. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: World Wide Web Owner [mailto:www@psg.com] On Behalf Of rt+ltru- > registry@rt.psg.com > Sent: jeudi 7 avril 2005 14:32 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [psg.com #882] registry should copy non-English fields from > ISO documents > > Hi - > > (co-chair hat ON) > > In http://www1.ietf.org/mail-archive/web/ltru/current/msg00083.html > the request was made to copy non-English fields from ISO documents. > > (Not to be confused with the "native name of language" question!!!) > > At this point, I believe the rough consensus is to reject this request, > but I'd like confirmation from the WG that my understanding of the > rough consensus is correct. > > Randy > > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:34:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10762; Thu, 7 Apr 2005 17:34:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJemk-0003lS-2U; Thu, 07 Apr 2005 17:43:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJedF-0004hD-FV; Thu, 07 Apr 2005 17:33:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJedC-0004gl-Ab for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:33:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10692 for ; Thu, 7 Apr 2005 17:33:39 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJelo-0003ht-GB for ltru@ietf.org; Thu, 07 Apr 2005 17:42:37 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 14:33:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Apr 2005 14:33:31 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFF03@irvmbxw01.quest.com> Thread-Topic: [psg.com #882] registry should copy non-English fields from ISO documents Thread-Index: AcU7uUSQDdaHYlmSSlegMJQLZyUCvQAACI+A From: "Addison Phillips" To: X-OriginalArrivalTime: 07 Apr 2005 21:33:31.0640 (UTC) FILETIME=[71EEEF80:01C53BB9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] RE: [psg.com #882] registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0517221351==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d --===============0517221351== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjb25jdXIuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlv biBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0 aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBm ZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBXb3JsZCBXaWRlIFdlYiBPd25lciBbbWFpbHRvOnd3d0Bwc2cuY29t XSBPbiBCZWhhbGYgT2YgcnQrbHRydS0NCj4gcmVnaXN0cnlAcnQucHNnLmNvbQ0KPiBTZW50OiBq ZXVkaSA3IGF2cmlsIDIwMDUgMTQ6MzINCj4gVG86IEFkZGlzb24gUGhpbGxpcHMNCj4gQ2M6IGx0 cnVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtwc2cuY29tICM4ODJdIHJlZ2lzdHJ5IHNob3Vs ZCBjb3B5IG5vbi1FbmdsaXNoIGZpZWxkcyBmcm9tDQo+IElTTyBkb2N1bWVudHMNCj4gDQo+IEhp IC0NCj4gDQo+IChjby1jaGFpciBoYXQgT04pDQo+IA0KPiBJbiAgaHR0cDovL3d3dzEuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1cnJlbnQvbXNnMDAwODMuaHRtbA0KPiB0aGUgcmVx dWVzdCB3YXMgbWFkZSB0byBjb3B5IG5vbi1FbmdsaXNoIGZpZWxkcyBmcm9tIElTTyBkb2N1bWVu dHMuDQo+IA0KPiAoTm90IHRvIGJlIGNvbmZ1c2VkIHdpdGggdGhlICJuYXRpdmUgbmFtZSBvZiBs YW5ndWFnZSIgcXVlc3Rpb24hISEpDQo+IA0KPiBBdCB0aGlzIHBvaW50LCBJIGJlbGlldmUgdGhl IHJvdWdoIGNvbnNlbnN1cyBpcyB0byByZWplY3QgdGhpcyByZXF1ZXN0LA0KPiBidXQgSSdkIGxp a2UgY29uZmlybWF0aW9uIGZyb20gdGhlIFdHIHRoYXQgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUN Cj4gcm91Z2ggY29uc2Vuc3VzIGlzIGNvcnJlY3QuDQo+IA0KPiBSYW5keQ0KPiANCj4gDQo+IA0K PiANCg0KDQo= --===============0517221351== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0517221351==-- From ltru-bounces@ietf.org Thu Apr 7 17:34:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10780; Thu, 7 Apr 2005 17:34:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJems-0003lW-4C; Thu, 07 Apr 2005 17:43:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJebp-0004Z7-O6; Thu, 07 Apr 2005 17:32:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJebn-0004Yw-H1 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:32:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10555 for ; Thu, 7 Apr 2005 17:32:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJekQ-0003fR-N5 for ltru@ietf.org; Thu, 07 Apr 2005 17:41:10 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJebm-000ELe-4L for ltru@ietf.org; Thu, 07 Apr 2005 21:32:14 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #882 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:32:14 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi - (co-chair hat ON) In http://www1.ietf.org/mail-archive/web/ltru/current/msg00083.html the request was made to copy non-English fields from ISO documents. (Not to be confused with the "native name of language" question!!!) At this point, I believe the rough consensus is to reject this request, but I'd like confirmation from the WG that my understanding of the rough consensus is correct. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:36:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10837; Thu, 7 Apr 2005 17:36:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeo8-0003mQ-4S; Thu, 07 Apr 2005 17:45:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJebp-0004ZE-SZ; Thu, 07 Apr 2005 17:32:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJebn-0004Z1-Ja for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:32:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10559 for ; Thu, 7 Apr 2005 17:32:12 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJekQ-0003fS-Uy for ltru@ietf.org; Thu, 07 Apr 2005 17:41:11 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJebm-000ELl-Gf; Thu, 07 Apr 2005 21:32:14 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #882 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:32:14 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi - (co-chair hat ON) In http://www1.ietf.org/mail-archive/web/ltru/current/msg00083.html the request was made to copy non-English fields from ISO documents. (Not to be confused with the "native name of language" question!!!) At this point, I believe the rough consensus is to reject this request, but I'd like confirmation from the WG that my understanding of the rough consensus is correct. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:48:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11383; Thu, 7 Apr 2005 17:48:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJezr-00048T-9F; Thu, 07 Apr 2005 17:57:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJefu-0004ub-AL; Thu, 07 Apr 2005 17:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJefs-0004uO-8l for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:36:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10856 for ; Thu, 7 Apr 2005 17:36:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeoV-0003mu-NO for ltru@ietf.org; Thu, 07 Apr 2005 17:45:23 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJefr-000Efp-7I for ltru@ietf.org; Thu, 07 Apr 2005 21:36:27 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #884 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:36:27 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #884] remove dead references X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi - (co-chair hat ON) This issue raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00086.html I believe there is consensus to remove dead references, and that the editors have already done this. Consequently, I plan to mark this issue "resolved". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:49:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11465; Thu, 7 Apr 2005 17:49:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJf0x-0004CE-E5; Thu, 07 Apr 2005 17:58:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJefu-0004uf-Eh; Thu, 07 Apr 2005 17:36:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJefs-0004uW-Kc for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:36:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10859 for ; Thu, 7 Apr 2005 17:36:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJeoW-0003mv-2n for ltru@ietf.org; Thu, 07 Apr 2005 17:45:24 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJefr-000Eg0-Ja; Thu, 07 Apr 2005 21:36:27 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #884 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:36:27 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #884] remove dead references X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi - (co-chair hat ON) This issue raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00086.html I believe there is consensus to remove dead references, and that the editors have already done this. Consequently, I plan to mark this issue "resolved". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:50:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11546; Thu, 7 Apr 2005 17:50:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJf1h-0004Cs-6o; Thu, 07 Apr 2005 17:59:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeeJ-0004oJ-C0; Thu, 07 Apr 2005 17:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeeI-0004oA-TF for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:34:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10802 for ; Thu, 7 Apr 2005 17:34:48 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJemv-0003la-8n for ltru@ietf.org; Thu, 07 Apr 2005 17:43:46 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeeG-000EWN-Kk for ltru@ietf.org; Thu, 07 Apr 2005 21:34:48 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #883 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:34:48 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #883] language tag reviewers should be elected, rather than appointed X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - (co-chair hat ON) In http://www1.ietf.org/mail-archive/web/ltru/current/msg00083.html it was suggested that language tag reviewers should be elected, rather than appointed by the IESG. I have seen no support for this proposal. Consequently, I suggest that we change the status of this request to "rejected". If there are objections to closing this issue in this manner, now is the time to make them heard. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:50:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11601; Thu, 7 Apr 2005 17:50:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJf1y-0004Do-1L; Thu, 07 Apr 2005 17:59:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJep2-0005IS-28; Thu, 07 Apr 2005 17:45:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeoz-0005IH-On for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:45:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11258 for ; Thu, 7 Apr 2005 17:45:50 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJexc-00045s-IH for ltru@ietf.org; Thu, 07 Apr 2005 17:54:48 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 14:45:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: [psg.com #874] propagation of parent organizationdeprecations Date: Thu, 7 Apr 2005 14:45:42 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFF0E@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #874] propagation of parent organizationdeprecations Thread-Index: AcU7t88VcirJPsGGSpuAJ1c8mh/kIwAAA7MA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 07 Apr 2005 21:45:43.0677 (UTC) FILETIME=[2642EAD0:01C53BBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable > Why not simply add the new code, and change the old code to > "deprecated" with the new code as canonical value ? (=3D as in 2) Because we guarantee that once a subtag is canonical it is canonical = forever for that meaning. In my previous note, you'll note that we can separate whether is it = deprecated from whether it is canonical. Canonical means that there is = another code that should be used. Deprecated merely means "don't use = this one (after the date provided)". Canonical is a normative mapping = and deprecated is informative by that measure. Consider NH turning into VU as if it happened a year from now. Currently (using #2) it is: %% Subtag: NH Canonical: VU Deprecated: 1980-01-01 %% Subtag: VU %% With the rules I proposed: %% Subtag: NH Deprecated: 2006-01-01 Comment: use VU for Vanuatu %% Subtag: VU %% With the second, we haven't invalidated anyone's data. But the registry = conveys the new value. As written in John's rules here is what would happen: %% Subtag: NH %% Subtag: VU Canonical: NH Deprecated: 2006-01-01 Comment: use NH for Vanuatu by rule %% This is vaguely unsatisfying by comparison. Now let's consider if some other country got NH assigned to it. %% Subtag: NH Deprecated: 2006-01-01 %% Subtag: VU %% Subtag: 1234 Comment: UN M.49 code, Code NH is used by New Hebrides %% Finally, let's consider if VU changed it name again as some future date: %% Subtag: NH Deprecated: 2006-01-01 Comment: use VU %% Subtag: VU Deprecated: 2010-01-01 Comment: use XX %% Subtag: XX %% Still no one's data is hurt, but there is a trail of bread crumbs to = follow. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: jeudi 7 avril 2005 14:20 > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #874] propagation of parent > organizationdeprecations >=20 > John Cowan wrote: >=20 > > 4) When a code is deprecated after Date B, and a replacement > > code is provided, the old code remains unchanged in the > > registry, and the new code goes into the registry as > > deprecated with the canonical form given. >=20 > Why not simply add the new code, and change the old code to > "deprecated" with the new code as canonical value ? (=3D as in 2) >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:50:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11640; Thu, 7 Apr 2005 17:50:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJf2V-0004EI-9G; Thu, 07 Apr 2005 17:59:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeeJ-0004oF-6O; Thu, 07 Apr 2005 17:34:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeeI-0004o5-7r for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:34:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10799 for ; Thu, 7 Apr 2005 17:34:47 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJemv-0003lb-LS for ltru@ietf.org; Thu, 07 Apr 2005 17:43:45 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJeeH-000EWW-0b; Thu, 07 Apr 2005 21:34:49 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #883 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:34:49 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #883] language tag reviewers should be elected, rather than appointed X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - (co-chair hat ON) In http://www1.ietf.org/mail-archive/web/ltru/current/msg00083.html it was suggested that language tag reviewers should be elected, rather than appointed by the IESG. I have seen no support for this proposal. Consequently, I suggest that we change the status of this request to "rejected". If there are objections to closing this issue in this manner, now is the time to make them heard. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:50:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11662; Thu, 7 Apr 2005 17:50:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJf2a-0004ER-Jq; Thu, 07 Apr 2005 17:59:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeqj-0005Ms-La; Thu, 07 Apr 2005 17:47:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeqi-0005Me-73 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:47:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11372 for ; Thu, 7 Apr 2005 17:47:37 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJezK-000487-Oi for ltru@ietf.org; Thu, 07 Apr 2005 17:56:35 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37LlTfo028174; Thu, 7 Apr 2005 17:47:30 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 17:47:44 -0400 Date: Thu, 7 Apr 2005 17:47:43 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: [psg.com #874] propagation of parent organization deprecations Message-ID: <20050407214743.GF10046@skunk.reutershealth.com> References: <00e401c53baa$14100340$7f1afea9@oemcomputer> <20050407201951.GD10046@skunk.reutershealth.com> <4255A3EC.377C@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4255A3EC.377C@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Frank Ellermann scripsit: > John Cowan wrote: > > > 4) When a code is deprecated after Date B, and a replacement > > code is provided, the old code remains unchanged in the > > registry, and the new code goes into the registry as > > deprecated with the canonical form given. > > Why not simply add the new code, and change the old code to > "deprecated" with the new code as canonical value ? (= as in 2) The whole point is to make sure that the subtags don't change after Date B (when the draft is published as an RFC), so that we are no longer subject to the vagaries of the ISO authorities. -- He made the Legislature meet at one-horse John Cowan tank-towns out in the alfalfa belt, so that jcowan@reutershealth.com hardly nobody could get there and most of http://www.reutershealth.com the leaders would stay home and let him go http://www.ccil.org/~cowan to work and do things as he pleased. --Mencken, Declaration of Independence _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:51:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11712; Thu, 7 Apr 2005 17:51:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJf2q-0004FA-6M; Thu, 07 Apr 2005 18:00:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJen8-0005DW-Gg; Thu, 07 Apr 2005 17:43:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJen7-0005DR-1U for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:43:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11074 for ; Thu, 7 Apr 2005 17:43:53 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJevi-000409-C4 for ltru@ietf.org; Thu, 07 Apr 2005 17:52:52 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJen1-0001YN-00 for ltru@ietf.org; Thu, 07 Apr 2005 14:43:51 -0700 Message-ID: <01b601c53bbb$12797500$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 7 Apr 2005 14:45:10 -0700 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 Subject: [Ltru] "talking" to RT and duplicate messages X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - To reduce the number of duplicate messages on the mailing list, do *not* cc: ltru@ietf.org when you send a message to any of the rt+ltru-*@rt.psg.com addresses. The ltru@ietf.org list is currently a "watcher" of these queues, so major changes to issues automatically go to this mailing list. If we find this too unwieldy to work with, we can change the configuration. My rationale for the current configuration is that this way any messages going for an issue will be assured of showing up on the open list, giving us a complete record in one place. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:51:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11749; Thu, 7 Apr 2005 17:51:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJf2y-0004FK-T9; Thu, 07 Apr 2005 18:00:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeaL-0004L4-Jh; Thu, 07 Apr 2005 17:30:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJeaJ-0004Kw-MT for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:30:43 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10461 for ; Thu, 7 Apr 2005 17:30:40 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJeXL-0006wh-Nv for ltru@lists.ietf.org; Thu, 07 Apr 2005 23:27:39 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 23:27:39 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 07 Apr 2005 23:27:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 07 Apr 2005 23:28:50 +0200 Organization: Lines: 8 Message-ID: <4255A612.3BFC@xyzzy.claranet.de> References: <00e901c53baa$d18d3aa0$7f1afea9@oemcomputer> 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.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #875] should initial registry contents be made into an internet-draft? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > if you have strong arguments pro or contra Pro, something like RfC 4021 is nice. If Doug somehow forces page footers below %% lines, and page headers above the next registry entry. Please no big gap like 4021-3864. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:51:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11818; Thu, 7 Apr 2005 17:51:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJf3P-0004Ij-Hs; Thu, 07 Apr 2005 18:00:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJedB-0004gh-B2; Thu, 07 Apr 2005 17:33:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJed7-0004g7-4o for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:33:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10681 for ; Thu, 7 Apr 2005 17:33:34 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJelj-0003kL-GZ for ltru@ietf.org; Thu, 07 Apr 2005 17:42:32 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJed5-000ERk-1u for ltru@ietf.org; Thu, 07 Apr 2005 21:33:35 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #882 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Thu, 07 Apr 2005 21:33:35 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@ietf.org Subject: [Ltru] RE: [psg.com #882] registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa I concur. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: World Wide Web Owner [mailto:www@psg.com] On Behalf Of rt+ltru- > registry@rt.psg.com > Sent: jeudi 7 avril 2005 14:32 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [psg.com #882] registry should copy non-English fields from > ISO documents > > Hi - > > (co-chair hat ON) > > In http://www1.ietf.org/mail-archive/web/ltru/current/msg00083.html > the request was made to copy non-English fields from ISO documents. > > (Not to be confused with the "native name of language" question!!!) > > At this point, I believe the rough consensus is to reject this request, > but I'd like confirmation from the WG that my understanding of the > rough consensus is correct. > > Randy > > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 17:59:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12539; Thu, 7 Apr 2005 17:59:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJfAV-0004bF-KP; Thu, 07 Apr 2005 18:08:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJf0w-0002Xu-8K; Thu, 07 Apr 2005 17:58:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJf0u-0002Wz-Au for ltru@megatron.ietf.org; Thu, 07 Apr 2005 17:58:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12495 for ; Thu, 7 Apr 2005 17:58:09 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJf9W-0004aP-Vx for ltru@ietf.org; Thu, 07 Apr 2005 18:07:08 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j37Lw1xe028257; Thu, 7 Apr 2005 17:58:02 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 17:58:04 -0400 Date: Thu, 7 Apr 2005 17:58:04 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: [psg.com #875] should initial registry contents be made into an internet-draft? Message-ID: <20050407215804.GG10046@skunk.reutershealth.com> References: <00e901c53baa$d18d3aa0$7f1afea9@oemcomputer> <4255A612.3BFC@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4255A612.3BFC@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Frank Ellermann scripsit: > Randy Presuhn wrote: > > > if you have strong arguments pro or contra > > Pro, something like RfC 4021 is nice. If Doug somehow forces > page footers below %% lines, and page headers above the next > registry entry. Please no big gap like 4021-3864. Bye, Frank This is academic. An I-D that is not intended to become an RFC does not have to follow RFC format in any way. -- John Cowan http://www.ccil.org/~cowan http://www.reutershealth.com Charles li reis, nostre emperesdre magnes, Set anz totz pleinz ad ested in Espagnes. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 18:05:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13051; Thu, 7 Apr 2005 18:05:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJfGG-0004mL-Ms; Thu, 07 Apr 2005 18:14:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJf7B-0004GN-4N; Thu, 07 Apr 2005 18:04:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJf79-0004GI-Rc for ltru@megatron.ietf.org; Thu, 07 Apr 2005 18:04:40 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13000 for ; Thu, 7 Apr 2005 18:04:36 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJf4h-0003O4-0v for ltru@lists.ietf.org; Fri, 08 Apr 2005 00:02:07 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 00:02:07 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 00:02:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Apr 2005 00:03:02 +0200 Organization: Lines: 25 Message-ID: <4255AE16.69F8@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFE9B@irvmbxw01.quest.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.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: John Cowan's substantivecommentsondraft-ietf-ltru-registry-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > Personally, I support XML 1.1 and would reference it, except > that there isn't any real difference. I'd follow my personal preferences until somebody screams, the "last version" (either XML 1.0 or 1.1) links are also shorter. > I don't personally like the RFC 2822 folding. It's a part of the record-jar "like RfC 822" idea. Line ends escaped by a backslash are *NIXisms, and beside the point for a CrLf. [registration details] > It isn't relevant for just variants any more. All changes > will be forwarded using the process. But not for 7000+ languages, I hope, only for the expected about 10 updates per year. Anyway, after 50 years 500 strings http://www.iana.org/assignments/lang-tags/ are less than 20 KB, but 500 * full details within the tag registry could be a pain. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 18:17:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14965; Thu, 7 Apr 2005 18:17:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJfSe-0005Dj-Kv; Thu, 07 Apr 2005 18:26:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfJj-0007FB-62; Thu, 07 Apr 2005 18:17:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfJi-0007F6-Dj for ltru@megatron.ietf.org; Thu, 07 Apr 2005 18:17:38 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14933 for ; Thu, 7 Apr 2005 18:17:34 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJfHK-000566-QU for ltru@lists.ietf.org; Fri, 08 Apr 2005 00:15:10 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 00:15:10 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 00:15:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Apr 2005 00:15:25 +0200 Organization: Lines: 11 Message-ID: <4255B0FD.4891@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFE84@irvmbxw01.quest.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.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > This solves the default script problem because we are > recommending when to use the subtag (when your language > is in the list for that subtag). Not completely. For something like "fy" implementations still don't know what the undocumented default (Latn in this case) is. And you'd get a rather long list of prefixes for scripts like Latn or Cyrl (all languages using both), don't you ? Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 18:33:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16493; Thu, 7 Apr 2005 18:33:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJfhX-0005jB-G6; Thu, 07 Apr 2005 18:42:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfVv-00087I-6e; Thu, 07 Apr 2005 18:30:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfVt-00087A-Ph for ltru@megatron.ietf.org; Thu, 07 Apr 2005 18:30:14 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15946 for ; Thu, 7 Apr 2005 18:30:09 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJfT8-0006oc-Gi for ltru@lists.ietf.org; Fri, 08 Apr 2005 00:27:22 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 00:27:22 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 00:27:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Apr 2005 00:28:01 +0200 Organization: Lines: 11 Message-ID: <4255B3F1.1058@xyzzy.claranet.de> References: <00e901c53baa$d18d3aa0$7f1afea9@oemcomputer> <4255A612.3BFC@xyzzy.claranet.de> <20050407215804.GG10046@skunk.reutershealth.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.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #875] should initial registry contents be made into an internet-draft? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit John Cowan wrote: > This is academic. An I-D that is not intended to become an > RFC does not have to follow RFC format in any way. This ticket stuff with its numerous questions irritates me. What's the difference between 875 and 878, why is 878 posted twice ? When I said that I like RfC 4021 I meant RfC format, not some dummy I-D. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 18:45:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17313; Thu, 7 Apr 2005 18:45:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJfte-000690-6z; Thu, 07 Apr 2005 18:54:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfkS-0004jH-2F; Thu, 07 Apr 2005 18:45:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfkQ-0004jC-16 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 18:45:14 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17286 for ; Thu, 7 Apr 2005 18:45:10 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJfhl-0008NR-7S for ltru@lists.ietf.org; Fri, 08 Apr 2005 00:42:29 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 00:42:29 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 00:42:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Apr 2005 00:38:19 +0200 Organization: Lines: 11 Message-ID: <4255B65B.4776@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: fix ABNF bugs X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit rt+ltru-registry@rt.psg.com wrote: > Already done. Does the ticket system now read subjects and echo anything it understands ? The same article with three Message-IDs: <634978A7DF025A40BFEF33EB191E13BC0AEEFEE1@irvmbxw01.quest.com> _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 18:55:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18045; Thu, 7 Apr 2005 18:55:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJg2Z-0006RB-Ta; Thu, 07 Apr 2005 19:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfn3-0005UX-95; Thu, 07 Apr 2005 18:47:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfn1-0005UB-7U for ltru@megatron.ietf.org; Thu, 07 Apr 2005 18:47:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17426 for ; Thu, 7 Apr 2005 18:47:51 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJfve-0006B3-7O for ltru@ietf.org; Thu, 07 Apr 2005 18:56:51 -0400 Received: from lns-p19-2-idf-82-251-152-231.adsl.proxad.net ([82.251.152.231] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJfmp-00041a-D0; Thu, 07 Apr 2005 15:47:44 -0700 Message-Id: <6.1.2.0.2.20050407150441.034edeb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 07 Apr 2005 15:05:00 +0200 To: "Peter Constable" , From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 At 06:31 07/04/2005, Peter Constable wrote: >Anyway, I'll send you what I have (off-list, since I haven't seen >indication that this is of general interest). Where did not got that indication? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 18:55:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18102; Thu, 7 Apr 2005 18:55:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJg2u-0006RX-Lt; Thu, 07 Apr 2005 19:04:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfn1-0005UP-VJ; Thu, 07 Apr 2005 18:47:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfn1-0005UA-6y for ltru@megatron.ietf.org; Thu, 07 Apr 2005 18:47:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17424 for ; Thu, 7 Apr 2005 18:47:51 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJfve-0006B5-54 for ltru@ietf.org; Thu, 07 Apr 2005 18:56:51 -0400 Received: from lns-p19-2-idf-82-251-152-231.adsl.proxad.net ([82.251.152.231] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJfmq-00041a-P7; Thu, 07 Apr 2005 15:47:45 -0700 Message-Id: <6.1.2.0.2.20050407151257.05072eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Apr 2005 00:47:27 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) In-Reply-To: <002c01c53b40$9b68a780$030aa8c0@DEWELL> References: <20050406191319.GBPY2135.mta2.adelphia.net@megatron.ietf.org> <002c01c53b40$9b68a780$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 At 09:08 07/04/2005, Doug Ewell wrote: >the latter (including all the ridiculous ones) would be about 15 million. Serious ones would probably be billions. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 18:55:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18135; Thu, 7 Apr 2005 18:55:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJg3T-0006S3-S8; Thu, 07 Apr 2005 19:04:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfn3-0005UT-2z; Thu, 07 Apr 2005 18:47:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfn1-0005UC-CA for ltru@megatron.ietf.org; Thu, 07 Apr 2005 18:47:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17422 for ; Thu, 7 Apr 2005 18:47:51 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJfve-0006B7-61 for ltru@ietf.org; Thu, 07 Apr 2005 18:56:51 -0400 Received: from lns-p19-2-idf-82-251-152-231.adsl.proxad.net ([82.251.152.231] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJfms-00041a-R5; Thu, 07 Apr 2005 15:47:48 -0700 Message-Id: <6.1.2.0.2.20050407161438.0513ec50@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Apr 2005 00:27:10 +0200 To: John Cowan From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] draft review In-Reply-To: <20050407135146.GI1795@skunk.reutershealth.com> References: <6.1.2.0.2.20050405014928.037ea550@mail.jefsey.com> <20050407135146.GI1795@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ce2737a971e141e0457c8c1bf182367f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id SAA17422 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 5655aae64318292c42757ebeb53e54ce Content-Transfer-Encoding: quoted-printable Dear John, I thank you for this review. If I am correct my response here should only= =20 be to say if I maintain the point or if I accept that your objection is=20 correct and I should remove it? There are many comments which root in a different vision of the Internet=20 and of the Charter. I note them the first time they occur. They should be= =20 debatted separately. Some mignt lead to the need of a call on an IAB=20 Guidance, due to their fundamental aspect for the Internet, if theyr were= =20 still shared by a significant proportion of the score of participants to=20 this WG. At 15:51 07/04/2005, John Cowan wrote: > > 16. 2.2: it is noted that the language used for the "language tags > > namespace" and its registry is quite similar to the domain name syste= m. > >The analogy is vague and specious, and utterly ungrounded in the text, >which does not even contain the phrases "domain name system" or "DNS". I have however a general comment which is that you seem to entertain some= =20 confusion about what is the DNS and its main usage. This is a common=20 confusion. I suggest you study STD 013. I will not comment your further=20 allusions to DNS. > > However the proposed semantic is not consistent with other Internet > > spaces like DNS, IPv4, OID, etc. where the dot-separation is used, > > something users and parsers are accustomed to and existing processes > > have identified in different scripts. It relies to the contrary on th= e > > "-" as a separator which is more confusing and may have less identifi= ed > > homographs. > >What is more confusing about "-" than "."? In any case, "-" has been >used in all language tags until now, and is required for backward >compatibility. Not a objection to a factual remark. The point is not that the format wou= ld=20 be wrong, but that the format wants to be unique and general. This=20 misunderstanding affects most of the remarks about the format. I will=20 therefore not comment it, only the specifics of each point. > > 17. [...] Such a two, possibly contradictory, systems format will > > never scale, is far too dependent from external changes and unable to > > support innovation. > >This is handwaving. Scale to what, millions of countries and trillions >of languages? Of course it is dependent on external changes, or rather >the lack of them. A format that is designed to depend on anything exter= nal >cannot possibly adjust in advance to radical changes of an unknown natur= e. The charter is precisely about making the format independent from externa= l=20 elements. This confusion is part of several reponses. I will not comment = them. > > This cannot be made a world-wide standard through an IETF BCP except > > in the cases defined by the charter if the IESG wants to run into the > > risk of endless conflicts and of a quick obsolescence. > >The alleged risk is not supported by the history of RFC 1766/3066 in >the last ten years. This is precisely the point. The way this RFC is writen and applied makes= a=20 real difference with the Draft. Here is were comes the risk. > > It is to be noted that the referred ISO standard to be used are less > > than 30 years old and yet ISO 3166-2 cannot be supported. > >ISO 3166-2 (subnational regions) is not freely available; it costs CHF 2= 00 >for a copy without even update service. (Approx. EUR 129 or USD 167.) I fail to see what is the problem about the rightness of the content? The= =20 point is not in the access to the ISO document, but the inability of the=20 proposed format to support IANA registrations of ISO 3166-2 equivalents. >It has never been proposed or used for language tagging. In addition, >it is extremely unstable, because countries are allowed to rewrite >their parts of it pretty much ad lib as they reorganize their internal >subdivisions from time to time. This is precisely the second point. When they do that it is usually for a= =20 reason which is regionally or locally the same as ISO 3166-1 at national=20 level. This is what makes ISO 3166 consistent, but not the proposed forma= t. > > 18. 2.2.1: primary language: fixed length identification starts > > with 2 or 3 and possibly 8 but discouraged language ID coming this wa= y > > only from ISO 639. This removes the possibility to consider computer > > related (non only programming) languages, dialects, etc. nor to adapt > > to evolutions, adjustments, and passed languages. > >Untrue. 36^8 possible language tags is more than enough. Discouraging >something does not imply removing the possibility of it. Document the "more than enough" please. There is a general trend in these= =20 remarks to assume things. This is also a noted remark of the Draft. Rathe= r=20 than to discuss them I will note the remarks made on assumptions. To be=20 constructive we should discuss these assumptions separately and probably=20 list them as a leading part of the Draft, indicating the real scope of th= e=20 Draft. What I can only support. 19. 2.2.1.: the 2 letters code for language is an oddity inherited > > from earlier times of RFC 1776 and ISO 639. > >It is unquestionably a theoretical wart, but is absolutely required >for backward compatibility. Yes. We are in agreement. You therefore do not contest the validity of th= is=20 point. Its discussion is obviously another thing. > > It is likely that at some time it will be timed out by ISO or/and by > > usage may be even by anti-racist laws. > >This is a truly amazing bit of prophecy worthy of Michel de Notredame. This represents a certain lack of legal international culture. The French= =20 law used in the Yahoo case (which has equivalent in the world) makes this= =20 illegal. It is also most probably a case to be made with the WTO as an=20 unfair commercial advantage. We are here discussing standards. Standards=20 concerned with stability (if they are stable and used they probably are=20 adequate). The legal enforcement of a change in Standard is then real fea= r=20 we should share. > > Time is now to update existing applications rather than to increase > > complexity of the years/century to come. > >Applications are not at issue; data is. Where is the money going to >come from to re-mark-up the billions of existing documents and metadata >repositories worldwide that rely on ISO 639-1 codes? I do not understand this point. The point is not to re-mark-up billions o= f=20 existing documents (backward compatibility will address that) but to save= =20 the money that trillons of clumsy tagging will cost. Improving on somethi= ng=20 existant is usually for a ROI. > > This makes me think > > to "UK" instead of "GB". > >Words like "united" and "kingdom" are avoided when possible in ISO 3166-= 1 >codes because they are shared by many nations. You would be better off >pressing for GN (Great Britain and Northern Ireland) or for changing >US to some other code. I was refering to the origin of UK being used instead of GB. I know this = is=20 because Mr. Peter Jones. I will know and will be able to tell my grand-so= ns=20 that I also know the lang3tag origin.... > > 20. 2.2.2: language [extended] subtags are permitted only if they > > are 3 characters (a permanent rigid position) based the anticipation > > of a non documented ISO 639 works. This is also a violation of the > > Internet standard process: the document in reference should be quoted > > and cannot be a draft. > >ltru-registry is also only a draft at present. Same comment as Scott Hollebeck's remark as about ABNF format. > > Language extended subtags are the most active part of languages, > >Where is the evidence for this claim? Are you confusing the function >of extended language subtags with that of variant subtags? This can be certainly be discussed. Could you write a few lines on this. A Draft writter should not assume=20 three things: - that his readers are intelligent - I know this is a fault I commonly co= mmit - that his readers know things which are not documented in the Draft (nee= d=20 of an explanation or of a link) - that his readers share his visions, this is why he has to explain them = so=20 they understand where he comes from and adapt. > > 21. 2.2.3: Script subtags follow the same rigid logic and constrain= ts > > from the format. What happens if the memory waste of ISO 15924 (3 > > bytes lost) is corrected, or if another code element has a fixed 4 > > characters length in the future? > >We cannot design the draft to adapt to unpredictable massive changes >in the format of ISO codes, especially when there is not the slightest >evidence that such a thing will ever happen. Charter. This is also easy. I do not see any "massive" change here. > > 22. 2.2.4: I understand that all the regional language differences > > of the world are to be supported by the ISO 3166 alpha-3/digit-3 list. > >Incorrect. National and supranational regions are supported by ISO 3166= -1 >alpha-2 and UN M.49 digit-3 codes. :-) Your comment is serious. Let stay this way. > > This means that regions like NY, TX or California are not entitled a > > code but the 56 persons of Pitcairn Island yes? I doubt that disparit= y > > can hold very long, all the more than ISO 3166-2 provides all the > > possibilities for a far more adequate granularity. > >See above. wart? agree. > > 23. 2.2.9: There is a MUST in "there MUST be an attempt to register= " > > which cannot be enforced if there is not a non-delaying procedure to > > verify that a language was attempted to be registered with ISO 639. > >Forward verification would surely suffice; a copy of a dated email to >ISO 639/RA showing an ignored registration would suffice. In facct, >however, the RA is quite responsive. Document it. This is a standard, not a newspaper. > > Otherwise this part is to be understood as a disguised way, concerted > > with ISO, to block names. > >There is no evidence for this allegation. Many in ISO question ISO 15924 document. IETF and IANA have massive=20 additions (starting with DNS Tables), Michael Eversom already made clear = he=20 will not consider. Being on both sides there is a CIO with the current te= xt. > > The concern on this point is high enough to see the Draft blocked. > >Whose concern? Blocked by whom? Vague and unfounded. Unless IESG drops the rule of consensus, there is no possible consensus o= n=20 the present Draft. I am a documentation of it. At the present stage I can= =20 only oppose. This is why I try to see my opposition reduced. But this is = a=20 consensus process, not a compromise and obviously not an enforcement=20 process. This means that at the end of the day APMD and I must be equally= =20 satisfied with the result. > > It seems that the second paragraph is a smoky verbose replay of the > > same idea, without any procedural description nor request/provision > > of formal proof. > >It may *seem* so to you. We deal here in what is so, not in what seems = so. I was polite. As a general comment, an RFC is an IETF delivery to readers. What counts = is=20 not what the authors intended to say but what the readers will understand= .=20 This is why the last call, the IESG and the Editor contribute after the W= G.=20 This is why also all the RFC do not become standards. This case is=20 particular due to the status of BCP 047 of the RFC 3066. > > The general idea is precisely in opposition with the purpose of the > > proposed RFC: to be able to register names not registered by ISO. Thi= s > > amount to a legitimisation of censoring, and censoring against the > > very intent of this document. > >Libelous nonsense. The general idea is of course to avoid duplication >of effort, so that ISO and ietf-languages are not considering the same >language at the same time. No. Such a legitimate preoccupation would be satisfied by a registration=20 except if a serious documented objection is risen within a 15 days=20 consideration period _and_ documented (for the very point you make) by th= e=20 ISO MA. > > 24. 2.2.9: registrations are left to a decision of appropriateness > > by someone debating with undefined others for a matter without any > > importance on the network stability and security (documented in in > > part 4) non on the end to end interoperability. This seems to amount > > to pure intellectual censoring. > >Non sequitur. ??? Unless you agree with my comment that these proposition do not make real = sense. > > 25. 2.3: recommendation 3 seems inappropriate. Aliases are aliases. > > All the aliases must be equally supported because (a) they are aliase= s > > (b) to make sure developers develops correct code. > >All aliases are equally supported. Not all aliases are equally recommen= ded. Not the text. > > 26. 2.4. "language tags always define a language as spoken by human > > being for communications of information to other human beings. Comput= er > > languages are explicitly excluded" has no ground in the Charter and > > in reality. > >Computer languages are not languages, save metaphorically. See ISO 639. Sorry, ISO 639 is not the Charter. ISO 639 has obvious lacks that ISO 639= -4=20 is meant to correct. Impeaching supported Internet applications to benefi= t=20 from ISO 639-4/6 probable positions, together with a disregard of the=20 Charter, is a responsibility I will not assume. But it can be discussed it in your assumptions. > > Web Services relations are excluded which may speak limited languages. > >Do you suppose that SOAP is a language? I have difficulty in understanding the question. > > Coded human languages should be supported: they fit the definition. > >What is a coded human language? arbaille. > > 27. 2.4.1: in the canonicalization part "" is reminded as a > > deprecation indicator, yet this is not documented earlier. It seems t= his > > is an external ISO practice. This should be documented in the format > > description part. All the more than this practice is counter intuitiv= e > > "" being understood intuitively as "-(nul)-". And the "" being used > > in IDN there could be some homograph confusion to investigate. > >I suppose that by "" you mean "--". This is not a deprecation indicator= , >as the draft clearly explains. Please give reference of the part. May be I missed it. >I will address comments 28-33 elsewhere. > > > 34. 3.3. why a "MAY" concerning the "description, note and prefix > > fields" is not documented by conditions? Is that not a "CAN". > >CAN does not appear in RFC 2119. Sure. But this is not a reason to use a wrong term. >I will address comment 35 elsewhere. Comment 36 is editorial in nature >and has already been addressed elsewhere. > > > 37. 3.4. The description of information to be maintained is clear, > > but the format is not described. This permits IANA to freely change i= t > > or to present it in HTML form. This does not help its automated readi= ng. > >3.4 is about extensions, which are documented through the RFC process >and only through the RFC process, as is plainly stated. There is no >expectation that information about extensions will be machine-processabl= e. There is mine. As you may know I maintain a daily survey of some IANA fil= es=20 (http://ccmso.org/intldate.txt - http://ccmso.org/intlfile.txt) and=20 langtags will certainly be included in it. > > 38. 4. security considerations should not deal with users political > > security outside of their network usage. Otherwise tons of such > > considerations should be presented. > >The point has been raised and is documented. I do not understand this comment. I raise the point. Please indicate the=20 documentation? > > 39. 4. An important security consideration is homographs. It is > > certainly possible to include part of text in a foreign language whic= h > > look printed as in another language or having a different meaning or > > printing (phishing). > >This is a security consideration related to the existence of text >altogether, not to the tagging of it. Or at most it is related to >the absence of tagging. Security considerations are where people will go and look when a security= =20 concern is raised. Again this is a standard, not a newspaper or a lawyer=20 defense. The "at most" means we agree: there is an impact. The role of th= e=20 security considerations part is to discuss it. It can be positive or limi= ted. > > Concerns are also the double "-" which is specifically used by the > > IANA code "xn". > >The IDN code space is unrelated in any way to the language tag code spac= e. Private assumption. BTW I say otherwise. It is at least through RFC 1958 basic principle and=20 consistency rule. > > 40. 4. Fourth paragraph tend to say that specification of valid > > sub-tags MUST be available over the internet but that applications > > should take possible DoS into consideration. This is an important > > indication on the way the Draft proposes the registry file to be used > > and accessed. It can be read that applications can freely access it > > and proposed mirrors: this may impose on the IANA a load which will > > result in its permanent inability of service. > >There are several possible solutions, including mirrors, upgrades to >IANA infrastructure, and load throttling by IANA. Which of these is >done, if any, is an internal IANA question and off-topic here. Private assumption. Several on-going debates (WebDAV, LDAP, DNS) in addition show that the=20 point start being a point of consensus. An important issue is that the Draft _does_not_document_ in which way=20 applications may use it. This means what is to be the expected process of= a=20 parser reading a langtag. We are here in an ISO debate, not in an IETF de= bate. >Comments 41-42 are editorial in nature and will be addressed elsewhere. > > > 43. 6. Stability. Confusion between document. This document does > > not provide a mechanism but a format that can be used by the mechanis= m > > described in the next document. This text has not been adapted after > > the split. > >This does not seem to reflect draft-ietf-ltru-registry-01. We work on the published draft. Glad if next draft goes for a better resp= onse. > > 44. 6. Validity. This document should define the IQ of > > the "intelligent people" being considered or the collective IQ > > augmentation necessary to understand the system ?? Please see the > > ideas of the one who created the NIC and grand fathered the RFC syste= m > > (http://bootstrap.org). > >Irrelevant. The draft says that *even* intelligent people may do >inconsistent things in the absence of guidance. The reference given is to the root of the "IETF core values" and to the=20 idea of the founders than computers augmented the intelligence of a=20 bootstrap (a concept today translated in WGs). The best reading is=20 therefore "even for the members of the WG" which is an acceptable=20 auto-derisive remark. Beyond that, the remark is hurting. This is a=20 standard, not a newspaper. > > 45. 6. Extensibility such as presented actually results (in a very > > limited way) from the underlying ISO codes. This is not the target of > > Charter which is to permit scalability even when a code element it is > > not supported by ISO. > >That is one of many points mentioned in the charter. It is not the >singular goal of the draft. This prioritization is your personal assumption. You do not constest the goal. This qualifies the remark. >Comment 46 is editorial in nature and will be addressed elsewhere. > > > 47. 6. last: added text for "" is not sufficient enough, or is > > missing in my version. > >Unintelligible. Probable mail transliteration. "--" is quoted. You constest the point, bu= t=20 did not provide the reference (I may have missed). > > CHARTER VS DRATF RELATED COMMENTS AND QUESTIONS 48. language > > preferences are uniquely understood in HTML, XML only. CLDR are > > quoted in the charter and not quoted in the Draft. The Charter does > > not prevent other applications, systems to be supported. The Draft > > does not allude to them. > >As stated in earlier postings, these are merely consumers of RFC 3066 >language tags. There are others. There is no reason for the draft >to mention its consumers; rather they mention it. Debate has shown that authors intended to exclude some. This is unadvisab= le=20 since it can only kill consensus possibility. > > 49. The charter lists RFC 3066 problems. These problems are: (a) > > stability there is a paragraph on the matter; (b) accessibility to t= he > > underlying ISO standard this is definitely impeached by the format > > (no ISO 3166-2, no other ISO 639 format than 2 or 3 characters no > > other script description format than 4 characters, etc. as if the > > current ISO presentation will never improve); > >Answered above. There is no reason to expect such changes, and no >evidence is given that they constitute improvements. Private assumptions used not to address Charter requirements. > > (c) difficulty with registration and acceptance: this could be improv= ed > > by the subtag registration system but it seems to be made worse, > > due to the censoring rules introduced to prevent non-ISO entries to > > be entered in the IANA non-ISO table; > >"Prevent" is a malicious falsehood. Please propose a more adequate wording than my Franglish. > > (e) lack of clear guidance to identify script and region: scripts are > > Unicode only, > >Untrue. See the ISO 15924/RA registry, which lists many non-Unicode >scripts. I am not sure of the ISO 15924 copy I have. It wears the name and the=20 copyright of its author. Would you have an URL for a stable version of th= e=20 standard? Until I have a final document I cannot comment. > > region are 2 letter Telex codes; > >They are part of an international standard, whether originally >derived from Telex codes or not. Unproductive comment. IETF is Datacoms. > > (f) lack of parseability and well-formedness : this has certainly bee= n > > addressed [it seems to be both the major improvement of the Draft > > )B=85 and the source of most of its problems due to the rigidity > > it introduces]. > >Rigidity about matters which cannot be expected to change is not only >reasonable but desirable. all the more if the Charter says that you are to document how they will=20 match these "not expected" changes. > > 50. The main purpose of this Draft from the charter is to describe > > the IANA registry to support the resolution of the above problems, > > and how transition from RFC 3066. This is to be in a clear and concis= e > > way. RFC 3066 represents roughly 17.000 characters and the draft 70.0= 00 > > (out of the IETF format and verbose). > >Out of the IETF format in what way? I documented: http://mltf.org/addmark.pdf. > > This makes it confuse. From what I understand it includes 3 parts: > > (a) the subtags file with a clear format (b) the accompanying > > registration/update forms (c) the variant tables with a clear, yet > > less precise format. > >What "variant tables"? This expression does not appear in the draft, >nor is anything described that could be so designated. IRT the Draft: this concerns additions made by other RFCs. > > From what I understand (a)(b) are the real responsibility of the old > > aliased distribution list and of a Reviewer designated by IESG with > > unlimited veto powers; > >As the draft (and RFC 3066 and 1766) clearly state, the Reviewer's >decisions may be appealed to IESG. That is not an unlimited veto. Yes it is. De facto as I observed the mailling list. In the way a CIO=20 results from his position and from his copyrigths ISO 15924. > > 51. it lists challenges to be addressed. Stability: "how the langua= ge > > tags remains stable even if the underlying references should change". > > This means a process where the tag name is unrelated to its underlyin= g > > components, like a domain name is stable even if the underlying IP > > address changes. This is not provided. > >The analogy to the DNS is specious. A more correct analogy would be >attemping to keep a domain name stable when one of its enclosing >domains changes its name. DNS. > > 52. it lists challenges to be addressed. Accessibility: "a simple w= ay > > to determine if a subtag is valid as of a given date. Like receiving > > a 404 when calling an expired domain name". Such a mechanism is not > > provided. > >The expression in quotation marks is not, in fact, a quotation from >the charter, and so need not be addressed. The quotation is not of the Charter. It is a quote of the need. Its author will be dismayed from your dispise. The remark certainly hold. > > 53. it lists challenges to be addressed. extensibility: this meant > > not having to record millions of combinations. This is provided. To > > the price of format rigidity, impossible use of foreseen or existing > > ISO code elements, and a censoring of the non-ISO extensions which > > may lead to more harassment. It also meant addition of the script in > > language tags. This is permitted by the proposed format but to the > > detriment of other 4 letters entries. Registration of non ISO scripts > > is not permitted. > >Answered above. No answer above, disqualifies this question. > > 54. it lists challenges to be addressed. "provide mechanism to supp= ort > > the evolution of the underlying standards, in particular ISO 693-3, > > mechanisms to support variant registration and format extensions, > > as well as allowing generative private use when necessary": I am not > > sure what "generative" may mean in here but I feel it is not supporte= d, > > the rest is certainly opposed by the chosen format; > >"Generative" refers to the ability to create complex elements from >the systematic assembly of simpler elements. ISO 639-3 concerns have >been taken into account from the start. Variant registration is >directly supported. Format extensions are provided for. Charter says ISO 639-3 "in particular", not "exclusively". I will wait fo= r=20 ISO 639-6 and for ISO 639-4 and on MLTF positions to disqualify this poin= t. > > 55. it lists challenges to be addressed: "to specify a mechanism fo= r > > easily identifying the role of each subtag in the language tag". Thi= s > > is addressed by the Draft. But this challenge is contradictory with > > stability challenge above. If a language tag displays an identifiable > > subtag, it becomes by nature dependent from the underlying value of > > the subtag. > >It certainly does. To use your favorite analogy, a domain name >is not independent of the name of its enclosing domains; were the .fr >TLD to change its name to .gaul tomorrow, all subdomains of .fr would >have to change likewise. DNS. This makes no sense to me. As a general comment. This review is interesting. It underlines the need = to=20 have the throughout review of the charter we did not initially carried. I= t=20 shows there is a misunderstanding about consensus process we have to=20 clarify. Also that the target is not to enforce a format but to get=20 backward compatibility with a new format. It also shows the need for the=20 score of participants to this work to know better about the other "client= s"=20 of their intended deliverable. I will try to word an begning of analysis = of=20 the use of the langtag, for everyone to add to it. It also starts some additional small debates and possibility of tuning,=20 both for the draft and for my own position. I therefore thank John for th= is=20 work and wait for the next batch of comments. I will also delay my own=20 draft to permit comments to come in (as also indicated by Randy's mail) a= nd=20 permit my own mailing list to review them before. Best regards. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 18:56:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18236; Thu, 7 Apr 2005 18:56:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJg4J-0006Tk-1h; Thu, 07 Apr 2005 19:05:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfrK-0005bk-Tf; Thu, 07 Apr 2005 18:52:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfrK-0005bf-94 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 18:52:22 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17726 for ; Thu, 7 Apr 2005 18:52:18 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJfol-0000Zw-Rp for ltru@lists.ietf.org; Fri, 08 Apr 2005 00:49:43 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 00:49:43 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 00:49:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Apr 2005 00:50:47 +0200 Organization: Lines: 10 Message-ID: <4255B947.28C@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFEDD@irvmbxw01.quest.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.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: clarify "i-default" and "und" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > What am I supposed to clarify? Nothing, close this ticket, I didn't see the difference between und and i-default until John (IIRC) explained it, "und" is just "I don't know what it is", "i-default" is "I hope you know some basic English". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 19:05:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18989; Thu, 7 Apr 2005 19:05:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJgCZ-0006lI-ES; Thu, 07 Apr 2005 19:14:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJg0O-0007u4-Us; Thu, 07 Apr 2005 19:01:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJg0N-0007tz-Qa for ltru@megatron.ietf.org; Thu, 07 Apr 2005 19:01:44 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18694 for ; Thu, 7 Apr 2005 19:01:39 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJfxW-0001af-Ul for ltru@lists.ietf.org; Fri, 08 Apr 2005 00:58:52 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 00:58:46 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 00:58:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Apr 2005 01:00:00 +0200 Organization: Lines: 9 Message-ID: <4255BB70.EE8@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit rt+ltru-registry@rt.psg.com wrote: > I'd like confirmation from the WG that my understanding of > the rough consensus is correct. Bruce wanted the French names in the draft-10 last call, IIRC nobody else wanted this. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 19:06:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19054; Thu, 7 Apr 2005 19:06:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJgDU-0006mO-3X; Thu, 07 Apr 2005 19:15:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJg0Y-0007uG-3c; Thu, 07 Apr 2005 19:01:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJg0W-0007uB-L0 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 19:01:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18697 for ; Thu, 7 Apr 2005 19:01:49 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJg99-0006em-Nf for ltru@ietf.org; Thu, 07 Apr 2005 19:10:49 -0400 Received: from uknsprd1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 7 Apr 2005 23:01:36 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IEL0046OMMOZY@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 08 Apr 2005 00:01:36 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Fri, 08 Apr 2005 00:01:35 +0100 Date: Fri, 08 Apr 2005 00:01:35 +0100 From: Misha Wolf Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) To: LTRU Working Group Message-id: <1987416CA83AC7499AC772F92E2DBF78037C9786@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU7s/VmlNJQntZSQPaAX/7uE3P5jgAETIDw content-class: urn:content-classes:message X-OriginalArrivalTime: 07 Apr 2005 23:01:35.0786 (UTC) FILETIME=[BF87A0A0:01C53BC5] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Frank Ellermann wrote: =20 > Let's say that all "old" implementations try RTL expecting > lang-region-more-stuff. So that's by definition hopeless, > we can only pray that they understand at least lang-region. "Expecting lang-region-more-stuff"? "understand at least lang-region"? What *are* you talking about? Please come down to Earth. The vast majority of implementations simply compare strings,=20 removing stuff from the right. Expecting or understanding=20 doesn't come into it. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 19:07:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19144; Thu, 7 Apr 2005 19:07:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJgEV-0006o7-UR; Thu, 07 Apr 2005 19:16:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJg5M-0008Nb-9r; Thu, 07 Apr 2005 19:06:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJg5K-0008L1-Os for ltru@megatron.ietf.org; Thu, 07 Apr 2005 19:06:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19097 for ; Thu, 7 Apr 2005 19:06:47 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJgDy-0006mx-Te for ltru@ietf.org; Thu, 07 Apr 2005 19:15:47 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 16:06:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Compatibility with existing use (LDAP) Date: Thu, 7 Apr 2005 16:06:36 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFF57@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU7v7nVn8FY+CGQQpS+h6K5Um2m+AAAEgXQ From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 07 Apr 2005 23:06:36.0802 (UTC) FILETIME=[72F30620:01C53BC6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable > Not completely. For something like "fy" implementations still > don't know what the undocumented default (Latn in this case) > is. =20 Implementations do not care what the default is. Just like they don't = care what the "default region" is for a language code. Because it = doesn't matter.=20 What matters is whether users adopt script codes consistently. = Inconsistency breeds problems for RFR matching schemes (requiring that = implementations "care" about default values). All of which is amply = demonstrated on this long thread.=20 Your concern was that we provide no guidance to users on whether or not = to use the new subtags. RFR works as long the number of subtags being = matched is consistent within a given language range. Here is a way to = provide exactly that guidance without burdening language tag = applications with having to know about it. Default scripts require = smarts inside applications (to expand the script subtag at appropriate = times). This merely requires "smarts" inside users (or implementers), = which is a far more likely place to find intelligence. Users are still free to ignore the advice in the registry if that is = their whim (or requirement), but they're adequately warned about the = matching issues. > And you'd get a rather long list of prefixes for scripts > like Latn or Cyrl (all languages using both), don't you ? Certain scripts will have a long-ish list of languages while most = scripts will languish unadorned. This is a problem because...? In practice, while the list of multi-script languages may turn out to be = impressively long, it probably isn't that long. And users are really = looking to see if they should tag their language with a script or not. = If implementations follow the registry, most users will pick from a list = of appropriately formatted tags and this won't be a problem. I think we've also shown that this problem cannot be 100% solved for all = cases of all tags, no matter what their formation. I think this could be = good enough because it helps guide users into making good choices that = mostly avoids the problem. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: jeudi 7 avril 2005 15:15 > To: ltru@ietf.org > Subject: [Ltru] Re: Compatibility with existing use (LDAP) >=20 > Addison Phillips wrote: >=20 > > This solves the default script problem because we are > > recommending when to use the subtag (when your language > > is in the list for that subtag). >=20 > Not completely. For something like "fy" implementations still > don't know what the undocumented default (Latn in this case) > is. And you'd get a rather long list of prefixes for scripts > like Latn or Cyrl (all languages using both), don't you ? Bye. >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 19:38:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20495; Thu, 7 Apr 2005 19:38:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJgil-0007eR-5P; Thu, 07 Apr 2005 19:47:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJgZQ-00078E-TL; Thu, 07 Apr 2005 19:37:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJgZP-00077k-6f for ltru@megatron.ietf.org; Thu, 07 Apr 2005 19:37:55 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20469 for ; Thu, 7 Apr 2005 19:37:50 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJgWx-0006Hk-1X for ltru@lists.ietf.org; Fri, 08 Apr 2005 01:35:23 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 01:35:23 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 01:35:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Apr 2005 01:35:51 +0200 Organization: Lines: 94 Message-ID: <4255C3D7.4A9F@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFF0E@irvmbxw01.quest.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.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: propagation of parent organizationdeprecations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Addison Phillips wrote: >> Why not simply add the new code, and change the old code to >> "deprecated" with the new code as canonical value ? (= as in 2) > Because we guarantee that once a subtag is canonical it is > canonical forever for that meaning. That's a dubious idea, "stability" is not the same as "forever canonical". Consider the ugly effects for something like RH or YU instead of new canonical tags ZW or CS. > we can separate whether is it deprecated from whether it is > canonical. Canonical means that there is another code that > should be used. Deprecated merely means "don't use this one > (after the date provided)". A deprecated RH or YU with a canonical RH or YU makes no sense. If something is deprecated it needs a new canonical value where possible - impossible for SU, simple for DD or RH. It doesn't work as expected for the old YU before the split, but it's okay for the new YU => new CS case. > Subtag: NH > Canonical: VU > Deprecated: 1980-01-01 > %% > Subtag: VU Yes, that's fine. > Subtag: NH > Deprecated: 2006-01-01 > Comment: use VU for Vanuatu > %% > Subtag: VU And that's not okay, "comment" isn't readable for machines. > With the second, we haven't invalidated anyone's data. Both don't invalidate anything, the old NH is still valid, it's only deprecated. If NH is later recycled by ISO 3166-1, then it's better to stay as far as possible away from the old NH. Human taggers will get it wrong and use the new ISO 3166-1 NH, no matter what the registry says. A canonical VU avoids this foreseeable error. > Subtag: NH > %% > Subtag: VU > Canonical: NH > Deprecated: 2006-01-01 > Comment: use NH for Vanuatu by rule > This is vaguely unsatisfying by comparison. This is FUBAR. Deprecated NH => canonical VU is correct. > let's consider if VU changed it name again as some future > date: > Subtag: NH > Deprecated: 2006-01-01 > Comment: use VU > %% > Subtag: VU > Deprecated: 2010-01-01 > Comment: use XX > %% > Subtag: XX > Still no one's data is hurt Until the flood of erroneous NH instead of 1234 begins. It's much clearer and simpler to have this "final" constellation: | Subtag: NH | Deprecated: 2006-01-01 | Canonical: XX | %% | Subtag: VU | Deprecated: 2010-01-01 | Canonical: XX | %% | Subtag: XX | %% | Subtag: 1234 | Comment: UN M.49 code, Code NH blocked by New Hebrides If NH points to VU, and VU to XX, it's also okay. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 19:43:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20679; Thu, 7 Apr 2005 19:43:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJgnc-0007n6-Em; Thu, 07 Apr 2005 19:52:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJgec-00080T-D7; Thu, 07 Apr 2005 19:43:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJgeb-00080L-6W for ltru@megatron.ietf.org; Thu, 07 Apr 2005 19:43:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20664 for ; Thu, 7 Apr 2005 19:43:13 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJgnE-0007ma-Iw for ltru@ietf.org; Thu, 07 Apr 2005 19:52:13 -0400 Received: from lns-p19-2-idf-82-251-152-231.adsl.proxad.net ([82.251.152.231] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJgeX-0002y9-Kn; Thu, 07 Apr 2005 16:43:14 -0700 Message-Id: <6.1.2.0.2.20050408010859.033e17f0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Apr 2005 01:42:58 +0200 To: Frank Ellermann From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: registry should copy non-English fields from ISO documents In-Reply-To: <4255BB70.EE8@xyzzy.claranet.de> References: <4255BB70.EE8@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On 01:00 08/04/2005, Frank Ellermann said: >rt+ltru-registry@rt.psg.com wrote: > > > I'd like confirmation from the WG that my understanding of > > the rough consensus is correct. > >Bruce wanted the French names in the draft-10 last call, IIRC >nobody else wanted this. Uncorrect. Serveral wanted it. I am one. For two main reasons: - consistency with the concerned ISO document - same reason as ISO: crossculture validation is a warranty against monocultural dominance. No consensus will be reached without this. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 19:45:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20795; Thu, 7 Apr 2005 19:45:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJgpW-0007r8-Co; Thu, 07 Apr 2005 19:54:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJgeh-00082V-Hg; Thu, 07 Apr 2005 19:43:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJgeg-00081f-L9 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 19:43:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20670 for ; Thu, 7 Apr 2005 19:43:19 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJgnJ-0007mk-PG for ltru@ietf.org; Thu, 07 Apr 2005 19:52:19 -0400 Received: from lns-p19-2-idf-82-251-152-231.adsl.proxad.net ([82.251.152.231] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJgec-0002y9-EI; Thu, 07 Apr 2005 16:43:18 -0700 Message-Id: <6.1.2.0.2.20050408013714.033e34c0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Apr 2005 01:41:44 +0200 To: ned.freed@mrochek.com From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) In-Reply-To: <01LMT5FFC4MO00005R@mauve.mrochek.com> References: <01LMT5FFC4MO00005R@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 On 19:22 07/04/2005, ned.freed@mrochek.com said: >Balkanization of how language tags are used is the last thing we want, and I >think this is where we're going to end up if we break compatibility. Ned, full agreement. I delay the Draft I intended to present, ir order to follow this. Our approach is to say that BCP 047 should provide a framework to support application related formats. The different formats would then be easily supported. RFC 1776/3066 would continue to be accepted and the new format proposed by APMD could be recommended for HTML/XML/CLDR applications. This would not affect existing applications. This would also support any new need, without a risk of balkanization or even of fragmentation. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 19:45:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20814; Thu, 7 Apr 2005 19:45:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJgpa-0007rC-FZ; Thu, 07 Apr 2005 19:54:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJgel-000835-M7; Thu, 07 Apr 2005 19:43:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJgef-00080o-3C for ltru@megatron.ietf.org; Thu, 07 Apr 2005 19:43:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20667 for ; Thu, 7 Apr 2005 19:43:17 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJgnI-0007mi-Gz for ltru@ietf.org; Thu, 07 Apr 2005 19:52:17 -0400 Received: from lns-p19-2-idf-82-251-152-231.adsl.proxad.net ([82.251.152.231] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJgea-0002y9-TO; Thu, 07 Apr 2005 16:43:17 -0700 Message-Id: <6.1.2.0.2.20050408013547.03c61cc0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Apr 2005 01:36:06 +0200 To: "Addison Phillips" , "John Cowan" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] John Cowan's substantive commentsondraft-ietf-ltru-registry-01 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AEEFD0B@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFD0B@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 At 19:26 07/04/2005, Addison Phillips wrote: > > URIs are ASCII by definition. I am not proposing an IRI. >You're not, but it is rapidly becoming reflexive for me to do so Here we are. At last. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 20:00:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21467; Thu, 7 Apr 2005 20:00:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJh3v-0008Gl-RT; Thu, 07 Apr 2005 20:09:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJgv0-0003RV-1X; Thu, 07 Apr 2005 20:00:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJguy-0003RF-FW for ltru@megatron.ietf.org; Thu, 07 Apr 2005 20:00:12 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21448 for ; Thu, 7 Apr 2005 20:00:07 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJgsS-0000gD-IE for ltru@lists.ietf.org; Fri, 08 Apr 2005 01:57:36 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 01:57:36 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 01:57:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Apr 2005 01:59:24 +0200 Organization: Lines: 14 Message-ID: <4255C95C.2DBC@xyzzy.claranet.de> References: <1987416CA83AC7499AC772F92E2DBF78037C9786@LONSMSXM02.emea.ime.reuters.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.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Misha Wolf wrote: > What *are* you talking about? Exactly this: > The vast majority of implementations simply compare strings, > removing stuff from the right. Expecting or understanding > doesn't come into it. For "expecting" read "one side is old and uses language or language-region", and for "understanding" read "the old side doesn't support any language-script constructs". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 20:14:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22160; Thu, 7 Apr 2005 20:14:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJhH9-0000Ai-LF; Thu, 07 Apr 2005 20:23:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJh2A-00050i-6D; Thu, 07 Apr 2005 20:07:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJh28-00050d-Uk for ltru@megatron.ietf.org; Thu, 07 Apr 2005 20:07:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21794 for ; Thu, 7 Apr 2005 20:07:33 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJhAm-0008Qr-Iq for ltru@ietf.org; Thu, 07 Apr 2005 20:16:33 -0400 Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by mx2.foretec.com with esmtp (Exim 4.24) id 1DJgnU-0005lE-OI for ltru@ietf.org; Thu, 07 Apr 2005 19:52:28 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 16:51:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Date: Thu, 7 Apr 2005 16:51:32 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEEFF7F@irvmbxw01.quest.com> Thread-Topic: [Ltru] John Cowan's substantive commentsondraft-ietf-ltru-registry-01 Thread-Index: AcU7y5OdlVE/iJjcRQusEO97NBuiHgAARIMg From: "Addison Phillips" To: "JFC (Jefsey) Morfin" , "John Cowan" X-OriginalArrivalTime: 07 Apr 2005 23:51:33.0040 (UTC) FILETIME=[BA084B00:01C53BCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable ? Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > Sent: jeudi 7 avril 2005 16:36 > To: Addison Phillips; John Cowan > Cc: ltru@ietf.org > Subject: RE: [Ltru] John Cowan's substantive = commentsondraft-ietf-ltru- > registry-01 >=20 > At 19:26 07/04/2005, Addison Phillips wrote: > > > URIs are ASCII by definition. I am not proposing an IRI. > >You're not, but it is rapidly becoming reflexive for me to do so >=20 > Here we are. At last. > jfc >=20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 20:22:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22634; Thu, 7 Apr 2005 20:22:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJhP3-0000P8-Pn; Thu, 07 Apr 2005 20:31:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJhFz-00089o-Oq; Thu, 07 Apr 2005 20:21:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJhFy-00089j-34 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 20:21:54 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22613 for ; Thu, 7 Apr 2005 20:21:51 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJhD7-0002mm-3g for ltru@lists.ietf.org; Fri, 08 Apr 2005 02:18:57 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 02:18:57 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 02:18:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Apr 2005 02:19:03 +0200 Organization: Lines: 9 Message-ID: <4255CDF7.56D3@xyzzy.claranet.de> References: <4255BB70.EE8@xyzzy.claranet.de> <6.1.2.0.2.20050408010859.033e17f0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: quoted-printable Subject: [Ltru] Re: registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable JFC (Jefsey) Morfin wrote: > crossculture validation is a warranty against monocultural > dominance. =46rom my POV "mono" isn't much worse than "bi", the English and French names for FO are both strange: Faroe vs. F=E9ro=E9. In their own language it's F=F8roya(r) - I'm not sure, bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 20:55:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24643; Thu, 7 Apr 2005 20:55:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJhvH-0001US-Uf; Thu, 07 Apr 2005 21:04:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJhii-0005of-Pj; Thu, 07 Apr 2005 20:51:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfmw-0005Py-W9 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 18:47:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17413 for ; Thu, 7 Apr 2005 18:47:47 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJfvZ-0006B2-SX for ltru@ietf.org; Thu, 07 Apr 2005 18:56:47 -0400 Received: from lns-p19-2-idf-82-251-152-231.adsl.proxad.net ([82.251.152.231] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJfmp-00041Z-I4 for ltru@ietf.org; Thu, 07 Apr 2005 15:47:44 -0700 Message-Id: <6.1.2.0.2.20050407155838.050827c0@pop.online.fr> X-Sender: jefsey@pop.online.fr X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 07 Apr 2005 15:59:54 +0200 To: ltru@ietf.org From: Jefsey Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - online.fr X-Spam-Score: 0.7 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 X-Mailman-Approved-At: Thu, 07 Apr 2005 20:51:34 -0400 Subject: [Ltru] interesting IETF archives on language tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 This URL may be of interest to some. http://www.watersprings.org/cgi-bin/namazu.cgi?query=language+tag&idxname=id&max=20&result=normal&sort=score jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 20:56:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24707; Thu, 7 Apr 2005 20:56:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJhvo-0001VG-Ar; Thu, 07 Apr 2005 21:05:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJhj8-0005pQ-9C; Thu, 07 Apr 2005 20:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJflz-0005B3-7g for ltru@megatron.ietf.org; Thu, 07 Apr 2005 18:46:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17366 for ; Thu, 7 Apr 2005 18:46:47 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJfuc-0006AE-2L for ltru@ietf.org; Thu, 07 Apr 2005 18:55:47 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMRWPF54IO00005R@mauve.mrochek.com> for ltru@ietf.org; Thu, 07 Apr 2005 15:46:45 -0700 (PDT) Date: Thu, 07 Apr 2005 15:25:26 -0700 (PDT) In-reply-to: "Your message dated Thu, 07 Apr 2005 13:01:34 -0700" <634978A7DF025A40BFEF33EB191E13BC0AEEFE84@irvmbxw01.quest.com> Message-id: <01LMTGD0JBSE00005R@mauve.mrochek.com> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFE84@irvmbxw01.quest.com> Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) To: Addison Phillips X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Thu, 07 Apr 2005 20:52:00 -0400 Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7BIT > > Maybe it's better than this obscure "don't use script tags > > unless you must, but we don't tell you when you must and when > > you shouldn't" (= no default script) rule. > How about a useful compromise? We seem to be going around in circles with no > way out. It seems to me that our options are limited if we need scripts (and > we do). I agree 100%. > In thinking about how you might move scripts down towards the end of the tag, > one of the thoughts I had was: gee, if scripts were just variants, then we > could put a Recommended Prefix on them. > Hmm... a recommended prefix... Clever! > What if we put Recommended Prefix fields onto script subtags in the registry? > This solves the default script problem because we are recommending when to > use the subtag (when your language is in the list for that subtag). > We don't have to identify them all on Day One, since we can add prefixes for > those we don't know over time using registration. Guidance can be provided that > script recommended prefixes should usually be added in groups of two or more > (that is, you don't want a prefix for a specific language unless the language > is commonly written in more than on script). Which in turn would minimize, if not outright prevent, overuse of script codes. > It doesn't break 3066 processing (still), but does help these implementations > by having users avoid creating tags such as "en-Latn-US" that don't have much > additional utility. Anything that would avoid such nonsense would help considerably. Indeed, superfluous use of script tags is one of my main worries here. At one point I considered suggesting wording to the effect that unnecessary script codes be avoided, but past experience with such directives has been mixed at best. Your idea of encoding it into the script registry is much, much better. It even has the added advantage of helping implementations avoid silly states. > It doesn't break implementations that choose, wisely or unwisely, to > implement those tags either. For example, if using the Brai/Latn subtag pair > with "en-*-US" is sensible for a certain application, then it isn't forbidden > and works with 3066-like implementations as long as users realize that they > must be consistent in the body of work. Cases where both script and country code tagging are useful as part of the same tag are tolerable as long as they are rare enough, I think, that the resulting breakage is, while not exactly welcome, livable. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 20:56:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24741; Thu, 7 Apr 2005 20:56:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJhwR-0001Vh-N4; Thu, 07 Apr 2005 21:05:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJhj8-0005pM-4W; Thu, 07 Apr 2005 20:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJfPh-0007ZG-D5 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 18:23:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15596 for ; Thu, 7 Apr 2005 18:23:46 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJfYK-0005PJ-Pc for ltru@ietf.org; Thu, 07 Apr 2005 18:32:45 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMRWPF54IO00005R@mauve.mrochek.com> for ltru@ietf.org; Thu, 07 Apr 2005 15:23:41 -0700 (PDT) Date: Thu, 07 Apr 2005 14:31:43 -0700 (PDT) In-reply-to: "Your message dated Thu, 07 Apr 2005 13:52:16 -0400" <20050407175216.GE9134@skunk.reutershealth.com> Message-id: <01LMTFJFCQ4400005R@mauve.mrochek.com> References: <01LMT5FFC4MO00005R@mauve.mrochek.com> <20050407175216.GE9134@skunk.reutershealth.com> Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) To: John Cowan X-Spam-Score: 0.3 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Thu, 07 Apr 2005 20:52:00 -0400 Cc: ltru@ietf.org, ned.freed@mrochek.com X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7BIT > ned.freed@mrochek.com scripsit: > > As you might expect, I am in complete agreement with Ira here. This break with > > backwards compatibility is going to cause a bunch of problems. I also find the > > assertion that implementations done in good faith to what was specified in RFC > > 1766 are "buggy and nonconformant" to be a bit disturbing. > Implementing RFC 1766 while ignoring IANA-registered tags is about > like implementing C while ignoring the "goto" statement. Most programs > compile. The analogy is a stretch in and of itself, but it is also irrelevant since the basis of comparison is a strawman. We're not talking about incompliant implementations here. A compliant RFC 3066 implementation can (and I know for a fact has) been written that handles these exceptions through an exception table, but still operates under the assumption that a two letter code in the second position is a country code but a two letter code elsewhere is not. Like it or not, there are lots of application domains where script information is much less readily available than country information. As such, it is entirely reasonable for these implementations to rely on extraction of country code information for the purposes of making finer grained matches. And this proposal breaks this. > > Speaking as a coauthor of MIME, I know better than most what sorts of > > compromises are required to make things backwards compatible. But having > > watched various attempts to do multimedia email prior to MIME fail due in large > > part to their lack of backwards compatibility, I also know what can happen if > > you don't hit the sweet spot on these matters. > The only way to ensure 100% backward compatibility is to change > nothing. Not true. The question is what was or was not standardized in the past. The rules for country code positioning were clearly written and clearly normative. The prefix matching rule, OTOH, was specifically called out as NOT necessarily being generally applicable in RFC 3066. > Putting the script subtag after the region subtag exchanges > one incompatibility for another, as Doug points out. I'm sorry, but I don't have the time to dig out what Doug said somewhere else. I assume he was referring to the fact that putting script codes after the country code breaks the short-test-prefix-match scheme in cases where both script and country code information is available and the script is more relevant. The difference is that there was never any guarantee given that the shortest-prefix-match approach would work well in all cases. > What is more, we > already have some language-script-region tags registered under RFC 3066 > (IANA hasn't posted them yet), so it's a fait accompli. Actually, sgn- created an exception situation long ago. (I suppose a fair number of implementations could safely ignore sgn- given the limited realm of applicability of sign languages, but others cetainly cannot.) > > Balkanization of how language tags are used is the last thing we want, and I > > think this is where we're going to end up if we break compatibility. > We are not breaking compatibility. You're effectively moving country codes to a new position in the string. That's breaking compatibility in my book. And since you referred to this previously as an incompatibility, I guess you agree... In any case, like Ira, I don't expect to win this argument. Nor do I have the time to argue the point at the level of frequency that is clearly needed on this list to make any sort of difference. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:05:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25424; Thu, 7 Apr 2005 21:05:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJi53-0001np-FS; Thu, 07 Apr 2005 21:14:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJhun-0000bT-9Q; Thu, 07 Apr 2005 21:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJhul-0000bJ-Bo for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:04:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25278 for ; Thu, 7 Apr 2005 21:04:01 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJi3Q-0001ln-GU for ltru@ietf.org; Thu, 07 Apr 2005 21:13:00 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJhuk-000Ab5-68 for ltru@ietf.org; Fri, 08 Apr 2005 01:04:02 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #885 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:04:02 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #885] split references between normative and informative X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi - (co-chair hat ON) This issue was raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00092.html There's really no choice in the matter, and the editors have done the edits, so I plan to mark this one "resolved". _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:05:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25449; Thu, 7 Apr 2005 21:05:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJi5H-0001ny-0m; Thu, 07 Apr 2005 21:14:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJhun-0000bX-EW; Thu, 07 Apr 2005 21:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJhum-0000bO-1X for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:04:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25281 for ; Thu, 7 Apr 2005 21:04:01 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJi3R-0001ls-AP for ltru@ietf.org; Thu, 07 Apr 2005 21:13:01 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJhuk-000AbM-JC; Fri, 08 Apr 2005 01:04:02 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #885 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:04:02 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #885] split references between normative and informative X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi - (co-chair hat ON) This issue was raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00092.html There's really no choice in the matter, and the editors have done the edits, so I plan to mark this one "resolved". _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:11:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25822; Thu, 7 Apr 2005 21:11:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiAw-0001z0-OR; Thu, 07 Apr 2005 21:20:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi1o-0002D0-1v; Thu, 07 Apr 2005 21:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi1m-0002Ck-L0 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:11:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25723 for ; Thu, 7 Apr 2005 21:11:16 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiAR-0001yH-Vf for ltru@ietf.org; Thu, 07 Apr 2005 21:20:16 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJi1l-000BWG-JV; Fri, 08 Apr 2005 01:11:17 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #886 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:11:17 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #886] registry should add French translations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - (co-chair hat ON) The question of adding French translations of specific fields in the registry was raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00094.html Though this was discussed at some length on the ietf-languages list, I'd like to verify that we have a rough consensus in this WG. I believe that consensus is to reject this proposal. Please speak up if you have compelling technical arguments that this WG should add French translations of specific fields in the registry. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:13:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25954; Thu, 7 Apr 2005 21:13:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiCL-00023K-Vl; Thu, 07 Apr 2005 21:22:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi1q-0002E6-5f; Thu, 07 Apr 2005 21:11:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi1n-0002Cq-4j for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:11:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25726 for ; Thu, 7 Apr 2005 21:11:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiAR-0001yF-FC for ltru@ietf.org; Thu, 07 Apr 2005 21:20:16 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJi1l-000BVN-2W for ltru@ietf.org; Fri, 08 Apr 2005 01:11:17 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #886 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:11:17 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #886] registry should add French translations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - (co-chair hat ON) The question of adding French translations of specific fields in the registry was raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00094.html Though this was discussed at some length on the ietf-languages list, I'd like to verify that we have a rough consensus in this WG. I believe that consensus is to reject this proposal. Please speak up if you have compelling technical arguments that this WG should add French translations of specific fields in the registry. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:24:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27025; Thu, 7 Apr 2005 21:24:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiNI-0002TH-KB; Thu, 07 Apr 2005 21:33:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi4K-0002hd-Ty; Thu, 07 Apr 2005 21:13:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi4K-0002g4-02 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:13:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26034 for ; Thu, 7 Apr 2005 21:13:53 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiCz-00024M-BP for ltru@ietf.org; Thu, 07 Apr 2005 21:22:53 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJi4I-000BvD-VC for ltru@ietf.org; Fri, 08 Apr 2005 01:13:54 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #887 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:13:54 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #887] references to 3066 and 1766 should be informative X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi - (co-chair hat ON) This issue was raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00103.html I believe there is a rough Consensus to make the change, to wit, if any references to 3066 and 1766 remain in the document, they should be made informative rather than normative. Objections? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:25:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27094; Thu, 7 Apr 2005 21:25:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiNm-0002UP-MS; Thu, 07 Apr 2005 21:34:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi4P-0002hu-1c; Thu, 07 Apr 2005 21:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi4K-0002ga-DV for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:13:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26037 for ; Thu, 7 Apr 2005 21:13:54 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiCz-00024O-P1 for ltru@ietf.org; Thu, 07 Apr 2005 21:22:54 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJi4J-000BvN-Cb; Fri, 08 Apr 2005 01:13:55 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #887 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:13:55 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #887] references to 3066 and 1766 should be informative X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi - (co-chair hat ON) This issue was raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00103.html I believe there is a rough Consensus to make the change, to wit, if any references to 3066 and 1766 remain in the document, they should be made informative rather than normative. Objections? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:25:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27151; Thu, 7 Apr 2005 21:25:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiOV-0002V2-Fe; Thu, 07 Apr 2005 21:34:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiBP-000342-P3; Thu, 07 Apr 2005 21:21:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiBM-00033q-8D for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:21:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26550 for ; Thu, 7 Apr 2005 21:21:10 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiK0-0002IK-Lx for ltru@ietf.org; Thu, 07 Apr 2005 21:30:09 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJiBK-000Czn-1Z; Fri, 08 Apr 2005 01:21:10 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #890 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:21:10 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #890] include character set information in tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi - (co-chair hat ON) This Issue was raised in http://www.ietf.org/mail-archive/web/ltru/current/msg00161.html Subsequent discussion revealed no support for the proposal. Consequently, I plan to mark this one "rejected". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:28:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27307; Thu, 7 Apr 2005 21:28:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiQt-0002aq-Hy; Thu, 07 Apr 2005 21:37:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiBL-00033m-KD; Thu, 07 Apr 2005 21:21:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiBK-00033h-U4 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:21:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26547 for ; Thu, 7 Apr 2005 21:21:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiK0-0002II-Be for ltru@ietf.org; Thu, 07 Apr 2005 21:30:08 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJiBJ-000Czf-LR for ltru@ietf.org; Fri, 08 Apr 2005 01:21:09 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #890 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:21:09 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #890] include character set information in tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi - (co-chair hat ON) This Issue was raised in http://www.ietf.org/mail-archive/web/ltru/current/msg00161.html Subsequent discussion revealed no support for the proposal. Consequently, I plan to mark this one "rejected". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:29:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27522; Thu, 7 Apr 2005 21:29:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiS9-0002cM-6r; Thu, 07 Apr 2005 21:38:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi7J-0002tB-9y; Thu, 07 Apr 2005 21:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi7F-0002sq-Oq for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:16:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26137 for ; Thu, 7 Apr 2005 21:16:55 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiFu-00029M-VC for ltru@ietf.org; Thu, 07 Apr 2005 21:25:55 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJi7E-000CTf-HN; Fri, 08 Apr 2005 01:16:56 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #888 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:16:56 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #888] ietf-languages mailing list is not the IANA list presented in RFC 3066 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - (co-chair hat ON) Issue raised in http://www.ietf.org/mail-archive/web/ltru/current/msg00094.html I believe this issue should be marked "rejected." The ietf-languages address works as advertised. In keeping with longstanding IETF practice, where the list is physically hosted is not and should not be mandated. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:29:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27540; Thu, 7 Apr 2005 21:29:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiSB-0002cQ-0c; Thu, 07 Apr 2005 21:38:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi9o-0002xH-Ru; Thu, 07 Apr 2005 21:19:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi9m-0002x4-RM for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:19:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26370 for ; Thu, 7 Apr 2005 21:19:32 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiIS-0002Fw-7x for ltru@ietf.org; Thu, 07 Apr 2005 21:28:32 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJi9l-000Ci8-QF for ltru@ietf.org; Fri, 08 Apr 2005 01:19:33 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #889 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:19:33 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #889] registry should be consistent with ISO lists X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - (co-chair hat ON) This issue was raised in http://www.ietf.org/mail-archive/web/ltru/current/msg00094.html Coping with changes in the ISO lists is one of the reasons for this work, as documented in the WG charter. Consequently, I believe we have little choice but to reject this one, unless I've completely misunderstood the issue statement. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:29:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27577; Thu, 7 Apr 2005 21:29:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiSN-0002ch-9b; Thu, 07 Apr 2005 21:38:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi9p-0002xL-1g; Thu, 07 Apr 2005 21:19:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi9n-0002x9-EZ for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:19:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26375 for ; Thu, 7 Apr 2005 21:19:33 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiIS-0002G0-MW for ltru@ietf.org; Thu, 07 Apr 2005 21:28:33 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJi9m-000CiS-80; Fri, 08 Apr 2005 01:19:34 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #889 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:19:34 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #889] registry should be consistent with ISO lists X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - (co-chair hat ON) This issue was raised in http://www.ietf.org/mail-archive/web/ltru/current/msg00094.html Coping with changes in the ISO lists is one of the reasons for this work, as documented in the WG charter. Consequently, I believe we have little choice but to reject this one, unless I've completely misunderstood the issue statement. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:30:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27664; Thu, 7 Apr 2005 21:30:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiSt-0002do-Sr; Thu, 07 Apr 2005 21:39:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi7G-0002t2-RH; Thu, 07 Apr 2005 21:16:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJi7F-0002sl-A8 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:16:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26130 for ; Thu, 7 Apr 2005 21:16:55 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJiFu-00029C-Ih for ltru@ietf.org; Thu, 07 Apr 2005 21:25:54 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJi7E-000CTY-5E for ltru@ietf.org; Fri, 08 Apr 2005 01:16:56 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #888 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:16:56 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #888] ietf-languages mailing list is not the IANA list presented in RFC 3066 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - (co-chair hat ON) Issue raised in http://www.ietf.org/mail-archive/web/ltru/current/msg00094.html I believe this issue should be marked "rejected." The ietf-languages address works as advertised. In keeping with longstanding IETF practice, where the list is physically hosted is not and should not be mandated. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:48:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28721; Thu, 7 Apr 2005 21:48:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJikJ-0003B7-IR; Thu, 07 Apr 2005 21:57:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJibY-0001hO-2M; Thu, 07 Apr 2005 21:48:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJibT-0001gr-Uf for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:48:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28709 for ; Thu, 7 Apr 2005 21:48:09 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJik6-0003Al-JJ for ltru@ietf.org; Thu, 07 Apr 2005 21:57:09 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJibL-000FVP-H5 for ltru@ietf.org; Fri, 08 Apr 2005 01:48:03 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #891 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:48:03 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #891] support non-ASCII representation of native name of language X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi - (co-chair hat ON) This issue was raised in http://www.ietf.org/mail-archive/web/ltru/current/msg00248.html I believe further discussion is needed before we declare consensus to accept or reject this proposal. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:49:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28800; Thu, 7 Apr 2005 21:49:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJilE-0003Ev-1X; Thu, 07 Apr 2005 21:58:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJibU-0001h0-U9; Thu, 07 Apr 2005 21:48:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJibS-0001gm-V4 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:48:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28706 for ; Thu, 7 Apr 2005 21:48:08 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJik6-0003Ap-JN for ltru@ietf.org; Thu, 07 Apr 2005 21:57:08 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJibM-000FVe-1a; Fri, 08 Apr 2005 01:48:04 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #891 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:48:04 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #891] support non-ASCII representation of native name of language X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi - (co-chair hat ON) This issue was raised in http://www.ietf.org/mail-archive/web/ltru/current/msg00248.html I believe further discussion is needed before we declare consensus to accept or reject this proposal. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 21:53:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29237; Thu, 7 Apr 2005 21:53:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJioy-0003Mr-H4; Thu, 07 Apr 2005 22:02:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiey-0002G6-Th; Thu, 07 Apr 2005 21:51:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiey-0002Fw-1M for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:51:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28988 for ; Thu, 7 Apr 2005 21:51:45 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJind-0003K1-O3 for ltru@ietf.org; Thu, 07 Apr 2005 22:00:45 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJiex-000Fxs-1N for ltru@ietf.org; Fri, 08 Apr 2005 01:51:47 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #893 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:51:47 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #893] support incremental updates of registry shadows X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi - (co-chair hat ON) Hinted at in several postings, this issue was raised in http://www.ietf.org/mail-archive/web/ltru/current/msg00302.html Discussion is needed before we try to claim consensus. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:00:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29623; Thu, 7 Apr 2005 22:00:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJivr-0003XI-84; Thu, 07 Apr 2005 22:09:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJif2-0002GA-0N; Thu, 07 Apr 2005 21:51:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiey-0002G1-EL for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:51:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28991 for ; Thu, 7 Apr 2005 21:51:46 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJine-0003K5-4h for ltru@ietf.org; Thu, 07 Apr 2005 22:00:46 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJiex-000Fy1-Ds; Fri, 08 Apr 2005 01:51:47 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #893 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:51:47 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #893] support incremental updates of registry shadows X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi - (co-chair hat ON) Hinted at in several postings, this issue was raised in http://www.ietf.org/mail-archive/web/ltru/current/msg00302.html Discussion is needed before we try to claim consensus. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:01:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29704; Thu, 7 Apr 2005 22:01:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJix2-0003bh-Im; Thu, 07 Apr 2005 22:10:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJik3-0002Tc-DU; Thu, 07 Apr 2005 21:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJik2-0002TS-3X for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:57:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29411 for ; Thu, 7 Apr 2005 21:56:59 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJish-0003RZ-Rq for ltru@ietf.org; Thu, 07 Apr 2005 22:06:00 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJik1-000GSa-3t for ltru@ietf.org; Fri, 08 Apr 2005 01:57:01 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #895 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:57:01 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #895] remove region subtags withdrawn from ISO 3166 before 1988 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - In http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html there is a proposal to remove region subtags withdrawn from ISO 3166 before 1988. Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:02:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29761; Thu, 7 Apr 2005 22:02:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJixc-0003c3-UO; Thu, 07 Apr 2005 22:11:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJik3-0002Tg-H2; Thu, 07 Apr 2005 21:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJik2-0002TX-Fo for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:57:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29414 for ; Thu, 7 Apr 2005 21:57:00 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJisi-0003Ra-7p for ltru@ietf.org; Thu, 07 Apr 2005 22:06:00 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJik1-000GSh-Fo; Fri, 08 Apr 2005 01:57:01 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #895 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:57:01 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #895] remove region subtags withdrawn from ISO 3166 before 1988 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - In http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html there is a proposal to remove region subtags withdrawn from ISO 3166 before 1988. Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:02:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29794; Thu, 7 Apr 2005 22:02:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJixl-0003cG-SR; Thu, 07 Apr 2005 22:11:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJinS-0002Z0-81; Thu, 07 Apr 2005 22:00:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJidp-0002EX-Fg for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:50:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28944 for ; Thu, 7 Apr 2005 21:50:35 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJimU-0003GR-5a for ltru@ietf.org; Thu, 07 Apr 2005 21:59:35 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJidn-000FqN-El for ltru@ietf.org; Fri, 08 Apr 2005 01:50:35 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #892 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 01:50:35 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Thu, 07 Apr 2005 22:00:33 -0400 Subject: [Ltru] Re: [psg.com #892] instructions for IANA if registry becomes "too large" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi - (co-chair hat ON) The question of what IANA should be told to do to ease access to the registry if it becomes "too large" was raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00275.html I think additional discussion is needed on this topic before we call consensus. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:02:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29817; Thu, 7 Apr 2005 22:02:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJixn-0003cP-NK; Thu, 07 Apr 2005 22:11:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiml-0002WC-Pi; Thu, 07 Apr 2005 21:59:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiiU-0002On-Dp for ltru@megatron.ietf.org; Thu, 07 Apr 2005 21:55:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29348 for ; Thu, 7 Apr 2005 21:55:24 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJirA-0003QN-5A for ltru@ietf.org; Thu, 07 Apr 2005 22:04:24 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJiiT-000GHg-DR for ltru@ietf.org; Fri, 08 Apr 2005 01:55:25 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #894 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-matching@rt.psg.com Date: Fri, 08 Apr 2005 01:55:25 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-Mailman-Approved-At: Thu, 07 Apr 2005 21:59:50 -0400 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #894] AutoReply: add figure-of-merit matching X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-matching@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - (co-chair hat ON) Proposal for additional matching algorithms appeared in http://www.ietf.org/mail-archive/web/ltru/current/msg00313.html Though additional discussion on the details is needed, I think there is a clear consensus that this approach should be added to the matching document, and that this issue can be marked "resolved" when that i-d becomes available. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:05:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29982; Thu, 7 Apr 2005 22:05:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj0j-0003hz-R1; Thu, 07 Apr 2005 22:14:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJirf-0004Az-9X; Thu, 07 Apr 2005 22:04:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJire-0004Aq-4k for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:04:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29976 for ; Thu, 7 Apr 2005 22:04:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj0I-0003hL-VD for ltru@ietf.org; Thu, 07 Apr 2005 22:13:52 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJirc-000HUt-54; Fri, 08 Apr 2005 02:04:52 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #896 Precedence: bulk To: dewell@adelphia.net X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Fri, 08 Apr 2005 02:04:52 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #896] change descriptions for region subtags withdrawn from ISO 3166 after 1988 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - This proposal was set forth in http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:05:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00045; Thu, 7 Apr 2005 22:05:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj1B-0003iW-Eg; Thu, 07 Apr 2005 22:14:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJirf-0004Av-5e; Thu, 07 Apr 2005 22:04:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJird-0004Al-Ox for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:04:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29973 for ; Thu, 7 Apr 2005 22:04:51 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj0I-0003hK-JD for ltru@ietf.org; Thu, 07 Apr 2005 22:13:51 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJirb-000HUm-PM for ltru@ietf.org; Fri, 08 Apr 2005 02:04:51 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #896 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Fri, 08 Apr 2005 02:04:51 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #896] change descriptions for region subtags withdrawn from ISO 3166 after 1988 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - This proposal was set forth in http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:06:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00120; Thu, 7 Apr 2005 22:06:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj2G-0003m9-A6; Thu, 07 Apr 2005 22:15:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJisj-0004HU-JE; Thu, 07 Apr 2005 22:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJisi-0004HK-9h for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:06:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00063 for ; Thu, 7 Apr 2005 22:05:57 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj1O-0003ib-1Q for ltru@ietf.org; Thu, 07 Apr 2005 22:14:58 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJish-000Hm6-6v for ltru@ietf.org; Fri, 08 Apr 2005 02:05:59 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #897 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Fri, 08 Apr 2005 02:05:59 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #897] change canonical values to match ISO 3166:1998 for region subtags withdrawn after 1988 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi - The detailed proposal was in http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:07:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00159; Thu, 7 Apr 2005 22:07:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj2f-0003mQ-TT; Thu, 07 Apr 2005 22:16:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJisl-0004HY-Mz; Thu, 07 Apr 2005 22:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJisi-0004HP-JX for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:06:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00066 for ; Thu, 7 Apr 2005 22:05:58 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj1O-0003ic-E1 for ltru@ietf.org; Thu, 07 Apr 2005 22:14:58 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJish-000HmE-Jg; Fri, 08 Apr 2005 02:05:59 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #897 Precedence: bulk To: dewell@adelphia.net X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Fri, 08 Apr 2005 02:05:59 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #897] change canonical values to match ISO 3166:1998 for region subtags withdrawn after 1988 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi - The detailed proposal was in http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:09:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00308; Thu, 7 Apr 2005 22:09:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj4S-0003og-Pn; Thu, 07 Apr 2005 22:18:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiuy-0004sS-Dd; Thu, 07 Apr 2005 22:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiuv-0004rw-CE for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:08:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00270 for ; Thu, 7 Apr 2005 22:08:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj3b-0003nf-6t for ltru@ietf.org; Thu, 07 Apr 2005 22:17:15 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJiuu-000I6J-Bq; Fri, 08 Apr 2005 02:08:16 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #898 Precedence: bulk To: dewell@adelphia.net X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Fri, 08 Apr 2005 02:08:16 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #898] change comments for region subtags withdrawn from ISO 3166 after 1988 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi - This proposal came from http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:09:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00390; Thu, 7 Apr 2005 22:09:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj5A-0003rs-MN; Thu, 07 Apr 2005 22:18:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiuw-0004s1-8W; Thu, 07 Apr 2005 22:08:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiuu-0004rr-W8 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:08:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00266 for ; Thu, 7 Apr 2005 22:08:14 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj3a-0003nd-Qw for ltru@ietf.org; Thu, 07 Apr 2005 22:17:15 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJiut-000I6C-Vt for ltru@ietf.org; Fri, 08 Apr 2005 02:08:15 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #898 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Fri, 08 Apr 2005 02:08:15 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #898] change comments for region subtags withdrawn from ISO 3166 after 1988 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi - This proposal came from http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:10:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00415; Thu, 7 Apr 2005 22:10:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj5K-0003s5-H0; Thu, 07 Apr 2005 22:19:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJivw-0004wT-Iu; Thu, 07 Apr 2005 22:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJivu-0004wB-Gl for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:09:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00336 for ; Thu, 7 Apr 2005 22:09:16 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj4a-0003ot-CN for ltru@ietf.org; Thu, 07 Apr 2005 22:18:16 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJivt-000ICR-G3; Fri, 08 Apr 2005 02:09:17 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #899 Precedence: bulk To: dewell@adelphia.net X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Fri, 08 Apr 2005 02:09:17 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #899] remove region subtag 172 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - The proposal to remove region subtag 172 appeared in http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:10:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00444; Thu, 7 Apr 2005 22:10:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj5U-0003sB-Gq; Thu, 07 Apr 2005 22:19:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJivw-0004wg-N8; Thu, 07 Apr 2005 22:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJivv-0004wG-2x for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:09:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00339 for ; Thu, 7 Apr 2005 22:09:16 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj4Z-0003or-Ul for ltru@ietf.org; Thu, 07 Apr 2005 22:18:17 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJivs-000ICG-W5 for ltru@ietf.org; Fri, 08 Apr 2005 02:09:17 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #899 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Fri, 08 Apr 2005 02:09:16 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #899] remove region subtag 172 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - The proposal to remove region subtag 172 appeared in http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:12:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00759; Thu, 7 Apr 2005 22:12:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj8B-0003yk-9m; Thu, 07 Apr 2005 22:21:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiyW-0005rv-KA; Thu, 07 Apr 2005 22:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiyT-0005re-V8 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:11:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00601 for ; Thu, 7 Apr 2005 22:11:55 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj79-0003ts-RN for ltru@ietf.org; Thu, 07 Apr 2005 22:20:56 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJiyS-000IfU-VA for ltru@ietf.org; Fri, 08 Apr 2005 02:11:56 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #900 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Fri, 08 Apr 2005 02:11:56 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #900] remove region subtag 200 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - Message http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html proposed removing region subtag 200. Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:13:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00781; Thu, 7 Apr 2005 22:13:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj8S-0003yt-Fp; Thu, 07 Apr 2005 22:22:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiyX-0005rz-25; Thu, 07 Apr 2005 22:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJiyU-0005rf-Je for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:11:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00604 for ; Thu, 7 Apr 2005 22:11:55 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj7A-0003tu-7N for ltru@ietf.org; Thu, 07 Apr 2005 22:20:56 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJiyT-000Ifb-BC; Fri, 08 Apr 2005 02:11:57 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #900 Precedence: bulk To: dewell@adelphia.net X-RT-Loop-Prevention: psg.com From: rt+ltru-initial@rt.psg.com Date: Fri, 08 Apr 2005 02:11:57 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #900] remove region subtag 200 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-initial@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - Message http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html proposed removing region subtag 200. Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:13:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00821; Thu, 7 Apr 2005 22:13:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj8x-0003zW-Hv; Thu, 07 Apr 2005 22:22:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJizU-000616-76; Thu, 07 Apr 2005 22:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJizS-00060u-KY for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:12:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00746 for ; Thu, 7 Apr 2005 22:12:56 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj88-0003yX-HH for ltru@ietf.org; Thu, 07 Apr 2005 22:21:56 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJizR-000Iks-L7 for ltru@ietf.org; Fri, 08 Apr 2005 02:12:57 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #901 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 02:12:57 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #901] add "Deprecated" field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - Message http://www.ietf.org/mail-archive/web/ltru/current/msg00479.htm proposes adding a "Deprecated" field. Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:14:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00851; Thu, 7 Apr 2005 22:14:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj9S-0003zi-1t; Thu, 07 Apr 2005 22:23:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJizU-00061D-Bs; Thu, 07 Apr 2005 22:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJizT-00060z-3M for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:12:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00750 for ; Thu, 7 Apr 2005 22:12:56 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJj88-0003yY-TQ for ltru@ietf.org; Thu, 07 Apr 2005 22:21:57 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJizS-000Ikz-0o; Fri, 08 Apr 2005 02:12:58 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #901 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 02:12:58 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #901] add "Deprecated" field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - Message http://www.ietf.org/mail-archive/web/ltru/current/msg00479.htm proposes adding a "Deprecated" field. Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 22:30:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01824; Thu, 7 Apr 2005 22:30:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJjPQ-0004Rj-Uf; Thu, 07 Apr 2005 22:39:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjGW-00085C-0J; Thu, 07 Apr 2005 22:30:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjGU-000857-38 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 22:30:34 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01806 for ; Thu, 7 Apr 2005 22:30:30 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJjDe-00058f-Ba for ltru@lists.ietf.org; Fri, 08 Apr 2005 04:27:38 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 04:27:38 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 04:27:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Apr 2005 04:24:53 +0200 Organization: Lines: 8 Message-ID: <4255EB75.728D@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: remove region subtag 200 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit rt+ltru-initial@rt.psg.com wrote: > removing region subtag 200. Yes, a hopeless case. Dito 172 in ticket #899, for the reasons stated by Doug. Dito anything else in Doug's http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:10:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04503; Thu, 7 Apr 2005 23:10:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk1j-0005e0-LD; Thu, 07 Apr 2005 23:19:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjq5-0006FV-Cf; Thu, 07 Apr 2005 23:07:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjq4-0006FM-Kk for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:07:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04346 for ; Thu, 7 Apr 2005 23:07:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJjyj-0005Z6-IG for ltru@ietf.org; Thu, 07 Apr 2005 23:16:18 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJjq2-000P5R-5W for ltru@ietf.org; Fri, 08 Apr 2005 03:07:18 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #903 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:07:18 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #903] add "Former_Name" field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - http://www.ietf.org/mail-archive/web/ltru/current/msg00479.html requests addition of a "Former_Name" field. Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:11:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04539; Thu, 7 Apr 2005 23:11:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk2M-0005eV-Dn; Thu, 07 Apr 2005 23:20:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjq5-0006FR-9a; Thu, 07 Apr 2005 23:07:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjq4-0006FG-2V for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:07:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04343 for ; Thu, 7 Apr 2005 23:07:16 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJjyk-0005Z7-2e for ltru@ietf.org; Thu, 07 Apr 2005 23:16:18 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJjq2-000P5Y-I5; Fri, 08 Apr 2005 03:07:18 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #903 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:07:18 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #903] add "Former_Name" field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - http://www.ietf.org/mail-archive/web/ltru/current/msg00479.html requests addition of a "Former_Name" field. Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:11:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04618; Thu, 7 Apr 2005 23:11:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk36-0005fs-5Q; Thu, 07 Apr 2005 23:20:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjpV-0006ED-RN; Thu, 07 Apr 2005 23:06:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjpT-0006Dv-0I for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:06:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04282 for ; Thu, 7 Apr 2005 23:06:39 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJjy7-0005YE-KY for ltru@ietf.org; Thu, 07 Apr 2005 23:15:40 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJjpP-000Oz1-PS for ltru@ietf.org; Fri, 08 Apr 2005 03:06:39 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #902 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:06:39 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #902] AutoReply: add "Name_Changed" field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi - The message http://www.ietf.org/mail-archive/web/ltru/current/msg00479.html requests the addition of a "Name_Changed" field. Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:12:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04666; Thu, 7 Apr 2005 23:12:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk3e-0005gi-IS; Thu, 07 Apr 2005 23:21:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjpS-0006Dr-Mr; Thu, 07 Apr 2005 23:06:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjpR-0006Dm-Of for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:06:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04278 for ; Thu, 7 Apr 2005 23:06:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJjy7-0005YF-O0 for ltru@ietf.org; Thu, 07 Apr 2005 23:15:39 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJjpQ-000OzQ-8K; Fri, 08 Apr 2005 03:06:40 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #902 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:06:40 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #902] AutoReply: add "Name_Changed" field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Hi - The message http://www.ietf.org/mail-archive/web/ltru/current/msg00479.html requests the addition of a "Name_Changed" field. Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:12:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04699; Thu, 7 Apr 2005 23:12:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk3f-0005gs-J3; Thu, 07 Apr 2005 23:21:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjqm-0006Gd-Jt; Thu, 07 Apr 2005 23:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjql-0006GN-Ai for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:08:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04400 for ; Thu, 7 Apr 2005 23:08:00 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJjzR-0005Zs-3g for ltru@ietf.org; Thu, 07 Apr 2005 23:17:01 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJjqj-000PBH-Ni; Fri, 08 Apr 2005 03:08:01 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #904 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:08:01 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #904] add "Comment" field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - http://www.ietf.org/mail-archive/web/ltru/current/msg00482.html requests addition of a "Comment" field. Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:12:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04818; Thu, 7 Apr 2005 23:12:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk44-0005jy-6B; Thu, 07 Apr 2005 23:21:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjuC-0006UW-MK; Thu, 07 Apr 2005 23:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjuB-0006UB-7o for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:11:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04587 for ; Thu, 7 Apr 2005 23:11:32 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk2r-0005fG-C7 for ltru@ietf.org; Thu, 07 Apr 2005 23:20:33 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJju9-000PeN-V6 for ltru@ietf.org; Fri, 08 Apr 2005 03:11:33 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #906 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:11:33 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #906] reference to ABNF needs update X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi - (co-chair hat ON) Issue raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00537.html The consensus is to change the reference to current the i-d approved by IESG. I'll be marking this item "resolved." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:13:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04907; Thu, 7 Apr 2005 23:13:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk4a-0005kc-6c; Thu, 07 Apr 2005 23:22:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjuC-0006Ua-Pt; Thu, 07 Apr 2005 23:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjuB-0006UR-K0 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:11:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04590 for ; Thu, 7 Apr 2005 23:11:32 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk2r-0005fH-Nl for ltru@ietf.org; Thu, 07 Apr 2005 23:20:33 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJjuA-000PeV-B3; Fri, 08 Apr 2005 03:11:34 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #906 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:11:34 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #906] reference to ABNF needs update X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Hi - (co-chair hat ON) Issue raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00537.html The consensus is to change the reference to current the i-d approved by IESG. I'll be marking this item "resolved." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:13:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04934; Thu, 7 Apr 2005 23:13:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk4k-0005ko-9e; Thu, 07 Apr 2005 23:22:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjqm-0006GZ-GO; Thu, 07 Apr 2005 23:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjql-0006GO-BE for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:08:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04399 for ; Thu, 7 Apr 2005 23:08:00 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJjzQ-0005Zq-OS for ltru@ietf.org; Thu, 07 Apr 2005 23:17:00 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJjqj-000PB8-BK for ltru@ietf.org; Fri, 08 Apr 2005 03:08:01 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #904 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:08:01 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #904] add "Comment" field X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi - http://www.ietf.org/mail-archive/web/ltru/current/msg00482.html requests addition of a "Comment" field. Discussion? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:14:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05008; Thu, 7 Apr 2005 23:14:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk5a-0005lp-0S; Thu, 07 Apr 2005 23:23:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjsn-0006JX-BQ; Thu, 07 Apr 2005 23:10:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjsl-0006J9-Ri for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:10:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04493 for ; Thu, 7 Apr 2005 23:10:04 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk1Q-0005de-EN for ltru@ietf.org; Thu, 07 Apr 2005 23:19:05 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJjsi-000POa-EV; Fri, 08 Apr 2005 03:10:04 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #905 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:10:04 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #905] update IPR boilerplate X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi - (WG co-chair hat ON) This issue raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00520.html Consensus is to update boilerplate when xml2rfc supports it. I'll be changing this issue's status to "resolved." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:35:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06458; Thu, 7 Apr 2005 23:35:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkPz-0006Q5-EX; Thu, 07 Apr 2005 23:44:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkCY-00025d-51; Thu, 07 Apr 2005 23:30:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkCX-00025Y-5z for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:30:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05965 for ; Thu, 7 Apr 2005 23:30:29 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkLC-0006I7-61 for ltru@ietf.org; Thu, 07 Apr 2005 23:39:31 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJkCT-0000vn-00 for ltru@ietf.org; Thu, 07 Apr 2005 20:30:29 -0700 Message-ID: <00e101c53beb$7da8e060$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <4255B65B.4776@xyzzy.claranet.de> Date: Thu, 7 Apr 2005 20:31:45 -0700 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: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Ltru] Using RT X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Hi - (NOTE NEW SUBJECT!) > From: "Frank Ellermann" > To: > Sent: Thursday, April 07, 2005 3:38 PM > Subject: [Ltru] Re: fix ABNF bugs > > rt+ltru-registry@rt.psg.com wrote: > > > Already done. > > Does the ticket system now read subjects and echo anything > it understands ? The same article with three Message-IDs: > > <634978A7DF025A40BFEF33EB191E13BC0AEEFEE1@irvmbxw01.quest.com> > > ... The first duplicate, and how it can be avoided, is explained in http://www.ietf.org/mail-archive/web/ltru/current/msg00707.html I'm not sure about the second one; I've sent a query to someone who knows much more about these things. General instructions on the use of the system are at http://rt.psg.com/ If you keep the "[psg.com #xxx]" in the subject line and post to the appropriate rt+ltru-*@rt.psg.com address, the message will go into the history of that particular ticket and, since ltru@ietf.org is a "watcher", a copy will go to this list automatically. Where the extra copy comes from is not clear; I hope to find out soon, for the sake of everyone's sanity. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:51:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07967; Thu, 7 Apr 2005 23:51:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkfN-0006wz-OO; Fri, 08 Apr 2005 00:00:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkU8-00042L-G5; Thu, 07 Apr 2005 23:48:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkU7-00042G-CN for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:48:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07624 for ; Thu, 7 Apr 2005 23:48:39 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkcm-0006ri-B0 for ltru@ietf.org; Thu, 07 Apr 2005 23:57:41 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJkU3-0005Fu-00 for ltru@ietf.org; Thu, 07 Apr 2005 20:48:39 -0700 Message-ID: <010601c53bee$0725cc20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <00e901c53baa$d18d3aa0$7f1afea9@oemcomputer><4255A612.3BFC@xyzzy.claranet.de> <20050407215804.GG10046@skunk.reutershealth.com> Subject: Re: [Ltru] Re: [psg.com #875] should initial registry contents bemade into an internet-draft? Date: Thu, 7 Apr 2005 20:49:55 -0700 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: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi - > From: "John Cowan" > To: "Frank Ellermann" > Cc: > Sent: Thursday, April 07, 2005 2:58 PM > Subject: Re: [Ltru] Re: [psg.com #875] should initial registry contents bemade into an internet-draft? ... > This is academic. An I-D that is not intended to become an RFC does not > have to follow RFC format in any way. ... Actually,the requirements in http://www.ietf.org/ietf/1id-guidelines.html and http://www.ietf.org/ID-Checklist.html will result in something that is remarkably RFC-like in format. The secretariat is becoming stricter in enforcing these long-standing requirements. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:53:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08090; Thu, 7 Apr 2005 23:53:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkh8-0007AS-G1; Fri, 08 Apr 2005 00:02:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkWm-0004BJ-Vd; Thu, 07 Apr 2005 23:51:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkWl-0004B9-Bi for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:51:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07999 for ; Thu, 7 Apr 2005 23:51:24 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkfS-0006xL-2c for ltru@ietf.org; Fri, 08 Apr 2005 00:00:26 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJkWk-0003ZK-Au for ltru@ietf.org; Fri, 08 Apr 2005 03:51:26 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: RE: [Ltru] Re: [psg.com #904] add "Comment" field RT-Ticket: psg.com #904 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:51:26 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 No discussion. We already have a Comments field. It was previously called "Notes". This isn't worthy of discussion. Please don't make open issues out of things like this. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of rt+ltru-registry@rt.psg.com > Sent: jeudi 7 avril 2005 20:08 > Cc: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #904] add "Comment" field > > Hi - > > http://www.ietf.org/mail-archive/web/ltru/current/msg00482.html > requests addition of a "Comment" field. > > Discussion? > > Randy > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:53:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08157; Thu, 7 Apr 2005 23:53:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkhM-0007Av-7j; Fri, 08 Apr 2005 00:02:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkYQ-0004Dd-L0; Thu, 07 Apr 2005 23:53:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkYO-0004DP-0J for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:53:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08079 for ; Thu, 7 Apr 2005 23:53:04 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkh3-0007AI-Jz for ltru@ietf.org; Fri, 08 Apr 2005 00:02:06 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJkYL-0003jm-4y for ltru@ietf.org; Fri, 08 Apr 2005 03:53:05 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: RE: [Ltru] Re: [psg.com #902] AutoReply: add "Name_Changed" field RT-Ticket: psg.com #902 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:53:05 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 I vote no. "Name_Changed" is too much work to maintain. Let's figure out the deprecation/canonical issue and avoid lots of pointless maintenance. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of rt+ltru-registry@rt.psg.com > Sent: jeudi 7 avril 2005 20:07 > Cc: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #902] AutoReply: add "Name_Changed" field > > Hi - > > The message > http://www.ietf.org/mail-archive/web/ltru/current/msg00479.html > requests the addition of a "Name_Changed" field. > > Discussion? > > Randy > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:53:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08211; Thu, 7 Apr 2005 23:53:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkhe-0007BJ-LD; Fri, 08 Apr 2005 00:02:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkYT-0004Eu-Oj; Thu, 07 Apr 2005 23:53:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkYS-0004ET-8M for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:53:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08086 for ; Thu, 7 Apr 2005 23:53:09 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkh7-0007AH-Rn for ltru@ietf.org; Fri, 08 Apr 2005 00:02:11 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 20:53:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #902] AutoReply: add "Name_Changed" field Date: Thu, 7 Apr 2005 20:53:01 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF0021@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #902] AutoReply: add "Name_Changed" field Thread-Index: AcU76LF2cnFQBmmqTfajhrpAIOIATwABaKUw From: "Addison Phillips" To: X-OriginalArrivalTime: 08 Apr 2005 03:53:01.0916 (UTC) FILETIME=[761351C0:01C53BEE] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1899945824==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 --===============1899945824== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB2b3RlIG5vLiAiTmFtZV9DaGFuZ2VkIiBpcyB0b28gbXVjaCB3b3JrIHRvIG1haW50YWluLiBM ZXQncyBmaWd1cmUgb3V0IHRoZSBkZXByZWNhdGlvbi9jYW5vbmljYWwgaXNzdWUgYW5kIGF2b2lk IGxvdHMgb2YgcG9pbnRsZXNzIG1haW50ZW5hbmNlLg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpH bG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJu YXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9u IGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBb bWFpbHRvOmx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIHJ0K2x0 cnUtcmVnaXN0cnlAcnQucHNnLmNvbQ0KPiBTZW50OiBqZXVkaSA3IGF2cmlsIDIwMDUgMjA6MDcN Cj4gQ2M6IGx0cnVAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0x0cnVdIFJlOiBbcHNnLmNvbSAjOTAy XSBBdXRvUmVwbHk6IGFkZCAiTmFtZV9DaGFuZ2VkIiBmaWVsZA0KPiANCj4gSGkgLQ0KPiANCj4g VGhlIG1lc3NhZ2UNCj4gIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1 L2N1cnJlbnQvbXNnMDA0NzkuaHRtbA0KPiByZXF1ZXN0cyB0aGUgYWRkaXRpb24gb2YgYSAiTmFt ZV9DaGFuZ2VkIiBmaWVsZC4NCj4gDQo+IERpc2N1c3Npb24/DQo+IA0KPiBSYW5keQ0KPiANCj4g DQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+ IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg0K --===============1899945824== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1899945824==-- From ltru-bounces@ietf.org Thu Apr 7 23:54:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08251; Thu, 7 Apr 2005 23:54:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJki2-0007C2-TN; Fri, 08 Apr 2005 00:03:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkYo-0004H6-3p; Thu, 07 Apr 2005 23:53:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkYm-0004Go-FN for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:53:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08190 for ; Thu, 7 Apr 2005 23:53:29 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkhS-0007Ak-36 for ltru@ietf.org; Fri, 08 Apr 2005 00:02:31 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 20:53:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #903] add "Former_Name" field Date: Thu, 7 Apr 2005 20:53:19 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF0022@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #903] add "Former_Name" field Thread-Index: AcU76H73ESCdQzlWRyaZpDI83eOaJgABfjrw From: "Addison Phillips" To: X-OriginalArrivalTime: 08 Apr 2005 03:53:19.0786 (UTC) FILETIME=[80BA10A0:01C53BEE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1845089684==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 --===============1845089684== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlIHByZXZpb3VzIHJlcGx5LiBOby4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBz DQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50 ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0 aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9y ZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIHJ0 K2x0cnUtcmVnaXN0cnlAcnQucHNnLmNvbQ0KPiBTZW50OiBqZXVkaSA3IGF2cmlsIDIwMDUgMjA6 MDcNCj4gQ2M6IGx0cnVAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0x0cnVdIFJlOiBbcHNnLmNvbSAj OTAzXSBhZGQgIkZvcm1lcl9OYW1lIiBmaWVsZA0KPiANCj4gSGkgLQ0KPiANCj4gIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9sdHJ1L2N1cnJlbnQvbXNnMDA0NzkuaHRtbA0K PiByZXF1ZXN0cyBhZGRpdGlvbiBvZiBhICJGb3JtZXJfTmFtZSIgZmllbGQuDQo+IA0KPiBEaXNj dXNzaW9uPw0KPiANCj4gUmFuZHkNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxp c3QNCj4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9sdHJ1DQoNCg== --===============1845089684== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1845089684==-- From ltru-bounces@ietf.org Thu Apr 7 23:54:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08278; Thu, 7 Apr 2005 23:54:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJki9-0007CG-Dg; Fri, 08 Apr 2005 00:03:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkOF-0003vI-Ex; Thu, 07 Apr 2005 23:42:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkOD-0003vD-Ts for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:42:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07173 for ; Thu, 7 Apr 2005 23:42:34 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkWt-0006cw-Dm for ltru@ietf.org; Thu, 07 Apr 2005 23:51:36 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j383gNoJ029919; Thu, 7 Apr 2005 23:42:23 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 23:42:38 -0400 Date: Thu, 7 Apr 2005 23:42:37 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: propagation of parent organizationdeprecations Message-ID: <20050408034237.GF14141@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFF0E@irvmbxw01.quest.com> <4255C3D7.4A9F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4255C3D7.4A9F@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Frank Ellermann scripsit: > That's a dubious idea, "stability" is not the same as "forever > canonical". Consider the ugly effects for something like RH > or YU instead of new canonical tags ZW or CS. Get used to it. When the 639-3 languages get included, the whole notion that most codes are mnemonic is going to go by the board forever. There are just too many names. > Both don't invalidate anything, the old NH is still valid, it's > only deprecated. If NH is later recycled by ISO 3166-1, then > it's better to stay as far as possible away from the old NH. But then all systems have to deal with the identity of (hypothetical) NH and VU. By sticking to NH and ignoring the attempted change (which ISO 639/RA and ISO 15924/RA are pledged not to do), we don't have that problem. > Human taggers will get it wrong and will use tags like "English". So it goes. -- After fixing the Y2K bug in an application: John Cowan WELCOME TO jcowan@reutershealth.com DATE: MONDAK, JANUARK 1, 1900 http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:54:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08291; Thu, 7 Apr 2005 23:54:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJki9-0007CI-Rx; Fri, 08 Apr 2005 00:03:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkW1-00045s-LI; Thu, 07 Apr 2005 23:50:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkW0-00045k-3Q for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:50:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07876 for ; Thu, 7 Apr 2005 23:50:37 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkeg-0006uo-Qb for ltru@ietf.org; Thu, 07 Apr 2005 23:59:39 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j383oUDS029942; Thu, 7 Apr 2005 23:50:30 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Apr 2005 23:50:30 -0400 Date: Thu, 7 Apr 2005 23:50:29 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Message-ID: <20050408035029.GG14141@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AEEFE84@irvmbxw01.quest.com> <4255B0FD.4891@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4255B0FD.4891@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Frank Ellermann scripsit: > Not completely. For something like "fy" implementations still > don't know what the undocumented default (Latn in this case) > is. And you'd get a rather long list of prefixes for scripts > like Latn or Cyrl (all languages using both), don't you ? Bye. Actually not. There aren't that many languages that use both Latin *and* some other script in practice (excluding special-purpose scripts like Braille). Languages that only use Latin, like en, de, or fy, aren't going to be listed. It occurs to me that if "ipa" becomes a variant signifying "IPA transcription", it would be sensible not to give it a recommended prefix. -- John Cowan http://www.ccil.org/~cowan jcowan@reutershealth.com Please leave your values Check your assumptions. In fact, at the front desk. check your assumptions at the door. --sign in Paris hotel --Cordelia Vorkosigan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:54:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08320; Thu, 7 Apr 2005 23:54:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkiD-0007CR-55; Fri, 08 Apr 2005 00:03:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkYN-0004DL-I6; Thu, 07 Apr 2005 23:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkYN-0004DF-7R for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:53:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08076 for ; Thu, 7 Apr 2005 23:53:04 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkh3-0007AJ-SE for ltru@ietf.org; Fri, 08 Apr 2005 00:02:06 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJkYL-0003jp-G4 for ltru@ietf.org; Fri, 08 Apr 2005 03:53:05 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: RE: [Ltru] Re: [psg.com #902] AutoReply: add "Name_Changed" field RT-Ticket: psg.com #902 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:53:05 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 I vote no. "Name_Changed" is too much work to maintain. Let's figure out the deprecation/canonical issue and avoid lots of pointless maintenance. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of rt+ltru-registry@rt.psg.com > Sent: jeudi 7 avril 2005 20:07 > Cc: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #902] AutoReply: add "Name_Changed" field > > Hi - > > The message > http://www.ietf.org/mail-archive/web/ltru/current/msg00479.html > requests the addition of a "Name_Changed" field. > > Discussion? > > Randy > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:54:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08350; Thu, 7 Apr 2005 23:54:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkic-0007FB-A1; Fri, 08 Apr 2005 00:03:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkWn-0004BN-3h; Thu, 07 Apr 2005 23:51:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkWm-0004BE-3S for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:51:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08002 for ; Thu, 7 Apr 2005 23:51:25 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkfR-0006xK-QK for ltru@ietf.org; Fri, 08 Apr 2005 00:00:27 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJkWk-0003ZG-0S for ltru@ietf.org; Fri, 08 Apr 2005 03:51:26 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: RE: [Ltru] Re: [psg.com #904] add "Comment" field RT-Ticket: psg.com #904 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:51:26 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 No discussion. We already have a Comments field. It was previously called "Notes". This isn't worthy of discussion. Please don't make open issues out of things like this. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of rt+ltru-registry@rt.psg.com > Sent: jeudi 7 avril 2005 20:08 > Cc: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #904] add "Comment" field > > Hi - > > http://www.ietf.org/mail-archive/web/ltru/current/msg00482.html > requests addition of a "Comment" field. > > Discussion? > > Randy > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:54:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08391; Thu, 7 Apr 2005 23:54:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkit-0007Fh-L7; Fri, 08 Apr 2005 00:04:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkWw-0004Bl-Dv; Thu, 07 Apr 2005 23:51:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkWu-0004Bg-Q7 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:51:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08014 for ; Thu, 7 Apr 2005 23:51:33 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkfZ-0006wv-VZ for ltru@ietf.org; Fri, 08 Apr 2005 00:00:35 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 20:51:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #904] add "Comment" field Date: Thu, 7 Apr 2005 20:51:20 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF001F@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #904] add "Comment" field Thread-Index: AcU76QZPh6xneN+vS3WYAhdiotx3KwABN01w From: "Addison Phillips" To: X-OriginalArrivalTime: 08 Apr 2005 03:51:21.0416 (UTC) FILETIME=[3A2C3C80:01C53BEE] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1935991987==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 --===============1935991987== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8gZGlzY3Vzc2lvbi4gV2UgYWxyZWFkeSBoYXZlIGEgQ29tbWVudHMgZmllbGQuIEl0IHdhcyBw cmV2aW91c2x5IGNhbGxlZCAiTm90ZXMiLiBUaGlzIGlzbid0IHdvcnRoeSBvZiBkaXNjdXNzaW9u LiBQbGVhc2UgZG9uJ3QgbWFrZSBvcGVuIGlzc3VlcyBvdXQgb2YgdGhpbmdzIGxpa2UgdGhpcy4N Cg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVj dCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBX b3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJ dCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0Bs aXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIHJ0K2x0cnUtcmVnaXN0cnlAcnQucHNnLmNv bQ0KPiBTZW50OiBqZXVkaSA3IGF2cmlsIDIwMDUgMjA6MDgNCj4gQ2M6IGx0cnVAaWV0Zi5vcmcN Cj4gU3ViamVjdDogW0x0cnVdIFJlOiBbcHNnLmNvbSAjOTA0XSBhZGQgIkNvbW1lbnQiIGZpZWxk DQo+IA0KPiBIaSAtDQo+IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bHRydS9jdXJyZW50L21zZzAwNDgyLmh0bWwNCj4gcmVxdWVzdHMgYWRkaXRpb24gb2YgYSAiQ29t bWVudCIgZmllbGQuDQo+IA0KPiBEaXNjdXNzaW9uPw0KPiANCj4gUmFuZHkNCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiBodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --===============1935991987== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1935991987==-- From ltru-bounces@ietf.org Thu Apr 7 23:55:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08413; Thu, 7 Apr 2005 23:54:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkiv-0007Fm-Pd; Fri, 08 Apr 2005 00:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkYf-0004GO-Sv; Thu, 07 Apr 2005 23:53:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkYe-0004G3-Sg for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:53:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08137 for ; Thu, 7 Apr 2005 23:53:21 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkhL-0007Am-Cm for ltru@ietf.org; Fri, 08 Apr 2005 00:02:23 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJkYd-0003nj-LB for ltru@ietf.org; Fri, 08 Apr 2005 03:53:23 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: RE: [Ltru] Re: [psg.com #903] add "Former_Name" field RT-Ticket: psg.com #903 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:53:23 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 See previous reply. No. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of rt+ltru-registry@rt.psg.com > Sent: jeudi 7 avril 2005 20:07 > Cc: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #903] add "Former_Name" field > > Hi - > > http://www.ietf.org/mail-archive/web/ltru/current/msg00479.html > requests addition of a "Former_Name" field. > > Discussion? > > Randy > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:55:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08443; Thu, 7 Apr 2005 23:55:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkjA-0007G0-Cn; Fri, 08 Apr 2005 00:04:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkYg-0004GS-0P; Thu, 07 Apr 2005 23:53:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkYf-0004GJ-AG for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:53:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08142 for ; Thu, 7 Apr 2005 23:53:22 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkhL-0007Ao-Qc for ltru@ietf.org; Fri, 08 Apr 2005 00:02:24 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJkYe-0003nw-2Q for ltru@ietf.org; Fri, 08 Apr 2005 03:53:24 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: addison.phillips@quest.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: RE: [Ltru] Re: [psg.com #903] add "Former_Name" field RT-Ticket: psg.com #903 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:53:24 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 See previous reply. No. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of rt+ltru-registry@rt.psg.com > Sent: jeudi 7 avril 2005 20:07 > Cc: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #903] add "Former_Name" field > > Hi - > > http://www.ietf.org/mail-archive/web/ltru/current/msg00479.html > requests addition of a "Former_Name" field. > > Discussion? > > Randy > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 7 23:58:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08824; Thu, 7 Apr 2005 23:58:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJklr-0007OI-Vs; Fri, 08 Apr 2005 00:07:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkcd-0005T9-DS; Thu, 07 Apr 2005 23:57:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkcb-0005RZ-TC for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:57:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08742 for ; Thu, 7 Apr 2005 23:57:26 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJklH-0007Kf-FK for ltru@ietf.org; Fri, 08 Apr 2005 00:06:28 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 20:57:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Using RT Date: Thu, 7 Apr 2005 20:57:18 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF0029@irvmbxw01.quest.com> Thread-Topic: [Ltru] Using RT Thread-Index: AcU76+2koCslZ835Qfi3JsZ8l0+WjwAAZWBA From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 08 Apr 2005 03:57:18.0645 (UTC) FILETIME=[0F190E50:01C53BEF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable I'm getting three copies of every message to this alleged tool and find = most of the issues currently flowing through my inbox redundant on top = of that. This is emphatically annoying. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: jeudi 7 avril 2005 20:32 > To: ltru@ietf.org > Subject: [Ltru] Using RT >=20 > Hi - >=20 > (NOTE NEW SUBJECT!) >=20 > > From: "Frank Ellermann" > > To: > > Sent: Thursday, April 07, 2005 3:38 PM > > Subject: [Ltru] Re: fix ABNF bugs > > >=20 > > rt+ltru-registry@rt.psg.com wrote: > > > > > Already done. > > > > Does the ticket system now read subjects and echo anything > > it understands ? The same article with three Message-IDs: > > > > <634978A7DF025A40BFEF33EB191E13BC0AEEFEE1@irvmbxw01.quest.com> > > > > > ... >=20 > The first duplicate, and how it can be avoided, is explained in > http://www.ietf.org/mail-archive/web/ltru/current/msg00707.html >=20 > I'm not sure about the second one; I've sent a query to someone > who knows much more about these things. >=20 > General instructions on the use of the system are at = http://rt.psg.com/ > If you keep the "[psg.com #xxx]" in the subject line and post to > the appropriate rt+ltru-*@rt.psg.com address, the message will go > into the history of that particular ticket and, since ltru@ietf.org is > a "watcher", a copy will go to this list automatically. >=20 > Where the extra copy comes from is not clear; I hope to find out > soon, for the sake of everyone's sanity. >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 00:00:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09068; Fri, 8 Apr 2005 00:00:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkoI-0007Ub-SV; Fri, 08 Apr 2005 00:09:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJker-0006pi-PF; Thu, 07 Apr 2005 23:59:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkeq-0006pd-QE for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:59:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09033 for ; Thu, 7 Apr 2005 23:59:45 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJknW-0007RZ-J9 for ltru@ietf.org; Fri, 08 Apr 2005 00:08:47 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 20:59:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #898] change comments for region subtagswithdrawn from ISO 3166 after 1988 Date: Thu, 7 Apr 2005 20:59:37 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF002A@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #898] change comments for region subtagswithdrawn from ISO 3166 after 1988 Thread-Index: AcU74AxwjehEmi2mRZu8YZ7HyEbRwwADzUAQ From: "Addison Phillips" To: X-OriginalArrivalTime: 08 Apr 2005 03:59:38.0317 (UTC) FILETIME=[62594FD0:01C53BEF] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1994383762==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 --===============1994383762== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCdzIHRvIGRpc2N1c3M/IEl0IGlzIGNsYXNzaWZpZWQsIGFzIG5vdGVkLCBhcyBhbiBlY29u b21pYyBjb2RlLiBJdCBpcyBmb3JiaWRkZW4gYnkgcnVsZS4NCg0KQWRkaXNvbg0KDQpBZGRpc29u IFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNo YWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVy bmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUu IA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0Bs aXN0cy5pZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4g QmVoYWxmIE9mIHJ0K2x0cnUtaW5pdGlhbEBydC5wc2cuY29tDQo+IFNlbnQ6IGpldWRpIDcgYXZy aWwgMjAwNSAxOTowOA0KPiBDYzogbHRydUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbTHRydV0gUmU6 IFtwc2cuY29tICM4OThdIGNoYW5nZSBjb21tZW50cyBmb3IgcmVnaW9uDQo+IHN1YnRhZ3N3aXRo ZHJhd24gZnJvbSBJU08gMzE2NiBhZnRlciAxOTg4DQo+IA0KPiBIaSAtDQo+IA0KPiBUaGlzIHBy b3Bvc2FsIGNhbWUgZnJvbSBodHRwOi8vd3d3MS5pZXRmLm9yZy9tYWlsLQ0KPiBhcmNoaXZlL3dl Yi9sdHJ1L2N1cnJlbnQvbXNnMDAzNzkuaHRtbA0KPiANCj4gRGlzY3Vzc2lvbj8NCj4gDQo+IFJh bmR5DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAbGlzdHMu aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K DQo= --===============1994383762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1994383762==-- From ltru-bounces@ietf.org Fri Apr 8 00:01:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04668; Thu, 7 Apr 2005 23:12:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk3e-0005gh-IL; Thu, 07 Apr 2005 23:21:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjsm-0006JE-ND; Thu, 07 Apr 2005 23:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJjsl-0006Iz-B7 for ltru@megatron.ietf.org; Thu, 07 Apr 2005 23:10:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04489 for ; Thu, 7 Apr 2005 23:10:04 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJk1Q-0005da-3i for ltru@ietf.org; Thu, 07 Apr 2005 23:19:05 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJjsi-000POD-1B for ltru@ietf.org; Fri, 08 Apr 2005 03:10:04 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) RT-Ticket: psg.com #905 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 03:10:04 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #905] update IPR boilerplate X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi - (WG co-chair hat ON) This issue raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00520.html Consensus is to update boilerplate when xml2rfc supports it. I'll be changing this issue's status to "resolved." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 00:05:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09395; Fri, 8 Apr 2005 00:05:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJksp-0007cp-K8; Fri, 08 Apr 2005 00:14:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkje-00084e-Cx; Fri, 08 Apr 2005 00:04:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkjc-00084Z-2h for ltru@megatron.ietf.org; Fri, 08 Apr 2005 00:04:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09351 for ; Fri, 8 Apr 2005 00:04:40 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJksH-0007bd-Ud for ltru@ietf.org; Fri, 08 Apr 2005 00:13:43 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3844XwZ000054; Fri, 8 Apr 2005 00:04:33 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 8 Apr 2005 00:04:33 -0400 Date: Fri, 8 Apr 2005 00:04:32 -0400 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] Re: [psg.com #875] should initial registry contents bemade into an internet-draft? Message-ID: <20050408040432.GH14141@skunk.reutershealth.com> References: <20050407215804.GG10046@skunk.reutershealth.com> <010601c53bee$0725cc20$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010601c53bee$0725cc20$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Randy Presuhn scripsit: > Actually,the requirements in http://www.ietf.org/ietf/1id-guidelines.html > and http://www.ietf.org/ID-Checklist.html will result in something that > is remarkably RFC-like in format. The secretariat is becoming stricter > in enforcing these long-standing requirements. Yeah, you're right. We don't want the registry to be an I-D, because I-D's are designed for potential RFCs. -- John Cowan www.ccil.org/~cowan www.reutershealth.com jcowan@reutershealth.com All "isms" should be "wasms". --Abbie _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 00:07:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09611; Fri, 8 Apr 2005 00:07:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJkvN-0007iT-U9; Fri, 08 Apr 2005 00:16:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkky-00087T-KQ; Fri, 08 Apr 2005 00:06:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJkky-00087O-1A for ltru@megatron.ietf.org; Fri, 08 Apr 2005 00:06:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09460 for ; Fri, 8 Apr 2005 00:06:04 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJktd-0007dn-D1 for ltru@ietf.org; Fri, 08 Apr 2005 00:15:06 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJkku-0001B3-00 for ltru@ietf.org; Thu, 07 Apr 2005 21:06:05 -0700 Message-ID: <010f01c53bf0$763064c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <00e901c53baa$d18d3aa0$7f1afea9@oemcomputer><4255A612.3BFC@xyzzy.claranet.de><20050407215804.GG10046@skunk.reutershealth.com> <4255B3F1.1058@xyzzy.claranet.de> Subject: Re: [Ltru] Re: [psg.com #875] should initial registry contents be made into an internet-draft? Date: Thu, 7 Apr 2005 21:07:20 -0700 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: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi - (co-chair hat ON) > From: "Frank Ellermann" > To: > Sent: Thursday, April 07, 2005 3:28 PM > Subject: [Ltru] Re: [psg.com #875] should initial registry contents be made into an internet-draft? ... > This ticket stuff with its numerous questions irritates me. Consider it motivation to get these issues resolved. Stream-of-consciousness is nice for brainstorming sessions, but we have a bunch of specific issues to resolve, as well as a couple of thorny questions from the charter that haven't seen much discussion. The tickets will allow us to reach closure quickly on the easy stuff, and I hope keep the heavy discussion threads on track. > What's the difference between 875 and 878, why is 878 posted > twice ? When I said that I like RfC 4021 I meant RfC format, > not some dummy I-D. ... The decision by a working group to post something in the form of an internet-draft does NOT automatically mean that it is going to become an RFC. The original text had the WG chair hand a file to the secretariat. We *could* do this, but giving the secretariat an i-d or an RFC is a more normal way of initializing a registry. The heart of this question is whether anyone sees any particular value in requesting that the i-d be published as an RFC. Since you obviously do care about this, it's a good thing we asked these numerous irritating questions. Otherwise we would have treated the choice between i-d-only and i-d->RFC as simply a question of IANA's preference. By indicating a strong preference for publication of the initial registry as an RFC, you've shifted the debate to the question of whether anyone would have a strong objection to publication of the initial registry in that form. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 00:24:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10569; Fri, 8 Apr 2005 00:24:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJlBL-00089w-PM; Fri, 08 Apr 2005 00:33:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJktL-0001Bi-T2; Fri, 08 Apr 2005 00:14:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJktK-0001BY-LA for ltru@megatron.ietf.org; Fri, 08 Apr 2005 00:14:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10007 for ; Fri, 8 Apr 2005 00:14:43 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJl21-0007tf-FU for ltru@ietf.org; Fri, 08 Apr 2005 00:23:45 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJktJ-0006i4-BD for ltru@ietf.org; Fri, 08 Apr 2005 04:14:45 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: Re: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" RT-Ticket: psg.com #879 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 04:14:45 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi - > From: > Cc: > Sent: Thursday, April 07, 2005 2:19 PM > Subject: RE: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" (formatted so I can read it) > I would say: reject the comment if it doesn't result in something concrete. > If we're going to deal with the UND and MUL rules (and pull in i-default at > the same time) then we should propose specific text or at least tell the editor > what is supposed to be modified so that person has a fighting chance of doing something useful. > > Comments on the initial registry contents, by the way, go into the now former Appendix C: > instructions on creating the registry. I can put a note in about i-default and BCP 18, if there is consensus to do so. ... (co-chair hat on) I believe that note is all that was being requested, and the discussion sounded like it had reached a consensus on that point. (co-chair hat off) The request and proposed solution sound reasonable to me. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 00:25:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10625; Fri, 8 Apr 2005 00:25:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJlCA-0008DI-AD; Fri, 08 Apr 2005 00:34:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJktM-0001Bm-0w; Fri, 08 Apr 2005 00:14:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJktK-0001Bd-TT for ltru@megatron.ietf.org; Fri, 08 Apr 2005 00:14:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10010 for ; Fri, 8 Apr 2005 00:14:43 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJl21-0007tg-Kd for ltru@ietf.org; Fri, 08 Apr 2005 00:23:45 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJktJ-0006iA-N7; Fri, 08 Apr 2005 04:14:45 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: Re: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" RT-Ticket: psg.com #879 Precedence: bulk To: addison.phillips@quest.com X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 04:14:45 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi - > From: > Cc: > Sent: Thursday, April 07, 2005 2:19 PM > Subject: RE: [Ltru] RE: [psg.com #879] clarify "i-default" and "und" (formatted so I can read it) > I would say: reject the comment if it doesn't result in something concrete. > If we're going to deal with the UND and MUL rules (and pull in i-default at > the same time) then we should propose specific text or at least tell the editor > what is supposed to be modified so that person has a fighting chance of doing something useful. > > Comments on the initial registry contents, by the way, go into the now former Appendix C: > instructions on creating the registry. I can put a note in about i-default and BCP 18, if there is consensus to do so. ... (co-chair hat on) I believe that note is all that was being requested, and the discussion sounded like it had reached a consensus on that point. (co-chair hat off) The request and proposed solution sound reasonable to me. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 00:54:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12277; Fri, 8 Apr 2005 00:54:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJleW-0000ZR-Oq; Fri, 08 Apr 2005 01:03:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJlSu-0006oJ-4k; Fri, 08 Apr 2005 00:51:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJlSo-0006nj-KC for ltru@megatron.ietf.org; Fri, 08 Apr 2005 00:51:30 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12159 for ; Fri, 8 Apr 2005 00:51:22 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050408045052.SMUT7277.mta10.adelphia.net@DEWELL> for ; Fri, 8 Apr 2005 00:50:52 -0400 Message-ID: <001e01c53bf6$80d58e40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050407161037.UAIY4900.mta8.adelphia.net@megatron.ietf.org> Date: Thu, 7 Apr 2005 21:50:34 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: e[n]-GB-scouse (was: Matching metrics) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit > From: Frank Ellermann wrote: >> In fact what you need is the knowledge that Scouse is a >> dialect of en-GB. > > Not used elsewhere ? That would be very different from some > de-dialects found in places like Pennsylvania, Paraguay, or > Kazakhstan, all different from their oounterparts in Germany > today. No chance of "en-scouse" communities in the US or in > other parts of the world excl. GB ? Not bloody likely. Scouse is very closely linked with Liverpool, and is quite distinct from other varieties of English English. IIRC there is also an implication of working-class. I think Scouse mixed with non-GB usage or non-GB pronunciation would not even be Scouse any more. (Though I'd love to hear someone mix Scouse with SoCal surfer lingo: "Gerron, dude!") > If that's the case we just found another problem of squeezing > four dimensions into one: "scouse" would need a "recommended > prefix" en-GB (implicitly en-*-GB), not only en. In fact, there was a proposal back in 2002 to deprecate "en-scouse" and replace it with "en-GB-scouse", but it was not approved. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 01:18:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13662; Fri, 8 Apr 2005 01:18:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJm1a-0001E9-MN; Fri, 08 Apr 2005 01:27:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJlsD-0002pX-1u; Fri, 08 Apr 2005 01:17:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJlsB-0002pP-T0 for ltru@megatron.ietf.org; Fri, 08 Apr 2005 01:17:40 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13554 for ; Fri, 8 Apr 2005 01:17:38 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DJlpg-0003xV-N2 for ltru@lists.ietf.org; Fri, 08 Apr 2005 07:15:04 +0200 Received: from 212.82.251.127 ([212.82.251.127]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 07:15:04 +0200 Received: from nobody by 212.82.251.127 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Apr 2005 07:15:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Apr 2005 07:15:33 +0200 Organization: Lines: 36 Message-ID: <42561375.1C09@xyzzy.claranet.de> References: <00e901c53baa$d18d3aa0$7f1afea9@oemcomputer><4255A612.3BFC@xyzzy.claranet.de><20050407215804.GG10046@skunk.reutershealth.com> <4255B3F1.1058@xyzzy.claranet.de> <010f01c53bf0$763064c0$7f1afea9@oemcomputer> 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.127 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: should initial registry contents be made into an internet-draft? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: >> This ticket stuff with its numerous questions irritates me. > Consider it motivation to get these issues resolved. It doesn't motivate me if each article from the ticket system is posted at least twice, sometimes three times, in one case six times. This mail bot is out of control. The day before yesterday there were 512 articles in the archive, now we are at 788, +50% in less than two days. Look at the end of this: > Stream-of-consciousness is nice for brainstorming sessions I know it as threads, it has a Message-ID and References, and if the threads drifts somebody will update the Subject. Now all I see in overview mode are a lot of "Re: [psg.com #8" from "rt+ltru..." (truncated as indicated in this mode). And this "rt+ltru..." is not necessarily you, sometimes it's Addison's reply, but always starting a new thread. Confusing. > you've shifted the debate to the question of whether anyone > would have a strong objection to publication of the initial > registry in that form. John doesn't want an RfC. An I-D not meant to become an RfC is pointless, it would only spoil Doug's format with page headers, IPR boilerplates and disclaimers, security considerations, etc. And xml2rfc has no unpaginated output, if that's how Doug would create an I-D. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 01:19:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13836; Fri, 8 Apr 2005 01:19:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJm2w-0001IT-Cy; Fri, 08 Apr 2005 01:28:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJlt6-0002yS-9l; Fri, 08 Apr 2005 01:18:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJlt4-0002yF-WB for ltru@megatron.ietf.org; Fri, 08 Apr 2005 01:18:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13718 for ; Fri, 8 Apr 2005 01:18:34 -0400 (EDT) Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJm1k-0001EB-Us for ltru@ietf.org; Fri, 08 Apr 2005 01:27:34 -0400 Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050408051818.QTPT4618.mta13.adelphia.net@DEWELL> for ; Fri, 8 Apr 2005 01:18:18 -0400 Message-ID: <006501c53bfa$539ba820$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050406191319.GBPY2135.mta2.adelphia.net@megatron.ietf.org> <002c01c53b40$9b68a780$030aa8c0@DEWELL> <6.1.2.0.2.20050407151257.05072eb0@mail.jefsey.com> Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Date: Thu, 7 Apr 2005 22:17:56 -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.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: >> the latter (including all the ridiculous ones) would be about 15 >> million. > > Serious ones would probably be billions. 479 language subtags. 104 script subtags, plus 1 for no script subtag. 285 region subtags, plus 1 for no region subtag. 10 variant subtags, plus 1 for no variant. (This does not include multiple variants; there are no two variants out of the current 10 that could sensibly be used together.) 479 times (104 + 1) times (285 + 1) times (10 + 1) equals 143,843,700. Off by a factor of 10 (for which I apologize), but this is still not "billions," and I still contend that 99% of these are ridiculous. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ . _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 01:25:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14207; Fri, 8 Apr 2005 01:25:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJm8C-0001Ty-I9; Fri, 08 Apr 2005 01:34:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJlxd-0003TJ-CP; Fri, 08 Apr 2005 01:23:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJlxb-0003TB-KB for ltru@megatron.ietf.org; Fri, 08 Apr 2005 01:23:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14034 for ; Fri, 8 Apr 2005 01:23:15 -0400 (EDT) Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJm6I-0001OZ-59 for ltru@ietf.org; Fri, 08 Apr 2005 01:32:15 -0400 Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050408052305.OTAQ5402.mta11.adelphia.net@DEWELL>; Fri, 8 Apr 2005 01:23:05 -0400 Message-ID: <007001c53bfb$01d82620$030aa8c0@DEWELL> From: "Doug Ewell" To: References: Date: Thu, 7 Apr 2005 22:22:49 -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.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #896] change descriptions for region subtags withdrawn from ISO 3166 after 1988 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit > This proposal was set forth in > http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html > > Discussion? One or two people supported this idea; nobody opposed it. Consequently, the record-jar registry I posted on April 6 reflects the "original" names; BU is now Burma rather than Myanmar. I recommend changing this to "resolved." -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 01:31:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14600; Fri, 8 Apr 2005 01:31:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmE4-0001f8-I1; Fri, 08 Apr 2005 01:40:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJm0l-0003al-No; Fri, 08 Apr 2005 01:26:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJm0k-0003aa-LT for ltru@megatron.ietf.org; Fri, 08 Apr 2005 01:26:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14401 for ; Fri, 8 Apr 2005 01:26:30 -0400 (EDT) Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJm9S-0001VU-4s for ltru@ietf.org; Fri, 08 Apr 2005 01:35:30 -0400 Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050408052621.QYEV4618.mta13.adelphia.net@DEWELL>; Fri, 8 Apr 2005 01:26:21 -0400 Message-ID: <007e01c53bfb$76853a80$030aa8c0@DEWELL> From: "Doug Ewell" To: References: Date: Thu, 7 Apr 2005 22:26:04 -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.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #898] change comments for region subtags withdrawn from ISO 3166 after 1988 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit > This proposal came from http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html > > Discussion? This was rendered moot by the addition of a new field, "Deprecated," which simply takes the date of deprecation. There is no longer a comment per se which lists the new name or new subtag. This should be closed. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 01:38:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14913; Fri, 8 Apr 2005 01:38:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmKw-0001q3-K3; Fri, 08 Apr 2005 01:47:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJm9K-0004NP-2p; Fri, 08 Apr 2005 01:35:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJm9I-0004N8-Kw for ltru@megatron.ietf.org; Fri, 08 Apr 2005 01:35:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14836 for ; Fri, 8 Apr 2005 01:35:19 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmHw-0001lO-1b for ltru@ietf.org; Fri, 08 Apr 2005 01:44:17 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJm9C-0002z9-00 for ltru@ietf.org; Thu, 07 Apr 2005 22:35:14 -0700 Message-ID: <01f101c53bfc$e9584240$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <007001c53bfb$01d82620$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: [psg.com #896] change descriptions for region subtagswithdrawn from ISO 3166 after 1988 Date: Thu, 7 Apr 2005 22:36:27 -0700 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: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi - > From: "Doug Ewell" > To: > Cc: > Sent: Thursday, April 07, 2005 10:22 PM > Subject: [Ltru] Re: [psg.com #896] change descriptions for region subtagswithdrawn from ISO 3166 after 1988 > > > This proposal was set forth in > > http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html > > > > Discussion? > > One or two people supported this idea; nobody opposed it. Consequently, > the record-jar registry I posted on April 6 reflects the "original" > names; BU is now Burma rather than Myanmar. I recommend changing this > to "resolved." > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ ... Ok. As co-chair, I'll consider that a rough consensus, and I've changed this one's state to "resolved." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 01:39:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14961; Fri, 8 Apr 2005 01:39:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmLj-0001qp-1V; Fri, 08 Apr 2005 01:48:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJm7z-0004KV-GH; Fri, 08 Apr 2005 01:33:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJm7y-0004KQ-6D for ltru@megatron.ietf.org; Fri, 08 Apr 2005 01:33:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14705 for ; Fri, 8 Apr 2005 01:33:57 -0400 (EDT) Received: from mta13.mail.adelphia.net ([68.168.78.44] helo=mta13.adelphia.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmGe-0001jr-Gd for ltru@ietf.org; Fri, 08 Apr 2005 01:42:57 -0400 Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050408053347.RCHA4618.mta13.adelphia.net@DEWELL>; Fri, 8 Apr 2005 01:33:47 -0400 Message-ID: <008501c53bfc$807b78a0$030aa8c0@DEWELL> From: "Doug Ewell" To: References: Date: Thu, 7 Apr 2005 22:33:30 -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.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #899] remove region subtag 172 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit > The proposal to remove region subtag 172 appeared in > http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html > > Discussion? Region subtag 172 is "Commonwealth of Independent States." Although found among the otherwise-inappropriate "economic codes," this UN code actually represents a political and geographic region, more like "Eastern Africa" or "Melanesia" than like "Small Island Developing States." In retrospect, there is probably not much need for this subtag that could not be met by other macrogeographical subtags. It also represents an exception to the general rule of not using codes from the economic category, even though it is not unequivocally an economic code. There was neither support nor opposition on the list with regard to removing this subtag. It was removed in the April 6 registry, but could easily be reinstated. I am not dogmatic about it either way. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 01:41:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15152; Fri, 8 Apr 2005 01:41:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmOC-0001xI-90; Fri, 08 Apr 2005 01:50:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmFN-0005kb-Vv; Fri, 08 Apr 2005 01:41:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmFN-0005kO-Ac for ltru@megatron.ietf.org; Fri, 08 Apr 2005 01:41:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15140 for ; Fri, 8 Apr 2005 01:41:33 -0400 (EDT) Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmO0-0001ws-B5 for ltru@ietf.org; Fri, 08 Apr 2005 01:50:33 -0400 Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050408054123.TUUC7277.mta10.adelphia.net@DEWELL>; Fri, 8 Apr 2005 01:41:23 -0400 Message-ID: <008c01c53bfd$8f7e2220$030aa8c0@DEWELL> From: "Doug Ewell" To: References: Date: Thu, 7 Apr 2005 22:41:05 -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.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org Subject: [Ltru] Re: [psg.com #900] remove region subtag 200 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit > Message http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html > proposed removing region subtag 200. > > Discussion? 200 is the UN M.49 code for Czechoslovakia, now withdrawn from UN use, like other codes for countries no longer in existence. It was originally proposed as a way to allow content previously tagged with the old "CS" region subtag to be retagged, avoiding the ambiguity of the new "CS" code meaning Serbia and Montenegro, and without requiring the tagger to know whether the original "Czechoslovakia" should be mapped to the current Czech Republic (CZ) or to Slovakia (SK). There is probably no way to know whether content would actually be retagged in this way. Frank Ellermann originally opposed this subtag, then appeared to soften his objection. Conversely, I originally supported the subtag, then grew less supportive of it. I don't recall any other dialogue concerning this subtag. It was retained in the April 6 registry. Currently I am *very weakly* in favor of removing it. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 01:47:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15401; Fri, 8 Apr 2005 01:47:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmTP-00027m-Cg; Fri, 08 Apr 2005 01:56:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmKM-0007KC-Mq; Fri, 08 Apr 2005 01:46:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmKK-0007Jj-Ik for ltru@megatron.ietf.org; Fri, 08 Apr 2005 01:46:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15372 for ; Fri, 8 Apr 2005 01:46:43 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmT0-00027M-HW for ltru@ietf.org; Fri, 08 Apr 2005 01:55:43 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJmKE-0005AW-00 for ltru@ietf.org; Thu, 07 Apr 2005 22:46:39 -0700 Message-ID: <023501c53bfe$80ffb1e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #904] add "Comment" field Date: Thu, 7 Apr 2005 22:47:51 -0700 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: 79899194edc4f33a41f49410777972f8 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi - > From: > Cc: > Sent: Thursday, April 07, 2005 8:51 PM > Subject: RE: [Ltru] Re: [psg.com #904] add "Comment" field > > No discussion. We already have a Comments field. It was previously called "Notes". > This isn't worthy of discussion. Please don't make open issues out of things like this. ... Just trying to ensure that we have a coherent record of where the changes from version to version are coming from. There's no predicting what folks will get excited about. So, I've changed this one to "resolved." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 02:05:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21294; Fri, 8 Apr 2005 02:05:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmkt-0002gH-Mo; Fri, 08 Apr 2005 02:14:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmbx-0000jz-T5; Fri, 08 Apr 2005 02:04:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmbv-0000ju-US for ltru@megatron.ietf.org; Fri, 08 Apr 2005 02:04:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21052 for ; Fri, 8 Apr 2005 02:04:55 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmkd-0002fr-Nm for ltru@ietf.org; Fri, 08 Apr 2005 02:13:56 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJmbu-00011x-00 for ltru@ietf.org; Thu, 07 Apr 2005 23:04:54 -0700 Message-ID: <029801c53c01$0e1024a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <008501c53bfc$807b78a0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: [psg.com #899] remove region subtag 172 Date: Thu, 7 Apr 2005 23:06:07 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi - Ok, I've marked this one as "resolved" as well. Randy > From: "Doug Ewell" > To: > Cc: > Sent: Thursday, April 07, 2005 10:33 PM > Subject: [Ltru] Re: [psg.com #899] remove region subtag 172 > > > The proposal to remove region subtag 172 appeared in > > http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html > > > > Discussion? > > Region subtag 172 is "Commonwealth of Independent States." Although > found among the otherwise-inappropriate "economic codes," this UN code > actually represents a political and geographic region, more like > "Eastern Africa" or "Melanesia" than like "Small Island Developing > States." > > In retrospect, there is probably not much need for this subtag that > could not be met by other macrogeographical subtags. It also represents > an exception to the general rule of not using codes from the economic > category, even though it is not unequivocally an economic code. > > There was neither support nor opposition on the list with regard to > removing this subtag. It was removed in the April 6 registry, but could > easily be reinstated. I am not dogmatic about it either way. > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ ... _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 02:05:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21524; Fri, 8 Apr 2005 02:05:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJml6-0002gP-JR; Fri, 08 Apr 2005 02:14:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmYN-0000bx-1m; Fri, 08 Apr 2005 02:01:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmYL-0000bn-En for ltru@megatron.ietf.org; Fri, 08 Apr 2005 02:01:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17309 for ; Fri, 8 Apr 2005 02:01:12 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmh1-0002Zd-Gk for ltru@ietf.org; Fri, 08 Apr 2005 02:10:12 -0400 Received: from h-64-105-35-204.snvacaid.dynamic.covad.net ([64.105.35.204] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJmYI-0000Gt-00 for ltru@ietf.org; Thu, 07 Apr 2005 23:01:10 -0700 Message-ID: <028201c53c00$88187d20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <007e01c53bfb$76853a80$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: [psg.com #898] change comments for region subtagswithdrawn from ISO 3166 after 1988 Date: Thu, 7 Apr 2005 23:02:22 -0700 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: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi - > From: "Doug Ewell" > To: > Cc: > Sent: Thursday, April 07, 2005 10:26 PM > Subject: [Ltru] Re: [psg.com #898] change comments for region subtagswithdrawn from ISO 3166 after 1988 > > > This proposal came from > http://www1.ietf.org/mail-archive/web/ltru/current/msg00379.html > > > > Discussion? > > This was rendered moot by the addition of a new field, "Deprecated," > which simply takes the date of deprecation. There is no longer a > comment per se which lists the new name or new subtag. This should be > closed. ... Ok, I've changed the status to "rejected". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 02:12:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27955; Fri, 8 Apr 2005 02:12:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmrb-0002qS-P6; Fri, 08 Apr 2005 02:21:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmip-0001pi-HP; Fri, 08 Apr 2005 02:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmin-0001os-F1 for ltru@megatron.ietf.org; Fri, 08 Apr 2005 02:12:01 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27812 for ; Fri, 8 Apr 2005 02:12:00 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050408061129.CXEZ2192.mta9.adelphia.net@DEWELL> for ; Fri, 8 Apr 2005 02:11:29 -0400 Message-ID: <00a601c53c01$bfaac1c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050407203314.FIBH2135.mta4.adelphia.net@megatron.ietf.org> Date: Thu, 7 Apr 2005 23:11:05 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit John Cowan wrote: >> What if we put Recommended Prefix fields onto script subtags in the >> registry? >> >> This solves the default script problem because we are recommending >> when to use the subtag (when your language is in the list for that >> subtag). > > Excellent! So Latn would have a Recommended Prefix of az (among > others) but not en. I still oppose the premise of "default script" itself, regardless of the mechanism used to implement it. If there is a single piece of content labeled "en-Cyrl" or "en-Arab" or "en-Dsrt", someone may have a need to request it. Similarly, someone else may have a need to request "en-Latn" and, by doing so, explicitly exclude whatever Cyrillic or Aaraib or Deseret content might otherwise be returned. I do not believe we are in a position to "recommend" these on anyone's behalf. This is not at all the same as the "recommended prefix" associated with variant subtags. We are able to recommend certain prefixes for use with certain variants, because other combinations would be absurd. It is absurd to speak of Korean written according to the 1996 Rechtschreibung, or the Natisone dialect of Xhosa. It is not absurd to speak of Korean written in Cyrillic, or Xhosa written in Yi, no matter how uncommon those combinations may be. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 02:17:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03649; Fri, 8 Apr 2005 02:17:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJmx7-0003BV-09; Fri, 08 Apr 2005 02:26:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmnn-0004Ai-TU; Fri, 08 Apr 2005 02:17:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmnm-00049c-6l for ltru@megatron.ietf.org; Fri, 08 Apr 2005 02:17:10 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02962 for ; Fri, 8 Apr 2005 02:17:09 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050408061638.UMZN7277.mta10.adelphia.net@DEWELL> for ; Fri, 8 Apr 2005 02:16:38 -0400 Message-ID: <00b301c53c02$7a563b80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050407210751.LBPB2135.mta4.adelphia.net@megatron.ietf.org> Date: Thu, 7 Apr 2005 23:16:17 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #874] propagation of parent organizationdeprecations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > Previously we had only one field, "Canonical", and it served both for > mapping and indicating deprecation. > > Now we have TWO fields, "Canonical" and "Deprecated" and these can be > assigned independently and have separate stability guarantees. > > Thus a subtag can be deprecated (because it was withdrawn) without > mapping it to a new tag. Is this a suggestion to get rid of all Canonical fields with value "--" (dash-dash)? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 02:23:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08844; Fri, 8 Apr 2005 02:23:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJn2b-0003N0-JJ; Fri, 08 Apr 2005 02:32:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmtJ-0006Xw-3x; Fri, 08 Apr 2005 02:22:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJmtG-0006Xr-Mk for ltru@megatron.ietf.org; Fri, 08 Apr 2005 02:22:50 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08446 for ; Fri, 8 Apr 2005 02:22:49 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050408062219.DDAO2192.mta9.adelphia.net@DEWELL> for ; Fri, 8 Apr 2005 02:22:19 -0400 Message-ID: <00ba01c53c03$46218ee0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050407214045.JCIB2132.mta5.adelphia.net@megatron.ietf.org> Date: Thu, 7 Apr 2005 23:21:59 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #875] should initial registry contents be made into an internet-draft? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > Pro, something like RfC 4021 is nice. If Doug somehow forces > page footers below %% lines, and page headers above the next > registry entry. Please no big gap like 4021-3864. It's a data file. Record breaks are going to fall wherever they fall. "48 lines per page" is completely orthogonal to this. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 02:52:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10836; Fri, 8 Apr 2005 02:52:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJnUW-000483-Ii; Fri, 08 Apr 2005 03:01:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnLZ-000230-CH; Fri, 08 Apr 2005 02:52:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnLU-00022s-QK for ltru@megatron.ietf.org; Fri, 08 Apr 2005 02:52:00 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10819 for ; Fri, 8 Apr 2005 02:51:59 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050408065129.VCBN7277.mta10.adelphia.net@DEWELL> for ; Fri, 8 Apr 2005 02:51:29 -0400 Message-ID: <00cd01c53c07$53576040$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050407225542.FZQG5424.mta6.adelphia.net@megatron.ietf.org> Date: Thu, 7 Apr 2005 23:50:59 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: draft review X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: >>> The concern on this point is high enough to see the Draft blocked. >> >> Whose concern? Blocked by whom? Vague and unfounded. > > Unless IESG drops the rule of consensus, there is no possible > consensus on the present Draft. I am a documentation of it. At the > present stage I can only oppose. This is why I try to see my > opposition reduced. But this is a consensus process, not a compromise > and obviously not an enforcement process. This means that at the end > of the day APMD and I must be equally satisfied with the result. "Consensus" in an IETF Working Group means "rough consensus." It does not require absolute unanimity. If you doubt this, ask the chairs, or go over their heads to the ADs. >>> Concerns are also the double "-" which is specifically used by the >>> IANA code "xn". >> >> The IDN code space is unrelated in any way to the language tag code >> space. > > Private assumption. > BTW I say otherwise. It is at least through RFC 1958 basic principle > and consistency rule. Please point out a passage in RFC 1958 that says that if one protocol uses a character sequence such as "--", that no other protocol may use that same two-character sequence, no matter how unrelated the uses are. Language tags are not encoded in Punycode. Domain names, internationalized or otherwise, do not contain language tags. There is no conflict. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 03:05:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11846; Fri, 8 Apr 2005 03:05:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJnhO-0004Uq-0O; Fri, 08 Apr 2005 03:14:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnXr-0004hb-SB; Fri, 08 Apr 2005 03:04:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnXm-0004hO-8d for ltru@megatron.ietf.org; Fri, 08 Apr 2005 03:04:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11815 for ; Fri, 8 Apr 2005 03:04:40 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJngT-0004To-BZ for ltru@ietf.org; Fri, 08 Apr 2005 03:13:42 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3874VRp026711 for ; Fri, 8 Apr 2005 03:04:31 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3874Vil106804 for ; Fri, 8 Apr 2005 03:04:31 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3874KSw001208 for ; Fri, 8 Apr 2005 03:04:21 -0400 Received: from markdavis (sig-9-48-115-53.mts.ibm.com [9.48.115.53]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j38748wI000794; Fri, 8 Apr 2005 03:04:19 -0400 Message-ID: <021201c53c09$2af308f0$be733009@sanjose.ibm.com> From: "Mark Davis" To: "John Cowan" References: <6.1.2.0.2.20050405014928.037ea550@mail.jefsey.com> <20050407135146.GI1795@skunk.reutershealth.com> Subject: Re: [Ltru] draft review Date: Thu, 7 Apr 2005 09:27:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id j3874VRp026711 X-Spam-Score: 0.4 (/) X-Scan-Signature: 916029c14bdb340aa234d3ec4cd24f52 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 Content-Transfer-Encoding: quoted-printable Thanks, John, for taking the trouble to go through all of this! =E2=80=8EMark ----- Original Message -----=20 From: "John Cowan" To: "JFC (Jefsey) Morfin" Cc: Sent: Thursday, April 07, 2005 06:51 Subject: Re: [Ltru] draft review I apologize in advance for the length of this document. It is a formal, but entirely personal, reply to M. Morfin's draft review. The points which I consider valuable in that review are not taken up here; I have concerned myself in this particular message only with M. Morfin's errors, misapprehensions, and insinuations, in the faint hope that they can be disposed of once and for all. JFC (Jefsey) Morfin scripsit: > DRATF RELATED COMMENTS AND QUESTIONS Comments 1-15 are editorial in nature and I have addressed them elsewhere. > 16. 2.2: it is noted that the language used for the "language tags > namespace" and its registry is quite similar to the domain name system. The analogy is vague and specious, and utterly ungrounded in the text, which does not even contain the phrases "domain name system" or "DNS". > However the proposed semantic is not consistent with other Internet > spaces like DNS, IPv4, OID, etc. where the dot-separation is used, > something users and parsers are accustomed to and existing processes > have identified in different scripts. It relies to the contrary on the > "-" as a separator which is more confusing and may have less identified > homographs. What is more confusing about "-" than "."? In any case, "-" has been used in all language tags until now, and is required for backward compatibility. > 17. [...] Such a two, possibly contradictory, systems format will > never scale, is far too dependent from external changes and unable to > support innovation. This is handwaving. Scale to what, millions of countries and trillions of languages? Of course it is dependent on external changes, or rather the lack of them. A format that is designed to depend on anything extern= al cannot possibly adjust in advance to radical changes of an unknown nature. > This cannot be made a world-wide standard through an IETF BCP except > in the cases defined by the charter if the IESG wants to run into the > risk of endless conflicts and of a quick obsolescence. The alleged risk is not supported by the history of RFC 1766/3066 in the last ten years. > It is to be noted that the referred ISO standard to be used are less > than 30 years old and yet ISO 3166-2 cannot be supported. ISO 3166-2 (subnational regions) is not freely available; it costs CHF 20= 0 for a copy without even update service. (Approx. EUR 129 or USD 167.) It has never been proposed or used for language tagging. In addition, it is extremely unstable, because countries are allowed to rewrite their parts of it pretty much ad lib as they reorganize their internal subdivisions from time to time. > 18. 2.2.1: primary language: fixed length identification starts > with 2 or 3 and possibly 8 but discouraged language ID coming this way > only from ISO 639. This removes the possibility to consider computer > related (non only programming) languages, dialects, etc. nor to adapt > to evolutions, adjustments, and passed languages. Untrue. 36^8 possible language tags is more than enough. Discouraging something does not imply removing the possibility of it. > 19. 2.2.1.: the 2 letters code for language is an oddity inherited > from earlier times of RFC 1776 and ISO 639. It is unquestionably a theoretical wart, but is absolutely required for backward compatibility. > It is likely that at some time it will be timed out by ISO or/and by > usage may be even by anti-racist laws. This is a truly amazing bit of prophecy worthy of Michel de Notredame. > Time is now to update existing applications rather than to increase > complexity of the years/century to come. Applications are not at issue; data is. Where is the money going to come from to re-mark-up the billions of existing documents and metadata repositories worldwide that rely on ISO 639-1 codes? > This makes me think > to "UK" instead of "GB". Words like "united" and "kingdom" are avoided when possible in ISO 3166-1 codes because they are shared by many nations. You would be better off pressing for GN (Great Britain and Northern Ireland) or for changing US to some other code. > 20. 2.2.2: language [extended] subtags are permitted only if they > are 3 characters (a permanent rigid position) based the anticipation > of a non documented ISO 639 works. This is also a violation of the > Internet standard process: the document in reference should be quoted > and cannot be a draft. ltru-registry is also only a draft at present. > Language extended subtags are the most active part of languages, Where is the evidence for this claim? Are you confusing the function of extended language subtags with that of variant subtags? > 21. 2.2.3: Script subtags follow the same rigid logic and constraints > from the format. What happens if the memory waste of ISO 15924 (3 > bytes lost) is corrected, or if another code element has a fixed 4 > characters length in the future? We cannot design the draft to adapt to unpredictable massive changes in the format of ISO codes, especially when there is not the slightest evidence that such a thing will ever happen. > 22. 2.2.4: I understand that all the regional language differences > of the world are to be supported by the ISO 3166 alpha-3/digit-3 list. Incorrect. National and supranational regions are supported by ISO 3166-= 1 alpha-2 and UN M.49 digit-3 codes. > This means that regions like NY, TX or California are not entitled a > code but the 56 persons of Pitcairn Island yes? I doubt that disparity > can hold very long, all the more than ISO 3166-2 provides all the > possibilities for a far more adequate granularity. See above. > 23. 2.2.9: There is a MUST in "there MUST be an attempt to register" > which cannot be enforced if there is not a non-delaying procedure to > verify that a language was attempted to be registered with ISO 639. Forward verification would surely suffice; a copy of a dated email to ISO 639/RA showing an ignored registration would suffice. In facct, however, the RA is quite responsive. > Otherwise this part is to be understood as a disguised way, concerted > with ISO, to block names. There is no evidence for this allegation. > The concern on this point is high enough to see the Draft blocked. Whose concern? Blocked by whom? Vague and unfounded. > It seems that the second paragraph is a smoky verbose replay of the > same idea, without any procedural description nor request/provision > of formal proof. It may *seem* so to you. We deal here in what is so, not in what seems s= o. > The general idea is precisely in opposition with the purpose of the > proposed RFC: to be able to register names not registered by ISO. This > amount to a legitimisation of censoring, and censoring against the > very intent of this document. Libelous nonsense. The general idea is of course to avoid duplication of effort, so that ISO and ietf-languages are not considering the same language at the same time. > 24. 2.2.9: registrations are left to a decision of appropriateness > by someone debating with undefined others for a matter without any > importance on the network stability and security (documented in in > part 4) non on the end to end interoperability. This seems to amount > to pure intellectual censoring. Non sequitur. > 25. 2.3: recommendation 3 seems inappropriate. Aliases are aliases. > All the aliases must be equally supported because (a) they are aliases > (b) to make sure developers develops correct code. All aliases are equally supported. Not all aliases are equally recommend= ed. > 26. 2.4. "language tags always define a language as spoken by human > being for communications of information to other human beings. Computer > languages are explicitly excluded" has no ground in the Charter and > in reality. Computer languages are not languages, save metaphorically. See ISO 639. > Web Services relations are excluded which may speak limited languages. Do you suppose that SOAP is a language? > Coded human languages should be supported: they fit the definition. What is a coded human language? > 27. 2.4.1: in the canonicalization part "" is reminded as a > deprecation indicator, yet this is not documented earlier. It seems thi= s > is an external ISO practice. This should be documented in the format > description part. All the more than this practice is counter intuitive > "" being understood intuitively as "-(nul)-". And the "" being used > in IDN there could be some homograph confusion to investigate. I suppose that by "" you mean "--". This is not a deprecation indicator, as the draft clearly explains. I will address comments 28-33 elsewhere. > 34. 3.3. why a "MAY" concerning the "description, note and prefix > fields" is not documented by conditions? Is that not a "CAN". CAN does not appear in RFC 2119. I will address comment 35 elsewhere. Comment 36 is editorial in nature and has already been addressed elsewhere. > 37. 3.4. The description of information to be maintained is clear, > but the format is not described. This permits IANA to freely change it > or to present it in HTML form. This does not help its automated reading. 3.4 is about extensions, which are documented through the RFC process and only through the RFC process, as is plainly stated. There is no expectation that information about extensions will be machine-processable. > 38. 4. security considerations should not deal with users political > security outside of their network usage. Otherwise tons of such > considerations should be presented. The point has been raised and is documented. > 39. 4. An important security consideration is homographs. It is > certainly possible to include part of text in a foreign language which > look printed as in another language or having a different meaning or > printing (phishing). This is a security consideration related to the existence of text altogether, not to the tagging of it. Or at most it is related to the absence of tagging. > Concerns are also the double "-" which is specifically used by the > IANA code "xn". The IDN code space is unrelated in any way to the language tag code space. > 40. 4. Fourth paragraph tend to say that specification of valid > sub-tags MUST be available over the internet but that applications > should take possible DoS into consideration. This is an important > indication on the way the Draft proposes the registry file to be used > and accessed. It can be read that applications can freely access it > and proposed mirrors: this may impose on the IANA a load which will > result in its permanent inability of service. There are several possible solutions, including mirrors, upgrades to IANA infrastructure, and load throttling by IANA. Which of these is done, if any, is an internal IANA question and off-topic here. Comments 41-42 are editorial in nature and will be addressed elsewhere. > 43. 6. Stability. Confusion between document. This document does > not provide a mechanism but a format that can be used by the mechanism > described in the next document. This text has not been adapted after > the split. This does not seem to reflect draft-ietf-ltru-registry-01. > 44. 6. Validity. This document should define the IQ of > the "intelligent people" being considered or the collective IQ > augmentation necessary to understand the system ?? Please see the > ideas of the one who created the NIC and grand fathered the RFC system > (http://bootstrap.org). Irrelevant. The draft says that *even* intelligent people may do inconsistent things in the absence of guidance. > 45. 6. Extensibility such as presented actually results (in a very > limited way) from the underlying ISO codes. This is not the target of > Charter which is to permit scalability even when a code element it is > not supported by ISO. That is one of many points mentioned in the charter. It is not the singular goal of the draft. Comment 46 is editorial in nature and will be addressed elsewhere. > 47. 6. last: added text for "" is not sufficient enough, or is > missing in my version. Unintelligible. > CHARTER VS DRATF RELATED COMMENTS AND QUESTIONS 48. language > preferences are uniquely understood in HTML, XML only. CLDR are > quoted in the charter and not quoted in the Draft. The Charter does > not prevent other applications, systems to be supported. The Draft > does not allude to them. As stated in earlier postings, these are merely consumers of RFC 3066 language tags. There are others. There is no reason for the draft to mention its consumers; rather they mention it. > 49. The charter lists RFC 3066 problems. These problems are: (a) > stability there is a paragraph on the matter; (b) accessibility to the > underlying ISO standard this is definitely impeached by the format > (no ISO 3166-2, no other ISO 639 format than 2 or 3 characters no > other script description format than 4 characters, etc. as if the > current ISO presentation will never improve); Answered above. There is no reason to expect such changes, and no evidence is given that they constitute improvements. > (c) difficulty with registration and acceptance: this could be improved > by the subtag registration system but it seems to be made worse, > due to the censoring rules introduced to prevent non-ISO entries to > be entered in the IANA non-ISO table; "Prevent" is a malicious falsehood. > (e) lack of clear guidance to identify script and region: scripts are > Unicode only, Untrue. See the ISO 15924/RA registry, which lists many non-Unicode scripts. > region are 2 letter Telex codes; They are part of an international standard, whether originally derived from Telex codes or not. > (f) lack of parseability and well-formedness : this has certainly been > addressed [it seems to be both the major improvement of the Draft > =1B)B. and the source of most of its problems due to the rigidity > it introduces]. Rigidity about matters which cannot be expected to change is not only reasonable but desirable. > 50. The main purpose of this Draft from the charter is to describe > the IANA registry to support the resolution of the above problems, > and how transition from RFC 3066. This is to be in a clear and concise > way. RFC 3066 represents roughly 17.000 characters and the draft 70.000 > (out of the IETF format and verbose). Out of the IETF format in what way? > This makes it confuse. From what I understand it includes 3 parts: > (a) the subtags file with a clear format (b) the accompanying > registration/update forms (c) the variant tables with a clear, yet > less precise format. What "variant tables"? This expression does not appear in the draft, nor is anything described that could be so designated. > From what I understand (a)(b) are the real responsibility of the old > aliased distribution list and of a Reviewer designated by IESG with > unlimited veto powers; As the draft (and RFC 3066 and 1766) clearly state, the Reviewer's decisions may be appealed to IESG. That is not an unlimited veto. > 51. it lists challenges to be addressed. Stability: "how the language > tags remains stable even if the underlying references should change". > This means a process where the tag name is unrelated to its underlying > components, like a domain name is stable even if the underlying IP > address changes. This is not provided. The analogy to the DNS is specious. A more correct analogy would be attemping to keep a domain name stable when one of its enclosing domains changes its name. > 52. it lists challenges to be addressed. Accessibility: "a simple way > to determine if a subtag is valid as of a given date. Like receiving > a 404 when calling an expired domain name". Such a mechanism is not > provided. The expression in quotation marks is not, in fact, a quotation from the charter, and so need not be addressed. > 53. it lists challenges to be addressed. extensibility: this meant > not having to record millions of combinations. This is provided. To > the price of format rigidity, impossible use of foreseen or existing > ISO code elements, and a censoring of the non-ISO extensions which > may lead to more harassment. It also meant addition of the script in > language tags. This is permitted by the proposed format but to the > detriment of other 4 letters entries. Registration of non ISO scripts > is not permitted. Answered above. > 54. it lists challenges to be addressed. "provide mechanism to support > the evolution of the underlying standards, in particular ISO 693-3, > mechanisms to support variant registration and format extensions, > as well as allowing generative private use when necessary": I am not > sure what "generative" may mean in here but I feel it is not supported, > the rest is certainly opposed by the chosen format; "Generative" refers to the ability to create complex elements from the systematic assembly of simpler elements. ISO 639-3 concerns have been taken into account from the start. Variant registration is directly supported. Format extensions are provided for. > 55. it lists challenges to be addressed: "to specify a mechanism for > easily identifying the role of each subtag in the language tag". This > is addressed by the Draft. But this challenge is contradictory with > stability challenge above. If a language tag displays an identifiable > subtag, it becomes by nature dependent from the underlying value of > the subtag. It certainly does. To use your favorite analogy, a domain name is not independent of the name of its enclosing domains; were the .fr TLD to change its name to .gaul tomorrow, all subdomains of .fr would have to change likewise. --=20 As you read this, I don't want you to feel John Cowan sorry for me, because, I believe everyone jcowan@reutershealth.com will die someday. http://www.reutershealth.= com --From a Nigerian-type scam spam http://www.ccil.org/~cowa= n _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 03:18:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12623; Fri, 8 Apr 2005 03:18:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJnth-0004so-Ht; Fri, 08 Apr 2005 03:27:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnfc-0005KH-Gu; Fri, 08 Apr 2005 03:12:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnfY-0005K3-FB for ltru@megatron.ietf.org; Fri, 08 Apr 2005 03:12:45 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12345 for ; Fri, 8 Apr 2005 03:12:42 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050408071212.SOHL4618.mta13.adelphia.net@DEWELL> for ; Fri, 8 Apr 2005 03:12:12 -0400 Message-ID: <00d601c53c0a$46f184e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050408000100.CBWK2132.mta5.adelphia.net@megatron.ietf.org> Date: Fri, 8 Apr 2005 00:12:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: >> Bruce wanted the French names in the draft-10 last call, IIRC >> nobody else wanted this. > > Uncorrect. Serveral wanted it. I am one. And Bruce Lilly wanted it. That makes two. Anyone else? Anyone else for whom it was a showstopper? > For two main reasons: > - consistency with the concerned ISO document > - same reason as ISO: crossculture validation is a warranty against > monocultural dominance. We've had this debate before. > No consensus will be reached without this. Unanimity will not be reached without this. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 03:19:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12698; Fri, 8 Apr 2005 03:19:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJnv6-0004wN-EU; Fri, 08 Apr 2005 03:28:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnlu-0006Dd-QT; Fri, 08 Apr 2005 03:19:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJnls-0006DY-HN for ltru@megatron.ietf.org; Fri, 08 Apr 2005 03:19:17 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12680 for ; Fri, 8 Apr 2005 03:19:14 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050408071844.SQYF4618.mta13.adelphia.net@DEWELL> for ; Fri, 8 Apr 2005 03:18:44 -0400 Message-ID: <00df01c53c0b$2f9492a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050408020206.YMCY2128.mta1.adelphia.net@megatron.ietf.org> Date: Fri, 8 Apr 2005 00:18:37 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #891] support non-ASCII representation of native name of language X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit > This issue was raised in > http://www.ietf.org/mail-archive/web/ltru/current/msg00248.html > > I believe further discussion is needed before we declare consensus > to accept or reject this proposal. I support the removal of the ASCII-only constraint. I oppose opening up the description field to non-Latin scripts. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 04:08:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16584; Fri, 8 Apr 2005 04:08:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJog2-0006h6-Rw; Fri, 08 Apr 2005 04:17:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJoWS-0005B7-O1; Fri, 08 Apr 2005 04:07:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJoWP-0005A4-AX for ltru@megatron.ietf.org; Fri, 08 Apr 2005 04:07:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16541 for ; Fri, 8 Apr 2005 04:07:17 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJof5-0006gX-Iu for ltru@ietf.org; Fri, 08 Apr 2005 04:16:19 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j38875br022029 for ; Fri, 8 Apr 2005 04:07:05 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j38875il035162 for ; Fri, 8 Apr 2005 04:07:05 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j38875wo021953 for ; Fri, 8 Apr 2005 04:07:05 -0400 Received: from markdavis (sig-9-48-115-109.mts.ibm.com [9.48.115.109]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j38871Dc021784; Fri, 8 Apr 2005 04:07:04 -0400 Message-ID: <049001c53c11$f24cfed0$be733009@sanjose.ibm.com> From: "Mark Davis" To: , "Frank Ellermann" References: <634978A7DF025A40BFEF33EB191E13BC0AEEFF0E@irvmbxw01.quest.com> <4255C3D7.4A9F@xyzzy.claranet.de> Subject: Re: [Ltru] Re: propagation of parent organizationdeprecations Date: Fri, 8 Apr 2005 01:01:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e6.ny.us.ibm.com id j38875br022029 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable I agree with Addison (and not Frank). For stability, you keep the oldest valid name; otherwise canonicalization for *the same name* may change between different implementations. =E2=80=8EMark ----- Original Message -----=20 From: "Frank Ellermann" To: Sent: Thursday, April 07, 2005 16:35 Subject: [Ltru] Re: propagation of parent organizationdeprecations > Addison Phillips wrote: > > >> Why not simply add the new code, and change the old code to > >> "deprecated" with the new code as canonical value ? (=3D as in 2) > > > Because we guarantee that once a subtag is canonical it is > > canonical forever for that meaning. > > That's a dubious idea, "stability" is not the same as "forever > canonical". Consider the ugly effects for something like RH > or YU instead of new canonical tags ZW or CS. > > > we can separate whether is it deprecated from whether it is > > canonical. Canonical means that there is another code that > > should be used. Deprecated merely means "don't use this one > > (after the date provided)". > > A deprecated RH or YU with a canonical RH or YU makes no sense. > > If something is deprecated it needs a new canonical value where > possible - impossible for SU, simple for DD or RH. It doesn't > work as expected for the old YU before the split, but it's okay > for the new YU =3D> new CS case. > > > Subtag: NH > > Canonical: VU > > Deprecated: 1980-01-01 > > %% > > Subtag: VU > > Yes, that's fine. > > > Subtag: NH > > Deprecated: 2006-01-01 > > Comment: use VU for Vanuatu > > %% > > Subtag: VU > > And that's not okay, "comment" isn't readable for machines. > > > With the second, we haven't invalidated anyone's data. > > Both don't invalidate anything, the old NH is still valid, it's > only deprecated. If NH is later recycled by ISO 3166-1, then > it's better to stay as far as possible away from the old NH. > > Human taggers will get it wrong and use the new ISO 3166-1 NH, > no matter what the registry says. A canonical VU avoids this > foreseeable error. > > > Subtag: NH > > %% > > Subtag: VU > > Canonical: NH > > Deprecated: 2006-01-01 > > Comment: use NH for Vanuatu by rule > > > This is vaguely unsatisfying by comparison. > > This is FUBAR. Deprecated NH =3D> canonical VU is correct. > > > let's consider if VU changed it name again as some future > > date: > > > Subtag: NH > > Deprecated: 2006-01-01 > > Comment: use VU > > %% > > Subtag: VU > > Deprecated: 2010-01-01 > > Comment: use XX > > %% > > Subtag: XX > > > Still no one's data is hurt > > Until the flood of erroneous NH instead of 1234 begins. It's > much clearer and simpler to have this "final" constellation: > > | Subtag: NH > | Deprecated: 2006-01-01 > | Canonical: XX > | %% > | Subtag: VU > | Deprecated: 2010-01-01 > | Canonical: XX > | %% > | Subtag: XX > | %% > | Subtag: 1234 > | Comment: UN M.49 code, Code NH blocked by New Hebrides > > If NH points to VU, and VU to XX, it's also okay. Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 05:53:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28681; Fri, 8 Apr 2005 05:53:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJqJU-0002qD-O2; Fri, 08 Apr 2005 06:02:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJq5q-00041E-Rr; Fri, 08 Apr 2005 05:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJq5o-00040X-T0 for ltru@megatron.ietf.org; Fri, 08 Apr 2005 05:48:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27930 for ; Fri, 8 Apr 2005 05:47:56 -0400 (EDT) Received: from smtp.nildram.co.uk ([195.112.4.54]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJq2y-0001ez-KG for ltru@ietf.org; Fri, 08 Apr 2005 05:45:05 -0400 Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) by smtp.nildram.co.uk (Postfix) with ESMTP id 499DD25F36C; Fri, 8 Apr 2005 10:35:57 +0100 (BST) From: "Debbie Garside" To: "'Randy Presuhn'" , Date: Fri, 8 Apr 2005 10:36:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU8Hn/ZosmorOFQRreyUPmL6+DMPQ== Message-Id: <20050408093557.499DD25F36C@smtp.nildram.co.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Subject: [Ltru] OT - Traffic X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Hi Randy I have received 252 emails from LTRU since 4pm yesterday (17 hours). There is no possible way I can track/digest or even open this level of traffic. Debbie Garside Managing Director ICT Marketing Limited Corner House Barn Street Haverfordwest Pembrokeshire SA61 1BW Wales UK Tel: 0044 (0)1437 766441 Web: www.ictmarketing.co.uk Chief Executive Officer ICT Enterprise Centre Limited Corner House Barn Street Haverfordwest Pembrokeshire SA61 1BW Wales UK Tel: 0044 (0)1437 766441 Web: www.ictenterprise.co.uk _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 08:16:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10952; Fri, 8 Apr 2005 08:16:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJsYh-0001j3-Ub; Fri, 08 Apr 2005 08:26:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJsPa-0005v6-Sa; Fri, 08 Apr 2005 08:16:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJsPY-0005v1-KN for ltru@megatron.ietf.org; Fri, 08 Apr 2005 08:16:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10901 for ; Fri, 8 Apr 2005 08:16:31 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJsYJ-0001iD-Fj for ltru@ietf.org; Fri, 08 Apr 2005 08:25:35 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j38CGHVO001861; Fri, 8 Apr 2005 08:16:17 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 8 Apr 2005 08:16:18 -0400 Date: Fri, 8 Apr 2005 08:16:17 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: registry should copy non-English fields from ISO documents Message-ID: <20050408121617.GJ14141@skunk.reutershealth.com> References: <20050408000100.CBWK2132.mta5.adelphia.net@megatron.ietf.org> <00d601c53c0a$46f184e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00d601c53c0a$46f184e0$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Doug Ewell scripsit: > >> Bruce wanted the French names in the draft-10 last call, IIRC > >> nobody else wanted this. > > > > Uncorrect. Serveral wanted it. I am one. > > And Bruce Lilly wanted it. That makes two. Anyone else? I favor including the French data from ISO as well. > > For two main reasons: > > - consistency with the concerned ISO document > > - same reason as ISO: crossculture validation is a warranty against > > monocultural dominance. I agree with these reasons. As a data point, I believe Peter Constable said in ietf-languages that the French data was helpful in determining exactly which language was meant in certain cases by a specific code. -- With techies, I've generally found John Cowan If your arguments lose the first round http://www.reutershealth.com Make it rhyme, make it scan http://www.ccil.org/~cowan Then you generally can jcowan@reutershealth.com Make the same stupid point seem profound! --Jonathan Robie _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 08:26:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11538; Fri, 8 Apr 2005 08:26:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJshf-0002D6-5R; Fri, 08 Apr 2005 08:35:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJsV2-000716-Mr; Fri, 08 Apr 2005 08:22:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJsV1-000711-0L for ltru@megatron.ietf.org; Fri, 08 Apr 2005 08:22:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11345 for ; Fri, 8 Apr 2005 08:22:10 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJsdm-00023x-8V for ltru@ietf.org; Fri, 08 Apr 2005 08:31:14 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j38CLu32001890; Fri, 8 Apr 2005 08:21:57 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 8 Apr 2005 08:21:56 -0400 Date: Fri, 8 Apr 2005 08:21:56 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: [psg.com #900] remove region subtag 200 Message-ID: <20050408122156.GK14141@skunk.reutershealth.com> References: <008c01c53bfd$8f7e2220$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008c01c53bfd$8f7e2220$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Doug Ewell scripsit: > Frank Ellermann originally opposed this subtag, then appeared to soften > his objection. Conversely, I originally supported the subtag, then grew > less supportive of it. I don't recall any other dialogue concerning > this subtag. It was retained in the April 6 registry. Currently I am > *very weakly* in favor of removing it. The -01 draft has a paragraph talking about it, and I have proposed an editorial change to strengthen its exceptionality. So I do support it, specially called out in the RFC as an exception for a particular purpose to the general rules about M.49 codes. -- Principles. You can't say A is John Cowan made of B or vice versa. All mass http://www.reutershealth.com is interaction. --Richard Feynman http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 09:22:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16882; Fri, 8 Apr 2005 09:22:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJtaK-0005HF-Of; Fri, 08 Apr 2005 09:31:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJtP7-00021V-AB; Fri, 08 Apr 2005 09:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJtP4-00021H-QF for ltru@megatron.ietf.org; Fri, 08 Apr 2005 09:20:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16702 for ; Fri, 8 Apr 2005 09:20:05 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJtXp-00059I-N5 for ltru@ietf.org; Fri, 08 Apr 2005 09:29:10 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j38DJt0J002145; Fri, 8 Apr 2005 09:19:56 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 8 Apr 2005 09:19:55 -0400 Date: Fri, 8 Apr 2005 09:19:54 -0400 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] draft review Message-ID: <20050408131954.GL14141@skunk.reutershealth.com> References: <6.1.2.0.2.20050405014928.037ea550@mail.jefsey.com> <20050407135146.GI1795@skunk.reutershealth.com> <6.1.2.0.2.20050407161438.0513ec50@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050407161438.0513ec50@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 544c2133b952fa264803d857bb70855b Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f JFC (Jefsey) Morfin scripsit: > I thank you for this review. If I am correct my response here should only > be to say if I maintain the point or if I accept that your objection is > correct and I should remove it? Your responses are entirely at your own discretion -- and the Chair's. > I have however a general comment which is that you seem to entertain some > confusion about what is the DNS and its main usage. I know very well what the DNS is and what its main usage is. > Not a objection to a factual remark. The point is not that the format > would be wrong, but that the format wants to be unique and general. Formats don't "want" things. This is unintelligible. > The charter is precisely about making the format independent from > external elements. This confusion is part of several reponses. Not so. Construe more closely: the charter is about making the format independent of *changes* in external elements. > This is precisely the point. The way this RFC is writen and applied makes > a real difference with the Draft. Here is were comes the risk. Unintelligible. > I fail to see what is the problem about the rightness of the content? The > point is not in the access to the ISO document, but the inability of the > proposed format to support IANA registrations of ISO 3166-2 equivalents. It is entirely able to support such IANA registrations via the registration of variant tags. There is no problem with registering 'texas' or 'lyons', for example. > This is precisely the second point. When they do that it is usually for a > reason which is regionally or locally the same as ISO 3166-1 at national > level. This is what makes ISO 3166 consistent, but not the proposed > format. Unintelligible. > >> 18. 2.2.1: primary language: fixed length identification starts > >> with 2 or 3 and possibly 8 but discouraged language ID coming this way > >> only from ISO 639. This removes the possibility to consider computer > >> related (non only programming) languages, dialects, etc. nor to adapt > >> to evolutions, adjustments, and passed languages. > > > >Untrue. 36^8 possible language tags is more than enough. Discouraging > >something does not imply removing the possibility of it. > > Document the "more than enough" please. The burden of persuasion is on you to show that 2,091,771,330,064 variant tags (36^8+36^7+36^6+36^5+10^4) is insufficient. > >It is unquestionably a theoretical wart, but is absolutely required > >for backward compatibility. > > Yes. We are in agreement. You are too quick to claim that someone agrees with you when in facct there is no such agreement. > You therefore do not contest the validity of > this point. I more than contest it, I deny it absolutely. > This represents a certain lack of legal international culture. The French > law used in the Yahoo case (which has equivalent in the world) makes this > illegal. Do you imagine that the fact that fr has a 2-alpha code but bug does not would be the subject of a lawsuit anywhere in the world, given the clear standards for assigning 2-alpha codes stated on the ISO 639/RA page? Cite a legal action on point, if you please. > I do not understand this point. The point is not to re-mark-up billions > of existing documents (backward compatibility will address that) but to > save the money that trillons of clumsy tagging will cost. What is the evidence that this tagging system is clumsy? > Could you write a few lines on this. A Draft writter should not assume > three things: > - that his readers are intelligent - I know this is a fault I commonly > commit > - that his readers know things which are not documented in the Draft > (need of an explanation or of a link) > - that his readers share his visions, this is why he has to explain them > so they understand where he comes from and adapt. The purpose of extended language subtags is to deal usefully with a semantic mismatch between ISO 639-1/639-2 and ISO 639-3, whereby certain languages coded by the former are treated as more than one language by the latter. For example, zh is a single language in ISO 639-1, but is a is listed as both a single macrolanguage and a group of individual languages in ISO 639-3. The intention is that these individual languages which are parts of a macrolanguage be tagged using the extended language tag: zh will mean "Chinese" in general, whereas zh-gan will specify the specific language "Gan Chinese". > Charter. This is also easy. I do not see any "massive" change here. A change in code length amounts to changing every code in a particular ISO standard, and is a massive change indeed. > >however, the RA is quite responsive. > > Document it. This is a standard, not a newspaper. *shrug* I don't propose to write the responsiveness of the RA into the RFC. Look at the timestamps of emails in the ietf-language archive. > >> Otherwise this part is to be understood as a disguised way, concerted > >> with ISO, to block names. > > > >There is no evidence for this allegation. > > Many in ISO question ISO 15924 document. IETF and IANA have massive > additions (starting with DNS Tables), Michael Eversom already made clear > he will not consider. Being on both sides there is a CIO with the current > text. Give your evidence for these statements or withdraw them. > Unless IESG drops the rule of consensus, there is no possible consensus > on the present Draft. I am a documentation of it. At the present stage I > can only oppose. This is why I try to see my opposition reduced. But this > is a consensus process, not a compromise and obviously not an enforcement > process. This means that at the end of the day APMD and I must be equally > satisfied with the result. Not so. Consensus is not unanimity. > >> It seems that the second paragraph is a smoky verbose replay of the > >> same idea, without any procedural description nor request/provision > >> of formal proof. > > > >It may *seem* so to you. We deal here in what is so, not in what seems > >so. > > I was polite. Charges of obscurity and verbosity, especially without supporting arguments, are scarcely polite. > >Libelous nonsense. The general idea is of course to avoid duplication > >of effort, so that ISO and ietf-languages are not considering the same > >language at the same time. > > No. Such a legitimate preoccupation would be satisfied by a registration > except if a serious documented objection is risen within a 15 days > consideration period _and_ documented (for the very point you make) by > the ISO MA. Why 15 days? Languages don't arise out of nothing like software or new Internet hosts. They are pre-existing facts. Surely it is worth taking some time and trouble over their permanent encodings. > Unless you agree with my comment that these proposition do not make real > sense. I don't. > >All aliases are equally supported. Not all aliases are equally > >recommended. > > Not the text. A direct consequence of it. > >> 26. 2.4. "language tags always define a language as spoken by human > >> being for communications of information to other human beings. Computer > >> languages are explicitly excluded" has no ground in the Charter and > >> in reality. > > > >Computer languages are not languages, save metaphorically. See ISO 639. > > Sorry, ISO 639 is not the Charter. ISO 639 has obvious lacks that ISO > 639-4 is meant to correct. Impeaching supported Internet applications to > benefit from ISO 639-4/6 probable positions, together with a disregard of > the Charter, is a responsibility I will not assume. You might as well say that STD 3 is binding on human hosts as well as computer hosts. > >> Web Services relations are excluded which may speak limited languages. > > > >Do you suppose that SOAP is a language? > > I have difficulty in understanding the question. Well, all right, what do you mean by "limited languages"? > >> Coded human languages should be supported: they fit the definition. > > > >What is a coded human language? > > arbaille. Googling shows this only as the name of several places in the Basque country. But if it is an argot, then there is no problem tagging argots using an appropriate variant subtag; en-boont is such an argot. > Please give reference of the part. May be I missed it. Maybe. > There is mine. As you may know I maintain a daily survey of some IANA > files (http://ccmso.org/intldate.txt - http://ccmso.org/intlfile.txt) and > langtags will certainly be included in it. Excellent. But what has this to do with extensions, which are licensed only by new (and as yet unwritten) RFCs? > >> 38. 4. security considerations should not deal with users political > >> security outside of their network usage. Otherwise tons of such > >> considerations should be presented. > > > >The point has been raised and is documented. > > I do not understand this comment. I raise the point. Please indicate the > documentation? You claimed that the security consideration in Section 4 ought not to appear there. Someone asked for it between RFC 1766 and RFC 3066, and Harald put it in, and it remains there. > >This is a security consideration related to the existence of text > >altogether, not to the tagging of it. Or at most it is related to > >the absence of tagging. > > Security considerations are where people will go and look when a security > concern is raised. A concern with the use or misuse of the standard, not with its non-use. > >The IDN code space is unrelated in any way to the language tag code > >space. > > Private assumption. > BTW I say otherwise. It is at least through RFC 1958 basic principle and > consistency rule. Cite the section of RFC 1958 you are talking about, please. I note BTW that the second sentence of 3.2 disposes of your desire for incompatible language tags. > >There are several possible solutions, including mirrors, upgrades to > >IANA infrastructure, and load throttling by IANA. Which of these is > >done, if any, is an internal IANA question and off-topic here. > > Private assumption. > Several on-going debates (WebDAV, LDAP, DNS) in addition show that the > point start being a point of consensus. Unintelligible. > An important issue is that the Draft _does_not_document_ in which way > applications may use it. This means what is to be the expected process of > a parser reading a langtag. We are here in an ISO debate, not in an IETF > debate. (looks around) Funny, I thought this was the IETF. > >Comments 41-42 are editorial in nature and will be addressed elsewhere. > > > >> 43. 6. Stability. Confusion between document. This document does > >> not provide a mechanism but a format that can be used by the mechanism > >> described in the next document. This text has not been adapted after > >> the split. > > > >This does not seem to reflect draft-ietf-ltru-registry-01. > > We work on the published draft. Glad if next draft goes for a better > response. > > >> 44. 6. Validity. This document should define the IQ of > >> the "intelligent people" being considered or the collective IQ > >> augmentation necessary to understand the system ?? Please see the > >> ideas of the one who created the NIC and grand fathered the RFC system > >> (http://bootstrap.org). > > > >Irrelevant. The draft says that *even* intelligent people may do > >inconsistent things in the absence of guidance. > > The reference given is to the root of the "IETF core values" and to the > idea of the founders than computers augmented the intelligence of a > bootstrap (a concept today translated in WGs). The best reading is > therefore "even for the members of the WG" which is an acceptable > auto-derisive remark. Beyond that, the remark is hurting. This is a > standard, not a newspaper. You are missing my point, and I despair of clarifying it for you, but I will try. The reference here is to the fact that intelligence alone is not enough: one also needs guidance from the RFC to determine how to proceed. > >That is one of many points mentioned in the charter. It is not the > >singular goal of the draft. > > This prioritization is your personal assumption. It is you, not I, who have prioritized the goals by claiming that *the* target of the Charter is to handle things that the ISO registration authorities do not. This may reflect a mismatch between English "the" and French "le/la"; the English form has much stronger connotations of definiteness and uniqueness. Let me urge you once again to write in your own language; ce qui n'est pas clair n'est pas franc,ais, whereas English is often the language of muddle. > You do not constest the goal. This qualifies the remark. Unintelligible. > >> 47. 6. last: added text for "" is not sufficient enough, or is > >> missing in my version. > > > >Unintelligible. > > Probable mail transliteration. "--" is quoted. You constest the point, > but did not provide the reference (I may have missed). Even with this clarification I still cannot understand your point. > Debate has shown that authors intended to exclude some. Evidence? > >Answered above. There is no reason to expect such changes, and no > >evidence is given that they constitute improvements. > > Private assumptions used not to address Charter requirements. No, no, the burden of persuasion is on you. You must show why there is reason not to trust the ISO authorities to do what they have documented they will do. > >> (c) difficulty with registration and acceptance: this could be improved > >> by the subtag registration system but it seems to be made worse, > >> due to the censoring rules introduced to prevent non-ISO entries to > >> be entered in the IANA non-ISO table; > > > >"Prevent" is a malicious falsehood. > > Please propose a more adequate wording than my Franglish. I will not assume the responsibility of guessing what you might have meant. (The Western Alliance, it is said, nearly broke down during WW II over an incorrect translation of "demander" as "demand" (exiger) rather than "request".) > >> (e) lack of clear guidance to identify script and region: scripts are > >> Unicode only, > > > >Untrue. See the ISO 15924/RA registry, which lists many non-Unicode > >scripts. > > I am not sure of the ISO 15924 copy I have. It wears the name and the > copyright of its author. Would you have an URL for a stable version of > the standard? Until I have a final document I cannot comment. As is well known, official copies of ISO standards are available through your national body or directly from ISO. If you want the registry, it is available at http://www.unicode.org/iso15924/codelists.html . > >> region are 2 letter Telex codes; > > > >They are part of an international standard, whether originally > >derived from Telex codes or not. > > Unproductive comment. IETF is Datacoms. Irrelevant. > all the more if the Charter says that you are to document how they will > match these "not expected" changes. That refers to changes in individual codes, not the entire system. > >> (out of the IETF format and verbose). > > > >Out of the IETF format in what way? > > I documented: http://mltf.org/addmark.pdf. @@ > >> This makes it confuse. From what I understand it includes 3 parts: > >> (a) the subtags file with a clear format (b) the accompanying > >> registration/update forms (c) the variant tables with a clear, yet > >> less precise format. > > > >What "variant tables"? This expression does not appear in the draft, > >nor is anything described that could be so designated. > > IRT the Draft: this concerns additions made by other RFCs. Ah, extension subtags. Please make an effort not to confuse technical terms defined in the draft; it's not conducive to understanding. > >As the draft (and RFC 3066 and 1766) clearly state, the Reviewer's > >decisions may be appealed to IESG. That is not an unlimited veto. > > Yes it is. De facto as I observed the mailling list. In the way a CIO > results from his position and from his copyrigths ISO 15924. Of course Michael does not own the copyright to an ISO standard. If no one has appealed his decisions, perhaps no one disagreed with them sufficiently to do so. That does not make him a dictator. > >The expression in quotation marks is not, in fact, a quotation from > >the charter, and so need not be addressed. > > The quotation is not of the Charter. It is a quote of the need. > Its author will be dismayed from your dispise. The remark certainly hold. This section is about conflicts between the draft and the charter. This is not one. > Charter says ISO 639-3 "in particular", not "exclusively". I will wait > for ISO 639-6 and for ISO 639-4 and on MLTF positions to disqualify this > point. You are mistaken about the identity and purpose of ISO 639-4, which has been explained several times. Please do your work instead of expecting others to do it for you. I will not comment further in this thread. -- It was dreary and wearisome. Cold clammy winter still held way in this forsaken country. The only green was the scum of livid weed on the dark greasy surfaces of the sullen waters. Dead grasses and rotting reeds loomed up in the mists like ragged shadows of long-forgotten summers. --"The Passage of the Marshes" http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 11:44:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04575; Fri, 8 Apr 2005 11:44:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJvnF-0004Il-9D; Fri, 08 Apr 2005 11:53:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJve1-0003FT-2Y; Fri, 08 Apr 2005 11:43:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJvdy-0003FJ-VZ for ltru@megatron.ietf.org; Fri, 08 Apr 2005 11:43:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04530 for ; Fri, 8 Apr 2005 11:43:36 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJvmi-0004Ha-Sr for ltru@ietf.org; Fri, 08 Apr 2005 11:52:44 -0400 Received: from lns-p19-2-idf-82-251-152-231.adsl.proxad.net ([82.251.152.231] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJvdl-0002k3-AF; Fri, 08 Apr 2005 08:43:25 -0700 Message-Id: <6.1.2.0.2.20050408163329.04eb31d0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Apr 2005 17:09:18 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Prepare for a burst of issue-tracker messages In-Reply-To: <000701c53b34$106acca0$7f1afea9@oemcomputer> References: <000701c53b34$106acca0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 At 07:38 07/04/2005, Randy Presuhn wrote: >Hi - >(Co-chair hat ON) >Due to the large number of issues that have come up on this list, >and due to the terrible job we've all been doing of starting new >subject lines when we raise new issues, we'll try using an issue >tracker. > >I've gone through the archives to identify issues. Dear Randy, I have received 50 mails from you as a co-Chair in 2 hours. I have spent 8 hours of telephone exchanges, discussion with partners, calls to international oganisations and writing to respond to one (on respect of ISO bilingualism). I am sure that if you used your co-chair hat it is because each of your mail is of equivalent interest. They will also probably lead to a debate. I therefore expect that all the pending issues calls at least for a 400 hours involvement. I also note that - as far as I understant the system - you declared a rough consensus, and a point resolved, (IRT 3166 and 1988) when you get one positive response within 3 hours, and document it through a non explicit example. This is beyond what I can dedicate to the search of a consensus concerning the APMD Draft. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 11:45:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04894; Fri, 8 Apr 2005 11:45:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJvon-0004SI-84; Fri, 08 Apr 2005 11:54:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJveE-0003IS-4J; Fri, 08 Apr 2005 11:43:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJveC-0003II-FX for ltru@megatron.ietf.org; Fri, 08 Apr 2005 11:43:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04555 for ; Fri, 8 Apr 2005 11:43:50 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJvmy-0004IK-6u for ltru@ietf.org; Fri, 08 Apr 2005 11:52:57 -0400 Received: from lns-p19-2-idf-82-251-152-231.adsl.proxad.net ([82.251.152.231] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DJvdi-0002k3-PN; Fri, 08 Apr 2005 08:43:23 -0700 Message-Id: <6.1.2.0.2.20050408103302.03adfbc0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Apr 2005 17:43:06 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] registry should be bilingual In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 On 03:11 08/04/2005, rt+ltru-registry@rt.psg.com said: >Hi - >(co-chair hat ON) > >The question of adding French translations of specific fields in the registry >was raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00094.html > >Though this was discussed at some length on the ietf-languages list, I'd >like to >verify that we have a rough consensus in this WG. I believe that consensus is >to reject this proposal. Please speak up if you have compelling technical >arguments >that this WG should add French translations of specific fields in the >registry. (Various hats ON) I am surprised by this. I will only repeat my position expressed often on the IETF main list and to this IETF WG-ltru: French and English are equally compelling for the IANA language tags registry, for reasons which should be obvious for standadizers of a global system. Among these reasons: - this is the rule of the ISO standards considered by the Charter. Additions to these standards are to be homogenous with these standards. - they make sure that at least experts from two major visions were involved: a protection of the interests and rights of every other culture. - this is a necessary technical seed for the support of multilingualism over internationalisation. ISO biculturalism is a first step to what should extend to other languages like Spanish, Russian, Chinese and Arabic and, further on to every languages, as required by a Multilingual Internet. The error of RFC 3066 in that area MUST not be repeated. I measure the technical complexity of the Multilingual Internet, the IAB avoided to consider among its RFC 3869's R&D priorities. But I think that to leave its architectural organization to a grassroots process is inappropriate. Langtags are by essence the basic building blocks of this evolution. They must be standardized as such. The lack of lingual consistency between BCP 047 and ISO standards would therefore prevent any consensus. A lack of consideration of multilingualism can only to a Internet balkanization we do not want. J-F C. Morfin _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 12:09:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07509; Fri, 8 Apr 2005 12:09:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwCH-0005tH-GE; Fri, 08 Apr 2005 12:19:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJvzE-0000OR-S4; Fri, 08 Apr 2005 12:05:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJvzD-0000OE-I3 for ltru@megatron.ietf.org; Fri, 08 Apr 2005 12:05:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07103 for ; Fri, 8 Apr 2005 12:05:33 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJw80-0005Zu-Jt for ltru@ietf.org; Fri, 08 Apr 2005 12:14:40 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 09:05:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: [psg.com #900] remove region subtag 200 Date: Fri, 8 Apr 2005 09:05:11 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF01B4@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #900] remove region subtag 200 Thread-Index: AcU8NnYC5uMSQn0LStSzma417QyvzQAHglsw From: "Addison Phillips" To: "John Cowan" , "Doug Ewell" X-OriginalArrivalTime: 08 Apr 2005 16:05:11.0952 (UTC) FILETIME=[BE6AD900:01C53C54] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Not any more it doesn't. I commented it out in the most recent update of = the -01 draft precisely because of this discussion. (Note that I didn't = actually delete the paragraph!) Either the rules work or they don't. Let's not make a single exception = unless we have really good reason. NB> I didn't remove one or two examples of -200 from the draft yet, = pending final consensus. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: vendredi 8 avril 2005 05:22 > To: Doug Ewell > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: [psg.com #900] remove region subtag 200 >=20 > Doug Ewell scripsit: >=20 > > Frank Ellermann originally opposed this subtag, then appeared to = soften > > his objection. Conversely, I originally supported the subtag, then = grew > > less supportive of it. I don't recall any other dialogue concerning > > this subtag. It was retained in the April 6 registry. Currently I = am > > *very weakly* in favor of removing it. >=20 > The -01 draft has a paragraph talking about it, and I have proposed an > editorial change to strengthen its exceptionality. So I do support = it, > specially called out in the RFC as an exception for a particular = purpose > to the general rules about M.49 codes. >=20 > -- > Principles. You can't say A is John Cowan > > made of B or vice versa. All mass http://www.reutershealth.com > is interaction. --Richard Feynman http://www.ccil.org/~cowan >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 12:11:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07768; Fri, 8 Apr 2005 12:11:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwEA-0005yR-C3; Fri, 08 Apr 2005 12:21:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJw4j-0002VP-DR; Fri, 08 Apr 2005 12:11:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJw4i-0002VG-4M for ltru@megatron.ietf.org; Fri, 08 Apr 2005 12:11:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07669 for ; Fri, 8 Apr 2005 12:11:13 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwDU-0005wA-EC for ltru@ietf.org; Fri, 08 Apr 2005 12:20:21 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j38GB5nQ002763; Fri, 8 Apr 2005 12:11:05 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 8 Apr 2005 12:11:07 -0400 Date: Fri, 8 Apr 2005 12:11:07 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] Re: [psg.com #900] remove region subtag 200 Message-ID: <20050408161107.GK10046@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AEF01B4@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AEF01B4@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Doug Ewell , ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Addison Phillips scripsit: > Either the rules work or they don't. Let's not make a single exception > unless we have really good reason. I believe we do have a really good reason. So far, the ISO authorities have stuck to the _de facto_ rule "Don't reuse codes", with exactly one exception: ISO 3166/MA reused the code for Czechoslovakia. We can and should introduce an exactly compensating exception that makes it possible to map any existing codes referring to that former country into something permanent. -- Mos Eisley spaceport. You will never John Cowan see a more wretched hive of scum and jcowan@reutershealth.com villainy -- unless you watch the http://www.ccil.org/~cowan Jerry Springer Show. --georgettesworld.com http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 12:18:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08553; Fri, 8 Apr 2005 12:18:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwKt-0006Rx-Ij; Fri, 08 Apr 2005 12:27:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJwBV-0007Ew-5T; Fri, 08 Apr 2005 12:18:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJwBU-0007EC-Bp for ltru@megatron.ietf.org; Fri, 08 Apr 2005 12:18:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08488 for ; Fri, 8 Apr 2005 12:18:14 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwKG-0006LD-Id for ltru@ietf.org; Fri, 08 Apr 2005 12:27:21 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 09:18:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: [psg.com #900] remove region subtag 200 Date: Fri, 8 Apr 2005 09:18:05 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF01C2@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #900] remove region subtag 200 Thread-Index: AcU8VZhulzbdrYsHRnWHKWbwN00RXwAAJP3w From: "Addison Phillips" To: "John Cowan" X-OriginalArrivalTime: 08 Apr 2005 16:18:05.0874 (UTC) FILETIME=[8BB5F920:01C53C56] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable I'm happy to put the text back (I didn't delete on purpose), but it is = also possible to define a rule for items between Date A and Date B that = does the same thing (and cite the sole example). If we've overlooked = another item somehow (doubtful) then we'll have a guide on what to do. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] > Sent: vendredi 8 avril 2005 09:11 > To: Addison Phillips > Cc: Doug Ewell; ltru@ietf.org > Subject: Re: [Ltru] Re: [psg.com #900] remove region subtag 200 >=20 > Addison Phillips scripsit: >=20 > > Either the rules work or they don't. Let's not make a single = exception > > unless we have really good reason. >=20 > I believe we do have a really good reason. So far, the ISO = authorities > have > stuck to the _de facto_ rule "Don't reuse codes", with exactly one > exception: > ISO 3166/MA reused the code for Czechoslovakia. We can and should > introduce an > exactly compensating exception that makes it possible to map any = existing > codes > referring to that former country into something permanent. >=20 > -- > Mos Eisley spaceport. You will never John Cowan > see a more wretched hive of scum and = jcowan@reutershealth.com > villainy -- unless you watch the = http://www.ccil.org/~cowan > Jerry Springer Show. --georgettesworld.com > http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 12:24:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09486; Fri, 8 Apr 2005 12:24:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwQb-0006lf-S3; Fri, 08 Apr 2005 12:33:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJwHK-0000oU-NU; Fri, 08 Apr 2005 12:24:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJwHI-0000oI-Fz for ltru@megatron.ietf.org; Fri, 08 Apr 2005 12:24:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09437 for ; Fri, 8 Apr 2005 12:24:14 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwQ4-0006kn-Re for ltru@ietf.org; Fri, 08 Apr 2005 12:33:22 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 09:24:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #891] support non-ASCII representation ofnative name of language Date: Fri, 8 Apr 2005 09:24:01 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF01CD@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #891] support non-ASCII representation ofnative name of language Thread-Index: AcU8DBeWcdpsI8cnSkes6zIxc2ZxggASzhJA From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 08 Apr 2005 16:24:02.0362 (UTC) FILETIME=[6031B9A0:01C53C57] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0464151329==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb --===============0464151329== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVzY3JpcHRpb24gYW5kIENvbW1lbnRzIGZpZWxkcyBib3RoLg0KDQpBZGRpc29uDQoNCkFkZGlz b24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0K Q2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50 ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVy ZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2Vz QGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnXSBPbg0K PiBCZWhhbGYgT2YgRG91ZyBFd2VsbA0KPiBTZW50OiB2ZW5kcmVkaSA4IGF2cmlsIDIwMDUgMDA6 MTkNCj4gVG86IExUUlUgV29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBbTHRydV0gUmU6IFtwc2cu Y29tICM4OTFdIHN1cHBvcnQgbm9uLUFTQ0lJIHJlcHJlc2VudGF0aW9uDQo+IG9mbmF0aXZlIG5h bWUgb2YgbGFuZ3VhZ2UNCj4gDQo+ID4gVGhpcyBpc3N1ZSB3YXMgcmFpc2VkIGluDQo+ID4gaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2x0cnUvY3VycmVudC9tc2cwMDI0OC5o dG1sDQo+ID4NCj4gPiBJIGJlbGlldmUgZnVydGhlciBkaXNjdXNzaW9uIGlzIG5lZWRlZCBiZWZv cmUgd2UgZGVjbGFyZSBjb25zZW5zdXMNCj4gPiB0byBhY2NlcHQgb3IgcmVqZWN0IHRoaXMgcHJv cG9zYWwuDQo+IA0KPiBJIHN1cHBvcnQgdGhlIHJlbW92YWwgb2YgdGhlIEFTQ0lJLW9ubHkgY29u c3RyYWludC4NCj4gSSBvcHBvc2Ugb3BlbmluZyB1cCB0aGUgZGVzY3JpcHRpb24gZmllbGQgdG8g bm9uLUxhdGluIHNjcmlwdHMuDQo+IA0KPiAtRG91ZyBFd2VsbA0KPiAgRnVsbGVydG9uLCBDYWxp Zm9ybmlhDQo+ICBodHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvDQo+IA0KPiANCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0 cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQo= --===============0464151329== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0464151329==-- From ltru-bounces@ietf.org Fri Apr 8 12:33:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10160; Fri, 8 Apr 2005 12:33:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwZU-0007Gi-BW; Fri, 08 Apr 2005 12:43:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJwMt-0001g1-Bq; Fri, 08 Apr 2005 12:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJwMr-0001fN-Tb for ltru@megatron.ietf.org; Fri, 08 Apr 2005 12:30:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09729 for ; Fri, 8 Apr 2005 12:29:58 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwVe-00070p-HD for ltru@ietf.org; Fri, 08 Apr 2005 12:39:06 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 09:29:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: draft review Date: Fri, 8 Apr 2005 09:29:51 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF01D4@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: draft review Thread-Index: AcU8B38ufTjEdiTTQKaYC7smj++hNAAUH7Kg From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 08 Apr 2005 16:29:51.0923 (UTC) FILETIME=[308C8030:01C53C58] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0780942320==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 --===============0780942320== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBQbGVhc2UgcG9pbnQgb3V0IGEgcGFzc2FnZSBpbiBSRkMgMTk1OCB0aGF0IHNheXMgdGhhdCBp ZiBvbmUgcHJvdG9jb2wNCj4gdXNlcyBhIGNoYXJhY3RlciBzZXF1ZW5jZSBzdWNoIGFzICItLSIs IHRoYXQgbm8gb3RoZXIgcHJvdG9jb2wgbWF5IHVzZQ0KPiB0aGF0IHNhbWUgdHdvLWNoYXJhY3Rl ciBzZXF1ZW5jZSwgbm8gbWF0dGVyIGhvdyB1bnJlbGF0ZWQgdGhlIHVzZXMgYXJlLg0KDQpGdXJ0 aGVybW9yZSwgYXMgcG9pbnRlZCBvdXQgcHJldmlvdXNseSwgbGFuZ3VhZ2UgdGFncyBkbyBub3Qg dXNlIHRoZSBzZXF1ZW5jZSAiLS0iIGFueXdheS4gRHJhZnQtMDAgdXNlcyBpdCBpbiB0aGUgY2Fu b25pY2FsIGZpZWxkIHRvIGluZGljYXRlIGEgZGVwcmVjYXRlZCBjb2RlIChub3QgYW4gYWN0dWFs IHZhbHVlIHRvIGFzc2lnbikuDQoNCkluIHRoZSBjdXJyZW50IGRyYWZ0IG9mIERyYWZ0LTAxLCB0 aGlzIHNlcXVlbmNlIGlzIGVudGlyZWx5IHJlbW92ZWQsIHJlcGxhY2VkIGJ5IHRoZSBEZXByZWNh dGVkIGZpZWxkICh3aGljaCBjb250YWlucyBhIGRhdGUpLiBTbyB0aGlzIHdob2xlIHRocmVhZCBt YXkgYmUgbW9vdC4NCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0 aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6 YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBh IGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFpbHRvOmx0 cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIERvdWcgRXdlbGwNCj4g U2VudDogamV1ZGkgNyBhdnJpbCAyMDA1IDIzOjUxDQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXAN Cj4gU3ViamVjdDogW0x0cnVdIFJlOiBkcmFmdCByZXZpZXcNCj4gDQo+IEpGQyAoSmVmc2V5KSBN b3JmaW4gPGplZnNleSBhdCBqZWZzZXkgZG90IGNvbT4gd3JvdGU6DQo+IA0KPiA+Pj4gVGhlIGNv bmNlcm4gb24gdGhpcyBwb2ludCBpcyBoaWdoIGVub3VnaCB0byBzZWUgdGhlIERyYWZ0IGJsb2Nr ZWQuDQo+ID4+DQo+ID4+IFdob3NlIGNvbmNlcm4/ICBCbG9ja2VkIGJ5IHdob20/ICBWYWd1ZSBh bmQgdW5mb3VuZGVkLg0KPiA+DQo+ID4gVW5sZXNzIElFU0cgZHJvcHMgdGhlIHJ1bGUgb2YgY29u c2Vuc3VzLCB0aGVyZSBpcyBubyBwb3NzaWJsZQ0KPiA+IGNvbnNlbnN1cyBvbiB0aGUgcHJlc2Vu dCBEcmFmdC4gSSBhbSBhIGRvY3VtZW50YXRpb24gb2YgaXQuIEF0IHRoZQ0KPiA+IHByZXNlbnQg c3RhZ2UgSSBjYW4gb25seSBvcHBvc2UuIFRoaXMgaXMgd2h5IEkgdHJ5IHRvIHNlZSBteQ0KPiA+ IG9wcG9zaXRpb24gcmVkdWNlZC4gQnV0IHRoaXMgaXMgYSBjb25zZW5zdXMgcHJvY2Vzcywgbm90 IGEgY29tcHJvbWlzZQ0KPiA+IGFuZCBvYnZpb3VzbHkgbm90IGFuIGVuZm9yY2VtZW50IHByb2Nl c3MuIFRoaXMgbWVhbnMgdGhhdCBhdCB0aGUgZW5kDQo+ID4gb2YgdGhlIGRheSBBUE1EIGFuZCBJ IG11c3QgYmUgZXF1YWxseSBzYXRpc2ZpZWQgd2l0aCB0aGUgcmVzdWx0Lg0KPiANCj4gIkNvbnNl bnN1cyIgaW4gYW4gSUVURiBXb3JraW5nIEdyb3VwIG1lYW5zICJyb3VnaCBjb25zZW5zdXMuIiAg SXQgZG9lcw0KPiBub3QgcmVxdWlyZSBhYnNvbHV0ZSB1bmFuaW1pdHkuICBJZiB5b3UgZG91YnQg dGhpcywgYXNrIHRoZSBjaGFpcnMsIG9yDQo+IGdvIG92ZXIgdGhlaXIgaGVhZHMgdG8gdGhlIEFE cy4NCj4gDQo+ID4+PiBDb25jZXJucyBhcmUgYWxzbyB0aGUgZG91YmxlICItIiB3aGljaCBpcyBz cGVjaWZpY2FsbHkgdXNlZCBieSB0aGUNCj4gPj4+IElBTkEgY29kZSAieG4iLg0KPiA+Pg0KPiA+ PiBUaGUgSUROIGNvZGUgc3BhY2UgaXMgdW5yZWxhdGVkIGluIGFueSB3YXkgdG8gdGhlIGxhbmd1 YWdlIHRhZyBjb2RlDQo+ID4+IHNwYWNlLg0KPiA+DQo+ID4gUHJpdmF0ZSBhc3N1bXB0aW9uLg0K PiA+IEJUVyBJIHNheSBvdGhlcndpc2UuIEl0IGlzIGF0IGxlYXN0IHRocm91Z2ggUkZDIDE5NTgg YmFzaWMgcHJpbmNpcGxlDQo+ID4gYW5kIGNvbnNpc3RlbmN5IHJ1bGUuDQo+IA0KPiBQbGVhc2Ug cG9pbnQgb3V0IGEgcGFzc2FnZSBpbiBSRkMgMTk1OCB0aGF0IHNheXMgdGhhdCBpZiBvbmUgcHJv dG9jb2wNCj4gdXNlcyBhIGNoYXJhY3RlciBzZXF1ZW5jZSBzdWNoIGFzICItLSIsIHRoYXQgbm8g b3RoZXIgcHJvdG9jb2wgbWF5IHVzZQ0KPiB0aGF0IHNhbWUgdHdvLWNoYXJhY3RlciBzZXF1ZW5j ZSwgbm8gbWF0dGVyIGhvdyB1bnJlbGF0ZWQgdGhlIHVzZXMgYXJlLg0KPiANCj4gTGFuZ3VhZ2Ug dGFncyBhcmUgbm90IGVuY29kZWQgaW4gUHVueWNvZGUuICBEb21haW4gbmFtZXMsDQo+IGludGVy bmF0aW9uYWxpemVkIG9yIG90aGVyd2lzZSwgZG8gbm90IGNvbnRhaW4gbGFuZ3VhZ2UgdGFncy4g IFRoZXJlIGlzDQo+IG5vIGNvbmZsaWN0Lg0KPiANCj4gLURvdWcgRXdlbGwNCj4gIEZ1bGxlcnRv biwgQ2FsaWZvcm5pYQ0KPiAgaHR0cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiAN Cj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+IGh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg0K --===============0780942320== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0780942320==-- From ltru-bounces@ietf.org Fri Apr 8 12:35:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10322; Fri, 8 Apr 2005 12:35:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwbC-0007JU-9i; Fri, 08 Apr 2005 12:44:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJwRq-00039F-Q5; Fri, 08 Apr 2005 12:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJwRo-000390-Sq for ltru@megatron.ietf.org; Fri, 08 Apr 2005 12:35:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10286 for ; Fri, 8 Apr 2005 12:35:06 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwab-0007Ic-8g for ltru@ietf.org; Fri, 08 Apr 2005 12:44:14 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 09:34:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: [psg.com #875] should initial registry contents be madeinto an internet-draft? Date: Fri, 8 Apr 2005 09:34:57 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF01DC@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #875] should initial registry contents be madeinto an internet-draft? Thread-Index: AcU8A3uunWZB1lbOS/+M2F0gQqOSkAAVLllA From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 08 Apr 2005 16:34:58.0546 (UTC) FILETIME=[E74F7520:01C53C58] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable I still fail to see how an I-D does anything useful. Putting the draft = registry under some form of version control and making it available on = the IETF website under "internet-drafts" strikes me as sufficient. The = I-D can be (copyrights and other legal matters excluded) one line long, = containing the URI of the registry itself in a non-rubbished format = suitable for actual publication. Here's what it could say: "The initial contents of the Language Subtag Registry defined by RFC = 3066bis SHALL be the file at this location, subject to the provisions in = Section 3.6 of RFC 3066bis: = " Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Doug Ewell > Sent: jeudi 7 avril 2005 23:22 > To: LTRU Working Group > Subject: [Ltru] Re: [psg.com #875] should initial registry contents be > madeinto an internet-draft? >=20 > Frank Ellermann wrote: >=20 > > Pro, something like RfC 4021 is nice. If Doug somehow forces > > page footers below %% lines, and page headers above the next > > registry entry. Please no big gap like 4021-3864. >=20 > It's a data file. Record breaks are going to fall wherever they fall. > "48 lines per page" is completely orthogonal to this. >=20 > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 12:37:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10432; Fri, 8 Apr 2005 12:37:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwcb-0007QA-MR; Fri, 08 Apr 2005 12:46:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJwSx-0003Ub-A5; Fri, 08 Apr 2005 12:36:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJwSv-0003Sc-PB for ltru@megatron.ietf.org; Fri, 08 Apr 2005 12:36:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10382 for ; Fri, 8 Apr 2005 12:36:15 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwbj-0007K2-4h for ltru@ietf.org; Fri, 08 Apr 2005 12:45:23 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 09:36:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #874] propagation of parentorganizationdeprecations Date: Fri, 8 Apr 2005 09:36:07 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF01DE@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #874] propagation of parentorganizationdeprecations Thread-Index: AcU8AqyBaKYP0qj0TAqufCdmuFqBIAAVkHUQ From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 08 Apr 2005 16:36:08.0373 (UTC) FILETIME=[10EE3650:01C53C59] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============2026105976==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa --===============2026105976== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgbm8gbG9uZ2VyIHNlcnZlcyBhIHB1cnBvc2U6IG9taXR0aW5nIENhbm9uaWNhbCBhbmQgcHV0 dGluZyBpbiBhIERlcHJlY2F0ZWQgY29udmV5cyBleGFjdGx5IHRoZSBzYW1lIG1lYW5pbmcgSSBi ZWxpZXZlLg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24g QXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlv biBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVh dHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1i b3VuY2VzQGxpc3RzLmlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgRG91ZyBFd2VsbA0KPiBTZW50 OiBqZXVkaSA3IGF2cmlsIDIwMDUgMjM6MTYNCj4gVG86IExUUlUgV29ya2luZyBHcm91cA0KPiBT dWJqZWN0OiBbTHRydV0gUmU6IFtwc2cuY29tICM4NzRdIHByb3BhZ2F0aW9uIG9mDQo+IHBhcmVu dG9yZ2FuaXphdGlvbmRlcHJlY2F0aW9ucw0KPiANCj4gQWRkaXNvbiBQaGlsbGlwcyA8YWRkaXNv biBkb3QgcGhpbGxpcHMgYXQgcXVlc3QgZG90IGNvbT4gd3JvdGU6DQo+IA0KPiA+IFByZXZpb3Vz bHkgd2UgaGFkIG9ubHkgb25lIGZpZWxkLCAiQ2Fub25pY2FsIiwgYW5kIGl0IHNlcnZlZCBib3Ro IGZvcg0KPiA+IG1hcHBpbmcgYW5kIGluZGljYXRpbmcgZGVwcmVjYXRpb24uDQo+ID4NCj4gPiBO b3cgd2UgaGF2ZSBUV08gZmllbGRzLCAiQ2Fub25pY2FsIiBhbmQgIkRlcHJlY2F0ZWQiIGFuZCB0 aGVzZSBjYW4gYmUNCj4gPiBhc3NpZ25lZCBpbmRlcGVuZGVudGx5IGFuZCBoYXZlIHNlcGFyYXRl IHN0YWJpbGl0eSBndWFyYW50ZWVzLg0KPiA+DQo+ID4gVGh1cyBhIHN1YnRhZyBjYW4gYmUgZGVw cmVjYXRlZCAoYmVjYXVzZSBpdCB3YXMgd2l0aGRyYXduKSB3aXRob3V0DQo+ID4gbWFwcGluZyBp dCB0byBhIG5ldyB0YWcuDQo+IA0KPiBJcyB0aGlzIGEgc3VnZ2VzdGlvbiB0byBnZXQgcmlkIG9m IGFsbCBDYW5vbmljYWwgZmllbGRzIHdpdGggdmFsdWUgIi0tIg0KPiAoZGFzaC1kYXNoKT8NCj4g DQo+IC1Eb3VnIEV3ZWxsDQo+ICBGdWxsZXJ0b24sIENhbGlmb3JuaWENCj4gIGh0dHA6Ly91c2Vy cy5hZGVscGhpYS5uZXQvfmRld2VsbC8NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRy dUBsaXN0cy5pZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9sdHJ1DQoNCg== --===============2026105976== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2026105976==-- From ltru-bounces@ietf.org Fri Apr 8 13:18:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15039; Fri, 8 Apr 2005 13:18:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxGt-00014l-PF; Fri, 08 Apr 2005 13:27:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJx76-0003eY-H6; Fri, 08 Apr 2005 13:17:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJx75-0003eP-5x for ltru@megatron.ietf.org; Fri, 08 Apr 2005 13:17:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14914 for ; Fri, 8 Apr 2005 13:17:44 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxFr-0000wu-Vh for ltru@ietf.org; Fri, 08 Apr 2005 13:26:53 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j38HHaZP003081; Fri, 8 Apr 2005 13:17:36 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 8 Apr 2005 13:17:36 -0400 Date: Fri, 8 Apr 2005 13:17:35 -0400 From: John Cowan To: ned.freed@mrochek.com Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Message-ID: <20050408171735.GA20657@skunk.reutershealth.com> References: <01LMT5FFC4MO00005R@mauve.mrochek.com> <20050407175216.GE9134@skunk.reutershealth.com> <01LMTFJFCQ4400005R@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01LMTFJFCQ4400005R@mauve.mrochek.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ned.freed@mrochek.com scripsit: > A compliant RFC 3066 implementation can (and I know for a fact has) been > written that handles these exceptions through an exception table, but still > operates under the assumption that a two letter code in the second position is > a country code but a two letter code elsewhere is not. An assumption quite without warrant in the text of RFC 3066. > Like it or not, there are lots of application domains where script information > is much less readily available than country information. The intention (as Addison has developed in his messages on the subject) is to use script information only for those languages where it is commonly required. > Not true. The question is what was or was not standardized in the past. The > rules for country code positioning were clearly written and clearly normative. RFC 3066 states that a 2-letter subtag in the second position is normatively a country code. It nowhere states the converse, and goes out of its way to say that there are no rules for positions past the second. -- De plichten van een docent zijn divers, John Cowan die van het gehoor ook. jcowan@reutershealth.com --Edsger Dijkstra http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 13:30:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16102; Fri, 8 Apr 2005 13:30:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxS1-0001aX-HK; Fri, 08 Apr 2005 13:39:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJxIR-0000Y1-7d; Fri, 08 Apr 2005 13:29:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJxIP-0000Xw-Ot for ltru@megatron.ietf.org; Fri, 08 Apr 2005 13:29:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16057 for ; Fri, 8 Apr 2005 13:29:26 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxRD-0001ZZ-8l for ltru@ietf.org; Fri, 08 Apr 2005 13:38:35 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 10:29:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) Date: Fri, 8 Apr 2005 10:29:07 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF0227@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU8AedKFVHA0lX3SZmoTbJAmirRwgAV4w/w From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 08 Apr 2005 17:29:08.0337 (UTC) FILETIME=[78563610:01C53C60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1460870872==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 --===============1460870872== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJIHN0aWxsIG9wcG9zZSB0aGUgcHJlbWlzZSBvZiAiZGVmYXVsdCBzY3JpcHQiIGl0c2VsZiwg cmVnYXJkbGVzcyBvZiB0aGUNCj4gbWVjaGFuaXNtIHVzZWQgdG8gaW1wbGVtZW50IGl0LiAgDQoN CkknbSBub3Qgd2lsZCBhYm91dCBkZWZhdWx0IHNjcmlwdCwgYnV0IEkgdGhpbmsgdGhpcyBpcyBx dWFsaXRhdGl2ZWx5IGRpZmZlcmVudC4gVGhpcyBpcyBhIHN1Z2dlc3Rpb24gb2Ygd2hpY2ggbGFu Z3VhZ2VzIHdvdWxkIGJlIG1vc3QgYXBwcm9wcmlhdGUgdG8gdXNlIGEgc2NyaXB0IHdpdGguIFRo aXMgbGlzdCBpcyBub3QgY2xvc2VkIGFuZCBpcyBub24tZXhjbHVzaXZlLiBXZSBjb3VsZCBjcmVh dGUgWWV0IEFub3RoZXIgRmllbGQgVHlwZSB0byBkbyB0aGlzIHNwZWNpZmljYWxseSBmb3Igc2Ny aXB0cy4gSW4gYW55IGNhc2UsIHRoaXMgaXMgaW5mb3JtYXRpb25hbCByYXRoZXIgdGhhbiBub3Jt YXRpdmUgY29udGVudC4NCg0KPiBJZiB0aGVyZSBpcyBhIHNpbmdsZSBwaWVjZSBvZiBjb250ZW50 DQo+IGxhYmVsZWQgImVuLUN5cmwiIG9yICJlbi1BcmFiIiBvciAiZW4tRHNydCIsIHNvbWVvbmUg bWF5IGhhdmUgYSBuZWVkIHRvDQo+IHJlcXVlc3QgaXQuIA0KDQpUaGlzIHByb3Bvc2FsIGRvZXNu J3QgcHJldmVudCB0aGVzZSBjYXNlcywgbm9yIHdvdWxkIGl0IHByZXZlbnQgdGhlIHdpZGVzcHJl YWQgYWRvcHRpb24gb2Ygc2NyaXB0IHN1YnRhZ3MgZm9yIGFueSBzcGVjaWZpYyBsYW5ndWFnZSwg bm8gbWF0dGVyIGhvdyAiZGVmYXVsdCIgdGhlIHNjcmlwdCBtaWdodCBiZS4gSXQgbWVyZWx5IGFk ZHJlc3NlcyB0aGUgY29tbWVudCB0aGF0IHRoZXJlIGlzIG5vIGd1aWRhbmNlIG9uIHdoZW4gdG8g dXNlIHRoZSBzY3JpcHQgc3VidGFncy4NCg0KPiBTaW1pbGFybHksIHNvbWVvbmUgZWxzZSBtYXkg aGF2ZSBhIG5lZWQgdG8gcmVxdWVzdA0KPiAiZW4tTGF0biIgYW5kLCBieSBkb2luZyBzbywgZXhw bGljaXRseSBleGNsdWRlIHdoYXRldmVyIEN5cmlsbGljIG9yDQo+IEFhcmFpYiBvciBEZXNlcmV0 IGNvbnRlbnQgbWlnaHQgb3RoZXJ3aXNlIGJlIHJldHVybmVkLiAgSSBkbyBub3QgYmVsaWV2ZQ0K PiB3ZSBhcmUgaW4gYSBwb3NpdGlvbiB0byAicmVjb21tZW5kIiB0aGVzZSBvbiBhbnlvbmUncyBi ZWhhbGYuDQoNCldlIGFyZW4ndC4gV2UgYXJlIHJlY29tbWVuZGluZyB0aGF0IHNwZWNpZmljIGxh bmd1YWdlcyBhbHdheXMgYmUgdXNlZCB3aXRoIGEgc2NyaXB0IHN1YnRhZyAoYW5kIHdlIGRvbid0 IGRlZmluZSB3aGljaCBvbmUgcGVyLXNlKSBhbmQgYXJlIHN1Z2dlc3RpbmcgdGhhdCBvdGhlciBs YW5ndWFnZXMgbm90IHVzZSB0aGVtIHVubGVzcyB0aGVyZSBpcyBzb21lIG5lZWQuDQoNCj4gDQo+ IFRoaXMgaXMgbm90IGF0IGFsbCB0aGUgc2FtZSBhcyB0aGUgInJlY29tbWVuZGVkIHByZWZpeCIg YXNzb2NpYXRlZCB3aXRoDQo+IHZhcmlhbnQgc3VidGFncy4gIA0KDQpOb3QgcXVpdGUgdGhlIHNh bWUsIG5vLiBWYXJpYW50cyBTSE9VTEQgTk9UIGJlIHVzZWQgd2l0aCBvdGhlciBwcmVmaXhlcy4g QnV0IG5vdGUgdGhhdCBzY3JpcHRzIFNIT1VMRCBOT1QgYmUgdXNlZCB3aXRoIGxhbmd1YWdlcyBm b3Igd2hpY2ggdGhleSBhZGQgbm8gZGlzdGluZ3Vpc2hpbmcgaW5mb3JtYXRpb24gKFNlY3Rpb24g Mi4zLCBydWxlIDIpIGFuZCByZWNvbW1lbmRlZCBwcmVmaXggcHJvdmlkZXMgYSBtZWNoYW5pc20g dG8gYWNoaWV2ZSBleGFjdGx5IHRoYXQuDQoNCk5vdGUgYWxzbyB0aGF0IG9uZSBjb3VsZCB3cml0 ZSB0aGF0IHNlbnRlbmNlIGFzICJTY3JpcHRzIE1BWSBiZSB1c2VkIHdpdGggbGFuZ3VhZ2VzIGZv ciB3aGljaCB0aGV5IGFkZCBubyBkaXN0aW5ndWlzaGluZyBpbmZvcm1hdGlvbi4iIDotKQ0KDQpU aGUgZHJhZnQgZG9lc24ndCwgdGhlcmVmb3JlLCBjbGFpbSBvbW5pc2NpZW5jZSByZWdhcmRpbmcg d2hhdCBhIGdvb2QgbGFuZ3VhZ2UgdGFnIGNob2ljZSBpcyBmb3IgeW91ciBwYXJ0aWN1bGFyIGFw cGxpY2F0aW9uLCBpdCBtZXJlbHkgc3VnZ2VzdHMsIGJhc2VkIG9uIHBhc3QgZXhwZXJpZW5jZSwg d2hpY2ggc2NyaXB0IHN1YnRhZ3MgbWFrZSBnb29kIGNvbWJpbmF0aW9ucy4gRGVmYXVsdCBzY3Jp cHRzLCBieSBjb250cmFzdCwgZG8gbWFrZSBzdWNoIGEgY2xhaW0gb2Ygb21uaXNjaWVuY2UuDQoN Cj4gV2UgYXJlIGFibGUgdG8gcmVjb21tZW5kIGNlcnRhaW4gcHJlZml4ZXMgZm9yIHVzZSB3aXRo DQo+IGNlcnRhaW4gdmFyaWFudHMsIGJlY2F1c2Ugb3RoZXIgY29tYmluYXRpb25zIHdvdWxkIGJl IGFic3VyZC4gIEl0IGlzDQo+IGFic3VyZCB0byBzcGVhayBvZiBLb3JlYW4gd3JpdHRlbiBhY2Nv cmRpbmcgdG8gdGhlIDE5OTYgUmVjaHRzY2hyZWlidW5nLA0KPiBvciB0aGUgTmF0aXNvbmUgZGlh bGVjdCBvZiBYaG9zYS4gIEl0IGlzIG5vdCBhYnN1cmQgdG8gc3BlYWsgb2YgS29yZWFuDQo+IHdy aXR0ZW4gaW4gQ3lyaWxsaWMsIG9yIFhob3NhIHdyaXR0ZW4gaW4gWWksIG5vIG1hdHRlciBob3cg dW5jb21tb24NCg0KWWVzLCBJIGFncmVlLiBCdXQgdGhlIHF1ZXN0aW9uIGlzbid0IG9uZSBvZiB0 YWdnaW5nIHVudXN1YWwgY29udGVudC4gSXQgaXMgYSBxdWVzdGlvbiBvZiBob3cgdG8gdGFnIHJ1 bi1vZi10aGUtbWlsbCBjb250ZW50LiAnLUhhbmcnIGFkZHMgbm8gZGlzdGluZ3Vpc2hpbmcgaW5m b3JtYXRpb24gdG8gdGhlIGxhbmd1YWdlIHN1YnRhZyAna28nLiBJIGNhbiBjZXJ0YWlubHkgaW1h Z2luZSB0YWdnaW5nIGNvbnRlbnQgImtvLUN5cmwiIHRvIGRpc3Rpbmd1aXNoIGl0IHByb3Blcmx5 LCB0aG91Z2guDQoNCkFueXdheSwgaXQgaXMganVzdCBhbiBpZGVhIGZvciBob3cgdG8gYnJlYWsg dGhlIGRlYWRsb2NrIG9uIHRoZSBvbmx5IHJlYWwgc3Vic3RhbnRpdmUgb2JqZWN0aW9uIHRvIHRo ZSBkcmFmdCBhcyBhIHdob2xlIGF0IHRoaXMgZGF0ZS4gT25jZSB0aGUgZ2VuZXJhbCBkZXNpZ24g cmVhY2hlcyBmdWxsIGNvbnNlbnN1cywgdGhlbiBhbGwgb2YgdGhlIHJlbWFpbmluZyBkaXNjdXNz aW9uIGlzIGFib3V0IHRleHQgaW4gdGhlIGRyYWZ0LCB3aGljaCBpcyBmaWdodGluZyBvdmVyIHRo ZSB0YWJsZSBzY3JhcHMgYXMgZmFyIGFzIEknbSBjb25jZXJuZWQuDQoNCkFkZGlzb24NCg0KQWRk aXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJl DQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJ bnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0 dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5j ZXNAbGlzdHMuaWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmddIE9u DQo+IEJlaGFsZiBPZiBEb3VnIEV3ZWxsDQo+IFNlbnQ6IGpldWRpIDcgYXZyaWwgMjAwNSAyMzox MQ0KPiBUbzogTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFtMdHJ1XSBSZTogQ29tcGF0 aWJpbGl0eSB3aXRoIGV4aXN0aW5nIHVzZSAoTERBUCkNCj4gDQo+IEpvaG4gQ293YW4gPGpjb3dh biBhdCByZXV0ZXJzaGVhbHRoIGRvdCBjb20+IHdyb3RlOg0KPiANCj4gPj4gV2hhdCBpZiB3ZSBw dXQgUmVjb21tZW5kZWQgUHJlZml4IGZpZWxkcyBvbnRvIHNjcmlwdCBzdWJ0YWdzIGluIHRoZQ0K PiA+PiByZWdpc3RyeT8NCj4gPj4NCj4gPj4gVGhpcyBzb2x2ZXMgdGhlIGRlZmF1bHQgc2NyaXB0 IHByb2JsZW0gYmVjYXVzZSB3ZSBhcmUgcmVjb21tZW5kaW5nDQo+ID4+IHdoZW4gdG8gdXNlIHRo ZSBzdWJ0YWcgKHdoZW4geW91ciBsYW5ndWFnZSBpcyBpbiB0aGUgbGlzdCBmb3IgdGhhdA0KPiA+ PiBzdWJ0YWcpLg0KPiA+DQo+ID4gRXhjZWxsZW50ISAgU28gTGF0biB3b3VsZCBoYXZlIGEgUmVj b21tZW5kZWQgUHJlZml4IG9mIGF6IChhbW9uZw0KPiA+IG90aGVycykgYnV0IG5vdCBlbi4NCj4g DQo+IEkgc3RpbGwgb3Bwb3NlIHRoZSBwcmVtaXNlIG9mICJkZWZhdWx0IHNjcmlwdCIgaXRzZWxm LCByZWdhcmRsZXNzIG9mIHRoZQ0KPiBtZWNoYW5pc20gdXNlZCB0byBpbXBsZW1lbnQgaXQuICBJ ZiB0aGVyZSBpcyBhIHNpbmdsZSBwaWVjZSBvZiBjb250ZW50DQo+IGxhYmVsZWQgImVuLUN5cmwi IG9yICJlbi1BcmFiIiBvciAiZW4tRHNydCIsIHNvbWVvbmUgbWF5IGhhdmUgYSBuZWVkIHRvDQo+ IHJlcXVlc3QgaXQuICBTaW1pbGFybHksIHNvbWVvbmUgZWxzZSBtYXkgaGF2ZSBhIG5lZWQgdG8g cmVxdWVzdA0KPiAiZW4tTGF0biIgYW5kLCBieSBkb2luZyBzbywgZXhwbGljaXRseSBleGNsdWRl IHdoYXRldmVyIEN5cmlsbGljIG9yDQo+IEFhcmFpYiBvciBEZXNlcmV0IGNvbnRlbnQgbWlnaHQg b3RoZXJ3aXNlIGJlIHJldHVybmVkLiAgSSBkbyBub3QgYmVsaWV2ZQ0KPiB3ZSBhcmUgaW4gYSBw b3NpdGlvbiB0byAicmVjb21tZW5kIiB0aGVzZSBvbiBhbnlvbmUncyBiZWhhbGYuDQo+IA0KPiBU aGlzIGlzIG5vdCBhdCBhbGwgdGhlIHNhbWUgYXMgdGhlICJyZWNvbW1lbmRlZCBwcmVmaXgiIGFz c29jaWF0ZWQgd2l0aA0KPiB2YXJpYW50IHN1YnRhZ3MuICBXZSBhcmUgYWJsZSB0byByZWNvbW1l bmQgY2VydGFpbiBwcmVmaXhlcyBmb3IgdXNlIHdpdGgNCj4gY2VydGFpbiB2YXJpYW50cywgYmVj YXVzZSBvdGhlciBjb21iaW5hdGlvbnMgd291bGQgYmUgYWJzdXJkLiAgSXQgaXMNCj4gYWJzdXJk IHRvIHNwZWFrIG9mIEtvcmVhbiB3cml0dGVuIGFjY29yZGluZyB0byB0aGUgMTk5NiBSZWNodHNj aHJlaWJ1bmcsDQo+IG9yIHRoZSBOYXRpc29uZSBkaWFsZWN0IG9mIFhob3NhLiAgSXQgaXMgbm90 IGFic3VyZCB0byBzcGVhayBvZiBLb3JlYW4NCj4gd3JpdHRlbiBpbiBDeXJpbGxpYywgb3IgWGhv c2Egd3JpdHRlbiBpbiBZaSwgbm8gbWF0dGVyIGhvdyB1bmNvbW1vbg0KPiB0aG9zZSBjb21iaW5h dGlvbnMgbWF5IGJlLg0KPiANCj4gLURvdWcgRXdlbGwNCj4gIEZ1bGxlcnRvbiwgQ2FsaWZvcm5p YQ0KPiAgaHR0cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiANCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1h aWxpbmcgbGlzdA0KPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg0K --===============1460870872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1460870872==-- From ltru-bounces@ietf.org Fri Apr 8 13:31:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16204; Fri, 8 Apr 2005 13:31:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxTL-0001ha-JC; Fri, 08 Apr 2005 13:40:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJxKA-0000md-CB; Fri, 08 Apr 2005 13:31:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJxK9-0000mY-6A for ltru@megatron.ietf.org; Fri, 08 Apr 2005 13:31:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16192 for ; Fri, 8 Apr 2005 13:31:14 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxSx-0001hN-3l for ltru@ietf.org; Fri, 08 Apr 2005 13:40:23 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 10:31:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Compatibility with existing use (LDAP) Date: Fri, 8 Apr 2005 10:31:07 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF022B@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU8XxDe/bCxS9tUTQaG54aQVDf5FQAAXTNA From: "Addison Phillips" To: "John Cowan" , X-OriginalArrivalTime: 08 Apr 2005 17:31:07.0909 (UTC) FILETIME=[BF9B7350:01C53C60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable To back up for a second: does my proposal about recommended prefix (I = think you indicated initial enthusiasm, Ned) solve this problem = sufficiently to move forward with this design? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: vendredi 8 avril 2005 10:18 > To: ned.freed@mrochek.com > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) >=20 > ned.freed@mrochek.com scripsit: >=20 > > A compliant RFC 3066 implementation can (and I know for a fact has) = been > > written that handles these exceptions through an exception table, = but > still > > operates under the assumption that a two letter code in the second > position is > > a country code but a two letter code elsewhere is not. >=20 > An assumption quite without warrant in the text of RFC 3066. >=20 > > Like it or not, there are lots of application domains where script > information > > is much less readily available than country information. >=20 > The intention (as Addison has developed in his messages on the = subject) is > to use script information only for those languages where it is = commonly > required. >=20 > > Not true. The question is what was or was not standardized in the = past. > The > > rules for country code positioning were clearly written and clearly > normative. >=20 > RFC 3066 states that a 2-letter subtag in the second position is > normatively > a country code. It nowhere states the converse, and goes out of its = way > to say that there are no rules for positions past the second. >=20 > -- > De plichten van een docent zijn divers, John Cowan > die van het gehoor ook. = jcowan@reutershealth.com > --Edsger Dijkstra = http://www.ccil.org/~cowan >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 13:54:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17598; Fri, 8 Apr 2005 13:54:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxp4-0002h0-3A; Fri, 08 Apr 2005 14:03:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJxen-0004cb-Qe; Fri, 08 Apr 2005 13:52:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJxSy-0002Nn-92 for ltru@megatron.ietf.org; Fri, 08 Apr 2005 13:40:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16939 for ; Fri, 8 Apr 2005 13:40:21 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJxbl-00028m-0f for ltru@ietf.org; Fri, 08 Apr 2005 13:49:30 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMUIR4QTV400005R@mauve.mrochek.com> for ltru@ietf.org; Fri, 08 Apr 2005 10:40:16 -0700 (PDT) Date: Fri, 08 Apr 2005 10:34:07 -0700 (PDT) In-reply-to: "Your message dated Fri, 08 Apr 2005 13:17:35 -0400" <20050408171735.GA20657@skunk.reutershealth.com> Message-id: <01LMUJXEBHJK00005R@mauve.mrochek.com> References: <01LMT5FFC4MO00005R@mauve.mrochek.com> <20050407175216.GE9134@skunk.reutershealth.com> <01LMTFJFCQ4400005R@mauve.mrochek.com> <20050408171735.GA20657@skunk.reutershealth.com> Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) To: John Cowan X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Fri, 08 Apr 2005 13:52:36 -0400 Cc: ltru@ietf.org, ned.freed@mrochek.com X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7BIT > ned.freed@mrochek.com scripsit: > > A compliant RFC 3066 implementation can (and I know for a fact has) been > > written that handles these exceptions through an exception table, but still > > operates under the assumption that a two letter code in the second position is > > a country code but a two letter code elsewhere is not. > An assumption quite without warrant in the text of RFC 3066. On the contrary, I believe the RFC is very clear on this . It says: The following rules apply to the second subtag: - All 2-letter subtags are interpreted as ISO 3166 alpha-2 country codes from [ISO 3166], or subsequently assigned by the ISO 3166 maintenance agency or governing standardization bodies, denoting the area to which this language variant relates. It also says that country codes can appear in other places: The information in a subtag may for instance be: - Country identification, such as en-US (this usage is described in ISO 639) Given this text, I believe an implementation seeking to perform matches based on country codes is compliant if: (1) It treats a two letter code in the second position as a country code. (2) It uses an extensible exception table to enumerate cases where country codes appear in other places that should be matched. Please explain why such an implementation is incompliant. > > Like it or not, there are lots of application domains where script information > > is much less readily available than country information. > The intention (as Addison has developed in his messages on the subject) is > to use script information only for those languages where it is commonly > required. This has never been made clear, and as I have said elsewhere, simple directives along these lines are often ignored. > > Not true. The question is what was or was not standardized in the past. The > > rules for country code positioning were clearly written and clearly normative. > RFC 3066 states that a 2-letter subtag in the second position is normatively > a country code. It nowhere states the converse, and goes out of its way > to say that there are no rules for positions past the second. Which, as I have stated over and over and over, can be readily handled with a table. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 14:26:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20563; Fri, 8 Apr 2005 14:26:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJyKI-0004K2-IZ; Fri, 08 Apr 2005 14:35:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJyA2-0003zC-Qf; Fri, 08 Apr 2005 14:24:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJyA1-0003z7-8v for ltru@megatron.ietf.org; Fri, 08 Apr 2005 14:24:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20420 for ; Fri, 8 Apr 2005 14:24:52 -0400 (EDT) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJyIo-0004I0-Hw for ltru@ietf.org; Fri, 08 Apr 2005 14:33:59 -0400 Received: from h-68-165-6-58.snvacaid.dynamic.covad.net ([68.165.6.58] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJy9p-0007hS-00 for ltru@ietf.org; Fri, 08 Apr 2005 11:24:41 -0700 Message-ID: <002501c53c68$6a89ac80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050408000100.CBWK2132.mta5.adelphia.net@megatron.ietf.org><00d601c53c0a$46f184e0$030aa8c0@DEWELL> <20050408121617.GJ14141@skunk.reutershealth.com> Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fields from ISOdocuments Date: Fri, 8 Apr 2005 11:25:31 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Hi - (Please note issue number restored to subject line.) > From: "John Cowan" > To: "Doug Ewell" > Cc: > Sent: Friday, April 08, 2005 5:16 AM > Subject: Re: [Ltru] Re: registry should copy non-English fields from ISOdocuments > > Doug Ewell scripsit: > > > >> Bruce wanted the French names in the draft-10 last call, IIRC > > >> nobody else wanted this. > > > > > > Uncorrect. Serveral wanted it. I am one. > > > > And Bruce Lilly wanted it. That makes two. Anyone else? > > I favor including the French data from ISO as well. > > > > For two main reasons: > > > - consistency with the concerned ISO document > > > - same reason as ISO: crossculture validation is a warranty against > > > monocultural dominance. > > I agree with these reasons. As a data point, I believe Peter Constable > said in ietf-languages that the French data was helpful in determining > exactly which language was meant in certain cases by a specific code. ... (co-chair hat ON) While recollections of what happened on ietf-languages are useful historical background, we cannot use them to determine consensus HERE. If anyone supports or opposes the proposal, they need to state their case ON THIS LIST. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 14:31:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20844; Fri, 8 Apr 2005 14:31:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJyPL-0004ZO-Hi; Fri, 08 Apr 2005 14:40:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJyDm-00057L-19; Fri, 08 Apr 2005 14:28:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJyDk-000568-FN for ltru@megatron.ietf.org; Fri, 08 Apr 2005 14:28:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20739 for ; Fri, 8 Apr 2005 14:28:43 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJyMY-0004Ru-TQ for ltru@ietf.org; Fri, 08 Apr 2005 14:37:51 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJyDj-0006Yu-5k for ltru@ietf.org; Fri, 08 Apr 2005 18:28:43 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: Re: [Ltru] Re: [psg.com #891] support non-ASCII representationofnative name of language RT-Ticket: psg.com #891 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 18:28:43 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Hi - (Co-chair hat ON) Ok, I'll mark this issue RESOLVED. Randy > From: "Addison Phillips" > To: "Doug Ewell" ; "LTRU Working Group" > Sent: Friday, April 08, 2005 9:24 AM > Subject: RE: [Ltru] Re: [psg.com #891] support non-ASCII representationofnative name of language > > Description and Comments fields both. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Doug Ewell > > Sent: vendredi 8 avril 2005 00:19 > > To: LTRU Working Group > > Subject: [Ltru] Re: [psg.com #891] support non-ASCII representation > > ofnative name of language > > > > > This issue was raised in > > > http://www.ietf.org/mail-archive/web/ltru/current/msg00248.html > > > > > > I believe further discussion is needed before we declare consensus > > > to accept or reject this proposal. > > > > I support the removal of the ASCII-only constraint. > > I oppose opening up the description field to non-Latin scripts. > > > > -Doug Ewell > > Fullerton, California > > http://users.adelphia.net/~dewell/ > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > -------------------------------------------------------------------------------- > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 14:31:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20867; Fri, 8 Apr 2005 14:31:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJyPV-0004ZS-CO; Fri, 08 Apr 2005 14:40:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJyDm-00057P-4H; Fri, 08 Apr 2005 14:28:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJyDl-00056D-4I for ltru@megatron.ietf.org; Fri, 08 Apr 2005 14:28:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20742 for ; Fri, 8 Apr 2005 14:28:44 -0400 (EDT) Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJyMY-0004Rt-IH for ltru@ietf.org; Fri, 08 Apr 2005 14:37:51 -0400 Received: from www by psg.com with local (Exim 4.44 (FreeBSD)) id 1DJyDi-0006Yl-Qg for ltru@ietf.org; Fri, 08 Apr 2005 18:28:42 +0000 MIME-Version: 1.0 In-Reply-To: X-Mailer: Perl5 Mail::Internet v1.64 Message-ID: Content-Type: text/plain; charset="utf-8" RT-Originator: randy_presuhn@mindspring.com X-RT-Original-Encoding: utf-8 Managed-BY: RT 3.0.12 (http://www.bestpractical.com/rt/) Subject: Re: [Ltru] Re: [psg.com #891] support non-ASCII representationofnative name of language RT-Ticket: psg.com #891 Precedence: bulk X-RT-Loop-Prevention: psg.com From: rt+ltru-registry@rt.psg.com Date: Fri, 08 Apr 2005 18:28:42 +0000 X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Reply-To: rt+ltru-registry@rt.psg.com List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Hi - (Co-chair hat ON) Ok, I'll mark this issue RESOLVED. Randy > From: "Addison Phillips" > To: "Doug Ewell" ; "LTRU Working Group" > Sent: Friday, April 08, 2005 9:24 AM > Subject: RE: [Ltru] Re: [psg.com #891] support non-ASCII representationofnative name of language > > Description and Comments fields both. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Doug Ewell > > Sent: vendredi 8 avril 2005 00:19 > > To: LTRU Working Group > > Subject: [Ltru] Re: [psg.com #891] support non-ASCII representation > > ofnative name of language > > > > > This issue was raised in > > > http://www.ietf.org/mail-archive/web/ltru/current/msg00248.html > > > > > > I believe further discussion is needed before we declare consensus > > > to accept or reject this proposal. > > > > I support the removal of the ASCII-only constraint. > > I oppose opening up the description field to non-Latin scripts. > > > > -Doug Ewell > > Fullerton, California > > http://users.adelphia.net/~dewell/ > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > -------------------------------------------------------------------------------- > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 14:35:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21126; Fri, 8 Apr 2005 14:35:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJyTK-0004i2-Px; Fri, 08 Apr 2005 14:44:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJyJx-0006Es-FY; Fri, 08 Apr 2005 14:35:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJyJv-0006Em-A2 for ltru@megatron.ietf.org; Fri, 08 Apr 2005 14:35:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21092 for ; Fri, 8 Apr 2005 14:35:05 -0400 (EDT) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJySi-0004hh-3n for ltru@ietf.org; Fri, 08 Apr 2005 14:44:13 -0400 Received: from h-68-165-6-58.snvacaid.dynamic.covad.net ([68.165.6.58] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJyJr-0002RP-00 for ltru@ietf.org; Fri, 08 Apr 2005 11:35:03 -0700 Message-ID: <004b01c53c69$ddd23260$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #891] support non-ASCIIrepresentationofnative name of language Date: Fri, 8 Apr 2005 11:36:23 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hi - > From: > Cc: > Sent: Friday, April 08, 2005 11:28 AM > Subject: Re: [Ltru] Re: [psg.com #891] support non-ASCIIrepresentationofnative name of language > > Hi - > > (Co-chair hat ON) > > Ok, I'll mark this issue RESOLVED. .... OOOPS! I spoke too soon. I re-read Doug's and Addison's comments, and realized we have some disagreements here, so I'm leaving the issue "open". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 15:19:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25523; Fri, 8 Apr 2005 15:19:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJz9j-0006qC-NM; Fri, 08 Apr 2005 15:28:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJz0D-0006u4-Uo; Fri, 08 Apr 2005 15:18:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJz0D-0006tz-7I for ltru@megatron.ietf.org; Fri, 08 Apr 2005 15:18:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25462 for ; Fri, 8 Apr 2005 15:18:47 -0400 (EDT) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJz90-0006pa-Jf for ltru@ietf.org; Fri, 08 Apr 2005 15:27:55 -0400 Received: from h-68-165-6-58.snvacaid.dynamic.covad.net ([68.165.6.58] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DJz09-0006lg-00 for ltru@ietf.org; Fri, 08 Apr 2005 12:18:45 -0700 Message-ID: <00df01c53c6f$f91a1640$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0AEF01DC@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: [psg.com #875] should initial registry contents be made into an internet-draft? Date: Fri, 8 Apr 2005 12:19:28 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Hi - > From: "Addison Phillips" > To: "Doug Ewell" ; "LTRU Working Group" > Sent: Friday, April 08, 2005 9:34 AM > Subject: RE: [Ltru] Re: [psg.com #875] should initial registry contents bemadeinto an internet-draft? (re-formatted so I can read it) > I still fail to see how an I-D does anything useful. > Putting the draft registry under some form of version control > and making it available on the IETF website under "internet-drafts" > strikes me as sufficient. > The I-D can be (copyrights and other legal matters excluded) one line long, > containing the URI of the registry itself in a non-rubbished format suitable for actual publication. > > Here's what it could say: > > "The initial contents of the Language Subtag Registry defined by RFC 3066bis > SHALL be the file at this location, subject to the provisions in Section 3.6 of RFC > 3066bis: " ... As a contributor... This approach misses the whole point of bothering to put the initial content into an i-d, and is equivalent to the registry-00 proposal. The concern is about ensuring the integrity of whatever IANA is given a pointer to, and that that initial content that is there when IANA retrieves it is what was approved by the WG. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 15:49:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02811; Fri, 8 Apr 2005 15:48:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJzcG-0001PN-AE; Fri, 08 Apr 2005 15:58:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJz6m-0007wd-GE; Fri, 08 Apr 2005 15:25:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJz6l-0007wN-C6 for ltru@megatron.ietf.org; Fri, 08 Apr 2005 15:25:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26150 for ; Fri, 8 Apr 2005 15:25:32 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJzFX-00078I-EM for ltru@ietf.org; Fri, 08 Apr 2005 15:34:40 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 12:25:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: [psg.com #875] should initial registry contents bemade into an internet-draft? Date: Fri, 8 Apr 2005 12:25:06 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF02D8@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #875] should initial registry contents bemade into an internet-draft? Thread-Index: AcU8b+HhriTMb3Q0T7aJvuH/joTwDwAACRow From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 08 Apr 2005 19:25:06.0737 (UTC) FILETIME=[ABDDCA10:01C53C70] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable > As a contributor... > This approach misses the whole point of bothering to put the initial > content into an i-d, and is equivalent to the registry-00 proposal. = The > concern is about ensuring the integrity of whatever IANA is given a > pointer to, and that that initial content that is there when IANA > retrieves > it is what was approved by the WG. Well, yes, that's what I'm saying. Putting page breaks into the document = to make it an I-D just to have IANA pluck them out again seems like a = waste of time. I'm just bemused by the notion that somehow a document hosted at a = particular address (especially if it is handled like an I-D) is somehow = inferior to a document that *is* an I-D but which IANA must muck around = with to make a "clean" registry. But since I don't make the registry, you can count me as "not caring". = Close the issue under whatever the consensus is. I *only* care about = text in the -01 draft. The content of the registry is entirely driven by = that anyway. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: vendredi 8 avril 2005 12:19 > To: LTRU Working Group > Subject: Re: [Ltru] Re: [psg.com #875] should initial registry = contents > bemade into an internet-draft? >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "Doug Ewell" ; "LTRU Working Group" > > > Sent: Friday, April 08, 2005 9:34 AM > > Subject: RE: [Ltru] Re: [psg.com #875] should initial registry = contents > bemadeinto an internet-draft? >=20 > (re-formatted so I can read it) >=20 > > I still fail to see how an I-D does anything useful. > > Putting the draft registry under some form of version control > > and making it available on the IETF website under "internet-drafts" > > strikes me as sufficient. > > The I-D can be (copyrights and other legal matters excluded) one = line > long, > > containing the URI of the registry itself in a non-rubbished format > suitable for actual publication. > > > > Here's what it could say: > > > > "The initial contents of the Language Subtag Registry defined by RFC > 3066bis > > SHALL be the file at this location, subject to the provisions in = Section > 3.6 of RFC > > 3066bis: = are>" > ... >=20 > As a contributor... > This approach misses the whole point of bothering to put the initial > content into an i-d, and is equivalent to the registry-00 proposal. = The > concern is about ensuring the integrity of whatever IANA is given a > pointer to, and that that initial content that is there when IANA > retrieves > it is what was approved by the WG. >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 15:56:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05360; Fri, 8 Apr 2005 15:56:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJzj6-0002Y5-Fj; Fri, 08 Apr 2005 16:05:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzGs-00028f-KP; Fri, 08 Apr 2005 15:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzGp-00027v-RN for ltru@megatron.ietf.org; Fri, 08 Apr 2005 15:36:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28373 for ; Fri, 8 Apr 2005 15:35:54 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJzPW-0007yN-Sa for ltru@ietf.org; Fri, 08 Apr 2005 15:45:02 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j38JZWD1027377; Fri, 8 Apr 2005 12:35:32 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AF47F>; Fri, 8 Apr 2005 12:35:32 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , John Cowan , ned.freed@mrochek.com Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) Date: Fri, 8 Apr 2005 12:35:31 -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: a7d2e37451f7f22841e3b6f40c67db0f Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Hi Addison, I'm lost (hundreds of LTRU messages polluted my inbox today). Does your suggestion about "recommended prefix" include moving the country codes firmly back to second position? If yes, then I agree. If no, then nothing substantive is accomplished. The idea that compatible software that supports comparison of language tags in the RFC3066bis era MUST have a copy of the registry is a lousy idea. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Friday, April 08, 2005 1:31 PM > To: John Cowan; ned.freed@mrochek.com > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) > > > To back up for a second: does my proposal about recommended > prefix (I think you indicated initial enthusiasm, Ned) solve > this problem sufficiently to move forward with this design? > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of John Cowan > > Sent: vendredi 8 avril 2005 10:18 > > To: ned.freed@mrochek.com > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) > > > > ned.freed@mrochek.com scripsit: > > > > > A compliant RFC 3066 implementation can (and I know for a > fact has) been > > > written that handles these exceptions through an > exception table, but > > still > > > operates under the assumption that a two letter code in the second > > position is > > > a country code but a two letter code elsewhere is not. > > > > An assumption quite without warrant in the text of RFC 3066. > > > > > Like it or not, there are lots of application domains where script > > information > > > is much less readily available than country information. > > > > The intention (as Addison has developed in his messages on > the subject) is > > to use script information only for those languages where it > is commonly > > required. > > > > > Not true. The question is what was or was not > standardized in the past. > > The > > > rules for country code positioning were clearly written > and clearly > > normative. > > > > RFC 3066 states that a 2-letter subtag in the second position is > > normatively > > a country code. It nowhere states the converse, and goes > out of its way > > to say that there are no rules for positions past the second. > > > > -- > > De plichten van een docent zijn divers, John Cowan > > die van het gehoor ook. > jcowan@reutershealth.com > > --Edsger Dijkstra http://www.ccil.org/~cowan > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 16:03:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07856; Fri, 8 Apr 2005 16:03:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJzqE-0003Ye-75; Fri, 08 Apr 2005 16:12:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzhB-0001AP-5j; Fri, 08 Apr 2005 16:03:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJzh9-00016k-GU for ltru@megatron.ietf.org; Fri, 08 Apr 2005 16:03:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07783 for ; Fri, 8 Apr 2005 16:03:09 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJzpy-0003Rh-DR for ltru@ietf.org; Fri, 08 Apr 2005 16:12:18 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 13:02:57 -0700 content-class: urn:content-classes:message Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) Date: Fri, 8 Apr 2005 13:02:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF031C@irvmbxw01.quest.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU8cjmjIhs0krc9TJ6F28+uHwYfOAAABFMw From: "Addison Phillips" To: "McDonald, Ira" , "John Cowan" , X-OriginalArrivalTime: 08 Apr 2005 20:02:57.0809 (UTC) FILETIME=[F587E010:01C53C75] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable > Does your suggestion about "recommended prefix" include moving > the country codes firmly back to second position? Emphatically not. I think that is a poor choice for all the reasons = previously enumerated. Putting script after region only solves = identification of region codes for a certain subset of language tags and = implementations and does so at great disadvantage to language tags and = implementations that require script codes. I disagree that my proposal accomplishes nothing substantive: you really = should go read it first.=20 What it does is help users avoid choosing ill-advised tags that include = scripts for those languages where it is of little value and likewise = include them consistently for languages where it is of importance. There is NO requirement that software have a copy of the registry.=20 Software that uses prefixes and remove-from-right (RFR) previously = (which is many but not all of the current implementations) all work = out-of-the-box with this solution, since the problem was having to "know = something" about the tags in order to expand or ignore the script subtag = when matching. This does away with the need to do that by making tag = prefixes consistent for a given language range.=20 Users are advised that their tags choices may cause selection problems = if they choose to use script subtags with a prefix that normally would = not take one or with content where script collections subtags were not = previously used. (i.e. this doesn't solve all possible problems, but = then no solution does) Software such as Ned Freed has described, which depends on the country = code being in the second position and may use an exception table to find = it in a limited number of other cases, does exist. These implementations = will not recognize the region subtag in tags that use script subtags. = They wouldn't have recognized these tags anyway and treated them as = unknown registered tags: essentially "I don't know what this is". = Matching may or may not have proceeded on RFR (RFC 2616 matching) terms = after that. We can debate whether an implementation that doesn't is = "broken" or not. One that does would be in exactly the same position as = the other RFR processors (see above). One that does not has a problem = with that subset of tags. What my proposal does is try to limit how often script subtags are used = by advising tag consumers about when to use them, but this same = information could easily be used to generate a new exception table for = the "Freed-style" implementations. Also: the nature of 3066bis tags, unlike 3066 tags, is that you NEVER = need the registry to identify the region subtag (or any other subtag). = The tag format is stricter and does it for you. You can write a = "Freed-style" algorithm based on 3066bis and it will always work (to the = extent that the subtag types can be identified), which is NOT something = you can say about 3066 Freed-style algorithms (*and* that exception = table is a copy of the registry!!) Yes, existing processors may not recognize tags such as "sr-Cyrl-CS" as = containing a region subtag.=20 But with the recommended prefix on Cyrl one could update such an = implementation, which, in fact, is already necessary, even if IANA = hasn't gotten around to noticing just yet. So it is a compromise that tries to address some of the problems of = compatibility without changing the design. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: vendredi 8 avril 2005 12:36 > To: Addison Phillips; John Cowan; ned.freed@mrochek.com > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) >=20 > Hi Addison, >=20 > I'm lost (hundreds of LTRU messages polluted my inbox today). >=20 > Does your suggestion about "recommended prefix" include moving > the country codes firmly back to second position? >=20 > If yes, then I agree. If no, then nothing substantive is > accomplished. >=20 > The idea that compatible software that supports comparison of > language tags in the RFC3066bis era MUST have a copy of the > registry is a lousy idea. >=20 > Cheers, > - Ira >=20 > 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 >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of Addison Phillips > > Sent: Friday, April 08, 2005 1:31 PM > > To: John Cowan; ned.freed@mrochek.com > > Cc: ltru@ietf.org > > Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) > > > > > > To back up for a second: does my proposal about recommended > > prefix (I think you indicated initial enthusiasm, Ned) solve > > this problem sufficiently to move forward with this design? > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] On > > > Behalf Of John Cowan > > > Sent: vendredi 8 avril 2005 10:18 > > > To: ned.freed@mrochek.com > > > Cc: ltru@ietf.org > > > Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) > > > > > > ned.freed@mrochek.com scripsit: > > > > > > > A compliant RFC 3066 implementation can (and I know for a > > fact has) been > > > > written that handles these exceptions through an > > exception table, but > > > still > > > > operates under the assumption that a two letter code in the = second > > > position is > > > > a country code but a two letter code elsewhere is not. > > > > > > An assumption quite without warrant in the text of RFC 3066. > > > > > > > Like it or not, there are lots of application domains where = script > > > information > > > > is much less readily available than country information. > > > > > > The intention (as Addison has developed in his messages on > > the subject) is > > > to use script information only for those languages where it > > is commonly > > > required. > > > > > > > Not true. The question is what was or was not > > standardized in the past. > > > The > > > > rules for country code positioning were clearly written > > and clearly > > > normative. > > > > > > RFC 3066 states that a 2-letter subtag in the second position is > > > normatively > > > a country code. It nowhere states the converse, and goes > > out of its way > > > to say that there are no rules for positions past the second. > > > > > > -- > > > De plichten van een docent zijn divers, John Cowan > > > die van het gehoor ook. > > jcowan@reutershealth.com > > > --Edsger Dijkstra > http://www.ccil.org/~cowan > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 16:26:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09648; Fri, 8 Apr 2005 16:26:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK0CQ-0004eB-Bm; Fri, 08 Apr 2005 16:35:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK03V-00020j-Fh; Fri, 08 Apr 2005 16:26:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK03G-0001jh-PB for ltru@megatron.ietf.org; Fri, 08 Apr 2005 16:26:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09575 for ; Fri, 8 Apr 2005 16:26:00 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK0C4-0004cx-SF for ltru@ietf.org; Fri, 08 Apr 2005 16:35:10 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 13:25:51 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Apr 2005 13:25:50 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF0337@irvmbxw01.quest.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Question about some draft text. Thread-Index: AcU8eSPVYAcsYHFMSwWh4BeU9KwSAg== From: "Addison Phillips" To: X-OriginalArrivalTime: 08 Apr 2005 20:25:51.0160 (UTC) FILETIME=[281C9B80:01C53C79] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ltru] Question about some draft text. X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1434390562==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 --===============1434390562== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gdGhlIGRyYWZ0IHRoZXJlIGlzIG9uZSBzZW50ZW5jZSB0aGF0IGlzIGJvdGhlcmluZyBtZS4g SSB0aGluayBKRkMgcGFydGlhbGx5IHBvaW50IHRoaXMgb3V0Og0KDQo8dD5VcGRhdGVzIG9mIHJl Z2lzdHJhdGlvbnMgZm9sbG93IHRoZSBzYW1lIHByb2NlZHVyZSBhcyANCnJlZ2lzdHJhdGlvbnMu IFRoZSBzdWJ0YWcgcmV2aWV3ZXIgZGVjaWRlcyB3aGV0aGVyIHRvIA0KYWxsb3cgYSBuZXcgcmVn aXN0cmFudCB0byB1cGRhdGUgYSByZWdpc3RyYXRpb24gbWFkZSANCmJ5IHNvbWVvbmUgZWxzZTsg bm9ybWFsbHkgb2JqZWN0aW9ucyBieSB0aGUgb3JpZ2luYWwgDQpyZWdpc3RyYW50IHdvdWxkIGNh cnJ5IGV4dHJhIHdlaWdodCBpbiBzdWNoIGEgZGVjaXNpb24uPC90Pg0KDQpUaGlzIGlzIGEgaG9s ZG92ZXIgZnJvbSBSRkMgMzA2Ni4gSXQgc3VnZ2VzdHMgdGhhdCB1cGRhdGUgcmVxdWVzdHMgYXJl IG5vdCBzdWJqZWN0IHRvIHRoZSBzYW1lIHJldmlldy4gSSB3b3VsZCBsaWtlIHRvIGNoYW5nZSB0 aGlzIHRvIHNheToNCg0KPHQ+VXBkYXRlcyBvciBjaGFuZ2VzIHRvIGV4aXN0aW5nIHJlY29yZHMs IGluY2x1ZGluZw0KcHJldmlvdXMgcmVnaXN0cmF0aW9ucywgZm9sbG93IHRoZSBzYW1lIHByb2Nl ZHVyZQ0KYXMgbmV3IHJlZ2lzdHJhdGlvbnMuIFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIN CmRlY2lkZXMgd2hldGhlciB0aGVyZSBpcyBjb25zZW5zdXMgdG8gdXBkYXRlIHRoZQ0KcmVnaXN0 cmF0aW9uIGZvbGxvd2luZyB0aGUgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZDsNCm5vcm1hbGx5IG9i amVjdGlvbnMgYnkgdGhlIG9yaWdpbmFsIHJlZ2lzdHJhbnQgd2lsbA0KY2FycnkgZXh0cmEgd2Vp Z2h0IGluIGZvcm1pbmcgc3VjaCBhIGNvbnNlbnN1cy48L3Q+DQoNCg0KT2JqZWN0aW9ucz8NCg0K DQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0 LCBRdWVzdCBTb2Z0d2FyZQ0KaHR0cDovL3d3dy5xdWVzdC5jb20NCg0KQ2hhaXIsIFczQyBJbnRl cm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCmh0dHA6Ly93d3cudzMub3JnL0lu dGVybmF0aW9uYWwNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0 IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCg0K --===============1434390562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1434390562==-- From ltru-bounces@ietf.org Fri Apr 8 16:37:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10608; Fri, 8 Apr 2005 16:37:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK0ND-0005F0-Bw; Fri, 08 Apr 2005 16:46:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK0DT-0004Ve-8I; Fri, 08 Apr 2005 16:36:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK0DO-0004VU-7L for ltru@megatron.ietf.org; Fri, 08 Apr 2005 16:36:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10567 for ; Fri, 8 Apr 2005 16:36:28 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK0MC-0005DU-Nu for ltru@ietf.org; Fri, 08 Apr 2005 16:45:38 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 13:36:19 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Apr 2005 13:36:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AEF0348@irvmbxw01.quest.com> Thread-Topic: Format for extension registry Thread-Index: AcU8epoQUmdPz5JETk+xr1ecdevjHg== From: "Addison Phillips" To: X-OriginalArrivalTime: 08 Apr 2005 20:36:19.0687 (UTC) FILETIME=[9EBE3770:01C53C7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ltru] Format for extension registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1342845235==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 --===============1342845235== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgd2FzIHBvaW50ZWQgb3V0IHRoYXQgdGhlcmUgaXMgbm8gZGVmaW5pdGlvbiBvZiB0aGUgZXh0 ZW5zaW9ucyByZWdpc3RyeS4gQ3VycmVudGx5IHRoZSBkcmFmdCBzYXlzOg0KDQo8dD5JQU5BIHdp bGwgbWFpbnRhaW4gYSByZWdpc3RyeSBvZiBhbGxvY2F0ZWQgc2luZ2xlLWxldHRlciBzdWJ0YWdz LiANCiAgICBUaGlzIHJlZ2lzdHJ5IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgaW5mb3JtYXRpb246 DQogICAgbGV0dGVyIGlkZW50aWZpZXI7IG5hbWU7IHB1cnBvc2U7IFJGQyBkZWZpbmluZyB0aGUg c3VidGFnIG5hbWVzcGFjZSBhbmQgDQogICAgaXRzIHVzZTsNCiAgICBhbmQgdGhlIG5hbWUsIFVS TCwgYW5kIGVtYWlsIGFkZHJlc3Mgb2YgdGhlIG1haW50YWluaW5nIGF1dGhvcml0eS48L3Q+DQoN Ckkgd291bGQgbGlrZSB0byBtb2RpZnkgdGhpcyB0byBzYXk6DQoNCjx0PklBTkEgd2lsbCBtYWlu dGFpbiBhIHJlZ2lzdHJ5IG9mIGFsbG9jYXRlZCBzaW5nbGUtbGV0dGVyIChzaW5nbGV0b24pIHN1 YnRhZ3MuIFRoaXMgcmVnaXN0cnkgd2lsbCB1c2UgdGhlIHJlY29yZC1qYXIgZm9ybWF0IGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDMuMSwgdXNpbmcgdGhlIEFCTkYgIChSRkMyMjM0YmlzKSBpbiB0aGF0 IHNlY3Rpb24uIFVwb24gcHVibGljYXRpb24gb2YgYW4gZXh0ZW5zaW9uIGFzIGFuIFJGQywgdGhl IG1haW50YWluaW5nIGF1dGhvcml0eSBkZWZpbmVkIGluIHRoZSBSRkMgbXVzdCBmb3J3YXJkIHRv IGlhbmFAaWFuYS5vcmcgdGhlIHJlZ2lzdHJhdGlvbiBmb3JtIGRlZmluZWQgaW4gdGhpcyBzZWN0 aW9uIGFuZCByZXF1aXJlZCBpbiB0aGUgZXh0ZW5zaW9uJ3MgUkZDIGZvciBpbmNsdXNpb24gaW50 byB0aGUgcmVnaXN0cnkuIDwvdD4NCg0KV2Ugd291bGQgdGhlbiBkZWZpbmUgdGhlIHJlY29yZHMg YXMgZm9sbG93czoNCg0KJSUNCklkZW50aWZpZXI6IChsZXR0ZXIgaWRlbnRpZnlpbmcgdGhlIGV4 dGVuc2lvbikNCkRlc2NyaXB0aW9uOiAobmFtZSBhbmQgcHVycG9zZSBvZiB0aGUgZXh0ZW5zaW9u KQ0KQ29tbWVudHM6IChjb21tZW50cykNCkFkZGVkOiAoZGF0ZSBpbiBJU08gODYwMSBmdWxsLWRh dGUgZm9ybWF0IHdoZW4gdGhpcyByZWNvcmQgYWRkZWQpDQpSRkM6IChSRkMgZGVmaW5pbmcgdGhl IGV4dGVuc2lvbikNCkF1dGhvcml0eTogKG5hbWUgb2YgdGhlIG1haW50YWluaW5nIGF1dGhvcml0 eSkNCkVtYWlsOiAoZW1haWwgb2YgdGhlIG1haW50YWluaW5nIGF1dGhvcml0eSkNClVSTDogKFVS TCBvZiB0aGUgZXh0ZW5zaW9uKQ0KJSUNCg0KDQpDb21tZW50cy9zdWdnZXN0aW9ucz8NCg0KQWRk aXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVl c3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkNoYWlyLCBXM0MgSW50ZXJuYXRp b25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRwOi8vd3d3LnczLm9yZy9JbnRlcm5h dGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBh biBhcmNoaXRlY3R1cmUuIA0KDQoNCg== --===============1342845235== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1342845235==-- From ltru-bounces@ietf.org Fri Apr 8 17:59:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15201; Fri, 8 Apr 2005 17:59:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK1ep-0000TM-Mh; Fri, 08 Apr 2005 18:08:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK1UH-0005TG-Pm; Fri, 08 Apr 2005 17:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK1U8-0005Sw-Dz for ltru@megatron.ietf.org; Fri, 08 Apr 2005 17:57:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15146 for ; Fri, 8 Apr 2005 17:57:50 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK1cx-0000Rd-Hv for ltru@ietf.org; Fri, 08 Apr 2005 18:07:00 -0400 Received: from lns-p19-1-idf-82-251-73-220.adsl.proxad.net ([82.251.73.220] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DK1U5-0002NH-9c; Fri, 08 Apr 2005 14:57:50 -0700 Message-Id: <6.1.2.0.2.20050408232618.02e9b5a0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Apr 2005 23:32:45 +0200 To: "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Format for extension registry In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AEF0348@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AEF0348@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Addison, everything you propose in term of your format is fine. You know what you want. Just stop claiming your solution is universal in wanting your document to become the BCP 047. Explain how your format will be used by applications, to understand the load on the IANA. We will stop being harassed by your proposition and develop our own system quietly for what your proposition does not address and we work on... There is room for everyone and for innovation. jfc On 22:36 08/04/2005, Addison Phillips said: >content-class: urn:content-classes:message >Content-Type: text/plain; > charset="utf-8" > >It was pointed out that there is no definition of the extensions registry. >Currently the draft says: > >IANA will maintain a registry of allocated single-letter subtags. > This registry contains the following information: > letter identifier; name; purpose; RFC defining the subtag namespace and > its use; > and the name, URL, and email address of the maintaining authority. > >I would like to modify this to say: > >IANA will maintain a registry of allocated single-letter (singleton) >subtags. This registry will use the record-jar format described in Section >3.1, using the ABNF (RFC2234bis) in that section. Upon publication of an >extension as an RFC, the maintaining authority defined in the RFC must >forward to iana@iana.org the registration form defined in this section and >required in the extension's RFC for inclusion into the registry. > >We would then define the records as follows: > >%% >Identifier: (letter identifying the extension) >Description: (name and purpose of the extension) >Comments: (comments) >Added: (date in ISO 8601 full-date format when this record added) >RFC: (RFC defining the extension) >Authority: (name of the maintaining authority) >Email: (email of the maintaining authority) >URL: (URL of the extension) >%% > > >Comments/suggestions? > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >http://www.quest.com > >Chair, W3C Internationalization Core Working Group >http://www.w3.org/International > >Internationalization is not a feature. >It is an architecture. > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 18:00:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15258; Fri, 8 Apr 2005 18:00:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK1fE-0000Tj-EE; Fri, 08 Apr 2005 18:09:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK1Uy-0005VC-0m; Fri, 08 Apr 2005 17:58:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK1Uv-0005V5-Ml for ltru@megatron.ietf.org; Fri, 08 Apr 2005 17:58:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15167 for ; Fri, 8 Apr 2005 17:58:38 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK1dl-0000SJ-40 for ltru@ietf.org; Fri, 08 Apr 2005 18:07:49 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j38LwMjQ009221; Fri, 8 Apr 2005 14:58:28 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AFWG6>; Fri, 8 Apr 2005 14:58:22 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Randy Presuhn , LTRU Working Group Subject: RE: [Ltru] Re: [psg.com #875] should initial registry contents be made into an internet-draft? Date: Fri, 8 Apr 2005 14:58:21 -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: 200d029292fbb60d25b263122ced50fc X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Hi, The point of the I-D (but not necessarily an RFC) for the registry content is to get wider review of the registry content by the IETF and computing community. The ONLY time that the registry needs to / should be published as an I-D is simultaneous with the Last Call of RFC3066bis. But Doug could perfectly well publish a dated (in the filename) copy of the registry content that was identical to the reviewed I-D (and so claimed in the I-D). That's essentially what IANA did with IANA Charset MIB (RFC 3808, one SNMP textual convention) when the RFC came out - took the clean registry (and the tool that machine-generates it from an updated plaintext IANA Charset registry) from the named archive. Because of I-D format rules, publishing the registry in an I-D also makes certain that there are no: (a) overlength lines; (b) non-ASCII characters (except as XML character references); (c) tabs, or other extraneous layout characters. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Friday, April 08, 2005 3:25 PM > To: Randy Presuhn; LTRU Working Group > Subject: RE: [Ltru] Re: [psg.com #875] should initial > registry contents > bemade into an internet-draft? > > > > As a contributor... > > This approach misses the whole point of bothering to put the initial > > content into an i-d, and is equivalent to the registry-00 > proposal. The > > concern is about ensuring the integrity of whatever IANA is given a > > pointer to, and that that initial content that is there when IANA > > retrieves > > it is what was approved by the WG. > > Well, yes, that's what I'm saying. Putting page breaks into > the document to make it an I-D just to have IANA pluck them > out again seems like a waste of time. > > I'm just bemused by the notion that somehow a document hosted > at a particular address (especially if it is handled like an > I-D) is somehow inferior to a document that *is* an I-D but > which IANA must muck around with to make a "clean" registry. > > But since I don't make the registry, you can count me as "not > caring". Close the issue under whatever the consensus is. I > *only* care about text in the -01 draft. The content of the > registry is entirely driven by that anyway. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Randy Presuhn > > Sent: vendredi 8 avril 2005 12:19 > > To: LTRU Working Group > > Subject: Re: [Ltru] Re: [psg.com #875] should initial > registry contents > > bemade into an internet-draft? > > > > Hi - > > > > > From: "Addison Phillips" > > > To: "Doug Ewell" ; "LTRU Working Group" > > > > > Sent: Friday, April 08, 2005 9:34 AM > > > Subject: RE: [Ltru] Re: [psg.com #875] should initial > registry contents > > bemadeinto an internet-draft? > > > > (re-formatted so I can read it) > > > > > I still fail to see how an I-D does anything useful. > > > Putting the draft registry under some form of version control > > > and making it available on the IETF website under > "internet-drafts" > > > strikes me as sufficient. > > > The I-D can be (copyrights and other legal matters > excluded) one line > > long, > > > containing the URI of the registry itself in a > non-rubbished format > > suitable for actual publication. > > > > > > Here's what it could say: > > > > > > "The initial contents of the Language Subtag Registry > defined by RFC > > 3066bis > > > SHALL be the file at this location, subject to the > provisions in Section > > 3.6 of RFC > > > 3066bis: > > are>" > > ... > > > > As a contributor... > > This approach misses the whole point of bothering to put the initial > > content into an i-d, and is equivalent to the registry-00 > proposal. The > > concern is about ensuring the integrity of whatever IANA is given a > > pointer to, and that that initial content that is there when IANA > > retrieves > > it is what was approved by the WG. > > > > Randy > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 18:01:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15338; Fri, 8 Apr 2005 18:01:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK1gQ-0000aW-IC; Fri, 08 Apr 2005 18:10:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK1UI-0005TT-Mb; Fri, 08 Apr 2005 17:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK1U8-0005Sv-Cp for ltru@megatron.ietf.org; Fri, 08 Apr 2005 17:57:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15144 for ; Fri, 8 Apr 2005 17:57:50 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK1cx-0000Rc-Hq for ltru@ietf.org; Fri, 08 Apr 2005 18:07:00 -0400 Received: from lns-p19-1-idf-82-251-73-220.adsl.proxad.net ([82.251.73.220] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DK1U3-0002NH-Us; Fri, 08 Apr 2005 14:57:48 -0700 Message-Id: <6.1.2.0.2.20050408231014.03976eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Apr 2005 23:10:50 +0200 To: "Addison Phillips" , "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: draft review In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AEF01D4@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AEF01D4@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 At 18:29 08/04/2005, Addison Phillips wrote: >Content-class: urn:content-classes:message >Content-Type: text/plain; > charset="utf-8" > > > Please point out a passage in RFC 1958 that says that if one protocol > > uses a character sequence such as "--", that no other protocol may use > > that same two-character sequence, no matter how unrelated the uses are. > >Furthermore, as pointed out previously, language tags do not use the >sequence "--" anyway. Draft-00 uses it in the canonical field to indicate >a deprecated code (not an actual value to assign). > >In the current draft of Draft-01, this sequence is entirely removed, >replaced by the Deprecated field (which contains a date). So this whole >thread may be moot. Perfect. Thank you. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 18:07:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16063; Fri, 8 Apr 2005 18:07:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK1mP-0000sq-9r; Fri, 08 Apr 2005 18:16:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK1ci-0006n2-IG; Fri, 08 Apr 2005 18:06:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK1cg-0006mx-Vd for ltru@megatron.ietf.org; Fri, 08 Apr 2005 18:06:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15939 for ; Fri, 8 Apr 2005 18:06:40 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK1lX-0000rg-67 for ltru@ietf.org; Fri, 08 Apr 2005 18:15:51 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j38M6WE9010058; Fri, 8 Apr 2005 15:06:32 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AFW25>; Fri, 8 Apr 2005 15:06:33 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , ltru@ietf.org Subject: RE: [Ltru] Question about some draft text. Date: Fri, 8 Apr 2005 15:06:25 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hi, No objections. Simpler process is better. Cheers, - Ira PS - Asking for 'Objections?' invites ambiguous responses (since it asks for the negatives). Asking for 'Agreement?' makes a more readable email thread. 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: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Friday, April 08, 2005 4:26 PM > To: ltru@ietf.org > Subject: [Ltru] Question about some draft text. > > > In the draft there is one sentence that is bothering me. I > think JFC partially point this out: > > Updates of registrations follow the same procedure as > registrations. The subtag reviewer decides whether to > allow a new registrant to update a registration made > by someone else; normally objections by the original > registrant would carry extra weight in such a decision. > > This is a holdover from RFC 3066. It suggests that update > requests are not subject to the same review. I would like to > change this to say: > > Updates or changes to existing records, including > previous registrations, follow the same procedure > as new registrations. The Language Subtag Reviewer > decides whether there is consensus to update the > registration following the two week review period; > normally objections by the original registrant will > carry extra weight in forming such a consensus. > > > Objections? > > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > http://www.quest.com > > Chair, W3C Internationalization Core Working Group > http://www.w3.org/International > > Internationalization is not a feature. > It is an architecture. > > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 18:48:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19277; Fri, 8 Apr 2005 18:48:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK2Pp-0002d3-33; Fri, 08 Apr 2005 18:57:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK2G3-0007oY-98; Fri, 08 Apr 2005 18:47:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK10a-0006yl-Kh for ltru@megatron.ietf.org; Fri, 08 Apr 2005 17:27:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13716 for ; Fri, 8 Apr 2005 17:27:18 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK19P-0007aD-J2 for ltru@ietf.org; Fri, 08 Apr 2005 17:36:28 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMUQYEM2PS00005R@mauve.mrochek.com> for ltru@ietf.org; Fri, 08 Apr 2005 14:27:15 -0700 (PDT) Date: Fri, 08 Apr 2005 14:24:37 -0700 (PDT) In-reply-to: "Your message dated Thu, 07 Apr 2005 20:57:18 -0700" <634978A7DF025A40BFEF33EB191E13BC0AEF0029@irvmbxw01.quest.com> Message-id: <01LMURUTCWNK00005R@mauve.mrochek.com> References: <634978A7DF025A40BFEF33EB191E13BC0AEF0029@irvmbxw01.quest.com> Subject: RE: [Ltru] Using RT To: Addison Phillips X-Spam-Score: 0.3 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Fri, 08 Apr 2005 18:47:19 -0400 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7BIT > I'm getting three copies of every message to this alleged tool and find most > of the issues currently flowing through my inbox redundant on top of that. This > is emphatically annoying. "Alleged" is spot on. We're drowning. Let's either fix this or stop using the thing. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 19:06:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20092; Fri, 8 Apr 2005 19:06:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK2hV-0003OD-QV; Fri, 08 Apr 2005 19:15:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK2Y4-0003B0-Hp; Fri, 08 Apr 2005 19:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK2Y2-0003Av-Qk for ltru@megatron.ietf.org; Fri, 08 Apr 2005 19:05:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20066 for ; Fri, 8 Apr 2005 19:05:55 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK2gs-0003IK-8C for ltru@ietf.org; Fri, 08 Apr 2005 19:15:07 -0400 Received: from h-68-165-6-58.snvacaid.dynamic.covad.net ([68.165.6.58] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DK2Xy-0002CX-00 for ltru@ietf.org; Fri, 08 Apr 2005 16:05:55 -0700 Message-ID: <00a201c53c8f$b55d2ee0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 8 Apr 2005 16:07:16 -0700 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.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Hi - I believe this may be of interest to many members of the ltru WG. Randy > From: > To: > Sent: Friday, April 08, 2005 7:25 AM > Subject: I-D ACTION:draft-lilly-content-script-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Indicating and Negotiating Text Script > Author(s) : B. Lilly > Filename : draft-lilly-content-script-01.txt > Pages : 14 > Date : 2005-4-7 > > Some written text in some languages can be represented in multiple > scripts, or writing forms. This memo proposes mechanisms for > identification and negotiation of script for written text. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-lilly-content-script-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-lilly-content-script-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > begin 666 ATT00156.dat M0V]N=&5N="U4>7!E.B!T97AT+W!L86EN#0I#;VYT96YT+4E$.B \,C P-2TT M+3@Q,#4X,#,N22U$0&EE=&8N;W)G/@T*#0I%3D-/1$E.1R!M:6UE#0I&24Q% M("]I;G1E; Fri, 8 Apr 2005 19:19:23 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK2ts-0003sy-Tw for ltru@ietf.org; Fri, 08 Apr 2005 19:28:34 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMUQYEM2PS00005R@mauve.mrochek.com> for ltru@ietf.org; Fri, 08 Apr 2005 16:19:16 -0700 (PDT) Date: Fri, 08 Apr 2005 16:17:45 -0700 (PDT) In-reply-to: "Your message dated Fri, 08 Apr 2005 08:16:17 -0400" <20050408121617.GJ14141@skunk.reutershealth.com> Message-id: <01LMUVROSRA200005R@mauve.mrochek.com> References: <20050408000100.CBWK2132.mta5.adelphia.net@megatron.ietf.org> <00d601c53c0a$46f184e0$030aa8c0@DEWELL> <20050408121617.GJ14141@skunk.reutershealth.com> Subject: Re: [Ltru] Re: registry should copy non-English fields from ISO documents To: John Cowan X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Fri, 08 Apr 2005 19:19:47 -0400 Cc: Doug Ewell , ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7BIT > Doug Ewell scripsit: > > >> Bruce wanted the French names in the draft-10 last call, IIRC > > >> nobody else wanted this. > > > > > > Uncorrect. Serveral wanted it. I am one. > > > > And Bruce Lilly wanted it. That makes two. Anyone else? > I favor including the French data from ISO as well. > > > For two main reasons: > > > - consistency with the concerned ISO document > > > - same reason as ISO: crossculture validation is a warranty against > > > monocultural dominance. > I agree with these reasons. As a data point, I believe Peter Constable > said in ietf-languages that the French data was helpful in determining > exactly which language was meant in certain cases by a specific code. I agree with these reasons as well. Is there a downside here I'm not seeing? We're only talking about copying existing data, right? Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 19:23:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21140; Fri, 8 Apr 2005 19:23:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK2xl-00042x-PM; Fri, 08 Apr 2005 19:32:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK2nz-00068C-KM; Fri, 08 Apr 2005 19:22:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK2nx-000681-SY for ltru@megatron.ietf.org; Fri, 08 Apr 2005 19:22:26 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21012 for ; Fri, 8 Apr 2005 19:22:22 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DK2l3-0006aq-P1 for ltru@lists.ietf.org; Sat, 09 Apr 2005 01:19:25 +0200 Received: from du-001-228.access.de.clara.net ([212.82.227.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 01:19:25 +0200 Received: from nobody by du-001-228.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 01:19:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 09 Apr 2005 01:18:46 +0200 Organization: Lines: 33 Message-ID: <42571156.6A78@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AEF01B4@irvmbxw01.quest.com> <20050408161107.GK10046@skunk.reutershealth.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: du-001-228.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: remove region subtag 200 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit John Cowan wrote: > So far, the ISO authorities have stuck to the _de facto_ rule > "Don't reuse codes", with exactly one exception There's no such rule, it wouldn't work, and CS is not the only case where they reused codes: SK Sikkim vs. Slovakia, GE Gilber and Ellice Is. vs. Georgia come to mind. > We can and should introduce an exactly compensating exception First of all we MUST acknowledge that our concept of alpha-2 country codes was completely wrong. Until we haven't done this we end up with the bogus "forever canonical" rules, and the abomination to hide the canonical value in a "comment", where implementations won't find it. If these details are unnderstood we can check the fixed rules against the problems of splits and unions. At the moment the rules just break down and lose some former regions. Only if all this is fixed we can consider to add an exception for 200, because this split between date A and B is a special case. But as long as the general rules are broken don't even think about exceptions from broken rules. Bye, Frank -- Subject tags considerd inefficient at best _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 19:40:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22045; Fri, 8 Apr 2005 19:40:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3Ec-0004pi-MV; Fri, 08 Apr 2005 19:49:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK356-0002Hs-MP; Fri, 08 Apr 2005 19:40:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK350-0002Gx-Co for ltru@megatron.ietf.org; Fri, 08 Apr 2005 19:40:02 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22013 for ; Fri, 8 Apr 2005 19:39:59 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DK328-0007ua-4g for ltru@lists.ietf.org; Sat, 09 Apr 2005 01:37:04 +0200 Received: from du-001-228.access.de.clara.net ([212.82.227.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 01:37:04 +0200 Received: from nobody by du-001-228.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 01:37:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 09 Apr 2005 01:38:51 +0200 Organization: Lines: 15 Message-ID: <4257160B.7C03@xyzzy.claranet.de> References: <20050407225542.FZQG5424.mta6.adelphia.net@megatron.ietf.org> <00cd01c53c07$53576040$030aa8c0@DEWELL> 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: du-001-228.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: draft review X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > If you doubt this, ask the chairs, or go over their heads to > the ADs. Jefsey has already congratulated Brian Carpeter on his ASCII artwork with consensus / rough consensus / wrong question in ietf.general. Unrelated but maybe interesting: draft-lilly-content-script-01 http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 19:59:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23259; Fri, 8 Apr 2005 19:59:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3XA-0005fi-Ko; Fri, 08 Apr 2005 20:09:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3Nq-0006hc-IW; Fri, 08 Apr 2005 19:59:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3Np-0006gR-7B for ltru@megatron.ietf.org; Fri, 08 Apr 2005 19:59:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23213 for ; Fri, 8 Apr 2005 19:59:26 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3Wf-0005ep-A1 for ltru@ietf.org; Fri, 08 Apr 2005 20:08:38 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 16:59:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Subject: RE: [Ltru] Re: registry should copy non-English fields from ISOdocuments MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Apr 2005 16:59:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3A37@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: registry should copy non-English fields from ISOdocuments Thread-Index: AcU8kebuSwBz4fzcTtSuPmVtWVkVMgAAhd8Q From: "Addison Phillips" To: , "John Cowan" X-OriginalArrivalTime: 08 Apr 2005 23:59:18.0174 (UTC) FILETIME=[F9AFDBE0:01C53C96] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: Doug Ewell , ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Two potential issues. 1. How do we distinguish the French names from the English ones? (Other = than by inspection) 2. Do we include (require?)(allow?) French, English, or both for future = registrations that are not sourced from one of the ISO standards (i.e. = variants) Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of ned.freed@mrochek.com > Sent: vendredi 8 avril 2005 16:18 > To: John Cowan > Cc: Doug Ewell; ltru@ietf.org > Subject: Re: [Ltru] Re: registry should copy non-English fields from > ISOdocuments >=20 > > Doug Ewell scripsit: >=20 > > > >> Bruce wanted the French names in the draft-10 last call, IIRC > > > >> nobody else wanted this. > > > > > > > > Uncorrect. Serveral wanted it. I am one. > > > > > > And Bruce Lilly wanted it. That makes two. Anyone else? >=20 > > I favor including the French data from ISO as well. >=20 > > > > For two main reasons: > > > > - consistency with the concerned ISO document > > > > - same reason as ISO: crossculture validation is a warranty = against > > > > monocultural dominance. >=20 > > I agree with these reasons. As a data point, I believe Peter = Constable > > said in ietf-languages that the French data was helpful in = determining > > exactly which language was meant in certain cases by a specific = code. >=20 > I agree with these reasons as well. >=20 > Is there a downside here I'm not seeing? We're only talking about > copying existing data, right? >=20 > Ned >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 20:16:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24344; Fri, 8 Apr 2005 20:16:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3mr-0006V8-Px; Fri, 08 Apr 2005 20:25:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3aU-00022p-Fs; Fri, 08 Apr 2005 20:12:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3aS-00022W-D1 for ltru@megatron.ietf.org; Fri, 08 Apr 2005 20:12:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24049 for ; Fri, 8 Apr 2005 20:12:29 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3jH-0006Jn-IM for ltru@ietf.org; Fri, 08 Apr 2005 20:21:41 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMUQYEM2PS00005R@mauve.mrochek.com> for ltru@ietf.org; Fri, 08 Apr 2005 17:12:26 -0700 (PDT) Date: Fri, 08 Apr 2005 17:10:41 -0700 (PDT) In-reply-to: "Your message dated Fri, 08 Apr 2005 16:59:17 -0700" <634978A7DF025A40BFEF33EB191E13BC0AFA3A37@irvmbxw01.quest.com> Message-id: <01LMUXMLL97E00005R@mauve.mrochek.com> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A37@irvmbxw01.quest.com> Subject: RE: [Ltru] Re: registry should copy non-English fields from ISOdocuments To: Addison Phillips X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7BIT Cc: Doug Ewell , ltru@ietf.org, ned.freed@mrochek.com X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7BIT > Two potential issues. > 1. How do we distinguish the French names from the English ones? (Other than > by inspection) I guess I don't understand. Aren't there two names for each? Or are there some blanks in the ISO data? > 2. Do we include (require?)(allow?) French, English, or both for future registrations that are not sourced from one of the ISO standards (i.e. variants) My preference would be to allow but not require. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 20:22:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24621; Fri, 8 Apr 2005 20:22:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK3tI-0006lm-KO; Fri, 08 Apr 2005 20:32:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3jV-0003uh-V6; Fri, 08 Apr 2005 20:21:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3jT-0003sl-Hv for ltru@megatron.ietf.org; Fri, 08 Apr 2005 20:21:51 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24555 for ; Fri, 8 Apr 2005 20:21:50 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DK3gh-0002eM-Rs for ltru@lists.ietf.org; Sat, 09 Apr 2005 02:18:59 +0200 Received: from du-001-228.access.de.clara.net ([212.82.227.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 02:18:59 +0200 Received: from nobody by du-001-228.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 02:18:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 09 Apr 2005 02:17:32 +0200 Organization: Lines: 29 Message-ID: <42571F1C.3124@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AEF031C@irvmbxw01.quest.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: du-001-228.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > great disadvantage to language tags and implementations that > require script codes. This "disadvantage" is impossible: 1 - At the moment no RfC 3066bis implementation exists. Proof: 3066bis isn't an RfC at the moment. 2 - Future implementations of the future RfC can get it right. Otherwise the RfC is so broken that it should be no RfC. 3 - The future RfC can say lang-extlang-region-script-variant. Implementations can match tags in any allowed way. Maybe using "Accept-Script" as in draft-lilly-content-script-01 It's good to break a bad idea completely, and the idea of RTL matching in four dimensions was never convincing. We'd need a math. expert, it's not trivial, John's 8-2-4-1 could work. > I disagree that my proposal accomplishes nothing substantive ACK, instead of specifying an optional default script for the language plus a rule that it SHOULD NOT be used explicitly, you have some languages for each script plus a rule that it SHOULD be used explicitly. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 20:34:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25152; Fri, 8 Apr 2005 20:34:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK44l-0007FE-CY; Fri, 08 Apr 2005 20:43:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3uq-0006qw-Uw; Fri, 08 Apr 2005 20:33:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3uf-0006qd-3K for ltru@megatron.ietf.org; Fri, 08 Apr 2005 20:33:26 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25117 for ; Fri, 8 Apr 2005 20:33:23 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DK3s0-0003TV-4c for ltru@lists.ietf.org; Sat, 09 Apr 2005 02:30:40 +0200 Received: from du-001-228.access.de.clara.net ([212.82.227.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 02:30:40 +0200 Received: from nobody by du-001-228.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 02:30:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 09 Apr 2005 02:32:16 +0200 Organization: Lines: 12 Message-ID: <42572290.5CF3@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AEF0348@irvmbxw01.quest.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: du-001-228.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Format for extension registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Addison Phillips wrote: > Comments/suggestions? Fine. Could you use it get rid of the "x" ABNF ? Initialize the singleton registry section with "x" (private use, defined in 3066is). And a production singleton = ALPHA would be nice. OTOH that could conflict with John's singleton sorting ideas. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 20:39:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25395; Fri, 8 Apr 2005 20:39:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK49r-0007TW-8R; Fri, 08 Apr 2005 20:49:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3ze-0007ff-AT; Fri, 08 Apr 2005 20:38:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK3zY-0007en-Sp for ltru@megatron.ietf.org; Fri, 08 Apr 2005 20:38:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25344 for ; Fri, 8 Apr 2005 20:38:27 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK48P-0007Mo-GD for ltru@ietf.org; Fri, 08 Apr 2005 20:47:38 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 8 Apr 2005 17:38:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: registry should copy non-English fields from ISOdocuments Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Apr 2005 17:38:15 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3A3D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: registry should copy non-English fields from ISOdocuments Thread-Index: AcU8mNHyVKXDvQupTt2iCs/F50063QAA4D7A From: "Addison Phillips" To: X-OriginalArrivalTime: 09 Apr 2005 00:38:15.0620 (UTC) FILETIME=[6AE9D040:01C53C9C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Doug Ewell , ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable I mean: how does one distinguish the French from the English the = Language Subtag Directory after we've imported the values? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] > Sent: vendredi 8 avril 2005 17:11 > To: Addison Phillips > Cc: ned.freed@mrochek.com; John Cowan; Doug Ewell; ltru@ietf.org > Subject: RE: [Ltru] Re: registry should copy non-English fields from > ISOdocuments >=20 > > Two potential issues. >=20 > > 1. How do we distinguish the French names from the English ones? = (Other > than > > by inspection) >=20 > I guess I don't understand. Aren't there two names for each? Or are = there > some > blanks in the ISO data? >=20 > > 2. Do we include (require?)(allow?) French, English, or both for = future > registrations that are not sourced from one of the ISO standards (i.e. > variants) >=20 > My preference would be to allow but not require. >=20 > Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 20:49:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25991; Fri, 8 Apr 2005 20:49:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4Iz-0007rJ-3A; Fri, 08 Apr 2005 20:58:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK48Y-0001Fe-EQ; Fri, 08 Apr 2005 20:47:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK48U-0001FP-6A for ltru@megatron.ietf.org; Fri, 08 Apr 2005 20:47:42 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25916 for ; Fri, 8 Apr 2005 20:47:40 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DK45e-0004Me-T3 for ltru@lists.ietf.org; Sat, 09 Apr 2005 02:44:46 +0200 Received: from du-001-228.access.de.clara.net ([212.82.227.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 02:44:46 +0200 Received: from nobody by du-001-228.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 02:44:46 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 09 Apr 2005 02:46:18 +0200 Organization: Lines: 7 Message-ID: <425725DA.7FED@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A3D@irvmbxw01.quest.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: du-001-228.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: registry should copy non-English fields from ISOdocuments X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Addison Phillips wrote: > how does one distinguish the French from the English the > Language Subtag Directory after we've imported the values? How about: English name semicolon French name ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 21:05:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27263; Fri, 8 Apr 2005 21:05:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4YF-00006d-TZ; Fri, 08 Apr 2005 21:14:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4Of-0005Sl-N2; Fri, 08 Apr 2005 21:04:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4OZ-0005S4-3m for ltru@megatron.ietf.org; Fri, 08 Apr 2005 21:04:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27227 for ; Fri, 8 Apr 2005 21:04:17 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4XP-00005j-Se for ltru@ietf.org; Fri, 08 Apr 2005 21:13:29 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMUQYEM2PS00005R@mauve.mrochek.com> for ltru@ietf.org; Fri, 08 Apr 2005 18:04:14 -0700 (PDT) Date: Fri, 08 Apr 2005 18:03:56 -0700 (PDT) In-reply-to: "Your message dated Sat, 09 Apr 2005 02:46:18 +0200" <425725DA.7FED@xyzzy.claranet.de> Message-id: <01LMUZFTMEE800005R@mauve.mrochek.com> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A3D@irvmbxw01.quest.com> <425725DA.7FED@xyzzy.claranet.de> Subject: Re: [Ltru] Re: registry should copy non-English fields from ISOdocuments To: Frank Ellermann X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7BIT Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7BIT > Addison Phillips wrote: > > how does one distinguish the French from the English the > > Language Subtag Directory after we've imported the values? > How about: English name semicolon French name ? Bye, Frank Yah, that was pretty much what I had in mind. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 21:26:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28646; Fri, 8 Apr 2005 21:26:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4sX-000116-Qp; Fri, 08 Apr 2005 21:35:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4jJ-0001h5-OV; Fri, 08 Apr 2005 21:25:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4jI-0001h0-Re for ltru@megatron.ietf.org; Fri, 08 Apr 2005 21:25:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28637 for ; Fri, 8 Apr 2005 21:25:43 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4sA-00010T-12 for ltru@ietf.org; Fri, 08 Apr 2005 21:34:55 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j391PYdR005910; Fri, 8 Apr 2005 21:25:34 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 8 Apr 2005 21:25:45 -0400 Date: Fri, 8 Apr 2005 21:25:44 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: registry should copy non-English fields from ISOdocuments Message-ID: <20050409012544.GA24173@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A3D@irvmbxw01.quest.com> <425725DA.7FED@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425725DA.7FED@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Frank Ellermann scripsit: > Addison Phillips wrote: > > > how does one distinguish the French from the English the > > Language Subtag Directory after we've imported the values? > > How about: English name semicolon French name ? Bye, Frank XML and its xml:lang attribute are looking better all the kind. Recursive, of course. :-) -- I don't know half of you half as well John Cowan as I should like, and I like less than half jcowan@reutershealth.com of you half as well as you deserve. http://www.ccil.org/~cowan --Bilbo http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 21:28:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28757; Fri, 8 Apr 2005 21:28:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4uy-00018A-2o; Fri, 08 Apr 2005 21:37:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4ka-000259-2M; Fri, 08 Apr 2005 21:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4kX-00024n-2d for ltru@megatron.ietf.org; Fri, 08 Apr 2005 21:27:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28734 for ; Fri, 8 Apr 2005 21:26:59 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4tP-00011d-8B for ltru@ietf.org; Fri, 08 Apr 2005 21:36:11 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j391QpMP005925; Fri, 8 Apr 2005 21:26:51 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 8 Apr 2005 21:26:53 -0400 Date: Fri, 8 Apr 2005 21:26:53 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Message-ID: <20050409012653.GB24173@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AEF031C@irvmbxw01.quest.com> <42571F1C.3124@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42571F1C.3124@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Frank Ellermann scripsit: > ACK, instead of specifying an optional default script for the > language plus a rule that it SHOULD NOT be used explicitly, you > have some languages for each script plus a rule that it SHOULD > be used explicitly. Yup. They're mathematically equivalent. -- Business before pleasure, if not too bloomering long before. --Nicholas van Rijn John Cowan http://www.ccil.org/~cowan http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 21:33:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28922; Fri, 8 Apr 2005 21:33:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4zl-0001MX-A5; Fri, 08 Apr 2005 21:42:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4nj-0002bK-Ox; Fri, 08 Apr 2005 21:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK4ni-0002bF-MF for ltru@megatron.ietf.org; Fri, 08 Apr 2005 21:30:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28823 for ; Fri, 8 Apr 2005 21:30:17 -0400 (EDT) Received: from pop-a065c05.pas.sa.earthlink.net ([207.217.121.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK4wZ-0001Ct-Rs for ltru@ietf.org; Fri, 08 Apr 2005 21:39:29 -0400 Received: from h-68-165-6-58.snvacaid.dynamic.covad.net ([68.165.6.58] helo=oemcomputer) by pop-a065c05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DK4nf-00051D-00 for ltru@ietf.org; Fri, 08 Apr 2005 18:30:15 -0700 Message-ID: <000a01c53ca3$decc6480$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A3D@irvmbxw01.quest.com><425725DA.7FED@xyzzy.claranet.de> <01LMUZFTMEE800005R@mauve.mrochek.com> Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fields fromISOdocuments Date: Fri, 8 Apr 2005 18:31:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi - > From: > To: "Frank Ellermann" > Cc: > Sent: Friday, April 08, 2005 6:03 PM > Subject: Re: [Ltru] Re: registry should copy non-English fields fromISOdocuments > > > Addison Phillips wrote: > > > > how does one distinguish the French from the English the > > > Language Subtag Directory after we've imported the values? > > > How about: English name semicolon French name ? Bye, Frank > > Yah, that was pretty much what I had in mind. ... How about making them separate fields? I don't like adding redundant data, but I'm thinking ahead to when folks decide that just having French and English is too blatantly euro-centric, and that it's time to add Chinese (tagged appropriately, of course) to better support that developer community. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 21:52:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29646; Fri, 8 Apr 2005 21:52:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK5I4-00027q-6y; Fri, 08 Apr 2005 22:01:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK56n-0006rj-Jb; Fri, 08 Apr 2005 21:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK56m-0006qH-67 for ltru@megatron.ietf.org; Fri, 08 Apr 2005 21:50:00 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29547 for ; Fri, 8 Apr 2005 21:49:58 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DK547-0008B0-Ql for ltru@lists.ietf.org; Sat, 09 Apr 2005 03:47:15 +0200 Received: from du-001-228.access.de.clara.net ([212.82.227.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 03:47:15 +0200 Received: from nobody by du-001-228.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 03:47:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 09 Apr 2005 03:48:50 +0200 Organization: Lines: 15 Message-ID: <42573482.2369@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AEF031C@irvmbxw01.quest.com> <42571F1C.3124@xyzzy.claranet.de> <20050409012653.GB24173@skunk.reutershealth.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: du-001-228.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Script prefixes (was: Compatibility with existing use (LDAP)) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit John Cowan wrote: >> instead of specifying an optional default script for the >> language plus a rule that it SHOULD NOT be used explicitly, >> you have some languages for each script plus a rule that it >> SHOULD be used explicitly. > Yup. They're mathematically equivalent. SHOULD NOT and SHOULD are fuzzy logic, I missed this lecture, but it MAY be good enough. ;-) For which language can we use it as an example in the text and in the registry ? Debbie said ess, but that's not yet registered. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 23:53:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07987; Fri, 8 Apr 2005 23:53:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK7Av-0007Ec-3f; Sat, 09 Apr 2005 00:02:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK70P-0007Bn-OU; Fri, 08 Apr 2005 23:51:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK6zV-0006od-4j for ltru@megatron.ietf.org; Fri, 08 Apr 2005 23:50:37 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07877 for ; Fri, 8 Apr 2005 23:50:34 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050409035005.BTST2192.mta9.adelphia.net@DEWELL> for ; Fri, 8 Apr 2005 23:50:05 -0400 Message-ID: <003601c53cb7$315d3180$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050409012753.RKSN2128.mta1.adelphia.net@megatron.ietf.org> Date: Fri, 8 Apr 2005 20:49:53 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > 1 - At the moment no RfC 3066bis implementation exists. Proof: > 3066bis isn't an RfC at the moment. I'd like to see the look on your face when I show you my fully compliant tag generator and validator for RFC 3066bis. (Cf. the last sentence of Appendix A.) Of course, I can't distribute it publicly as being compliant with anything, since 3066bis is, indeed, not an RFC at the moment. But I always smile when someone says, for example, that the mechanism for identifying subtags based on length and position "doesn't work," or that parsing or validating tags is too complicated to be practical. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 8 23:58:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08152; Fri, 8 Apr 2005 23:58:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK7Fp-0007SO-O0; Sat, 09 Apr 2005 00:07:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK76u-0008NM-Kb; Fri, 08 Apr 2005 23:58:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK76l-0008FS-Vk for ltru@megatron.ietf.org; Fri, 08 Apr 2005 23:58:08 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08140 for ; Fri, 8 Apr 2005 23:58:05 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050409035736.BXYN2192.mta9.adelphia.net@DEWELL> for ; Fri, 8 Apr 2005 23:57:36 -0400 Message-ID: <003b01c53cb8$417bab40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050409012753.RKSN2128.mta1.adelphia.net@megatron.ietf.org> Date: Fri, 8 Apr 2005 20:57:30 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: remove region subtag 200 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> We can and should introduce an exactly compensating exception > > First of all we MUST acknowledge that our concept of alpha-2 > country codes was completely wrong. Even if that were true, it's not relevant. Language tags that use alpha-2 country codes are ubiquitous. Turn the page. > Until we haven't done this we end up with the bogus "forever > canonical" rules, and the abomination to hide the canonical > value in a "comment", where implementations won't find it. The canonical value isn't hidden inside a comment, and never has been, even in the very first version of the draft that mentioned a registry, back in July 2004. It has always been a normative, machine-readable field. "Forever canonical" is the only way to go unless you believe everyone is going to update their applications and retag all their existing data every time an ISO code is changed. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 00:23:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09183; Sat, 9 Apr 2005 00:23:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK7e2-0008Rl-Ge; Sat, 09 Apr 2005 00:32:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK7Up-0004o1-W4; Sat, 09 Apr 2005 00:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK7Uo-0004nw-Bo for ltru@megatron.ietf.org; Sat, 09 Apr 2005 00:22:58 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09157 for ; Sat, 9 Apr 2005 00:22:55 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050409042224.SDLA7277.mta10.adelphia.net@DEWELL> for ; Sat, 9 Apr 2005 00:22:24 -0400 Message-ID: <004401c53cbb$b6ec0840$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050409012753.RKSN2128.mta1.adelphia.net@megatron.ietf.org> Date: Fri, 8 Apr 2005 21:22:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id AAA09157 Subject: [Ltru] Re: registry should copy non-English fields from ISOdocuments X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Frank Ellermann wrote: >> how does one distinguish the French from the English the >> Language Subtag Directory after we've imported the values? > > How about: English name semicolon French name ? There are twenty-one language subtags in the current registry with compound names, separated by semicolons: Catalan; Valencian Spanish; Castilian Kalaallisut; Greenlandic Limburgan; Limburger; Limburgish Low German; Low Saxon; German, Low; Saxon, Low etc. These names were pulled directly from ISO 639. Arbitrarily picking the first name from the list and throwing away the rest doesn't work; there is no way to know which of the multiple names is preferred for any given purpose or by different speakers. All the names are there for a reason. (OK, I think they went overboard with the "Low German" permutations.) So, clearly, we can't ALSO implement French names by writing: English; anglais French; fran=C3=A7ais German; allemand etc. If there is support for adding French descriptions, then I prefer two description fields: "English_Description" and "French_Description", or perhaps "English_Name" and "French_Name". But only TWO. Expanding this beyond English and French should not happen. The registry is not a general-purpose repository of locale data; there are other sources for that. The stated goal of retaining important information from the ISO standards can be met by adding French and leaving it at that. Trying to dig up the Kwanyama word for "Skolt Sami" is way out of scope for language tagging. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 00:30:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09452; Sat, 9 Apr 2005 00:30:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK7kp-0000K5-Mz; Sat, 09 Apr 2005 00:39:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK7a2-0006GG-8T; Sat, 09 Apr 2005 00:28:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK7Zt-0006CA-UX for ltru@megatron.ietf.org; Sat, 09 Apr 2005 00:28:13 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09401 for ; Sat, 9 Apr 2005 00:28:11 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050409042742.JBVH5402.mta11.adelphia.net@DEWELL> for ; Sat, 9 Apr 2005 00:27:42 -0400 Message-ID: <004701c53cbc$75fa8e00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A37@irvmbxw01.quest.com> <01LMUXMLL97E00005R@mauve.mrochek.com> Subject: Re: [Ltru] Re: registry should copy non-English fields from ISOdocuments Date: Fri, 8 Apr 2005 21:27:36 -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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Ned Freed wrote: >> 2. Do we include (require?)(allow?) French, English, or both for >> future registrations that are not sourced from one of the ISO >> standards (i.e. variants) > > My preference would be to allow but not require. Related question: Do we attempt to find French translations for the items in the initial registry that are not sourced from the ISO standards? This includes the UN macrogeographical codes, the variant subtags, and the grandfathered and redundant tags. (Some of the redundant tags have slightly different descriptions from the equivalent generative combinations.) I actually solicited French translations for these items from a couple of French speakers who had assisted me with translations before, but I never heard back from them. They are busy people. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 01:46:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18151; Sat, 9 Apr 2005 01:46:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK8wF-0004KI-Me; Sat, 09 Apr 2005 01:55:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK8lo-0005BI-Eq; Sat, 09 Apr 2005 01:44:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK8lj-0005B7-98 for ltru@megatron.ietf.org; Sat, 09 Apr 2005 01:44:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18063 for ; Sat, 9 Apr 2005 01:44:30 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK8uc-0004CU-CS for ltru@ietf.org; Sat, 09 Apr 2005 01:53:43 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j395iKmj006781; Sat, 9 Apr 2005 01:44:20 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 9 Apr 2005 01:44:19 -0400 Date: Sat, 9 Apr 2005 01:44:19 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: remove region subtag 200 Message-ID: <20050409054418.GE24173@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AEF01B4@irvmbxw01.quest.com> <20050408161107.GK10046@skunk.reutershealth.com> <42571156.6A78@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42571156.6A78@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Frank Ellermann scripsit: > SK Sikkim vs. Slovakia, GE Gilber and Ellice Is. vs. Georgia > come to mind. I believe that all of these precede Date A, and so are out of scope for us. -- Schlingt dreifach einen Kreis vom dies! John Cowan Schliesst euer Aug vor heiliger Schau, http://www.reutershealth.com Denn er genoss vom Honig-Tau, http://www.ccil.org/~cowan Und trank die Milch vom Paradies. -- Coleridge (tr. Politzer) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 01:53:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18396; Sat, 9 Apr 2005 01:53:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK93A-0004bI-Nx; Sat, 09 Apr 2005 02:02:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK8tU-0006bN-2a; Sat, 09 Apr 2005 01:52:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK8tR-0006bI-Lw for ltru@megatron.ietf.org; Sat, 09 Apr 2005 01:52:30 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18363 for ; Sat, 9 Apr 2005 01:52:28 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DK8qg-0006WQ-Ot for ltru@lists.ietf.org; Sat, 09 Apr 2005 07:49:38 +0200 Received: from du-001-228.access.de.clara.net ([212.82.227.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 07:49:38 +0200 Received: from nobody by du-001-228.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 07:49:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 09 Apr 2005 07:48:19 +0200 Organization: Lines: 48 Message-ID: <42576CA3.2654@xyzzy.claranet.de> References: <20050409012753.RKSN2128.mta1.adelphia.net@megatron.ietf.org> <003b01c53cb8$417bab40$030aa8c0@DEWELL> 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: du-001-228.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Comment: use VU for Vanuatu (was: remove region subtag 200) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > Even if that were true, it's not relevant. It's essential, because the rules as they are won't work. We've already seen that with the "old" proposal, it's now only acceptable because you've removed the pre-1988 codes. Without fixing the rules the same would be necessary in about 16 years (2005-1988=17, 1988-1974=14, 2005+16=2021). > The canonical value isn't hidden inside a comment The real canonical value in Addison's NHVU example is VU: | Subtag: NH | Deprecated: 2006-01-01 | Comment: use VU for Vanuatu > "Forever canonical" is the only way to go unless you > believe everyone is going to update their applications > and retag all their existing data every time an ISO > code is changed. That's not true, you keep all deprecated tags as they are. Nobody is forced to update his deprecated NH tags or NH software. But new software and new tags should use the new canonical value VU. The line... | Comment: use VU for Vanuatu ...is not good enough. If one side is old software and asks for NH, and the other side is new and has VU, then how is the new side supposed to detect this situation if it's only documented in a human readable comment ? Software normally cannot interpret a "use VU for Vanatu". Maybe we have only different ideas of "canonical" here, I really don't care about the name, as long as it's a machine readable pointer, how about: Alias: VU or See also: VU Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 02:09:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28477; Sat, 9 Apr 2005 02:09:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK9J0-0005M9-UC; Sat, 09 Apr 2005 02:18:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK99K-0001eT-D8; Sat, 09 Apr 2005 02:08:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DK99I-0001eO-OD for ltru@megatron.ietf.org; Sat, 09 Apr 2005 02:08:52 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27637 for ; Sat, 9 Apr 2005 02:08:51 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DK96c-0007QR-RF for ltru@lists.ietf.org; Sat, 09 Apr 2005 08:06:06 +0200 Received: from du-001-228.access.de.clara.net ([212.82.227.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 08:06:06 +0200 Received: from nobody by du-001-228.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Apr 2005 08:06:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 09 Apr 2005 08:07:44 +0200 Organization: Lines: 28 Message-ID: <42577130.6A08@xyzzy.claranet.de> References: <20050409012753.RKSN2128.mta1.adelphia.net@megatron.ietf.org> <003601c53cb7$315d3180$030aa8c0@DEWELL> 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: du-001-228.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > I'd like to see the look on your face when I show you my > fully compliant tag generator and validator for RFC 3066bis. My point was "no RfC at the moment". It's good that you have a prototype for the draft. If somebody asks why a completely new scheme is called "best common practice" we can answer that one practical implementation exists, and that's automagically the best, the worst, the only practice. Not exactly common. > 3066bis is, indeed, not an RFC at the moment. Yes, and if we would say language-region-script-variant, or if we allow any order after language, you probably need 5 minutes to update your prototype. A bit longer for the test suite, if you have edited it manually. > I always smile when someone says, for example, that the > mechanism for identifying subtags based on length and > position "doesn't work," Better, your prototype already supports what Ira and Ned were talking about (see subject). I can't judge how useful it would be to organize the subtags in another way. But all claims that this is impossible are wrong. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 03:07:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13679; Sat, 9 Apr 2005 03:07:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKACt-00084T-5b; Sat, 09 Apr 2005 03:16:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKA36-0007YP-W0; Sat, 09 Apr 2005 03:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKA33-0007Y5-8H for ltru@megatron.ietf.org; Sat, 09 Apr 2005 03:06:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13591 for ; Sat, 9 Apr 2005 03:06:27 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKABx-00083P-Rb for ltru@ietf.org; Sat, 09 Apr 2005 03:15:42 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3976JbY024560 for ; Sat, 9 Apr 2005 03:06:19 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3976IUo053808 for ; Sat, 9 Apr 2005 03:06:19 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3976Ivv026619 for ; Sat, 9 Apr 2005 03:06:18 -0400 Received: from markdavis (sig-9-48-114-190.mts.ibm.com [9.48.114.190]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with SMTP id j3976B2n026433; Sat, 9 Apr 2005 03:06:17 -0400 Message-ID: <077001c53cd2$9d1bca10$be733009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , References: <634978A7DF025A40BFEF33EB191E13BC0AEF0337@irvmbxw01.quest.com> Subject: Re: [Ltru] Question about some draft text. Date: Sat, 9 Apr 2005 00:02:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id j3976JbY024560 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable I agree. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: Sent: Friday, April 08, 2005 13:25 Subject: [Ltru] Question about some draft text. > In the draft there is one sentence that is bothering me. I think JFC partially point this out: > > Updates of registrations follow the same procedure as > registrations. The subtag reviewer decides whether to > allow a new registrant to update a registration made > by someone else; normally objections by the original > registrant would carry extra weight in such a decision. > > This is a holdover from RFC 3066. It suggests that update requests are = not subject to the same review. I would like to change this to say: > > Updates or changes to existing records, including > previous registrations, follow the same procedure > as new registrations. The Language Subtag Reviewer > decides whether there is consensus to update the > registration following the two week review period; > normally objections by the original registrant will > carry extra weight in forming such a consensus. > > > Objections? > > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > http://www.quest.com > > Chair, W3C Internationalization Core Working Group > http://www.w3.org/International > > Internationalization is not a feature. > It is an architecture. > > > -------------------------------------------------------------------------= --- ---- > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 08:06:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02070; Sat, 9 Apr 2005 08:06:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKEsT-00054f-4V; Sat, 09 Apr 2005 08:15:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKEiA-0001VW-U7; Sat, 09 Apr 2005 08:05:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKEi9-0001V8-Gm for ltru@megatron.ietf.org; Sat, 09 Apr 2005 08:05:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01942 for ; Sat, 9 Apr 2005 08:05:12 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKEr7-0004wR-9E for ltru@ietf.org; Sat, 09 Apr 2005 08:14:29 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Apr 2005 05:05:13 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sat, 9 Apr 2005 05:05:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Compatibility with existing use (LDAP) Date: Sat, 9 Apr 2005 05:04:35 -0700 Message-ID: Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU7zhFhcR5Zq5OCTAOdUxdzXQUbFABEpeSQ From: "Peter Constable" To: X-OriginalArrivalTime: 09 Apr 2005 12:05:04.0393 (UTC) FILETIME=[5D418F90:01C53CFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > For "expecting" read "one side is old and uses language or > language-region", and for "understanding" read "the old side > doesn't support any language-script constructs". Bye, Frank But in what sense would the old side not be supporting language-script constructs? These exist and conform to RFC 3066, so if the old side is incapable of supporting them, it is not a 3066-conformant implementation that we need to worry about.=20 Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 08:07:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02181; Sat, 9 Apr 2005 08:07:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKEt7-00055T-2f; Sat, 09 Apr 2005 08:16:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKEiJ-0001XV-9p; Sat, 09 Apr 2005 08:05:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKEiA-0001VN-K7 for ltru@megatron.ietf.org; Sat, 09 Apr 2005 08:05:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01948 for ; Sat, 9 Apr 2005 08:05:13 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKEr8-0004wQ-9k for ltru@ietf.org; Sat, 09 Apr 2005 08:14:30 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Sat, 9 Apr 2005 05:05:04 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sat, 9 Apr 2005 05:05:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Compatibility with existing use (LDAP) Date: Sat, 9 Apr 2005 05:04:36 -0700 Message-ID: Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU71eu49cGmo+baTfWbzvqJOE4M3gBFrJEw From: "Peter Constable" To: X-OriginalArrivalTime: 09 Apr 2005 12:05:17.0196 (UTC) FILETIME=[64E324C0:01C53CFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > The analogy is a stretch in and of itself, but it is also irrelevant since > the > basis of comparison is a strawman. We're not talking about incompliant > implementations here. >=20 > A compliant RFC 3066 implementation can (and I know for a fact has) been > written that handles these exceptions through an exception table, but > still > operates under the assumption that a two letter code in the second > position is > a country code but a two letter code elsewhere is not. >=20 > Like it or not, there are lots of application domains where script > information > is much less readily available than country information. As such, it is > entirely reasonable for these implementations to rely on extraction of > country > code information for the purposes of making finer grained matches. And > this > proposal breaks this. This whole argument is a strawman. The number of cases in which tags of the form ll-Ssss-CC will be used are limited. In the cases in which they will be used, the script distinction is almost certainly to be a more relevant distinction, so there's actually a greater likelihood that what will be used is a tag of the form ll-Ssss (indeed, likely one that is already registered under 3066), in which case your existing implementation will be just as incapable of extracting country information as if ll-Ssss-CC were used. Sure, in the latter case at least there was a *potential* for extracting such information, but I'd contend that the failure to realize that potential is less of a problem than all the existing implementations that would use left-prefix matching and give greater priority to minor regional distinctions than to script distinctions if a subtag sequence ll-CC-Ssss were required. It is a completely invalid to say that "backward compatibility" is being broken. That assumes that backward compatibility is defined in terms of certain expectations that have never been guaranteed: that if a second subtag exists, it would be a country ID. The appropriate way to present an argument on this issue is to say that some specific functionality would not exist, and then to evaluate in relation to realistic scenarios just how great a loss that would be. > Not true. The question is what was or was not standardized in the past. > The > rules for country code positioning were clearly written and clearly > normative. (Here we go again.) The rules that were clearly written state that *if* a tag has the form ll-CC or lll-CC, then CC must be from ISO 3166. It's a one-way implication; that's it! It does *not* say that an ISO 3166 country ID *must* occur as the second subtag. > The difference is that there was never any guarantee given that the > shortest-prefix-match approach would work well in all cases. And there was never any guarantee that country IDs would always occur as the second subtag. > You're effectively moving country codes to a new position in the string. > That's > breaking compatibility in my book. This is *not* a valid argument: - Tags like "en-US" will still be "en-US" with the country ID in the same position they were always in. - The only cases in which one could possibly contend that the country ID moved to a new position would be in comparing e.g. zh-TW with zh-Hant-TW, and in such cases the loss of functionality resulting from the country ID "moving" when the latter tag is used on one side of a match (remember: zh-TW will still be valid) is less of a loss than having implementations match for regional distinctions that pale in relation to script distinctions. - Again, neither RFC 1766 or RFC 3066 stated that a country ID could only occur as the second subtag, and it has always been invalid to assume that this must be the case. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 08:07:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02224; Sat, 9 Apr 2005 08:07:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKEtW-00055s-9y; Sat, 09 Apr 2005 08:16:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKEiA-0001VS-QA; Sat, 09 Apr 2005 08:05:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKEi9-0001V3-7K for ltru@megatron.ietf.org; Sat, 09 Apr 2005 08:05:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01939 for ; Sat, 9 Apr 2005 08:05:12 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKEr5-0004wQ-W4 for ltru@ietf.org; Sat, 09 Apr 2005 08:14:29 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Sat, 9 Apr 2005 05:05:02 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sat, 9 Apr 2005 05:05:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [semi-OT] ISO 639-3, record-jars, and Boontling Date: Sat, 9 Apr 2005 05:04:33 -0700 Message-ID: Thread-Topic: [Ltru] [semi-OT] ISO 639-3, record-jars, and Boontling Thread-Index: AcU7w9EhiseCS8tjSTmjX543HEEIPwBGzHyw From: "Peter Constable" To: X-OriginalArrivalTime: 09 Apr 2005 12:05:15.0179 (UTC) FILETIME=[63AF5FB0:01C53CFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > At 06:31 07/04/2005, Peter Constable wrote: > >Anyway, I'll send you what I have (off-list, since I haven't seen > >indication that this is of general interest). >=20 > Where did not got that indication? John is the only one that has been asking me for this. Please note that this information will soon be available from the Ethnologue site once the 15th edition is launched. (The book is published, btw. Can't wait to get my copy and check out all the new maps!) Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 08:08:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02274; Sat, 9 Apr 2005 08:08:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKEu3-00056E-RI; Sat, 09 Apr 2005 08:17:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKEiC-0001Vb-06; Sat, 09 Apr 2005 08:05:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKEi9-0001VG-Sc for ltru@megatron.ietf.org; Sat, 09 Apr 2005 08:05:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01945 for ; Sat, 9 Apr 2005 08:05:13 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKEr7-0004wQ-Kp for ltru@ietf.org; Sat, 09 Apr 2005 08:14:29 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Sat, 9 Apr 2005 05:05:02 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sat, 9 Apr 2005 05:05:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: registry should copy non-English fields fromISO documents Date: Sat, 9 Apr 2005 05:04:34 -0700 Message-ID: Thread-Topic: [Ltru] Re: registry should copy non-English fields fromISO documents Thread-Index: AcU7y50A7InePOaoSt2UwJOSOvmw7wBFDgVQ From: "Peter Constable" To: X-OriginalArrivalTime: 09 Apr 2005 12:05:03.0377 (UTC) FILETIME=[5CA68810:01C53CFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of JFC (Jefsey) Morfin > >Bruce wanted the French names in the draft-10 last call, IIRC > >nobody else wanted this. >=20 > Uncorrect. Serveral wanted it. I am one. You and Bruce do not constitute several. There were far more that *didn't* see the need for this. > For two main reasons: > - consistency with the concerned ISO document A complete non-issue. There's nothing inconsistent about including only a single name from the source standard. We are only inconsistent if we start listing *different* names than what is in the ISO standard. > - same reason as ISO: crossculture validation is a warranty against > monocultural dominance. Monocultural dominance is not what is at stake here. This is purely a matter of documentation to ensure that the item listed in the registry is the *same* item with the *same* semantic as the source standard. Additional languages do not establish that any more than a single language; they simply make the registry bigger. > No consensus will be reached without this. I believe if you are the only one on this list not in agreement, that we have a consensus. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 08:08:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02334; Sat, 9 Apr 2005 08:08:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKEuf-00056h-8v; Sat, 09 Apr 2005 08:18:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKEiP-0001Yl-0e; Sat, 09 Apr 2005 08:05:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKEiF-0001Wu-53 for ltru@megatron.ietf.org; Sat, 09 Apr 2005 08:05:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01970 for ; Sat, 9 Apr 2005 08:05:18 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKErB-0004wd-Tv for ltru@ietf.org; Sat, 09 Apr 2005 08:14:35 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Apr 2005 05:05:08 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sat, 9 Apr 2005 05:05:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Compatibility with existing use (LDAP) Date: Sat, 9 Apr 2005 05:04:39 -0700 Message-ID: Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU7iNpM5qff1aS7T4Ke0te+Yw8mvQBbAJ2A From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 09 Apr 2005 12:05:08.0799 (UTC) FILETIME=[5FE1DCF0:01C53CFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of McDonald, Ira > It's true that such tags were allowed to be registered by > RFC 3066. But there are literally millions of documents > currently language tagged on the Internet in the style of > 'language-REGION-whatever' and lots of naive software thinks > that's the only valid form of a language tag. Where it has made sense to tag documents using language-REGION-whatever, that will likely continue to be the case, and the RFC as proposed *will* be harmless wrt those millions of documents. It is only for specific cases, such as zh-TW that might be affected, but for which zh-TW has generally be problematic in the past and for which zh-Hant or zh-Hant-TW really solves problems. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 08:51:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04875; Sat, 9 Apr 2005 08:51:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKFa9-0007AI-Ka; Sat, 09 Apr 2005 09:01:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKFQJ-0003Ad-3I; Sat, 09 Apr 2005 08:50:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKFQH-0003AW-ME for ltru@megatron.ietf.org; Sat, 09 Apr 2005 08:50:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04836 for ; Sat, 9 Apr 2005 08:50:48 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKFZE-00073a-SG for ltru@ietf.org; Sat, 09 Apr 2005 09:00:06 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Sat, 9 Apr 2005 05:50:39 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sat, 9 Apr 2005 05:50:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Question about some draft text. Date: Sat, 9 Apr 2005 05:50:38 -0700 Message-ID: Thread-Topic: [Ltru] Question about some draft text. Thread-Index: AcU8eSPVYAcsYHFMSwWh4BeU9KwSAgAiX5Sw From: "Peter Constable" To: X-OriginalArrivalTime: 09 Apr 2005 12:50:55.0100 (UTC) FILETIME=[C4CE23C0:01C53D02] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > This is a holdover from RFC 3066. It suggests that update requests are not > subject to the same review. I would like to change this to say: >=20 > Updates or changes to existing records, including > previous registrations, follow the same procedure > as new registrations. The Language Subtag Reviewer > decides whether there is consensus to update the > registration following the two week review period; > normally objections by the original registrant will > carry extra weight in forming such a consensus. Seems OK to me. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 08:52:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02072; Sat, 9 Apr 2005 08:06:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKEsT-00054g-4f; Sat, 09 Apr 2005 08:15:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKEiJ-0001Xc-Kw; Sat, 09 Apr 2005 08:05:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKEiB-0001VZ-9f for ltru@megatron.ietf.org; Sat, 09 Apr 2005 08:05:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01953 for ; Sat, 9 Apr 2005 08:05:14 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKEr9-0004wQ-1O for ltru@ietf.org; Sat, 09 Apr 2005 08:14:31 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Sat, 9 Apr 2005 05:05:06 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sat, 9 Apr 2005 05:05:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Compatibility with existing use (LDAP) Date: Sat, 9 Apr 2005 05:04:38 -0700 Message-ID: Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU8AedKFVHA0lX3SZmoTbJAmirRwgAV4w/wACXRAwA= From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 09 Apr 2005 12:05:19.0590 (UTC) FILETIME=[66507060:01C53CFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > This is a suggestion of which languages would be most > appropriate to use a script with. Wouldn't it be more useful to state in which cases a script does not normally need to be specified for a given language? E.g. we'd be saying for en that it's not normally recommended to include "Latn", that it's not normally recommended to include "Cyrl" for ru, etc. This is not the same as listing a default script for languages: that was problematic due to a sense of expectation that some default should be identified for every language, which has many vagueries; and because they imply (as you state) a certain omniscience. For the alternative I'm suggesting here, we'd only be saying something for known cases in which it was applicable (which would require a lot less space to state than the other, btw), and we'd only stating it as a recommendation for general use without assuming what may be needed in all scenarios. Both may be able to accomplish the same result, but what I'm suggesting states the recommendation we want users to go away with directly, rather than them having to infer if by analyzing lists of what languages use what scripts (and understanding what's implied by how many scripts are associated with a given language). > We aren't. We are recommending that specific languages always be used with > a script subtag (and we don't define which one per-se) and are suggesting > that other languages not use them unless there is some need. The way you proposed doing this -- listing languages in the Recommended Prefix field for a script subtag -- does this in an indirect way that would not be transparent to users, IMO. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 08:53:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05039; Sat, 9 Apr 2005 08:53:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKFba-0007CI-V1; Sat, 09 Apr 2005 09:02:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKFSI-0003ZS-Cn; Sat, 09 Apr 2005 08:52:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKFSD-0003Xz-64 for ltru@megatron.ietf.org; Sat, 09 Apr 2005 08:52:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05022 for ; Sat, 9 Apr 2005 08:52:47 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKFb9-0007Bv-SB for ltru@ietf.org; Sat, 09 Apr 2005 09:02:05 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Apr 2005 05:52:54 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sat, 9 Apr 2005 05:52:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Format for extension registry Date: Sat, 9 Apr 2005 05:52:37 -0700 Message-ID: Thread-Topic: [Ltru] Format for extension registry Thread-Index: AcU8epoQUmdPz5JETk+xr1ecdevjHgAiEnPg From: "Peter Constable" To: X-OriginalArrivalTime: 09 Apr 2005 12:52:39.0005 (UTC) FILETIME=[02BCC8D0:01C53D03] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > We would then define the records as follows: >=20 > %% > Identifier: (letter identifying the extension) > Description: (name and purpose of the extension) > Comments: (comments) > Added: (date in ISO 8601 full-date format when this record added) > RFC: (RFC defining the extension) > Authority: (name of the maintaining authority) > Email: (email of the maintaining authority) > URL: (URL of the extension) > %% >=20 >=20 > Comments/suggestions? Sounds like a reasonable change to me. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 09:00:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05335; Sat, 9 Apr 2005 09:00:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKFiq-0007Z4-LT; Sat, 09 Apr 2005 09:10:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKFXX-00056H-Gp; Sat, 09 Apr 2005 08:58:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKFXV-00053k-0o for ltru@megatron.ietf.org; Sat, 09 Apr 2005 08:58:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05242 for ; Sat, 9 Apr 2005 08:58:15 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKFgT-0007RB-0j for ltru@ietf.org; Sat, 09 Apr 2005 09:07:33 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Apr 2005 05:58:07 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sat, 9 Apr 2005 05:58:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: registry should copy non-English fields fromISOdocuments Date: Sat, 9 Apr 2005 05:58:06 -0700 Message-ID: Thread-Topic: [Ltru] Re: registry should copy non-English fields fromISOdocuments Thread-Index: AcU8kebuSwBz4fzcTtSuPmVtWVkVMgAAhd8QABvVBEA= From: "Peter Constable" To: X-OriginalArrivalTime: 09 Apr 2005 12:58:07.0944 (UTC) FILETIME=[C6CCE480:01C53D03] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > Two potential issues. >=20 > 1. How do we distinguish the French names from the English ones? (Other > than by inspection) Let me add a third potential issue: When ISO 639-3 is initially published, and the RA has published the initial code table, there will not be French-language and English-language names for languages. There will simply be a "reference name" for each language. Over time, the RA may add documentation to list the names of languages in English, French and possibly other languages, but it won't happen from the outset. So... =20 > 2. Do we include (require?)(allow?) French, English, or both for future > registrations that are not sourced from one of the ISO standards (i.e. > variants) I suggest that you cannot *require* anything in this regard. Allowing is, of course, a different matter. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 11:27:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15403; Sat, 9 Apr 2005 11:27:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKI0i-0005wq-2u; Sat, 09 Apr 2005 11:36:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKHpl-0003sO-7y; Sat, 09 Apr 2005 11:25:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKHpj-0003or-Pb for ltru@megatron.ietf.org; Sat, 09 Apr 2005 11:25:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15274 for ; Sat, 9 Apr 2005 11:25:13 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKHyh-0005p8-VT for ltru@ietf.org; Sat, 09 Apr 2005 11:34:33 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMVSY94CM800005R@mauve.mrochek.com> for ltru@ietf.org; Sat, 09 Apr 2005 08:25:09 -0700 (PDT) Date: Sat, 09 Apr 2005 08:13:47 -0700 (PDT) In-reply-to: "Your message dated Sat, 09 Apr 2005 05:04:36 -0700" Message-id: <01LMVTI7HSQ000005R@mauve.mrochek.com> References: Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) To: Peter Constable X-Spam-Score: 0.3 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7BIT Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7BIT > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On > > The analogy is a stretch in and of itself, but it is also irrelevant > since > > the > > basis of comparison is a strawman. We're not talking about incompliant > > implementations here. > > > > A compliant RFC 3066 implementation can (and I know for a fact has) > been > > written that handles these exceptions through an exception table, but > > still > > operates under the assumption that a two letter code in the second > > position is > > a country code but a two letter code elsewhere is not. > > > > Like it or not, there are lots of application domains where script > > information > > is much less readily available than country information. As such, it > is > > entirely reasonable for these implementations to rely on extraction of > > country > > code information for the purposes of making finer grained matches. And > > this > > proposal breaks this. > This whole argument is a strawman. The number of cases in which tags of > the form ll-Ssss-CC will be used are limited. You have absolutely no way of knowing that that will be the case. As I pointed out in other mail, script information is something that often can be derived from other data. Country information is often something you have available as well. This makes it entirely possible that such tags will be created in an attempt to make things more informative. > In the cases in which they > will be used, the script distinction is almost certainly to be a more > relevant distinction, so there's actually a greater likelihood that what > will be used is a tag of the form ll-Ssss (indeed, likely one that is > already registered under 3066), in which case your existing > implementation will be just as incapable of extracting country > information as if ll-Ssss-CC were used. You have no way of knowing this either. And even if it is true in all cases, it is beside the point if you have country information but not script information. > Sure, in the latter case at > least there was a *potential* for extracting such information, but I'd > contend that the failure to realize that potential is less of a problem > than all the existing implementations that would use left-prefix > matching and give greater priority to minor regional distinctions than > to script distinctions if a subtag sequence ll-CC-Ssss were required. > It is a completely invalid to say that "backward compatibility" is being > broken. On the contrary, it is completely demonstrable that that is what is happening. > That assumes that backward compatibility is defined in terms of > certain expectations that have never been guaranteed: that if a second > subtag exists, it would be a country ID. This isn't the expectation. > The appropriate way to present > an argument on this issue is to say that some specific functionality > would not exist, and then to evaluate in relation to realistic scenarios > just how great a loss that would be. I disagree. It's a big world out there, and it is next to impossible to figure out what people have done or will do. The best we can do is to try and maintain compatibility. And if we have to break compatibility, an effort needs to be made to minimize the degree of breakage. > > Not true. The question is what was or was not standardized in the > past. > > The > > rules for country code positioning were clearly written and clearly > > normative. > (Here we go again.) The rules that were clearly written state that *if* > a tag has the form ll-CC or lll-CC, then CC must be from ISO 3166. It's > a one-way implication; that's it! It does *not* say that an ISO 3166 > country ID *must* occur as the second subtag. I have _never_ claimed otherwise. > > The difference is that there was never any guarantee given that the > > shortest-prefix-match approach would work well in all cases. > And there was never any guarantee that country IDs would always occur as > the second subtag. I HAVE NEVER CLAIMED OTHERWISE. > > You're effectively moving country codes to a new position in the > string. > > That's > > breaking compatibility in my book. > This is *not* a valid argument: > - Tags like "en-US" will still be "en-US" with the country ID in the > same position they were always in. > - The only cases in which one could possibly contend that the country ID > moved to a new position would be in comparing e.g. zh-TW with > zh-Hant-TW, and in such cases the loss of functionality resulting from > the country ID "moving" when the latter tag is used on one side of a > match (remember: zh-TW will still be valid) is less of a loss than > having implementations match for regional distinctions that pale in > relation to script distinctions. You're assuming that script codes will only be inserted where they are needed. Until Addison's proposal came up I saw no way to encourage this. > - Again, neither RFC 1766 or RFC 3066 stated that a country ID could > only occur as the second subtag, and it has always been invalid to > assume that this must be the case. And it has always been valid to handle this issue through an list of exceptions, resulting in a fully compliant implementation. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 11:37:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15835; Sat, 9 Apr 2005 11:37:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKIAA-0006MN-0n; Sat, 09 Apr 2005 11:46:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKHzf-000657-QM; Sat, 09 Apr 2005 11:35:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKHze-000652-2d for ltru@megatron.ietf.org; Sat, 09 Apr 2005 11:35:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15736 for ; Sat, 9 Apr 2005 11:35:28 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKI8d-0006FD-GV for ltru@ietf.org; Sat, 09 Apr 2005 11:44:48 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMVSY94CM800005R@mauve.mrochek.com> for ltru@ietf.org; Sat, 09 Apr 2005 08:35:24 -0700 (PDT) Date: Sat, 09 Apr 2005 08:27:36 -0700 (PDT) In-reply-to: "Your message dated Fri, 08 Apr 2005 20:49:53 -0700" <003601c53cb7$315d3180$030aa8c0@DEWELL> Message-id: <01LMVTUXJSQ400005R@mauve.mrochek.com> References: <20050409012753.RKSN2128.mta1.adelphia.net@megatron.ietf.org> <003601c53cb7$315d3180$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) To: Doug Ewell X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7BIT Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7BIT > Frank Ellermann wrote: > > 1 - At the moment no RfC 3066bis implementation exists. Proof: > > 3066bis isn't an RfC at the moment. > I'd like to see the look on your face when I show you my fully compliant > tag generator and validator for RFC 3066bis. (Cf. the last sentence of > Appendix A.) How about the look on your face when some detail in 3066bis changes, rendering your implemenation invalid in some way? I've implemented the rules I believe might be part of 3066bis myself. But since I lack a working crystal ball, I have no way of knowing if that's what will actually be in 3066bis when it is finally published. I therefore cannot claim to have a compliant implementation at this point. Nobody can. > Of course, I can't distribute it publicly as being compliant with > anything, since 3066bis is, indeed, not an RFC at the moment. Exactly. And more to the point, it may transpire that what actually emerges is different in some way. We'd all be wasting our time here if such changes weren't possible. > But I > always smile when someone says, for example, that the mechanism for > identifying subtags based on length and position "doesn't work," or that > parsing or validating tags is too complicated to be practical. Is anyone actually saying that in this group? If so I sure haven't heard it. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 12:26:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18534; Sat, 9 Apr 2005 12:26:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKIvq-0000BY-Su; Sat, 09 Apr 2005 12:35:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKImd-0001E7-VK; Sat, 09 Apr 2005 12:26:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKImc-0001E2-Ty for ltru@megatron.ietf.org; Sat, 09 Apr 2005 12:26:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18499 for ; Sat, 9 Apr 2005 12:26:04 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKIvb-0000B7-U9 for ltru@ietf.org; Sat, 09 Apr 2005 12:35:25 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j39GPuDD009202; Sat, 9 Apr 2005 12:25:56 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 9 Apr 2005 12:25:55 -0400 Date: Sat, 9 Apr 2005 12:25:55 -0400 From: John Cowan To: Jefsey Morfin Subject: Re: [Ltru] interesting IETF archives on language tags Message-ID: <20050409162555.GL24173@skunk.reutershealth.com> References: <6.1.2.0.2.20050407155838.050827c0@pop.online.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050407155838.050827c0@pop.online.fr> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Jefsey Morfin scripsit: > This URL may be of interest to some. > http://www.watersprings.org/cgi-bin/namazu.cgi?query=language+tag&idxname=id&max=20&result=normal&sort=score One of the links on this page is to RFC 3720, iSCSI, which refers to 3066 in its normative-references section despite its absolute irrelevance to the subject matter. Bizarre. > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- John Cowan jcowan@reutershealth.com www.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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 12:51:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19736; Sat, 9 Apr 2005 12:51:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKJJq-0001FI-Dx; Sat, 09 Apr 2005 13:00:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKJ8e-0005th-9k; Sat, 09 Apr 2005 12:48:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKJ8Z-0005tR-73 for ltru@megatron.ietf.org; Sat, 09 Apr 2005 12:48:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19640 for ; Sat, 9 Apr 2005 12:48:44 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKJHY-0001DI-Gr for ltru@ietf.org; Sat, 09 Apr 2005 12:58:05 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKJ8W-0008Bi-JO; Sat, 09 Apr 2005 09:48:45 -0700 Message-Id: <6.1.2.0.2.20050409174024.03f97810@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 09 Apr 2005 18:00:08 +0200 To: "Peter Constable" , From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: registry should copy non-English fields fromISOdocuments In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 At 14:58 09/04/2005, Peter Constable wrote: > > 1. How do we distinguish the French names from the English ones? > > (Other than by inspection) > >Let me add a third potential issue: When ISO 639-3 is initially >published, and the RA has published the initial code table, there will >not be French-language and English-language names for languages. There >will simply be a "reference name" for each language. Over time, the RA >may add documentation to list the names of languages in English, French >and possibly other languages, but it won't happen from the outset. > >So... This reference name is obviously not a medium term user acceptable solution. This is why the ISO 639-3 cannot be a final solution. And why we need a multi-language ontlogy. > > 2. Do we include (require?)(allow?) French, English, or both for > > future registrations that are not sourced from one of the ISO standards > > (ie. variants) > >I suggest that you cannot *require* anything in this regard. Allowing >is, of course, a different matter. I am sorry, but we make _require_ a MUST and main languages a SHOULD. I do not think this is negotiable. To the countrary it will become a MUST for main languages and a SHOULD for every languages. Extended to icons. BCP 047 describes a Best Practice. The discussed matter is hardly yet "common" since not yet agreed. What ISO does not do is of little interest when compared with common equal users needs and rights. Whatever their language, origin, script, culture, localisation, budget, intelligence, history. Within the limits of practicality I do not think we yet reached. I fully understand this leads to changes in your vision, way of thinking and organizing, etc. but I do not think you can avoid it. Because either we will do it or other people will do it, because this is what people and processes need. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 12:52:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19814; Sat, 9 Apr 2005 12:52:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKJKu-0001NO-F1; Sat, 09 Apr 2005 13:01:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKJ8e-0005tl-Dh; Sat, 09 Apr 2005 12:48:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKJ8a-0005tc-IC for ltru@megatron.ietf.org; Sat, 09 Apr 2005 12:48:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19646 for ; Sat, 9 Apr 2005 12:48:46 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKJHa-0001DO-Tm for ltru@ietf.org; Sat, 09 Apr 2005 12:58:07 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKJ8Y-0008Bi-HB; Sat, 09 Apr 2005 09:48:46 -0700 Message-Id: <6.1.2.0.2.20050409180657.03cda380@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 09 Apr 2005 18:32:59 +0200 To: ned.freed@mrochek.com, Doug Ewell From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) In-Reply-To: <01LMVTUXJSQ400005R@mauve.mrochek.com> References: <20050409012753.RKSN2128.mta1.adelphia.net@megatron.ietf.org> <003601c53cb7$315d3180$030aa8c0@DEWELL> <01LMVTUXJSQ400005R@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 At 17:27 09/04/2005, ned.freed@mrochek.com wrote: >Is anyone actually saying that in this group? If so I sure haven't heard it. I say it is absurd to define an information by its ... size! But if some like it ... Since I cannot use the whole thing ... as long as they do not make it mandatory in it being the only format of BCP 047 .... FYI the logical network multilingual layers come in the following order : - script so you can write each other strings - language so you can read each other commands - geolegal so you know the applying rules ... this permits interoperationality - referent so you can understand each other ... this permits interintellegibility - the vernacular style/practice so you can work together ... this permits interusability. If you really want to make it a formated langtag it should be script-language-country (in your parlance [4-]3-2 character strings, with 2 characters being acceptable in 1st position and script preposition being optional. This is what we should have in the IDNA and the big mistake was to put it in a different order, not understanding that the Internet is actually the ASCII class of the Multilingual Internet system. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 12:54:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19999; Sat, 9 Apr 2005 12:54:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKJNK-0001Up-22; Sat, 09 Apr 2005 13:04:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKJ8Z-0005tQ-5s; Sat, 09 Apr 2005 12:48:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKJ8W-0005tH-Dm for ltru@megatron.ietf.org; Sat, 09 Apr 2005 12:48:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19635 for ; Sat, 9 Apr 2005 12:48:41 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKJHW-0001DD-N1 for ltru@ietf.org; Sat, 09 Apr 2005 12:58:02 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKJ8V-0008Bi-0w for ltru@ietf.org; Sat, 09 Apr 2005 09:48:43 -0700 Message-Id: <6.1.2.0.2.20050409165318.03c3b520@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 09 Apr 2005 17:38:09 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 On 14:04 09/04/2005, Peter Constable said: > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] >On > > Behalf Of Frank Ellermann > > For "expecting" read "one side is old and uses language or > > language-region", and for "understanding" read "the old side > > doesn't support any language-script constructs". Bye, Frank > >But in what sense would the old side not be supporting language-script >constructs? These exist and conform to RFC 3066, so if the old side is >incapable of supporting them, it is not a 3066-conformant implementation >that we need to worry about. Dear Peter, I am not particularly interested in the APMD format since it does not fit my needs and I will not be able to use it. But would it be easier if you built a simple decision tree, documenting who/which application needs which information, when, how, for what, what it will do with it? After months I am still unable to understand what most in this WG want to do with langtags (to the point that the only comment I received to that question is that such a question is "editorial"). For example, let assume you have a document with "jfc-jefs-ey" as a langtag. Exactly what will happen? Will this be different if that document is XML, HTML, CLDR, LDAP, etc. Thank you for your help understanding this. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 12:56:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20191; Sat, 9 Apr 2005 12:56:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKJPW-0001Y1-3p; Sat, 09 Apr 2005 13:06:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKJ8Z-0005tM-1L; Sat, 09 Apr 2005 12:48:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKJ8U-0005sz-MJ for ltru@megatron.ietf.org; Sat, 09 Apr 2005 12:48:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19631 for ; Sat, 9 Apr 2005 12:48:40 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKJHU-0001D1-Oa for ltru@ietf.org; Sat, 09 Apr 2005 12:58:01 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKJ8Q-0008Bi-69 for ltru@ietf.org; Sat, 09 Apr 2005 09:48:39 -0700 Message-Id: <6.1.2.0.2.20050409131859.03dbceb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 09 Apr 2005 14:56:30 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Question about some draft text. In-Reply-To: <077001c53cd2$9d1bca10$be733009@sanjose.ibm.com> References: <634978A7DF025A40BFEF33EB191E13BC0AEF0337@irvmbxw01.quest.com> <077001c53cd2$9d1bca10$be733009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.7 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA19631 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable On 09:02 09/04/2005, Mark Davis said: >I agree. >=E2=80=8EMark I agree on the modification. I disagree on: - the decision by the reviewer to accept. It should be "to refuse",=20 decision being "yes" by default. Otherwise we may have CIOs, we have a=20 complex non documented procedure of relations with ISO (and only the ISO=20 case is quoted), we have no formal complete denial documentation to appea= l=20 (a new request may result in a new refusal). 15 days are enough for exper= ts=20 to say "this is inconsistent" or "should be reworded" and to document it = to=20 the reviewer, and then for the reviewer to document her decision (same=20 work) - could be 15 extra days to issue a statement. Less hassel and=20 maximum delays instead of minimum delays. - the extra wheight given to the initial registrant. For many practical=20 reasons. First the initial registrant can be dead, what puts some languag= es=20 in a different positions. Then it gives the registrant some kind of rigt = on=20 a language what is not acceptable. But mostly it implies that the=20 registration may be not clear enough to everyone to need an additional=20 comment. This is a standardization process, the name and the organization= =20 of the initial proponent should be forgotten. - no single one can "register" a language of many, we should use the=20 term "proponent" - the registration should not be deemed to be made by the proponent bu= t=20 by the ietf-languages@iana.org list. - the registered data should be all what is ever needed. jfc >----- Original Message ----- >From: "Addison Phillips" >To: >Sent: Friday, April 08, 2005 13:25 >Subject: [Ltru] Question about some draft text. > > > > In the draft there is one sentence that is bothering me. I think JFC >partially point this out: > > > > Updates of registrations follow the same procedure as > > registrations. The subtag reviewer decides whether to > > allow a new registrant to update a registration made > > by someone else; normally objections by the original > > registrant would carry extra weight in such a decision. > > > > This is a holdover from RFC 3066. It suggests that update requests ar= e not >subject to the same review. I would like to change this to say: > > > > Updates or changes to existing records, including > > previous registrations, follow the same procedure > > as new registrations. The Language Subtag Reviewer > > decides whether there is consensus to update the > > registration following the two week review period; > > normally objections by the original registrant will > > carry extra weight in forming such a consensus. > > > > > > Objections? > > > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > http://www.quest.com > > > > Chair, W3C Internationalization Core Working Group > > http://www.w3.org/International > > > > Internationalization is not a feature. > > It is an architecture. > > > > > > > > >------------------------------------------------------------------------= ---- >---- > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 13:00:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21315; Sat, 9 Apr 2005 13:00:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKJSd-0001ro-VC; Sat, 09 Apr 2005 13:09:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKJ8V-0005t9-U5; Sat, 09 Apr 2005 12:48:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKJ8U-0005t0-TH for ltru@megatron.ietf.org; Sat, 09 Apr 2005 12:48:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19629 for ; Sat, 9 Apr 2005 12:48:39 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKJHU-0001D5-ND for ltru@ietf.org; Sat, 09 Apr 2005 12:58:00 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKJ8R-0008Bi-U8; Sat, 09 Apr 2005 09:48:40 -0700 Message-Id: <6.1.2.0.2.20050409164651.03c304f0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 09 Apr 2005 16:52:45 +0200 To: "Peter Constable" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: registry should copy non-English fields fromISO documents In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On 14:04 09/04/2005, Peter Constable said: >I believe if you are the only one on this list not in agreement, that we >have a consensus. True. But you have not if I am in disagreement. And I am in disagreement. But the real point is this is not because that this list humms something that the world will consent. I tend to think we should listen to the world rather than expect the world will want to listen to us. Not just to study it? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 13:50:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25193; Sat, 9 Apr 2005 13:50:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKKF6-0004Ds-Vt; Sat, 09 Apr 2005 13:59:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKK2J-0000Wy-KT; Sat, 09 Apr 2005 13:46:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKK2I-0000Wr-HJ for ltru@megatron.ietf.org; Sat, 09 Apr 2005 13:46:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25031 for ; Sat, 9 Apr 2005 13:46:21 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKKBJ-00044r-3s for ltru@ietf.org; Sat, 09 Apr 2005 13:55:41 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j39Hk2X3003188; Sat, 9 Apr 2005 10:46:02 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AF9LD>; Sat, 9 Apr 2005 10:46:02 -0700 Message-ID: From: "McDonald, Ira" To: "'ned.freed@mrochek.com'" , Peter Constable Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) Date: Sat, 9 Apr 2005 10:46:01 -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: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of ned.freed@mrochek.com > Sent: Saturday, April 09, 2005 11:14 AM > To: Peter Constable > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) > > > > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] > > On > > > > This whole argument is a strawman. The number of cases in > which tags of > > the form ll-Ssss-CC will be used are limited. > > You have absolutely no way of knowing that that will be the > case. As I pointed > out in other mail, script information is something that often > can be derived > from other data. Country information is often something you > have available as > well. This makes it entirely possible that such tags will be > created in an > attempt to make things more informative. Since the inclusion or omission of script tags in future language tags would at best be a SHOULD in RFC3066bis, no definitive statement that the use of script tags will be rare is accurate. Much earlier in this thread, it was suggested to Kurt Zeilenga that an LDAP server be updated to infix script tags in EVERY record containing language tags (e.g., 'en-GB' --> 'en-Latn-GB'). If that's legal, then some misguided person may actually write a tool to do just that. Breaking all access by existing clients. John Cowan gave an example (level 2 Braille) where the script tag definitely should be sorted AFTER the region tag. In order to clean up what someday may well be called "The Chinese Mess" and provide for the use of script tags elsewhere, you folks are maintaining that it's harmless to reorder the subtags. It's not! If script tags SHOULD be rare in use, then it's no burden for them to occupy the third position, rather than the second. Semi-OT - the inclusion of script tags in language tags breaks utterly the utility of presenting language choices to users in GUIs as country-flag icons - the script differences would be invisible. Cheers, - Ira _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 14:08:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26103; Sat, 9 Apr 2005 14:08:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKKWJ-00052j-Va; Sat, 09 Apr 2005 14:17:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKKKj-0004Mn-5t; Sat, 09 Apr 2005 14:05:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKJ8R-0005sl-0u for ltru@megatron.ietf.org; Sat, 09 Apr 2005 12:48:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19619 for ; Sat, 9 Apr 2005 12:48:36 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKJHR-0001Cu-6h for ltru@ietf.org; Sat, 09 Apr 2005 12:57:57 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKJ8O-0008Bh-OX for ltru@ietf.org; Sat, 09 Apr 2005 09:48:37 -0700 Message-Id: <6.1.2.0.2.20050409154123.03910ab0@pop.online.fr> X-Sender: jefsey@pop.online.fr X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 09 Apr 2005 16:16:04 +0200 To: "LTRU Working Group" From: Jefsey Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - online.fr X-Spam-Score: 1.8 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Sat, 09 Apr 2005 14:05:23 -0400 Subject: [Ltru] ISO 639, ISO 3166 and ISO 15924 BCP 047 subtags supports. X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 1.8 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 With the automated deluge of resolved points which poured on this WG I am not sure of the exact situation. 1. ISO 639 I understand that we converge towards the idea that French and English code element documentation will be two BCP 047 "subtags". I also understand that the more CPU costly to parse that "|" separators, but more flexible "jar notation" will permit (but not force) to add languages in registries desiring it (we will be directly able to generate your registry from ours). Our own Gositer format will permit easily to generate a FrancoEnglish registry from any multilingual system we may maintain. (Gositer is multifile [includes files] and multilanguages [entries are preceded by a language tag: jar "name:" is ":fr .name" in gositer). I understand we still have a disagreement which is that the initial registry could bve registered as an RFC and only include the current ISO 639-2, while I say that the RFC should say that every ISO 639 tables (2,3,6) should be registered when available under the responsibility of the "Reviewer". 2. ISO 3166 I am not sure about the ISO 3166 situation. Obviously every historic situation of ISO 3166 should be registered (if this was not the current situation please accept this as a formal opposition to any other proposition). Since the inception of ISO 3166 (as reminded we started using it in 1978), but also the reconstitution that the ISO 3166 commission may introduce, we need every information presented in the same way for an historically consistent description of languages. 3. ISO 15924 ISO 15924 is the younguest standard. Its use/way of use is not necessarily clear to most of the Internet application. There is obviously no harm in having it listed as BCP 047 compliant. The addition of other scripts should be concerted with the concerned standardisation organisations. 4. Initial registry I understand there is a problem to make the initial registry French compliant, since some IANA entries have been made which does not include a French description. I suggest that the appropriate requests are sent to the French Commissions for ISO 639 and ISO 3166. I am not sure about the existence of a French Commission for ISO 15924. I will inquire. (I note that you may not have a heavy commitment if ISO 3166 prior 1988 elements are not retained). General comment I wish to underline this is written in the spirit of the WG-ltru Charter and only concerns the IANA registry, I make a separte issue from any format, from any usage, from any dissemination method, from any additional not ISO content and from any maintenance procedure. I only use the term "subtag" to be understood. I prefer the term if descriptor but I am open to any other term which does not refer to any given format. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 14:08:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26132; Sat, 9 Apr 2005 14:08:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKKX4-00053K-R5; Sat, 09 Apr 2005 14:18:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKKKj-0004Mr-AN; Sat, 09 Apr 2005 14:05:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKJ8S-0005sq-Ot for ltru@megatron.ietf.org; Sat, 09 Apr 2005 12:48:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19622 for ; Sat, 9 Apr 2005 12:48:38 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKJHS-0001Cz-5M for ltru@ietf.org; Sat, 09 Apr 2005 12:57:59 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKJ8Q-0008Bh-6f for ltru@ietf.org; Sat, 09 Apr 2005 09:48:38 -0700 Message-Id: <6.1.2.0.2.20050409184008.03cda230@pop.online.fr> X-Sender: jefsey@pop.online.fr X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 09 Apr 2005 18:44:30 +0200 To: "ltru Working Group" From: Jefsey Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - online.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db X-Mailman-Approved-At: Sat, 09 Apr 2005 14:05:23 -0400 Subject: [Ltru] language or price tag ? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de http://www.dailypress.net/letters/story/046202005_let01-l0406.asp This type of consideration is exactly the kind of problem we all face and that langtags should participate into the resolution. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 14:38:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27876; Sat, 9 Apr 2005 14:38:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKKzL-0006P4-7b; Sat, 09 Apr 2005 14:47:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKKpm-0001nM-Vm; Sat, 09 Apr 2005 14:37:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKKpk-0001n8-Qv for ltru@megatron.ietf.org; Sat, 09 Apr 2005 14:37:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27831 for ; Sat, 9 Apr 2005 14:37:27 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKKyl-0006O0-Q1 for ltru@ietf.org; Sat, 09 Apr 2005 14:46:48 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=ISO-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMVSY94CM800005R@mauve.mrochek.com> for ltru@ietf.org; Sat, 09 Apr 2005 11:37:22 -0700 (PDT) Date: Sat, 09 Apr 2005 11:32:02 -0700 (PDT) In-reply-to: "Your message dated Sat, 09 Apr 2005 10:46:01 -0700" Message-id: <01LMW08HTX9I00005R@mauve.mrochek.com> References: Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) To: McDonald Ira X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7BIT Cc: ltru@ietf.org, "'nedfreedmrochekcom'" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7BIT > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of ned.freed@mrochek.com > > Sent: Saturday, April 09, 2005 11:14 AM > > To: Peter Constable > > Cc: ltru@ietf.org > > Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) > > > > > > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] > > > On > > > > > > > This whole argument is a strawman. The number of cases in > > which tags of > > > the form ll-Ssss-CC will be used are limited. > > > > You have absolutely no way of knowing that that will be the > > case. As I pointed > > out in other mail, script information is something that often > > can be derived > > from other data. Country information is often something you > > have available as > > well. This makes it entirely possible that such tags will be > > created in an > > attempt to make things more informative. > Since the inclusion or omission of script tags in future language > tags would at best be a SHOULD in RFC3066bis, no definitive > statement that the use of script tags will be rare is accurate. > Much earlier in this thread, it was suggested to Kurt Zeilenga > that an LDAP server be updated to infix script tags in EVERY > record containing language tags (e.g., 'en-GB' --> 'en-Latn-GB'). > If that's legal, then some misguided person may actually write > a tool to do just that. Breaking all access by existing clients. Didn't catch that one. Not good at all. The one I've been thinking is likely is for message sending clients (including but not limited to email clients) to insert script tags based on analysis of message text. I already see a fair number of instances of clients blithely adding language labels unconditionally (and often incorrectly), so this didn't seem like much of a stretch. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 14:50:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28547; Sat, 9 Apr 2005 14:50:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKLBE-0006wU-Rq; Sat, 09 Apr 2005 14:59:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKL1Z-0003rz-CQ; Sat, 09 Apr 2005 14:49:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKL1Y-0003ru-NA for ltru@megatron.ietf.org; Sat, 09 Apr 2005 14:49:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28524 for ; Sat, 9 Apr 2005 14:49:39 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKLAY-0006vm-2m for ltru@ietf.org; Sat, 09 Apr 2005 14:59:00 -0400 Received: from h-68-166-38-178.snvacaid.dynamic.covad.net ([68.166.38.178] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DKL1S-0006Dp-00 for ltru@ietf.org; Sat, 09 Apr 2005 11:49:34 -0700 Message-ID: <006001c53d35$0ff36ea0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0AEF0337@irvmbxw01.quest.com><077001c53cd2$9d1bca10$be733009@sanjose.ibm.com> <6.1.2.0.2.20050409131859.03dbceb0@mail.jefsey.com> Subject: Re: [Ltru] [psg.com #907] Question about some draft text. Date: Sat, 9 Apr 2005 11:50:55 -0700 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: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi - (co-chair hat ON) Since there appears to be agreement on the change, I've entered this into the RT issue tracker as "resolved" issue [psg.com #907]. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 15:04:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29603; Sat, 9 Apr 2005 15:04:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKLPI-0007gF-Ta; Sat, 09 Apr 2005 15:14:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKLEm-0006Mi-HR; Sat, 09 Apr 2005 15:03:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKLEk-0006L9-Mh for ltru@megatron.ietf.org; Sat, 09 Apr 2005 15:03:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29443 for ; Sat, 9 Apr 2005 15:03:16 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKLNl-0007fB-DU for ltru@ietf.org; Sat, 09 Apr 2005 15:12:37 -0400 Received: from h-68-166-38-178.snvacaid.dynamic.covad.net ([68.166.38.178] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DKLEi-0001Li-00 for ltru@ietf.org; Sat, 09 Apr 2005 12:03:16 -0700 Message-ID: <006701c53d36$facb8f60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0AEF0337@irvmbxw01.quest.com><077001c53cd2$9d1bca10$be733009@sanjose.ibm.com> <6.1.2.0.2.20050409131859.03dbceb0@mail.jefsey.com> Subject: [Ltru] Re: [psg.com #881] remove registrant information from registry Date: Sat, 9 Apr 2005 12:04:39 -0700 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: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Hi - I've change the subject line so Jefsey's comments are included in the correct thread. > From: "JFC (Jefsey) Morfin" > To: > Sent: Saturday, April 09, 2005 5:56 AM > Subject: Re: [Ltru] Question about some draft text. ... > - the extra wheight given to the initial registrant. For many practical > reasons. First the initial registrant can be dead, what puts some languages > in a different positions. Then it gives the registrant some kind of rigt on > a language what is not acceptable. But mostly it implies that the > registration may be not clear enough to everyone to need an additional > comment. This is a standardization process, the name and the organization > of the initial proponent should be forgotten. > > - no single one can "register" a language of many, we should use the > term "proponent" > - the registration should not be deemed to be made by the proponent but > by the ietf-languages@iana.org list. > - the registered data should be all what is ever needed. > > jfc ... (Co-chair hat ON) I marked this issue "rejected" because it has found no support in the WG from anyone other than you, its originator. That status will not change back to "open" unless there is broader support for re-opening the issue. Nonetheless, you are welcome to continue to try to make a case for re-opening it. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 15:25:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01955; Sat, 9 Apr 2005 15:25:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKLjU-0000Dj-N1; Sat, 09 Apr 2005 15:35:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKLaD-00019L-Oe; Sat, 09 Apr 2005 15:25:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKLaC-00019G-O6 for ltru@megatron.ietf.org; Sat, 09 Apr 2005 15:25:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01931 for ; Sat, 9 Apr 2005 15:25:26 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKLjC-0000D9-Rg for ltru@ietf.org; Sat, 09 Apr 2005 15:34:48 -0400 Received: from h-68-166-38-178.snvacaid.dynamic.covad.net ([68.166.38.178] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DKLa8-0006bD-00 for ltru@ietf.org; Sat, 09 Apr 2005 12:25:24 -0700 Message-ID: <007801c53d3a$12c31720$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "ltru Working Group" References: <6.1.2.0.2.20050409184008.03cda230@pop.online.fr> Subject: Re: [Ltru] language or price tag ? Date: Sat, 9 Apr 2005 12:26:47 -0700 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: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi - > From: "Jefsey Morfin" > To: "ltru Working Group" > Sent: Saturday, April 09, 2005 9:44 AM > Subject: [Ltru] language or price tag ? > > http://www.dailypress.net/letters/story/046202005_let01-l0406.asp > This type of consideration is exactly the kind of problem we all face and > that langtags should participate into the resolution. > jfc ... I find this puzzling. The letter in question advocates the adoption of an official national language in the US, and uses the cost of supporting multilingual access as justification. Are you proposing that the WG's members should somehow lobby to rescind corresponding laws in countries that have designated certain languages as "official"? That would be *far* outside our charter. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 17:06:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08182; Sat, 9 Apr 2005 17:06:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKNJ6-0004xN-HD; Sat, 09 Apr 2005 17:15:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKN8p-0007nr-85; Sat, 09 Apr 2005 17:05:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKN8n-0007nm-Tg for ltru@megatron.ietf.org; Sat, 09 Apr 2005 17:05:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08157 for ; Sat, 9 Apr 2005 17:05:15 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKNHq-0004qb-9c for ltru@ietf.org; Sat, 09 Apr 2005 17:14:38 -0400 Received: from uknsprd1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Sat, 9 Apr 2005 21:05:00 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IEP00I2Q6KCBO@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Sat, 09 Apr 2005 22:05:00 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Sat, 09 Apr 2005 21:05:00 +0000 Date: Sat, 09 Apr 2005 22:05:00 +0100 From: Misha Wolf Subject: RE: [Ltru] Compatibility with existing use (LDAP) To: LTRU Working Group Message-id: <1987416CA83AC7499AC772F92E2DBF78037C9AFC@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Compatibility with existing use (LDAP) Thread-Index: AcU9LJgEAxu+dHvQRkuKyzVIWW1jHgAGREFw content-class: urn:content-classes:message X-OriginalArrivalTime: 09 Apr 2005 21:05:00.0301 (UTC) FILETIME=[CAB8D3D0:01C53D47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Ira McDonald wrote: > If script tags SHOULD be rare in use, then it's no burden for > them to occupy the third position, rather than the second. I cannot imagine what mental model you have of *why* a=20 script or a country should be included in a language tag. Consider "zh". And consider the *very* large number of=20 people wanting to tag their text as, or look for text in,=20 either Traditional or Simplified Chinese. Are you serious=20 in arguing that they should have to inject a country code=20 between "zh" and the "Hant" or "Hans"? Let's see: The person requesting a resource will have to=20 specify a list of languages, of the form zh-C1-Hant,=20 zh-C2-Hant, zh-C3-Hant, in order to obtain all resources in=20 Traditional Chinese. And what do you expect the person tagging a resource to do? In general, they don't have the possibility of using multiple=20 tags (zh-C1-Hant, zh-C2-Hant, zh-C3-Hant) to describe their=20 resource. So what should they do? If they choose just one,=20 eg zh-C2-Hant, then requestors specifying either zh-C1-Hant=20 or zh-C3-Hant will not get the resource. I feel that those who advocate the ll-CC-Scipt approach are=20 simply sticking their heads in the sand and refusing to=20 engage with reality. > Semi-OT - the inclusion of script tags in language tags breaks > utterly the utility of presenting language choices to users in > GUIs as country-flag icons - the script differences would be > invisible. I can't imagine how you can seek to portray something so=20 daft as being a reasonable practice. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 17:25:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09013; Sat, 9 Apr 2005 17:25:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKNbO-0005it-LM; Sat, 09 Apr 2005 17:34:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKNRW-0002Kf-CD; Sat, 09 Apr 2005 17:24:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKNRU-0002KW-IH for ltru@megatron.ietf.org; Sat, 09 Apr 2005 17:24:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08910 for ; Sat, 9 Apr 2005 17:24:34 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKNaW-0005i0-9V for ltru@ietf.org; Sat, 09 Apr 2005 17:33:57 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Apr 2005 14:24:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: registry should copy non-English fields fromISOdocuments Date: Sat, 9 Apr 2005 14:24:23 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3A95@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: registry should copy non-English fields fromISOdocuments Thread-Index: AcU9JXezzgoSOsALT7al3M4WyT9gkwABDulw From: "Addison Phillips" To: "JFC (Jefsey) Morfin" , "Peter Constable" X-OriginalArrivalTime: 09 Apr 2005 21:24:23.0759 (UTC) FILETIME=[80326DF0:01C53D4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable This is an open list. If the world cares to hum, we will hear it from = here (and no where else). There is no other way to form or judge = consensus: how else will IETF standards get done? If there are = objections then individuals will have to make them known so that they = can be considered. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of JFC (Jefsey) Morfin > Sent: samedi 9 avril 2005 07:53 > To: Peter Constable > Cc: ltru Working Group > Subject: RE: [Ltru] Re: registry should copy non-English fields > fromISOdocuments >=20 > On 14:04 09/04/2005, Peter Constable said: > >I believe if you are the only one on this list not in agreement, that = we > >have a consensus. >=20 > True. But you have not if I am in disagreement. And I am in = disagreement. > But the real point is this is not because that this list humms = something > that the world will consent. > I tend to think we should listen to the world rather than expect the = world > will want to listen to us. > Not just to study it? > jfc >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 17:26:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09089; Sat, 9 Apr 2005 17:26:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKNc0-0005jv-VQ; Sat, 09 Apr 2005 17:35:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKNRW-0002Kb-7Q; Sat, 09 Apr 2005 17:24:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKNRT-0002KO-SU for ltru@megatron.ietf.org; Sat, 09 Apr 2005 17:24:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08907 for ; Sat, 9 Apr 2005 17:24:33 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKNaW-0005hz-Aq for ltru@ietf.org; Sat, 09 Apr 2005 17:33:56 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Apr 2005 14:24:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Question about some draft text. Date: Sat, 9 Apr 2005 14:24:22 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3A94@irvmbxw01.quest.com> Thread-Topic: [Ltru] Question about some draft text. Thread-Index: AcU9JO0fuaAZFz+rRDukEbd5+fVtAAAA7QCw From: "Addison Phillips" To: "JFC (Jefsey) Morfin" , X-OriginalArrivalTime: 09 Apr 2005 21:24:23.0437 (UTC) FILETIME=[80014BD0:01C53D4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Content-Transfer-Encoding: quoted-printable See inline. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of JFC (Jefsey) Morfin > Sent: samedi 9 avril 2005 05:57 > To: ltru@ietf.org > Subject: Re: [Ltru] Question about some draft text. >=20 > On 09:02 09/04/2005, Mark Davis said: > >I agree. > >=E2EURZMark >=20 > I agree on the modification. >=20 > I disagree on: >=20 > - the decision by the reviewer to accept. It should be "to refuse", > decision being "yes" by default. Otherwise we may have CIOs, we have a [Addison Phillips]=20 The reviewer makes a statement about whether consensus has or has not = been reached. Lack of consensus is "no". The reviewer does NOT decide = about the registration personally, they only make the judgment call on = group consensus. There are many registered tags today that the current reviewer did not = personally agree with. > complex non documented procedure of relations with ISO (and only the = ISO > case is quoted), we have no formal complete denial documentation to = appeal > (a new request may result in a new refusal). 15 days are enough for > experts > to say "this is inconsistent" or "should be reworded" and to document = it > to > the reviewer, and then for the reviewer to document her decision (same > work) - could be 15 extra days to issue a statement. Less hassel and > maximum delays instead of minimum delays. >=20 > - the extra wheight given to the initial registrant. For many = practical > reasons. First the initial registrant can be dead, what puts some > languages [Addison Phillips]=20 Read my text carefully. It says: > > > normally objections by the original registrant will > > > carry extra weight in forming such a consensus. Which is different than what RFC 3066 says. RFC 3066 actually gave extra = weight to the original registrant by rule. My text says that their voice = will probably be influential. There is a world of difference in that. > in a different positions. Then it gives the registrant some kind of = rigt > on > a language what is not acceptable. But mostly it implies that the > registration may be not clear enough to everyone to need an additional > comment. This is a standardization process, the name and the = organization > of the initial proponent should be forgotten. >=20 > - no single one can "register" a language of many, we should use = the > term "proponent" [Addison Phillips]=20 I disagree. > - the registration should not be deemed to be made by the proponent = but > by the ietf-languages@iana.org list. [Addison Phillips]=20 The registration is not "made by" the registrant. But we track who = requested it. > - the registered data should be all what is ever needed. [Addison Phillips]=20 No kidding? Is there something we are not requesting that should be? The registered data fills in the registry entry. Of course, others may = register additional comments, prefixes, etc. etc. in the record over = time. >=20 > jfc >=20 >=20 > >----- Original Message ----- > >From: "Addison Phillips" > >To: > >Sent: Friday, April 08, 2005 13:25 > >Subject: [Ltru] Question about some draft text. > > > > > > > In the draft there is one sentence that is bothering me. I think = JFC > >partially point this out: > > > > > > Updates of registrations follow the same procedure as > > > registrations. The subtag reviewer decides whether to > > > allow a new registrant to update a registration made > > > by someone else; normally objections by the original > > > registrant would carry extra weight in such a decision. > > > > > > This is a holdover from RFC 3066. It suggests that update requests = are > not > >subject to the same review. I would like to change this to say: > > > > > > Updates or changes to existing records, including > > > previous registrations, follow the same procedure > > > as new registrations. The Language Subtag Reviewer > > > decides whether there is consensus to update the > > > registration following the two week review period; > > > normally objections by the original registrant will > > > carry extra weight in forming such a consensus. > > > > > > > > > Objections? > > > > > > > > > Addison > > > > > > Addison P. Phillips > > > Globalization Architect, Quest Software > > > http://www.quest.com > > > > > > Chair, W3C Internationalization Core Working Group > > > http://www.w3.org/International > > > > > > Internationalization is not a feature. > > > It is an architecture. > > > > > > > > > > > > > > = >------------------------------------------------------------------------= - > --- > >---- > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 17:35:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09708; Sat, 9 Apr 2005 17:35:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKNla-0006Cd-35; Sat, 09 Apr 2005 17:45:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKNU3-0002hu-8E; Sat, 09 Apr 2005 17:27:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKNTz-0002hh-DN for ltru@megatron.ietf.org; Sat, 09 Apr 2005 17:27:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09255 for ; Sat, 9 Apr 2005 17:27:09 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKNd2-0005m3-2q for ltru@ietf.org; Sat, 09 Apr 2005 17:36:32 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Apr 2005 14:27:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Compatibility with existing use (LDAP) Date: Sat, 9 Apr 2005 14:27:01 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3A96@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU9LJdE2G1hD/GnSYqjtjPCENu0XwAHduBA From: "Addison Phillips" To: "McDonald, Ira" , , "Peter Constable" X-OriginalArrivalTime: 09 Apr 2005 21:27:02.0022 (UTC) FILETIME=[DE877260:01C53D4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable > Much earlier in this thread, it was suggested to Kurt Zeilenga > that an LDAP server be updated to infix script tags in EVERY > record containing language tags (e.g., 'en-GB' --> 'en-Latn-GB'). > If that's legal, then some misguided person may actually write > a tool to do just that. Breaking all access by existing clients. That is a valiant mis-reading of my previous email, at best, if you are = referring to my email to Kurt. I suggested that users who wished to use script subtags would, by = necessity, need to use them consistently for some particular language = prefix. Either all in or all out, as it were. This does not suggest that someone write an LDAP implementation to = perform the expansion. Only that users choose tags wisely. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of McDonald, Ira > Sent: samedi 9 avril 2005 10:46 > To: 'ned.freed@mrochek.com'; Peter Constable > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of ned.freed@mrochek.com > > Sent: Saturday, April 09, 2005 11:14 AM > > To: Peter Constable > > Cc: ltru@ietf.org > > Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) > > > > > > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] > > > On > > > > > > > This whole argument is a strawman. The number of cases in > > which tags of > > > the form ll-Ssss-CC will be used are limited. > > > > You have absolutely no way of knowing that that will be the > > case. As I pointed > > out in other mail, script information is something that often > > can be derived > > from other data. Country information is often something you > > have available as > > well. This makes it entirely possible that such tags will be > > created in an > > attempt to make things more informative. >=20 > Since the inclusion or omission of script tags in future language > tags would at best be a SHOULD in RFC3066bis, no definitive > statement that the use of script tags will be rare is accurate. >=20 > Much earlier in this thread, it was suggested to Kurt Zeilenga > that an LDAP server be updated to infix script tags in EVERY > record containing language tags (e.g., 'en-GB' --> 'en-Latn-GB'). > If that's legal, then some misguided person may actually write > a tool to do just that. Breaking all access by existing clients. >=20 > John Cowan gave an example (level 2 Braille) where the script > tag definitely should be sorted AFTER the region tag. In order > to clean up what someday may well be called "The Chinese Mess" > and provide for the use of script tags elsewhere, you folks are > maintaining that it's harmless to reorder the subtags. It's not! >=20 > If script tags SHOULD be rare in use, then it's no burden for > them to occupy the third position, rather than the second. >=20 > Semi-OT - the inclusion of script tags in language tags breaks > utterly the utility of presenting language choices to users in > GUIs as country-flag icons - the script differences would be > invisible. >=20 > Cheers, > - Ira >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 17:51:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10630; Sat, 9 Apr 2005 17:51:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKO0Q-00071V-C6; Sat, 09 Apr 2005 18:00:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKNrA-0006P7-9j; Sat, 09 Apr 2005 17:51:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKNr8-0006P2-Hq for ltru@megatron.ietf.org; Sat, 09 Apr 2005 17:51:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10616 for ; Sat, 9 Apr 2005 17:51:03 -0400 (EDT) Received: from pop-a065c05.pas.sa.earthlink.net ([207.217.121.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKO0A-0006vU-4k for ltru@ietf.org; Sat, 09 Apr 2005 18:00:27 -0400 Received: from h-68-166-38-178.snvacaid.dynamic.covad.net ([68.166.38.178] helo=oemcomputer) by pop-a065c05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DKNr5-0002Xh-00 for ltru@ietf.org; Sat, 09 Apr 2005 14:51:03 -0700 Message-ID: <001601c53d4e$6a5ab4c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <1987416CA83AC7499AC772F92E2DBF78037C9AFC@LONSMSXM02.emea.ime.reuters.com> Subject: Re: [Ltru] Compatibility with existing use (LDAP) Date: Sat, 9 Apr 2005 14:52:24 -0700 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: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi - As a technical contributor, the longer this thread goes on the more consideration I think we should give to alternatives like http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt If we were to treat the identification of the language(variant), the script, and the orthography of a text as three distinct attributes, rather than trying to structure them into a single string called a "language tag" would it ultimately make things simpler or more complicated? I find this approach intuitively appealing in the case where there are multiple orthographic alternatives in the same script for a given language, yet it has no impact at all on texts in languages where identification of the script or orthography in use is of no particular interest. Even transcriptions and transliterations can be handled nicely into this kind of approach, since they just become orthographic alternatives. It would, however, require a re-thinking of how we've handled German and Chinese. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 18:22:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13453; Sat, 9 Apr 2005 18:22:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKOUW-0008UU-Ij; Sat, 09 Apr 2005 18:31:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKOJW-0002C0-GX; Sat, 09 Apr 2005 18:20:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKOJV-0002Bv-2d for ltru@megatron.ietf.org; Sat, 09 Apr 2005 18:20:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13378 for ; Sat, 9 Apr 2005 18:20:22 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKOSY-0008Mg-1P for ltru@ietf.org; Sat, 09 Apr 2005 18:29:46 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Apr 2005 15:20:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 9 Apr 2005 15:20:14 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3A97@irvmbxw01.quest.com> Thread-Topic: seeking resolution of the Great Script Debate Thread-Index: AcU9UkkZDZhi6kHLR3m9cbpcJ+ipBw== From: "Addison Phillips" To: X-OriginalArrivalTime: 09 Apr 2005 22:20:15.0109 (UTC) FILETIME=[4DC1DB50:01C53D52] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Subject: [Ltru] seeking resolution of the Great Script Debate X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0801172277==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 --===============0801172277== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgdG8gbWUgdGhhdCBpbiBvcmRlciB0byBhY2hpZXZlIGEgcmVzb2x1dGlvbiBvZiB0 aGlzIGlzc3VlLCB3ZSBuZWVkIHRvIHRha2UgYSBzdGVwIGJhY2sgYW5kIGxvb2sgY29uY3JldGVs eSBhdCB0aGUgcHJvYmxlbS4NCg0KVGhpcyBtZXNzYWdlIGlzIGdvaW5nIHRvIGJlIHNvbWV3aGF0 IGxvbmcsIHNpbmNlIEknbSBnb2luZyB0byBsb29rIGF0IGJvdGggc2lkZXMgb2YgdGhlIHByb2Js ZW0gaW4gZGV0YWlsLg0KDQpMZXQncyBzdGFydCB3aXRoIHRoZSBjb21wYXRpYmlsaXR5IHByb2Js ZW0uIFRoZSBjbGFpbSBvZiBOZWQsIElyYSwgYW5kIG90aGVycyBpcyB0aGF0IDMwNjZiaXMgImJy ZWFrcyIgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zLiBJIHRoaW5rIHRoYXQgd29yZCAiYnJlYWtz IiBpcyBwcm9ibGVtYXRpYywgYmVjYXVzZSBpdCBkb2VzIG5vdCBkZXNjcmliZSBhY2N1cmF0ZWx5 IHdoYXQgaGFwcGVucy4gTm8gaW1wbGVtZW50YXRpb25zIGFjdHVhbGx5IGNyYXNoIHdoZW4geW91 IHNlbmQgdGhlbSB0YWdzIHRoYXQgdGhleSBkb24ndCByZWNvZ25pemUgKHRob3NlIHRoYXQgZG8g YXJlIGJleW9uZCBjb25zaWRlcmF0aW9uIGhlcmUpLiBXaGF0IHdlIG1lYW4gaXMgdGhhdCB0aGUg cmVzdWx0cyBwcm9kdWNlZCBhcmUgZWl0aGVyIG5vdCB3aGF0IHRoZSB1c2VyIGV4cGVjdGVkIG9y IGFyZSBkaWZmZXJlbnQgdGhhbiB3aGF0IHRoZSB1c2VyIHByZXZpb3VzbHkgcmVjZWl2ZWQgZm9y IHRoZSBzYW1lIHJlcXVlc3QuDQoNClRoZXJlIGFyZSB0d28ga2luZHMgb2YgaW1wbGVtZW50YXRp b24gdGhhdCB3ZSd2ZSBiZWVuIGhvbGRpbmcgdXAgZm9yIGV4YW1pbmF0aW9uLiBJJ2xsIHRha2Ug dGhlbSBpbiB0dXJucy4NCg0KRmlyc3QgYXJlIHB1cmUgUkZDIDI2MTYgbWF0Y2hpbmcgaW1wbGVt ZW50YXRpb25zIHdoaWNoIGRvbid0IGNhcmUgYWJvdXQgdGhlIGNvbnRlbnRzIG9mIGEgcGFydGlj dWxhciBzdWJ0YWcuIFRoaXMgaXMgZXF1aXZhbGVudCB0byB3aGF0IDMwNjZiaXMgY2FsbHMgYSAi d2VsbC1mb3JtZWQiIHByb2Nlc3Nvci4gQ29tbW9uIGV4YW1wbGVzIG9mIHRoZXNlIGluY2x1ZGUg eG1sOmxhbmcsIENTUyAyLjEsIEFwYWNoZSdzIGxhbmd1YWdlIG5lZ290aWF0aW9uIG1lY2hhbmlz bSBhbmQgS3VydCdzIExEQVAgUkZDLiBJbiB0aGVzZSBpbXBsZW1lbnRhdGlvbnMsIGl0IGRvZXNu J3QgbWF0dGVyIGlmIHlvdSBzZW5kIHRoZW0gYSB0YWcgbGlrZSAiZm9vLWJhci1iYXotZ2xlZXAi IG9yICJ6aC1IYW50LUNOIi4gQWxsIHRoYXQgbWF0dGVycyBpcyB0aGUgbWF0Y2hpbmcgb2YgZWFj aCB0b2tlbiBvciBzdWJ0YWcgaW4gb3JkZXIuDQoNCkZvciB0aGVzZSBpbXBsZW1lbnRhdGlvbnMs IHNjcmlwdCBzdWJ0YWdzIHBvc2UgYSBwcm9ibGVtIGlmIHRoZXkgYXJlIGluY29uc2lzdGVudGx5 IHVzZWQgZm9yIGEgZ2l2ZW4gbGFuZ3VhZ2UgcHJlZml4LiBUaGF0IGlzLCBpZiBJIHNvbWV0aW1l cyByZXF1ZXN0ICJ4eC1MYXRuLUNDIiBhbmQgc29tZXRpbWVzIHJlcXVlc3QgInh4LUNDIiBvciBp ZiBJIHNvbWV0aW1lcyB0YWcgY29udGVudCB1c2luZyAieHgtTGF0bi1DQyIgYW5kIHNvbWV0aW1l cyBhcyAieHgtQ0MiLCB0aGVuIEkgd2lsbCBleHBlcmllbmNlIHByb2JsZW1zIHdpdGggbWF0Y2hp bmcgdGhlICJ4eC1MYXRuIiBwcmVmaXggdG8gInh4LUNDIiBhbmQgdmljZSB2ZXJzYS4gVGhlIGFw cHJvYWNoIDMwNjZiaXMgdGFrZXMgaGVyZSBpcyB0byBzdWdnZXN0IHRoYXQgY29udGVudCBhdXRo b3JzIGFuZCByZXF1ZXN0ZXJzIGJlIHN5c3RlbWF0aWMgaW4gdXNpbmcgb3Igbm90IHVzaW5nIHNj cmlwdCBzdWJ0YWdzLiANCg0KTGV0IHVzIHBhdXNlIGFuZCByZWNvZ25pemUgdGhhdCB0aGVyZSBh cmUgbWFueSBpbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBuYXR1cmUgYW5kIGFsc28gcmVjb2duaXpl IHRoYXQgdGhpcyBpcyBub3QgYnkgYW55IG1lYW5zICJhbGwiIGltcGxlbWVudGF0aW9ucyBlaXRo ZXIuDQoNClNlY29uZCBhcmUgdGhlIGtpbmRzIG9mIGltcGxlbWVudGF0aW9ucyBOZWQgRnJlZWQg aGFzIGRlc2NyaWJlZCwgd2hpY2ggRE8gY2FyZSBhYm91dCB0aGUgY29udGVudHMgb2Ygc3BlY2lm aWMgc3VidGFncy4gSW4gYW4gUkZDIDMwNjZiaXMgaW1wbGVtZW50YXRpb24sIHRoZXNlIGFyZSB2 YWxpZGF0aW5nIHByb2Nlc3NvcnMuIEEgd2VsbC1rbm93biBleGFtcGxlIHRoYXQgSSdsbCB1c2Ug YXMgYSBwcm9vZi1vZi1jb25jZXB0IGlzIHRoZSBTZXJ2bGV0UmVxdWVzdC5nZXRMb2NhbGUgbWV0 aG9kIG9mIEoyRUUuIFRoaXMgbWV0aG9kIHRha2VzIEFjY2VwdC1sYW5ndWFnZSB0YWdzIGluIHRo ZSBIVFRQIGhlYWRlciBhbmQgYXR0ZW1wdHMgdG8gbWF0Y2ggdGhlbSB0byBqYXZhLnV0aWwuTG9j YWxlIG9iamVjdHMgcHJlZGVmaW5lZCBpbiB0aGUgSmF2YSBydW50aW1lIGVudmlyb25tZW50LiBU aGVyZSBhcmUgcm91Z2hseSAxNTAgb2YgdGhlc2UgaW4gYSBKUkUgKGxlc3MsIHVzdWFsbHksIGFu ZCB0aGUgbnVtYmVyIHZhcmllcyBieSBKUkUpIGluIHRoZSBmb3JtIGxhbmd1YWdlX3JlZ2lvbl92 YXJpYW50Lg0KDQpUaGVyZSBhcmUgZm91ciB3YXlzIHRoYXQgdGhlc2UgaW1wbGVtZW50YXRpb25z IG1heSByZWFjdCB0byBhIHRhZyBpbiB0aGUgZm9ybSAieHgtTGF0bi1DQyIuIEZpcnN0LCB0aGV5 IG1heSBmaW5kIHRoZSBsYW5ndWFnZSBhbmQgcmVnaW9uIGNvZGUgYW5kIGlnbm9yZSBpbnRlcnN0 aXRpYWwgc3VidGFncyAocHJvZHVjaW5nIHh4LUNDIGluIG91ciBleGFtcGxlKS4gU2Vjb25kLCB0 aGV5IG1heSBmaW5kIGFzIG1hbnkgc3VidGFncyBpbiBvcmRlciB1bnRpbCB0aGUgbWVldCBvbmUg dGhleSBkb24ndCByZWNvZ25pemUgKHByb2R1Y2luZyB4eCBpbiBvdXIgZXhhbXBsZSkuIFRoaXJk LCB0aGV5IG1heSByZWplY3QgdGhlIHdob2xlIHRhZyBhcyB1bnJlY29nbml6ZWQuIEZvdXJ0aCwg dGhleSBtYXkgYXNzaWduIHdyb25nIHZhbHVlcyB0byB0aGUgd3JvbmcgZmllbGRzICh3aGljaCBw cm9kdWNlcyB0aGUgc2FtZSByZXN1bHRzIGluIG1hbnkgd2F5cyBhcyBvcHRpb24gdGhlIHNlY29u ZCkuDQoNCkFueSBvZiB0aGVzZSBpcyBhIHZhbGlkIHJlYWN0aW9uLg0KDQpJdCBpcyBjZXJ0YWlu bHkgcG9zc2libGUgaW4gdGhlIEoyRUUgY2FzZSBmb3IgYSB1c2VyIHRvIHNldCB1cCBhbGwgb2Yg dGhlaXIgY29udGVudCBhbmQgcmVzb3VyY2UgYnVuZGxlcyB0byB3b3JrICJjb3JyZWN0bHkiIHdp dGggc2NyaXB0IHN1YnRhZ3MsIGJ1dCBpdCBpcyBzaWduaWZpY2FudCB3b3JrIHRvIGRvIHNvLiBJ biBhZGRpdGlvbiwgTG9jYWxlIG9iamVjdHMgY3JlYXRlZCB3aXRoIGEgc2NyaXB0IGluIGVpdGhl ciB0aGUgcmVnaW9uIG9yIHZhcmlhbnQgc2xvdCB3aWxsIG5vdCB3b3JrIGNvcnJlY3RseSBhbmQg cHJvYmFibHkgcmV0dXJuIHRoZSBkZWZhdWx0IGxhbmd1YWdlIGZvciB0aGUgcGFydGljdWxhciBj b25maWd1cmF0aW9uIG9yIEpSRS4gDQoNClRoaXMgaXMgbm90IGFuIGluc2lnbmlmaWNhbnQgcHJv YmxlbS4NCg0KSW4gZmFjdCwgaXJvbmljYWxseSwgSSBoYXZlIGEgZGVtbyBvZiB0aGlzIG9uIG15 IG93biB3ZWJzaXRlIGhlcmU6DQoNCmh0dHA6Ly93d3cuaW50ZXItbG9jYWxlLmNvbS9Mb2NhbGVz RGVtby5qc3ANCg0KT25seS4uLiBJIHdyb3RlIHRoZSBBY2NlcHRMYW5ndWFnZUJlYW4gY2xhc3Mg dGhhdCBwb3dlcnMgdGhpcyBkZW1vIGFyb3VuZCBteSBSRkMgMzA2NmJpcyBpbXBsZW1lbnRhdGlv biBhbmQgaXQgZ2V0cyB0aGUgcmlnaHQgYW5zd2VyIGZvciAiemgtSGFudC1UVyIgKHRyeSBpdCB5 b3Vyc2VsZikuDQoNClNvIEkgd3JvdGUgb25lIHRoYXQgdXNlcyBwdXJlIEoyRUUgaGVyZToNCg0K aHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tL2Jpcy5qc3ANCg0KSXQgcHJvZHVjZXM6DQoNCkxh bmcgPSB6aA0KUmVnaW9uID0gSGFudA0KQ291bnRyeSA9IFRXDQoNClRoaXMgaXMgZXNzZW50aWFs bHkgdGhlIHNhbWUgdGhpbmcgYXMgc2F5aW5nICJ6aCIgaW4gdGVybXMgb2YgcmVzdWx0cy4NCg0K VGhlcmUgaXNuJ3QgbXVjaCB0aGF0IHdlIGNhbiB0ZWxsIHVzZXJzIHRvIGRvIHdpdGggdGhlaXIg Y29udGVudCB0YWdzIG9yIHJlcXVlc3RzIHRoYXQgd2lsbCBhbWVsaW9yYXRlIHRoaXMgbWlzbWF0 Y2gsIHNpbmNlIHRoZSBpbXBsZW1lbnRhdGlvbiBpcyB1c2luZyB2YWx1ZXMgaW4gdGhlIHN1YnRh Z3MgdG8gcGVyZm9ybSBzb21lIGtpbmQgb2YgbWFwcGluZyBvciBwcm9jZXNzaW5nLiANCg0KVGhp cyBwcm9ibGVtIChpbiB0aGlzIGV4YW1wbGUsIGJ1dCBub3QsIHBsZWFzZSBub3RlLCBhbGwgcG9z c2libGUgZXhhbXBsZXMpIGNvdWxkIGJlIGFkZHJlc3NlZCBieSBtb3ZpbmcgdGhlIHNjcmlwdCBz dWJ0YWcgZG93biBpbiB0aGUgb3JkZXIuDQoNClRoZSBwcm9ibGVtIGlzIHRoZSBtaXNtYXRjaCBi ZXR3ZWVuIFJGQyAyNjE2IG1hdGNoaW5nJ3MgbmVlZHMgKHNlZSBNaXNoYSdzIGVtYWlsKSBhbmQg dGhpcyBKMkVFLXN0eWxlIG1hdGNoaW5nJ3MgbmVlZHMuIA0KDQpBZGRpc29uDQoNCkFkZGlzb24g UC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KaHR0 cDovL3d3dy5xdWVzdC5jb20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3Jl IFdvcmtpbmcgR3JvdXANCmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwNCg0KSW50ZXJu YXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4g DQoNCg0K --===============0801172277== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0801172277==-- From ltru-bounces@ietf.org Sat Apr 9 19:36:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17553; Sat, 9 Apr 2005 19:36:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKPeh-0003L6-1p; Sat, 09 Apr 2005 19:46:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPUn-0004YW-06; Sat, 09 Apr 2005 19:36:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPUl-0004YB-Be for ltru@megatron.ietf.org; Sat, 09 Apr 2005 19:36:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17459 for ; Sat, 9 Apr 2005 19:36:04 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKPdo-0003H1-6A for ltru@ietf.org; Sat, 09 Apr 2005 19:45:29 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKPTz-0007eU-NR; Sat, 09 Apr 2005 16:35:20 -0700 Message-Id: <6.1.2.0.2.20050409235702.03856e60@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 00:10:37 +0200 To: "Randy Presuhn" , From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #881] remove registrant information from registry In-Reply-To: <006701c53d36$facb8f60$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0AEF0337@irvmbxw01.quest.com> <077001c53cd2$9d1bca10$be733009@sanjose.ibm.com> <6.1.2.0.2.20050409131859.03dbceb0@mail.jefsey.com> <006701c53d36$facb8f60$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb ???? I beg your pardon???? I enter a new point at 18:55 my time. And next I come I discover that at 21:04 my time the very same day ..... At 21:04 09/04/2005, Randy Presuhn wrote: >I've change the subject line so Jefsey's comments are included in the >correct thread. 1. you have change the threat to another which has no relation since you relate it to "removing registrant information from registry" when I follow on another threat discussed by both authors, and I discuss a new text of them and new points which are: - to use a new concept of proponent rather than a registrant - to not enter the proponent name in the registry - the necessary clarity of the first registration - how to address possible CIO problems for the Reviewer 2. and that: >(Co-chair hat ON) >I marked this issue "rejected" because it has found no support in the WG >from anyone other than you, its originator. in 2 hours and 9 minutes.... >That status will not change back to "open" unless there is broader support >for re-opening the issue. Nonetheless, you are welcome to continue >to try to make a case for re-opening it. I am glad of that! jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 19:37:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17578; Sat, 9 Apr 2005 19:37:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKPfC-0003LE-K8; Sat, 09 Apr 2005 19:46:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPUs-0004ZE-47; Sat, 09 Apr 2005 19:36:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPUm-0004YM-N5 for ltru@megatron.ietf.org; Sat, 09 Apr 2005 19:36:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17463 for ; Sat, 9 Apr 2005 19:36:05 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKPdq-0003Jc-Hh for ltru@ietf.org; Sat, 09 Apr 2005 19:45:30 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKPU7-0007eU-2H; Sat, 09 Apr 2005 16:35:27 -0700 Message-Id: <6.1.2.0.2.20050410012624.03b19ce0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 01:33:55 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Compatibility with existing use (LDAP) In-Reply-To: <001601c53d4e$6a5ab4c0$7f1afea9@oemcomputer> References: <1987416CA83AC7499AC772F92E2DBF78037C9AFC@LONSMSXM02.emea.ime.reuters.com> <001601c53d4e$6a5ab4c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Dear Randy, what you propose here has a name: flexibility. And flexibility is a requirement for scalability. Why I disagree with the initial approach of this WG is because we did not start in considering the Charter, what it wanted and what it permited to discuss to provide the best and most generalized response. I think that what you suggest is exactly what the Charter should lead us to. 1. to help users to use ISO standards and any other one or private proposition they may have to best understand each others 2. to propose a framework for every alternative - including APMD format - to be precisely documented, adequately supported, used as required and fully understood. Cheers! jfc At 23:52 09/04/2005, Randy Presuhn wrote: >Hi - > >As a technical contributor, the longer this thread goes on >the more consideration I think we should give to alternatives like >http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt > >If we were to treat the identification of the language(variant), >the script, and the orthography of a text as three distinct >attributes, rather than trying to structure them into a single string >called a "language tag" would it ultimately make things simpler >or more complicated? > >I find this approach intuitively appealing in the case where there are >multiple orthographic alternatives in the same script for a >given language, yet it has no impact at all on texts in languages >where identification of the script or orthography in use is of >no particular interest. Even transcriptions and transliterations can >be handled nicely into this kind of approach, since they just become >orthographic alternatives. > >It would, however, require a re-thinking of how we've handled >German and Chinese. > >Randy > > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 19:37:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17603; Sat, 9 Apr 2005 19:37:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKPfg-0003LP-Fy; Sat, 09 Apr 2005 19:47:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPUQ-0004XR-Sr; Sat, 09 Apr 2005 19:35:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPUP-0004XM-04 for ltru@megatron.ietf.org; Sat, 09 Apr 2005 19:35:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17406 for ; Sat, 9 Apr 2005 19:35:42 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKPdS-0003DG-Qv for ltru@ietf.org; Sat, 09 Apr 2005 19:45:07 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKPU3-0007eU-64; Sat, 09 Apr 2005 16:35:23 -0700 Message-Id: <6.1.2.0.2.20050410005620.03ce5c40@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 01:01:26 +0200 To: Misha Wolf , LTRU Working Group From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Compatibility with existing use (LDAP) In-Reply-To: <1987416CA83AC7499AC772F92E2DBF78037C9AFC@LONSMSXM02.emea.i me.reuters.com> References: <1987416CA83AC7499AC772F92E2DBF78037C9AFC@LONSMSXM02.emea.ime.reuters.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Misha, I think you should be clearer. With real ISO 3166 codes. What you really discuss is for an LDAP meta-database on Chinese speaking web sites to enter: zh-Hant-tw or zh-tw-Hant zh-Hant-cn or zn-cn-Hant zh-Hant-sg or zn-sh-Hant etc... ? And CN people to querry that database?? jfc At 23:05 09/04/2005, Misha Wolf wrote: >Ira McDonald wrote: > > > If script tags SHOULD be rare in use, then it's no burden for > > them to occupy the third position, rather than the second. > >I cannot imagine what mental model you have of *why* a >script or a country should be included in a language tag. > >Consider "zh". And consider the *very* large number of >people wanting to tag their text as, or look for text in, >either Traditional or Simplified Chinese. Are you serious >in arguing that they should have to inject a country code >between "zh" and the "Hant" or "Hans"? > >Let's see: The person requesting a resource will have to >specify a list of languages, of the form zh-C1-Hant, >zh-C2-Hant, zh-C3-Hant, in order to obtain all resources in >Traditional Chinese. > >And what do you expect the person tagging a resource to do? >In general, they don't have the possibility of using multiple >tags (zh-C1-Hant, zh-C2-Hant, zh-C3-Hant) to describe their >resource. So what should they do? If they choose just one, >eg zh-C2-Hant, then requestors specifying either zh-C1-Hant >or zh-C3-Hant will not get the resource. > >I feel that those who advocate the ll-CC-Scipt approach are >simply sticking their heads in the sand and refusing to >engage with reality. > > > Semi-OT - the inclusion of script tags in language tags breaks > > utterly the utility of presenting language choices to users in > > GUIs as country-flag icons - the script differences would be > > invisible. > >I can't imagine how you can seek to portray something so >daft as being a reasonable practice. > >Misha > > > > >----------------------------------------------------------------- > Visit our Internet site at http://www.reuters.com > >To find out more about Reuters Products and Services visit >http://www.reuters.com/productinfo > >Any views expressed in this message are those of the individual >sender, except where the sender specifically states them to be >the views of Reuters Ltd. > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 19:38:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17624; Sat, 9 Apr 2005 19:38:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKPg6-0003LX-6f; Sat, 09 Apr 2005 19:47:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPUe-0004Xs-9l; Sat, 09 Apr 2005 19:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPUd-0004Xn-2Q for ltru@megatron.ietf.org; Sat, 09 Apr 2005 19:35:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17429 for ; Sat, 9 Apr 2005 19:35:56 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKPdg-0003DW-D3 for ltru@ietf.org; Sat, 09 Apr 2005 19:45:20 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKPU1-0007eU-Uv; Sat, 09 Apr 2005 16:35:22 -0700 Message-Id: <6.1.2.0.2.20050410002727.03caf010@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 01:34:53 +0200 To: "Randy Presuhn" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] language or price tag ? In-Reply-To: <007801c53d3a$12c31720$7f1afea9@oemcomputer> References: <6.1.2.0.2.20050409184008.03cda230@pop.online.fr> <007801c53d3a$12c31720$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 On 21:26 09/04/2005, Randy Presuhn said: >Hi - > > > From: "Jefsey Morfin" > > To: "ltru Working Group" > > Sent: Saturday, April 09, 2005 9:44 AM > > Subject: [Ltru] language or price tag ? > > > > > http://www.dailypress.net/letters/story/046202005_let01-l0406.asp > > This type of consideration is exactly the kind of problem we all face and > > that langtags should participate into the resolution. > > jfc >... > >I find this puzzling. The letter in question advocates the adoption of >an official national language in the US, and uses the cost of supporting >multilingual access as justification. Are you proposing that the WG's >members should somehow lobby to rescind corresponding laws >in countries that have designated certain languages as "official"? >That would be *far* outside our charter. Shhhhh... Please read my comment. Am I not clear enough in saying that such considerations are precisely the problem we face? And we should bring another solution to. I advocate that such problems we all face (reality) should be addressed by techies more cleverly than in using ISO 3166 political divisions as language divisions; and that the cost reduction permited by a computer supported granular multilinguism and the legal aspects permitted by a less "prototype" and more multilingual internet architecture would allow politics to search, experiment and adopt more clever solutions. Our charter is not to rebuild the world (as some seems to want it), but to better adapt to and serve the world the way it is, to permit laws to be more adapted, and cost lower for better services to the people. The internet is the multilingual network of the multilingual people by the multilingual people. Our role is not to serve our egoes or RFCs, but to make it work, to make it work well, to make it work cheap and to make it work now. There is no doubt that whatever the result, this WG will have a price tag for the world. I only hope it can be as low or as negative (for a cost) as possible. When ICANN responded its brillantly obscure press release to the mobile telephone industry and its still more confuse response to MINC, Verisign and i-DNs on multilingual DNs both in summer 2000, an evaluation has been carried by a Canadian cabinet, about the resulting cost of just not understanding them and of the consequences, to 5 and 10 millions of $. Obviously the impact of langtags will be much more. One way or another. IMHO in the billion range over the years. But I am not the only one having figured that out. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 19:38:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17659; Sat, 9 Apr 2005 19:38:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKPgc-0003Lz-8T; Sat, 09 Apr 2005 19:48:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPUj-0004Y7-FB; Sat, 09 Apr 2005 19:36:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPUf-0004Xw-0e for ltru@megatron.ietf.org; Sat, 09 Apr 2005 19:36:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17449 for ; Sat, 9 Apr 2005 19:35:58 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKPdi-0003Dc-Om for ltru@ietf.org; Sat, 09 Apr 2005 19:45:23 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKPU4-0007eU-CG; Sat, 09 Apr 2005 16:35:24 -0700 Message-Id: <6.1.2.0.2.20050410010223.03cb9b10@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 01:07:22 +0200 To: "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: registry should copy non-English fields fromISOdocuments In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AFA3A95@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A95@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 On 23:24 09/04/2005, Addison Phillips said: >This is an open list. If the world cares to hum, we will hear it from here >(and no where else). There is no other way to form or judge consensus: how >else will IETF standards get done? If there are objections then >individuals will have to make them known so that they can be considered. This is what I just do. Oh! you want me to call upon friends to "vote" in here? No problem, but we may then have a worse problem of load. Consensus rules are precisely what permits to avoid that kind of stupid blocking. jfc >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >Chair, W3C Internationalization Core Working Group > >Internationalization is not a feature. >It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of JFC (Jefsey) Morfin > > Sent: samedi 9 avril 2005 07:53 > > To: Peter Constable > > Cc: ltru Working Group > > Subject: RE: [Ltru] Re: registry should copy non-English fields > > fromISOdocuments > > > > On 14:04 09/04/2005, Peter Constable said: > > >I believe if you are the only one on this list not in agreement, that we > > >have a consensus. > > > > True. But you have not if I am in disagreement. And I am in disagreement. > > But the real point is this is not because that this list humms something > > that the world will consent. > > I tend to think we should listen to the world rather than expect the world > > will want to listen to us. > > Not just to study it? > > jfc > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 20:08:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18589; Sat, 9 Apr 2005 20:08:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKQ8w-0004aV-AE; Sat, 09 Apr 2005 20:17:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPzc-0000ci-OE; Sat, 09 Apr 2005 20:08:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPza-0000cd-Ms for ltru@megatron.ietf.org; Sat, 09 Apr 2005 20:07:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18575 for ; Sat, 9 Apr 2005 20:07:55 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKQ8e-0004aE-N1 for ltru@ietf.org; Sat, 09 Apr 2005 20:17:21 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKPzW-0002Te-OD; Sat, 09 Apr 2005 17:07:57 -0700 Message-Id: <6.1.2.0.2.20050410013833.03f10490@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 02:07:29 +0200 To: "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] seeking resolution of the Great Script Debate In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AFA3A97@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A97@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Addison, I may be dumb stupid. But I see that you honnestly document a problem which results from a change in the format of the entry in a function. I have some difficulty understanding why do you want to do that? What you document is that the current functions work well with the current tags. But if you change them to work well with the new tags, they will not to work well anymore with old tags what seems to make sense. Why not just to do as Jesus said: to have new functions for new tags and to keep old functions for old tags? Is this a very big problem for W3C to say that xml:lang will keep using the old tags format and that xml:nlang will use a new format built from experience? Since you say libraries will have to be updated and no one is using yet your new format, the update would only to add nlangtag support to existing langtag support? By the same token you could also announce the support of xml:xlang to support the extended language tag we need. Question (I am not at all an XML person): - would this be a big problem if the xml:*lang tag was an URL? - would this be a big problem if the language parameters were documented in another more extended way? jfc On 00:20 10/04/2005, Addison Phillips said: >content-class: urn:content-classes:message >Content-Type: text/plain; > charset="utf-8" > >It seems to me that in order to achieve a resolution of this issue, we >need to take a step back and look concretely at the problem. > >This message is going to be somewhat long, since I'm going to look at both >sides of the problem in detail. > >Let's start with the compatibility problem. The claim of Ned, Ira, and >others is that 3066bis "breaks" existing implementations. I think that >word "breaks" is problematic, because it does not describe accurately what >happens. No implementations actually crash when you send them tags that >they don't recognize (those that do are beyond consideration here). What >we mean is that the results produced are either not what the user expected >or are different than what the user previously received for the same request. > >There are two kinds of implementation that we've been holding up for >examination. I'll take them in turns. > >First are pure RFC 2616 matching implementations which don't care about >the contents of a particular subtag. This is equivalent to what 3066bis >calls a "well-formed" processor. Common examples of these include >xml:lang, CSS 2.1, Apache's language negotiation mechanism and Kurt's LDAP >RFC. In these implementations, it doesn't matter if you send them a tag >like "foo-bar-baz-gleep" or "zh-Hant-CN". All that matters is the matching >of each token or subtag in order. > >For these implementations, script subtags pose a problem if they are >inconsistently used for a given language prefix. That is, if I sometimes >request "xx-Latn-CC" and sometimes request "xx-CC" or if I sometimes tag >content using "xx-Latn-CC" and sometimes as "xx-CC", then I will >experience problems with matching the "xx-Latn" prefix to "xx-CC" and vice >versa. The approach 3066bis takes here is to suggest that content authors >and requesters be systematic in using or not using script subtags. > >Let us pause and recognize that there are many implementations of this >nature and also recognize that this is not by any means "all" >implementations either. > >Second are the kinds of implementations Ned Freed has described, which DO >care about the contents of specific subtags. In an RFC 3066bis >implementation, these are validating processors. A well-known example that >I'll use as a proof-of-concept is the ServletRequest.getLocale method of >J2EE. This method takes Accept-language tags in the HTTP header and >attempts to match them to java.util.Locale objects predefined in the Java >runtime environment. There are roughly 150 of these in a JRE (less, >usually, and the number varies by JRE) in the form language_region_variant. > >There are four ways that these implementations may react to a tag in the >form "xx-Latn-CC". First, they may find the language and region code and >ignore interstitial subtags (producing xx-CC in our example). Second, they >may find as many subtags in order until the meet one they don't recognize >(producing xx in our example). Third, they may reject the whole tag as >unrecognized. Fourth, they may assign wrong values to the wrong fields >(which produces the same results in many ways as option the second). > >Any of these is a valid reaction. > >It is certainly possible in the J2EE case for a user to set up all of >their content and resource bundles to work "correctly" with script >subtags, but it is significant work to do so. In addition, Locale objects >created with a script in either the region or variant slot will not work >correctly and probably return the default language for the particular >configuration or JRE. > >This is not an insignificant problem. > >In fact, ironically, I have a demo of this on my own website here: > >http://www.inter-locale.com/LocalesDemo.jsp > >Only... I wrote the AcceptLanguageBean class that powers this demo around >my RFC 3066bis implementation and it gets the right answer for >"zh-Hant-TW" (try it yourself). > >So I wrote one that uses pure J2EE here: > >http://www.inter-locale.com/bis.jsp > >It produces: > >Lang = zh >Region = Hant >Country = TW > >This is essentially the same thing as saying "zh" in terms of results. > >There isn't much that we can tell users to do with their content tags or >requests that will ameliorate this mismatch, since the implementation is >using values in the subtags to perform some kind of mapping or processing. > >This problem (in this example, but not, please note, all possible >examples) could be addressed by moving the script subtag down in the order. > >The problem is the mismatch between RFC 2616 matching's needs (see Misha's >email) and this J2EE-style matching's needs. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >http://www.quest.com > >Chair, W3C Internationalization Core Working Group >http://www.w3.org/International > >Internationalization is not a feature. >It is an architecture. > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 20:27:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17660; Sat, 9 Apr 2005 19:38:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKPgc-0003Ly-7F; Sat, 09 Apr 2005 19:48:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPUZ-0004Xg-3D; Sat, 09 Apr 2005 19:35:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKPUW-0004XY-LS for ltru@megatron.ietf.org; Sat, 09 Apr 2005 19:35:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17409 for ; Sat, 9 Apr 2005 19:35:49 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKPda-0003DN-DK for ltru@ietf.org; Sat, 09 Apr 2005 19:45:14 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKPU5-0007eU-Hu; Sat, 09 Apr 2005 16:35:26 -0700 Message-Id: <6.1.2.0.2.20050410010816.03ca8740@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 01:18:14 +0200 To: "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Question about some draft text. In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AFA3A94@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A94@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA17409 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable On 23:24 09/04/2005, Addison Phillips said: >See inline. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org= ] On > > Behalf Of JFC (Jefsey) Morfin > > On 09:02 09/04/2005, Mark Davis said: > > >I agree. > > >=E2EURZMark > > I agree on the modification. > > > > I disagree on: > > > > - the decision by the reviewer to accept. It should be "to refuse", > > decision being "yes" by default. Otherwise we may have CIOs, we have = a >[Addison Phillips] > >The reviewer makes a statement about whether consensus has or has not be= en=20 >reached. Lack of consensus is "no". The reviewer does NOT decide about t= he=20 >registration personally, they only make the judgment call on group conse= nsus.* I fully understand that. I say that lack of consensus should be "yes". If something is dumb stupid there will be a consensus against it. If something is controverted there will be no consensus for it. The targe= t=20 is not to have a non disputed list. The target is to permit people to use= =20 the list. >There are many registered tags today that the current reviewer did not=20 >personally agree with. When there was a consensus _against_ Michael's opinion? I believe you but= I=20 would be glad to know one, just about a script for example. > > complex non documented procedure of relations with ISO (and only the = ISO > > case is quoted), we have no formal complete denial documentation to a= ppeal > > (a new request may result in a new refusal). 15 days are enough for > > experts > > to say "this is inconsistent" or "should be reworded" and to document= it > > to > > the reviewer, and then for the reviewer to document her decision (sam= e > > work) - could be 15 extra days to issue a statement. Less hassel and > > maximum delays instead of minimum delays. > > > > - the extra wheight given to the initial registrant. For many practic= al > > reasons. First the initial registrant can be dead, what puts some > > languages >[Addison Phillips] >Read my text carefully. It says: > > > > normally objections by the original registrant will > > > > carry extra weight in forming such a consensus. > >Which is different than what RFC 3066 says. RFC 3066 actually gave extra= =20 >weight to the original registrant by rule. My text says that their voice= =20 >will probably be influential. There is a world of difference in that. I noted it. But, this still gives exta weight where there should be none. > > in a different positions. Then it gives the registrant some kind of r= igt > > on > > a language what is not acceptable. But mostly it implies that the > > registration may be not clear enough to everyone to need an additiona= l > > comment. This is a standardization process, the name and the organiza= tion > > of the initial proponent should be forgotten. > > > > - no single one can "register" a language of many, we should use t= he > > term "proponent" >[Addison Phillips] > >I disagree. Your priviledge. As is mine to disagree to your disagreement. > > - the registration should not be deemed to be made by the proponen= t but > > by the ietf-languages@iana.org list. >[Addison Phillips] > >The registration is not "made by" the registrant. But we track who=20 >requested it. What for? What counts in a network is not the way the network was built b= ut=20 the way its users believe it should be used. Basic law. > > - the registered data should be all what is ever needed. >[Addison Phillips] > >No kidding? Is there something we are not requesting that should be? >The registered data fills in the registry entry. Of course, others may=20 >register additional comments, prefixes, etc. etc. in the record over tim= e. I mean that the all what is ever needed in an entry is what is entered.=20 Additional comments, prefixes, etc. etc. should never be subject to=20 something which was not previously entered. Comments by who ever proposed= =20 or commented before are not to be considered. If they should, they should= =20 have been entered. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 20:53:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20782; Sat, 9 Apr 2005 20:53:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKQqf-0006YA-DP; Sat, 09 Apr 2005 21:02:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKQhE-0006re-Mz; Sat, 09 Apr 2005 20:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKQhB-0006rZ-N1 for ltru@megatron.ietf.org; Sat, 09 Apr 2005 20:53:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20763 for ; Sat, 9 Apr 2005 20:53:00 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKQqF-0006Xs-PJ for ltru@ietf.org; Sat, 09 Apr 2005 21:02:24 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 9 Apr 2005 17:52:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] seeking resolution of the Great Script Debate Date: Sat, 9 Apr 2005 17:52:49 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@irvmbxw01.quest.com> Thread-Topic: [Ltru] seeking resolution of the Great Script Debate Thread-Index: AcU9YVrsQSjd1Kr/RgGUwQD3J3uBXAAAlNYg From: "Addison Phillips" To: "JFC (Jefsey) Morfin" X-OriginalArrivalTime: 10 Apr 2005 00:52:49.0410 (UTC) FILETIME=[9E255620:01C53D67] X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Content-Transfer-Encoding: quoted-printable Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Content-Transfer-Encoding: quoted-printable In a word: yes, it would be a HORRIBLE problem to have two different = language tags in the same document that do the same thing. And it isn't = possible for XML and its relatives to adopt another scheme anyway. = Language tags in W3C document formats must be compatible with xml:lang = (meaning RFC 3066's 1*8ALPHANUM *["-" 1*8 ALPHANUM]) or they will be a = failure before they even start. I am getting to writing the email in which I demonstrate that the issue = I document isn't so large as I made it appear. You'll have to wait for = Monday for that one. The reason that XML and CSS and other document formats don't go off and = ignore 3066 in favor of an improved scheme is the same reason Randy's = suggest that we create a bunch of orthogonal headers is a bad one. = Tagging content with language becomes balkanized. Users must create both = new attributes in their documents and new headers in the transmission = formats and populate both and keep the various bits synchronized. = Further more, headers in HTTP (for example) refer to tags in document = formats such as XHTML. These items necessarily refer to one another.=20 There is no need for this confusion to take place. Language tags are = extensible in many ways without breaking most RFC 3066 implementations = (and only harming the remaining 3066 implementations in very specific, = relatively benign ways---but again, you have to wait for Monday for why = I think it's benign). Some more below. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > Sent: samedi 9 avril 2005 17:07 > To: Addison Phillips > Cc: ltru Working Group > Subject: Re: [Ltru] seeking resolution of the Great Script Debate >=20 > Addison, > I may be dumb stupid. But I see that you honnestly document a problem > which > results from a change in the format of the entry in a function. I have > some > difficulty understanding why do you want to do that?=20 [Addison Phillips]=20 Because the first step in gaining support for consensus compromise is = documenting both sides honestly. If I show that I acknowledge and = understand issues raised by Ned, et al, then it is likely that they'll = not be feeling attacked while I discuss why I think our solution is the = best one available and why I think that the situation is not so dire. What you document is > that the current functions work well with the current tags. But if you > change them to work well with the new tags, they will not to work well > anymore with old tags what seems to make sense. [Addison Phillips]=20 No, I did NOT document that. Old tags work perfectly with new = processors. Every time. The new (3066bis) processors are much better = than the old ones when dealing with and detecting corner cases. The problem is that some old processors that "look inside" tags and = expect (wrongly in the case of J2EE: notice that J2EE doesn't even LOOK = at the value it crams into the region code) that a specific position = maps to a specific value creating a situation in which slightly or = mostly wrong content is supplied in response to a request. Send "i-klingon" to J2EE and you get language "I" and region "Klingon". = Bad stupid. Thankfully, that locale matches the nearest actual locale in Java = supporting that tag--which is the empty locale! In Java the request "xx-ssss-cc" would match the actual locale "xx" = instead of the locale "xx-CC" when "xx" is a supported language. Bad, = but not completely stupid. >=20 > Why not just to do as Jesus said: to have new functions for new tags = and > to > keep old functions for old tags? Is this a very big problem for W3C to = say > that xml:lang will keep using the old tags format and that xml:nlang = will > use a new format built from experience? Since you say libraries will = have > to be updated and no one is using yet your new format, the update = would > only to add nlangtag support to existing langtag support? By the same > token > you could also announce the support of xml:xlang to support the = extended > language tag we need. [Addison Phillips]=20 XML doesn't *need* or *want* two ways to identify language. Furthermore, = it can't GET a new built in attribute that uses a URL or any other = format (see: "the huge success of XML 1.1"). Language tags in W3C = document formats will be 3066-compatible tags for essentially forever. Locale identifiers for Web services can be URLs and may very well be. = But they are orthogonal to this discussion. >=20 > Question (I am not at all an XML person): > - would this be a big problem if the xml:*lang tag was an URL? [Addison Phillips]=20 See above. > - would this be a big problem if the language parameters were = documented > in > another more extended way? [Addison Phillips]=20 Yes. How may XML implementations are there already? Count all = technologies that use XML in them. It is not possible for it to be = adopted. There is a firm requirement for a compatible scheme. > jfc >=20 >=20 > On 00:20 10/04/2005, Addison Phillips said: > >content-class: urn:content-classes:message > >Content-Type: text/plain; > > charset=3D"utf-8" > > > >It seems to me that in order to achieve a resolution of this issue, = we > >need to take a step back and look concretely at the problem. > > > >This message is going to be somewhat long, since I'm going to look at > both > >sides of the problem in detail. > > > >Let's start with the compatibility problem. The claim of Ned, Ira, = and > >others is that 3066bis "breaks" existing implementations. I think = that > >word "breaks" is problematic, because it does not describe accurately > what > >happens. No implementations actually crash when you send them tags = that > >they don't recognize (those that do are beyond consideration here). = What > >we mean is that the results produced are either not what the user > expected > >or are different than what the user previously received for the same > request. > > > >There are two kinds of implementation that we've been holding up for > >examination. I'll take them in turns. > > > >First are pure RFC 2616 matching implementations which don't care = about > >the contents of a particular subtag. This is equivalent to what = 3066bis > >calls a "well-formed" processor. Common examples of these include > >xml:lang, CSS 2.1, Apache's language negotiation mechanism and Kurt's > LDAP > >RFC. In these implementations, it doesn't matter if you send them a = tag > >like "foo-bar-baz-gleep" or "zh-Hant-CN". All that matters is the > matching > >of each token or subtag in order. > > > >For these implementations, script subtags pose a problem if they are > >inconsistently used for a given language prefix. That is, if I = sometimes > >request "xx-Latn-CC" and sometimes request "xx-CC" or if I sometimes = tag > >content using "xx-Latn-CC" and sometimes as "xx-CC", then I will > >experience problems with matching the "xx-Latn" prefix to "xx-CC" and > vice > >versa. The approach 3066bis takes here is to suggest that content = authors > >and requesters be systematic in using or not using script subtags. > > > >Let us pause and recognize that there are many implementations of = this > >nature and also recognize that this is not by any means "all" > >implementations either. > > > >Second are the kinds of implementations Ned Freed has described, = which DO > >care about the contents of specific subtags. In an RFC 3066bis > >implementation, these are validating processors. A well-known example > that > >I'll use as a proof-of-concept is the ServletRequest.getLocale method = of > >J2EE. This method takes Accept-language tags in the HTTP header and > >attempts to match them to java.util.Locale objects predefined in the = Java > >runtime environment. There are roughly 150 of these in a JRE (less, > >usually, and the number varies by JRE) in the form > language_region_variant. > > > >There are four ways that these implementations may react to a tag in = the > >form "xx-Latn-CC". First, they may find the language and region code = and > >ignore interstitial subtags (producing xx-CC in our example). Second, > they > >may find as many subtags in order until the meet one they don't = recognize > >(producing xx in our example). Third, they may reject the whole tag = as > >unrecognized. Fourth, they may assign wrong values to the wrong = fields > >(which produces the same results in many ways as option the second). > > > >Any of these is a valid reaction. > > > >It is certainly possible in the J2EE case for a user to set up all of > >their content and resource bundles to work "correctly" with script > >subtags, but it is significant work to do so. In addition, Locale = objects > >created with a script in either the region or variant slot will not = work > >correctly and probably return the default language for the particular > >configuration or JRE. > > > >This is not an insignificant problem. > > > >In fact, ironically, I have a demo of this on my own website here: > > > >http://www.inter-locale.com/LocalesDemo.jsp > > > >Only... I wrote the AcceptLanguageBean class that powers this demo = around > >my RFC 3066bis implementation and it gets the right answer for > >"zh-Hant-TW" (try it yourself). > > > >So I wrote one that uses pure J2EE here: > > > >http://www.inter-locale.com/bis.jsp > > > >It produces: > > > >Lang =3D zh > >Region =3D Hant > >Country =3D TW > > > >This is essentially the same thing as saying "zh" in terms of = results. > > > >There isn't much that we can tell users to do with their content tags = or > >requests that will ameliorate this mismatch, since the implementation = is > >using values in the subtags to perform some kind of mapping or = processing. > > > >This problem (in this example, but not, please note, all possible > >examples) could be addressed by moving the script subtag down in the > order. > > > >The problem is the mismatch between RFC 2616 matching's needs (see > Misha's > >email) and this J2EE-style matching's needs. > > > >Addison > > > >Addison P. Phillips > >Globalization Architect, Quest Software > >http://www.quest.com > > > >Chair, W3C Internationalization Core Working Group > >http://www.w3.org/International > > > >Internationalization is not a feature. > >It is an architecture. > > > >_______________________________________________ > >Ltru mailing list > >Ltru@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 22:11:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23863; Sat, 9 Apr 2005 22:11:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKS4O-0001VW-19; Sat, 09 Apr 2005 22:21:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKRuX-0008WO-Qs; Sat, 09 Apr 2005 22:10:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKRuV-0008WJ-RJ for ltru@megatron.ietf.org; Sat, 09 Apr 2005 22:10:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23838 for ; Sat, 9 Apr 2005 22:10:50 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKS3a-0001VC-KQ for ltru@ietf.org; Sat, 09 Apr 2005 22:20:15 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMVSY94CM800005R@mauve.mrochek.com> for ltru@ietf.org; Sat, 09 Apr 2005 19:10:46 -0700 (PDT) Date: Sat, 09 Apr 2005 18:44:30 -0700 (PDT) In-reply-to: "Your message dated Sat, 09 Apr 2005 14:52:24 -0700" <001601c53d4e$6a5ab4c0$7f1afea9@oemcomputer> Message-id: <01LMWG2NCBKW00005R@mauve.mrochek.com> References: <1987416CA83AC7499AC772F92E2DBF78037C9AFC@LONSMSXM02.emea.ime.reuters.com> <001601c53d4e$6a5ab4c0$7f1afea9@oemcomputer> Subject: Re: [Ltru] Compatibility with existing use (LDAP) To: Randy Presuhn X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7BIT Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7BIT > As a technical contributor, the longer this thread goes on > the more consideration I think we should give to alternatives like > http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt > If we were to treat the identification of the language(variant), > the script, and the orthography of a text as three distinct > attributes, rather than trying to structure them into a single string > called a "language tag" would it ultimately make things simpler > or more complicated? > I find this approach intuitively appealing in the case where there are > multiple orthographic alternatives in the same script for a > given language, yet it has no impact at all on texts in languages > where identification of the script or orthography in use is of > no particular interest. Even transcriptions and transliterations can > be handled nicely into this kind of approach, since they just become > orthographic alternatives. > It would, however, require a re-thinking of how we've handled > German and Chinese. No doubt there's some appeal to this idea, but I don't think it's practical. The single biggest implementation problem I see right off is that language tags are used in lots of places, at least one of which is not amenable to the addition of separate script field. I'm referring, of course, to XML. I believe adding an xml:script field to go along with xml:lang could only be done with a major revision to the XML base specification. And even if such a change could be made, getting it deployed would be a real challenge. Other cases, like email, would be able to add a content-script: field much more easily, of course. Even so, a vast amount of code would have to be changed to actually make use of this new field. LDAP is another interesting case. Language tags in LDAP are actually a specific case of a more general mechanism. But AFAIK little use is made of attribute tags for purposes other than language tagging. This calls into question how general the mechanism actually implemented by various clients and servers actually is. And even if you were to get the field defined in every place where there's a field for language tags, you still have to actually make use of the field. Having two separate fields certainly makes it easy to recognize script tags and prevents them from causing problems in the language tag space, but you lose information relating language to scripts. For example, suppose you have: content-language: az, ru, en content-script: latn, cryl It stands to reason the Russian is written in cyrillic and the English in latin, but what script is the Azerbaijani text written in? Of course you could require a 1:1 correspondence between the entries in the two fields, but that would then require a way to indicate when the script is unknown. And tags would have to be repeated since a single script can apply to multiple languages or vice versa. Ick. This is _seriously_ ugly. And even if you ignore the ugly, the repetition of tags in language fields is certain to cause problems to existing software. So, much as I would like to eliminate the interop problems the current proposal for adding script codes causes, I really don't think this is a viable way to do it. Ned P.S. My linguistic skills are rudimentary at best, but my recollection is that Azerbaijani is a language that can be written in either cyrillic or latin script. If that's not the case please substitute a language where this is actually true in the above example. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 22:57:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25570; Sat, 9 Apr 2005 22:57:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKSmf-0003YN-LV; Sat, 09 Apr 2005 23:06:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKSdI-0005vO-EC; Sat, 09 Apr 2005 22:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKSdG-0005vE-Vc for ltru@megatron.ietf.org; Sat, 09 Apr 2005 22:57:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25556 for ; Sat, 9 Apr 2005 22:57:02 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKSmK-0003Vq-C0 for ltru@ietf.org; Sat, 09 Apr 2005 23:06:28 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKSdB-0002eO-Qm; Sat, 09 Apr 2005 19:57:03 -0700 Message-Id: <6.1.2.0.2.20050410030855.0471b3e0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 04:56:43 +0200 To: "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] seeking resolution of the Great Script Debate In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 On 02:52 10/04/2005, Addison Phillips said: >In a word: yes, it would be a HORRIBLE problem to have two different >language tags in the same document that do the same thing Dear Addison, Why two different language tags in the _same_ document? The choice would have been between the "xml:lang" and "xml:nlang"? But I will wait for Monday to understand. Yet, we need a context tag anyway, which will include the elements of the language tag since a context can much wider and necessarily includes the language elements. >And it isn't possible for XML and its relatives to adopt another scheme >anyway. Language tags in W3C document formats must be compatible with >xml:lang (meaning RFC 3066's 1*8ALPHANUM *["-" 1*8 ALPHANUM]) or they will >be a failure before they even start. Okay you know better what XML does. But beware that what we currently work on is to study and further on document a much much wider need (all what two interlocutors may think they share in common). We are not interested in any specific application, but in networking. But I suspect that XML users will want to use them. Right now we are interested first in ASN.1 to document formats under various systems including XML and our own Gositer multilingual exploratory system, and in convergence with other technologies (phone, MPEG, etc).One of the first issue is a universal numbering scheme permitting to access the context data directly through a stable IPv6 address. Just remember that we approach the networks in a user centric way, very pragmatic. The network of the people by the people technology. >I am getting to writing the email in which I demonstrate that the issue I >document isn't so large as I made it appear. You'll have to wait for >Monday for that one. No problem. Thank you. >The reason that XML and CSS and other document formats don't go off and >ignore 3066 in favor of an improved scheme is the same reason Randy's >suggest that we create a bunch of orthogonal headers is a bad one. Tagging >content with language becomes balkanized. Users must create both new >attributes in their documents and new headers in the transmission formats >and populate both and keep the various bits synchronized. Further more, >headers in HTTP (for example) refer to tags in document formats such as >XHTML. These items necessarily refer to one another. This is your area. Not mine. Mine is all this is to work on a network which cannot support all this without either balkanizing what we do not want, or drasticically enhance in seriously supporting classes and groups (not just a single "Internet" class and a pseudo Chaos class). I have no idea yet how an application will be able to take advantage from such an evolution. (When you started your RFC 3066 bis effort you interrupted my own effort to document how IETF could tackle the Multilingual Internet documentation: it started with the description of the request of IAB guidances on a certain numbers of key points). This is also why I am glad of the new IESG Chair, as his RFCs on the Internet architecture are clear, open and full of experience. >There is no need for this confusion to take place. Language tags are >extensible in many ways without breaking most RFC 3066 implementations >(and only harming the remaining 3066 implementations in very specific, >relatively benign ways---but again, you have to wait for Monday for why I >think it's benign). > >Some more below. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >Chair, W3C Internationalization Core Working Group > >Internationalization is not a feature. >It is an architecture. > > > -----Original Message----- > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > Sent: samedi 9 avril 2005 17:07 > > To: Addison Phillips > > Cc: ltru Working Group > > Subject: Re: [Ltru] seeking resolution of the Great Script Debate > > > > Addison, > > I may be dumb stupid. But I see that you honnestly document a problem > > which > > results from a change in the format of the entry in a function. I have > > some > > difficulty understanding why do you want to do that? >[Addison Phillips] > >Because the first step in gaining support for consensus compromise is >documenting both sides honestly. If I show that I acknowledge and >understand issues raised by Ned, et al, then it is likely that they'll not >be feeling attacked while I discuss why I think our solution is the best >one available and why I think that the situation is not so dire. My question was why do you want to enter a new format in an old function. But I appreciate all this as quite positive. >What you document is > > that the current functions work well with the current tags. But if you > > change them to work well with the new tags, they will not to work well > > anymore with old tags what seems to make sense. >[Addison Phillips] > >No, I did NOT document that. Old tags work perfectly with new processors. >Every time. The new (3066bis) processors are much better than the old ones >when dealing with and detecting corner cases. > >The problem is that some old processors that "look inside" tags and expect >(wrongly in the case of J2EE: notice that J2EE doesn't even LOOK at the >value it crams into the region code) that a specific position maps to a >specific value creating a situation in which slightly or mostly wrong >content is supplied in response to a request. > >Send "i-klingon" to J2EE and you get language "I" and region "Klingon". >Bad stupid. > >Thankfully, that locale matches the nearest actual locale in Java >supporting that tag--which is the empty locale! > >In Java the request "xx-ssss-cc" would match the actual locale "xx" >instead of the locale "xx-CC" when "xx" is a supported language. Bad, but >not completely stupid. Okay. XML, HTML and I suppose CLDR, at least are your show. > > Why not just to do as Jesus said: to have new functions for new tags and > > to > > keep old functions for old tags? Is this a very big problem for W3C to say > > that xml:lang will keep using the old tags format and that xml:nlang will > > use a new format built from experience? Since you say libraries will have > > to be updated and no one is using yet your new format, the update would > > only to add nlangtag support to existing langtag support? By the same > > token > > you could also announce the support of xml:xlang to support the extended > > language tag we need. >[Addison Phillips] > >XML doesn't *need* or *want* two ways to identify language. Furthermore, >it can't GET a new built in attribute that uses a URL or any other format >(see: "the huge success of XML 1.1"). Language tags in W3C document >formats will be 3066-compatible tags for essentially forever. Okay if you say so. Problem is that the format you propose 2/3 chars - 4 chars - 2 chars is not enough to support what we need. So we will need another system which will also identify languages. And that system may not directly use subtags to stay stable (cf. Charter). >Locale identifiers for Web services can be URLs and may very well be. But >they are orthogonal to this discussion. > > Question (I am not at all an XML person): > > - would this be a big problem if the xml:*lang tag was an URL? >[Addison Phillips] > >See above. > > > - would this be a big problem if the language parameters were documented > > in another more extended way? >[Addison Phillips] > >Yes. How may XML implementations are there already? Count all technologies >that use XML in them. It is not possible for it to be adopted. There is a >firm requirement for a compatible scheme. This is I suppose the main difference we have. I consider that langtags are the first building block of a Multilingual Internet. And that MI is a totally new network architecture (yet fully based upon and compatible with the ASCII Internet). So, there are three areas to consider: - where you need your langtags. You know where, I dont - and I do not fully understand what you do with them. - where one does not need your langtags (or not necessarily): you added web services to the list - good news as one of my main concern was OPES and web services interintelligibility. Are you considering Word processors etc. in the same case as XML or as Web Services? - where Multilingual Internet features may be considered/defined first to provide a stable, compact, open one shot container. I will carefully read your Monday explanation. Have a nice WE. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 9 22:58:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25597; Sat, 9 Apr 2005 22:58:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKSnZ-0003Yh-Sb; Sat, 09 Apr 2005 23:07:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKSdK-0005vS-IK; Sat, 09 Apr 2005 22:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKSdH-0005vJ-GM for ltru@megatron.ietf.org; Sat, 09 Apr 2005 22:57:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25562 for ; Sat, 9 Apr 2005 22:57:05 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKSmN-0003Y3-3I for ltru@ietf.org; Sat, 09 Apr 2005 23:06:31 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKSdF-0002eO-K5; Sat, 09 Apr 2005 19:57:06 -0700 Message-Id: <6.1.2.0.2.20050410044608.047d1a70@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 04:55:31 +0200 To: ned.freed@mrochek.com From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Compatibility with existing use (LDAP) In-Reply-To: <01LMWG2NCBKW00005R@mauve.mrochek.com> References: <1987416CA83AC7499AC772F92E2DBF78037C9AFC@LONSMSXM02.emea.ime.reuters.com> <001601c53d4e$6a5ab4c0$7f1afea9@oemcomputer> <01LMWG2NCBKW00005R@mauve.mrochek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Ned, you are most probably right about LDAP and Addison about XML. But this is not the case for _new_ services like OPES (open pluggable edge services: intelligence on the edge of the network, able to change the langtag of an XML page at will before it receives it) or my own long delayed ONES (open network extended services: intelligence (virtually in an end to end architecture) within the network we see coming back. This not true about the architectural solutions to support multilingualism. Even SMTP can be dramatically affected through the charter of the WG-OPES on SMTP support (even if we are quite delayed by the same problem as this WG: to understand how to support at the same time the past, the present and the future). jfc On 03:44 10/04/2005, ned.freed@mrochek.com said: > > As a technical contributor, the longer this thread goes on > > the more consideration I think we should give to alternatives like > > http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt > > > If we were to treat the identification of the language(variant), > > the script, and the orthography of a text as three distinct > > attributes, rather than trying to structure them into a single string > > called a "language tag" would it ultimately make things simpler > > or more complicated? > > > I find this approach intuitively appealing in the case where there are > > multiple orthographic alternatives in the same script for a > > given language, yet it has no impact at all on texts in languages > > where identification of the script or orthography in use is of > > no particular interest. Even transcriptions and transliterations can > > be handled nicely into this kind of approach, since they just become > > orthographic alternatives. > > > It would, however, require a re-thinking of how we've handled > > German and Chinese. > >No doubt there's some appeal to this idea, but I don't think it's practical. > >The single biggest implementation problem I see right off is that language >tags >are used in lots of places, at least one of which is not amenable to the >addition of separate script field. I'm referring, of course, to XML. I believe >adding an xml:script field to go along with xml:lang could only be done with a >major revision to the XML base specification. And even if such a change could >be made, getting it deployed would be a real challenge. > >Other cases, like email, would be able to add a content-script: field much >more >easily, of course. Even so, a vast amount of code would have to be changed to >actually make use of this new field. > >LDAP is another interesting case. Language tags in LDAP are actually a >specific >case of a more general mechanism. But AFAIK little use is made of attribute >tags for purposes other than language tagging. This calls into question how >general the mechanism actually implemented by various clients and servers >actually is. > >And even if you were to get the field defined in every place where there's a >field for language tags, you still have to actually make use of the field. >Having two separate fields certainly makes it easy to recognize script >tags and >prevents them from causing problems in the language tag space, but you lose >information relating language to scripts. For example, suppose you have: > > content-language: az, ru, en > content-script: latn, cryl > >It stands to reason the Russian is written in cyrillic and the English in >latin, but what script is the Azerbaijani text written in? > >Of course you could require a 1:1 correspondence between the entries in >the two >fields, but that would then require a way to indicate when the script is >unknown. And tags would have to be repeated since a single script can apply to >multiple languages or vice versa. Ick. This is _seriously_ ugly. And even if >you ignore the ugly, the repetition of tags in language fields is certain to >cause problems to existing software. > >So, much as I would like to eliminate the interop problems the current >proposal for adding script codes causes, I really don't think this is >a viable way to do it. > > Ned > >P.S. My linguistic skills are rudimentary at best, but my recollection is >that >Azerbaijani is a language that can be written in either cyrillic or latin >script. If that's not the case please substitute a language where this is >actually true in the above example. > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 02:48:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27650; Sun, 10 Apr 2005 02:48:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKWO0-0005U9-Ab; Sun, 10 Apr 2005 02:57:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKWEQ-0007M7-Dy; Sun, 10 Apr 2005 02:47:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKWEN-0007Lu-OR for ltru@megatron.ietf.org; Sun, 10 Apr 2005 02:47:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27629 for ; Sun, 10 Apr 2005 02:47:37 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKWNT-0005Nt-V3 for ltru@ietf.org; Sun, 10 Apr 2005 02:57:05 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3A6lSKG011719; Sun, 10 Apr 2005 02:47:28 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 10 Apr 2005 02:47:42 -0400 Date: Sun, 10 Apr 2005 02:47:41 -0400 From: John Cowan To: "McDonald, Ira" Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Message-ID: <20050410064741.GM24173@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.reutershealth.com id j3A6lSKG011719 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable McDonald, Ira scripsit: > John Cowan gave an example (level 2 Braille) where the script > tag definitely should be sorted AFTER the region tag. =20 My remark was rather more tentative than that. > If script tags SHOULD be rare in use, then it's no burden for > them to occupy the third position, rather than the second. Rare in practice does not mean unimportant in principle. > Semi-OT - the inclusion of script tags in language tags breaks > utterly the utility of presenting language choices to users in > GUIs as country-flag icons - the script differences would be > invisible. As I have said before, that practice is absurd. The proper icon for a language is its native name. --=20 Kill Gorg=FBn! Kill orc-folk! John Cowan No other words please Wild Men. jcowan@reutershealth.com Drive away bad air and darkness http://www.reutershealth.com with brig ht iron! --Gh=E2n-buri-Gh=E2n http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 03:02:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28153; Sun, 10 Apr 2005 03:02:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKWbw-000623-BW; Sun, 10 Apr 2005 03:12:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKWSm-0001Nx-Nv; Sun, 10 Apr 2005 03:02:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKWSk-0001Ls-QW for ltru@megatron.ietf.org; Sun, 10 Apr 2005 03:02:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28149 for ; Sun, 10 Apr 2005 03:02:29 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKWbs-00061y-Mi for ltru@ietf.org; Sun, 10 Apr 2005 03:11:56 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3A72Lgi011761; Sun, 10 Apr 2005 03:02:21 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 10 Apr 2005 03:02:29 -0400 Date: Sun, 10 Apr 2005 03:02:28 -0400 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] Compatibility with existing use (LDAP) Message-ID: <20050410070228.GO24173@skunk.reutershealth.com> References: <1987416CA83AC7499AC772F92E2DBF78037C9AFC@LONSMSXM02.emea.ime.reuters.com> <001601c53d4e$6a5ab4c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001601c53d4e$6a5ab4c0$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Randy Presuhn scripsit: > As a technical contributor, the longer this thread goes on > the more consideration I think we should give to alternatives like > http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt I have no difficulty with the use of this header in MIME and HTTP contexts. But it does not satisfy the general requirement for tagging documents outside any particular transport protocol or sub-protocol. Like it or not, langtags have a context wider than the IETF's core concerns with Internet protocols. Nor do I wish to see an environment in which some language tags are valid only in certain contexts whereas others are valid in other contexts. In general, assuming that out-of-band metadata will be correctly preserved in a heterogeneous environment is an idea that history has shown not to work very well. > If we were to treat the identification of the language(variant), > the script, and the orthography of a text as three distinct > attributes, rather than trying to structure them into a single string > called a "language tag" would it ultimately make things simpler > or more complicated? Things should be as simple as possible, but no more so. -- Values of beeta will give rise to dom! John Cowan (5th/6th edition 'mv' said this if you tried http://www.ccil.org/~cowan to rename '.' or '..' entries; see jcowan@reutershealth.com http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 03:36:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29751; Sun, 10 Apr 2005 03:36:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKX97-0007aD-NC; Sun, 10 Apr 2005 03:46:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKWyg-0006Gm-CY; Sun, 10 Apr 2005 03:35:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKWyd-0006Gh-Vl for ltru@megatron.ietf.org; Sun, 10 Apr 2005 03:35:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29676 for ; Sun, 10 Apr 2005 03:35:26 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKX7l-0007T4-14 for ltru@ietf.org; Sun, 10 Apr 2005 03:44:54 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3A7ZHGt011928; Sun, 10 Apr 2005 03:35:17 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 10 Apr 2005 03:35:17 -0400 Date: Sun, 10 Apr 2005 03:35:17 -0400 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] seeking resolution of the Great Script Debate Message-ID: <20050410073516.GQ24173@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A97@irvmbxw01.quest.com> <6.1.2.0.2.20050410013833.03f10490@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050410013833.03f10490@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 JFC (Jefsey) Morfin scripsit: > But if you change them to work well with the new tags, they will not to > work well anymore with old tags what seems to make sense. This is simply incorrect. -- You escaped them by the will-death John Cowan and the Way of the Black Wheel. jcowan@reutershealth.com I could not. --Great-Souled Sam http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 07:21:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10886; Sun, 10 Apr 2005 07:21:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKaeU-0003Ze-FB; Sun, 10 Apr 2005 07:30:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKaUk-00054L-TT; Sun, 10 Apr 2005 07:20:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKaUk-00054G-B4 for ltru@megatron.ietf.org; Sun, 10 Apr 2005 07:20:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10847 for ; Sun, 10 Apr 2005 07:20:47 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKadt-0003Vk-8e for ltru@ietf.org; Sun, 10 Apr 2005 07:30:18 -0400 Received: from lns-p19-8-idf-82-249-30-81.adsl.proxad.net ([82.249.30.81] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKaUg-0004IH-5h; Sun, 10 Apr 2005 04:20:46 -0700 Message-Id: <6.1.2.0.2.20050410112833.0d43f570@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 11:29:13 +0200 To: John Cowan From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Compatibility with existing use (LDAP) In-Reply-To: <20050410070228.GO24173@skunk.reutershealth.com> References: <1987416CA83AC7499AC772F92E2DBF78037C9AFC@LONSMSXM02.emea.ime.reuters.com> <001601c53d4e$6a5ab4c0$7f1afea9@oemcomputer> <20050410070228.GO24173@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 On 09:02 10/04/2005, John Cowan said: >I have no difficulty with the use of this header in MIME and HTTP >contexts. But it does not satisfy the general requirement for tagging >documents outside any particular transport protocol or sub-protocol. >Like it or not, langtags have a context wider than the IETF's core >concerns with Internet protocols. We are in agreement. This is why it is not adequate to specify them through an IETF WG and to try to impose them through the IANA without working on a global consensus. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 12:09:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29258; Sun, 10 Apr 2005 12:09:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKf9c-0004Hy-Bj; Sun, 10 Apr 2005 12:19:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKezx-0002F7-NW; Sun, 10 Apr 2005 12:09:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKezv-0002F2-Pt for ltru@megatron.ietf.org; Sun, 10 Apr 2005 12:09:20 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29233 for ; Sun, 10 Apr 2005 12:09:16 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DKex3-0003W4-GE for ltru@lists.ietf.org; Sun, 10 Apr 2005 18:06:21 +0200 Received: from 212.82.251.245 ([212.82.251.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 18:06:21 +0200 Received: from nobody by 212.82.251.245 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 18:06:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 10 Apr 2005 18:08:23 +0200 Organization: Lines: 7 Message-ID: <42594F77.4479@xyzzy.claranet.de> References: <1987416CA83AC7499AC772F92E2DBF78037C9AFC@LONSMSXM02.emea.ime.reuters.com> <001601c53d4e$6a5ab4c0$7f1afea9@oemcomputer> 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.245 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > It would, however, require a re-thinking of how we've handled > German and Chinese. AFAIK no problem with the grandfathered German tags, bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 12:48:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01668; Sun, 10 Apr 2005 12:48:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKfkg-0005W6-UC; Sun, 10 Apr 2005 12:57:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKfar-0007U3-6T; Sun, 10 Apr 2005 12:47:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKfap-0007Ty-PR for ltru@megatron.ietf.org; Sun, 10 Apr 2005 12:47:27 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01627 for ; Sun, 10 Apr 2005 12:47:24 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DKfY2-0007Ty-9g for ltru@lists.ietf.org; Sun, 10 Apr 2005 18:44:34 +0200 Received: from 212.82.251.245 ([212.82.251.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 18:44:34 +0200 Received: from nobody by 212.82.251.245 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 18:44:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 10 Apr 2005 18:45:54 +0200 Organization: Lines: 34 Message-ID: <42595842.175B@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@irvmbxw01.quest.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.245 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: seeking resolution of the Great Script Debate X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Addison Phillips wrote: > XML doesn't *need* or *want* two ways to identify language. But it has encoding and allows other meta-data, in the case of XHTML I could use something like... ...to define a script in addition to the old xml:lang= or lang= language. > it can't GET a new built in attribute that uses a URL or any > other format It also can't get a new built-in attribute for say the location - but it's simple to add this meta-data where needed. > (see: "the huge success of XML 1.1"). That's apparently a joke, without knowing what's going on I've almost started a flame-war on the xml2rfc list only because I dared (durst ?) test version="1.1". > Locale identifiers for Web services can be URLs and may very > well be. But they are orthogonal to this discussion. Why ? Maybe we should add scripts to the "charset" instead of the languages. Using Unicode everywhere caused this mess, so it's only fair if they fix it, charset="UTF-8-mainly-Latn" or whatever. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 13:14:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03064; Sun, 10 Apr 2005 13:14:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKg9p-0006Hx-Kl; Sun, 10 Apr 2005 13:23:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKfzj-0001l9-RZ; Sun, 10 Apr 2005 13:13:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKfzi-0001ky-VA for ltru@megatron.ietf.org; Sun, 10 Apr 2005 13:13:11 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03018 for ; Sun, 10 Apr 2005 13:13:07 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050410171239.CQCW5402.mta11.adelphia.net@DEWELL>; Sun, 10 Apr 2005 13:12:39 -0400 Message-ID: <004a01c53df0$786d46c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> Date: Sun, 10 Apr 2005 10:12: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 Content-Transfer-Encoding: 7bit Cc: Frank Ellermann Subject: [Ltru] Re: Comment: use VU for Vanuatu (was: remove region subtag 200) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > We've already seen that with the "old" proposal, it's now > only acceptable because you've removed the pre-1988 codes. It's acceptable *to you* because we've removed the pre-1988 codes. Many others found it acceptable before that change was made. There is solid evidence that having a language tagging mechanism that relies on the stability of ISO standards causes problems when those standards show instability. The draft seeks to remove or reduce that instability by introducing a stable layer on top of it. I do not believe there is any evidence that the stability of the extra layer will cause the problems you have described. >> The canonical value isn't hidden inside a comment > > The real canonical value in Addison's NHVU example is VU: > > | Subtag: NH > | Deprecated: 2006-01-01 > | Comment: use VU for Vanuatu I don't know where this example keeps coming from. Possibly Addison used it when we were talking about making comments a parsable field. Nevertheless, it is simply NOT the case that canonical-value information has ever been buried in a comment field, parsable or not, since the dawn of the registry idea. There has ALWAYS been a canonical-value field. Please re-read Section 3.1 of the current draft, in particular the description of the Canonical field. Then visit http://www.inter-locale.com/ID/draft-phillips-langtags-04.html to see the very first version of the draft that involved a registry. It also includes a canonical-value field, intended to be parsed by machines, and a separate comment field, intended to be read by humans. Please do not take an example that was meant to illustrate the value of a parsable comment field, and use it to claim that canonical values are buried inside comments. > I really don't care about the name, as long as it's a > machine readable pointer, how about: > > Alias: VU > or > See also: VU Or how about: Canonical: VU Which is exactly what the registry has. (Except that NH was purged as having been withdrawn before 1988, so I really don't see why we are using it as an example anyway.) -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 13:27:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04268; Sun, 10 Apr 2005 13:27:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKgNG-0006oJ-RP; Sun, 10 Apr 2005 13:37:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgCo-0003iS-5p; Sun, 10 Apr 2005 13:26:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgCm-0003iG-9O for ltru@megatron.ietf.org; Sun, 10 Apr 2005 13:26:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04195 for ; Sun, 10 Apr 2005 13:26:37 -0400 (EDT) Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKgLz-0006jn-Ku for ltru@ietf.org; Sun, 10 Apr 2005 13:36:11 -0400 Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050410172625.DBLR5402.mta11.adelphia.net@DEWELL>; Sun, 10 Apr 2005 13:26:25 -0400 Message-ID: <006d01c53df2$682eba80$030aa8c0@DEWELL> From: "Doug Ewell" To: References: <20050409012753.RKSN2128.mta1.adelphia.net@megatron.ietf.org> <003601c53cb7$315d3180$030aa8c0@DEWELL> <01LMVTUXJSQ400005R@mauve.mrochek.com> Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Date: Sun, 10 Apr 2005 10:26:17 -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.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit wrote: >> I'd like to see the look on your face when I show you my fully >> compliant tag generator and validator for RFC 3066bis. (Cf. the last >> sentence of Appendix A.) > > How about the look on your face when some detail in 3066bis changes, > rendering your implemenation invalid in some way? Oh, that's happened lots of times. Usually I just shrug and implement the change. Sometimes I smile broadly, because the change is one I supported. I don't have to worry about distribution, of course, since it's only a draft and not expected to be permanent. > I've implemented the rules I believe might be part of 3066bis myself. > But since I lack a working crystal ball, I have no way of knowing if > that's what will actually be in 3066bis when it is finally published. > I therefore cannot claim to have a compliant implementation at this > point. Nobody can. I have a version that is compliant with the draft as it stands today. Tomorrow's draft may be different enough to break my implementation, but that's OK because we are in draft mode. >> Of course, I can't distribute it publicly as being compliant with >> anything, since 3066bis is, indeed, not an RFC at the moment. > > Exactly. And more to the point, it may transpire that what actually > emerges is different in some way. We'd all be wasting our time here if > such changes weren't possible. Absolutely correct. >> But I always smile when someone says, for example, that the mechanism >> for identifying subtags based on length and position "doesn't work," >> or that parsing or validating tags is too complicated to be >> practical. > > Is anyone actually saying that in this group? If so I sure haven't > heard it. Frank had written on March 19: "But it would require complex restrictions allowing to identify the class of some subtags independent of their position. Most probably that was discussed years ago before the first of the old drafts, and it simply doesn't work." In other messages it had been stated that "smart matching" is impractical because the parsing rules are too complex. I can dig out examples if necessary, either from this list or from ietf-languages. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 13:33:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04468; Sun, 10 Apr 2005 13:33:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKgSn-0006y9-Jw; Sun, 10 Apr 2005 13:43:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgJM-0004hn-EH; Sun, 10 Apr 2005 13:33:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgJK-0004hi-UG for ltru@megatron.ietf.org; Sun, 10 Apr 2005 13:33:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04461 for ; Sun, 10 Apr 2005 13:33:23 -0400 (EDT) Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKgSW-0006y4-Ov for ltru@ietf.org; Sun, 10 Apr 2005 13:42:58 -0400 Received: from korppi.cs.tut.fi (korppi.cs.tut.fi [130.230.4.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id 3EF76D14 for ; Sun, 10 Apr 2005 20:33:11 +0300 (EEST) Date: Sun, 10 Apr 2005 20:33:10 +0300 (EEST) From: "Jukka K. Korpela" To: ltru@ietf.org Subject: Re: [Ltru] Re: seeking resolution of the Great Script Debate In-Reply-To: <42595842.175B@xyzzy.claranet.de> Message-ID: References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@irvmbxw01.quest.com> <42595842.175B@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On Sun, 10 Apr 2005, Frank Ellermann wrote: > > > > ...to define a script in addition to the old xml:lang= or lang= > language. No, those tags have nothing to do with specifying human languages or scripts (writing systems) for writing them. It would take too much time to explain all the conceptual errors involved, but the main point is that the (pragmatically useless) second tag above specifies the _programming (scripting) language_ used on the page. > Why ? Maybe we should add scripts to the "charset" instead of > the languages. The "charset" thing there is itself something that has been added to an Internet media type, a parameter. It would be illogical to put extra information into a parameter instead of using another parameter. Besides, an Internet media type designation has its own role and purpose, not including the indication of language or script. > Using Unicode everywhere caused this mess, so > it's only fair if they fix it, charset="UTF-8-mainly-Latn" or > whatever. Are you serious? It's not 1st of April any more. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 13:36:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04716; Sun, 10 Apr 2005 13:36:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKgVX-000749-GT; Sun, 10 Apr 2005 13:46:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgLw-00051B-Kt; Sun, 10 Apr 2005 13:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgLv-000516-5P for ltru@megatron.ietf.org; Sun, 10 Apr 2005 13:36:07 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04625 for ; Sun, 10 Apr 2005 13:36:03 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050410173532.DGVT4618.mta13.adelphia.net@DEWELL> for ; Sun, 10 Apr 2005 13:35:32 -0400 Message-ID: <007501c53df3$ae4916e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050409180925.CDLH2132.mta5.adelphia.net@megatron.ietf.org> Date: Sun, 10 Apr 2005 10:35: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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > This reference name is obviously not a medium term user acceptable > solution. This is why the ISO 639-3 cannot be a final solution. And why we > need a multi-language ontlogy. And yet you support the inclusion not only of ISO 639-3, but also ISO 639-6, which is not nearly as far along in the draft process, and whose contents most of us have never seen. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 13:42:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05096; Sun, 10 Apr 2005 13:42:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKgb3-0007GI-W0; Sun, 10 Apr 2005 13:51:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgQx-0005ZO-QO; Sun, 10 Apr 2005 13:41:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgQw-0005Z2-0S for ltru@megatron.ietf.org; Sun, 10 Apr 2005 13:41:18 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05065 for ; Sun, 10 Apr 2005 13:41:13 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050410174045.DMEA5402.mta11.adelphia.net@DEWELL> for ; Sun, 10 Apr 2005 13:40:45 -0400 Message-ID: <007a01c53df4$6866a880$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050409180925.CDLH2132.mta5.adelphia.net@megatron.ietf.org> Date: Sun, 10 Apr 2005 10:40:37 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > I am not particularly interested in the APMD format since it does not > fit my needs and I will not be able to use it. OK, then the rest of us can carry on addressing the issues raised in the charter. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 13:48:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05791; Sun, 10 Apr 2005 13:48:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKggz-0007UQ-0C; Sun, 10 Apr 2005 13:57:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgXQ-0006MQ-Gy; Sun, 10 Apr 2005 13:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgXO-0006MD-KK for ltru@megatron.ietf.org; Sun, 10 Apr 2005 13:47:58 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05742 for ; Sun, 10 Apr 2005 13:47:55 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050410174727.DRBA5402.mta11.adelphia.net@DEWELL> for ; Sun, 10 Apr 2005 13:47:27 -0400 Message-ID: <008701c53df5$57a77000$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> Date: Sun, 10 Apr 2005 10:47:18 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > My point was "no RfC at the moment". It's good that you have > a prototype for the draft. If somebody asks why a completely > new scheme is called "best common practice" we can answer that > one practical implementation exists, and that's automagically > the best, the worst, the only practice. Not exactly common. I did not create an implementation in order to misrepresent the status of the proposed language-tag mechanism. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 14:02:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06803; Sun, 10 Apr 2005 14:02:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKguY-0007vO-Nb; Sun, 10 Apr 2005 14:11:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgkn-00085H-C5; Sun, 10 Apr 2005 14:01:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgkm-00085C-Ik for ltru@megatron.ietf.org; Sun, 10 Apr 2005 14:01:48 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06789 for ; Sun, 10 Apr 2005 14:01:46 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DKghY-0006Gw-7X for ltru@lists.ietf.org; Sun, 10 Apr 2005 19:58:28 +0200 Received: from 212.82.251.245 ([212.82.251.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 19:58:28 +0200 Received: from nobody by 212.82.251.245 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 19:58:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 10 Apr 2005 19:58:48 +0200 Organization: Lines: 38 Message-ID: <42596958.3CBF@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@irvmbxw01.quest.com> <42595842.175B@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.245 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: seeking resolution of the Great Script Debate X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Jukka K. Korpela wrote: > those tags have nothing to do with specifying human languages Of course not, that's why I said "something like". For Bruce's draft it could be "Content-Script". > the (pragmatically useless) second tag above specifies the > _programming (scripting) language_ used on the page. Yes, I know this, and it's not useless, or how should a XHTML- browser guess what I want with an onload="..." string ? We're on the wrong list for this question, but at least it should be clear that I did not propose to replace text/javascript by Latn or Brai. > It would be illogical to put extra information into a > parameter instead of using another parameter. At the moment the draft adds extra information (script) to the language, if that's a bad idea maybe adding it to the charset is less illogical. Maybe an independent parameter is better. It's IMNSHO obvious that nobody needed it when the "charset" was something like Latin-1. It's only now after Unicode has de facto eliminated these differences that we miss them and want a script back, somehow, somewhere. >> charset="UTF-8-mainly-Latn" or whatever. > Are you serious? It's not 1st of April any more. It's the "Great Script Debate". I didn't start it, so where would you add the script after the "charset" degenerated into the "ideally it's all Unicode" in HTML 4 and later ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 14:04:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07056; Sun, 10 Apr 2005 14:04:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKgws-00081G-C1; Sun, 10 Apr 2005 14:14:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgmI-0008Fb-Jq; Sun, 10 Apr 2005 14:03:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgmH-0008FW-Q8 for ltru@megatron.ietf.org; Sun, 10 Apr 2005 14:03:21 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06912 for ; Sun, 10 Apr 2005 14:03:20 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050410180250.GMQU2192.mta9.adelphia.net@DEWELL> for ; Sun, 10 Apr 2005 14:02:50 -0400 Message-ID: <009701c53df7$7c923420$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050409233836.GAA2128.mta1.adelphia.net@megatron.ietf.org> Subject: Re: [Ltru] language or price tag ? Date: Sun, 10 Apr 2005 11:02:39 -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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > Our charter is not to rebuild the world (as some seems to want it) I would like to ask that these baseless insinuations about world domination come to an immediate end. We're talking about short alphanumeric language tags. I will also point out, for the record, that I will not entertain any claims, public or private, that opponents of the draft speak for "billions" of users while the proponents speak only for themselves. Besides the outlandish numerical hyperbole, the Chair has already stated that participation in the IETF is by individuals, not representatives. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 14:13:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07551; Sun, 10 Apr 2005 14:13:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKh5V-0008HI-I6; Sun, 10 Apr 2005 14:23:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgvW-0001D4-Mm; Sun, 10 Apr 2005 14:12:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKgvU-0001Cz-Iw for ltru@megatron.ietf.org; Sun, 10 Apr 2005 14:12:52 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07513 for ; Sun, 10 Apr 2005 14:12:51 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050410181221.GTAN2192.mta9.adelphia.net@DEWELL>; Sun, 10 Apr 2005 14:12:21 -0400 Message-ID: <00b801c53df8$ce4d8de0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050407135543.TTZO2124.mta7.adelphia.net@megatron.ietf.org> Date: Sun, 10 Apr 2005 11:12:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA07513 Cc: Frank Ellermann Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Frank Ellermann wrote: >> =C3=85land Islands, C=C3=B4te d'Ivoire, and R=C3=A9union. > > Odd, yes, also on their Web page, apparently only these 3 cases. > What happened below Luxembourg and below Oman, the extra line ? What page are you looking at? I checked the HTML and text pages, both English and French, as well as the decoding table, and don't see any extra line. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 14:33:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08849; Sun, 10 Apr 2005 14:33:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKhOa-0000Tn-EW; Sun, 10 Apr 2005 14:42:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKhDw-0003PL-JC; Sun, 10 Apr 2005 14:31:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKhDu-0003PG-JO for ltru@megatron.ietf.org; Sun, 10 Apr 2005 14:31:54 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08755 for ; Sun, 10 Apr 2005 14:31:52 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DKhB1-0000Rm-K2 for ltru@lists.ietf.org; Sun, 10 Apr 2005 20:28:55 +0200 Received: from 212.82.251.245 ([212.82.251.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 20:28:55 +0200 Received: from nobody by 212.82.251.245 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 20:28:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 10 Apr 2005 20:28:33 +0200 Organization: Lines: 56 Message-ID: <42597051.13F1@xyzzy.claranet.de> References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> <004a01c53df0$786d46c0$030aa8c0@DEWELL> 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.245 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Comment: use VU for Vanuatu X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Doug Ewell wrote: >> We've already seen that with the "old" proposal, it's now >> only acceptable because you've removed the pre-1988 codes. > It's acceptable *to you* because we've removed the pre-1988 > codes. Many others found it acceptable before that change > was made. In fact Jefsey said somewhere that he wants all the old codes (pre-1988) back. Anyway, Addison's example about NH and VU was fictitious, asuming that we have NH today, and later it's changed to VU, and still later changed again to XX. So that would "deprecate" (ISO 3166-1 view) NH, and later it would again "deprecate" VU. Is Addison's example now clear ? What exactly is the outcome for the LTRU registry ? Do we get pointers from XX to VU to NH, or vice versa, or in any way ? Or do we get three unrelated entries NH, VU, and XX, where the only hint that these entries belong to "the same piece of land" is hidden in a comment ? The latter would be very bad. That's all I've said (in reply to Addison's article). > I don't know where this example keeps coming from I can't reconstruct it, your References header field is broken, it points to a Message-ID which doesn't exist in the list: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> But it was in "this thread" if you can reconstruct it, one or two articles before I've changed the subject from 200 to VU. >> Alias: VU >> or >> See also: VU > Or how about: > Canonical: VU Excellent idea, but it was you who said that this won't work after date-B, because NH would then be "forever canonical". So what happens if an existing NH is somehow renamed to VU ? We don't need Addison's double-renaming for this question, so you could also use "VU renamed to XX" (after date-B). I would want "VU...deprecated...canonical XX", but you said that this is bad. What do you get ? "VU...deprecated" + "XX...canonical VU" is IMO gibberish. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 14:48:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09853; Sun, 10 Apr 2005 14:48:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKhdg-0000vZ-4s; Sun, 10 Apr 2005 14:58:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKhTp-00059h-Cc; Sun, 10 Apr 2005 14:48:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKhTo-00059c-Mf for ltru@megatron.ietf.org; Sun, 10 Apr 2005 14:48:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09824 for ; Sun, 10 Apr 2005 14:48:18 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKhd1-0000v4-Sn for ltru@ietf.org; Sun, 10 Apr 2005 14:57:52 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Sun, 10 Apr 2005 19:42:08 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Apr 2005 19:42:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: registry should copy non-English fields from ISO documents Date: Sun, 10 Apr 2005 19:42:07 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A2121A5940@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: registry should copy non-English fields from ISO documents Thread-Index: AcU99FhrMSisX3lQSXmMZd4EqeIeDgAAep+q From: "L.Gillam" To: ltru X-OriginalArrivalTime: 10 Apr 2005 18:42:07.0956 (UTC) FILETIME=[FF9E8940:01C53DFC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0568922336==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 This is a multi-part message in MIME format. --===============0568922336== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53DFC.FF85FD08" This is a multi-part message in MIME format. ------_=_NextPart_001_01C53DFC.FF85FD08 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Aside from wondering whether an ontlogy is a spelling error or a new = invention, I consider the following: =20 1. A "reference name" is for interoperability. The reference name for a = language can be taken from that language, and need not be in either = English or French, as I believe Peter was alluding to. I believe this to = be the case with -3 and it's certainly intended for -6. Difficulty only = arises if the name of the language itself causes a code (i.e. Unicode) = problem, as discussed previously.=20 2. A reference name acts as a "conceptual" identifier - a code is an = abbreviated form of such a "concept" (c/w terminological model). Nobody = is prevented from making and maintaining as many sets of names of = languages in other languages as they require (Jefsey's "multilingual = internet" perhaps?). For "network" interoperability, however, you need = to refer somehow to the chosen item in the "conceptual" entry.=20 3. A code (e.g. alpha3 in 639-3) stands as synonymous with the reference = name and as entry point into the "conceptual" entry - the mantra is "I = don't care what you call it as long as we are referring to the same = thing" 4. Applicability, or otherwise, of ISO 639-6 will be discussed when the = appropriate draft versions are available. A number of people are = involved in producing the draft of 639-6, learning from the various = experiences and discussions in a variety of locations, and some of those = are also involved with ensuring -4 has necessary and sufficient = coverage. Whatever consensus is achieved for -3 and/or -6, and indeed -4 = and -5 (has unanimous consensus ever been required on forums such as = this?) is for this forum to discuss. Doug is right to be cautious. =20 The reference name, therefore, seems to be an adequate and highly = extensible approach. I don't understand how it can be otherwise. =20 The question, as I see it, becomes: ISO code lists already contain French and English names. If the registry = identifies the code list and the code, does it really need to duplicate = all the fields from this list? If 639-1 and 639-2 were XML namespaces, = such replication could be made avoidable. =20 The second question becomes: If 639-3 is using the name of the language in the language itself, does = the code system have to be applied to itself? (This, to me, suggests = using XML - which I am currently in favour of longer-term, not least = because it allows the type of namespacing as above. I suggested same in, = at least, June 2004 in case anybody thinks I'm agreeing with their = recent suggestions). =20 ________________________________ From: ltru-bounces@lists.ietf.org on behalf of Doug Ewell Sent: Sun 10/04/2005 18:35 To: LTRU Working Group Subject: [Ltru] Re: registry should copy non-English fields from ISO = documents JFC (Jefsey) Morfin wrote: > This reference name is obviously not a medium term user acceptable > solution. This is why the ISO 639-3 cannot be a final solution. And why we > need a multi-language ontlogy. And yet you support the inclusion not only of ISO 639-3, but also ISO 639-6, which is not nearly as far along in the draft process, and whose contents most of us have never seen. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C53DFC.FF85FD08 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [Ltru] Re: registry should copy non-English fields from ISO = documents=0A= =0A= =0A=
=0A=
 
=0A=
Aside from wondering whether = an ontlogy is =0A= a spelling error or a new invention, I consider the = following:
=0A=
 
=0A=
1. A "reference name" = is for =0A= interoperability. The reference name for a language can be taken = from that =0A= language, and need not be in either English or French, as I = believe =0A= Peter was alluding to. I believe this to be the case with -3 and it's = certainly =0A= intended for -6. Difficulty only = arises if =0A= the name of the language itself causes a code (i.e. Unicode) problem, as =0A= discussed previously. 
=0A=
2. A reference name acts = as a =0A= "conceptual" identifier - a code is an abbreviated form of such a = "concept" (c/w =0A= terminological model). Nobody is prevented from making and maintaining = as =0A= many sets of names of languages in other languages as they require =0A= (Jefsey's "multilingual internet" perhaps?). For "network" = interoperability, =0A= however, you need to refer somehow to the chosen item in the = "conceptual" =0A= entry.
=0A=
3. A code (e.g. alpha3 in = 639-3) stands as =0A= synonymous with the reference name and as entry point into the = "conceptual" =0A= entry - the mantra is "I don't care what you call it as long as we are = referring =0A= to the same thing"
=0A=
4. Applicability, or = otherwise, of ISO =0A= 639-6 will be discussed when the appropriate draft versions are = available. A =0A= number of people are involved in producing the draft of 639-6, = learning =0A= from the various experiences and discussions in a variety of locations, = and some =0A= of those are also involved with ensuring -4 has necessary =0A= and sufficient coverage. Whatever consensus is achieved for -3 = and/or -6, =0A= and indeed -4 and -5 (has unanimous consensus ever been required on = forums =0A= such as this?) is for this forum to discuss. Doug is right to be =0A= cautious.
=0A=
 
=0A=
The reference name, = therefore, seems to be =0A= an adequate and highly extensible approach. I don't understand how it = can be =0A= otherwise.
=0A=
 
=0A=
The question, as I see it, =0A= becomes:
=0A=
ISO code lists already = contain French and =0A= English names. If the registry identifies the code list and the code, = does it =0A= really need to duplicate all the fields from this list? If 639-1 and = 639-2 were =0A= XML namespaces, such replication could be made = avoidable.
=0A=
 
=0A=
The second question = becomes:
=0A=
If 639-3 is using the name of = the language =0A= in the language itself, does the code system have to be applied to = itself? =0A= (This, to me, suggests using XML - which I am currently in = favour of =0A= longer-term, not least because it allows the type of namespacing as = above. I =0A= suggested same in, at least, June 2004 in case anybody thinks I'm = agreeing =0A= with their recent suggestions).
=0A=

 
=0A=
=0A=
=0A=
=0A=
From: = ltru-bounces@lists.ietf.org =0A= on behalf of Doug Ewell
Sent: Sun 10/04/2005 = 18:35
To: LTRU =0A= Working Group
Subject: [Ltru] Re: registry should copy = non-English =0A= fields from ISO documents

=0A=
=0A=

JFC (Jefsey) Morfin <jefsey at jefsey dot com> =0A= wrote:

> This reference name is obviously not a medium term = user =0A= acceptable
> solution. This is why the ISO 639-3 cannot be a final =0A= solution. And
why we
> need a multi-language = ontlogy.

And yet =0A= you support the inclusion not only of ISO 639-3, but also ISO
639-6, = which is =0A= not nearly as far along in the draft process, and whose
contents most = of us =0A= have never seen.

-Doug Ewell
 Fullerton, = California
 http://users.adelphia.net/~de= well/



_______________________________________________<= BR>Ltru =0A= mailing list
Ltru@lists.ietf.org
https://www1.ietf.or= g/mailman/listinfo/ltru

=0A= =0A= =0A= ------_=_NextPart_001_01C53DFC.FF85FD08-- --===============0568922336== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0568922336==-- From ltru-bounces@ietf.org Sun Apr 10 15:25:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13129; Sun, 10 Apr 2005 15:25:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiCu-0001xf-Rl; Sun, 10 Apr 2005 15:34:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKhzt-0000I5-Al; Sun, 10 Apr 2005 15:21:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKhzr-0000HV-It for ltru@megatron.ietf.org; Sun, 10 Apr 2005 15:21:27 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12976 for ; Sun, 10 Apr 2005 15:21:25 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DKhx2-0004nz-I4 for ltru@lists.ietf.org; Sun, 10 Apr 2005 21:18:32 +0200 Received: from 212.82.251.245 ([212.82.251.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 21:18:32 +0200 Received: from nobody by 212.82.251.245 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 21:18:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 10 Apr 2005 20:51:23 +0200 Organization: Lines: 14 Message-ID: <425975AB.213E@xyzzy.claranet.de> References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> <008701c53df5$57a77000$030aa8c0@DEWELL> 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.245 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] BCP 47 (was: Compatibility with existing use (LDAP)) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > I did not create an implementation in order to misrepresent > the status of the proposed language-tag mechanism. Sure, I know this. But I've no good idea how to get rid of a "best common practice", that's some IETF magic. Maybe 3066bis could be a "normal" RfC on standards track, and still obsolete BCP 47 a.k.a. RfC 3066. I don't feel comfortable with RfC 3066 as BCP, it didn't survive four years. And I'm not completely convinced that RfC 3066bis would last much longer, finding some "3066ter" on this list. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 15:26:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13189; Sun, 10 Apr 2005 15:26:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiDp-0001yn-Sz; Sun, 10 Apr 2005 15:35:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKi0g-0000Iw-FS; Sun, 10 Apr 2005 15:22:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKi0f-0000Ir-5f for ltru@megatron.ietf.org; Sun, 10 Apr 2005 15:22:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13008 for ; Sun, 10 Apr 2005 15:22:15 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKi9s-0001sz-Bz for ltru@ietf.org; Sun, 10 Apr 2005 15:31:49 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3AJLoHv014110; Sun, 10 Apr 2005 15:21:51 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 10 Apr 2005 15:21:54 -0400 Date: Sun, 10 Apr 2005 15:21:53 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: Comment: use VU for Vanuatu (was: remove region subtag 200) Message-ID: <20050410192153.GA11942@skunk.reutershealth.com> References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> <004a01c53df0$786d46c0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004a01c53df0$786d46c0$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Doug Ewell scripsit: > Which is exactly what the registry has. (Except that NH was purged as > having been withdrawn before 1988, so I really don't see why we are > using it as an example anyway.) We are imagining for the purpose of this example that it didn't happen until after Date A. -- It was dreary and wearisome. Cold clammy winter still held way in this forsaken country. The only green was the scum of livid weed on the dark greasy surfaces of the sullen waters. Dead grasses and rotting reeds loomed up in the mists like ragged shadows of long-forgotten summers. --"The Passage of the Marshes" http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 15:37:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14270; Sun, 10 Apr 2005 15:37:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiOS-0002QD-SN; Sun, 10 Apr 2005 15:46:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiCZ-0001g5-4T; Sun, 10 Apr 2005 15:34:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiCY-0001g0-9f for ltru@megatron.ietf.org; Sun, 10 Apr 2005 15:34:34 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14032 for ; Sun, 10 Apr 2005 15:34:31 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DKi9e-0005vL-MR for ltru@lists.ietf.org; Sun, 10 Apr 2005 21:31:34 +0200 Received: from 212.82.251.245 ([212.82.251.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 21:31:34 +0200 Received: from nobody by 212.82.251.245 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 21:31:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 10 Apr 2005 21:33:07 +0200 Organization: Lines: 15 Message-ID: <42597F73.6DA6@xyzzy.claranet.de> References: <20050407135543.TTZO2124.mta7.adelphia.net@megatron.ietf.org> <00b801c53df8$ce4d8de0$030aa8c0@DEWELL> 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.245 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed changes to region subtags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Doug Ewell wrote: >> What happened below Luxembourg and below Oman, the extra >> line ? > What page are you looking at? http://users.adelphia.net/~dewell/lstreg.txt It's okay today for the same File_Date: 2005-04-06, that was probably a bad hallucination on my side Hex. view, yes, there is really nothing wrong with Oman or Luxembourg, whatever it was, it was on my side, sorry & bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 15:38:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14319; Sun, 10 Apr 2005 15:38:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiPB-0002Qm-In; Sun, 10 Apr 2005 15:47:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiE3-0001k6-FG; Sun, 10 Apr 2005 15:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiE2-0001k1-2O for ltru@megatron.ietf.org; Sun, 10 Apr 2005 15:36:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14162 for ; Sun, 10 Apr 2005 15:36:04 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiNG-0002OY-DV for ltru@ietf.org; Sun, 10 Apr 2005 15:45:38 -0400 Received: from lns-p19-1-idf-82-251-94-206.adsl.proxad.net ([82.251.94.206] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKiDV-0004VJ-NN; Sun, 10 Apr 2005 12:35:34 -0700 Message-Id: <6.1.2.0.2.20050410193918.0d319910@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 21:35:06 +0200 To: Frank Ellermann , ltru@ietf.org, "Jukka K. Korpela" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: seeking resolution of the Great Script Debate In-Reply-To: <42595842.175B@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@irvmbxw01.quest.com> <42595842.175B@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Frank, Jukka, IMHO this debate started the wrong way with first a final proposition being proposed and progressively basic Charter issues emerging. I am a network man and not competent in external applications such as LDAP, XML, HTML, etc. I am somewhat interested in CLDR because it may add/interfere with the inner structure of a network operating system (NOS). I therefore tend to trust Addison as a W3C person when he speaks of XML. But obviously I am interested to understand the real XML lower level needs when they may relate with the NOS or with protocols. From what I understand from Addison, the intricacy of the XML system impeaches to think of another XML architectural solution? Your comments are really welcome, in the same way as Addison proceeded: discussing the cons and pros. (we cannot accept Jukka's "It would take too much time to explain all the conceptual errors involved" comment: we are here to specify network protocol related issues - and further as underlined by Jown Cohan - we are told to be dependent in XML demands. The least XML people can do is to document them). Our own need is simple: the members of a user class "A" share a context "A" with a group of resources "A", our job as a CRC (context reference center) is to maintain and make accessible the data of this context "A" to all the participants to the "A" externet registered to the "A" registry. Such context may contain every information the "A" Members may decide to store there. We started with DNS root, PAD, reference links and work on tags and a language to describe/use the context elements. Some context elements could certainly be (like for example the various tables used for the tags) maintained through CRCD subscriptions (context reference compact disk) proposed by intelligent services providers and formatted updates (comparable to anti-virus support). For example we can certainly conceive XML documents (or LDAP, etc.) including xml:lang=$langtag and the $langtag variable to be converted from a local context search or by an OPES/ONES acting on the page output/input, in taking care of the specifics of the concerned application. Our interest is not in format but in content. The content description and usage should be universal and the formats should be documented by the application designers. We are ready to best help, but not to the detriment of other general principles, equal and stable for everyone. The adequation of a format participates to the adequation and competitiveness of an application. The users are to chose on a network by the users for the users. jfc At 18:45 10/04/2005, Frank Ellermann wrote: >Addison Phillips wrote: > > > XML doesn't *need* or *want* two ways to identify language. > >But it has encoding and allows other meta-data, in the case of >XHTML I could use something like... > > > > >...to define a script in addition to the old xml:lang= or lang= >language. > > > it can't GET a new built in attribute that uses a URL or any > > other format > >It also can't get a new built-in attribute for say the location >- but it's simple to add this meta-data where needed. > > > (see: "the huge success of XML 1.1"). > >That's apparently a joke, without knowing what's going on I've >almost started a flame-war on the xml2rfc list only because I >dared (durst ?) test version="1.1". > > > Locale identifiers for Web services can be URLs and may very > > well be. But they are orthogonal to this discussion. > >Why ? Maybe we should add scripts to the "charset" instead of >the languages. Using Unicode everywhere caused this mess, so >it's only fair if they fix it, charset="UTF-8-mainly-Latn" or >whatever. > Bye, Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 15:38:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14342; Sun, 10 Apr 2005 15:38:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiPX-0002Qs-9S; Sun, 10 Apr 2005 15:47:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiFz-0001sL-L2; Sun, 10 Apr 2005 15:38:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiFy-0001sG-Ie for ltru@megatron.ietf.org; Sun, 10 Apr 2005 15:38:06 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14336 for ; Sun, 10 Apr 2005 15:38:04 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050410193735.JKCZ2192.mta9.adelphia.net@DEWELL>; Sun, 10 Apr 2005 15:37:35 -0400 Message-ID: <000801c53e04$bba87d60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> <004a01c53df0$786d46c0$030aa8c0@DEWELL> <20050410192153.GA11942@skunk.reutershealth.com> Subject: Re: [Ltru] Re: Comment: use VU for Vanuatu (was: remove region subtag 200) Date: Sun, 10 Apr 2005 12:37:27 -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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit John Cowan wrote: >> Which is exactly what the registry has. (Except that NH was purged as >> having been withdrawn before 1988, so I really don't see why we are >> using it as an example anyway.) > > We are imagining for the purpose of this example that it didn't happen > until after Date A. Sorry, I missed that. I was going to suggest that in that case, we should use BU and MM instead, but I guess I was the only one confused by this. Type: region Subtag: BU Description: Burma Date: 2004-07-06 Canonical: MM Deprecated: 1989-12-05 The Vanuatu example, if it had not happened until after Date A, would have been: Type: region Subtag: NH Description: New Hebrides Date: 2004-07-06 Canonical: VU Deprecated: 1980-01-01 -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 15:39:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14441; Sun, 10 Apr 2005 15:39:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiQL-0002UM-Qi; Sun, 10 Apr 2005 15:48:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiDq-0001jd-70; Sun, 10 Apr 2005 15:35:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiDp-0001jR-3b for ltru@megatron.ietf.org; Sun, 10 Apr 2005 15:35:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14123 for ; Sun, 10 Apr 2005 15:35:51 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiN2-0002LM-JC for ltru@ietf.org; Sun, 10 Apr 2005 15:45:25 -0400 Received: from lns-p19-1-idf-82-251-94-206.adsl.proxad.net ([82.251.94.206] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKiDX-0004VJ-1l; Sun, 10 Apr 2005 12:35:35 -0700 Message-Id: <6.1.2.0.2.20050410194819.0d2fbbd0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 19:55:23 +0200 To: "Doug Ewell" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Comment: use VU for Vanuatu (was: remove region subtag 200) In-Reply-To: <004a01c53df0$786d46c0$030aa8c0@DEWELL> References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> <004a01c53df0$786d46c0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On 19:12 10/04/2005, Doug Ewell said: >There is solid evidence that having a language tagging mechanism that >relies on the stability of ISO standards causes problems when those >standards show instability. The draft seeks to remove or reduce that >instability by introducing a stable layer on top of it. I do not >believe there is any evidence that the stability of the extra layer will >cause the problems you have described. I would be very interested in your description of this layer. The draft proposes a tag layer where the tag = "ISO 639"+"ISO 15924"+"ISO 3166". I fail to understand how tag is inderpendent from a change in one of the ISO subtags. An independent layer would be xml:lang="jefsey-2005" and "jefsey-2005" being documented at http://jefsey.langtags.org. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 15:39:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14472; Sun, 10 Apr 2005 15:39:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiQb-0002Ua-OC; Sun, 10 Apr 2005 15:49:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiDq-0001jZ-3s; Sun, 10 Apr 2005 15:35:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiDp-0001jP-1J for ltru@megatron.ietf.org; Sun, 10 Apr 2005 15:35:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14121 for ; Sun, 10 Apr 2005 15:35:51 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKiN3-0002LO-Bn for ltru@ietf.org; Sun, 10 Apr 2005 15:45:25 -0400 Received: from lns-p19-1-idf-82-251-94-206.adsl.proxad.net ([82.251.94.206] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKiDY-0004VJ-Bb; Sun, 10 Apr 2005 12:35:36 -0700 Message-Id: <6.1.2.0.2.20050410204510.0d430d10@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 10 Apr 2005 21:25:43 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] language or price tag ? In-Reply-To: <009701c53df7$7c923420$030aa8c0@DEWELL> References: <20050409233836.GAA2128.mta1.adelphia.net@megatron.ietf.org> <009701c53df7$7c923420$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 At 20:02 10/04/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > Our charter is not to rebuild the world (as some seems to want it) >I would like to ask that these baseless insinuations about world >domination come to an immediate end. We're talking about short >alphanumeric language tags. shhhhh... this becomes tiring. But I will try another time to kindly try to make you understand from your own words. Talking about "short" alphanumeric language tags to describe the extreme variety of the real human world _IS_ rebuilding the world. >I will also point out, for the record, that I will not entertain any >claims, public or private, that opponents of the draft speak for >"billions" of users while the proponents speak only for themselves. Your personal priviledge. >Besides the outlandish numerical hyperbole, the Chair has already stated >that participation in the IETF is by individuals, not representatives. We all are here because we are competent in some areas. I am probably one of the few involved in users and language oriented open and non commercial organizations and working groups, with forecasts or decisions having turned to be proven by the networks last three decades. I suggest that you ask the authors to remove the name of their organization from the headers of their RFCs. I understand some of your concerns and your irritation at facing the difficulty to obtain a market consensus before proposing a WG Draft. We all face this problem. Fighting one another cannot help. If there is no consensus between twenty, it is unlikely there is one between billions. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 15:52:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15257; Sun, 10 Apr 2005 15:52:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKidO-00032w-K6; Sun, 10 Apr 2005 16:02:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiTz-0003Xq-Dz; Sun, 10 Apr 2005 15:52:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiTy-0003Xd-9w for ltru@megatron.ietf.org; Sun, 10 Apr 2005 15:52:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15210 for ; Sun, 10 Apr 2005 15:52:32 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKidC-00031P-Ru for ltru@ietf.org; Sun, 10 Apr 2005 16:02:07 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3AJqOeS014239; Sun, 10 Apr 2005 15:52:25 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 10 Apr 2005 15:52:40 -0400 Date: Sun, 10 Apr 2005 15:52:40 -0400 From: John Cowan To: "L.Gillam" Subject: Re: [Ltru] Re: registry should copy non-English fields from ISO documents Message-ID: <20050410195239.GB11942@skunk.reutershealth.com> References: <4A7C6FA2AB31194E80E13FE585F6A2121A5940@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A2121A5940@EVS-EC1-NODE1.surrey.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 L.Gillam scripsit: > 1. A "reference name" is for interoperability. The reference name for > a language can be taken from that language, and need not be in either > English or French, as I believe Peter was alluding to. I believe this to > be the case with -3 and it's certainly intended for -6. ISO 639-3 reference names are English names (which may in many cases be identical to native names, but only when there is no traditional English name). "French", "German", "Chinese" are so named. This reflects 639-3's inheritance from the Ethnologue. Note also that many 639-3 languages have no written form, and would have to have the names transcribed in some system rather than simply written. > 3. A code (e.g. alpha3 in 639-3) stands as synonymous with the reference > name and as entry point into the "conceptual" entry - the mantra is > "I don't care what you call it as long as we are referring to the > same thing" The code points to the name, but the name does not always unambiguously point to the language. In ISO 639-1/2 (which are unambiguously mapped, so I treat them as one), there is the language coded "zh" or "chi" or "zho" and named "Chinese" and "chinois". But there is no way of knowing whether that means: 1) Mandarin Chinese, a specific Sinitic language 2) The Sinitic languages as a collection 3) The languages called "Chinese" as a collection 4) A macrolanguage incorporating the Sinitic languages as components 5) A macrolanguage incorporating the languages called "Chinese" as components ISO 639-3 takes position 5. > ensuring -4 has necessary and sufficient coverage. >From what I understand (I have not seen a draft), -4 will be conceptual and introductory (-0, in other words, if ISO rules permitted a -0 part) and will not provide coverage of anything. Has this changed? > The question, as I see it, becomes: > ISO code lists already contain French and English names. If the registry > identifies the code list and the code, does it really need to duplicate > all the fields from this list? There is no evidence which name is the reference name, however. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan This great college [Trinity], of this ancient university [Cambridge], has seen some strange sights. It has seen Wordsworth drunk and Porson sober. And here am I, a better poet than Porson, and a better scholar than Wordsworth, somewhere betwixt and between. --A.E. Housman _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 16:05:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16068; Sun, 10 Apr 2005 16:05:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKipY-0003Qy-Hb; Sun, 10 Apr 2005 16:14:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKiee-0004li-V2; Sun, 10 Apr 2005 16:03:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKied-0004ld-R7 for ltru@megatron.ietf.org; Sun, 10 Apr 2005 16:03:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15980 for ; Sun, 10 Apr 2005 16:03:33 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKins-0003PB-Je for ltru@ietf.org; Sun, 10 Apr 2005 16:13:08 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3AK3QLu014296; Sun, 10 Apr 2005 16:03:26 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 10 Apr 2005 16:03:27 -0400 Date: Sun, 10 Apr 2005 16:03:26 -0400 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Comment: use VU for Vanuatu (was: remove region subtag 200) Message-ID: <20050410200326.GC11942@skunk.reutershealth.com> References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> <004a01c53df0$786d46c0$030aa8c0@DEWELL> <6.1.2.0.2.20050410194819.0d2fbbd0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050410194819.0d2fbbd0@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 JFC (Jefsey) Morfin scripsit: > I would be very interested in your description of this layer. The draft > proposes a tag layer where the tag = "ISO 639"+"ISO 15924"+"ISO 3166". I > fail to understand how tag is inderpendent from a change in one of the > ISO subtags. To spell it out: If a code is *unassigned* by an ISO authority, it remains in the IANA registry as a subtag of the relevant kind and therefore valid. The ISO 639 and 15924 registration authorities have guaranteed not to *reassign* codes. When the ISO 3166 maintenance authority (which is under different pressures from the other two and has a different status and history with ISO) reassigns a code, we ignore the reassignment and make use of a UN M.49 numeric code instead. The UNSD also guarantees not to reassign tags. In this way, we stay completely compatible with the ISO codes and yet independent of changes. There is no need to create syntactically independent tags such as you propose. -- A mosquito cried out in his pain, John Cowan "A chemist has poisoned my brain!" http://www.ccil.org/~cowan The cause of his sorrow http://www.reutershealth.com Was para-dichloro- jcowan@reutershealth.com Diphenyltrichloroethane. (aka DDT) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 16:27:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17081; Sun, 10 Apr 2005 16:27:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKjB2-00044v-Gv; Sun, 10 Apr 2005 16:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKj1B-0006u4-J4; Sun, 10 Apr 2005 16:26:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKj19-0006tz-If for ltru@megatron.ietf.org; Sun, 10 Apr 2005 16:26:51 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17045 for ; Sun, 10 Apr 2005 16:26:48 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DKiyM-0001fB-TF for ltru@lists.ietf.org; Sun, 10 Apr 2005 22:23:58 +0200 Received: from 212.82.251.245 ([212.82.251.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 22:23:58 +0200 Received: from nobody by 212.82.251.245 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Apr 2005 22:23:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 10 Apr 2005 22:23:45 +0200 Organization: Lines: 58 Message-ID: <42598B51.3AD0@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@irvmbxw01.quest.com> <42595842.175B@xyzzy.claranet.de> <6.1.2.0.2.20050410193918.0d319910@mail.jefsey.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.245 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: seeking resolution of the Great Script Debate X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > I am a network man and not competent in external applications > such as LDAP, XML, HTML, etc. Okay, what Addison said (my interpretation) was essentially that we can't change XML 1.0 (or 1.1) as it is. Numerous formats based on XML exist (XHTML is only one example), they won't learn new tricks like a xml:script only because we say so in a hypothetical XML 1.2. And of course XML is W3C, not IETF, so we'd be in the wrong WG, unless Martin and Addison would start some very complex rituals with their hats => dead end, no XML 1.2, it cannot help. OTOH all document formats based on XML are free to add their own attributes, e.g. XHTML 1.0 has its own "lang" (inherited from HTML) in addition to the "xml:lang". But it's the same problem with existing formats like HTML 4.01 or XHTML 1.0, they won't learn new tricks in the form of new attributes only because we say so. A hypothetical new HTML 4.1 or XHTML 1.0.1 is a very dubious idea. It would be really nice if we could squeeze the script somehow in the existing language tags. But if Ned says NO because he knows a case where it would cause harm it's a serious problem. Jukka said that adding it to the charset is a horrible idea - that's of course true, but if we can't add it to the language we're stuck. > we cannot accept Jukka's "It would take too much time to > explain all the conceptual errors involved" comment That was probably only a misunderstandig, he feared that I don't know what a Content-Script-Type is, because he's used to some obscure charset="windows-1252" proposals from me on the validator.W3 list. ;-) And I'm used to his "why XHTML if HTML is better" comments on the same list, so maybe it was a joke. Or I didn't understand it, whatever, it's irrelevant for the Great Script Debate. > we are here to specify network protocol related issues Actually we are here to specify a new language tag registry. Debbie said, that she would like another dimension "charset" in these crazy tags, but now we're looking at solutions without script (less dimensions). Nothing promises to be the "best for all" solution. That forces us to find the least harmful exit. Please drop the idea to abuse DNS to get combined language tag registry entries, at least not in a form languages * scripts * regions * variants, that's horrible. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 16:30:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17154; Sun, 10 Apr 2005 16:30:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKjDj-000493-7e; Sun, 10 Apr 2005 16:39:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKj3h-00076Y-ML; Sun, 10 Apr 2005 16:29:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKj3g-00076T-MJ for ltru@megatron.ietf.org; Sun, 10 Apr 2005 16:29:28 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17148 for ; Sun, 10 Apr 2005 16:29:26 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050410202857.IDQX5402.mta11.adelphia.net@DEWELL> for ; Sun, 10 Apr 2005 16:28:57 -0400 Message-ID: <000f01c53e0b$de9b28c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> <004a01c53df0$786d46c0$030aa8c0@DEWELL> <6.1.2.0.2.20050410194819.0d2fbbd0@mail.jefsey.com> Subject: Re: [Ltru] Re: Comment: use VU for Vanuatu (was: remove region subtag 200) Date: Sun, 10 Apr 2005 13:28: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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > On 19:12 10/04/2005, Doug Ewell said: > ... The draft seeks to remove or reduce that > >instability by introducing a stable layer on top of it... > > I would be very interested in your description of this layer. The > draft proposes a tag layer where the tag = "ISO 639"+"ISO 15924"+"ISO > 3166". I fail to understand how tag is inderpendent from a change in > one of the ISO subtags. This is one of the fundamental features of the draft, and has been discussed at great length. The subtags are BASED ON code elements in ISO standards, but may deviate from them to preserve stability when the ISO code elements are changed, and especially so when they are reused. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 16:35:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17382; Sun, 10 Apr 2005 16:35:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKjIv-0004F2-QW; Sun, 10 Apr 2005 16:45:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKj94-0007Oa-T0; Sun, 10 Apr 2005 16:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKj93-0007OL-Vl for ltru@megatron.ietf.org; Sun, 10 Apr 2005 16:35:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17322 for ; Sun, 10 Apr 2005 16:34:59 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKjII-0004EV-0S for ltru@ietf.org; Sun, 10 Apr 2005 16:44:35 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3AKYpvL014437; Sun, 10 Apr 2005 16:34:51 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 10 Apr 2005 16:34:59 -0400 Date: Sun, 10 Apr 2005 16:34:58 -0400 From: John Cowan To: randy_presuhn@mindspring.com Message-ID: <20050410203458.GD11942@skunk.reutershealth.com> References: <20050409233836.GAA2128.mta1.adelphia.net@megatron.ietf.org> <009701c53df7$7c923420$030aa8c0@DEWELL> <6.1.2.0.2.20050410204510.0d430d10@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050410204510.0d430d10@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ltru@ietf.org Subject: [Ltru] Formal request for action by the LTRU Chair X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 JFC (Jefsey) Morfin scripsit: > >I would like to ask that these baseless insinuations about world > >domination come to an immediate end. We're talking about short > >alphanumeric language tags. > > shhhhh... this becomes tiring. M. Morfin does not seem to grasp how insulting it is to tell people to shut up. Mr. Chairman, I call for the immediate initiation of the process leading to the blocking of M. Morfin's ability to post to ltru@ietf.org because of his repeated pattern of unprofessional commentary. I take this step with regret, but in the belief that it is required to maintain order and forward progress in the WG. > >I will also point out, for the record, that I will not entertain any > >claims, public or private, that opponents of the draft speak for > >"billions" of users while the proponents speak only for themselves. > > Your personal priviledge. M. Morfin knows perfectly well that this is IETF policy and not a "personal privilege" of Mr. Ewell's. > I suggest that you ask the authors to remove the name of their > organization from the headers of their RFCs. M. Morfin knows perfectly well that the organization names in RFCs are provided for identification only and as a matter of IETF policy, and do not mean that the authors represent their organizations. -- If you have ever wondered if you are in hell, John Cowan it has been said, then you are on a well-traveled http://www.ccil.org/~cowan road of spiritual inquiry. If you are absolutely http://www.reutershealth.com sure you are in hell, however, then you must be jcowan@reutershealth.com on the Cross Bronx Expressway. --Alan Feuer, NYTimes, 2002-09-20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 17:32:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20158; Sun, 10 Apr 2005 17:32:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKkCR-0005ul-1F; Sun, 10 Apr 2005 17:42:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKk2Z-000466-Ew; Sun, 10 Apr 2005 17:32:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKk2Y-000461-8s for ltru@megatron.ietf.org; Sun, 10 Apr 2005 17:32:22 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20133 for ; Sun, 10 Apr 2005 17:32:19 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050410213150.ZPIE7277.mta10.adelphia.net@DEWELL> for ; Sun, 10 Apr 2005 17:31:50 -0400 Message-ID: <001601c53e14$9c641580$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050410193803.JRSC4900.mta8.adelphia.net@megatron.ietf.org> Date: Sun, 10 Apr 2005 14:31:07 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Comment: use VU for Vanuatu X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > In fact Jefsey said somewhere that he wants all the old codes > (pre-1988) back. I thought we'd resolved that already, but I see that ticket #895 was never resolved: http://www1.ietf.org/mail-archive/web/ltru/current/msg00749.html I'll respond to that separately. > Anyway, Addison's example about NH and VU > was fictitious, asuming that we have NH today, and later it's > changed to VU, and still later changed again to XX. OK, you're right. I'm getting confused by the example, which pretends we are not following the Date A/B principles I thought we had agreed on. So let's recast the example, with our Date A changed back to 1974 to accommodate the New Hebrides/Vanuatu example, but with all other historical facts intact. There is a current ISO 3166 code element, VU, that stands for Vanuatu, and another code element, NH, that stood for New Hebrides but was withdrawn by ISO 3166/MA in 1980 in favor of VU (due to its independence and name change). So there would initially be two region subtags: %% Type: region Subtag: NH Description: New Hebrides Added: 2004-07-06 Canonical: VU Deprecated: 1980-01-01 %% Type: region Subtag: VU Description: Vanuatu Added: 2004-07-06 %% Now let's jump to the future. Suppose that on January 1, 2006, the government of Vanuatu decides to change the official name of the country to "Vonuatu" with an O, perhaps choosing a form used in one of the country's minority languages instead of Bislama. Suppose that ISO 3166/MA goes along and changes the code element from VU to VO. Then, pending clerical review by the Language Subtag Reviewer, assisted by ietf-language, a new, NON-CANONICAL region subtag would be added to the registry: %% Type: region Subtag: VO Description: Vonuatu Added: 2006-02-19 Canonical: VU %% Ah, but what do we do about the Deprecated field? Section 3.1 says that a subtag with a Canonical field MUST also have a Deprecated field. Yet the new ISO 3166 code element VO has certainly not been "deprecated" or withdrawn by ISO 3166/MA; rather, that body has withdrawn VU. It is the Language Subtag Registry that keeps VU as the canonical value and makes VO an alias, just like NH. The existence of a Deprecated field at all is part of the recent reconstruction of Section 3.1, and I consider it an inconsistency rather than a change or disagreement about the policy of subtag stability. There are two ways to solve this problem: (1) The draft should specify that subtags that are born non-canonical, such as VO, must have a Deprecated date equal to the Added date. That is, the Deprecated date for such subtags represents the date the subtag was deprecated *within the registry*, not within the related ISO standard.. OR (2) The draft should remove the requirement that all records with a Canonical field must also have a Deprecated field. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 18:46:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25268; Sun, 10 Apr 2005 18:46:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKlLq-00081l-3k; Sun, 10 Apr 2005 18:56:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKlBZ-0000xp-3O; Sun, 10 Apr 2005 18:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKlBX-0000xk-Dx for ltru@megatron.ietf.org; Sun, 10 Apr 2005 18:45:43 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25201 for ; Sun, 10 Apr 2005 18:45:39 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DKl8S-0005vl-AV for ltru@lists.ietf.org; Mon, 11 Apr 2005 00:42:32 +0200 Received: from 212.82.251.245 ([212.82.251.245]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 00:42:32 +0200 Received: from nobody by 212.82.251.245 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 00:42:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 11 Apr 2005 00:29:48 +0200 Organization: Lines: 117 Message-ID: <4259A8DC.7B7F@xyzzy.claranet.de> References: <20050410193803.JRSC4900.mta8.adelphia.net@megatron.ietf.org> <001601c53e14$9c641580$030aa8c0@DEWELL> 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.245 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Comment: use VU for Vanuatu X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > I see that ticket #895 was never resolved: > http://www1.ietf.org/mail-archive/web/ltru/current/msg00749.html As far as I'm concerned it is resolved, all pre-date-B issues were resolved by your date-A = 1988 proposal. No idea why Jefsey wants to keep it open or reopen it, or why Randy didn't mark it as closed yet. > I'm getting confused by the example, which pretends we are > not following the Date A/B principles I thought we had agreed > on. Yes, I'll ignore anything before date-B until somebody changes date-A (please don't). > There is a current ISO 3166 code element, VU, that stands for > Vanuatu, ACK. And in theory there could be an old code say NH with a canonical value VU. No problem, anything after date-A and before date-B works as designed, we've lost three old regions 200, 280, and 720 automagically, but it's no serious problem in these cases. > Type: region > Subtag: NH > Description: New Hebrides > Added: 2004-07-06 > Canonical: VU > Deprecated: 1980-01-01 > %% > Type: region > Subtag: VU > Description: Vanuatu > Added: 2004-07-06 Exactly. > change the official name of the country to "Vonuatu" with an > O, perhaps choosing a form used in one of the country's > minority languages instead of Bislama. Suppose that ISO > 3166/MA goes along and changes the code element from VU to VO Yes, that was the point. > Type: region > Subtag: VO > Description: Vonuatu > Added: 2006-02-19 > Canonical: VU Yes, and that's IMHO ugly, it would be better to accept VO as the new canonical value and do something like this: | Type: region | Subtag: NH | Description: New Hebrides | Added: 2004-07-06 | Canonical: VO | Deprecated: 1980-01-01 Keeping NH as it was (canonical VU) is also possible, but less obvious, because what I really want is: | Type: region | Subtag: VU | Description: Vanuatu | Added: 2004-07-06 | Deprecated: 2006-02-19 | Canonical: VO You had some nightmares about changing all old VU tags and even applications, but that's unnecessary, even old NH tags (in this fictitious date-A example) are still valid and only deprecated. My nightmare was a later attempt to reuse VU for something else by ISO 3166-1, where some taggers could try to use the new VU, which is NOT the same as VO. > Section 3.1 says that a subtag with a Canonical field MUST > also have a Deprecated field. Now we're on the same track, that's why Addison introduced this example. We cannot insert a "Deprecated: 2006-02-19" into VU while VU is still canonical elsewhere (NH and VO), and we cannot insert "Deprecated: 2006-02-19" in VO, because VO is in fact only "new" but not "canonical" in your version. With my idea ("canonical" follows ISO 3166-1 until that's not more possible, and then it uses the UN numbers) it should work. > (1) The draft should specify that subtags that are born > non-canonical, such as VO, must have a Deprecated date equal > to the Added date. That's weird, please don't. > (2) The draft should remove the requirement that all records > with a Canonical field must also have a Deprecated field. Better, but not good enough for my SK-GE-CS-nightmares. So my idea is: (3) Whenever ISO 3166-1 introduces a new region code which is not already in the registry, it's added to the registry. Otherwise the UN number is added. In both cases the added code is the canonical value, all former codes for the same region are deprecated. And pray that we don't get into trouble with major discrepancies between the ISO 3166-1 concept of regions and the UN concept (TW is a fair warning for us). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 22:09:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11502; Sun, 10 Apr 2005 22:09:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKoVo-00077M-Uw; Sun, 10 Apr 2005 22:18:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKoMF-0007SI-JX; Sun, 10 Apr 2005 22:08:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKoMC-0007S4-C9 for ltru@megatron.ietf.org; Sun, 10 Apr 2005 22:08:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11458 for ; Sun, 10 Apr 2005 22:08:54 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKoVT-00076s-7l for ltru@ietf.org; Sun, 10 Apr 2005 22:18:32 -0400 Received: from lns-p19-1-idf-82-251-94-206.adsl.proxad.net ([82.251.94.206] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKoM9-0001cL-DN; Sun, 10 Apr 2005 19:08:53 -0700 Message-Id: <6.1.2.0.2.20050411014505.03b5b070@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 11 Apr 2005 01:57:20 +0200 To: Frank Ellermann From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Comment: use VU for Vanuatu In-Reply-To: <4259A8DC.7B7F@xyzzy.claranet.de> References: <20050410193803.JRSC4900.mta8.adelphia.net@megatron.ietf.org> <001601c53e14$9c641580$030aa8c0@DEWELL> <4259A8DC.7B7F@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On 00:29 11/04/2005, Frank Ellermann said: > > I see that ticket #895 was never resolved: > > http://www1.ietf.org/mail-archive/web/ltru/current/msg00749.html > >As far as I'm concerned it is resolved, all pre-date-B issues >were resolved by your date-A = 1988 proposal. No idea why >Jefsey wants to keep it open or reopen it, or why Randy didn't >mark it as closed yet. I documented that. We started using ISO 3166 in 1977 unformally (what permitted UK) and formally in 1978. As documented on this list langtags cover much more than XML and even IETF matters. The system must be consistent with any ISO 3166 table, concerning whatever period of the past, present and future. The 1988 could have been used to pre-load data (and I agreed then to the idea), but the way the things are understood now, make plain that there is a confusion between an occasional file and a principle. There is no point in the Charter opposing that. Languages are not born in 1988. I documented that I favor the use of a 2 bytes yearly code, covering years -32.000 to +32.000 jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 22:09:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11540; Sun, 10 Apr 2005 22:09:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKoWT-00077m-9h; Sun, 10 Apr 2005 22:19:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKoMF-0007SE-GM; Sun, 10 Apr 2005 22:08:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKoMB-0007Rz-PU for ltru@megatron.ietf.org; Sun, 10 Apr 2005 22:08:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11455 for ; Sun, 10 Apr 2005 22:08:53 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKoVS-00076p-Ga for ltru@ietf.org; Sun, 10 Apr 2005 22:18:32 -0400 Received: from lns-p19-1-idf-82-251-94-206.adsl.proxad.net ([82.251.94.206] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKoM8-0001cL-4a; Sun, 10 Apr 2005 19:08:52 -0700 Message-Id: <6.1.2.0.2.20050411013129.03b5d8a0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 11 Apr 2005 01:44:22 +0200 To: Frank Ellermann From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: seeking resolution of the Great Script Debate In-Reply-To: <42598B51.3AD0@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@irvmbxw01.quest.com> <42595842.175B@xyzzy.claranet.de> <6.1.2.0.2.20050410193918.0d319910@mail.jefsey.com> <42598B51.3AD0@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Dear Frank, I understand that the X(HT)ML applications have debate enough on the matter to permit this WG to feel free about them, as long as it fullfils its Charter assigned role to permit a consistent solution. On 22:23 10/04/2005, Frank Ellermann said: > > we are here to specify network protocol related issues >Actually we are here to specify a new language tag registry. If we can make the proposed language tag registry useful outside of the Internet standard process, all the best. But this is the IETF and we are concerned by protocols, procedures and best common practices. >Debbie said, that she would like another dimension "charset" >in these crazy tags, but now we're looking at solutions without >script (less dimensions). Nothing promises to be the "best for >all" solution. That forces us to find the least harmful exit. I do not think we are boud to a least harmful exit. Experiences in that area like IPv6, IDNA, etc. did not result into something really appealing. I think we can certainly find a good, stable and innovative for all solution. >Please drop the idea to abuse DNS to get combined language tag >registry entries, at least not in a form languages * scripts * >regions * variants, that's horrible. May be could you comment that more in detail? In the way you understand it. Thank you. I do not think my idea is to abuse DNS. I documented our need. I documented our solution. I did not document yet our information dissemination strategy. I need to understand first what Addison has to explain. I suppose we also need more involvement in this WG. As Addison explained it well, if you do not involve/hurt the people who may oppose you, you will upset them and you will never get their support. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 22:10:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11567; Sun, 10 Apr 2005 22:10:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKoWt-00078A-KT; Sun, 10 Apr 2005 22:19:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKoMB-0007Rv-D9; Sun, 10 Apr 2005 22:08:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKoMA-0007Rq-OK for ltru@megatron.ietf.org; Sun, 10 Apr 2005 22:08:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11452 for ; Sun, 10 Apr 2005 22:08:52 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKoVR-00073F-3n for ltru@ietf.org; Sun, 10 Apr 2005 22:18:30 -0400 Received: from lns-p19-1-idf-82-251-94-206.adsl.proxad.net ([82.251.94.206] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKoM6-0001cL-Pm; Sun, 10 Apr 2005 19:08:51 -0700 Message-Id: <6.1.2.0.2.20050411011604.03b48420@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 11 Apr 2005 04:08:34 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Comment: use VU for Vanuatu (was: remove region subtag 200) In-Reply-To: <000f01c53e0b$de9b28c0$030aa8c0@DEWELL> References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> <004a01c53df0$786d46c0$030aa8c0@DEWELL> <6.1.2.0.2.20050410194819.0d2fbbd0@mail.jefsey.com> <000f01c53e0b$de9b28c0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa At 22:28 10/04/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > > On 19:12 10/04/2005, Doug Ewell said: > > ... The draft seeks to remove or reduce that > > >instability by introducing a stable layer on top of it... > > > > I would be very interested in your description of this layer. The > > draft proposes a tag layer where the tag = "ISO 639"+"ISO 15924"+"ISO > > 3166". I fail to understand how tag is independent from a change in > > one of the ISO subtags. > >This is one of the fundamental features of the draft, and has been >discussed at great length. > >The subtags are BASED ON code elements in ISO standards, but may deviate >from them to preserve stability when the ISO code elements are changed, >and especially so when they are reused. Dear Doug, This means (I obviously assume big changes which are claimed never to happen :-) that nothing opposes that fra-Cyrl-US would still mean French writen in Cyrilic as spoken in the USA - while fra may have changed in that far future to Franglish, Cyrl to Cypriot revision of Latin and US to United States of Australia. - this is IETF not ISO and no position by ISO can be taken for granted: we have no control. - the draft precisely wants a solution which rules out any risk of that kind - this is indeed a fundamental features of the Draft, and that it has been discussed at great length. This does not change anything to it. This WG is to discuss Drafts only to address its Charter. You document that the draft does not match the charter. I noted that, and also the conflict in the charter which calls for an independence from the ISO evolutions and the possibility to identify the subtags in the tag. IMHO this calls for a request of guidance to the IESG if the debate on the charter (we still need to have, as Randy underlined it) does not deliver a solution. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 22:53:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13791; Sun, 10 Apr 2005 22:53:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKpCu-00005R-SY; Sun, 10 Apr 2005 23:03:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKp2o-0001ca-Qt; Sun, 10 Apr 2005 22:52:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKp2m-0001cV-Kj for ltru@megatron.ietf.org; Sun, 10 Apr 2005 22:52:56 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13683 for ; Sun, 10 Apr 2005 22:52:53 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DKozs-0007En-5h for ltru@lists.ietf.org; Mon, 11 Apr 2005 04:49:56 +0200 Received: from du-001-154.access.de.clara.net ([212.82.227.154]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 04:49:56 +0200 Received: from nobody by du-001-154.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 04:49:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 11 Apr 2005 04:51:07 +0200 Organization: Lines: 16 Message-ID: <4259E61B.1AA5@xyzzy.claranet.de> References: <20050410193803.JRSC4900.mta8.adelphia.net@megatron.ietf.org> <001601c53e14$9c641580$030aa8c0@DEWELL> <4259A8DC.7B7F@xyzzy.claranet.de> <6.1.2.0.2.20050411014505.03b5b070@mail.jefsey.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: du-001-154.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Comment: use VU for Vanuatu X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > We started using ISO 3166 in 1977 unformally I've no idea who this "we" is, and I don't care who it is, but if your TINW still uses ISO 3166-1 today, then it does not use any ISO 3166-1 alpha-2 codes deprecated in the stoneage before date-A. Your TINW also doesn't use crap like BU, DD, VD, or the old CS today, because your TINW would be in deep shit for the new CS, the new GE, the new SK, and so on. If your TINW uses ISO 3166-1 today, it either uses the valid codes today, or it uses its own private vision derived from an old ISO 3166-1. Please no courtesy copies, I read the list and don't want it partially mirrored in my inbox. TINW = "there is no we", bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sun Apr 10 23:22:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15210; Sun, 10 Apr 2005 23:22:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKpea-00011z-Ox; Sun, 10 Apr 2005 23:32:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKpUz-0003Ep-4u; Sun, 10 Apr 2005 23:22:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKpUw-0003Ej-PR for ltru@megatron.ietf.org; Sun, 10 Apr 2005 23:22:03 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15202 for ; Sun, 10 Apr 2005 23:21:59 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DKpS5-0000Tb-0t for ltru@lists.ietf.org; Mon, 11 Apr 2005 05:19:05 +0200 Received: from du-001-154.access.de.clara.net ([212.82.227.154]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 05:19:05 +0200 Received: from nobody by du-001-154.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 05:19:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 11 Apr 2005 05:18:35 +0200 Organization: Lines: 32 Message-ID: <4259EC8B.5E95@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@irvmbxw01.quest.com> <42595842.175B@xyzzy.claranet.de> <6.1.2.0.2.20050410193918.0d319910@mail.jefsey.com> <42598B51.3AD0@xyzzy.claranet.de> <6.1.2.0.2.20050411013129.03b5d8a0@mail.jefsey.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: du-001-154.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: seeking resolution of the Great Script Debate X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > May be could you comment that more in detail? In the way you > understand it. I do NOT understand you. You wanted to replace "-" by "." in the 3066bis tags, but 1766 & 3066 use "-". You had a problem with "--" because it's used in certain IDNA labels, but Doug only used "--" like the HH in 3166-3 (= "no single successor"), Doug's "--" has nothing to do with any 3066bis language tag. Finally you repeated weird calculations languages * scripts * regions * variants, I've not the faintest idea what you were talking about, but you kept mentioning "DNS" in this context. So I guessed that you plan to build something like a tag tree, maybe translating all possible language-script-region-variant into some variant.region.script.language.jefsey.example RRs (?) If that guess was wrong just ignore it. > I documented our need. I documented our solution. Please stop the pluralis majestatis TINW "our", what solution are you talking about, is it a standard or RfC, or is it your CD ROM with some IANA registries ? If it's the latter just copy the future IANA registry as is, and don't explode it into a languages * scripts * regions * variants tree with numerous bogus leaves like zh-Cans-BU-scouse. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 01:18:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20865; Mon, 11 Apr 2005 01:18:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKrSk-0004gw-DG; Mon, 11 Apr 2005 01:27:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKrJ4-0001y6-6A; Mon, 11 Apr 2005 01:17:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKrJ1-0001xy-P1 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 01:17:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20838 for ; Mon, 11 Apr 2005 01:17:50 -0400 (EDT) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKrSL-0004eq-36 for ltru@ietf.org; Mon, 11 Apr 2005 01:27:29 -0400 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050411051737.EBLY2192.mta9.adelphia.net@DEWELL> for ; Mon, 11 Apr 2005 01:17:37 -0400 Message-ID: <000d01c53e55$aa5a15e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> <004a01c53df0$786d46c0$030aa8c0@DEWELL> <6.1.2.0.2.20050410194819.0d2fbbd0@mail.jefsey.com> <000f01c53e0b$de9b28c0$030aa8c0@DEWELL> <6.1.2.0.2.20050411011604.03b48420@mail.jefsey.com> Date: Sun, 10 Apr 2005 22:16:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Comment: use VU for Vanuatu (was: remove region subtag 200) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > This means (I obviously assume big changes which are claimed never to > happen :-) that nothing opposes that fra-Cyrl-US would still mean > French writen in Cyrilic as spoken in the USA - while fra may have > changed in that far future to Franglish, Cyrl to Cypriot revision of > Latin and US to United States of Australia. Correct, except that the language subtag in question would be 'fr', not 'fra'. > - this is IETF not ISO and no position by ISO can be taken for > granted: we have no control. Correct. > - the draft precisely wants a solution which rules out any risk of > that kind Correct. > - this is indeed a fundamental features of the Draft, and that it has > been discussed at great length. This does not change anything to it. > This WG is to discuss Drafts only to address its Charter. Correct. > You document that the draft does not match the charter. Absolutely FALSE. How can you possibly reach that conclusion? The charter says: "For stability, it is expected that the document will describe how the meaning of language tags remains stable, even if underlying references should change, and how the structure is to remain stable in the future." Decoupling the subtags in the registry from strict adherence to the ISO standards is how the draft achieves this goal. > I noted that, and also the conflict in the charter which calls for an > independence from the ISO evolutions and the possibility to identify > the subtags in the tag. For God's sake. The length and position of subtags within the tag identify their type, and the description fields in the registry identify their meaning. > IMHO this calls for a request of guidance to the IESG if the debate on > the charter (we still need to have, as Randy underlined it) does not > deliver a solution. Every day you amaze me more. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 01:34:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21564; Mon, 11 Apr 2005 01:34:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKriG-00050H-CU; Mon, 11 Apr 2005 01:43:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKrYX-00031C-CS; Mon, 11 Apr 2005 01:33:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKrYV-000314-On for ltru@megatron.ietf.org; Mon, 11 Apr 2005 01:33:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21543 for ; Mon, 11 Apr 2005 01:33:50 -0400 (EDT) Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKrhp-0004zm-8K for ltru@ietf.org; Mon, 11 Apr 2005 01:43:29 -0400 Received: from korppi.cs.tut.fi (korppi.cs.tut.fi [130.230.4.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.tut.fi (Postfix) with ESMTP id BB3CDDD3 for ; Mon, 11 Apr 2005 08:33:40 +0300 (EEST) Date: Mon, 11 Apr 2005 08:33:39 +0300 (EEST) From: "Jukka K. Korpela" To: ltru@ietf.org Subject: Re: [Ltru] Re: seeking resolution of the Great Script Debate In-Reply-To: <42598B51.3AD0@xyzzy.claranet.de> Message-ID: References: <634978A7DF025A40BFEF33EB191E13BC0AFA3A9C@irvmbxw01.quest.com> <42595842.175B@xyzzy.claranet.de> <6.1.2.0.2.20050410193918.0d319910@mail.jefsey.com> <42598B51.3AD0@xyzzy.claranet.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On Sun, 10 Apr 2005, Frank Ellermann wrote: > OTOH all document formats based on XML are free to add their > own attributes, e.g. XHTML 1.0 has its own "lang" (inherited > from HTML) in addition to the "xml:lang". Indeed, and some relevant recommendation could even suggest that _if_ you implement something in XML, then you should do it in a such-and-such a way, like using a particular attribute name. But you could not easily make a new attribute part of the xml namespace ("part of XML itself", to speak loosely). > It would be really nice if we could squeeze the script somehow > in the existing language tags. But if Ned says NO because he > knows a case where it would cause harm it's a serious problem. There's the possibility of specifying script separately and not fixing how that information is stored and sent. After all, language codes too can be used in a multitude of ways. > > we cannot accept Jukka's "It would take too much time to > > explain all the conceptual errors involved" comment > > That was probably only a misunderstandig, he feared that I > don't know what a Content-Script-Type is Well, maybe in part that too, but basically I was afraid the discussion would take us to side paths that lead nowhere. For example, tags aren't really the way to specify language or charset or content type, so I missed the point in using them as (or in) arguments in this discussion looked off. -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 01:56:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22713; Mon, 11 Apr 2005 01:56:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKs3W-0005SI-6I; Mon, 11 Apr 2005 02:05:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKrtF-0004St-BL; Mon, 11 Apr 2005 01:55:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKrtC-0004Qf-U2 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 01:55:15 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22690 for ; Mon, 11 Apr 2005 01:55:11 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050411055441.ZVDR5402.mta11.adelphia.net@DEWELL> for ; Mon, 11 Apr 2005 01:54:41 -0400 Message-ID: <009401c53e5a$cc7dc360$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050406191319.GBPY2135.mta2.adelphia.net@megatron.ietf.org> <002c01c53b40$9b68a780$030aa8c0@DEWELL> <6.1.2.0.2.20050407151257.05072eb0@mail.jefsey.com> <006501c53bfa$539ba820$030aa8c0@DEWELL> <6.1.2.0.2.20050408171453.03390d70@mail.jefsey.com> Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Date: Sun, 10 Apr 2005 22:53: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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > On 07:17 08/04/2005, Doug Ewell said: > >> 479 times (104 + 1) times (285 + 1) times (10 + 1) equals >> 143,843,700. >> >> Off by a factor of 10 (for which I apologize), but this is still not >> "billions," and I still contend that 99% of these are ridiculous. > > 1. we agree that we include all the "ridiculous" one, this means we > discuss of the mathematical max. So we cannot disagree on computation. > > 2. we disagree on the figures. What is exactly the whole issue: > - you talk of ISO 639 479 languages, when I say 7.620 ISO 639-3 > or 20.000 ISO 639-6 plus all those registered on the IANA (the reason > why we discuss an RFC) probably millions. As a reminder to all, this traces back to a comment by Ira McDonald on April 6 that "LTRU is developing an IANA registry of EVERY possible valid language tag" [1]. As I said at the time, and Ira conceded this was true, LTRU is actually developing a registry of each subtag, which is numerically quite a different task. Since we are talking about what LTRU is doing, not what LTRU will do in the future or may never do, it follows that I was talking about ISO 639-1 and -2, not about 639-3 or 639-6 respectively. > - 104 scripts - which I consider as absurd when we know the real > life scripting variations. IDN Tables may represent 3 to 40.000 A script is a writing system used to notate language. There are 104 of these in the registry, based on the codes in ISO 15924, which uses the definition of "script" accepted by almost all authorities. It is not likely that there have been more than a few hundred widely used scripts throughout all of history. Each possible combination of letters used by a given language, country, society, or human being does not constitute a different "script." I don't know what exactly it is that IDN tables represent up to 40,000 of, but since we are talking about what LTRU is doing, I did not count them. > - 285 region subtags - where I consider _at_least_ ISO-3166-2 Since we are talking about what LTRU is doing, I did not include the number of codes allocated in ISO 3166-2, UN/LOCODE, MARC 21, FIPS 55-3, or any other geographic coding system not used in LTRU. > 3. this being said, I would be quite interested in understanding what > you list as the 10 variant subtags? Why, the ones in the registry: 1901, 1996, boont, gaulish, guoyu, hakka, nedis, rozaj, scouse, and xiang. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ [1] http://www1.ietf.org/mail-archive/web/ltru/current/msg00595.html _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 05:13:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24416; Mon, 11 Apr 2005 05:13:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKv8h-0001YR-SW; Mon, 11 Apr 2005 05:23:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKuvH-0000lK-9g; Mon, 11 Apr 2005 05:09:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKuvG-0000l1-7I for ltru@megatron.ietf.org; Mon, 11 Apr 2005 05:09:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24110 for ; Mon, 11 Apr 2005 05:09:23 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKv4S-0001TG-IA for ltru@ietf.org; Mon, 11 Apr 2005 05:19:05 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Mon, 11 Apr 2005 10:08:33 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 10:08:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Compatibility with existing use (LDAP) Date: Mon, 11 Apr 2005 10:08:13 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A2F4@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU9JKX60/5BCAYfS7CAPN38LxXUbABUTmMQ From: "L.Gillam" To: ltru X-OriginalArrivalTime: 11 Apr 2005 09:08:13.0548 (UTC) FILETIME=[FD869AC0:01C53E75] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable > FYI the logical network multilingual layers come in the=20 > following order : >=20 > - script so you can write each other strings > - language so you can read each other commands Commands? Do you mean e.g. SMTP commands? That's hardly a "natural" language. > - geolegal so you know the applying rules ... this permits=20 > interoperationality Laws apply to my use of language? Beyond libel, what is there? > - referent so you can understand each other ... this permits=20 > interintellegibility Unclear what this "referent" is. > - the vernacular style/practice so you can work together ...=20 > this permits=20 > interusability. Again unclear. > If you really want to make it a formated langtag it should be=20 > script-language-country (in your parlance [4-]3-2 character=20 > strings, with=20 > 2 characters being acceptable in 1st position and script=20 > preposition being=20 > optional. This is what we should have in the IDNA and the big=20 > mistake was=20 > to put it in a different order, not understanding that the=20 > Internet is=20 > actually the ASCII class of the Multilingual Internet system. >=20 > jfc Until this message gets registered, "Multilingual Internet system" is a one-hit-wonder (google). _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 05:31:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25558; Mon, 11 Apr 2005 05:31:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKvPQ-0001wG-NE; Mon, 11 Apr 2005 05:40:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKvDr-0002CU-I4; Mon, 11 Apr 2005 05:28:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKvDq-00024J-07 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 05:28:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21973 for ; Mon, 11 Apr 2005 04:37:27 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKuZZ-0000iD-7N for ltru@ietf.org; Mon, 11 Apr 2005 04:47:09 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Mon, 11 Apr 2005 09:24:42 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 09:24:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: registry should copy non-English fields from ISO documents Date: Mon, 11 Apr 2005 09:28:43 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A2EA@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: registry should copy non-English fields from ISO documents Thread-Index: AcU+BuBB2jLJYjueTUipf8VzNUuhlgAZV8GA From: "L.Gillam" To: ltru X-OriginalArrivalTime: 11 Apr 2005 08:24:41.0329 (UTC) FILETIME=[E8859E10:01C53E6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable John, > > 1. A "reference name" is for interoperability. The=20 > reference name for > > a language can be taken from that language, and need not be=20 > in either > > English or French, as I believe Peter was alluding to. I=20 > believe this to > > be the case with -3 and it's certainly intended for -6.=20 >=20 > ISO 639-3 reference names are English names (which may in=20 > many cases be > identical to native names, but only when there is no=20 > traditional English > name). "French", "German", "Chinese" are so named. This=20 > reflects 639-3's > inheritance from the Ethnologue. Note also that many 639-3 languages > have no written form, and would have to have the names transcribed in > some system rather than simply written. "need not be in either English or French". See below. > > 3. A code (e.g. alpha3 in 639-3) stands as synonymous with=20 > the reference > > name and as entry point into the "conceptual" entry - the mantra is > > "I don't care what you call it as long as we are referring to the > > same thing" >=20 > The code points to the name, but the name does not always=20 > unambiguously > point to the language. In ISO 639-1/2 (which are unambiguously > mapped, so I treat them as one), there is the language coded "zh" or > "chi" or "zho" and named "Chinese" and "chinois". But there is no > way of knowing whether that means: >=20 > 1) Mandarin Chinese, a specific Sinitic language > 2) The Sinitic languages as a collection > 3) The languages called "Chinese" as a collection > 4) A macrolanguage incorporating the Sinitic languages as components > 5) A macrolanguage incorporating the languages called=20 > "Chinese" as components >=20 > ISO 639-3 takes position 5. This is why I referred to a "conceptual" entry. One "term" for one = "concept" is a terminological ideal. Multiple codes leading into an ambiguous = entry requires one of 1-5 possible interpretations as above.=20 > > ensuring -4 has necessary and sufficient coverage. >=20 > >From what I understand (I have not seen a draft), -4 will be=20 > conceptual > and introductory (-0, in other words, if ISO rules permitted=20 > a -0 part) > and will not provide coverage of anything. Has this changed? That it will not provide coverage of anything? Certainly!=20 Presentations have been made of a "Language Description Framework"=20 in ISO TC37 SC2 (by Laurent Romary). I may be able to dig out a=20 copy if you are interested.=20 It has to identify what it is principles/concepts/introduction OF,=20 and how it applies. For example, a general principle of a "reference=20 name" could be that it can be used as a unique and unambiguous=20 "language-independent" identifier for a language that.=20 "language-independent": not necessarily bound to English or French. > > The question, as I see it, becomes: > > ISO code lists already contain French and English names. If=20 > the registry > > identifies the code list and the code, does it really need=20 > to duplicate > > all the fields from this list?=20 >=20 > There is no evidence which name is the reference name, however. The item you identified above ("Chinese") has 3 codes, multiple names and various criteria. One "view" into the code scheme is via=20 the "alpha-2 if available, (one of) alpha-3 otherwise" rule. It is not necessarily the only view. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 06:09:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28363; Mon, 11 Apr 2005 06:09:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKw0X-0002w4-Ng; Mon, 11 Apr 2005 06:19:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKvom-0005Oe-7L; Mon, 11 Apr 2005 06:06:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKvih-0004dz-Dt for ltru@megatron.ietf.org; Mon, 11 Apr 2005 06:00:39 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19240 for ; Mon, 11 Apr 2005 03:43:03 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050411074231.TTBX7277.mta10.adelphia.net@DEWELL> for ; Mon, 11 Apr 2005 03:42:31 -0400 Message-ID: <009c01c53e69$feef21e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 11 Apr 2005 00:42:20 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] New registry 2005-04-08 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit I've posted a new draft registry, dated April 8, which includes the following changes from the April 6 version: 1. The field "Date:" has been replaced by "Added:". 2. Non-ASCII escaping has been changed from the idiosyncratic "/uxxxx" format to the XML-compliant "&#xXXXX;" format. Note that two-digit hex codes are used whenever possible, which means "always" for the current version since descriptions are limited to Latin-1 and no other fields currently have non-ASCII. 3. The characters : (colon) and ; (semicolon) are no longer subject to the escape sequence. 4. The dash-dash value "--" for the Canonical field has been removed. 5. Some of the language and script names have been modified to take advantage of Latin-1 instead of just ASCII. All descriptions for language, script, and region subtags now reflect the underlying ISO or UN standards, except when the external standard itself goes beyond ASCII. 6. The line termination sequence is now unequivocally CRLF. 7. Line continuation is now denoted by a CRLF followed by two spaces. Note that multiple spaces within a subtag are collapsed to a single space. All of these changes are included in the draft-01 currently posted on Addison's site. The new registry, like all others before it, is available at http://users.adelphia.net/~dewell/lstreg.txt. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 06:30:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29642; Mon, 11 Apr 2005 06:30:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKwLL-0003Ng-Iz; Mon, 11 Apr 2005 06:40:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKw6m-0006wL-6z; Mon, 11 Apr 2005 06:25:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKw6l-0006vn-4W for ltru@megatron.ietf.org; Mon, 11 Apr 2005 06:25:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29377 for ; Mon, 11 Apr 2005 06:25:19 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKwFy-0003G1-4q for ltru@ietf.org; Mon, 11 Apr 2005 06:35:03 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Mon, 11 Apr 2005 11:23:47 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 11:23:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: registry should copy non-English fields fromISO documents Date: Mon, 11 Apr 2005 11:23:45 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A2FB@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: registry should copy non-English fields fromISO documents Thread-Index: AcU9JYE3/8pPAhkyQ/m21awJ0oTUwABWtoyg From: "L.Gillam" To: ltru X-OriginalArrivalTime: 11 Apr 2005 10:23:46.0267 (UTC) FILETIME=[8B3CA2B0:01C53E80] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Consensus or unanimous consensus? We should be clear about which is required. If it's only consensus, Peter is absolutely correct. What voices do you hear? > On 14:04 09/04/2005, Peter Constable said: > >I believe if you are the only one on this list not in=20 > agreement, that we > >have a consensus. >=20 > True. But you have not if I am in disagreement. And I am in=20 > disagreement. > But the real point is this is not because that this list=20 > humms something=20 > that the world will consent. > I tend to think we should listen to the world rather than=20 > expect the world=20 > will want to listen to us. > Not just to study it? > jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 06:46:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01174; Mon, 11 Apr 2005 06:46:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKwaG-0003m8-Vi; Mon, 11 Apr 2005 06:56:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKwPN-00005P-SX; Mon, 11 Apr 2005 06:44:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKwPM-0008VH-NX for ltru@megatron.ietf.org; Mon, 11 Apr 2005 06:44:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00948 for ; Mon, 11 Apr 2005 06:44:17 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKwYK-0003il-4o for ltru@ietf.org; Mon, 11 Apr 2005 06:54:01 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Mon, 11 Apr 2005 11:33:04 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 11:33:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Comment: use VU for Vanuatu (was: remove region subtag 200) Date: Mon, 11 Apr 2005 11:33:03 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A2FD@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: Comment: use VU for Vanuatu (was: remove region subtag 200) Thread-Index: AcU+BQBN4Hz1V1OfRd+JHdDywHKqPAAfY/zw From: "L.Gillam" To: ltru X-OriginalArrivalTime: 11 Apr 2005 10:33:03.0645 (UTC) FILETIME=[D775C4D0:01C53E81] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Which neither exists, nor has sources supporting its or use by any other party. As to stability, standardization, interoperability .......? > An independent layer would be xml:lang=3D"jefsey-2005" and=20 > "jefsey-2005"=20 > being documented at http://jefsey.langtags.org. > jfc=20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 07:00:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01856; Mon, 11 Apr 2005 07:00:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKwnb-00044j-3K; Mon, 11 Apr 2005 07:09:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKwVv-0000mT-1n; Mon, 11 Apr 2005 06:51:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKwVu-0000mC-GS for ltru@megatron.ietf.org; Mon, 11 Apr 2005 06:51:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01510 for ; Mon, 11 Apr 2005 06:51:19 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKwf9-0003tx-0p for ltru@ietf.org; Mon, 11 Apr 2005 07:01:03 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Mon, 11 Apr 2005 11:37:05 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 11:37:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] language or price tag ? Date: Mon, 11 Apr 2005 11:37:03 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A2FE@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] language or price tag ? Thread-Index: AcU+BQznvtUiWWpuTfmow/jXDL85qgAfcaqw From: "L.Gillam" To: ltru X-OriginalArrivalTime: 11 Apr 2005 10:37:03.0971 (UTC) FILETIME=[66B49B30:01C53E82] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable > At 20:02 10/04/2005, Doug Ewell wrote: > >JFC (Jefsey) Morfin wrote: > > > Our charter is not to rebuild the world (as some seems to want it) > >I would like to ask that these baseless insinuations about world > >domination come to an immediate end. We're talking about short > >alphanumeric language tags. >=20 > shhhhh... this becomes tiring. But I will try another time to=20 > kindly try to=20 > make you understand from your own words. Talking about=20 > "short" alphanumeric=20 > language tags to describe the extreme variety of the real=20 > human world _IS_=20 > rebuilding the world. No. There is a difference between "rebuilding the world" and = representing what is perceived by many to exist in the world. You cannot physically put a brick into a database - you should be able to prove this to = yourself using a short physical experiment. As you will discover, you can only = put=20 representatives of the brick into the database.=20 Your statement you seem to dismiss every single classification system = known. > jfc >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 08:45:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10227; Mon, 11 Apr 2005 08:45:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKyRS-00071B-UI; Mon, 11 Apr 2005 08:55:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKyEN-00015o-NJ; Mon, 11 Apr 2005 08:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKyEM-000159-Gk for ltru@megatron.ietf.org; Mon, 11 Apr 2005 08:41:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09924 for ; Mon, 11 Apr 2005 08:41:20 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKyNb-0006uB-2W for ltru@ietf.org; Mon, 11 Apr 2005 08:51:04 -0400 Received: from lns-p19-1-idf-82-251-94-206.adsl.proxad.net ([82.251.94.206] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKyEB-0006gq-WA for ltru@ietf.org; Mon, 11 Apr 2005 05:41:20 -0700 Message-Id: <6.1.2.0.2.20050411110551.043c6860@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 11 Apr 2005 14:41:02 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) In-Reply-To: <009401c53e5a$cc7dc360$030aa8c0@DEWELL> References: <20050406191319.GBPY2135.mta2.adelphia.net@megatron.ietf.org> <002c01c53b40$9b68a780$030aa8c0@DEWELL> <6.1.2.0.2.20050407151257.05072eb0@mail.jefsey.com> <006501c53bfa$539ba820$030aa8c0@DEWELL> <6.1.2.0.2.20050408171453.03390d70@mail.jefsey.com> <009401c53e5a$cc7dc360$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On 07:53 11/04/2005, Doug Ewell said: > > 3. this being said, I would be quite interested in understanding what > > you list as the 10 variant subtags? > >Why, the ones in the registry: 1901, 1996, boont, gaulish, guoyu, hakka, >nedis, rozaj, scouse, and xiang. Since the number of direct possibilities you give a maximum limit for is directly related (by multiplication) to their number, should I understand you assume that this list extinguishes all the possibilities? Or that the mximum number (as when you consider ISO 639) is only related to the present status of approved documents. In this case I would agree that your figure accurately represents the current administrative maximum, while I am refering to a probable maximum of the real world. The administrative maximum starting from your figure when preloading the database to reach mine once the IANA's register has stabilized. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 08:45:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10304; Mon, 11 Apr 2005 08:45:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKyRn-00072T-Nl; Mon, 11 Apr 2005 08:55:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKyEN-00015k-H0; Mon, 11 Apr 2005 08:41:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKyEM-000158-BF for ltru@megatron.ietf.org; Mon, 11 Apr 2005 08:41:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09921 for ; Mon, 11 Apr 2005 08:41:20 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKyNb-0006uD-Pn for ltru@ietf.org; Mon, 11 Apr 2005 08:51:04 -0400 Received: from lns-p19-1-idf-82-251-94-206.adsl.proxad.net ([82.251.94.206] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKyEC-0006gq-Uq for ltru@ietf.org; Mon, 11 Apr 2005 05:41:21 -0700 Message-Id: <6.1.2.0.2.20050411113258.03afd520@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 11 Apr 2005 11:51:15 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" In-Reply-To: <000d01c53e55$aa5a15e0$030aa8c0@DEWELL> References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org> <004a01c53df0$786d46c0$030aa8c0@DEWELL> <6.1.2.0.2.20050410194819.0d2fbbd0@mail.jefsey.com> <000f01c53e0b$de9b28c0$030aa8c0@DEWELL> <6.1.2.0.2.20050411011604.03b48420@mail.jefsey.com> <000d01c53e55$aa5a15e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Subject: [Ltru] Is there a consensus ? (was: Comment: use VU for Vanuatu (was: remove region subtag 200)) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Dear Doug, I thank you for this loyal and clear response, where you show that a tag could mean something totally different from what it would mean if it was currently built according to the current ISO standard, and that you fully support to such a proposition. I did not considered the conflicts or confusion in IANA registration during the ISO standard evolution, but I suppose your response would be the same. Since you are one of the most competent, active and acknowledged members of this Working Group, I am interested to know if - me apart - this is the consensus of this Working Group? jfc On 07:16 11/04/2005, Doug Ewell said: >JFC (Jefsey) Morfin wrote: > > > This means (I obviously assume big changes which are claimed never to > > happen :-) that nothing opposes that fra-Cyrl-US would still mean > > French writen in Cyrilic as spoken in the USA - while fra may have > > changed in that far future to Franglish, Cyrl to Cypriot revision of > > Latin and US to United States of Australia. > >Correct, except that the language subtag in question would be 'fr', not >'fra'. > > > - this is IETF not ISO and no position by ISO can be taken for > > granted: we have no control. > >Correct. > > > - the draft precisely wants a solution which rules out any risk of > > that kind > >Correct. > > > - this is indeed a fundamental features of the Draft, and that it has > > been discussed at great length. This does not change anything to it. > > This WG is to discuss Drafts only to address its Charter. > >Correct. > > > You document that the draft does not match the charter. > >Absolutely FALSE. How can you possibly reach that conclusion? The >charter says: > >"For stability, it is expected that the document will describe how the >meaning of language tags remains stable, even if underlying references >should change, and how the structure is to remain stable in the future." > >Decoupling the subtags in the registry from strict adherence to the ISO >standards is how the draft achieves this goal. > > > I noted that, and also the conflict in the charter which calls for an > > independence from the ISO evolutions and the possibility to identify > > the subtags in the tag. > >For God's sake. The length and position of subtags within the tag >identify their type, and the description fields in the registry identify >their meaning. > > > IMHO this calls for a request of guidance to the IESG if the debate on > > the charter (we still need to have, as Randy underlined it) does not > > deliver a solution. > >Every day you amaze me more. > >-Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 08:47:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10447; Mon, 11 Apr 2005 08:47:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKyT9-000759-Pb; Mon, 11 Apr 2005 08:56:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKyEc-00016z-1v; Mon, 11 Apr 2005 08:41:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKyEP-00015D-Ba for ltru@megatron.ietf.org; Mon, 11 Apr 2005 08:41:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09927 for ; Mon, 11 Apr 2005 08:41:23 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKyNd-0006uJ-RI for ltru@ietf.org; Mon, 11 Apr 2005 08:51:07 -0400 Received: from lns-p19-1-idf-82-251-94-206.adsl.proxad.net ([82.251.94.206] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKyEE-0006gq-UX for ltru@ietf.org; Mon, 11 Apr 2005 05:41:23 -0700 Message-Id: <6.1.2.0.2.20050411140509.030922f0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 11 Apr 2005 14:25:52 +0200 To: ltru From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] language or price tag ? In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A2FE@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A21292A2FE@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 At 12:37 11/04/2005, L.Gillam wrote: > > Talking about "short" alphanumeric language tags to describe the > extreme variety of the real human world _IS_ rebuilding the world. > >No. There is a difference between "rebuilding the world" and representing >what is perceived by many to exist in the world. You cannot physically put >a brick into a database - you should be able to prove this to yourself >using a short physical experiment. As you will discover, you can only put >representatives of the brick into the database. > >Your statement you seem to dismiss every single classification system known. Objecting for the fun of it is usually of no real use to a debate, but sometimes brings some humour. Experience shows that usually humour results from a brillant mental twist after having well understood the adversary position and challenging his own IQ. Here it seems you failed to see I say the unreality of the rebuilt world results from the underlined "short", not from the representation paradigm. A system where 350 millions of English speaking American, 56 English speaking Pitcairn Islanders and the single may be English speaking Pinguin from Kergelen benefit from the same level of unique geopolitical subtag, seems a representation of languages at odds wiht the real world. But may be we are from different planets? You see, I can only repeat the old say "not all RFC make a standard", because standards call for proven applications to the market. Here we are supposed to document a Best Common (therefore existing) Practice. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 08:47:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10467; Mon, 11 Apr 2005 08:47:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKyTD-00075D-Uw; Mon, 11 Apr 2005 08:56:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKyEc-000173-8s; Mon, 11 Apr 2005 08:41:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DKyEP-00015I-MX for ltru@megatron.ietf.org; Mon, 11 Apr 2005 08:41:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09930 for ; Mon, 11 Apr 2005 08:41:23 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKyNf-0006uL-02 for ltru@ietf.org; Mon, 11 Apr 2005 08:51:07 -0400 Received: from lns-p19-1-idf-82-251-94-206.adsl.proxad.net ([82.251.94.206] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DKyEF-0006gq-Ux for ltru@ietf.org; Mon, 11 Apr 2005 05:41:24 -0700 Message-Id: <6.1.2.0.2.20050411142724.0314faa0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 11 Apr 2005 14:28:47 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] New registry 2005-04-08 In-Reply-To: <009c01c53e69$feef21e0$030aa8c0@DEWELL> References: <009c01c53e69$feef21e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Thank you. But deontology and verification possibility calls for IPR/sources URI to be quoted. Any problem with it? jfc On 09:42 11/04/2005, Doug Ewell said: >I've posted a new draft registry, dated April 8, which includes the >following changes from the April 6 version: > >1. The field "Date:" has been replaced by "Added:". > >2. Non-ASCII escaping has been changed from the idiosyncratic "/uxxxx" >format to the XML-compliant "&#xXXXX;" format. Note that two-digit hex >codes are used whenever possible, which means "always" for the current >version since descriptions are limited to Latin-1 and no other fields >currently have non-ASCII. > >3. The characters : (colon) and ; (semicolon) are no longer subject to >the escape sequence. > >4. The dash-dash value "--" for the Canonical field has been removed. > >5. Some of the language and script names have been modified to take >advantage of Latin-1 instead of just ASCII. All descriptions for >language, script, and region subtags now reflect the underlying ISO or >UN standards, except when the external standard itself goes beyond >ASCII. > >6. The line termination sequence is now unequivocally CRLF. > >7. Line continuation is now denoted by a CRLF followed by two spaces. >Note that multiple spaces within a subtag are collapsed to a single >space. > >All of these changes are included in the draft-01 currently posted on >Addison's site. > >The new registry, like all others before it, is available at >http://users.adelphia.net/~dewell/lstreg.txt. > >-Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 12:29:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26942; Mon, 11 Apr 2005 12:29:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL1wu-0005Uw-Gy; Mon, 11 Apr 2005 12:39:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL1jF-0000rn-Dv; Mon, 11 Apr 2005 12:25:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL1jD-0000qz-JA for ltru@megatron.ietf.org; Mon, 11 Apr 2005 12:25:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26520 for ; Mon, 11 Apr 2005 12:25:24 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL1sU-0005Jn-2a for ltru@ietf.org; Mon, 11 Apr 2005 12:35:11 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 09:25:16 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 09:25:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] e-GB-scouse (was: Matching metrics) Date: Mon, 11 Apr 2005 09:25:08 -0700 Message-ID: Thread-Topic: [Ltru] e-GB-scouse (was: Matching metrics) Thread-Index: AcU7iudz+ItXWMMMS8GGzYPo8nu+NQBfPOdQ From: "Peter Constable" To: X-OriginalArrivalTime: 11 Apr 2005 16:25:17.0298 (UTC) FILETIME=[0C194D20:01C53EB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > If that's the case we just found another problem of squeezing > four dimensions into one: "scouse" would need a "recommended > prefix" en-GB (implicitly en-*-GB), not only en. How so? If "GB" doesn't add any useful qualification then it's redundant and unnecessary -- just as we wouldn't expect people to add "Latn" to en-GB. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 12:37:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27381; Mon, 11 Apr 2005 12:37:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL24c-0005hD-6p; Mon, 11 Apr 2005 12:47:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL1uY-0002pm-MI; Mon, 11 Apr 2005 12:37:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL1uX-0002ov-8f for ltru@megatron.ietf.org; Mon, 11 Apr 2005 12:37:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27357 for ; Mon, 11 Apr 2005 12:37:05 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL23o-0005gf-OB for ltru@ietf.org; Mon, 11 Apr 2005 12:46:53 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 11 Apr 2005 09:36:59 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 09:36:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Compatibility with existing use (LDAP) Date: Mon, 11 Apr 2005 09:36:54 -0700 Message-ID: Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU9GD2xnvikmupZQkiUpbggbW7sgwBm1ZcQ From: "Peter Constable" To: X-OriginalArrivalTime: 11 Apr 2005 16:36:59.0947 (UTC) FILETIME=[AEE907B0:01C53EB4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable > From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] > > It is a completely invalid to say that "backward compatibility" is being > > broken. >=20 > On the contrary, it is completely demonstrable that that is what is happening. >=20 > > That assumes that backward compatibility is defined in terms of > > certain expectations that have never been guaranteed: that if a second > > subtag exists, it would be a country ID. >=20 > This isn't the expectation. >=20 > > The appropriate way to present > > an argument on this issue is to say that some specific functionality > > would not exist, and then to evaluate in relation to realistic scenarios > > just how great a loss that would be. >=20 > I disagree. It's a big world out there, and it is next to impossible to figure > out what people have done or will do. Ned, you *must* define a specific functionality that isn't working rather than simply declare "back compat is broken": back compat can be defined in different ways, and someone else can (and some have) declared that backward compatibility is maintained with equal validity. If you insist on making blanket statements like this, you will IMO be blocking progress. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 12:39:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27524; Mon, 11 Apr 2005 12:39:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL26Q-0005kt-QS; Mon, 11 Apr 2005 12:49:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL1vO-000307-7y; Mon, 11 Apr 2005 12:38:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL1vL-0002xp-IM for ltru@megatron.ietf.org; Mon, 11 Apr 2005 12:38:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27402 for ; Mon, 11 Apr 2005 12:37:59 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL24f-0005hA-4S for ltru@ietf.org; Mon, 11 Apr 2005 12:47:46 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 09:37:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] New registry 2005-04-08 Date: Mon, 11 Apr 2005 09:37:50 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3D6F@irvmbxw01.quest.com> Thread-Topic: [Ltru] New registry 2005-04-08 Thread-Index: AcU+fqvbMAzGyEoeR/aLnNNNSW/b9QANbZFQ From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 11 Apr 2005 16:37:50.0897 (UTC) FILETIME=[CD476210:01C53EB4] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1051380636==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c --===============1051380636== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGFnYWluLCBEb3VnLCBmb3IgZG9pbmcgaGVyb2ljIHdvcmsgdG8ga2VlcCB0aGUgcmVn aXN0cnkgYW5kIHByb3RvLWRyYWZ0IGluIHN5bmMhDQoNCk9uZSBzbWFsbCBjb21tZW50LiBXaGVu IERvdWcgc2F5czoNCg0KPiBOb3RlIHRoYXQgbXVsdGlwbGUgc3BhY2VzIHdpdGhpbiBhIHN1YnRh ZyBhcmUgY29sbGFwc2VkIHRvIGEgc2luZ2xlDQo+IHNwYWNlLg0KDQpJIGJlbGlldmUgdGhpcyBt ZWFucyAiTm90ZSB0aGF0IHlvdSBzaG91bGQgY29sbGFwc2UgbXVsdGlwbGUgd2hpdGVzcGFjZSBj aGFyYWN0ZXJzIGluIGEgdmFsdWUgKGZpZWxkLWJvZHkgaW4gdGhlIHByb3RvLWRyYWZ0KSB0byBh IHNpbmdsZSBzcGFjZS4iDQoNCk5vdGUgdGhhdCB0aGUgcHJvdG8tZHJhZnQgbm93IGNvbnRhaW5z IEFCTkYgZGVmaW5pbmcgdGhlIHJlZ2lzdHJ5IGZvcm1hdC4NCg0KQmVzdCBSZWdhcmRzLA0KDQpB ZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBR dWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtp bmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlz IGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogbHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3Rz LmlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgRG91ZyBFd2VsbA0KPiBTZW50OiBsdW5kaSAxMSBh dnJpbCAyMDA1IDAwOjQyDQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogW0x0 cnVdIE5ldyByZWdpc3RyeSAyMDA1LTA0LTA4DQo+IA0KPiBJJ3ZlIHBvc3RlZCBhIG5ldyBkcmFm dCByZWdpc3RyeSwgZGF0ZWQgQXByaWwgOCwgd2hpY2ggaW5jbHVkZXMgdGhlDQo+IGZvbGxvd2lu ZyBjaGFuZ2VzIGZyb20gdGhlIEFwcmlsIDYgdmVyc2lvbjoNCj4gDQo+IDEuICBUaGUgZmllbGQg IkRhdGU6IiBoYXMgYmVlbiByZXBsYWNlZCBieSAiQWRkZWQ6Ii4NCj4gDQo+IDIuICBOb24tQVND SUkgZXNjYXBpbmcgaGFzIGJlZW4gY2hhbmdlZCBmcm9tIHRoZSBpZGlvc3luY3JhdGljICIvdXh4 eHgiDQo+IGZvcm1hdCB0byB0aGUgWE1MLWNvbXBsaWFudCAiJiN4WFhYWDsiIGZvcm1hdC4gIE5v dGUgdGhhdCB0d28tZGlnaXQgaGV4DQo+IGNvZGVzIGFyZSB1c2VkIHdoZW5ldmVyIHBvc3NpYmxl LCB3aGljaCBtZWFucyAiYWx3YXlzIiBmb3IgdGhlIGN1cnJlbnQNCj4gdmVyc2lvbiBzaW5jZSBk ZXNjcmlwdGlvbnMgYXJlIGxpbWl0ZWQgdG8gTGF0aW4tMSBhbmQgbm8gb3RoZXIgZmllbGRzDQo+ IGN1cnJlbnRseSBoYXZlIG5vbi1BU0NJSS4NCj4gDQo+IDMuICBUaGUgY2hhcmFjdGVycyA6IChj b2xvbikgYW5kIDsgKHNlbWljb2xvbikgYXJlIG5vIGxvbmdlciBzdWJqZWN0IHRvDQo+IHRoZSBl c2NhcGUgc2VxdWVuY2UuDQo+IA0KPiA0LiBUaGUgZGFzaC1kYXNoIHZhbHVlICItLSIgZm9yIHRo ZSBDYW5vbmljYWwgZmllbGQgaGFzIGJlZW4gcmVtb3ZlZC4NCj4gDQo+IDUuICBTb21lIG9mIHRo ZSBsYW5ndWFnZSBhbmQgc2NyaXB0IG5hbWVzIGhhdmUgYmVlbiBtb2RpZmllZCB0byB0YWtlDQo+ IGFkdmFudGFnZSBvZiBMYXRpbi0xIGluc3RlYWQgb2YganVzdCBBU0NJSS4gIEFsbCBkZXNjcmlw dGlvbnMgZm9yDQo+IGxhbmd1YWdlLCBzY3JpcHQsIGFuZCByZWdpb24gc3VidGFncyBub3cgcmVm bGVjdCB0aGUgdW5kZXJseWluZyBJU08gb3INCj4gVU4gc3RhbmRhcmRzLCBleGNlcHQgd2hlbiB0 aGUgZXh0ZXJuYWwgc3RhbmRhcmQgaXRzZWxmIGdvZXMgYmV5b25kDQo+IEFTQ0lJLg0KPiANCj4g Ni4gIFRoZSBsaW5lIHRlcm1pbmF0aW9uIHNlcXVlbmNlIGlzIG5vdyB1bmVxdWl2b2NhbGx5IENS TEYuDQo+IA0KPiA3LiAgTGluZSBjb250aW51YXRpb24gaXMgbm93IGRlbm90ZWQgYnkgYSBDUkxG IGZvbGxvd2VkIGJ5IHR3byBzcGFjZXMuDQo+IE5vdGUgdGhhdCBtdWx0aXBsZSBzcGFjZXMgd2l0 aGluIGEgc3VidGFnIGFyZSBjb2xsYXBzZWQgdG8gYSBzaW5nbGUNCj4gc3BhY2UuDQo+IA0KPiBB bGwgb2YgdGhlc2UgY2hhbmdlcyBhcmUgaW5jbHVkZWQgaW4gdGhlIGRyYWZ0LTAxIGN1cnJlbnRs eSBwb3N0ZWQgb24NCj4gQWRkaXNvbidzIHNpdGUuDQo+IA0KPiBUaGUgbmV3IHJlZ2lzdHJ5LCBs aWtlIGFsbCBvdGhlcnMgYmVmb3JlIGl0LCBpcyBhdmFpbGFibGUgYXQNCj4gaHR0cDovL3VzZXJz LmFkZWxwaGlhLm5ldC9+ZGV3ZWxsL2xzdHJlZy50eHQuDQo+IA0KPiAtRG91ZyBFd2VsbA0KPiAg RnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+ICBodHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdl bGwvDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQo= --===============1051380636== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1051380636==-- From ltru-bounces@ietf.org Mon Apr 11 12:46:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28086; Mon, 11 Apr 2005 12:46:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2Cl-0005xt-AR; Mon, 11 Apr 2005 12:56:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL22X-00048W-75; Mon, 11 Apr 2005 12:45:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL22V-00047P-B6 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 12:45:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27966 for ; Mon, 11 Apr 2005 12:45:23 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2Bo-0005ui-W6 for ltru@ietf.org; Mon, 11 Apr 2005 12:55:10 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 09:45:16 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 09:45:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Compatibility with existing use (LDAP) Date: Mon, 11 Apr 2005 09:45:14 -0700 Message-ID: Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU9GD2xnvikmupZQkiUpbggbW7sgwBnO8XA From: "Peter Constable" To: X-OriginalArrivalTime: 11 Apr 2005 16:45:16.0922 (UTC) FILETIME=[D72165A0:01C53EB5] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable > From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] > > This whole argument is a strawman. The number of cases in which tags of > > the form ll-Ssss-CC will be used are limited. >=20 > You have absolutely no way of knowing that that will be the case.=20 Your "back-compat" failure has to do specifically with cases in which ll-CC tags are now used. The number of cases from among these for which we would considerable it reasonable to use a script ID are indeed limited. Of course, we cannot guarantee that no one will ever use something like "en-Latn-GB", but we should not get overly concerned about bad-practice usage. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 12:53:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28947; Mon, 11 Apr 2005 12:53:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2JO-0006HJ-76; Mon, 11 Apr 2005 13:02:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL275-0005Mp-Ur; Mon, 11 Apr 2005 12:50:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL274-0005MA-34 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 12:50:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28582 for ; Mon, 11 Apr 2005 12:50:03 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2GM-000698-Ee for ltru@ietf.org; Mon, 11 Apr 2005 12:59:50 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 11 Apr 2005 09:49:57 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 09:49:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Compatibility with existing use (LDAP) Date: Mon, 11 Apr 2005 09:49:53 -0700 Message-ID: Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU9K/I6MrEIIrOsQsSpeFfKjNOq3wBijCuw From: "Peter Constable" To: X-OriginalArrivalTime: 11 Apr 2005 16:49:57.0910 (UTC) FILETIME=[7E9CC360:01C53EB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Semi-OT - the inclusion of script tags in language tags breaks > utterly the utility of presenting language choices to users in > GUIs as country-flag icons - the script differences would be > invisible. There's not much utility in that UI device when a script distinction exists and trumps any country distinction. It's not a very useful device in general, anyway. What language is an icon of the Swiss flag supposed to represent? Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 12:59:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29507; Mon, 11 Apr 2005 12:59:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2PC-0006SZ-Bu; Mon, 11 Apr 2005 13:08:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL2Dq-0006eN-FE; Mon, 11 Apr 2005 12:57:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL2Do-0006dL-JP for ltru@megatron.ietf.org; Mon, 11 Apr 2005 12:57:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29389 for ; Mon, 11 Apr 2005 12:57:01 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DL2N3-0006Pj-9O for ltru@ietf.org; Mon, 11 Apr 2005 13:06:48 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Mon, 11 Apr 2005 17:56:31 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 17:56:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] language or price tag ? Date: Mon, 11 Apr 2005 17:56:31 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A31E@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] language or price tag ? Thread-Index: AcU+lJr2Y5rxMhYKSUSJHuqDW3w0wAAIdq0A From: "L.Gillam" To: ltru X-OriginalArrivalTime: 11 Apr 2005 16:56:31.0214 (UTC) FILETIME=[690A30E0:01C53EB7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable Comments in-line > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of JFC (Jefsey) Morfin > Sent: 11 April 2005 13:26 > To: ltru > Subject: RE: [Ltru] language or price tag ? >=20 >=20 > At 12:37 11/04/2005, L.Gillam wrote: > > > Talking about "short" alphanumeric language tags to describe the=20 > > extreme variety of the real human world _IS_ rebuilding the world. > > > >No. There is a difference between "rebuilding the world" and=20 > representing=20 > >what is perceived by many to exist in the world. You cannot=20 > physically put=20 > >a brick into a database - you should be able to prove this=20 > to yourself=20 > >using a short physical experiment. As you will discover, you=20 > can only put=20 > >representatives of the brick into the database. > > > >Your statement you seem to dismiss every single=20 > classification system known. >=20 > Objecting for the fun of it is usually of no real use to a=20 > debate, but=20 > sometimes brings some humour. Experience shows that usually=20 > humour results=20 > from a brillant mental twist after having well understood the=20 > adversary=20 > position and challenging his own IQ. Here it seems you failed=20 > to see I say=20 > the unreality of the rebuilt world results from the=20 > underlined "short", not=20 > from the representation paradigm. "the unreality of the rebuilt world results from the underlined = "short""? You're right, at this point I have no idea what point you are attempting to make. Firstly, nobody is "rebuilding" the world. The very fact that a "short" identifier can stand in place of a longer one still enables = variety to be described - or have you not come across abbreviations either? > A system where 350 millions of English speaking American, 56 English=20 > speaking Pitcairn Islanders and the single may be English=20 > speaking Pinguin=20 > from Kergelen benefit from the same level of unique=20 > geopolitical subtag,=20 > seems a representation of languages at odds wiht the real=20 > world. But may be=20 > we are from different planets? Certainly a feasible final suggestion.=20 What would you suggest? Take equal divisions based on percentages of=20 the population and see what it's doing? I think this is more = unrealistic. Tell people that they have to speak and write another language so that = they can fit to some other scheme? Does the historical evidence of ISO = standards=20 and the linguistic evidence provided in tag registrations for the RFC=20 in relation to the RFC mean nothing to you? Classifications do not have to be equally balanced. Linguistic evidence of difference has been = provided as you would no doubt have seen in recent registrations. What evidence would you provide instead? > You see, I can only repeat the old say "not all RFC make a standard",=20 > because standards call for proven applications to the market.=20 > Here we are=20 > supposed to document a Best Common (therefore existing) Practice. > jfc HTML is a proven application. XML is a proven application. How much = proof do you expect? Sure, you can always provide places where proof does not exist, but you're surely missing the point. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 13:05:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29917; Mon, 11 Apr 2005 13:05:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2Vj-0006dI-8Z; Mon, 11 Apr 2005 13:15:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL2JY-0007R0-1c; Mon, 11 Apr 2005 13:03:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL2JW-0007Q3-IZ for ltru@megatron.ietf.org; Mon, 11 Apr 2005 13:03:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29663 for ; Mon, 11 Apr 2005 13:02:55 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2Sn-0006Xy-CB for ltru@ietf.org; Mon, 11 Apr 2005 13:12:42 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 10:02:47 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 10:02:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Compatibility with existing use (LDAP) Date: Mon, 11 Apr 2005 10:02:46 -0700 Message-ID: Thread-Topic: [Ltru] Compatibility with existing use (LDAP) Thread-Index: AcU9TiGRLh92uBpdSDyoSdGCp/s+3wBaJajw From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 11 Apr 2005 17:02:47.0983 (UTC) FILETIME=[499C93F0:01C53EB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Randy Presuhn > As a technical contributor, the longer this thread goes on > the more consideration I think we should give to alternatives like > http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt >=20 > If we were to treat the identification of the language(variant), > the script, and the orthography of a text as three distinct > attributes, rather than trying to structure them into a single string > called a "language tag" would it ultimately make things simpler > or more complicated? It would make things more complicated. The big failing I see in Bruce Lilly's draft is that it fails to recognize that script is not the only relevant aspect of written form. In terms of 3066bis, there are written-form variants and spelling conventions that will be distinguished using country IDs, variant subtags or both. Bruce is suggesting that we pull out the script subtag into a separate metadata category; but written-form distinctions indicated by the region and variant subtags are left behind.=20 If that idea is to be considered at all, then it requires written-form tags that involve more than just an ISO 15924 ID. But then you have a significant usability problem: should my current en-GB content be tagged lang =3D en-GB, script =3D Latn-GB or=20 lang =3D en, script =3D Latn-GB or=20 lang =3D en-GB, script =3D Latn or=20 lang =3D en-GB This scheme requires far more user guidance than what is currently proposed, and more than is feasible: it requires telling them how to judge e.g. whether a country distinction reflects a distinction in language variety, a distinction in written form, or both. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 13:19:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01570; Mon, 11 Apr 2005 13:19:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2is-00075h-9S; Mon, 11 Apr 2005 13:29:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL2Y6-0001ZK-Jk; Mon, 11 Apr 2005 13:18:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL2Y5-0001XK-AA for ltru@megatron.ietf.org; Mon, 11 Apr 2005 13:18:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01408 for ; Mon, 11 Apr 2005 13:17:33 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2gz-00071o-76 for ltru@ietf.org; Mon, 11 Apr 2005 13:27:21 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 10:17:27 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 10:17:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: registry should copy non-English fields fromISOdocuments Date: Mon, 11 Apr 2005 10:17:26 -0700 Message-ID: Thread-Topic: [Ltru] Re: registry should copy non-English fields fromISOdocuments Thread-Index: AcU9I+c3e3va7AA7QEGmGS4JPO4Y8wBle3Vw From: "Peter Constable" To: X-OriginalArrivalTime: 11 Apr 2005 17:17:28.0118 (UTC) FILETIME=[56368560:01C53EBA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > This reference name is obviously not a medium term user acceptable > solution. This is why the ISO 639-3 cannot be a final solution. And why we > need a multi-language ontlogy. This is nonsense. We already have a multi-language ontology: the *ontology* is the model of things in the world that we're describing, and we our model assumes multiple languages. That is completely independent of whether we document the individual entities using names in one language or in six-thousand languages. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 13:35:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02782; Mon, 11 Apr 2005 13:35:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2xs-0007UH-Lz; Mon, 11 Apr 2005 13:44:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL2ma-0003bp-1G; Mon, 11 Apr 2005 13:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL2mY-0003bN-8W for ltru@megatron.ietf.org; Mon, 11 Apr 2005 13:33:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02598 for ; Mon, 11 Apr 2005 13:32:54 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2vp-0007Qx-Bw for ltru@ietf.org; Mon, 11 Apr 2005 13:42:42 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 10:32:47 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 10:32:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: registry should copy non-English fields from ISOdocuments Date: Mon, 11 Apr 2005 10:32:46 -0700 Message-ID: Thread-Topic: [Ltru] Re: registry should copy non-English fields from ISOdocuments Thread-Index: AcU99FhrMSisX3lQSXmMZd4EqeIeDgAAep+qADFtydA= From: "Peter Constable" To: "ltru" X-OriginalArrivalTime: 11 Apr 2005 17:32:47.0967 (UTC) FILETIME=[7A7C56F0:01C53EBC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of L.Gillam > The second question becomes: > If 639-3 is using the name of the language in the language itself... The initial table of 639-3 will be using a name by which the given entity has been documented, but the origins of which are not specified. It would have been an impossible task to validate that all of 7000+ names have this or that kind of origin. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 13:46:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03630; Mon, 11 Apr 2005 13:46:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL39H-0007qU-63; Mon, 11 Apr 2005 13:56:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL2x1-0004IK-Fs; Mon, 11 Apr 2005 13:43:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL2x0-0004Hx-7E for ltru@megatron.ietf.org; Mon, 11 Apr 2005 13:43:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03362 for ; Mon, 11 Apr 2005 13:43:42 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL36G-0007kh-18 for ltru@ietf.org; Mon, 11 Apr 2005 13:53:30 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 10:43:34 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 10:43:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: registry should copy non-English fields from ISOdocuments Date: Mon, 11 Apr 2005 10:43:33 -0700 Message-ID: Thread-Topic: [Ltru] Re: registry should copy non-English fields from ISOdocuments Thread-Index: AcU+BuEcw482n1DGQy6I2P7p0q7kOAAtgDIQ From: "Peter Constable" To: X-OriginalArrivalTime: 11 Apr 2005 17:43:34.0920 (UTC) FILETIME=[FC198880:01C53EBD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > John Cowan > > 3. A code (e.g. alpha3 in 639-3) stands as synonymous with the reference > > name and as entry point into the "conceptual" entry - the mantra is > > "I don't care what you call it as long as we are referring to the > > same thing" >=20 > The code points to the name, but the name does not always unambiguously > point to the language... I think Lee's point is that the name used is intended to document the conceptual entity in a way that ideally is unambiguous. I don't think you two are actually disagreeing about anything; you're just struggling over common words to describe a common understanding. > > ensuring -4 has necessary and sufficient coverage. >=20 > >From what I understand (I have not seen a draft), -4 will be conceptual > and introductory (-0, in other words, if ISO rules permitted a -0 part) > and will not provide coverage of anything. Has this changed? If by "coverage" you mean "specify identifiers for some languages", your assumption is correct: part 4 will not do this (and has not changed in that regard). Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 14:00:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05060; Mon, 11 Apr 2005 14:00:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL3MS-0008Mv-Jn; Mon, 11 Apr 2005 14:10:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL3Bc-0006fR-Py; Mon, 11 Apr 2005 13:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL3Bb-0006bK-P5 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 13:58:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04867 for ; Mon, 11 Apr 2005 13:58:53 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL3Kw-0008IF-2j for ltru@ietf.org; Mon, 11 Apr 2005 14:08:39 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 11 Apr 2005 10:58:43 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 10:58:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Is there a consensus ? (was: Comment: use VU for Vanuatu (was: remove region subtag 200)) Date: Mon, 11 Apr 2005 10:58:43 -0700 Message-ID: Thread-Topic: [Ltru] Is there a consensus ? (was: Comment: use VU for Vanuatu (was: remove region subtag 200)) Thread-Index: AcU+lHU96TjAoMCAQvKbwksd4X1/MQAKu05g From: "Peter Constable" To: X-OriginalArrivalTime: 11 Apr 2005 17:58:44.0869 (UTC) FILETIME=[1A78BB50:01C53EC0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of JFC > (Jefsey) Morfin > Since you are one of the most competent, active and acknowledged members of > this Working Group, I am interested to know if - me apart - this is the > consensus of this Working Group? I have learned that I cannot possibly give a yes/no answer to a question coming from JFC about agreement on some idea since one cannot reliably assume they know what JFC's understanding of that idea is. So, I can only say that I am in agreement with what Doug Ewell has said, but I cannot comment on whether or not I am in agreement with JFC's interpretation of what Doug has said. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 14:20:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06152; Mon, 11 Apr 2005 14:20:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL3fO-0000Mu-Cl; Mon, 11 Apr 2005 14:29:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL3Tw-0008MC-8q; Mon, 11 Apr 2005 14:17:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL3Tu-0008LP-K4 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 14:17:55 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05999 for ; Mon, 11 Apr 2005 14:17:35 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL3Q0-0006Ut-Td for ltru@lists.ietf.org; Mon, 11 Apr 2005 20:13:52 +0200 Received: from 212.82.251.33 ([212.82.251.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 20:13:52 +0200 Received: from nobody by 212.82.251.33 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 20:13:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 11 Apr 2005 20:12:14 +0200 Organization: Lines: 13 Message-ID: <425ABDFE.3C8D@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.33 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Peter Constable wrote: > Of course, we cannot guarantee that no one will ever use > something like "en-Latn-GB", but we should not get overly > concerned about bad-practice usage. At the moment the complete formal definition of "bad practice" is an appeal to "use tags wisely", that's not enough. We need either language => script or script => language(s) pointers to define bad practice or good practice. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 14:27:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06639; Mon, 11 Apr 2005 14:27:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL3mO-0000Zd-KR; Mon, 11 Apr 2005 14:37:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL3cb-0000zb-0w; Mon, 11 Apr 2005 14:26:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL3cZ-0000z6-B2 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 14:26:51 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06600 for ; Mon, 11 Apr 2005 14:26:41 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL3Xv-0007mE-IY for ltru@lists.ietf.org; Mon, 11 Apr 2005 20:22:03 +0200 Received: from 212.82.251.33 ([212.82.251.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 20:22:03 +0200 Received: from nobody by 212.82.251.33 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 20:22:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 11 Apr 2005 20:22:31 +0200 Organization: Lines: 8 Message-ID: <425AC067.33A6@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3D6F@irvmbxw01.quest.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.33 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: New registry 2005-04-08 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > Note that the proto-draft now contains ABNF defining the > registry format. Maybe you don't like the I-D bureaucracy, but how about an URL ? I'm always curious if it comes to ABNF, bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 14:31:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06774; Mon, 11 Apr 2005 14:31:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL3qQ-0000eS-SG; Mon, 11 Apr 2005 14:41:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL3fI-0001GE-NH; Mon, 11 Apr 2005 14:29:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL3fH-0001Fh-NL for ltru@megatron.ietf.org; Mon, 11 Apr 2005 14:29:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06703 for ; Mon, 11 Apr 2005 14:29:29 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL3oX-0000b2-AL for ltru@ietf.org; Mon, 11 Apr 2005 14:39:16 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 11:29:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: New registry 2005-04-08 Date: Mon, 11 Apr 2005 11:29:18 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3E60@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: New registry 2005-04-08 Thread-Index: AcU+xBWZm/890Q1gTjuyTkIDinapVgAAA+Sw From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 11 Apr 2005 18:29:18.0852 (UTC) FILETIME=[5F9C5440:01C53EC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable I don't mind submitting I-D's, but prefer to have a complete edit round = completed first. We're sort-of in the middle. Editor's copies are always on: http://www.inter-locale.com/ This one is at = http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.html (or txt = if you prefer) Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: lundi 11 avril 2005 11:23 > To: ltru@ietf.org > Subject: [Ltru] Re: New registry 2005-04-08 >=20 > Addison Phillips wrote: >=20 > > Note that the proto-draft now contains ABNF defining the > > registry format. >=20 > Maybe you don't like the I-D bureaucracy, but how about an > URL ? I'm always curious if it comes to ABNF, bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 14:38:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07580; Mon, 11 Apr 2005 14:38:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL3wp-0000rJ-Is; Mon, 11 Apr 2005 14:47:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL3lJ-0001zG-Iw; Mon, 11 Apr 2005 14:35:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL3lG-0001yG-Ia for ltru@megatron.ietf.org; Mon, 11 Apr 2005 14:35:52 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07347 for ; Mon, 11 Apr 2005 14:35:40 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL3hf-0000oO-Nx for ltru@lists.ietf.org; Mon, 11 Apr 2005 20:32:07 +0200 Received: from 212.82.251.33 ([212.82.251.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 20:32:07 +0200 Received: from nobody by 212.82.251.33 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 20:32:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 11 Apr 2005 20:29:04 +0200 Organization: Lines: 19 Message-ID: <425AC1F0.106C@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.33 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: e-GB-scouse (was: Matching metrics) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Peter Constable wrote: >> "scouse" would need a "recommended prefix" en-GB >> (implicitly en-*-GB), not only en. > How so? If "GB" doesn't add any useful qualification then > it's redundant and unnecessary Point. But I came from the other direction trying tags like en-US-scouse until John and Mark told me to stop it because it's nonsense, en-scouse is implicitly always en-GB-scouse. Same problem as with the scripts if you don't know it. For me the GB in en-GB-scouse was not redundant (until John and Mark explained it), I'd like to have any implied info in the registry - not so important for scouse, but for the scripts. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 14:48:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08054; Mon, 11 Apr 2005 14:48:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL46k-00015f-TU; Mon, 11 Apr 2005 14:58:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL3vV-00032v-2u; Mon, 11 Apr 2005 14:46:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL3vU-00032f-KK for ltru@megatron.ietf.org; Mon, 11 Apr 2005 14:46:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07928 for ; Mon, 11 Apr 2005 14:46:10 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL44j-00012K-1o for ltru@ietf.org; Mon, 11 Apr 2005 14:55:57 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 11:46:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Apr 2005 11:46:02 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3E7A@irvmbxw01.quest.com> Thread-Topic: Great Script Debate Part II: Formats... Thread-Index: AcU+xrETzZpNDn3SRR6PYOiqoAziNw== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 11 Apr 2005 18:46:03.0039 (UTC) FILETIME=[B6271AF0:01C53EC6] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Ltru] Great Script Debate Part II: Formats... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1414256024==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --===============1414256024== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGF2aW5nIGVzdGFibGlzaGVkIHRoYXQgdGhlcmUgZXhpc3Qgc29tZSBSRkMgMzA2NiB0YWcgcHJv Y2Vzc29ycyBpbiBicm9hZCBkaXN0cmlidXRpb24gd2hvc2UgcmVzdWx0cyBhcmUgaW1wYWN0ZWQg YnkgdGhlIGxhbmctc2NyaXB0LXJlZ2lvbiBmb3JtYXQsIGxldCdzIHNraXAgb3ZlciB0aGUgcXVl c3Rpb24gb2YgdGhlIGxldmVsIG9mIGhhcm0gYW5kIGxvb2sgYXQgYWx0ZXJuYXRpdmUgZm9ybWF0 cyBuZXh0LiBJIHByb21pc2UgKEpGQykgdG8gY29tZSBiYWNrIGFuZCB2aXNpdCB0aGUgcmVsYXRp dmUgaGFybSBxdWVzdGlvbi4NCg0KSW4gdGhpcyBlbWFpbCwgSSdsbCB1c2UgdGhlIHN1YnRhZ3Mg aW4gdGhlIGZvbGxvd2luZyAzMDY2YmlzLXN0eWxlIHRhZyBmb3IgZGVtb25zdHJhdGlvbiBwdXJw b3NlczoNCg0KZGUtTGF0bi1DSC0xOTAxLXgtZ2xlZXANCg0KTGV0J3MgY29uc2lkZXIgdGhlIGRp ZmZlcmVudCB3YXlzIHRoYXQgd2UgY2FuIGluY2x1ZGUgc2NyaXB0IGluIGEgdGFnLiBGb3IgZWFj aCBvcHRpb24sIEknbGwgd3JpdGUgb3V0IGEgdGFnIHdpdGggYSBzY3JpcHQgYW5kIGEgdGFnIHdp dGhvdXQgYSBzY3JpcHQuDQoNCjEuIFNjcmlwdCBmaXJzdC4NCg0KV2l0aDogTGF0bi1kZS1DSC0x OTAxLXgtZ2xlZXANCk5vbmU6IGRlLUNILTE5MDEteC1nbGVlcA0KDQpUaGlzIHRhZyBmb3JtYXQg aGFzIGxpdHRsZSB0byByZWNvbW1lbmQgaXQuIFNvbWUgZm9sa3MgbWF5IGZpbmQgdGhhdCB0aGUg c2NyaXB0LWZpcnN0IHBvc2l0aW9uIHNlZW1zIG1vcmUgc3VpdGVkIHRvIGEgaGllcmFyY2h5IG9m IHRhZ3MgKG1hbnkgbGFuZ3VhZ2VzIGFyZSB3cml0dGVuIGluIG9uZSBzY3JpcHQpLCBidXQgdGhp cyBwb3NpdGlvbiBkb2Vzbid0IGFkZCBhcHByZWNpYWJseSB0byB0aGUgaW5mb3JtYXRpb24gY29u dmV5ZWQgYnkgYSAqbGFuZ3VhZ2UqIHRhZy4gSXQgaGFzIHRoZSBzYW1lIHByb2JsZW1zIGFzIDMw NjZiaXMncyBkZXNpZ24gZm9yICJzbWFydCIgMzA2NiBwcm9jZXNzb3JzLiBJbiBmYWN0LCBpdCBp cyB3b3JzZSwgc2luY2UgaXQgYWxzbyBwdXNoZXMgdGhlIGxhbmd1YWdlIG91dCBvZiBwb3NpdGlv bi4NCg0KMi4gU2NyaXB0IGNvbWJpbmVzIHdpdGggbGFuZ3VhZ2UuDQoNCmRlTGF0bi1DSC0xOTAx LXgtZ2xlZXANCmRlLUNILTE5MDEteC1nbGVlcA0KDQpUaGlzIHRhZyBmb3JtYXQgZml4ZXMgdGhl IHJlZ2lvbiBjb2RlIHByb2JsZW0uIEl0IGFsc28gaW5zdGFsbHMgYSAidW5pcXVlIG5ldyBmb3Jt YXQiIHRoYXQgc29tZSBoYXZlIGFza2VkIGZvci4gVGhlIHByb2JsZW0gaGVyZSBpcyB0aGF0IHRo ZSB0d28gdGFncyBhYm92ZSByZWFsbHkgc2hvdWxkIHJlZmVyIHRvIHRoZSBzYW1lIGxhbmd1YWdl IGFuZCAzMDY2IHByb2Nlc3NvcnMgb2YgYWxsIHR5cGVzIChSRlIsIHNtYXJ0KSB3aWxsIG5ldmVy IGdldCB0aGF0Lg0KDQozLiBTY3JpcHQgYWZ0ZXIgbGFuZ3VhZ2UNCg0KZGUtTGF0bi1DSC0xOTAx LXgtZ2xlZXANCmRlLUNILTE5MDEteC1nbGVlcA0KDQpUaGlzIGlzIFJGQyAzMDY2YmlzLCBvZiBj b3Vyc2UuIFRoZSBpc3N1ZSBoZXJlIGlzIHRoZSBzY3JpcHQgdnMuIHJlZ2lvbiBjb2RlIHRoYXQg d2UncmUgZGlzY3Vzc2luZy4gVGhlIGFkdmFudGFnZSB0byB0aGlzIGRlc2lnbiBpcyB0aGF0IHNj cmlwdCBpcyBhdCB0aGUgcmlnaHQgbGV2ZWwgaW4gdGhlIHRhZyBpbiBtb3N0IGNhc2VzLiBSRlIg cHJvY2Vzc29ycyBjYW4gcmVtb3ZlIHRoZSBzY3JpcHQgKHVubGlrZSBpbiAyKSBkdXJpbmcgbWF0 Y2hpbmcuIFJGUiBtYXRjaGluZyB3b3JrcyBhcyBsb25nIGFzIHVzZXJzIGFyZSBjb25zaXN0ZW50 IGFib3V0IHVzaW5nIG9yIG5vdCB1c2luZyBzY3JpcHQgZm9yIGEgcGFydGljdWxhciBwcmVmaXgu ICJTbWFydCIgMzA2NiBtYXRjaGluZyBjYW4ndCBmaW5kIHRoZSByZWdpb24gY29kZSB3aXRoIHRo aXMgZGVzaWduLiAoU21hcnQgMzA2NmJpcyBwcm9jZXNzaW5nIGZpbmRzIGFsbCBzdWJ0YWdzKQ0K DQo0LiBTY3JpcHQgYWZ0ZXIgcmVnaW9uIGFuZCBiZWZvcmUgdmFyaWFudA0KDQpkZS1DSC1MYXRu LTE5MDEteC1nbGVlcA0KZGUtQ0gtMTkwMS14LWdsZWVwDQpkZS1MYXRuLTE5MDEteC1nbGVlcCAv LyBsb29rb3V0Li4uDQoNClRoaXMgZG9lc24ndCBoYXJtIDMwNjYgcHJvY2Vzc29ycyBpbiBtb3N0 IGNhc2VzLCBidXQgaGFybXMgdXNlcnMgb2YgdGhlc2UgaW1wbGVtZW50YXRpb25zIHdobyBuZWVk IHRvIGZpbmQgc3BlY2lmaWMgc2NyaXB0IHZlcnNpb25zIG9mIGxhbmd1YWdlLiBUaGF0IGlzLCBS RlIgcHJvY2Vzc29ycyBjYW4ndCBmaW5kIG1hdGNoaW5nIHNjcmlwdHMuICJTbWFydCIgMzA2NiBw cm9jZXNzb3JzIChzdWNoIGFzIHRoZSBKMkVFIGRlbW8pLCBnZXQgbGFuZ3VhZ2UgYW5kIHJlZ2lv biBpbnRvIHRoZSByaWdodCBzbG90cy4NCg0KNGEuIFNjcmlwdCBhcyBhIHZhcmlhbnQuDQoNClRo aXMgaXMgdGhlIHNhbWUgYXMgKDQpLCBvbmx5IHRoZSBzY3JpcHQgaXMganVzdCBhbm90aGVyIHZh cmlhbnQuIFRvbyBib3JpbmcgdG8gZGlzY3Vzcy4NCg0KNS4gU2NyaXB0IGFzIGFuIGV4dGVuc2lv bg0KDQpkZS1DSC0xOTAxLXMtTGF0bi14LWdsZWVwDQpkZS1DSC0xOTAxLXgtZ2xlZXANCmRlLTE5 MDEtcy1MYXRuLXgtZ2xlZXAgLy8gbXkgcHJldmlvdXMgZXhhbXBsZSBvZiBhIHRhZyB0aGF0IGhh cm1zIHNtYXJ0IHByb2Nlc3NvcnMNCg0KVGhpcyBoYXMgdGhlIGFkdmFudGFnZSBvZiBhbGxvd2lu ZyAzMDY2YmlzICJzbWFydCIgcHJvY2Vzc29ycyB0byBwdXQgdGhlIHNjcmlwdCBiYWNrIGJldHdl ZW4gImRlIiBhbmQgIkNIIiBpZiBpdCB3YW50cyB0byBpbnRlcm5hbGx5LCB3aGlsZSBub3QgaW50 ZXJmZXJpbmcgd2l0aCBleGlzdGluZyB0YWdzIChub3RlIGVtcGhhc2lzIGhlcmU6ICp0YWdzKiku IFJGUiBwcm9jZXNzb3JzIHJlbW92ZSB0aGUgc2NyaXB0IGV2ZW4gYmVmb3JlIHZhcmlhbnQuDQoN CjYuIFNjcmlwdCBhcyBhbiBhdHRyaWJ1dGUNCg0KZGUtQ0gtMTkwMS14LWdsZWVwOyBzY3JpcHQ9 TGF0bjsgcT0xLjANCmRlLUNILTE5MDEteC1nbGVlcDsgcT0xLjANCg0KVGhpcyBoYXMgdGhlIGFk dmFudGFnZSBvZiBub3QgbXVja2luZyB3aXRoIHRoZSB0YWdzIGF0IGFsbCwgYnV0IGNhbid0IGJl IHVzZWQgaW4gY29udGV4dHMgc3VjaCBhcyBYTUwgOi0oLiBXaG8ga25vd3MgaG93IG1hdGNoaW5n IHdvcmtzLg0KDQo3LiBTY3JpcHQgaW5mZXJyZWQgZnJvbSB0aGUgdGFnDQoNCmRlLUNILTE5MDEt eC1nbGVlcA0KDQpUaGlzIGlzIHdoYXQgd2UgaGF2ZSB0b2RheS4gSWYgeW91IHNlZSAiemgtVFci LCB0aGF0IG11c3QgbWVhbiBIYW50LiBHb29kIGx1Y2sgaWYgeW91IGxpdmUgaW4gSEsuDQoNCg0K QW55IEkgbWlzc2VkPw0KDQoNCk5vdywgYmVmb3JlIHlvdSBjaG9vc2Ugb25lIG9mIHRoZXNlLCBk b27igJl0JyBmb3JnZXQgdGhhdCB5b3UgY2FuIGRvIHMvc2NyaXB0L2V4dGxhbmcvIG9uIHRoZSBh Ym92ZSB0ZXh0LiBXZSBkb24ndCBqdXN0IGhhdmUgb25lIGludGVycG9sYXRlZCBzdWJ0YWcsIHdl IGhhdmUgdHdvLg0KDQpCZXN0IFJlZ2FyZHMsDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGls bGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3 LnF1ZXN0LmNvbQ0KDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2lu ZyBHcm91cA0KaHR0cDovL3d3dy53My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFs aXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0K --===============1414256024== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1414256024==-- From ltru-bounces@ietf.org Mon Apr 11 14:59:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08803; Mon, 11 Apr 2005 14:59:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL4Hg-0001OL-In; Mon, 11 Apr 2005 15:09:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL45x-0003vU-FK; Mon, 11 Apr 2005 14:57:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL45v-0003uK-MC for ltru@megatron.ietf.org; Mon, 11 Apr 2005 14:57:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08660 for ; Mon, 11 Apr 2005 14:57:01 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL4FD-0001Lt-GV for ltru@ietf.org; Mon, 11 Apr 2005 15:06:48 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 11:56:51 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 11:56:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Compatibility with existing use (LDAP) Date: Mon, 11 Apr 2005 11:56:50 -0700 Message-ID: Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU+w0kQ7kwhxI3lT4eeKs6JMjSmVAABKvLQ From: "Peter Constable" To: X-OriginalArrivalTime: 11 Apr 2005 18:56:52.0398 (UTC) FILETIME=[39336CE0:01C53EC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Frank Ellermann > > Of course, we cannot guarantee that no one will ever use > > something like "en-Latn-GB", but we should not get overly > > concerned about bad-practice usage. >=20 > At the moment the complete formal definition of "bad practice" > is an appeal to "use tags wisely", that's not enough. We need > either language =3D> script or script =3D> language(s) pointers to > define bad practice or good practice. Agreed. BTW, notice that now we're discussing how to ensure good practice to avoid specific problems in functionality. This is quite different from the unqualified statement "backwards compatibility is broken". Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 15:02:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09194; Mon, 11 Apr 2005 15:02:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL4Kl-0001Wu-82; Mon, 11 Apr 2005 15:12:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL49M-0004Li-2D; Mon, 11 Apr 2005 15:00:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL49L-0004He-3Q for ltru@megatron.ietf.org; Mon, 11 Apr 2005 15:00:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08834 for ; Mon, 11 Apr 2005 14:59:44 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL4Hq-0001Oj-MG for ltru@ietf.org; Mon, 11 Apr 2005 15:09:31 -0400 Received: from h-64-105-136-143.snvacaid.dynamic.covad.net ([64.105.136.143] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DL48N-0000O2-00 for ltru@ietf.org; Mon, 11 Apr 2005 11:59:43 -0700 Message-ID: <00b701c53ec8$d38ad6c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050409070831.UZSN2132.mta5.adelphia.net@megatron.ietf.org><004a01c53df0$786d46c0$030aa8c0@DEWELL><6.1.2.0.2.20050410194819.0d2fbbd0@mail.jefsey.com><000f01c53e0b$de9b28c0$030aa8c0@DEWELL> <6.1.2.0.2.20050411011604.03b48420@mail.jefsey.com> Subject: Re: [Ltru] Re: Comment: use VU for Vanuatu (was: remove regionsubtag 200) Date: Mon, 11 Apr 2005 12:01:10 -0700 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: 93238566e09e6e262849b4f805833007 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi - > From: "JFC (Jefsey) Morfin" > To: "Doug Ewell" ; "LTRU Working Group" > Sent: Sunday, April 10, 2005 7:08 PM > Subject: Re: [Ltru] Re: Comment: use VU for Vanuatu (was: remove regionsubtag 200) ... > You document that the draft does not match the charter. I noted that, and > also the conflict in the charter which calls for an independence from the > ISO evolutions and the possibility to identify the subtags in the tag. IMHO > this calls for a request of guidance to the IESG if the debate on the > charter (we still need to have, as Randy underlined it) does not deliver a > solution. > jfc The charter us not up for debate. Jfc: Bogus claims that a co-chair supports a particular position are not a good way to win friends or favorably influence people. Randy, co-chair ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 15:17:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11283; Mon, 11 Apr 2005 15:17:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL4ZB-0001uQ-3b; Mon, 11 Apr 2005 15:27:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4Jo-0005Nt-Aw; Mon, 11 Apr 2005 15:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4Jm-0005IF-GM for ltru@megatron.ietf.org; Mon, 11 Apr 2005 15:11:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10387 for ; Mon, 11 Apr 2005 15:10:56 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL4Sg-0001kD-8R for ltru@ietf.org; Mon, 11 Apr 2005 15:20:43 -0400 Received: from h-64-105-136-143.snvacaid.dynamic.covad.net ([64.105.136.143] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DL4JD-0005Xt-00 for ltru@ietf.org; Mon, 11 Apr 2005 12:10:55 -0700 Message-ID: <00d001c53eca$644226e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "ltru" References: <4A7C6FA2AB31194E80E13FE585F6A21292A2FB@EVS-EC1-NODE1.surrey.ac.uk> Subject: Re: [Ltru] Re: registry should copy non-English fields fromISOdocuments Date: Mon, 11 Apr 2005 12:11:46 -0700 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: 93238566e09e6e262849b4f805833007 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi - > From: "L.Gillam" > To: "ltru" > Sent: Monday, April 11, 2005 3:23 AM > Subject: RE: [Ltru] Re: registry should copy non-English fields fromISOdocuments > > > Consensus or unanimous consensus? We should be clear > about which is required. If it's only consensus, Peter > is absolutely correct. ... The term "consensus" as used in the IETF means "rough consensus". Though unanimity is nice, it is by no means required. Determination of consensus is up to the WG chair(s). The appeals process is spelled out in RFC 2026. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 15:18:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11504; Mon, 11 Apr 2005 15:18:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL4aU-0001wY-9c; Mon, 11 Apr 2005 15:28:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4Pm-0005wb-UX; Mon, 11 Apr 2005 15:17:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4Pl-0005vO-FK for ltru@megatron.ietf.org; Mon, 11 Apr 2005 15:17:41 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11271 for ; Mon, 11 Apr 2005 15:17:30 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL4Lt-00079h-VD for ltru@lists.ietf.org; Mon, 11 Apr 2005 21:13:42 +0200 Received: from 212.82.251.33 ([212.82.251.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 21:13:41 +0200 Received: from nobody by 212.82.251.33 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 21:13:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 11 Apr 2005 21:15:11 +0200 Organization: Lines: 13 Message-ID: <425ACCBF.33DE@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.33 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Peter Constable wrote: > quite different from the unqualified statement "backwards > compatibility is broken". It's related, we're trying to avoid problems with existing software for language-script-region... One way is to shift the script to the right behind language-region, another way is to get rid of the script where it's unnecesary. Without the compatibility problem "use tags wisely" would be enough. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 15:35:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12861; Mon, 11 Apr 2005 15:35:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL4qj-0002OG-BY; Mon, 11 Apr 2005 15:45:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4gJ-0007X1-8Q; Mon, 11 Apr 2005 15:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4gG-0007W7-Pk for ltru@megatron.ietf.org; Mon, 11 Apr 2005 15:34:45 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12792 for ; Mon, 11 Apr 2005 15:34:33 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL4cK-0001He-Iv for ltru@lists.ietf.org; Mon, 11 Apr 2005 21:30:40 +0200 Received: from 212.82.251.33 ([212.82.251.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 21:30:40 +0200 Received: from nobody by 212.82.251.33 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Apr 2005 21:30:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 11 Apr 2005 21:32:12 +0200 Organization: Lines: 9 Message-ID: <425AD0BC.3E2C@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3E7A@irvmbxw01.quest.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.33 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Great Script Debate Part II: Formats... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Addison Phillips wrote: > Any I missed? Add script to the charset ;-) Joke off, you probably wanted to demonstrate that de-CH-s-Latn is worse than de-Latn-CH, but I don't see it immediately. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 15:41:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13328; Mon, 11 Apr 2005 15:41:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL4wA-0002Ty-Lv; Mon, 11 Apr 2005 15:51:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4kO-0007zQ-Uu; Mon, 11 Apr 2005 15:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4kN-0007xJ-KS for ltru@megatron.ietf.org; Mon, 11 Apr 2005 15:38:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13072 for ; Mon, 11 Apr 2005 15:38:52 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL4ti-0002RA-N2 for ltru@ietf.org; Mon, 11 Apr 2005 15:48:40 -0400 Received: from h-64-105-136-143.snvacaid.dynamic.covad.net ([64.105.136.143] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DL4kF-0000Dr-00 for ltru@ietf.org; Mon, 11 Apr 2005 12:38:51 -0700 Message-ID: <010201c53ece$4b970260$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Subject: Re: [Ltru] Compatibility with existing use (LDAP) Date: Mon, 11 Apr 2005 12:40:19 -0700 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: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Hi - (as contributor) > From: "Peter Constable" > To: "LTRU Working Group" > Sent: Monday, April 11, 2005 10:02 AM > Subject: RE: [Ltru] Compatibility with existing use (LDAP) > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Randy Presuhn ... > > If we were to treat the identification of the language(variant), > > the script, and the orthography of a text as three distinct > > attributes, rather than trying to structure them into a single string > > called a "language tag" would it ultimately make things simpler > > or more complicated? > > It would make things more complicated. The big failing I see in Bruce > Lilly's draft is that it fails to recognize that script is not the only > relevant aspect of written form. In terms of 3066bis, there are > written-form variants and spelling conventions that will be > distinguished using country IDs, variant subtags or both. Bruce is > suggesting that we pull out the script subtag into a separate metadata > category; but written-form distinctions indicated by the region and > variant subtags are left behind. That's why I'm suggesting that language, script, and orthography be handled as *three* attributes. > If that idea is to be considered at all, then it requires written-form > tags that involve more than just an ISO 15924 ID. Agreed. > But then you have a > significant usability problem: should my current en-GB content be tagged (alternatives elided) > This scheme requires far more user guidance than what is currently > proposed, and more than is feasible: it requires telling them how to > judge e.g. whether a country distinction reflects a distinction in > language variety, a distinction in written form, or both. ... True, but these are distinctions that have been causing us grief. For example, "Microsoft are on their best behaviour" shows en-GB language (the use of "are" and "their" for a collective noun, which would be ungrammatical in en-US) and en-GB orthography (the spelling of "behaviour" rather than "behavior"), all in Latin script. In our neighborhood is a shopping center owner by an Australian company. Signs there use Australian English grammar, but, as far as I can tell, they've "localized" things to use American English spelling, except for trademarks. Similarly, I've seen ISO documents written using an orthography based on the OED, but with clearly American language (grammar and usage). Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 16:10:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17154; Mon, 11 Apr 2005 16:10:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5O4-0003vp-BT; Mon, 11 Apr 2005 16:20:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4wn-0000LH-Ii; Mon, 11 Apr 2005 15:51:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4wl-0000Kv-MM for ltru@megatron.ietf.org; Mon, 11 Apr 2005 15:51:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14101 for ; Mon, 11 Apr 2005 15:51:37 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL563-0002tm-V3 for ltru@ietf.org; Mon, 11 Apr 2005 16:01:25 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 12:51:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Great Script Debate Part II: Formats... Date: Mon, 11 Apr 2005 12:51:26 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3EE3@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Great Script Debate Part II: Formats... Thread-Index: AcU+zavKxYLAgTskQ5aaF2+1fRNYMAAATACg From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 11 Apr 2005 19:51:26.0414 (UTC) FILETIME=[D8AA9EE0:01C53ECF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable I didn't want to demonstrate anything necessarily. What I'm trying to do = is frame the debate so we quit going around and around in circles. My = personal analysis of the potential problems and benefits of various = formats is what I tried to put into that message. The question of which = actually is the right choice is the substance of the debate. This is similar, in my mind, in spirit to my NH/VU example. We can have = a useful discussion only if we are comparing the alternatives. As long = as the debate consists solely of "lang-script-region is bad", we are not = making progress. So my personal opinion, reflected in two years of work on the current = design, is that lang-script-region will ultimately be better for the = vast majority of users than lang-region-script or lang-region-s-script. = But now we can have *that* debate (in terms of balancing relative = benefit and relative harm). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: lundi 11 avril 2005 12:32 > To: ltru@ietf.org > Subject: [Ltru] Re: Great Script Debate Part II: Formats... >=20 > Addison Phillips wrote: >=20 > > Any I missed? >=20 > Add script to the charset ;-) Joke off, you probably wanted > to demonstrate that de-CH-s-Latn is worse than de-Latn-CH, but > I don't see it immediately. > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 16:38:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23310; Mon, 11 Apr 2005 16:38:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5pe-000601-8o; Mon, 11 Apr 2005 16:48:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5Xn-0000mJ-BY; Mon, 11 Apr 2005 16:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5Xh-0000j0-I8 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 16:30:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21189 for ; Mon, 11 Apr 2005 16:29:46 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5gz-0005Hd-7e for ltru@ietf.org; Mon, 11 Apr 2005 16:39:34 -0400 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3BKTb5j720232 for ; Mon, 11 Apr 2005 16:29:37 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3BKTaLZ242322 for ; Mon, 11 Apr 2005 14:29:36 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3BKTaVb002085 for ; Mon, 11 Apr 2005 14:29:36 -0600 Received: from markdavis (mark-davis.sanjose.ibm.com [9.43.213.112]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3BKTZwv002072; Mon, 11 Apr 2005 14:29:36 -0600 Message-ID: <022201c53ed5$2c4fca70$447b3009@sanjose.ibm.com> From: "Mark Davis" To: , "Frank Ellermann" References: <425ABDFE.3C8D@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Compatibility with existing use (LDAP) Date: Mon, 11 Apr 2005 13:29:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id j3BKTb5j720232 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable I have no objection to having a "Default Script" in the registry, for *so= me* (important) kinds of matching. For example, if you are matching for the purpose of fallback, matching en-US to en-Latn as a fallback is perfectly reasonable. And for those cases, we can recommend that the script not be included if it is the 'default'. In other kinds of matching, such as for documents queries, such as defaul= t script is not warranted. The tag en-US means English in *any* script as u= sed in the US. As such, the user would not expect to reject some text that happened to be in, say, Cyrillic transliteration (and before anyone says otherwise, this can in fact exist; one of the people in my group has copi= es of magazines and other documents from Serbia that do just that; they simp= ly transliterate flows of text in English into Cyrillic so that the script i= s uniform on the page). =E2=80=8EMark ----- Original Message -----=20 From: "Frank Ellermann" To: Sent: Monday, April 11, 2005 11:12 Subject: [Ltru] Re: Compatibility with existing use (LDAP) > Peter Constable wrote: > > > Of course, we cannot guarantee that no one will ever use > > something like "en-Latn-GB", but we should not get overly > > concerned about bad-practice usage. > > At the moment the complete formal definition of "bad practice" > is an appeal to "use tags wisely", that's not enough. We need > either language =3D> script or script =3D> language(s) pointers to > define bad practice or good practice. > > Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 16:40:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23643; Mon, 11 Apr 2005 16:40:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5rG-00067E-0w; Mon, 11 Apr 2005 16:50:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4tH-0008W0-0I; Mon, 11 Apr 2005 15:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL4tG-0008VX-2H for ltru@megatron.ietf.org; Mon, 11 Apr 2005 15:48:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13870 for ; Mon, 11 Apr 2005 15:47:46 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL52M-0002fc-9W for ltru@ietf.org; Mon, 11 Apr 2005 15:57:34 -0400 Received: from h-64-105-136-143.snvacaid.dynamic.covad.net ([64.105.136.143] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DL4ss-0003Ud-00 for ltru@ietf.org; Mon, 11 Apr 2005 12:47:46 -0700 Message-ID: <010d01c53ecf$8a9fad80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050409233836.GAA2128.mta1.adelphia.net@megatron.ietf.org> <009701c53df7$7c923420$030aa8c0@DEWELL> <6.1.2.0.2.20050410204510.0d430d10@mail.jefsey.com> <20050410203458.GD11942@skunk.reutershealth.com> Date: Mon, 11 Apr 2005 12:48:56 -0700 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: 93238566e09e6e262849b4f805833007 Subject: [Ltru] Re: Formal request for action by the LTRU Chair X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi - > From: "John Cowan" > To: > Cc: > Sent: Sunday, April 10, 2005 1:34 PM > Subject: Formal request for action by the LTRU Chair ... > Mr. Chairman, I call for the immediate initiation of the process leading > to the blocking of M. Morfin's ability to post to ltru@ietf.org because > of his repeated pattern of unprofessional commentary. I take this step > with regret, but in the belief that it is required to maintain order > and forward progress in the WG. ... Martin and I, as co-chairs, will take this and related requests into consideration. Due to the time difference (Martin is based in Japan, I am in California) and our personal schedules, it may take a while for us to sync up. This is the kind of request that requires careful consideration by both of us. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 16:47:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24438; Mon, 11 Apr 2005 16:47:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5yY-0006QI-AJ; Mon, 11 Apr 2005 16:57:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5aL-0001d5-33; Mon, 11 Apr 2005 16:32:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5aK-0001bh-BB for ltru@megatron.ietf.org; Mon, 11 Apr 2005 16:32:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21931 for ; Mon, 11 Apr 2005 16:32:29 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5jb-0005Yv-UQ for ltru@ietf.org; Mon, 11 Apr 2005 16:42:18 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 11 Apr 2005 13:32:20 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 13:32:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Compatibility with existing use (LDAP) Date: Mon, 11 Apr 2005 13:32:19 -0700 Message-ID: Thread-Topic: [Ltru] Re: Compatibility with existing use (LDAP) Thread-Index: AcU+y42rrHFL3AurQy6dU1Q4nUqdnwACWwEQ From: "Peter Constable" To: X-OriginalArrivalTime: 11 Apr 2005 20:32:20.0754 (UTC) FILETIME=[8F912F20:01C53ED5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Frank Ellermann > > quite different from the unqualified statement "backwards > > compatibility is broken". >=20 > It's related... You miss my point. Arguing "the current proposal breaks backward compatibility" is not constructive as the terms are wide open to different interpretations. The discussion had turned to considering a specific issue -- the impact of inserting a script ID in ll-Ssss-CC in cases for which ll-CC is commonly used -- on which we can make progress because the specific functional behaviours and expectations are clear. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 17:01:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27555; Mon, 11 Apr 2005 17:01:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6Bq-0007Qs-8W; Mon, 11 Apr 2005 17:11:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL62H-0007mW-Tx; Mon, 11 Apr 2005 17:01:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL62G-0007l9-5C for ltru@megatron.ietf.org; Mon, 11 Apr 2005 17:01:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27505 for ; Mon, 11 Apr 2005 17:01:29 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6Bg-0007Pj-TF for ltru@ietf.org; Mon, 11 Apr 2005 17:11:18 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LMXO55NLW000005R@mauve.mrochek.com> for ltru@ietf.org; Mon, 11 Apr 2005 14:01:25 -0700 (PDT) Date: Mon, 11 Apr 2005 14:00:40 -0700 (PDT) In-reply-to: "Your message dated Mon, 11 Apr 2005 11:56:50 -0700" Message-id: <01LMYXTT9VTM00005R@mauve.mrochek.com> References: Subject: RE: [Ltru] Re: Compatibility with existing use (LDAP) To: Peter Constable X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7BIT Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7BIT > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On Behalf Of > > Frank Ellermann > > > Of course, we cannot guarantee that no one will ever use > > > something like "en-Latn-GB", but we should not get overly > > > concerned about bad-practice usage. > > > > At the moment the complete formal definition of "bad practice" > > is an appeal to "use tags wisely", that's not enough. We need > > either language => script or script => language(s) pointers to > > define bad practice or good practice. > Agreed. > BTW, notice that now we're discussing how to ensure good practice to > avoid specific problems in functionality. This is quite different from > the unqualified statement "backwards compatibility is broken". Actually, the two are intimately related and almost impossible to separate. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 17:02:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27758; Mon, 11 Apr 2005 17:02:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6Cl-0007V4-MH; Mon, 11 Apr 2005 17:12:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5FE-00041E-R6; Mon, 11 Apr 2005 16:10:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL5FD-00040U-6j for ltru@megatron.ietf.org; Mon, 11 Apr 2005 16:10:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17246 for ; Mon, 11 Apr 2005 16:10:40 -0400 (EDT) Received: from rly-ip04.mx.aol.com ([64.12.138.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5OU-0003wB-Cb for ltru@ietf.org; Mon, 11 Apr 2005 16:20:28 -0400 Received: from smtp-los04.proxy.aol.com (smtp-los04.proxy.aol.com [195.93.24.101]) by rly-ip04.mx.aol.com (v98.19) with ESMTP id RELAYIN7-8425ad9a310e; Mon, 11 Apr 2005 16:10:11 -0400 Received: from DEBHOME (ACD86522.ipt.aol.com [172.216.101.34]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3BKA5aV004544; Mon, 11 Apr 2005 16:10:05 -0400 Message-Id: <200504112010.j3BKA5aV004544@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'Addison Phillips'" , "'LTRU Working Group'" Subject: RE: [Ltru] Great Script Debate Part II: Formats... Date: Mon, 11 Apr 2005 21:10:29 +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.2900.2180 Thread-Index: AcU+xrETzZpNDn3SRR6PYOiqoAziNwAB/ShA In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AFA3E7A@irvmbxw01.quest.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.101 X-Spam-Score: 2.6 (++) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit Addison Option 5 has my vote as it may leave room for an *ext_langtag (4 character alphanumeric) for the proposed ISO 639-6 in what I think is a logical place e.g. ll-lll-llll-CC-S-Ssss There MAY (something that will be discussed at a meeting of the 639-6 Task Group in June 05) also be a possibility that 639-6 will offer script and language in the same tag e.g. Central Siberian Yupik = ypkw (written) Central Siberian Yupik = ypkc (written Cyrl script) Central Siberian Yupik = ypkl (written Latn script) As mentioned before, I also think that the tag scheme should be referenced in the langtag itself... e.g. Lang(scheme_3066bis)= etc.... or it could be the BCP reference... Nothing is forever. It is also MHO that it SHOULD be a requirement to tag content wisely... for me wisely means put as much information in as possible... if the information is there and known to you... use it... the return for the time will be a much improved, user-friendly, informative WWW. This is just my opinion. Kind regards Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Addison Phillips Sent: 11 April 2005 19:46 To: LTRU Working Group Subject: [Ltru] Great Script Debate Part II: Formats... Having established that there exist some RFC 3066 tag processors in broad distribution whose results are impacted by the lang-script-region format, let's skip over the question of the level of harm and look at alternative formats next. I promise (JFC) to come back and visit the relative harm question. In this email, I'll use the subtags in the following 3066bis-style tag for demonstration purposes: de-Latn-CH-1901-x-gleep Let's consider the different ways that we can include script in a tag. For each option, I'll write out a tag with a script and a tag without a script. 1. Script first. With: Latn-de-CH-1901-x-gleep None: de-CH-1901-x-gleep This tag format has little to recommend it. Some folks may find that the script-first position seems more suited to a hierarchy of tags (many languages are written in one script), but this position doesn't add appreciably to the information conveyed by a *language* tag. It has the same problems as 3066bis's design for "smart" 3066 processors. In fact, it is worse, since it also pushes the language out of position. 2. Script combines with language. deLatn-CH-1901-x-gleep de-CH-1901-x-gleep This tag format fixes the region code problem. It also installs a "unique new format" that some have asked for. The problem here is that the two tags above really should refer to the same language and 3066 processors of all types (RFR, smart) will never get that. 3. Script after language de-Latn-CH-1901-x-gleep de-CH-1901-x-gleep This is RFC 3066bis, of course. The issue here is the script vs. region code that we're discussing. The advantage to this design is that script is at the right level in the tag in most cases. RFR processors can remove the script (unlike in 2) during matching. RFR matching works as long as users are consistent about using or not using script for a particular prefix. "Smart" 3066 matching can't find the region code with this design. (Smart 3066bis processing finds all subtags) 4. Script after region and before variant de-CH-Latn-1901-x-gleep de-CH-1901-x-gleep de-Latn-1901-x-gleep // lookout... This doesn't harm 3066 processors in most cases, but harms users of these implementations who need to find specific script versions of language. That is, RFR processors can't find matching scripts. "Smart" 3066 processors (such as the J2EE demo), get language and region into the right slots. 4a. Script as a variant. This is the same as (4), only the script is just another variant. Too boring to discuss. 5. Script as an extension de-CH-1901-s-Latn-x-gleep de-CH-1901-x-gleep de-1901-s-Latn-x-gleep // my previous example of a tag that harms smart processors This has the advantage of allowing 3066bis "smart" processors to put the script back between "de" and "CH" if it wants to internally, while not interfering with existing tags (note emphasis here: *tags*). RFR processors remove the script even before variant. 6. Script as an attribute de-CH-1901-x-gleep; script=Latn; q=1.0 de-CH-1901-x-gleep; q=1.0 This has the advantage of not mucking with the tags at all, but can't be used in contexts such as XML :-(. Who knows how matching works. 7. Script inferred from the tag de-CH-1901-x-gleep This is what we have today. If you see "zh-TW", that must mean Hant. Good luck if you live in HK. Any I missed? Now, before you choose one of these, don't' forget that you can do s/script/extlang/ on the above text. We don't just have one interpolated subtag, we have two. Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software http://www.quest.com Chair, W3C Internationalization Core Working Group http://www.w3.org/International Internationalization is not a feature. It is an architecture. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 17:04:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28377; Mon, 11 Apr 2005 17:04:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6E8-0007if-Op; Mon, 11 Apr 2005 17:13:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL60e-0007HL-6y; Mon, 11 Apr 2005 16:59:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL60c-0007GR-On for ltru@megatron.ietf.org; Mon, 11 Apr 2005 16:59:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27222 for ; Mon, 11 Apr 2005 16:59:43 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL69y-0007Fw-LM for ltru@ietf.org; Mon, 11 Apr 2005 17:09:31 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 13:59:35 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 13:59:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Great Script Debate Part II: Formats... Date: Mon, 11 Apr 2005 13:59:34 -0700 Message-ID: Thread-Topic: [Ltru] Great Script Debate Part II: Formats... Thread-Index: AcU+xrETzZpNDn3SRR6PYOiqoAziNwAD1MBg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 11 Apr 2005 20:59:35.0043 (UTC) FILETIME=[5DADE530:01C53ED9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > 3. Script after language >=20 > de-Latn-CH-1901-x-gleep > de-CH-1901-x-gleep >=20 > This is RFC 3066bis, of course. The issue here is the script vs. region code that we're > discussing. The advantage to this design is that script is at the right level in the tag in > most cases. RFR processors can remove the script (unlike in 2) during matching. RFR > matching works as long as users are consistent about using or not using script for a > particular prefix. "Smart" 3066 matching can't find the region code with this design. Clarification: "smart" 3066 matching can't find the region ID **in those cases** in which a script ID is included. We must keep in mind that our expectation is and has always been that, for all those existing use cases in which a script ID has never been used because it isn't needed, we expect no script ID would be used in the future. > 6. Script as an attribute >=20 > de-CH-1901-x-gleep; script=3DLatn; q=3D1.0 > de-CH-1901-x-gleep; q=3D1.0 >=20 > This has the advantage of not mucking with the tags at all, but can't be used in > contexts such as XML :-(. Who knows how matching works. It has other problems as well, both for XML and non-XML applications. Ned Freed identified problems that make it quite problematic for several IETF applications. =20 > 7. Script inferred from the tag >=20 > de-CH-1901-x-gleep >=20 > This is what we have today. If you see "zh-TW", that must mean Hant. Good luck if > you live in HK. Clearly inadequate. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 17:16:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01616; Mon, 11 Apr 2005 17:16:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6Py-0000Pa-HF; Mon, 11 Apr 2005 17:26:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL6G4-00055O-Ki; Mon, 11 Apr 2005 17:15:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL6G2-00053s-U2 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 17:15:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01492 for ; Mon, 11 Apr 2005 17:15:31 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6PI-0000MN-6n for ltru@ietf.org; Mon, 11 Apr 2005 17:25:20 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 14:15:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Great Script Debate Part II: Formats... Date: Mon, 11 Apr 2005 14:15:23 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3F5F@irvmbxw01.quest.com> Thread-Topic: [Ltru] Great Script Debate Part II: Formats... Thread-Index: AcU+xrETzZpNDn3SRR6PYOiqoAziNwAB/ShAAAKorTA= From: "Addison Phillips" To: "Debbie Garside" , "LTRU Working Group" X-OriginalArrivalTime: 11 Apr 2005 21:15:23.0851 (UTC) FILETIME=[933681B0:01C53EDB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Content-Transfer-Encoding: quoted-printable Hi Debbie, I don't think you understood the ramifications of the last paragraphs. Extlang has exactly the same problems that script does in the second = position. Moving alpha4 script codes would permit an extlang that is an = alpha4, but then you have the same problem script codes have: you fill = the same subtag position in the tag that some "smart" processor expects = (stupidly) to be region. More to the point, I thought that ISO 639-6 was supposed to supplant ISO = 639-1/-2 codes in the primary language tag (something that can happen in = the registry as designed). With regard to "forever": maybe so. I don't think I want to scrawl my = name under Ozymandias's?:-). But, at the same time, it makes a LOT of = sense to define a fairly rigid grammar for language tags with the = intention of "forever". This allows us to create a more complex series = of subtags without the danger of future incompatibility. We enumerate = exactly how tags can change in the future, so that implementations can = be built to deal with those changes now. Otherwise your future = lang(3066ter) tag is just a big opaque piece of junk I don't know how to = deal with (and I have to upgrade to a 3066ter capable piece of code to = deal with your 3066ter content). In my 3066bis implementation, even though I don't know what an extension = means, I can correctly process one every time. Ditto with extlangs. RFC 3066bis, in fact, makes use of the fact that it narrows the range of = subtags (and ONLY narrows it) to be compatible with 3066 = implementations. > Central Siberian Yupik =3D ypkw (written) > Central Siberian Yupik =3D ypkc (written Cyrl script) > Central Siberian Yupik =3D ypkl (written Latn script) And how do I select "all documents written in Central Siberian Yupik"? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: lundi 11 avril 2005 13:10 > To: Addison Phillips; 'LTRU Working Group' > Subject: RE: [Ltru] Great Script Debate Part II: Formats... >=20 > Addison >=20 > Option 5 has my vote as it may leave room for an *ext_langtag (4 = character > alphanumeric) for the proposed ISO 639-6 in what I think is a logical > place > e.g. >=20 > ll-lll-llll-CC-S-Ssss >=20 > There MAY (something that will be discussed at a meeting of the 639-6 = Task > Group in June 05) also be a possibility that 639-6 will offer script = and > language in the same tag e.g. >=20 > Central Siberian Yupik =3D ypkw (written) > Central Siberian Yupik =3D ypkc (written Cyrl script) > Central Siberian Yupik =3D ypkl (written Latn script) >=20 > As mentioned before, I also think that the tag scheme should be = referenced > in the langtag itself... >=20 > e.g. Lang(scheme_3066bis)=3D etc.... or it could be the BCP = reference... >=20 > Nothing is forever. >=20 > It is also MHO that it SHOULD be a requirement to tag content = wisely... > for > me wisely means put as much information in as possible... if the > information > is there and known to you... use it... the return for the time will be = a > much improved, user-friendly, informative WWW. >=20 > This is just my opinion. >=20 > Kind regards >=20 > Debbie >=20 >=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Addison Phillips > Sent: 11 April 2005 19:46 > To: LTRU Working Group > Subject: [Ltru] Great Script Debate Part II: Formats... >=20 > Having established that there exist some RFC 3066 tag processors in = broad > distribution whose results are impacted by the lang-script-region = format, > let's skip over the question of the level of harm and look at = alternative > formats next. I promise (JFC) to come back and visit the relative harm > question. >=20 > In this email, I'll use the subtags in the following 3066bis-style tag = for > demonstration purposes: >=20 > de-Latn-CH-1901-x-gleep >=20 > Let's consider the different ways that we can include script in a tag. = For > each option, I'll write out a tag with a script and a tag without a = script. >=20 > 1. Script first. >=20 > With: Latn-de-CH-1901-x-gleep > None: de-CH-1901-x-gleep >=20 > This tag format has little to recommend it. Some folks may find that = the > script-first position seems more suited to a hierarchy of tags (many > languages are written in one script), but this position doesn't add > appreciably to the information conveyed by a *language* tag. It has = the > same > problems as 3066bis's design for "smart" 3066 processors. In fact, it = is > worse, since it also pushes the language out of position. >=20 > 2. Script combines with language. >=20 > deLatn-CH-1901-x-gleep > de-CH-1901-x-gleep >=20 > This tag format fixes the region code problem. It also installs a = "unique > new format" that some have asked for. The problem here is that the two > tags > above really should refer to the same language and 3066 processors of = all > types (RFR, smart) will never get that. >=20 > 3. Script after language >=20 > de-Latn-CH-1901-x-gleep > de-CH-1901-x-gleep >=20 > This is RFC 3066bis, of course. The issue here is the script vs. = region > code > that we're discussing. The advantage to this design is that script is = at > the > right level in the tag in most cases. RFR processors can remove the = script > (unlike in 2) during matching. RFR matching works as long as users are > consistent about using or not using script for a particular prefix. > "Smart" > 3066 matching can't find the region code with this design. (Smart = 3066bis > processing finds all subtags) >=20 > 4. Script after region and before variant >=20 > de-CH-Latn-1901-x-gleep > de-CH-1901-x-gleep > de-Latn-1901-x-gleep // lookout... >=20 > This doesn't harm 3066 processors in most cases, but harms users of = these > implementations who need to find specific script versions of language. > That > is, RFR processors can't find matching scripts. "Smart" 3066 = processors > (such as the J2EE demo), get language and region into the right slots. >=20 > 4a. Script as a variant. >=20 > This is the same as (4), only the script is just another variant. Too > boring > to discuss. >=20 > 5. Script as an extension >=20 > de-CH-1901-s-Latn-x-gleep > de-CH-1901-x-gleep > de-1901-s-Latn-x-gleep // my previous example of a tag that harms = smart > processors >=20 > This has the advantage of allowing 3066bis "smart" processors to put = the > script back between "de" and "CH" if it wants to internally, while not > interfering with existing tags (note emphasis here: *tags*). RFR > processors > remove the script even before variant. >=20 > 6. Script as an attribute >=20 > de-CH-1901-x-gleep; script=3DLatn; q=3D1.0 > de-CH-1901-x-gleep; q=3D1.0 >=20 > This has the advantage of not mucking with the tags at all, but can't = be > used in contexts such as XML :-(. Who knows how matching works. >=20 > 7. Script inferred from the tag >=20 > de-CH-1901-x-gleep >=20 > This is what we have today. If you see "zh-TW", that must mean Hant. = Good > luck if you live in HK. >=20 >=20 > Any I missed? >=20 >=20 > Now, before you choose one of these, don't' forget that you can do > s/script/extlang/ on the above text. We don't just have one = interpolated > subtag, we have two. >=20 > Best Regards, >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > http://www.quest.com >=20 > Chair, W3C Internationalization Core Working Group > http://www.w3.org/International >=20 > Internationalization is not a feature. > It is an architecture. >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 18:03:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05502; Mon, 11 Apr 2005 18:03:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL79I-0001pk-Bg; Mon, 11 Apr 2005 18:12:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL6zm-0008C2-9j; Mon, 11 Apr 2005 18:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL6zk-0007zr-TB for ltru@megatron.ietf.org; Mon, 11 Apr 2005 18:03:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05456 for ; Mon, 11 Apr 2005 18:02:01 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL78J-0001nL-53 for ltru@ietf.org; Mon, 11 Apr 2005 18:11:51 -0400 Received: from h-64-105-136-143.snvacaid.dynamic.covad.net ([64.105.136.143] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DL6yo-0006C3-00 for ltru@ietf.org; Mon, 11 Apr 2005 15:02:02 -0700 Message-ID: <011a01c53ee2$4a1a5d60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fields from ISO documents Date: Mon, 11 Apr 2005 15:03:27 -0700 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: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Hi - > From: "Peter Constable" > To: > Sent: Monday, April 11, 2005 10:43 AM > Subject: RE: [Ltru] Re: registry should copy non-English fields fromISOdocuments ... > I think Lee's point is that the name used is intended to document the > conceptual entity in a way that ideally is unambiguous. I don't think > you two are actually disagreeing about anything; you're just struggling > over common words to describe a common understanding. ... Trying to sum up this thread: 1) there is a reference name from the ISO documents. In some cases this is the English name of the language, in others it's a transcription. This is currently part of an entry in the registry, and no one is suggesting that it be removed. 2) in some cases the ISO documents also include a French name for a language. This tracker item is on the question of whether this information, when available, should also be included in the registry. It looks like there is a slight preference among active participants in the WG to include this information. (Those who want it appear to want it more than those who oppose it don't want it.) 3) In those cases where a French name for a language is available from the ISO documents, the remaining question is whether it should be included in the same field as the reference name, using some kind of delimiter, or given a field of its own. Based on the technical arguments so far, I believe the preference would be to use a separate field to hold the French name, when available, for a language. Note that this resolution would NOT entail translating entries for which French translations are not already present in the ISO documents, nor would it require a registrant to obtain a French name for a language, nor should it be in any way understood as constraining the names displayed by implementations or used by users. Would this be an acceptable statement of rough consensus? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 18:10:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06529; Mon, 11 Apr 2005 18:10:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7Gm-0001zB-Ve; Mon, 11 Apr 2005 18:20:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL75j-0000zq-Mv; Mon, 11 Apr 2005 18:09:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL75h-0000zD-Ti for ltru@megatron.ietf.org; Mon, 11 Apr 2005 18:09:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06320 for ; Mon, 11 Apr 2005 18:09:06 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7FA-0001xS-DI for ltru@ietf.org; Mon, 11 Apr 2005 18:18:56 -0400 Received: from lns-p19-8-idf-82-249-21-108.adsl.proxad.net ([82.249.21.108] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DL75f-0001up-I5 for ltru@ietf.org; Mon, 11 Apr 2005 15:09:09 -0700 Message-Id: <6.1.2.0.2.20050411220844.04920eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 11 Apr 2005 22:25:44 +0200 To: ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Comment: use VU for Vanuatu (was: remove regionsubtag 200) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 At 21:51 11/04/2005, JFC (Jefsey) Morfin wrote: >At 21:01 11/04/2005, Randy Presuhn wrote: >> > You document that the draft does not match the charter. I noted that, and >> > also the conflict in the charter which calls for an independence from the >> > ISO evolutions and the possibility to identify the subtags in the tag. >> IMHO >> > this calls for a request of guidance to the IESG if the debate on the >> > charter (we still need to have, as Randy underlined it) does not deliver a >> > solution. >> > jfc >> >>The charter us not up for debate. >> >>Jfc: Bogus claims that a co-chair supports a particular position >>are not a good way to win friends or favorably influence people. Hi! Randy, I am sorry, but I do not really see the interest of this. The main purpose of a WG is neither to win friends nor to favorably influence people. It is to deliver a document which makes sense in addressing a charter, and users needs my job in life is to represent and address for 27 years. Subjective aspects may be of interest to help the thinking process. They can also hamper it. This being said, IRT "bogus", I quote: "(co-chair hat ON) Consider it motivation to get these issues resolved. Stream-of-consciousness is nice for brainstorming sessions, but we have a bunch of specific issues to resolve, as well as a couple of thorny questions from the charter that haven't seen much discussion. The tickets will allow us to reach closure quickly on the easy stuff, and I hope keep the heavy discussion threads on track." I long to see now these thorny questions being seriously discussed. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 18:12:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06700; Mon, 11 Apr 2005 18:12:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7I6-00020Q-NC; Mon, 11 Apr 2005 18:21:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL75j-0000zm-I0; Mon, 11 Apr 2005 18:09:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL75h-0000yu-Hh for ltru@megatron.ietf.org; Mon, 11 Apr 2005 18:09:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06316 for ; Mon, 11 Apr 2005 18:09:06 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7F9-0001xK-2T for ltru@ietf.org; Mon, 11 Apr 2005 18:18:56 -0400 Received: from lns-p19-8-idf-82-249-21-108.adsl.proxad.net ([82.249.21.108] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DL75e-0001up-KF; Mon, 11 Apr 2005 15:09:07 -0700 Message-Id: <6.1.2.0.2.20050411210311.02fe10c0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 00:08:49 +0200 To: "L.Gillam" , ltru From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] language or price tag ? In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A31E@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A21292A31E@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 I can only genuinely admire your certitudes. Even if they are on different matters than the ones I rise and I am therefore unable to discuss. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 18:12:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06718; Mon, 11 Apr 2005 18:12:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7I8-00020U-Gf; Mon, 11 Apr 2005 18:22:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL75s-00010e-Qn; Mon, 11 Apr 2005 18:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL75j-0000zh-7P for ltru@megatron.ietf.org; Mon, 11 Apr 2005 18:09:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06328 for ; Mon, 11 Apr 2005 18:09:07 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7FB-0001xW-N7 for ltru@ietf.org; Mon, 11 Apr 2005 18:18:57 -0400 Received: from lns-p19-8-idf-82-249-21-108.adsl.proxad.net ([82.249.21.108] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DL75h-0001up-Nu; Mon, 11 Apr 2005 15:09:10 -0700 Message-Id: <6.1.2.0.2.20050411222843.02f8a280@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 11 Apr 2005 22:48:04 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Compatibility with existing use (LDAP) In-Reply-To: <010201c53ece$4b970260$7f1afea9@oemcomputer> References: <010201c53ece$4b970260$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 At 21:40 11/04/2005, Randy Presuhn wrote: >That's why I'm suggesting that language, script, and orthography be >handled as *three* attributes. Agreed. > > If that idea is to be considered at all, then it requires written-form > > tags that involve more than just an ISO 15924 ID. > >Agreed. Agreed. > > But then you have a > > significant usability problem: should my current en-GB content be tagged > >(alternatives elided) > > > This scheme requires far more user guidance than what is currently > > proposed, and more than is feasible: it requires telling them how to > > judge e.g. whether a country distinction reflects a distinction in > > language variety, a distinction in written form, or both. >... The whole question of this WG. Is it "user guidance" or "user's guidance". Is a language a way people claiming to speak that language MUST speak, or is a language the first societal contract among people the relations assistance tools and services MUST support? Your use of "orthography" is interesting to replace (?), complete (?) ISO 3166. Is this a way to consider a geopolitical reference through a common orthography (as taught in school?). jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 18:22:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07781; Mon, 11 Apr 2005 18:22:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7Sb-0002I8-Ig; Mon, 11 Apr 2005 18:32:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7H0-0002bx-FY; Mon, 11 Apr 2005 18:20:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7Gy-0002bA-Li for ltru@megatron.ietf.org; Mon, 11 Apr 2005 18:20:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07619 for ; Mon, 11 Apr 2005 18:20:23 -0400 (EDT) Received: from rly-ip04.mx.aol.com ([64.12.138.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7Q5-0002C4-1o for ltru@ietf.org; Mon, 11 Apr 2005 18:30:13 -0400 Received: from smtp-los03.proxy.aol.com (smtp-los03.proxy.aol.com [195.93.24.41]) by rly-ip04.mx.aol.com (v98.19) with ESMTP id RELAYIN6-7425af81712d; Mon, 11 Apr 2005 18:20:07 -0400 Received: from DEBHOME (ACD86522.ipt.aol.com [172.216.101.34]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3BMK84I004532; Mon, 11 Apr 2005 18:20:09 -0400 Message-Id: <200504112220.j3BMK84I004532@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Randy Presuhn'" , Subject: RE: [Ltru] [psg.com #882] registry should copy non-English fieldsfrom ISO documents Date: Mon, 11 Apr 2005 23:20:33 +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.2900.2180 Thread-Index: AcU+4jtm18hO0pAkT1+IdzCneK30hgAAUT/A In-Reply-To: <011a01c53ee2$4a1a5d60$7f1afea9@oemcomputer> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.6 (++) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Hi Hi > 3) In those cases where a French name for a language is available from > the ISO documents, the remaining question is whether it should be > included in the same field as the reference name, using some kind of > delimiter, or given a field of its own. Based on the technical arguments so> far, I believe the preference would be to use a separate field to hold the French name, when available, for a language. This is how it is currently held within the -6. > > Note that this resolution would NOT entail translating entries for which > French translations are not already present in the ISO documents, nor >would it require a registrant to obtain a French name for a language, nor >should it be in any way understood as constraining the names displayed by >implementations or used by users. > > Would this be an acceptable statement of rough consensus? For me... Yes Kind regards Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > Sent: 11 April 2005 23:03 > To: ltru@ietf.org > Subject: Re: [Ltru] [psg.com #882] registry should copy non-English > fieldsfrom ISO documents > > Hi - > > > From: "Peter Constable" > > To: > > Sent: Monday, April 11, 2005 10:43 AM > > Subject: RE: [Ltru] Re: registry should copy non-English fields > fromISOdocuments > ... > > I think Lee's point is that the name used is intended to document the > > conceptual entity in a way that ideally is unambiguous. I don't think > > you two are actually disagreeing about anything; you're just struggling > > over common words to describe a common understanding. > ... > > Trying to sum up this thread: > > 1) there is a reference name from the ISO documents. In some cases > this is the English name of the language, in others it's a > transcription. > This is currently part of an entry in the registry, and no one is > suggesting > that it be removed. > > 2) in some cases the ISO documents also include a French name for > a language. This tracker item is on the question of whether this > information, > when available, should also be included in the registry. It looks > like there > is a slight preference among active participants in the WG to > include this > information. (Those who want it appear to want it more than those > who > oppose it don't want it.) > > 3) In those cases where a French name for a language is available from > the > ISO documents, the remaining question is whether it should be > included > in the same field as the reference name, using some kind of > delimiter, or > given a field of its own. Based on the technical arguments so > far, I believe > the preference would be to use a separate field to hold the French > name, > when available, for a language. > > Note that this resolution would NOT entail translating entries for which > French > translations are not already present in the ISO documents, nor would it > require > a registrant to obtain a French name for a language, nor should it be in > any way > understood as constraining the names displayed by implementations or used > by > users. > > Would this be an acceptable statement of rough consensus? > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 18:24:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07923; Mon, 11 Apr 2005 18:24:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7Tl-0002LT-KL; Mon, 11 Apr 2005 18:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7Jm-0003BY-TO; Mon, 11 Apr 2005 18:23:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7Jl-0003B8-Fr for ltru@megatron.ietf.org; Mon, 11 Apr 2005 18:23:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07821 for ; Mon, 11 Apr 2005 18:23:30 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7T6-0002If-2Q for ltru@ietf.org; Mon, 11 Apr 2005 18:33:20 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 15:23:23 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 15:23:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [psg.com #882] registry should copy non-English fieldsfrom ISO documents Date: Mon, 11 Apr 2005 15:23:22 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #882] registry should copy non-English fieldsfrom ISO documents Thread-Index: AcU+4kIsFHSVrANlQoe40zuhfBFRRgAAfKrg From: "Peter Constable" To: X-OriginalArrivalTime: 11 Apr 2005 22:23:22.0685 (UTC) FILETIME=[12632ED0:01C53EE5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Randy Presuhn > 1) there is a reference name from the ISO documents. In some cases > this is the English name of the language, in others it's a transcription... > 2) in some cases the ISO documents also include a French name for > a language. This also may, in some cases, be a transcription -- just one done for French speakers rather than English speakers. > This tracker item is on the question of whether this information, > when available, should also be included in the registry. It looks like there > is a slight preference among active participants in the WG to include this > information. I think it is unnecessary. On the other hand, I'm not absolutely opposed to it. Bruce Lilly had first suggested it (before the LTRU list was started), insisting that it was required for localization purposes and because excluding the French names was not accurately reflecting the ISO standard. I think the first reason is bogus, myself, and the second one not terribly important. If it's included, though, we just need to be aware that not all of the source ISO standards will necessarily have distinct English and French names; in particular, ISO 639-3 will have (initially) only "reference" names, which may or may not correspond to English names. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 18:34:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08594; Mon, 11 Apr 2005 18:34:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7dZ-0002Z1-Uz; Mon, 11 Apr 2005 18:44:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7P7-0004f3-RC; Mon, 11 Apr 2005 18:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7P5-0004eg-Rd for ltru@megatron.ietf.org; Mon, 11 Apr 2005 18:29:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08383 for ; Mon, 11 Apr 2005 18:29:00 -0400 (EDT) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7YQ-0002RF-4P for ltru@ietf.org; Mon, 11 Apr 2005 18:38:50 -0400 Received: from smtp-los01.proxy.aol.com (smtp-los01.proxy.aol.com [195.93.24.40]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN2-3425afa1a172; Mon, 11 Apr 2005 18:28:42 -0500 Received: from DEBHOME (ACD86522.ipt.aol.com [172.216.101.34]) by smtp-los01.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3BMSSMQ005507; Mon, 11 Apr 2005 18:28:30 -0400 Message-Id: <200504112228.j3BMSSMQ005507@smtp-los01.proxy.aol.com> From: "Debbie Garside" To: "'Addison Phillips'" , "'LTRU Working Group'" Subject: RE: [Ltru] Great Script Debate Part II: Formats... Date: Mon, 11 Apr 2005 23:28:53 +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.2900.2180 Thread-Index: AcU+xrETzZpNDn3SRR6PYOiqoAziNwAB/ShAAAKorTAAAWl+8A== In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AFA3F5F@irvmbxw01.quest.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.40 X-Spam-Score: 2.6 (++) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Content-Transfer-Encoding: 7bit Hi Addison See inline comments Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: 11 April 2005 22:15 > To: Debbie Garside; LTRU Working Group > Subject: RE: [Ltru] Great Script Debate Part II: Formats... > > Hi Debbie, > > I don't think you understood the ramifications of the last paragraphs. You could be right :-) > > Extlang has exactly the same problems that script does in the second > position. Moving alpha4 script codes would permit an extlang that is an > alpha4, but then you have the same problem script codes have: you fill the > same subtag position in the tag that some "smart" processor expects > (stupidly) to be region. OK... > > More to the point, I thought that ISO 639-6 was supposed to supplant ISO > 639-1/-2 codes in the primary language tag (something that can happen in > the registry as designed). Yes... they can be used in this way, if required, or as an extension to other 639 tags. -6 is not designed to supplant anything... it is part of the 639 family... and they are all required for differing reasons... but yes... -6 (as it stands) could be used on its own. When I look at your draft it says Lang = 2*3 Alpha... -6 is CURRENTLY alpha4. Have I missed something? The last I heard was that -6 (if it becomes standard) would have a singleton placed in front of it and be treated as a variant... has this changed? Perhaps you could clarify exactly how you would deal with -6 in its present form - which includes language families, groups, languages, dialects, written, spoken and signed. OAFN, it MAY be possible to use the Alpha4 langtag in -6 to denote writing system rather than script - something, as you are aware, I feel is more relevant and useful. Are you saying that, some time in the future, you could possibly foresee the proposed 639-6 Alpha4 as the primary language tag? > > With regard to "forever": maybe so. I don't think I want to scrawl my name > under Ozymandias's?:-). But, at the same time, it makes a LOT of sense to > define a fairly rigid grammar for language tags with the intention of > "forever". This allows us to create a more complex series of subtags > without the danger of future incompatibility. We enumerate exactly how > tags can change in the future, so that implementations can be built to > deal with those changes now. Otherwise your future lang(3066ter) tag is > just a big opaque piece of junk I don't know how to deal with (and I have > to upgrade to a 3066ter capable piece of code to deal with your 3066ter > content). > Just MHO... but what happens if 4 years down the line it isn't "forever" and some, as yet unseen, circumstance arises that means the whole system needs changing... who knows... but I do accept your point. I am looking at those industries that are going to use this RFC's rules to tag content for archive purposes... archives that may not be touched for 10 years. I hope you are right :-) > In my 3066bis implementation, even though I don't know what an extension > means, I can correctly process one every time. Ditto with extlangs. > > RFC 3066bis, in fact, makes use of the fact that it narrows the range of > subtags (and ONLY narrows it) to be compatible with 3066 implementations. > > > Central Siberian Yupik = ypkw (written) > > Central Siberian Yupik = ypkc (written Cyrl script) > > Central Siberian Yupik = ypkl (written Latn script) > > And how do I select "all documents written in Central Siberian Yupik"? In this instance... query "ypk*" but, preferably you would reference the hierarchical registry, as proposed for -6, that includes the "Mother" tag... just go up one LEVEL and stop at the associated "Written Object". If you want everything... written, spoken, signed... follow the "Mother Tags" until you get to the "Language Level" (in this instance up one level again). Best regards Debbie > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > Sent: lundi 11 avril 2005 13:10 > > To: Addison Phillips; 'LTRU Working Group' > > Subject: RE: [Ltru] Great Script Debate Part II: Formats... > > > > Addison > > > > Option 5 has my vote as it may leave room for an *ext_langtag (4 > character > > alphanumeric) for the proposed ISO 639-6 in what I think is a logical > > place > > e.g. > > > > ll-lll-llll-CC-S-Ssss > > > > There MAY (something that will be discussed at a meeting of the 639-6 > Task > > Group in June 05) also be a possibility that 639-6 will offer script and > > language in the same tag e.g. > > > > Central Siberian Yupik = ypkw (written) > > Central Siberian Yupik = ypkc (written Cyrl script) > > Central Siberian Yupik = ypkl (written Latn script) > > > > As mentioned before, I also think that the tag scheme should be > referenced > > in the langtag itself... > > > > e.g. Lang(scheme_3066bis)= etc.... or it could be the BCP reference... > > > > Nothing is forever. > > > > It is also MHO that it SHOULD be a requirement to tag content wisely... > > for > > me wisely means put as much information in as possible... if the > > information > > is there and known to you... use it... the return for the time will be a > > much improved, user-friendly, informative WWW. > > > > This is just my opinion. > > > > Kind regards > > > > Debbie > > > > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Addison Phillips > > Sent: 11 April 2005 19:46 > > To: LTRU Working Group > > Subject: [Ltru] Great Script Debate Part II: Formats... > > > > Having established that there exist some RFC 3066 tag processors in > broad > > distribution whose results are impacted by the lang-script-region > format, > > let's skip over the question of the level of harm and look at > alternative > > formats next. I promise (JFC) to come back and visit the relative harm > > question. > > > > In this email, I'll use the subtags in the following 3066bis-style tag > for > > demonstration purposes: > > > > de-Latn-CH-1901-x-gleep > > > > Let's consider the different ways that we can include script in a tag. > For > > each option, I'll write out a tag with a script and a tag without a > script. > > > > 1. Script first. > > > > With: Latn-de-CH-1901-x-gleep > > None: de-CH-1901-x-gleep > > > > This tag format has little to recommend it. Some folks may find that the > > script-first position seems more suited to a hierarchy of tags (many > > languages are written in one script), but this position doesn't add > > appreciably to the information conveyed by a *language* tag. It has the > > same > > problems as 3066bis's design for "smart" 3066 processors. In fact, it is > > worse, since it also pushes the language out of position. > > > > 2. Script combines with language. > > > > deLatn-CH-1901-x-gleep > > de-CH-1901-x-gleep > > > > This tag format fixes the region code problem. It also installs a > "unique > > new format" that some have asked for. The problem here is that the two > > tags > > above really should refer to the same language and 3066 processors of > all > > types (RFR, smart) will never get that. > > > > 3. Script after language > > > > de-Latn-CH-1901-x-gleep > > de-CH-1901-x-gleep > > > > This is RFC 3066bis, of course. The issue here is the script vs. region > > code > > that we're discussing. The advantage to this design is that script is at > > the > > right level in the tag in most cases. RFR processors can remove the > script > > (unlike in 2) during matching. RFR matching works as long as users are > > consistent about using or not using script for a particular prefix. > > "Smart" > > 3066 matching can't find the region code with this design. (Smart > 3066bis > > processing finds all subtags) > > > > 4. Script after region and before variant > > > > de-CH-Latn-1901-x-gleep > > de-CH-1901-x-gleep > > de-Latn-1901-x-gleep // lookout... > > > > This doesn't harm 3066 processors in most cases, but harms users of > these > > implementations who need to find specific script versions of language. > > That > > is, RFR processors can't find matching scripts. "Smart" 3066 processors > > (such as the J2EE demo), get language and region into the right slots. > > > > 4a. Script as a variant. > > > > This is the same as (4), only the script is just another variant. Too > > boring > > to discuss. > > > > 5. Script as an extension > > > > de-CH-1901-s-Latn-x-gleep > > de-CH-1901-x-gleep > > de-1901-s-Latn-x-gleep // my previous example of a tag that harms smart > > processors > > > > This has the advantage of allowing 3066bis "smart" processors to put the > > script back between "de" and "CH" if it wants to internally, while not > > interfering with existing tags (note emphasis here: *tags*). RFR > > processors > > remove the script even before variant. > > > > 6. Script as an attribute > > > > de-CH-1901-x-gleep; script=Latn; q=1.0 > > de-CH-1901-x-gleep; q=1.0 > > > > This has the advantage of not mucking with the tags at all, but can't be > > used in contexts such as XML :-(. Who knows how matching works. > > > > 7. Script inferred from the tag > > > > de-CH-1901-x-gleep > > > > This is what we have today. If you see "zh-TW", that must mean Hant. > Good > > luck if you live in HK. > > > > > > Any I missed? > > > > > > Now, before you choose one of these, don't' forget that you can do > > s/script/extlang/ on the above text. We don't just have one interpolated > > subtag, we have two. > > > > Best Regards, > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > http://www.quest.com > > > > Chair, W3C Internationalization Core Working Group > > http://www.w3.org/International > > > > Internationalization is not a feature. > > It is an architecture. > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 18:34:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08678; Mon, 11 Apr 2005 18:34:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7du-0002Zh-KG; Mon, 11 Apr 2005 18:44:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7RD-0004x2-M9; Mon, 11 Apr 2005 18:31:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7RC-0004wl-H6 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 18:31:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08472 for ; Mon, 11 Apr 2005 18:31:11 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7aW-0002Uh-8P for ltru@ietf.org; Mon, 11 Apr 2005 18:41:01 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 15:31:04 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 15:31:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Compatibility with existing use (LDAP) Date: Mon, 11 Apr 2005 15:31:03 -0700 Message-ID: Thread-Topic: [Ltru] Compatibility with existing use (LDAP) Thread-Index: AcU+zqqt2pmWZxI+SrKaj1E3WhCdqAAFraDg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 11 Apr 2005 22:31:03.0610 (UTC) FILETIME=[251EC1A0:01C53EE6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Randy Presuhn > > But then you have a > > significant usability problem: should my current en-GB content be tagged >=20 > (alternatives elided) >=20 > > This scheme requires far more user guidance than what is currently > > proposed, and more than is feasible: it requires telling them how to > > judge e.g. whether a country distinction reflects a distinction in > > language variety, a distinction in written form, or both. > ... >=20 > True, but these are distinctions that have been causing us grief. IMO, the distinctions we'd have to explain in an RFC would cause much more grief than the relatively minor grief we've been debating. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 18:52:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09663; Mon, 11 Apr 2005 18:52:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7vL-00032S-N3; Mon, 11 Apr 2005 19:02:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7ek-0007n1-KJ; Mon, 11 Apr 2005 18:45:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7ej-0007gj-1w for ltru@megatron.ietf.org; Mon, 11 Apr 2005 18:45:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09279 for ; Mon, 11 Apr 2005 18:45:09 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL7o2-0002q8-Qk for ltru@ietf.org; Mon, 11 Apr 2005 18:55:00 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3BMiv8k020395; Mon, 11 Apr 2005 18:44:57 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 11 Apr 2005 18:44:57 -0400 Date: Mon, 11 Apr 2005 18:44:57 -0400 From: John Cowan To: Debbie Garside Subject: Re: [Ltru] Great Script Debate Part II: Formats... Message-ID: <20050411224456.GA23496@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3F5F@irvmbxw01.quest.com> <200504112228.j3BMSSMQ005507@smtp-los01.proxy.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504112228.j3BMSSMQ005507@smtp-los01.proxy.aol.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Debbie Garside scripsit: > Are you saying that, some time in the future, you could possibly foresee the > proposed 639-6 Alpha4 as the primary language tag? Until we know more about 639-6, nobody can say. From what I understand, 639-6 4-alpha tags encode language varieties, and one must make use of tables to learn how the language varieties are interrelated. I don't know whether these external tables are a hierarchy or what. Any information you can reveal would be extremely useful. -- Si hoc legere scis, nimium eruditionis habes. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 19:00:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09987; Mon, 11 Apr 2005 19:00:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL82e-0003Ct-1r; Mon, 11 Apr 2005 19:10:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7s8-00011c-Hm; Mon, 11 Apr 2005 18:59:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL7s7-000115-4u for ltru@megatron.ietf.org; Mon, 11 Apr 2005 18:59:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09919 for ; Mon, 11 Apr 2005 18:58:59 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL81R-00039m-0l for ltru@ietf.org; Mon, 11 Apr 2005 19:08:50 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 15:58:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Great Script Debate Part II: Formats... Date: Mon, 11 Apr 2005 15:58:45 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA3FE8@irvmbxw01.quest.com> Thread-Topic: [Ltru] Great Script Debate Part II: Formats... Thread-Index: AcU+6TEGB2Y7H4vbRfWiCsF14kJKYQAAB9oA From: "Addison Phillips" To: "John Cowan" , "Debbie Garside" X-OriginalArrivalTime: 11 Apr 2005 22:58:45.0381 (UTC) FILETIME=[039CE350:01C53EEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Please note that the ABNF for lang is actually: lang =3D 2*3ALPHA ; shortest ISO 639 code / registered-lang registered-lang =3D 4*8ALPHA ; registered language subtag Which means that language subtags in the registry can be 2 to 8 = characters long. Full stop. So the answer to your question, Debbie, is = "yes, I can foresee possibly including alpha4 subtags from whatever = source in the future." If ISO 639-6 were to be considered by some future = iteration of this WG to be useful in language tags, then its codes can = be placed in the registry making them valid for use. The rules in = 3066bis make it exceedingly unlikely that very many, if any, alpha4 = registered values will be there to get in the way. (Personally, I'm with John's comments below, and would want to see it = before deciding for myself if there is additional utility in these = codes.) Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: lundi 11 avril 2005 15:45 > To: Debbie Garside > Cc: ltru@ietf.org > Subject: Re: [Ltru] Great Script Debate Part II: Formats... >=20 > Debbie Garside scripsit: >=20 > > Are you saying that, some time in the future, you could possibly = foresee > the > > proposed 639-6 Alpha4 as the primary language tag? >=20 > Until we know more about 639-6, nobody can say. From what I = understand, > 639-6 4-alpha tags encode language varieties, and one must make use of > tables to learn how the language varieties are interrelated. I don't > know whether these external tables are a hierarchy or what. >=20 > Any information you can reveal would be extremely useful. >=20 > -- > Si hoc legere scis, nimium eruditionis habes. >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 19:12:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10498; Mon, 11 Apr 2005 19:12:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL8E9-0003SI-Uv; Mon, 11 Apr 2005 19:21:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL83C-0002Qi-7W; Mon, 11 Apr 2005 19:10:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL83A-0002Q8-Jk for ltru@megatron.ietf.org; Mon, 11 Apr 2005 19:10:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10377 for ; Mon, 11 Apr 2005 19:10:32 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL8Cc-0003P5-Vw for ltru@ietf.org; Mon, 11 Apr 2005 19:20:23 -0400 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3BNAQ4I064354 for ; Mon, 11 Apr 2005 19:10:26 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3BNAPLZ248326 for ; Mon, 11 Apr 2005 17:10:25 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3BNAPre001103 for ; Mon, 11 Apr 2005 17:10:25 -0600 Received: from markdavis (mark-davis.sanjose.ibm.com [9.43.213.112]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3BNAOoC001078; Mon, 11 Apr 2005 17:10:25 -0600 Message-ID: <041901c53eeb$a3cb1800$447b3009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , References: <011a01c53ee2$4a1a5d60$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fieldsfrom ISO documents Date: Mon, 11 Apr 2005 16:10:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j3BNAQ4I064354 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable I agree with Peter. I still see no need for the addition of a French language field. And worry that that might be taken as a precedent for add= ing more and more language names. That kind of information belongs in a local= e repository, not in the language tag registry. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: Sent: Monday, April 11, 2005 15:03 Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fieldsfrom ISO documents > Hi - > > > From: "Peter Constable" > > To: > > Sent: Monday, April 11, 2005 10:43 AM > > Subject: RE: [Ltru] Re: registry should copy non-English fields fromISOdocuments > ... > > I think Lee's point is that the name used is intended to document the > > conceptual entity in a way that ideally is unambiguous. I don't think > > you two are actually disagreeing about anything; you're just struggli= ng > > over common words to describe a common understanding. > ... > > Trying to sum up this thread: > > 1) there is a reference name from the ISO documents. In some cases > this is the English name of the language, in others it's a transcription. > This is currently part of an entry in the registry, and no one = is suggesting > that it be removed. > > 2) in some cases the ISO documents also include a French name for > a language. This tracker item is on the question of whether th= is information, > when available, should also be included in the registry. It lo= oks like there > is a slight preference among active participants in the WG to include this > information. (Those who want it appear to want it more than th= ose who > oppose it don't want it.) > > 3) In those cases where a French name for a language is available f= rom the > ISO documents, the remaining question is whether it should be included > in the same field as the reference name, using some kind of delimiter, or > given a field of its own. Based on the technical arguments so far, I believe > the preference would be to use a separate field to hold the Fre= nch name, > when available, for a language. > > Note that this resolution would NOT entail translating entries for whic= h French > translations are not already present in the ISO documents, nor would it require > a registrant to obtain a French name for a language, nor should it be i= n any way > understood as constraining the names displayed by implementations or us= ed by > users. > > Would this be an acceptable statement of rough consensus? > > Randy, ltru co-chair > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 19:17:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10875; Mon, 11 Apr 2005 19:17:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL8Jf-0003aK-19; Mon, 11 Apr 2005 19:27:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL890-0003j1-PJ; Mon, 11 Apr 2005 19:16:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL88z-0003hP-FO for ltru@megatron.ietf.org; Mon, 11 Apr 2005 19:16:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10775 for ; Mon, 11 Apr 2005 19:16:33 -0400 (EDT) Received: from rly-ip04.mx.aol.com ([64.12.138.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL8IR-0003Vm-8j for ltru@ietf.org; Mon, 11 Apr 2005 19:26:24 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip04.mx.aol.com (v98.19) with ESMTP id RELAYIN10-b425b0544d9; Mon, 11 Apr 2005 19:16:20 -0400 Received: from DEBHOME (ACD86522.ipt.aol.com [172.216.101.34]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3BNGEJZ004252; Mon, 11 Apr 2005 19:16:14 -0400 Message-Id: <200504112316.j3BNGEJZ004252@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'John Cowan'" Subject: RE: [Ltru] Great Script Debate Part II: Formats... Date: Tue, 12 Apr 2005 00:16:38 +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.2900.2180 Thread-Index: AcU+6BSqgenQC7HFSpuf3tVQtfUrBwAAfOGA In-Reply-To: <20050411224456.GA23496@skunk.reutershealth.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 X-Spam-Score: 2.6 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Hi John > Debbie Garside scripsit: > > > Are you saying that, some time in the future, you could possibly foresee > the > > proposed 639-6 Alpha4 as the primary language tag? > > Until we know more about 639-6, nobody can say. From what I understand, > 639-6 4-alpha tags encode language varieties, and one must make use of > tables to learn how the language varieties are interrelated. I don't > know whether these external tables are a hierarchy or what. The data that -6 is currently based on is contained within a hierarchical system which relates language families, language groups, languages and varieties (I use that term loosely). > > Any information you can reveal would be extremely useful. At present, other than the information that I gave last year outlining the system (which basically stands), it would not be a good idea for me to reveal too much (perhaps my ISO/BSI colleagues currently monitoring this list can help here... I don't know the ISO protocol on this). The draft I (and my colleagues in the BSI WG) are working on will be discussed in Paris in June (1st) by the ISO 639-6 Task Group and at the ISO 639 WG in Poland in August. I will endeavour to have the document distributed before end of July and at that time I hope to be able to distribute for "expert" opinion. Kind regards Debbie > > -- > Si hoc legere scis, nimium eruditionis habes. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 19:33:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11976; Mon, 11 Apr 2005 19:33:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL8Yi-00041F-0A; Mon, 11 Apr 2005 19:43:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL8MI-0006E4-7m; Mon, 11 Apr 2005 19:30:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL8MH-0006Dd-65 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 19:30:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11742 for ; Mon, 11 Apr 2005 19:30:17 -0400 (EDT) Received: from rly-ip04.mx.aol.com ([64.12.138.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL8Vk-0003vI-Cu for ltru@ietf.org; Mon, 11 Apr 2005 19:40:08 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip04.mx.aol.com (v98.19) with ESMTP id RELAYIN9-a425b087977; Mon, 11 Apr 2005 19:30:01 -0400 Received: from DEBHOME (ACD86522.ipt.aol.com [172.216.101.34]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3BNU20s005883; Mon, 11 Apr 2005 19:30:02 -0400 Message-Id: <200504112330.j3BNU20s005883@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Addison Phillips'" , "'John Cowan'" Subject: RE: [Ltru] Great Script Debate Part II: Formats... Date: Tue, 12 Apr 2005 00:30:27 +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.2900.2180 Thread-Index: AcU+6TEGB2Y7H4vbRfWiCsF14kJKYQAAB9oAAAEq2CA= In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AFA3FE8@irvmbxw01.quest.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 X-Spam-Score: 2.6 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Thanks for clarifying :-) I will keep you informed of any/new developments within the proposed ISO 639-6. Kind regards Debbie > Addison wrote: > Please note that the ABNF for lang is actually: > > lang = 2*3ALPHA ; shortest ISO 639 code > / registered-lang > registered-lang = 4*8ALPHA ; registered language subtag > > Which means that language subtags in the registry can be 2 to 8 characters > long. Full stop. So the answer to your question, Debbie, is "yes, I can > foresee possibly including alpha4 subtags from whatever source in the > future." If ISO 639-6 were to be considered by some future iteration of > this WG to be useful in language tags, then its codes can be placed in the > registry making them valid for use. The rules in 3066bis make it > exceedingly unlikely that very many, if any, alpha4 registered values will > be there to get in the way. > > (Personally, I'm with John's comments below, and would want to see it > before deciding for myself if there is additional utility in these codes.) > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of John Cowan > > Sent: lundi 11 avril 2005 15:45 > > To: Debbie Garside > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Great Script Debate Part II: Formats... > > > > Debbie Garside scripsit: > > > > > Are you saying that, some time in the future, you could possibly > foresee > > the > > > proposed 639-6 Alpha4 as the primary language tag? > > > > Until we know more about 639-6, nobody can say. From what I understand, > > 639-6 4-alpha tags encode language varieties, and one must make use of > > tables to learn how the language varieties are interrelated. I don't > > know whether these external tables are a hierarchy or what. > > > > Any information you can reveal would be extremely useful. > > > > -- > > Si hoc legere scis, nimium eruditionis habes. > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 19:34:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12046; Mon, 11 Apr 2005 19:34:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL8a3-00042i-Vs; Mon, 11 Apr 2005 19:44:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL8Q3-0006sn-S6; Mon, 11 Apr 2005 19:34:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL8Q2-0006sI-EX for ltru@megatron.ietf.org; Mon, 11 Apr 2005 19:34:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12025 for ; Mon, 11 Apr 2005 19:34:02 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL8ZN-00041l-1b for ltru@ietf.org; Mon, 11 Apr 2005 19:43:54 -0400 Received: from lns-p19-8-idf-82-249-21-108.adsl.proxad.net ([82.249.21.108] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DL8PM-0006Pf-B3; Mon, 11 Apr 2005 16:33:33 -0700 Message-Id: <6.1.2.0.2.20050411225638.02f5e2d0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 01:33:04 +0200 To: "Addison Phillips" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Great Script Debate Part II: Formats... In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AFA3E7A@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0AFA3E7A@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA12025 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Content-Transfer-Encoding: quoted-printable At 20:46 11/04/2005, Addison Phillips wrote: >In this email, I'll use the subtags in the following 3066bis-style tag f= or=20 >demonstration purposes: >de-Latn-CH-1901-x-gleep Dear Addison, Thank you for this. I will comment from my point of view which is=20 orthogonality between format and content, calling for the format to be=20 adapted to the application rather than the content to be adapted to the=20 format. But I also understand your historical constraints (I did not thou= gh=20 they were so bad). So, do not take my comments as critics, but as pure=20 comment/explanation/question to be sure I follow your point. Then I consider if there is a way out of all this. >Let's consider the different ways that we can include script in a tag. F= or=20 >each option, I'll write out a tag with a script and a tag without a scri= pt. > >1. Script first. > >With: Latn-de-CH-1901-x-gleep >None: de-CH-1901-x-gleep > >This tag format has little to recommend it. Some folks may find that the= =20 >script-first position seems more suited to a hierarchy of tags (many=20 >languages are written in one script), but this position doesn't add=20 >appreciably to the information conveyed by a *language* tag. It has the=20 >same problems as 3066bis's design for "smart" 3066 processors. In fact, = it=20 >is worse, since it also pushes the language out of position. This might interest in several cases: 1. when you already know the script, this format permits to forget the=20 script - and stay compatible with former formats? (LDAP?) 2. when you want to access the information in using a system in its own=20 language, you must first know the script. But access (DNS, database,=20 matrix) is related to the query order, not to the sequence; so we agree. >2. Script combines with language. > >deLatn-CH-1901-x-gleep >de-CH-1901-x-gleep > >This tag format fixes the region code problem. It also installs a "uniqu= e=20 >new format" that some have asked for. The problem here is that the two=20 >tags above really should refer to the same language and 3066 processors = of=20 >all types (RFR, smart) will never get that. The unique format does not match the requirement of the Charter to be abl= e=20 to identify the subtags. The other problem is that this format follows th= e=20 ISO tables and is therefore not independent from the ISO evolution. It ad= ds=20 both problems. However, this negative aspects should not hide a totally different avenue= =20 which is aliasing (name or number or IPv6 address). The main problem in o= ur=20 discussion is still to define the framework - charter has not been=20 discussed. What do you think a language is, what is the purpose of the ta= g,=20 what is its application process, what is its use, what is the IANA=20 implication. We can discuss endlessly if the different associated decision parameters=20 are not defined. You decided that the solution was to be in a way you=20 analyzed and you know it is not perfect. And you want to be helped in=20 having it the less imperfect. I am not really able to help because I will= =20 have probably very different responses to the Charter "thorny" questions.= =20 But where I may be really able to help is that these responses - which wi= ll=20 necessarily be those of the market at some stage - could help you to=20 consider the problem differently and may be better solve it. >3. Script after language > >de-Latn-CH-1901-x-gleep >de-CH-1901-x-gleep > >This is RFC 3066bis, of course. The issue here is the script vs. region=20 >code that we're discussing. The advantage to this design is that script = is=20 >at the right level in the tag in most cases. RFR processors can remove t= he=20 >script (unlike in 2) during matching. RFR matching works as long as user= s=20 >are consistent about using or not using script for a particular prefix.=20 >"Smart" 3066 matching can't find the region code with this design. (Smar= t=20 >3066bis processing finds all subtags) I obviously have no objection to that. Except that format should not be=20 limited to 2 letters or 3 digits. I understand the sense it makes for XML= =20 processors. It makes no sense for processors of mine. The real point is:=20 does it make sense to people and web services? You responded - if I am=20 correct - that formats are orthogonal to web services and you did not=20 respond yet about word processors etc. So the only real issue is with use= rs. >4. Script after region and before variant > >de-CH-Latn-1901-x-gleep >de-CH-1901-x-gleep >de-Latn-1901-x-gleep // lookout... > >This doesn't harm 3066 processors in most cases, but harms users of thes= e=20 >implementations who need to find specific script versions of language.=20 >That is, RFR processors can't find matching scripts. "Smart" 3066=20 >processors (such as the J2EE demo), get language and region into the rig= ht=20 >slots. OK. This is again a problem internal to "your" W3C applications. Nothing=20 against this patching of the past, as long as we can proceed with some=20 innovative thinking for the future. Randy proposes a one tag per subtag=20 approach. I think it may not be the proper way to do that as tags, but th= at=20 this is definitely a serious step ahead. I am open to every flexibility i= n=20 calling on a stable external reference. >4a. Script as a variant. > >This is the same as (4), only the script is just another variant. Too=20 >boring to discuss. Accepted. >5. Script as an extension > >de-CH-1901-s-Latn-x-gleep >de-CH-1901-x-gleep >de-1901-s-Latn-x-gleep // my previous example of a tag that harms smart=20 >processors > >This has the advantage of allowing 3066bis "smart" processors to put the= =20 >script back between "de" and "CH" if it wants to internally, while not=20 >interfering with existing tags (note emphasis here: *tags*). RFR=20 >processors remove the script even before variant. Would Randy's proposition not be supported as a complete extension of tha= t?=20 I say that 5 descriptors are necessary. I have nothing against the idea=20 that all are supported this way. However ugly a format it would make. >6. Script as an attribute > >de-CH-1901-x-gleep; script=3DLatn; q=3D1.0 >de-CH-1901-x-gleep; q=3D1.0 > >This has the advantage of not mucking with the tags at all, but can't be= =20 >used in contexts such as XML :-(. Who knows how matching works. gee! it seems that you (W3C) created yourself quite a problem. I should=20 reread the architectural framework you published some times ago. But I fe= el=20 you violated there some of your extensibility, etc. most basic rules? >7. Script inferred from the tag > >de-CH-1901-x-gleep >This is what we have today. If you see "zh-TW", that must mean Hant. Goo= d=20 >luck if you live in HK. Frankly, is this a real problem? I mean status quo with the system you=20 specified, got developed and deployed. Why not to think about a new=20 generation? I know this means a big problem. But would that problem not b= e=20 smaller that the addition of all the problems you are going to create=20 yourself and ourselves? You are thinking about it for 2 years... makes a=20 lot of pages in the meanwhile. BCP 047 will not be updated before some=20 time. And then? All this will lead to will be ugly patches you do not wan= t=20 to match our own parameters when we go through. I do not know XML but I know the DNS. We were explained by many people al= l=20 the problems of the DNS if this, if that. Due to that they forced the IDN= A.=20 My relations here were "nice" when compared with the WH-IDN. Except that=20 they talked privately and every of them except one (not an author) accept= ed=20 the Draft was far from perfect (including conceptually). Anyway at the en= d=20 of the day we had IDNA to please ICANN (I would say as to please W3C) and= =20 to please China. There were after that a lot of fuss on the way to apply=20 IDNA and there is quite no more use except may be in the Latn countries. What I fear with your approach is that you take the same concept as IDNA:= =20 to try to compromise impossible needs, between an ASCII and a Multilingal= =20 Internets. And to be tied by your own format rigidity? Same problem with=20 the IP=A8v6 format rigidity ... >Any I missed? Yes, mine :-) Again, your proposition is OK for identification (with additional=20 referent/style element if more than a menu) because it is likely that the= =20 current ISO tables will not change much before a entire revision of the=20 matter has been carried. But, we must give the direction of the transitio= n=20 and of the future. The problem is not your proposition. But the way you want to present and=20 introduce it within the IETF framework .... as BCP 047. >Now, before you choose one of these, don=E2=80=99t' forget that you can = do=20 >s/script/extlang/ on the above text. We don't just have one interpolated= =20 >subtag, we have two. General comment. Let be candid. There is no real good solution to your need today. And you= r=20 need is part of the far more general answer to the need of a new generati= on=20 network IETF awaits for 13 years (since they found they missed IP=20 addresses) and I observed 21 years ago (when I interconnected the DoD, et= c.=20 to the public international networks and saw we missed some of the hooks=20 others networks had). The question is simple: is a patch worth the try no= w,=20 or would it not be better to reshape the whole network (I talk of its rea= l=20 architecture, not of NGN)? My feeling is that the reshape is necessary but I do not believe IETF is=20 ready for it. So the patch is advisable. But the patch must not try to ta= ke=20 the place of the reshape while the reshape is going to occur as a=20 grassroots process. Instead they should cooperate. This is why I advocate documents to be split a little bit differently tha= t=20 you did. 1. a standard virtual tags framework, describing the registry, the=20 procedures, the applications, the obligations of the formats to be BCP 04= 7=20 compliant. This will address ISO tables inclusion (and possibly other=20 tables) and IANA registry, as well as IANA data dissemination and=20 possible filtering guidelines as part of the registration process. Acces= s=20 to pertinence is not an easy issue to address. 2. the format/filtering system for XML, HTML, CLDR, LDAP, OPES, etc. May = be=20 one document by application. The interest is that the first document will be a Multilingual Internet=20 building block. With a universal scope. It should help your "local" W3C=20 needs to be put in a wider perspective and help their evolution. Its=20 interest is also that incidentally it respects the spirit of the Charter=20 better. Thank you. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 20:49:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17923; Mon, 11 Apr 2005 20:49:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL9km-00067E-Kx; Mon, 11 Apr 2005 20:59:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL9Yl-0004JA-GZ; Mon, 11 Apr 2005 20:47:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL9Yj-0004J2-IC for ltru@megatron.ietf.org; Mon, 11 Apr 2005 20:47:18 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17782 for ; Mon, 11 Apr 2005 20:47:14 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DL9VO-0007l0-6g for ltru@lists.ietf.org; Tue, 12 Apr 2005 02:43:50 +0200 Received: from 212.82.251.232 ([212.82.251.232]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 02:43:50 +0200 Received: from nobody by 212.82.251.232 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 02:43:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 12 Apr 2005 02:45:41 +0200 Organization: Lines: 11 Message-ID: <425B1A35.15F2@xyzzy.claranet.de> References: <011a01c53ee2$4a1a5d60$7f1afea9@oemcomputer> 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.232 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Those who want it appear to want it more than those who > oppose it don't want it. > Would this be an acceptable statement of rough consensus? If Jefsey promises that he won't add "* 2" to his calculations. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 21:01:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18457; Mon, 11 Apr 2005 21:01:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL9wC-0006NK-RC; Mon, 11 Apr 2005 21:11:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL9ll-00070b-Rt; Mon, 11 Apr 2005 21:00:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL9lk-00070S-Kz for ltru@megatron.ietf.org; Mon, 11 Apr 2005 21:00:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18441 for ; Mon, 11 Apr 2005 21:00:42 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL9vD-0006Mn-NK for ltru@ietf.org; Mon, 11 Apr 2005 21:10:32 -0400 Received: from lns-p19-8-idf-82-249-21-108.adsl.proxad.net ([82.249.21.108] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DL9lh-0005wv-U1; Mon, 11 Apr 2005 18:00:42 -0700 Message-Id: <6.1.2.0.2.20050412014332.0309ceb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 03:00:22 +0200 To: "Debbie Garside" , "'Randy Presuhn'" , From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] [psg.com #882] registry should copy non-English fieldsfrom ISO documents In-Reply-To: <200504112220.j3BMK84I004532@smtp-los03.proxy.aol.com> References: <011a01c53ee2$4a1a5d60$7f1afea9@oemcomputer> <200504112220.j3BMK84I004532@smtp-los03.proxy.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb At 00:20 12/04/2005, Debbie Garside wrote: > > 3) In those cases where a French name for a language is available from > > the ISO documents, the remaining question is whether it should be > > included in the same field as the reference name, using some kind of > > delimiter, or given a field of its own. Based on the technical arguments > > so far, I believe the preference would be to use a separate field to hold >the French name, when available, for a language. > >This is how it is currently held within the -6. OK. > > Note that this resolution would NOT entail translating entries for which > > French translations are not already present in the ISO documents, nor > >would it require a registrant to obtain a French name for a language, nor > >should it be in any way understood as constraining the names displayed by > >implementations or used by users. > > > > Would this be an acceptable statement of rough consensus? > >For me... Yes I am sorry, I can only repeat this a definitive blocking opposition for me. For the reasons I gave several times. However once the principle of dual language (at least) naming necessity is established, practical arrangements can be quite flexible. 1. if an Englist or French (or other languages to be added) name for a language is missing, it will be accepted as non fully documented until a name is provided (a IANA procedure and Reviewer will have to be designated). 2. the same IANA registration could only be entered in English or French. It will be up to the French/English Reviewer to make sure the name in the missing language(s) is provided. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 22:02:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21951; Mon, 11 Apr 2005 22:02:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLAsz-0007pp-Dw; Mon, 11 Apr 2005 22:12:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLAjA-00006x-7Y; Mon, 11 Apr 2005 22:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLAj9-00006k-N1 for ltru@megatron.ietf.org; Mon, 11 Apr 2005 22:02:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21938 for ; Mon, 11 Apr 2005 22:01:57 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLAsV-0007pR-9y for ltru@ietf.org; Mon, 11 Apr 2005 22:11:48 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3C21nEn021381; Mon, 11 Apr 2005 22:01:49 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 11 Apr 2005 22:01:56 -0400 Date: Mon, 11 Apr 2005 22:01:56 -0400 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fieldsfrom ISO documents Message-ID: <20050412020156.GA25185@skunk.reutershealth.com> References: <011a01c53ee2$4a1a5d60$7f1afea9@oemcomputer> <200504112220.j3BMK84I004532@smtp-los03.proxy.aol.com> <6.1.2.0.2.20050412014332.0309ceb0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.1.2.0.2.20050412014332.0309ceb0@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 JFC (Jefsey) Morfin scripsit: > 1. if an Englist or French (or other languages to be added) name for a > language is missing, it will be accepted as non fully documented until a > name is provided (a IANA procedure and Reviewer will have to be > designated). For lots of languages there is no Academie-standardized French name. (English doesn't have a corresponding concept, so there is no problem.) -- "But I am the real Strider, fortunately," John Cowan he said, looking down at them with his face jcowan@reutershealth.com softened by a sudden smile. "I am Aragorn son http://www.ccil.org/~cowaan of Arathorn, and if by life or death I can http://www.reutershealth.com save you, I will." --LotR Book I Chapter 10 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 22:17:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23006; Mon, 11 Apr 2005 22:17:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLB7l-0008Cv-8m; Mon, 11 Apr 2005 22:27:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLAv9-0002Tl-7T; Mon, 11 Apr 2005 22:14:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLAv8-0002Tg-BU for ltru@megatron.ietf.org; Mon, 11 Apr 2005 22:14:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22769 for ; Mon, 11 Apr 2005 22:14:27 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLB3U-000856-L5 for ltru@ietf.org; Mon, 11 Apr 2005 22:24:19 -0400 Received: from h-64-105-136-143.snvacaid.dynamic.covad.net ([64.105.136.143] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLAtt-0000SN-00 for ltru@ietf.org; Mon, 11 Apr 2005 19:13:13 -0700 Message-ID: <008801c53f05$6159f940$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <011a01c53ee2$4a1a5d60$7f1afea9@oemcomputer> <200504112220.j3BMK84I004532@smtp-los03.proxy.aol.com> <6.1.2.0.2.20050412014332.0309ceb0@mail.jefsey.com> Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fields from ISO documents Date: Mon, 11 Apr 2005 19:14:31 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi - Still trying to see if we can reach closure on this... > From: "JFC (Jefsey) Morfin" > To: "Debbie Garside" ; "'Randy Presuhn'" ; > Sent: Monday, April 11, 2005 6:00 PM > Subject: RE: [Ltru] [psg.com #882] registry should copy non-English fieldsfrom ISO documents ... > > > Note that this resolution would NOT entail translating entries for which > > > French translations are not already present in the ISO documents, nor > > >would it require a registrant to obtain a French name for a language, nor > > >should it be in any way understood as constraining the names displayed by > > >implementations or used by users. > > > > > > Would this be an acceptable statement of rough consensus? > > > >For me... Yes > > I am sorry, I can only repeat this a definitive blocking opposition for me. > For the reasons I gave several times. However once the principle of dual > language (at least) naming necessity is established, practical arrangements > can be quite flexible. > > 1. if an Englist or French (or other languages to be added) name for a > language is missing, it will be accepted as non fully documented until a > name is provided (a IANA procedure and Reviewer will have to be designated). > 2. the same IANA registration could only be entered in English or French. > It will be up to the French/English Reviewer to make sure the name in the > missing language(s) is provided. ... Currently, Jefsey, John Cowan, and Ned Freed have written in support of including the French names. Addison Phillips and Randy Presuhn have written in opposition to it. Numerous others have posted messages in this thread, but their comments have been on the technical details, and have not included clear statements of support for or opposition to the proposal. If you would like to be in my tally of those in support or in opposition, please make an appropriate posting to the WG mailing list in this thread. Of those who support copying available French names (and transcriptions) for the names of languages, would you be willing to support Jefsey's provisos? Of those who have been neutral on the question, would Jeffsey's provisos make it unpalatable? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 22:22:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23355; Mon, 11 Apr 2005 22:22:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLBCC-0008JS-VS; Mon, 11 Apr 2005 22:32:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLB1O-0003BC-Vb; Mon, 11 Apr 2005 22:20:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLB1N-0003B7-JB for ltru@megatron.ietf.org; Mon, 11 Apr 2005 22:20:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23295 for ; Mon, 11 Apr 2005 22:20:54 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLBAr-0008IL-DY for ltru@ietf.org; Mon, 11 Apr 2005 22:30:46 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3C2KldG021468; Mon, 11 Apr 2005 22:20:47 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 11 Apr 2005 22:20:52 -0400 Date: Mon, 11 Apr 2005 22:20:51 -0400 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fields from ISO documents Message-ID: <20050412022051.GB25185@skunk.reutershealth.com> References: <011a01c53ee2$4a1a5d60$7f1afea9@oemcomputer> <200504112220.j3BMK84I004532@smtp-los03.proxy.aol.com> <6.1.2.0.2.20050412014332.0309ceb0@mail.jefsey.com> <008801c53f05$6159f940$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008801c53f05$6159f940$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Randy Presuhn scripsit: > Of those who support copying available French names (and transcriptions) > for the names of languages, would you be willing to support Jefsey's > provisos? No, indeed. Most 639-3 names don't have French versions, and because standard written French is a vocabulary-controlled language (unlike standard written English) there is no reasonable prospect of getting such standard names. -- Unless it was by accident that I had John Cowan offended someone, I never apologized. jcowan@reutershealth.com --Quentin Crisp http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 22:26:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24165; Mon, 11 Apr 2005 22:26:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLBGS-0008UK-N7; Mon, 11 Apr 2005 22:36:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLB6U-0004EQ-8p; Mon, 11 Apr 2005 22:26:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLB6S-0004E8-Qd for ltru@megatron.ietf.org; Mon, 11 Apr 2005 22:26:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24044 for ; Mon, 11 Apr 2005 22:26:02 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLBFo-0008RN-Ix for ltru@ietf.org; Mon, 11 Apr 2005 22:35:53 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 19:25:54 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 19:25:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [psg.com #882] registry should copy non-Englishfieldsfrom ISO documents Date: Mon, 11 Apr 2005 19:25:55 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #882] registry should copy non-Englishfieldsfrom ISO documents Thread-Index: AcU++wEoU5b7vezdTXa+I5YXRG22fAACm5nA From: "Peter Constable" To: X-OriginalArrivalTime: 12 Apr 2005 02:25:52.0117 (UTC) FILETIME=[F2865250:01C53F06] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of JFC (Jefsey) Morfin > I am sorry, I can only repeat this a definitive blocking opposition for me. Just to keep perspective, something being a definite blocking issue for you doesn't mean it is necessarily a blocking issue for this process. > For the reasons I gave several times. However once the principle of dual > language (at least) naming necessity is established, practical > arrangements > can be quite flexible. >=20 > 1. if an Englist or French (or other languages to be added) name for a > language is missing, it will be accepted as non fully documented until a > name is provided (a IANA procedure and Reviewer will have to be > designated). > 2. the same IANA registration could only be entered in English or French. > It will be up to the French/English Reviewer to make sure the name in the > missing language(s) is provided. This points to a reason why I think maintaining names in two languages might *not* be such a great idea: it leads to a whole lot more maintenance, with no significant benefit for the registry qua registry in return. If we are going to have names in more than one language, then - it should be at most English, French, and the auto-nym(s) used within the language community - there should be *no* requirement or expectation that the names will be reviewed or revised after addition to the registry except in case the source ISO standard introduces a revision to a name (if the maintainers of the registry wish to do more, they may do so at their discretion, but it should not be required or expected of them) Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 22:30:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24391; Mon, 11 Apr 2005 22:30:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLBKR-00007w-HU; Mon, 11 Apr 2005 22:40:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLB9F-0004Zv-3S; Mon, 11 Apr 2005 22:29:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLB9E-0004Ze-Dn for ltru@megatron.ietf.org; Mon, 11 Apr 2005 22:29:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24298 for ; Mon, 11 Apr 2005 22:28:53 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLBIa-0008W5-2l for ltru@ietf.org; Mon, 11 Apr 2005 22:38:45 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 19:28:45 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 11 Apr 2005 19:28:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [psg.com #882] registry should copy non-English fieldsfrom ISO documents Date: Mon, 11 Apr 2005 19:28:46 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #882] registry should copy non-English fieldsfrom ISO documents Thread-Index: AcU/BfTspfL1TV4ZRdyMmy7SUMgSTwAASHUA From: "Peter Constable" To: X-OriginalArrivalTime: 12 Apr 2005 02:28:43.0225 (UTC) FILETIME=[58835490:01C53F07] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > Currently, Jefsey, John Cowan, and Ned Freed have written in support > of including the French names. Addison Phillips and Randy Presuhn have > written in opposition to it. Numerous others have posted messages in this > thread, but their comments have been on the technical details, and have > not > included clear statements of support for or opposition to the proposal. Both Mark Davis and I indicated a preference that French names *not* be included. > Of those who have been neutral on the question, would Jeffsey's provisos > make it unpalatable? Speaking for myself only, Yes. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 22:32:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24471; Mon, 11 Apr 2005 22:32:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLBLy-00009L-Vy; Mon, 11 Apr 2005 22:42:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLBCJ-0004uE-Am; Mon, 11 Apr 2005 22:32:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLBCI-0004tV-8x for ltru@megatron.ietf.org; Mon, 11 Apr 2005 22:32:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24439 for ; Mon, 11 Apr 2005 22:31:58 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLBLZ-00008e-1v for ltru@ietf.org; Mon, 11 Apr 2005 22:41:50 -0400 Received: from h-64-105-136-143.snvacaid.dynamic.covad.net ([64.105.136.143] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLBC2-0000T8-00 for ltru@ietf.org; Mon, 11 Apr 2005 19:31:58 -0700 Message-ID: <00ae01c53f08$007b5c60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <011a01c53ee2$4a1a5d60$7f1afea9@oemcomputer><200504112220.j3BMK84I004532@smtp-los03.proxy.aol.com><6.1.2.0.2.20050412014332.0309ceb0@mail.jefsey.com> <008801c53f05$6159f940$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fieldsfrom ISO documents Date: Mon, 11 Apr 2005 19:33:24 -0700 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: 93238566e09e6e262849b4f805833007 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi - I missed one person in my tally: Pro: Jefsey Morfin, John Cowan, and Ned Freed Contra: Addison Phillips, Randy Presuhn, and Mark Davis If you would like to be in my tally of those in support or in opposition, please make an appropriate posting to the WG mailing list in this thread. Of those who support copying available French names (and transcriptions) for the names of languages, would you be willing to support Jefsey's provisos? My "pro" tally is Jefsey Morfin, "contra": John Cowan. Of those who have been neutral on the question, would Jeffsey's provisos make it unpalatable to you? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 22:41:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24924; Mon, 11 Apr 2005 22:41:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLBUd-0000Lt-Tm; Mon, 11 Apr 2005 22:51:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLBFf-0005zn-Sw; Mon, 11 Apr 2005 22:35:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLBFe-0005x1-6G for ltru@megatron.ietf.org; Mon, 11 Apr 2005 22:35:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24663 for ; Mon, 11 Apr 2005 22:35:39 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLBP9-0000Fy-2A for ltru@ietf.org; Mon, 11 Apr 2005 22:45:31 -0400 Received: from h-64-105-136-143.snvacaid.dynamic.covad.net ([64.105.136.143] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLBFc-0001Sb-00 for ltru@ietf.org; Mon, 11 Apr 2005 19:35:41 -0700 Message-ID: <00b701c53f08$854c8540$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fieldsfromISO documents Date: Mon, 11 Apr 2005 19:37:07 -0700 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: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi - > From: "Peter Constable" > To: > Sent: Monday, April 11, 2005 7:28 PM > Subject: RE: [Ltru] [psg.com #882] registry should copy non-English fieldsfromISO documents ... > Both Mark Davis and I indicated a preference that French names *not* be > included. ... Ok, so my updated tally is: Pro: Jefsey Morfin, John Cowan, and Ned Freed Contra: Addison Phillips, Randy Presuhn, Mark Davis, and Peter Constable If you would like to be in my tally of those in support or in opposition, please make an appropriate posting to the WG mailing list in this thread. Of those who support copying available French names (and transcriptions) for the names of languages, would you be willing to support Jefsey's provisos? My "pro" tally is Jefsey Morfin, "contra": John Cowan. Of those who have been neutral on the question, would Jeffsey's provisos make it unpalatable to you? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 22:53:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25524; Mon, 11 Apr 2005 22:53:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLBgi-0000dt-Es; Mon, 11 Apr 2005 23:03:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLBW8-0008WH-2M; Mon, 11 Apr 2005 22:52:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLBW7-0008VY-9E for ltru@megatron.ietf.org; Mon, 11 Apr 2005 22:52:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25462 for ; Mon, 11 Apr 2005 22:52:32 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLBfT-0000b2-9j for ltru@ietf.org; Mon, 11 Apr 2005 23:02:24 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3C2qNqg021576; Mon, 11 Apr 2005 22:52:23 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 11 Apr 2005 22:52:35 -0400 Date: Mon, 11 Apr 2005 22:52:35 -0400 From: John Cowan To: Debbie Garside Subject: Re: [Ltru] Great Script Debate Part II: Formats... Message-ID: <20050412025235.GB25948@skunk.reutershealth.com> References: <20050411224456.GA23496@skunk.reutershealth.com> <200504112316.j3BNGEJZ004252@smtp-los02.proxy.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504112316.j3BNGEJZ004252@smtp-los02.proxy.aol.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Debbie Garside scripsit: > At present, other than the information that I gave last year outlining the > system (which basically stands), it would not be a good idea for me to > reveal too much (perhaps my ISO/BSI colleagues currently monitoring this > list can help here... I don't know the ISO protocol on this). I think that the most important point for this list is: is there going to be a normative mapping between -6 tags and -1/-2 tags, and if so, will -3 and -5 tags be mapped when those parts are available? Or is the basis for -6 irreconcilable (not in principle but in detail) with the unified model of -1/-2/-3/-4/-5? -- You let them out again, Old Man Willow! John Cowan What you be a-thinking of? You should not be waking! jcowan@reutershealth.com Eat earth! Dig deep! Drink water! Go to sleep! www.reutershealth.com Bombadil is talking. www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 23:42:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28993; Mon, 11 Apr 2005 23:42:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLCSI-0001yf-Lo; Mon, 11 Apr 2005 23:52:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLCHb-0008EO-DE; Mon, 11 Apr 2005 23:41:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLCHZ-0008EJ-Pj for ltru@megatron.ietf.org; Mon, 11 Apr 2005 23:41:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28904 for ; Mon, 11 Apr 2005 23:41:42 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLCR4-0001xE-9Q for ltru@ietf.org; Mon, 11 Apr 2005 23:51:35 -0400 Received: from lns-p19-8-idf-82-249-21-108.adsl.proxad.net ([82.249.21.108] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLCHW-0003bV-N2 for ltru@ietf.org; Mon, 11 Apr 2005 20:41:43 -0700 Message-Id: <6.1.2.0.2.20050412042736.0331a020@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 05:41:25 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fields from ISO documents In-Reply-To: <20050412022051.GB25185@skunk.reutershealth.com> References: <011a01c53ee2$4a1a5d60$7f1afea9@oemcomputer> <200504112220.j3BMK84I004532@smtp-los03.proxy.aol.com> <6.1.2.0.2.20050412014332.0309ceb0@mail.jefsey.com> <008801c53f05$6159f940$7f1afea9@oemcomputer> <20050412022051.GB25185@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On 04:20 12/04/2005, John Cowan said: >Randy Presuhn scripsit: > > Of those who support copying available French names (and transcriptions) > > for the names of languages, would you be willing to support Jefsey's > > provisos? > >No, indeed. Most 639-3 names don't have French versions, and because >standard written French is a vocabulary-controlled language (unlike >standard written English) there is no reasonable prospect of getting >such standard names. Can you please fully document or remove these two statements. jfc PS. Randy, I note you use my comment to Debbie's as a basis for your gallop but do not quote her. I agree with Peter that ISO 639-3 maintainers' position should prevail (after througouht considerations of the situation and of ISO 639-1-2-3-4-6 and the serious crossverification of the ISO 639-3 English list the ISO 639-3 French list work is structurally intended for). I am not sure our Charter includes an opposition to ISO 639 practices. Peter, my position has not changed since August. Until now I believe it has helped you. I am surprised you consider the dual language ISO QA of low interest. BTW I would have no problem in adopting autonyms as sole reference names - but I feel a equivalent amount of work would be necessary. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 23:49:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29283; Mon, 11 Apr 2005 23:49:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLCYI-00025H-EG; Mon, 11 Apr 2005 23:59:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLCMa-0000Kr-CE; Mon, 11 Apr 2005 23:46:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLCMZ-0000Kd-CK for ltru@megatron.ietf.org; Mon, 11 Apr 2005 23:46:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29200 for ; Mon, 11 Apr 2005 23:46:44 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLCVv-00023Z-RT for ltru@ietf.org; Mon, 11 Apr 2005 23:56:37 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Apr 2005 20:46:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] [psg.com #882] registry should copy non-English fieldsfromISO documents Date: Mon, 11 Apr 2005 20:46:30 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA40AA@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #882] registry should copy non-English fieldsfromISO documents Thread-Index: AcU/B92AOJGrtL/6Soewl0v9nTaTwQACTXcQ From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 12 Apr 2005 03:46:31.0138 (UTC) FILETIME=[36CE5420:01C53F12] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable I am firmly against Jefsey's provisos as being unworkable, even if we = decide to do a two-language registry. I am still happier with the description field be the name of the subtag = transcribed into Latin script. Which transcription is open. This is = merely a useful descriptive identifier. If you want more text or a = description in a particular language, register a comment. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: lundi 11 avril 2005 19:33 > To: ltru@ietf.org > Subject: Re: [Ltru] [psg.com #882] registry should copy non-English > fieldsfromISO documents >=20 > Hi - >=20 > I missed one person in my tally: >=20 > Pro: > Jefsey Morfin, John Cowan, and Ned Freed >=20 > Contra: > Addison Phillips, Randy Presuhn, and Mark Davis >=20 > If you would like to be in my tally of those in support or in = opposition, > please > make an appropriate posting to the WG mailing list in this thread. >=20 > Of those who support copying available French names (and = transcriptions) > for the names of languages, would you be willing to support Jefsey's > provisos? My "pro" tally is Jefsey Morfin, "contra": John Cowan. >=20 > Of those who have been neutral on the question, would Jeffsey's = provisos > make it unpalatable to you? >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Mon Apr 11 23:49:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29303; Mon, 11 Apr 2005 23:49:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLCYJ-00025L-43; Mon, 11 Apr 2005 23:59:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLCOI-0000Oj-KI; Mon, 11 Apr 2005 23:48:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLCOH-0000OR-OE for ltru@megatron.ietf.org; Mon, 11 Apr 2005 23:48:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29269 for ; Mon, 11 Apr 2005 23:48:30 -0400 (EDT) Received: from office.oasis-open.org ([65.211.1.194] helo=mail.oasis-open.org) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLCXe-000250-At for ltru@ietf.org; Mon, 11 Apr 2005 23:58:23 -0400 Received: (qmail 1605 invoked by uid 500); 12 Apr 2005 04:14:44 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 12 Apr 2005 04:14:44 -0000 Date: Tue, 12 Apr 2005 00:14:43 -0400 (EDT) From: Robin Cover X-X-Sender: robin@localhost.localdomain To: Randy Presuhn Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fields from ISO documents In-Reply-To: <008801c53f05$6159f940$7f1afea9@oemcomputer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 I do not support a proposal to copy French names (and transcriptions), as this creates multiple new difficulties (potentially) and provides no useful solution to any technical requirement. Robin Cover _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 00:04:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00350; Tue, 12 Apr 2005 00:04:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLCn9-0002dM-KN; Tue, 12 Apr 2005 00:14:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLCcz-0003fI-A1; Tue, 12 Apr 2005 00:03:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLCcx-0003fD-8r for ltru@megatron.ietf.org; Tue, 12 Apr 2005 00:03:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00321 for ; Tue, 12 Apr 2005 00:03:47 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLCmS-0002cc-M6 for ltru@ietf.org; Tue, 12 Apr 2005 00:13:40 -0400 Received: from h-64-105-136-143.snvacaid.dynamic.covad.net ([64.105.136.143] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLCcv-0007Gd-00 for ltru@ietf.org; Mon, 11 Apr 2005 21:03:49 -0700 Message-ID: <000401c53f14$d30149e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "ltru Working Group" References: <011a01c53ee2$4a1a5d60$7f1afea9@oemcomputer><200504112220.j3BMK84I004532@smtp-los03.proxy.aol.com><6.1.2.0.2.20050412014332.0309ceb0@mail.jefsey.com><008801c53f05$6159f940$7f1afea9@oemcomputer><20050412022051.GB25185@skunk.reutershealth.com> <6.1.2.0.2.20050412042736.0331a020@mail.jefsey.com> Subject: Re: [Ltru] [psg.com #882] registry should copy non-Englishfields from ISO documents Date: Mon, 11 Apr 2005 21:05:10 -0700 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: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Hi - > From: "JFC (Jefsey) Morfin" > To: "ltru Working Group" > Sent: Monday, April 11, 2005 8:41 PM > Subject: Re: [Ltru] [psg.com #882] registry should copy non-Englishfields from ISO documents ... > Randy, > I note you use my comment to Debbie's as a basis for your gallop but do not > quote her. I am not able to figure out what this statement is supposed to mean. Do you have a problem or technical comment? > I agree with Peter that ISO 639-3 maintainers' position should > prevail (after througouht considerations of the situation and of ISO > 639-1-2-3-4-6 and the serious crossverification of the ISO 639-3 English > list the ISO 639-3 French list work is structurally intended for). I am not > sure our Charter includes an opposition to ISO 639 practices. ... The charter says: "It is also expected to provide mechanisms to support the evolution of the underlying ISO standards, in particular ISO 639-3..." This means that whatever solution this WG produces, one of the requirements that should be satisfied is the ability to cope with revisions to ISO 639-3, within reason. A blind re-statement of the ISO list fixed at some point in time will almost certainly not meet that requirement. Consequently, I would expect that what this WG produces will identify ISO 639-3 as one of its inputs, but that there would also be additional information and policy beyond that in order to satisfy our other charter requirements. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 00:31:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02135; Tue, 12 Apr 2005 00:31:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLDDA-0003J2-Mh; Tue, 12 Apr 2005 00:41:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLD2Z-0007iE-FY; Tue, 12 Apr 2005 00:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLD2Y-0007h7-Dk for ltru@megatron.ietf.org; Tue, 12 Apr 2005 00:30:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02073 for ; Tue, 12 Apr 2005 00:30:06 -0400 (EDT) Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLDBv-0003HO-15 for ltru@ietf.org; Tue, 12 Apr 2005 00:40:00 -0400 Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050412042950.JRDU5402.mta11.adelphia.net@DEWELL> for ; Tue, 12 Apr 2005 00:29:50 -0400 Message-ID: <00d801c53f18$27a336e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0AFA3D6F@irvmbxw01.quest.com> Subject: Re: [Ltru] New registry 2005-04-08 Date: Mon, 11 Apr 2005 21:28:57 -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.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Addison Phillips wrote: >> Note that multiple spaces within a subtag are collapsed to a single >> space. > > I believe this means "Note that you should collapse multiple > whitespace characters in a value (field-body in the proto-draft) to a > single space." I went to sleep five minutes after writing that. Should have been an hour before. Yes, that's what I meant to say. :-) -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 01:34:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05318; Tue, 12 Apr 2005 01:34:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLEBg-0004ha-1a; Tue, 12 Apr 2005 01:43:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLDyb-0007kf-Hr; Tue, 12 Apr 2005 01:30:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLDyZ-0007j0-RW for ltru@megatron.ietf.org; Tue, 12 Apr 2005 01:30:15 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05022 for ; Tue, 12 Apr 2005 01:29:58 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050412052927.KXUB5402.mta11.adelphia.net@DEWELL> for ; Tue, 12 Apr 2005 01:29:27 -0400 Message-ID: <010901c53f20$91507640$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050412034930.YEXI2140.mta3.adelphia.net@megatron.ietf.org> Date: Mon, 11 Apr 2005 22:29:14 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Of those who support copying available French names (and transcriptions) > for the names of languages, would you be willing to support Jefsey's > provisos? My "pro" tally is Jefsey Morfin, "contra": John Cowan. I am almost totally neutral on the basic question of adding French names. Maybe 51-49 in favor. I am *completely* opposed to making this a precedent for adding names in any other language. The registry is not a general localization resource. Note that this question should not apply only to language subtags, but to scripts, regions, variants, and (when they become available) extended-language subtags and extensions. > Of those who have been neutral on the question, would Jefsey's provisos > make it unpalatable to you? Yes, mostly. I can see some value in being consistent with the bilingual nature of the names, as opposed to having some in two languages and others in only one. But they are already inconsistent in that regard; there is no currently documented French translation of "Boontling" or "Scouse." It was just stated on the list that many of the ISO 639-3 languages have a "reference name" that is not inherently English or French. I don't like the idea of appointing a French/English Policeman to enforce bilingualism. It should be the responsibility of the proposer of a new entity to supply suitable descriptions, as it already is. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 01:43:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05775; Tue, 12 Apr 2005 01:43:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLEKv-0004uV-78; Tue, 12 Apr 2005 01:53:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLEAC-0001K1-2K; Tue, 12 Apr 2005 01:42:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLEA9-0001Ex-UE for ltru@megatron.ietf.org; Tue, 12 Apr 2005 01:42:15 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05710 for ; Tue, 12 Apr 2005 01:42:07 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050412054137.JHIU4618.mta13.adelphia.net@DEWELL> for ; Tue, 12 Apr 2005 01:41:37 -0400 Message-ID: <011401c53f22$42eea060$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050411231209.FWJN2132.mta5.adelphia.net@megatron.ietf.org> Date: Mon, 11 Apr 2005 22:41:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Great Script Debate Part II: Formats... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Debbie Garside wrote: > When I look at your draft it says Lang = 2*3 Alpha... -6 is CURRENTLY > alpha4. Have I missed something? The last I heard was that -6 (if it > becomes standard) would have a singleton placed in front of it and be > treated as a variant... has this changed? Perhaps you could clarify > exactly how you would deal with -6 in its present form - which > includes language families, groups, languages, dialects, written, > spoken and signed. A variant wouldn't have a singleton placed in front of it. You're probably thinking of an extension. It's hard for any of us who have never seen the proposed 639-6 to imagine how it would be used in language tags. Addison Phillips wrote: > Please note that the ABNF for lang is actually: > > lang = 2*3ALPHA ; shortest ISO 639 code > / registered-lang > registered-lang = 4*8ALPHA ; registered language subtag > > Which means that language subtags in the registry can be 2 to 8 > characters long. Full stop. So the answer to your question, Debbie, is > "yes, I can foresee possibly including alpha4 subtags from whatever > source in the future." If ISO 639-6 were to be considered by some > future iteration of this WG to be useful in language tags, then its > codes can be placed in the registry making them valid for use. The > rules in 3066bis make it exceedingly unlikely that very many, if any, > alpha4 registered values will be there to get in the way. If there is any thought whatsoever that Linguasphere codes, or any other alpha-4 codes, will be allowed as primary language subtags, then we should drop everything RIGHT NOW and restrict the syntax of registered-lang subtags to 5 to 8 letters, instead of 4 to 8. Four-letter primary subtags should be marked "reserved for future expansion" or some such. Then, if the decision is made to allow Linguasphere codes, the syntax can be easily expanded to allow them. This is much better than crossing our fingers and hoping that a 4-letter language code never gets registered. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 02:11:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19588; Tue, 12 Apr 2005 02:11:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLEmU-0005eI-F0; Tue, 12 Apr 2005 02:21:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLEZg-000536-ES; Tue, 12 Apr 2005 02:08:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLEZe-00051B-QI for ltru@megatron.ietf.org; Tue, 12 Apr 2005 02:08:34 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16027 for ; Tue, 12 Apr 2005 02:08:17 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050412060747.LRAL5402.mta11.adelphia.net@DEWELL> for ; Tue, 12 Apr 2005 02:07:47 -0400 Message-ID: <012501c53f25$de3e6ca0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050411124409.TWX2135.mta2.adelphia.net@megatron.ietf.org> Date: Mon, 11 Apr 2005 23:07:10 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Is there a consensus ? (was: Comment: use VU for Vanuatu) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > I thank you for this loyal and clear response, where you show that a > tag could mean something totally different from what it would mean if > it was currently built according to the current ISO standard, and that > you fully support to such a proposition. I did not considered the > conflicts or confusion in IANA registration during the ISO standard > evolution, but I suppose your response would be the same. Hmm, I'd better not answer this directly. Instead, I'll recast it in my own words, and then respond to that. The charter says, "For stability, it is expected that the document will describe how the meaning of language tags remains stable, even if underlying references should change, and how the structure is to remain stable in the future." I think it is reasonable to conclude from this that at some point in the future, there may be subtags that do not have the same meaning as the corresponding code element in the related ISO standard. It has been stated that ISO 639 and ISO 15924 have policies against reassigning code elements, and we know that the proposed revision of ISO 3166-1 recommends that code elements not be reused for at least 50 years, not 5 as the current version allows. Still, it is possible for the RAs and MAs to change or break these policies, and the draft ensures that even if this happens, the subtags derived from the reassigned code elements will not change. I fully support the proposition that I have described in the two paragraphs above. In my opinion, the potential conflicts and confusion of this approach will be less than if subtags are allowed to change in meaning as a result of changes in ISO standards. > Since you are one of the most competent, active and acknowledged > members of this Working Group, I am interested to know if - me apart - > this is the consensus of this Working Group? Determining consensus is the responsibility of the WG chairs, and so I cannot comment on that. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 04:04:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05491; Tue, 12 Apr 2005 04:04:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLGXV-0008RJ-CN; Tue, 12 Apr 2005 04:14:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGL5-0000iT-Tn; Tue, 12 Apr 2005 04:01:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGL3-0000ga-RG for ltru@megatron.ietf.org; Tue, 12 Apr 2005 04:01:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05284 for ; Tue, 12 Apr 2005 04:01:11 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLGUC-0008Ix-FI for ltru@ietf.org; Tue, 12 Apr 2005 04:11:05 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 12 Apr 2005 08:59:28 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 08:59:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: registry should copy non-English fields from ISOdocuments Date: Tue, 12 Apr 2005 08:59:26 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A32C@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: registry should copy non-English fields from ISOdocuments Thread-Index: AcU+BuEcw482n1DGQy6I2P7p0q7kOAAtgDIQAB4cXeA= From: "L.Gillam" To: ltru X-OriginalArrivalTime: 12 Apr 2005 07:59:26.0738 (UTC) FILETIME=[8C2B1F20:01C53F35] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable > > > 3. A code (e.g. alpha3 in 639-3) stands as synonymous with the > reference > > > name and as entry point into the "conceptual" entry - the=20 > mantra is > > > "I don't care what you call it as long as we are referring to the > > > same thing" > >=20 > > The code points to the name, but the name does not always > unambiguously > > point to the language... >=20 > I think Lee's point is that the name used is intended to document the > conceptual entity in a way that ideally is unambiguous. I don't think > you two are actually disagreeing about anything; you're just=20 > struggling > over common words to describe a common understanding. Indeed, and clearly the use of good descriptions for such items in the=20 relevant documents is going to be paramount to try and develop common understanding for unknown readers. The "how many language names" = discussion shows differences in practice in the -1/-2/-3 documents - I will address this in a later mail. > > > ensuring -4 has necessary and sufficient coverage. > >=20 > > >From what I understand (I have not seen a draft), -4 will be > conceptual > > and introductory (-0, in other words, if ISO rules permitted a -0 > part) > > and will not provide coverage of anything. Has this changed? >=20 > If by "coverage" you mean "specify identifiers for some=20 > languages", your > assumption is correct: part 4 will not do this (and has not changed in > that regard). Ah, got the contextualisation now. Necessary and sufficient coverage of the principles. No new tags! ;-) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 04:19:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07433; Tue, 12 Apr 2005 04:19:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLGls-0000WD-CL; Tue, 12 Apr 2005 04:29:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGbx-000410-HX; Tue, 12 Apr 2005 04:19:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGbu-0003y9-AO for ltru@megatron.ietf.org; Tue, 12 Apr 2005 04:19:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07391 for ; Tue, 12 Apr 2005 04:18:51 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLGlJ-0000VQ-HJ for ltru@ietf.org; Tue, 12 Apr 2005 04:28:45 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 12 Apr 2005 09:16:22 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 09:16:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [psg.com #882] registry should copy non-English fields from ISO documents Date: Tue, 12 Apr 2005 09:16:22 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A332@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] [psg.com #882] registry should copy non-English fields from ISO documents Thread-Index: AcU+4xCDkBt67uPARXiodxshl6vXQAAVG1HQ From: "L.Gillam" To: ltru X-OriginalArrivalTime: 12 Apr 2005 08:16:22.0378 (UTC) FILETIME=[E9897CA0:01C53F37] X-Spam-Score: 1.0 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Does the summary below entail something along the lines of: /reference_name/ /names lang=3D"en"/ /names lang=3D"fr"/ /reference_name/ filled if 639-3 /reference_name/ =3D pointer to first name in /names lang=3D"en"/ if = 639-1/2 /names lang=3D"en"/ filled if 639-1/2 /names lang=3D"fr"/ filled if 639-1/2 Peter, I'm assuming a 639-3 reference name to be unique (one name only). The above is also a reason I'm in favour of an XML registry also - the = proof of the registry becomes its application to itself! On the consensus side, I'm not bothered either way, as long as it's = clear - but I'd draw the line at filling fields that were not available in the = source documents. The devil, however, will be in the detail. > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Randy Presuhn > Sent: 11 April 2005 23:03 > To: ltru > Subject: Re: [Ltru] [psg.com #882] registry should copy non-English > fields from ISO documents >=20 >=20 > Hi - >=20 > > From: "Peter Constable" > > To: > > Sent: Monday, April 11, 2005 10:43 AM > > Subject: RE: [Ltru] Re: registry should copy non-English=20 > fields fromISOdocuments > ... > > I think Lee's point is that the name used is intended to=20 > document the > > conceptual entity in a way that ideally is unambiguous. I=20 > don't think > > you two are actually disagreeing about anything; you're=20 > just struggling > > over common words to describe a common understanding. > ... >=20 > Trying to sum up this thread: >=20 > 1) there is a reference name from the ISO documents. In=20 > some cases > this is the English name of the language, in others=20 > it's a transcription. > This is currently part of an entry in the registry,=20 > and no one is suggesting > that it be removed. >=20 > 2) in some cases the ISO documents also include a French name for > a language. This tracker item is on the question of=20 > whether this information, > when available, should also be included in the=20 > registry. It looks like there > is a slight preference among active participants in=20 > the WG to include this > information. (Those who want it appear to want it=20 > more than those who > oppose it don't want it.) >=20 > 3) In those cases where a French name for a language is=20 > available from the > ISO documents, the remaining question is whether it=20 > should be included > in the same field as the reference name, using some=20 > kind of delimiter, or > given a field of its own. Based on the technical=20 > arguments so far, I believe > the preference would be to use a separate field to=20 > hold the French name, > when available, for a language. >=20 > Note that this resolution would NOT entail translating=20 > entries for which French > translations are not already present in the ISO documents,=20 > nor would it require > a registrant to obtain a French name for a language, nor=20 > should it be in any way > understood as constraining the names displayed by=20 > implementations or used by > users. >=20 > Would this be an acceptable statement of rough consensus? >=20 > Randy, ltru co-chair >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 04:24:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07894; Tue, 12 Apr 2005 04:24:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLGqZ-0000iu-GI; Tue, 12 Apr 2005 04:34:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGdN-0004OM-Jl; Tue, 12 Apr 2005 04:20:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGdI-0004J4-Hm for ltru@megatron.ietf.org; Tue, 12 Apr 2005 04:20:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07569 for ; Tue, 12 Apr 2005 04:20:18 -0400 (EDT) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLGmh-0000Yz-Bh for ltru@ietf.org; Tue, 12 Apr 2005 04:30:12 -0400 Received: from smtp-los01.proxy.aol.com (smtp-los01.proxy.aol.com [195.93.24.40]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN6-7425b84b42db; Tue, 12 Apr 2005 04:20:04 -0500 Received: from DEBHOME (ACD86522.ipt.aol.com [172.216.101.34]) by smtp-los01.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3C8JpqF026024; Tue, 12 Apr 2005 04:19:52 -0400 Message-Id: <200504120819.j3C8JpqF026024@smtp-los01.proxy.aol.com> From: "Debbie Garside" To: "'John Cowan'" Subject: RE: [Ltru] Great Script Debate Part II: Formats... Date: Tue, 12 Apr 2005 09:20:19 +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.2900.2180 Thread-Index: AcU/CqWS60v0nzA+Rei+levLOki8FAALSb1g In-Reply-To: <20050412025235.GB25948@skunk.reutershealth.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.40 X-Spam-Score: 2.6 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Hi John In answer to your question... yes, -6 is currently being mapped to ISO 639 1; 2T/B;and the proposed 3 and 5 as well as 15924. Debbie > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] > Sent: 12 April 2005 03:53 > To: Debbie Garside > Cc: ltru@ietf.org > Subject: Re: [Ltru] Great Script Debate Part II: Formats... > > Debbie Garside scripsit: > > > At present, other than the information that I gave last year outlining > the > > system (which basically stands), it would not be a good idea for me to > > reveal too much (perhaps my ISO/BSI colleagues currently monitoring this > > list can help here... I don't know the ISO protocol on this). > > I think that the most important point for this list is: is there going > to be a normative mapping between -6 tags and -1/-2 tags, and if so, > will -3 and -5 tags be mapped when those parts are available? Or is > the basis for -6 irreconcilable (not in principle but in detail) with > the unified model of -1/-2/-3/-4/-5? > > -- > You let them out again, Old Man Willow! John Cowan > What you be a-thinking of? You should not be waking! > jcowan@reutershealth.com > Eat earth! Dig deep! Drink water! Go to sleep! > www.reutershealth.com > Bombadil is talking. > www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 04:30:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08425; Tue, 12 Apr 2005 04:30:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLGwi-0000v6-AU; Tue, 12 Apr 2005 04:40:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGmH-0006pf-Da; Tue, 12 Apr 2005 04:29:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGmF-0006og-0P for ltru@megatron.ietf.org; Tue, 12 Apr 2005 04:29:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08363 for ; Tue, 12 Apr 2005 04:29:32 -0400 (EDT) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLGve-0000rk-Ur for ltru@ietf.org; Tue, 12 Apr 2005 04:39:27 -0400 Received: from smtp-los01.proxy.aol.com (smtp-los01.proxy.aol.com [195.93.24.40]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN4-5425b86e133b; Tue, 12 Apr 2005 04:29:21 -0500 Received: from DEBHOME (ACD86522.ipt.aol.com [172.216.101.34]) by smtp-los01.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3C8THCo027508; Tue, 12 Apr 2005 04:29:17 -0400 Message-Id: <200504120829.j3C8THCo027508@smtp-los01.proxy.aol.com> From: "Debbie Garside" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: Great Script Debate Part II: Formats... Date: Tue, 12 Apr 2005 09:29:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU/Isn6BiSLBKGPQhCarLQsV3R4yQAFpQkw In-Reply-To: <011401c53f22$42eea060$030aa8c0@DEWELL> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.40 X-Spam-Score: 2.6 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > If there is any thought whatsoever that Linguasphere codes, or any other > alpha-4 codes, will be allowed as primary language subtags, then we > should drop everything RIGHT NOW and restrict the syntax of > registered-lang subtags to 5 to 8 letters, instead of 4 to 8. > Four-letter primary subtags should be marked "reserved for future > expansion" or some such. To be honest... I think this would be sensible. I cannot say for sure what will happen within ISO 639.. nobody can... but... the alpha4 codes have been "on the table" for 3 years and are still there. Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Doug Ewell > Sent: 12 April 2005 06:41 > To: LTRU Working Group > Subject: [Ltru] Re: Great Script Debate Part II: Formats... > > Debbie Garside wrote: > > > When I look at your draft it says Lang = 2*3 Alpha... -6 is CURRENTLY > > alpha4. Have I missed something? The last I heard was that -6 (if it > > becomes standard) would have a singleton placed in front of it and be > > treated as a variant... has this changed? Perhaps you could clarify > > exactly how you would deal with -6 in its present form - which > > includes language families, groups, languages, dialects, written, > > spoken and signed. > > A variant wouldn't have a singleton placed in front of it. You're > probably thinking of an extension. > > It's hard for any of us who have never seen the proposed 639-6 to > imagine how it would be used in language tags. > > > Addison Phillips wrote: > > > Please note that the ABNF for lang is actually: > > > > lang = 2*3ALPHA ; shortest ISO 639 code > > / registered-lang > > registered-lang = 4*8ALPHA ; registered language subtag > > > > Which means that language subtags in the registry can be 2 to 8 > > characters long. Full stop. So the answer to your question, Debbie, is > > "yes, I can foresee possibly including alpha4 subtags from whatever > > source in the future." If ISO 639-6 were to be considered by some > > future iteration of this WG to be useful in language tags, then its > > codes can be placed in the registry making them valid for use. The > > rules in 3066bis make it exceedingly unlikely that very many, if any, > > alpha4 registered values will be there to get in the way. > > If there is any thought whatsoever that Linguasphere codes, or any other > alpha-4 codes, will be allowed as primary language subtags, then we > should drop everything RIGHT NOW and restrict the syntax of > registered-lang subtags to 5 to 8 letters, instead of 4 to 8. > Four-letter primary subtags should be marked "reserved for future > expansion" or some such. Then, if the decision is made to allow > Linguasphere codes, the syntax can be easily expanded to allow them. > This is much better than crossing our fingers and hoping that a 4-letter > language code never gets registered. > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 04:36:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08838; Tue, 12 Apr 2005 04:36:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLH27-00016E-1c; Tue, 12 Apr 2005 04:46:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGrU-0007bK-MG; Tue, 12 Apr 2005 04:35:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGrS-0007Zn-FC for ltru@megatron.ietf.org; Tue, 12 Apr 2005 04:35:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08726 for ; Tue, 12 Apr 2005 04:34:59 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLH0u-00012K-B9 for ltru@ietf.org; Tue, 12 Apr 2005 04:44:53 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 12 Apr 2005 09:26:25 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 09:26:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [psg.com #882] registry should copy non-English fieldsfrom ISO documents Date: Tue, 12 Apr 2005 09:26:24 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A334@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] [psg.com #882] registry should copy non-English fieldsfrom ISO documents Thread-Index: AcU++/zHVgTc+SkeSTiSeqOGCPH15AAPZt9A From: "L.Gillam" To: ltru X-OriginalArrivalTime: 12 Apr 2005 08:26:24.0230 (UTC) FILETIME=[5044D060:01C53F39] X-Spam-Score: 1.0 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Who's going to pay for all these items to be translated into the variety of languages?=20 Who is going to maintain all the servers, code lists and so=20 forth, and deal with all those hits?=20 Your opposition simply is not scalable - you're insisting on developing nations with small finances making budgetary decisions that may not be in their best interests. I think you have to "eat your own dog food" here - you can't=20 hunt with the hounds and run with the foxes (especially not=20 in the UK any more).=20 > I am sorry, I can only repeat this a definitive blocking=20 > opposition for me.=20 > For the reasons I gave several times. However once the=20 > principle of dual=20 > language (at least) naming necessity is established,=20 > practical arrangements=20 > can be quite flexible. >=20 > 1. if an Englist or French (or other languages to be added)=20 > name for a=20 > language is missing, it will be accepted as non fully=20 > documented until a=20 > name is provided (a IANA procedure and Reviewer will have to=20 > be designated). > 2. the same IANA registration could only be entered in=20 > English or French.=20 > It will be up to the French/English Reviewer to make sure the=20 > name in the=20 > missing language(s) is provided. >=20 > jfc >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 04:41:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09139; Tue, 12 Apr 2005 04:41:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLH7K-0001Dt-3N; Tue, 12 Apr 2005 04:51:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGtY-0007pq-F4; Tue, 12 Apr 2005 04:37:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGtW-0007p2-NQ for ltru@megatron.ietf.org; Tue, 12 Apr 2005 04:37:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08901 for ; Tue, 12 Apr 2005 04:37:04 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLH2v-00017K-LI for ltru@ietf.org; Tue, 12 Apr 2005 04:46:59 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 12 Apr 2005 09:28:13 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 09:28:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [psg.com #882] registry should copy non-English fields from ISO documents Date: Tue, 12 Apr 2005 09:28:12 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A335@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] [psg.com #882] registry should copy non-English fields from ISO documents Thread-Index: AcU/BoFwL1wp9ojdTEmdLeFU/5kOogAM/esA From: "L.Gillam" To: ltru X-OriginalArrivalTime: 12 Apr 2005 08:28:12.0260 (UTC) FILETIME=[90A8E240:01C53F39] X-Spam-Score: 1.0 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable +1 > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of John Cowan > Sent: 12 April 2005 03:21 > To: Randy Presuhn > Cc: ltru@ietf.org > Subject: Re: [Ltru] [psg.com #882] registry should copy non-English > fields from ISO documents >=20 >=20 > Randy Presuhn scripsit: >=20 > > Of those who support copying available French names (and=20 > transcriptions) > > for the names of languages, would you be willing to support Jefsey's > > provisos? >=20 > No, indeed. Most 639-3 names don't have French versions, and because > standard written French is a vocabulary-controlled language (unlike > standard written English) there is no reasonable prospect of getting > such standard names. >=20 > --=20 > Unless it was by accident that I had John Cowan > offended someone, I never apologized. =20 > jcowan@reutershealth.com > --Quentin Crisp =20 > http://www.ccil.org/~cowan >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 05:38:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13143; Tue, 12 Apr 2005 05:38:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLI03-0002o4-Ns; Tue, 12 Apr 2005 05:48:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLHpA-00088m-2e; Tue, 12 Apr 2005 05:36:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLHp7-00087I-GM for ltru@megatron.ietf.org; Tue, 12 Apr 2005 05:36:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12964 for ; Tue, 12 Apr 2005 05:36:34 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLHyX-0002ll-Rb for ltru@ietf.org; Tue, 12 Apr 2005 05:46:30 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 12 Apr 2005 10:23:14 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 10:23:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Great Script Debate Part II: Formats... Date: Tue, 12 Apr 2005 10:23:01 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A338@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Great Script Debate Part II: Formats... Thread-Index: AcU/CuVgynR2jWyEQM6aBILe1uHKKwAMNCgg From: "L.Gillam" To: ltru X-OriginalArrivalTime: 12 Apr 2005 09:23:01.0864 (UTC) FILETIME=[396A9E80:01C53F41] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable There are two things that apply here - harmonisation and data fusion. The definitions of these two are varied, so in this instance harmonisation can refer to determining the general principles between these various systems (-4) which can provide for data fusion, described in a certain quarter recently as merging datasets based on common = values. The upper layers of the Linguasphere and what is proposed for 639-5 are, based on a small sample, highly interoperable. "gaps" such as there may be can be reconciled because of construction based on slightly differing characteristics, and where characteristics do differ needs to be = documented. Whether this is a -4 or -6 task, at an abstract level, is open for = discussion. -3 and -5 provide a means for disambiguating -1/-2 as I perceive them. = -6,=20 then, maps to the upper layers provided in this quadruple and provides=20 its most specific contribution at levels of variety in = written/spoken/signed=20 and subcomponents thereof. I would consider that these systems provide validation for each other and in combination are a very good basis for informed theoretical discussion and practical application. Perhaps I'm slightly biased! Of course, this doesn't answer the "show us" requirement, and we do need to pull everything together fairly soon. Perhaps we should be posting to this list a bit less frequently! > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of John Cowan > Sent: 12 April 2005 03:53 > To: Debbie Garside > Cc: ltru@ietf.org > Subject: Re: [Ltru] Great Script Debate Part II: Formats... >=20 >=20 > Debbie Garside scripsit: >=20 > > At present, other than the information that I gave last=20 > year outlining the > > system (which basically stands), it would not be a good=20 > idea for me to > > reveal too much (perhaps my ISO/BSI colleagues currently=20 > monitoring this > > list can help here... I don't know the ISO protocol on this). =20 >=20 > I think that the most important point for this list is: is there going > to be a normative mapping between -6 tags and -1/-2 tags, and if so, > will -3 and -5 tags be mapped when those parts are available? Or is > the basis for -6 irreconcilable (not in principle but in detail) with > the unified model of -1/-2/-3/-4/-5? >=20 > --=20 > You let them out again, Old Man Willow! John Cowan > What you be a-thinking of? You should not be waking! =20 > jcowan@reutershealth.com > Eat earth! Dig deep! Drink water! Go to sleep! =20 > www.reutershealth.com > Bombadil is talking. =20 > www.ccil.org/~cowan >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 09:09:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27646; Tue, 12 Apr 2005 09:09:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLLIp-0000D8-Qk; Tue, 12 Apr 2005 09:19:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLL6K-0006O7-LI; Tue, 12 Apr 2005 09:06:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLL6J-0006Ms-FE for ltru@megatron.ietf.org; Tue, 12 Apr 2005 09:06:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27457 for ; Tue, 12 Apr 2005 09:06:33 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLLFk-00008J-M5 for ltru@ietf.org; Tue, 12 Apr 2005 09:16:30 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3CD6N0v023886; Tue, 12 Apr 2005 09:06:23 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 12 Apr 2005 09:06:34 -0400 Date: Tue, 12 Apr 2005 09:06:33 -0400 From: John Cowan To: Debbie Garside Subject: Re: [Ltru] Re: Great Script Debate Part II: Formats... Message-ID: <20050412130633.GA30675@skunk.reutershealth.com> References: <011401c53f22$42eea060$030aa8c0@DEWELL> <200504120829.j3C8THCo027508@smtp-los01.proxy.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504120829.j3C8THCo027508@smtp-los01.proxy.aol.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Debbie Garside scripsit: > > If there is any thought whatsoever that Linguasphere codes, or any other > > alpha-4 codes, will be allowed as primary language subtags, then we > > should drop everything RIGHT NOW and restrict the syntax of > > registered-lang subtags to 5 to 8 letters, instead of 4 to 8. > > Four-letter primary subtags should be marked "reserved for future > > expansion" or some such. > > To be honest... I think this would be sensible. I cannot say for sure what > will happen within ISO 639.. nobody can... but... the alpha4 codes have been > "on the table" for 3 years and are still there. I think this is a worthwhile thing to do. We currently have no registered (that is, non-ISO) language subtags, and there is no reason not to restrict them to 5*8ALPHA. -- My confusion is rapidly waxing John Cowan For XML Schema's too taxing: jcowan@reutershealth.com I'd use DTDs http://www.reutershealth.com If they had local trees -- http://www.ccil.org/~cowan I think I best switch to RELAX NG. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 09:41:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29314; Tue, 12 Apr 2005 09:41:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLLnY-0000y5-7r; Tue, 12 Apr 2005 09:51:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLLbA-0002aH-Fx; Tue, 12 Apr 2005 09:38:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLLb8-0002ZK-QO for ltru@megatron.ietf.org; Tue, 12 Apr 2005 09:38:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29105 for ; Tue, 12 Apr 2005 09:38:24 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLLka-0000ss-Eo for ltru@ietf.org; Tue, 12 Apr 2005 09:48:21 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3CDcFAO023987; Tue, 12 Apr 2005 09:38:15 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 12 Apr 2005 09:38:27 -0400 Date: Tue, 12 Apr 2005 09:38:27 -0400 From: John Cowan To: Debbie Garside Subject: Re: [Ltru] Great Script Debate Part II: Formats... Message-ID: <20050412133826.GB30675@skunk.reutershealth.com> References: <20050412025235.GB25948@skunk.reutershealth.com> <200504120819.j3C8JpqF026024@smtp-los01.proxy.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504120819.j3C8JpqF026024@smtp-los01.proxy.aol.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Debbie Garside scripsit: > In answer to your question... yes, -6 is currently being mapped to ISO 639 > 1; 2T/B;and the proposed 3 and 5 as well as 15924. Excellent. It's a design point of the RFC 3066 system that no two tags have the same denotation (except where forced on us by ISO 3166), so if we decide to include 639-6 tags, we would want to bar those which are equivalent to existing -1, -2, or -3 tags (just as, e.g. we bar "eng" from 639-2 in favor of "en" from 639-1). Another question: Is it the intention of the future 639-6/RA to maintain a strict hierarchy moving forward? Or would it be in order, for example, to request a code for "Balkan Sprachbund languages" (roughly, Bulgarian, Romanian, Serbian, and Greek) even though that cuts across the standard genetic grouping for Indo-European? If that can be done, what about a code for "languages spoken in Nigeria" (mostly Benue-Congo languages, but also other Niger-Congo languages as well as Chadic from Afroasiatic plus English and Shuwa Arabic)? This question is also relevant to ISO 639-5, though not directly to RFC 3066-style language tags. -- Do I contradict myself? John Cowan Very well then, I contradict myself. jcowan@reutershealth.com I am large, I contain multitudes. http://www.ccil.org/~cowan --Walt Whitman, Leaves of Grass http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 10:12:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02520; Tue, 12 Apr 2005 10:12:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLMHk-0001rB-Q1; Tue, 12 Apr 2005 10:22:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLM7W-0007Jl-2z; Tue, 12 Apr 2005 10:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLM7U-0007IT-Jp for ltru@megatron.ietf.org; Tue, 12 Apr 2005 10:12:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02346 for ; Tue, 12 Apr 2005 10:11:50 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLMGw-0001of-Ik for ltru@ietf.org; Tue, 12 Apr 2005 10:21:47 -0400 Received: from lns-p19-8-idf-82-249-21-108.adsl.proxad.net ([82.249.21.108] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLM7H-00006w-Ad for ltru@ietf.org; Tue, 12 Apr 2005 07:11:47 -0700 Message-Id: <6.1.2.0.2.20050412154024.06d1ceb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 15:48:21 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Is there a consensus ? (was: Comment: use VU for Vanuatu) In-Reply-To: <012501c53f25$de3e6ca0$030aa8c0@DEWELL> References: <20050411124409.TWX2135.mta2.adelphia.net@megatron.ietf.org> <012501c53f25$de3e6ca0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab On 08:07 12/04/2005, Doug Ewell said: >I fully support the proposition that I have described in the two >paragraphs above. I am not sure you described any position. You just quoted the Charter and started asking yourself some questions ? you say "In my opinion, the potential conflicts and confusion of this approach will be less than if subtags are allowed to change in meaning as a result of changes in ISO standards.". Why not to consider that people/users/real languages come before both subtags _and_ standards. And are more stable and real than their descriptions? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 10:15:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02896; Tue, 12 Apr 2005 10:15:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLMKe-0001wI-6u; Tue, 12 Apr 2005 10:25:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLM7V-0007JX-ST; Tue, 12 Apr 2005 10:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLM7T-0007IS-Tp for ltru@megatron.ietf.org; Tue, 12 Apr 2005 10:12:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02341 for ; Tue, 12 Apr 2005 10:11:49 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLMGw-0001od-Io for ltru@ietf.org; Tue, 12 Apr 2005 10:21:46 -0400 Received: from lns-p19-8-idf-82-249-21-108.adsl.proxad.net ([82.249.21.108] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLM7E-00006w-To for ltru@ietf.org; Tue, 12 Apr 2005 07:11:45 -0700 Message-Id: <6.1.2.0.2.20050412132811.063ba010@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 16:11:25 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Great Script Debate Part II: Formats... In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A338@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A21292A338@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Thank you for this synthesis. On 11:23 12/04/2005, L.Gillam said: >I would consider that these systems provide validation for each other and >in combination are a very good basis for informed theoretical discussion >and practical application. Perhaps I'm slightly biased! No. But remember that "these systems" only "provide validations for each other". And that only users provide validation for all of them. >Of course, this doesn't answer the "show us" requirement, and we do need >to pull everything together fairly soon. Perhaps we should be posting to >this list a bit less frequently! This list is highly educative of what usage has to address in this area. Here as every where else the transition from centralised to distributed formulas, from dominance, to governance to intergovernance. A very general and common situation. On 10:26 12/04/2005, L.Gillam said: >Who's going to pay for all these items to be translated into the variety >of languages? Who is going to maintain all the servers, code lists and so >forth, and deal with all those hits? This is strange enough. One of my main motivation is that we (Internet Community) have _not_ the money for the considered IANA system - unless losing sovereignty, control, surety of usage for our own communities. I consider from 27 years daily experience in this area that the project does not operationnaly stand.. Covering the costs, developping the generic solutions, co-maintaining the data is precisely the target. How do you think INTL files are daily maintained? Because solutions and costs are to be trimmed from the very first idea of a system. What is not the case here. Yet. There is a huge difference between discussing a table and managing a reference source, efficiently, at low cost, motivating partners months over years. >Your opposition simply is not scalable - you're insisting on developing >nations with small finances making budgetary decisions that may not be in >their best interests. I have some difficulty in understanding this. You are precisely using my arguments and my position to oppose me. This is quite interesting. My point is to permit. Permit do not impose. Your point seems to forbid. Forbidding imposes. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 11:09:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06960; Tue, 12 Apr 2005 11:09:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLNAm-0003WZ-NP; Tue, 12 Apr 2005 11:19:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLMyy-00081b-G5; Tue, 12 Apr 2005 11:07:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLMyw-0007xt-BG for ltru@megatron.ietf.org; Tue, 12 Apr 2005 11:07:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06839 for ; Tue, 12 Apr 2005 11:06:58 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLN8K-0003S0-9k for ltru@ietf.org; Tue, 12 Apr 2005 11:16:56 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 08:06:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] ISO 639-6 (was: Great Script Debate Part II: Formats...) Date: Tue, 12 Apr 2005 08:06:40 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA4230@irvmbxw01.quest.com> Thread-Topic: [Ltru] ISO 639-6 (was: Great Script Debate Part II: Formats...) Thread-Index: AcU/CuVgynR2jWyEQM6aBILe1uHKKwAMNCggAA0ls4A= From: "Addison Phillips" To: "ltru" X-OriginalArrivalTime: 12 Apr 2005 15:06:40.0973 (UTC) FILETIME=[3B5CF7D0:01C53F71] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: quoted-printable I don't think we need to do anything positive or negative about ISO = 639-6 currently. The current draft doesn't prevent adoption of it, if it = were to become a standard and be useful in language tags. Let's let = Debbie/et al do their work and evaluate the results. Note that this is = the same thing we are doing for ISO 639-3. If people feel super strongly = about this, then let's change the ABNF in the draft to: lang =3D 2*8ALPHA ; primary language subtags This leaves, as I see it, just a few remaining issues in the draft: 1. Location and handling of scripts. 2. Inclusion (or not) of French descriptions. 3. Handling of deprecation and canonical mapping in regions. If we could focus on reaching consensus on those, we could at least put = out a fresh draft -01. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of L.Gillam > Sent: mardi 12 avril 2005 02:23 > To: ltru > Subject: RE: [Ltru] Great Script Debate Part II: Formats... >=20 >=20 > There are two things that apply here - harmonisation and data fusion. > The definitions of these two are varied, so in this instance > harmonisation can refer to determining the general principles between > these various systems (-4) which can provide for data fusion, = described > in a certain quarter recently as merging datasets based on common = values. > The upper layers of the Linguasphere and what is proposed for 639-5 = are, > based on a small sample, highly interoperable. "gaps" such as there = may > be can be reconciled because of construction based on slightly = differing > characteristics, and where characteristics do differ needs to be > documented. > Whether this is a -4 or -6 task, at an abstract level, is open for > discussion. > -3 and -5 provide a means for disambiguating -1/-2 as I perceive them. = -6, > then, maps to the upper layers provided in this quadruple and provides > its most specific contribution at levels of variety in > written/spoken/signed > and subcomponents thereof. I would consider that these systems provide > validation for each other and in combination are a very good basis > for informed theoretical discussion and practical application. Perhaps > I'm slightly biased! >=20 > Of course, this doesn't answer the "show us" requirement, and we do = need > to pull everything together fairly soon. Perhaps we should be posting > to this list a bit less frequently! >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of John Cowan > > Sent: 12 April 2005 03:53 > > To: Debbie Garside > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Great Script Debate Part II: Formats... > > > > > > Debbie Garside scripsit: > > > > > At present, other than the information that I gave last > > year outlining the > > > system (which basically stands), it would not be a good > > idea for me to > > > reveal too much (perhaps my ISO/BSI colleagues currently > > monitoring this > > > list can help here... I don't know the ISO protocol on this). > > > > I think that the most important point for this list is: is there = going > > to be a normative mapping between -6 tags and -1/-2 tags, and if so, > > will -3 and -5 tags be mapped when those parts are available? Or is > > the basis for -6 irreconcilable (not in principle but in detail) = with > > the unified model of -1/-2/-3/-4/-5? > > > > -- > > You let them out again, Old Man Willow! John Cowan > > What you be a-thinking of? You should not be waking! > > jcowan@reutershealth.com > > Eat earth! Dig deep! Drink water! Go to sleep! > > www.reutershealth.com > > Bombadil is talking. > > www.ccil.org/~cowan > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 11:18:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07637; Tue, 12 Apr 2005 11:18:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLNJR-0003mV-6o; Tue, 12 Apr 2005 11:28:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLN6B-0000dP-Es; Tue, 12 Apr 2005 11:14:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLN6A-0000cd-HH for ltru@megatron.ietf.org; Tue, 12 Apr 2005 11:14:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07399 for ; Tue, 12 Apr 2005 11:14:31 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLNFc-0003eU-Um for ltru@ietf.org; Tue, 12 Apr 2005 11:24:30 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 12 Apr 2005 15:50:58 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 15:50:57 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Great Script Debate Part II: Formats... Date: Tue, 12 Apr 2005 15:50:57 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A362@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Great Script Debate Part II: Formats... Thread-Index: AcU/a3HytobN69FmQy23yC2HYdBX3QAAWFjw From: "L.Gillam" To: ltru X-OriginalArrivalTime: 12 Apr 2005 14:50:57.0569 (UTC) FILETIME=[090CF110:01C53F6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > > JFC (Jefsey) Morfin > 12 April 2005 15:11 > No. But remember that "these systems" only "provide=20 > validations for each=20 > other". And that only users provide validation for all of them. You dismiss the extensive linguistic research that has gone into their creation and maintenance. I would consider that quite offensive to all involved. > This list is highly educative of what usage has to address in=20 > this area.=20 > Here as every where else the transition from centralised to=20 > distributed=20 > formulas, from dominance, to governance to intergovernance. A=20 > very general=20 > and common situation. Unintelligible and, likely, irrelevant. [snip irrelevant text] > >Your opposition simply is not scalable - you're insisting on=20 > developing=20 > >nations with small finances making budgetary decisions that=20 > may not be in=20 > >their best interests. >=20 > I have some difficulty in understanding this. You are=20 > precisely using my=20 > arguments and my position to oppose me. This is quite=20 > interesting. My point=20 > is to permit. Permit do not impose. Your point seems to=20 > forbid. Forbidding=20 > imposes. You contradicted yourself, I merely validated your contradiction using your own argumentation.=20 Where did I make something forbidden Jefsey? On the contrary, I think you'll find I say there are certain things we should=20 not impose (just above here for example). Quite the reverse.=20 Please do not twist what I, or indeed others, write in an attempt=20 to validate your position. There's a "forbid" if you want one. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 11:45:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09375; Tue, 12 Apr 2005 11:45:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLNjX-0004Wc-8a; Tue, 12 Apr 2005 11:55:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLNYa-0004ol-TF; Tue, 12 Apr 2005 11:44:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLNYZ-0004n6-EN for ltru@megatron.ietf.org; Tue, 12 Apr 2005 11:44:03 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09335 for ; Tue, 12 Apr 2005 11:43:44 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050412154312.BOHO7277.mta10.adelphia.net@DEWELL> for ; Tue, 12 Apr 2005 11:43:12 -0400 Message-ID: <016b01c53f76$308d8900$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050411231209.FWJN2132.mta5.adelphia.net@megatron.ietf.org> Date: Tue, 12 Apr 2005 08:42:09 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Great Script Debate Part II: Formats... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Debbie Garside wrote: > Just MHO... but what happens if 4 years down the line it isn't > "forever" and some, as yet unseen, circumstance arises that means the > whole system needs changing... who knows... but I do accept your > point. I am looking at those industries that are going to use this > RFC's rules to tag content for archive purposes... archives that may > not be touched for 10 years. I hope you are right :-) Then again, the Earth could collapse into the Sun tomorrow. :-) There's only so much we can do about the absolutely unforeseen. We're having enough controversy over making changes to defend against *known* instabilities. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 12:25:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12107; Tue, 12 Apr 2005 12:25:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOMk-0005iy-3M; Tue, 12 Apr 2005 12:35:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLO0Z-0000Xv-JO; Tue, 12 Apr 2005 12:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLO0Y-0000Ve-FP for ltru@megatron.ietf.org; Tue, 12 Apr 2005 12:12:58 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11296 for ; Tue, 12 Apr 2005 12:12:21 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLNwV-0004I5-KB for ltru@lists.ietf.org; Tue, 12 Apr 2005 18:08:47 +0200 Received: from c-134-92-247.hh.dial.de.ignite.net ([62.134.92.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 18:08:47 +0200 Received: from nobody by c-134-92-247.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 18:08:47 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 12 Apr 2005 18:05:58 +0200 Organization: Lines: 55 Message-ID: <425BF1E6.2130@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AFA4230@irvmbxw01.quest.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: c-134-92-247.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: ISO 639-6 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Addison Phillips wrote: > lang = 2*8ALPHA ; primary language subtags At the moment it's: lang = 2*3ALPHA ; shortest ISO 639 code / registered-lang registered-lang = 4*8ALPHA ; registered language subtag If the idea is to reserve alpha-4 for ISO 639-6, how about: lang = 2*4ALPHA ; shortest ISO 639 code / registered-lang registered-lang = 5*8ALPHA ; registered language subtag Your text says about registered-lang tags (none at the moment): | MAY be used to form the primary language subtag [...] | future registrations of this type will be discouraged: | primary languages are STRONGLY RECOMMENDED for registration | with ISO 639 and subtags rejected by ISO 639 will be closely | scrutinized before they are registered with IANA. In other words NOT RECOMMENDED, please use lower case instead of STRONGLY, screaming doesn't help with RfC 2119. Why do we need registered-lang at all ? The old i-whatever was good enough for this purpose. You would get a much simpler ABNF, and the old i-whatever system is automagically discouraging. Just say (modulo "shortest" if necessary for ISO 639-6): lang = 2*4ALPHA ; shortest ISO 639 code Remove registered-lang everywhere. Then fix the registration procedures to allow new IANA i-whatever tags. For the ABNF that means: 1 - insert "individual" between "private-use / gradfathered" 2 - lang = 2*4ALPHA, remove "registered-lang" in "lang" 3 - remove registered-lang 4 - replace 1*3ALPHA in "grandfathered" by 2*3ALPHA, strip the singleton i- comment from "grandfathered" 5 - add a new "individual" before "grandfathered": individual = "i" 1*2("-" (2*8alphanum)) In the procedures replace "registered-lang" by "individual", mention that an "individual" tag is deprecated when a proper ISO 639 tag is introduced. The tag reviewer has accepted several obscure tags for fantasy Macao-languages, it's time to stop this nonsense in 3066bis. The old i-whatever was better for dubious tags. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 12:31:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12644; Tue, 12 Apr 2005 12:31:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOSN-0005vW-G9; Tue, 12 Apr 2005 12:41:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLNtF-0008Pp-Bd; Tue, 12 Apr 2005 12:05:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLNtD-0008PI-Tk for ltru@megatron.ietf.org; Tue, 12 Apr 2005 12:05:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10623 for ; Tue, 12 Apr 2005 12:05:13 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLO2g-00054F-Uu for ltru@ietf.org; Tue, 12 Apr 2005 12:15:12 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3CG54nH024611; Tue, 12 Apr 2005 12:05:05 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 12 Apr 2005 12:05:11 -0400 Date: Tue, 12 Apr 2005 12:05:10 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] ISO 639-6 (was: Great Script Debate Part II: Formats...) Message-ID: <20050412160510.GC23496@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0AFA4230@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AFA4230@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Addison Phillips scripsit: > I don't think we need to do anything positive or negative about ISO > 639-6 currently. The current draft doesn't prevent adoption of it, > if it were to become a standard and be useful in language tags. Let's > let Debbie/et al do their work and evaluate the results. Note that > this is the same thing we are doing for ISO 639-3. If people feel > super strongly about this, then let's change the ABNF in the draft to: I just want to make sure that there is no collision between a registered subtag and an ISO 639-6 code. The simplest way to achieve this is to require that registered language subtags have at least 5 characters. > lang = 2*8ALPHA ; primary language subtags We could do that and then add a prose requirement that no language subtag less than 5 characters in length can be registered. -- Well, I have news for our current leaders John Cowan and the leaders of tomorrow: the Bill of jcowan@reutershealth.com Rights is not a frivolous luxury, in force http://www.ccil.org/~cowan only during times of peace and prosperity. http://www.reutershealth.com We don't just push it to the side when the going gets tough. --Molly Ivins _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 12:33:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12831; Tue, 12 Apr 2005 12:33:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOTa-0005zG-9O; Tue, 12 Apr 2005 12:42:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOH4-00021L-OJ; Tue, 12 Apr 2005 12:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOH2-0001zg-NM for ltru@megatron.ietf.org; Tue, 12 Apr 2005 12:30:01 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08856 for ; Tue, 12 Apr 2005 11:35:36 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050412153508.BCNO7277.mta10.adelphia.net@DEWELL> for ; Tue, 12 Apr 2005 11:35:08 -0400 Message-ID: <016001c53f75$111c0660$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050411210103.JNLD2135.mta4.adelphia.net@megatron.ietf.org> Date: Tue, 12 Apr 2005 08:34:06 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Compatibility with existing use (LDAP) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > True, but these are distinctions that have been causing us grief. > For example, "Microsoft are on their best behaviour" shows en-GB > language (the use of "are" and "their" for a collective noun, which > would be ungrammatical in en-US) and en-GB orthography (the > spelling of "behaviour" rather than "behavior"), all in Latin script. My favorite example was in a TV recap of an English soccer game: "But on forty-three minutes, United were level." I tried to count the number of differences in this short en-GB example from how an en-US speaker would say it, and ended up with five. The sports world often supplies jargon that is highly region-specific. Phillips flew out to Orange County, but Bonds flied out to left field. And no, I don't propose tagging to differentiate these. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 12:36:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13042; Tue, 12 Apr 2005 12:36:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOWg-00064n-41; Tue, 12 Apr 2005 12:46:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOIH-0002AF-Ja; Tue, 12 Apr 2005 12:31:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOIG-00028s-Ey for ltru@megatron.ietf.org; Tue, 12 Apr 2005 12:31:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12592 for ; Tue, 12 Apr 2005 12:31:05 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLORj-0005uD-JH for ltru@ietf.org; Tue, 12 Apr 2005 12:41:04 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3CGUvNW024700 for ; Tue, 12 Apr 2005 12:30:57 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 12 Apr 2005 12:30:57 -0400 Date: Tue, 12 Apr 2005 12:30:57 -0400 From: John Cowan To: ltru@ietf.org Message-ID: <20050412163056.GE23496@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [Ltru] M. Morfin's attempt to undermine me with my employer X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 I apologize for the off-topic nature of this post, but I feel I must take this action to defend myself. Reuters, my employer, received the following message today through our electronic customer help system. It was forwarded to me for disposition, although it was addressed to "Mr. Chairman". > E-mail: info@afrac.org > First Name: Legal Affairs > Last Name: AFRAC > E-Mail Address: info@afrac.org > Address: > City/Town: Versailles > Postal Code/Zip: > Country: France > Company: AFRAC > State: > > Mr. Chairman, > we wish to know if Mr. John Cowan, who uses the e-mail address > jcowan@reutershealth.com, belongs to the Reuters organization. If this > is the case we desire to know if his participation to the IETF (Internet > Engineering Task Force) is part of his Reuters assignments. If this was > the case, if his attitude there results from a Reuters policy. The answers are yes, no, and no respectively. My supervisor and other Reuters employees are aware of my membership in this WG, but my participation in it is not an "assignment". As is well known, IETF members speak for themselves and not for their employers. > The reason why we need to know this is that Mr. John Cowan has formally > petitioned the Chair of the IETF WG-ltru to ban our VP R&D from this > Working Group. Due to our VP R&D kind attitude in response to Mr. Cowan's > periodic harassment and his technical, political, societal background > and thirty years of high level experience in international networking > this request is ... childish. > > However, this WG discusses what we consider the founding building blocks > of the multilingual internet, resulting in an innovation demanded by the > World Summit on the Information Society, some considerable commercial and > political interests want to contain or at least constrain. We therefore > fear that under the circumstances some could be tempted to take advantage > of the name of your group as a cover for an action against what we > consider the general interest we strive to support. This could only > result in a public reaction from us against your supposed strategy which > would be detrimental to all, as we believe that - as an international > information group - we fully share the same values and will be among > the first to technically benefit from our action (we are in relation > with other press agencies technical departments and cooperated in the > past with information services now amalgamated in your organization). > > If your intent is not figth us and our efforts for the common good, > as we suppose, we could only suggest that Mr. John Cowan uses another > e-mail name, apologizes to his fellow members of his Working Group > for his attitude and continue his excellent contributions in a less > acrimonious way. Mr. Cowan declines to do anything of the sort, and believes his actions were fully justified. > This mail is sent in using your on-line [URL deleted] advised system. We > will contact tomorrow the Reuters legal department in Paris we will then > copy and ask an acknowledgment from. > > Sincerely yours. > > Legal Department > info@afrac.org > AFRAC > http://afrac.org > April 11th, 2005 WG members can draw their own conclusions about the actual author of this document. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 12:36:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13100; Tue, 12 Apr 2005 12:36:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOWs-00065X-VB; Tue, 12 Apr 2005 12:46:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOK4-0002Ml-1t; Tue, 12 Apr 2005 12:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOK1-0002MW-Rm for ltru@megatron.ietf.org; Tue, 12 Apr 2005 12:33:06 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12864 for ; Tue, 12 Apr 2005 12:33:02 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLOEv-0008CT-Ah for ltru@lists.ietf.org; Tue, 12 Apr 2005 18:27:49 +0200 Received: from c-134-92-247.hh.dial.de.ignite.net ([62.134.92.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 18:27:49 +0200 Received: from nobody by c-134-92-247.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 18:27:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 12 Apr 2005 18:27:07 +0200 Organization: Lines: 10 Message-ID: <425BF6DB.44B3@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-92-247.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] date B = 2005-01-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit After the intruduction of several nonsense MO-tags in the 3066 system I propose to use 2005-01-01 as "date B" and ignore all dubious 3066-tags introduced after 2005-01-01 (if they turn out to be "redundant" this point is moot). Further I want to express that I do not trust anybody involved in the registrations of MO-languages. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 12:43:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14038; Tue, 12 Apr 2005 12:43:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOdv-0006MZ-3y; Tue, 12 Apr 2005 12:53:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOSH-0003OZ-RA; Tue, 12 Apr 2005 12:41:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOSG-0003O8-K8 for ltru@megatron.ietf.org; Tue, 12 Apr 2005 12:41:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13563 for ; Tue, 12 Apr 2005 12:41:25 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLObj-0006EP-Re for ltru@ietf.org; Tue, 12 Apr 2005 12:51:25 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3CGfADx018754; Tue, 12 Apr 2005 09:41:10 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AG50Y>; Tue, 12 Apr 2005 09:41:11 -0700 Message-ID: From: "McDonald, Ira" To: "'John Cowan'" , Addison Phillips Subject: RE: [Ltru] ISO 639-6 (was: Great Script Debate Part II: Formats.. .) Date: Tue, 12 Apr 2005 09:41:01 -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: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Hi, I agree with John below. Let's make sure we don't conflict with (probable/possible) future use of ISO 639-6 tags. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of John Cowan > Sent: Tuesday, April 12, 2005 12:05 PM > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] ISO 639-6 (was: Great Script Debate Part II: > Formats...) > > > Addison Phillips scripsit: > > > I don't think we need to do anything positive or negative about ISO > > 639-6 currently. The current draft doesn't prevent adoption of it, > > if it were to become a standard and be useful in language > tags. Let's > > let Debbie/et al do their work and evaluate the results. Note that > > this is the same thing we are doing for ISO 639-3. If people feel > > super strongly about this, then let's change the ABNF in > the draft to: > > I just want to make sure that there is no collision between a > registered > subtag and an ISO 639-6 code. The simplest way to achieve this is to > require that registered language subtags have at least 5 characters. > > > lang = 2*8ALPHA ; primary language subtags > > We could do that and then add a prose requirement that no > language subtag > less than 5 characters in length can be registered. > > -- > Well, I have news for our current leaders John Cowan > and the leaders of tomorrow: the Bill of > jcowan@reutershealth.com > Rights is not a frivolous luxury, in force http://www.ccil.org/~cowan only during times of peace and prosperity. http://www.reutershealth.com We don't just push it to the side when the going gets tough. --Molly Ivins _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 12:43:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14057; Tue, 12 Apr 2005 12:43:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOdz-0006Mp-Jt; Tue, 12 Apr 2005 12:53:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOOy-00039D-P5; Tue, 12 Apr 2005 12:38:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOOx-00038S-1R for ltru@megatron.ietf.org; Tue, 12 Apr 2005 12:38:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13235 for ; Tue, 12 Apr 2005 12:38:00 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOYQ-00067Q-2T for ltru@ietf.org; Tue, 12 Apr 2005 12:47:59 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 09:37:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: ISO 639-6 Date: Tue, 12 Apr 2005 09:37:42 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA42D3@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: ISO 639-6 Thread-Index: AcU/fBixR3osGJ+1Roq56zIsGCPbXwAAITwA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 12 Apr 2005 16:37:42.0473 (UTC) FILETIME=[F2ABBB90:01C53F7D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable STRONGLY RECOMMENDED is an RFC 2119-ism. We're not screaming. Since it = doesn't make a lot of difference in practice, though, I can change the = case on STRONGLY. The old i-* format is ghastly and greatly complicates processing (since = it is a singleton). Let's avoid it and use just subtags. As for removing the ability to register a primary language subtag, we = have a conceit that variant can be used to register anything not = indicated by one of the ISO/UN based standards. But this cannot work for = one case, which is primary language. The fact that all of the registered = primary languages turned out to be junk doesn't necessarily mean that = the same will hold true in the future. So we leave a very small loophole = to allow it. The existence of a registry makes some of this moot, however. What's = valid in a language tag is whatever the registry says. Some of the ABNF = handwaving is no longer strictly necessary by that measure. We could use = the ABNF I proposed and merely forbid or greatly restrict the use of = registered primary languages. What's important to a well-formed processor is that a primary language = is a 2*8ALPHA. What's important to a validating processor is that the = subtag is in the registry. How it got into the registry is another = matter. I can easily agree to restrict independent registrations to = 5*8ALPHA (especially since I think we'll get zero of them). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: mardi 12 avril 2005 09:06 > To: ltru@ietf.org > Subject: [Ltru] Re: ISO 639-6 >=20 > Addison Phillips wrote: >=20 > > lang =3D 2*8ALPHA ; primary language subtags >=20 > At the moment it's: >=20 > lang =3D 2*3ALPHA ; shortest ISO 639 code > / registered-lang > registered-lang =3D 4*8ALPHA ; registered language subtag >=20 > If the idea is to reserve alpha-4 for ISO 639-6, how about: >=20 > lang =3D 2*4ALPHA ; shortest ISO 639 code > / registered-lang > registered-lang =3D 5*8ALPHA ; registered language subtag >=20 > Your text says about registered-lang tags (none at the moment): >=20 > | MAY be used to form the primary language subtag > [...] > | future registrations of this type will be discouraged: > | primary languages are STRONGLY RECOMMENDED for registration > | with ISO 639 and subtags rejected by ISO 639 will be closely > | scrutinized before they are registered with IANA. >=20 > In other words NOT RECOMMENDED, please use lower case instead > of STRONGLY, screaming doesn't help with RfC 2119. Why do we > need registered-lang at all ? The old i-whatever was good > enough for this purpose. You would get a much simpler ABNF, > and the old i-whatever system is automagically discouraging. >=20 > Just say (modulo "shortest" if necessary for ISO 639-6): > lang =3D 2*4ALPHA ; shortest ISO 639 code >=20 > Remove registered-lang everywhere. Then fix the registration > procedures to allow new IANA i-whatever tags. For the ABNF > that means: >=20 > 1 - insert "individual" between "private-use / gradfathered" > 2 - lang =3D 2*4ALPHA, remove "registered-lang" in "lang" > 3 - remove registered-lang > 4 - replace 1*3ALPHA in "grandfathered" by 2*3ALPHA, strip the > singleton i- comment from "grandfathered" > 5 - add a new "individual" before "grandfathered": > individual =3D "i" 1*2("-" (2*8alphanum)) >=20 > In the procedures replace "registered-lang" by "individual", > mention that an "individual" tag is deprecated when a proper > ISO 639 tag is introduced. >=20 > The tag reviewer has accepted several obscure tags for fantasy > Macao-languages, it's time to stop this nonsense in 3066bis. >=20 > The old i-whatever was better for dubious tags. Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 12:53:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15160; Tue, 12 Apr 2005 12:53:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOna-0006qW-BQ; Tue, 12 Apr 2005 13:03:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLObz-0005Yu-Uk; Tue, 12 Apr 2005 12:51:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLObx-0005XP-UL for ltru@megatron.ietf.org; Tue, 12 Apr 2005 12:51:38 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14847 for ; Tue, 12 Apr 2005 12:51:34 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLOWv-0003wQ-Gd for ltru@lists.ietf.org; Tue, 12 Apr 2005 18:46:26 +0200 Received: from c-134-92-247.hh.dial.de.ignite.net ([62.134.92.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 18:46:25 +0200 Received: from nobody by c-134-92-247.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 18:46:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 12 Apr 2005 18:48:23 +0200 Organization: Lines: 6 Message-ID: <425BFBD7.31E7@xyzzy.claranet.de> References: <20050412163056.GE23496@skunk.reutershealth.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: c-134-92-247.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] attempt to undermine me with my employer X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit John Cowan wrote: > I apologize for the off-topic nature of this post Harassing mails are posted, no reason to apologize. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 12:55:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15358; Tue, 12 Apr 2005 12:55:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOp1-0006tT-2t; Tue, 12 Apr 2005 13:05:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOdk-0006Qr-EX; Tue, 12 Apr 2005 12:53:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOdi-0006Hd-9k for ltru@megatron.ietf.org; Tue, 12 Apr 2005 12:53:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14958 for ; Tue, 12 Apr 2005 12:52:38 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOmb-0006js-Ai for ltru@ietf.org; Tue, 12 Apr 2005 13:02:38 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 09:52:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] date B = 2005-01-01 Date: Tue, 12 Apr 2005 09:52:30 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA42F1@irvmbxw01.quest.com> Thread-Topic: [Ltru] date B = 2005-01-01 Thread-Index: AcU/fb+i3bHC+0NLTLif39WfN3QdZQAAWGtQ From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 12 Apr 2005 16:52:31.0020 (UTC) FILETIME=[04493EC0:01C53F80] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Date B applies to ISO codes, not 3066 tags. What one or another of us = think of registered tags is beside the point: most of them actually are = junk. If they are redundant junk, so much the better. If they are = grandfathered junk, it won't make a difference. Whatever kind of junk it = is, the registry should capture the state of the RFC 3066 registry = rather than picking and choosing. There *is* an appeals process, you know, if you think that the consensus = was declared prematurely. Personally, I couldn't care less about those = tags. I just hope to get this work done quickly so we can quit having to = worry about 3066 and its registry. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: mardi 12 avril 2005 09:27 > To: ltru@ietf.org > Subject: [Ltru] date B =3D 2005-01-01 >=20 > After the intruduction of several nonsense MO-tags in the 3066 > system I propose to use 2005-01-01 as "date B" and ignore all > dubious 3066-tags introduced after 2005-01-01 (if they turn out > to be "redundant" this point is moot). >=20 > Further I want to express that I do not trust anybody involved > in the registrations of MO-languages. >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 12:56:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15535; Tue, 12 Apr 2005 12:56:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOqj-0006yB-3F; Tue, 12 Apr 2005 13:06:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOdX-0006Nx-35; Tue, 12 Apr 2005 12:53:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOdU-0006LO-O0 for ltru@megatron.ietf.org; Tue, 12 Apr 2005 12:53:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15017 for ; Tue, 12 Apr 2005 12:53:01 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOmx-0006lE-Kj for ltru@ietf.org; Tue, 12 Apr 2005 13:03:01 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3CGqq6G019369 for ; Tue, 12 Apr 2005 09:52:52 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AG61T>; Tue, 12 Apr 2005 09:52:52 -0700 Message-ID: From: "McDonald, Ira" To: ltru Working Group Date: Tue, 12 Apr 2005 09:52:43 -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: 79899194edc4f33a41f49410777972f8 Subject: [Ltru] Script debate closed by Chinese tags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi, Disclaimer - I do not mean to criticize (en-US) the excellent work of Michael Everson as the IETF Language Tag Reviewer. Since the collection of zh-script-region tags was just approved (on the IETF Language mailing list) by Michael Everson, the 'great script debate' is closed. Prior art now requires that a 'script' subtag be allowed in the second position in an IANA-registered language tag in RFC3066bis. Discouraged, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 13:11:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16837; Tue, 12 Apr 2005 13:11:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLP4p-0007Ro-JK; Tue, 12 Apr 2005 13:21:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOta-0001yz-LS; Tue, 12 Apr 2005 13:09:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOtZ-0001yK-8F for ltru@megatron.ietf.org; Tue, 12 Apr 2005 13:09:49 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16750 for ; Tue, 12 Apr 2005 13:09:37 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLOpb-0007rw-C0 for ltru@lists.ietf.org; Tue, 12 Apr 2005 19:05:43 +0200 Received: from c-134-92-247.hh.dial.de.ignite.net ([62.134.92.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 19:05:43 +0200 Received: from nobody by c-134-92-247.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 19:05:43 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 12 Apr 2005 19:02:03 +0200 Organization: Lines: 17 Message-ID: <425BFF0B.38B1@xyzzy.claranet.de> References: <4A7C6FA2AB31194E80E13FE585F6A21292A332@EVS-EC1-NODE1.surrey.ac.uk> 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: c-134-92-247.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit L.Gillam wrote: > The above is also a reason I'm in favour of an XML registry > also - the proof of the registry becomes its application to > itself! That's a beautiful idea, but you could also do it with an XML version derived from whatever IANA puts on its Web pages or ftp server. > I'd draw the line at filling fields that were not available > in the source documents. Of course, and IMHO better than Doug's line "Latn", bye, Frank -- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 13:13:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17084; Tue, 12 Apr 2005 13:13:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLP6b-0007XZ-4r; Tue, 12 Apr 2005 13:23:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOwv-0003YF-7H; Tue, 12 Apr 2005 13:13:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOwu-0003Ue-3t for ltru@megatron.ietf.org; Tue, 12 Apr 2005 13:13:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17079 for ; Tue, 12 Apr 2005 13:13:07 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLP6Q-0007XF-RP for ltru@ietf.org; Tue, 12 Apr 2005 13:23:08 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Tue, 12 Apr 2005 13:12:56 -0400 id 00590190.425C0198.00001110 Received-SPF: unknown (Address does not pass the Sender Policy Framework) SPF=HELO; sender=dul1shollenbl1; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; Received-SPF: none (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=sah@428cobrajet.net; remoteip=::ffff:216.168.239.87; remotehost=; helo=dul1shollenbl1; receiver=mail.verisignlabs.com; From: "Scott Hollenbeck" To: "'Addison Phillips'" , ltru@ietf.org Subject: RE: [Ltru] Re: ISO 639-6 Date: Tue, 12 Apr 2005 13:12:22 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0749C9F6@dul1wnexmb01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0AFA42D3@irvmbxw01.quest.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit > STRONGLY RECOMMENDED is an RFC 2119-ism. We're not screaming. > Since it doesn't make a lot of difference in practice, > though, I can change the case on STRONGLY. "STRONGLY" is not described in 2119, "RECOMMENDED" is. The case should definitely be changed to "strongly". -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 13:26:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18111; Tue, 12 Apr 2005 13:26:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPJk-0007ym-Dv; Tue, 12 Apr 2005 13:36:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLP67-0005I7-RH; Tue, 12 Apr 2005 13:22:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLP66-0005Gv-IJ for ltru@megatron.ietf.org; Tue, 12 Apr 2005 13:22:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17700 for ; Tue, 12 Apr 2005 13:22:35 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPFa-0007pl-VM for ltru@ietf.org; Tue, 12 Apr 2005 13:32:35 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 10:22:28 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Tue, 12 Apr 2005 10:22:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Apr 2005 10:22:29 -0700 Message-ID: Thread-Topic: [slightly OT] Linguasphere (was Great Script Debate Part II: Formats...) Thread-Index: AcU/CuVgynR2jWyEQM6aBILe1uHKKwAMNCggAAzdttA= From: "Peter Constable" To: "ltru" X-OriginalArrivalTime: 12 Apr 2005 17:22:28.0395 (UTC) FILETIME=[339AE7B0:01C53F84] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Subject: [Ltru] [slightly OT] Linguasphere (was Great Script Debate Part II: Formats...) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of L.Gillam > The upper layers of the Linguasphere and what is proposed for 639-5 are, > based on a small sample, highly interoperable. This is slightly overstated, I think.=20 Linguasphere's upper-layer analysis divides the world into ten buckets. Five correspond to linguistic phyla (which are genetic classifications), and five correspond to regions of the world.=20 For the five genetic buckets, the upper layers are somewhat, but not highly, interoperable with 639-5. There are a couple of factors that limit the extent to which the two align.=20 First, you need to ignore several of Linguasphere's artificially-constructed categories which are necessitated by fitting everything into its model, which requires every language to be in some net in some chain in some set in some zone in the given sector (phylum). For instance, the analysis for Coptic is: sector / zone / set / chain / net / (outer) language =3D=20 Afro-Asiatic / Coptic / Coptic / Coptic / Coptic / Coptic You won't find an entry for Coptic in the draft table for 639-5. Secondly, Linguasphere appears to have more higher-level branching than is currently reflected in the draft table for 639-5. Specifically, it often treats as a level-2 node something that in the analysis used for 639-5 is a level-3 node and as a result not included in the current draft for 639-5. The result of this is that Linguasphere has several level-2 nodes not found in the current draft of 639-5, and vice versa. (Some notes: I believe the current draft for 639-5 was based largely on Ethnologue, which itself is based on the Oxford International Encyclopaedia of Linguistics and Tyron's Comparitive Austronesian Dictionary. The number of layers included in the current draft of 639-5 for a given family or phylum varies from two to four; I'm not sure on what basis the editor for 639-5 decided how many layers to include, though it appears to be partly related to the size of the phylum: Austronesian, with >1200 languages, gets IDs for four layers while Afroasiatic, with < 400 languages, gets IDs for two layers. My understanding is that Linguasphere's analysis, to the extent that it differs from the above sources, is novel.)=20 Of Linguasphere's five "phylosectors", Indo-European gets the best interop with the current draft for 639-5. The other four don't fair all that well. This results from Linguasphere's unique analysis, which appears to be driven largely by the insistence of fitting everything into its five-layer model for upper levels of hierarchy and of having ten top layers each with ten level-2 groupings. As for Linguasphere's five "geosectors", the story is largely the same. The draft for 639-5 has inherited "North American Indian languages" and "South American Indian Languages" from 639-2, which match three of Linguasphere's geosectors. The level-2 nodes for NAI align somewhat, with a couple of issues. First, you must see past Linguasphere's insistence on geographic designators where familiar genetic terms exist: "Saint Lawrence" instead of Iroquioan, "Mississippi" instead of Siouan. The bigger issue is Linguasphere's insistence on ten level-2 nodes in each sector, forcing level-2 nodes that combining distinct families while in some cases splitting others. So, for instance, instead of nodes for Salishan and Penutian, it has a "Farwest" geozone; and the Hokan family appears to largely match L's "Desert" geozone, though there are a couple of Hokan outliers down in Oaxaca that appear to be somewhere else in L. (I'm not sure where, though: one of L's problems is that it can be really hard to find things since there's no index by name or by country, and the hierarchies don't correspond with familiar analyses.) The draft table for 639-5 has no category corresponding to L's top-level "Eurasia" geosector, but some of L's geozones in that sector align with 639-5 entries: Uralic, Causasus, Dravidic. The other level-2 nodes are more of these geographic groupings artificially created to result in ten zones within each sector. You won't find "Siberia" in 639-5, neither will you find a node for Altaic in Linguasphere. The story for L's "Africa" and "South America" geozones appear to be similar to that for "North America" and "Eurasia"; "Australia" looks like it would be less hopeful (but I haven't looked at it in detail). So, all in all, the best I think can be said regarding interoperability between 639-5 and Linguasphere is that the are somewhat interoperable. I don't think it really can be said that they are highly interoperable. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 13:41:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19419; Tue, 12 Apr 2005 13:41:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPY6-0008RR-JZ; Tue, 12 Apr 2005 13:51:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPMy-0000OU-NZ; Tue, 12 Apr 2005 13:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPMx-0000Mi-Ai for ltru@megatron.ietf.org; Tue, 12 Apr 2005 13:40:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19274 for ; Tue, 12 Apr 2005 13:40:07 -0400 (EDT) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPWZ-0008MM-RW for ltru@ietf.org; Tue, 12 Apr 2005 13:50:08 -0400 Received: from smtp-los03.proxy.aol.com (smtp-los03.proxy.aol.com [195.93.24.41]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN7-8425c07ee1c8; Tue, 12 Apr 2005 13:39:59 -0500 Received: from DEBHOME (ACD86522.ipt.aol.com [172.216.101.34]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3CHduVp000577; Tue, 12 Apr 2005 13:39:56 -0400 Message-Id: <200504121739.j3CHduVp000577@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Peter Constable'" , "'ltru'" Subject: RE: [Ltru] [slightly OT] Linguasphere (was Great Script Debate Part II:Formats...) Date: Tue, 12 Apr 2005 18:40:26 +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.2900.2180 Thread-Index: AcU/CuVgynR2jWyEQM6aBILe1uHKKwAMNCggAAzdttAABbEAIA== In-Reply-To: X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.6 (++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Before we get into a great OT debate about Linguasphere... I think we should be clear about something. Peter is quoting from the Linguasphere Register as published in 2000. There have been significant changes since this publication. I think it would be prudent to wait for the draft of 639-6 before we discuss this. Kind regards Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Peter Constable > Sent: 12 April 2005 18:22 > To: ltru > Subject: [Ltru] [slightly OT] Linguasphere (was Great Script Debate Part > II:Formats...) > > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of L.Gillam > > > > The upper layers of the Linguasphere and what is proposed for 639-5 > are, > > based on a small sample, highly interoperable. > > This is slightly overstated, I think. > > Linguasphere's upper-layer analysis divides the world into ten buckets. > Five correspond to linguistic phyla (which are genetic classifications), > and five correspond to regions of the world. > > For the five genetic buckets, the upper layers are somewhat, but not > highly, interoperable with 639-5. There are a couple of factors that > limit the extent to which the two align. > > First, you need to ignore several of Linguasphere's > artificially-constructed categories which are necessitated by fitting > everything into its model, which requires every language to be in some > net in some chain in some set in some zone in the given sector (phylum). > For instance, the analysis for Coptic is: > > sector / zone / set / chain / net / (outer) language = > Afro-Asiatic / Coptic / Coptic / Coptic / Coptic / Coptic > > You won't find an entry for Coptic in the draft table for 639-5. > > Secondly, Linguasphere appears to have more higher-level branching than > is currently reflected in the draft table for 639-5. Specifically, it > often treats as a level-2 node something that in the analysis used for > 639-5 is a level-3 node and as a result not included in the current > draft for 639-5. The result of this is that Linguasphere has several > level-2 nodes not found in the current draft of 639-5, and vice versa. > > (Some notes: I believe the current draft for 639-5 was based largely on > Ethnologue, which itself is based on the Oxford International > Encyclopaedia of Linguistics and Tyron's Comparitive Austronesian > Dictionary. The number of layers included in the current draft of 639-5 > for a given family or phylum varies from two to four; I'm not sure on > what basis the editor for 639-5 decided how many layers to include, > though it appears to be partly related to the size of the phylum: > Austronesian, with >1200 languages, gets IDs for four layers while > Afroasiatic, with < 400 languages, gets IDs for two layers. My > understanding is that Linguasphere's analysis, to the extent that it > differs from the above sources, is novel.) > > Of Linguasphere's five "phylosectors", Indo-European gets the best > interop with the current draft for 639-5. The other four don't fair all > that well. This results from Linguasphere's unique analysis, which > appears to be driven largely by the insistence of fitting everything > into its five-layer model for upper levels of hierarchy and of having > ten top layers each with ten level-2 groupings. > > As for Linguasphere's five "geosectors", the story is largely the same. > The draft for 639-5 has inherited "North American Indian languages" and > "South American Indian Languages" from 639-2, which match three of > Linguasphere's geosectors. The level-2 nodes for NAI align somewhat, > with a couple of issues. First, you must see past Linguasphere's > insistence on geographic designators where familiar genetic terms exist: > "Saint Lawrence" instead of Iroquioan, "Mississippi" instead of Siouan. > The bigger issue is Linguasphere's insistence on ten level-2 nodes in > each sector, forcing level-2 nodes that combining distinct families > while in some cases splitting others. So, for instance, instead of nodes > for Salishan and Penutian, it has a "Farwest" geozone; and the Hokan > family appears to largely match L's "Desert" geozone, though there are a > couple of Hokan outliers down in Oaxaca that appear to be somewhere else > in L. (I'm not sure where, though: one of L's problems is that it can be > really hard to find things since there's no index by name or by country, > and the hierarchies don't correspond with familiar analyses.) > > The draft table for 639-5 has no category corresponding to L's top-level > "Eurasia" geosector, but some of L's geozones in that sector align with > 639-5 entries: Uralic, Causasus, Dravidic. The other level-2 nodes are > more of these geographic groupings artificially created to result in ten > zones within each sector. You won't find "Siberia" in 639-5, neither > will you find a node for Altaic in Linguasphere. > > The story for L's "Africa" and "South America" geozones appear to be > similar to that for "North America" and "Eurasia"; "Australia" looks > like it would be less hopeful (but I haven't looked at it in detail). > > > So, all in all, the best I think can be said regarding interoperability > between 639-5 and Linguasphere is that the are somewhat interoperable. I > don't think it really can be said that they are highly interoperable. > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 13:43:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19561; Tue, 12 Apr 2005 13:43:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPZk-0008U2-CE; Tue, 12 Apr 2005 13:53:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPL6-0000Em-KE; Tue, 12 Apr 2005 13:38:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPL5-0000EE-TK for ltru@megatron.ietf.org; Tue, 12 Apr 2005 13:38:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19170 for ; Tue, 12 Apr 2005 13:38:04 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPUZ-0008IK-Gp for ltru@ietf.org; Tue, 12 Apr 2005 13:48:04 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 10:37:57 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Tue, 12 Apr 2005 10:37:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] M. Morfin's attempt to undermine me with my employer Date: Tue, 12 Apr 2005 10:37:55 -0700 Message-ID: Thread-Topic: [Ltru] M. Morfin's attempt to undermine me with my employer Thread-Index: AcU/famRI2ZJSvUsSUSmHvWASZm3DQACF1Jw From: "Peter Constable" To: "John Cowan" , X-OriginalArrivalTime: 12 Apr 2005 17:37:56.0936 (UTC) FILETIME=[5D0F0480:01C53F86] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable > I apologize for the off-topic nature of this post, but I feel I must > take this action to defend myself... This action on the part of JFC is way out of line, and leads me to second John's prior request for intervention on the part of the co-chairs. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 13:46:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19814; Tue, 12 Apr 2005 13:46:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPcZ-00008P-5M; Tue, 12 Apr 2005 13:56:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPSL-0001RC-SC; Tue, 12 Apr 2005 13:45:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPSK-0001QJ-SW for ltru@megatron.ietf.org; Tue, 12 Apr 2005 13:45:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19698 for ; Tue, 12 Apr 2005 13:45:33 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPbo-00006s-NV for ltru@ietf.org; Tue, 12 Apr 2005 13:55:34 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 10:45:26 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Tue, 12 Apr 2005 10:45:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] [slightly OT] Linguasphere (was Great Script Debate Part II:Formats...) Date: Tue, 12 Apr 2005 10:45:25 -0700 Message-ID: Thread-Topic: [Ltru] [slightly OT] Linguasphere (was Great Script Debate Part II:Formats...) Thread-Index: AcU/CuVgynR2jWyEQM6aBILe1uHKKwAMNCggAAzdttAABbEAIAAAO+jw From: "Peter Constable" To: "ltru" X-OriginalArrivalTime: 12 Apr 2005 17:45:25.0995 (UTC) FILETIME=[68B7FBB0:01C53F87] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Before we get into a great OT debate about Linguasphere... I think we should > be clear about something. Peter is quoting from the Linguasphere Register > as published in 2000. There have been significant changes since this > publication. >=20 > I think it would be prudent to wait for the draft of 639-6 before we discuss > this. Debbie is quite right: I'm quoting from the first edition of the Linguasphere register, which is the only info I have to go on; though certainly not insignificant in this case, it is certainly possible that very significant changes have been made. Thus, I agree with her final comment: that it would be prudent to wait. I did not intend to start any debate over Linguasphere. I only intended to point out reasons why I thought Lee's comment on interop was overly hopeful, but I concede that I may not have been comparing with an appropriate source. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 14:03:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20761; Tue, 12 Apr 2005 14:03:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLPsu-0000bW-78; Tue, 12 Apr 2005 14:13:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPiI-0004fI-4M; Tue, 12 Apr 2005 14:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPiC-0004dq-Aa for ltru@megatron.ietf.org; Tue, 12 Apr 2005 14:02:13 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20622 for ; Tue, 12 Apr 2005 14:01:49 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLPdl-0000b3-D6 for ltru@lists.ietf.org; Tue, 12 Apr 2005 19:57:33 +0200 Received: from c-134-92-247.hh.dial.de.ignite.net ([62.134.92.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 19:57:33 +0200 Received: from nobody by c-134-92-247.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 19:57:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 12 Apr 2005 19:56:10 +0200 Organization: Lines: 41 Message-ID: <425C0BBA.683F@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0AFA42F1@irvmbxw01.quest.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: c-134-92-247.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: date B = 2005-01-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > Date B applies to ISO codes, not 3066 tags. Maybe we could just use the grandfathered tags _as published_ by IANA, that's "date en-GB-oed" = 2003-07-09 at the moment. > What one or another of us think of registered tags is beside > the point: most of them actually are junk. Your co-author proposed the MO-junk. Abusing these tags as a precedence could result in much more junk tags. > If they are redundant junk, so much the better. Sure, I still think that we don't need redundant junk tags in the future registry. Recommended prefixes "zh-Hans ; zh-Hant" for region MO are certainly not what we want, pt-Latn-MO might be dubious, but it's not illegal. > If they are grandfathered junk, it won't make a difference. IBTD, only two of them are MO-junk, and all new grandfathered tags that are really useful would be a PITA (deprecate them, add a canonical value, the works). > the registry should capture the state of the RFC 3066 > registry rather than picking and choosing. Okay, _as is_ at date-B (= whenever Doug creates a new draft registry, the last is the initial registry). > There *is* an appeals process, you know I've already fired my "one appeal per period" [TBD] 2004-09-22, my personal rule, therefore no 2nd net suicide for the MO-junk. It's only ugly if they turn out to be "grandfathered", but not critical. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 14:13:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21859; Tue, 12 Apr 2005 14:13:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQ2s-0000wB-UH; Tue, 12 Apr 2005 14:23:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPsA-0006VS-4c; Tue, 12 Apr 2005 14:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPs8-0006Uv-DD for ltru@megatron.ietf.org; Tue, 12 Apr 2005 14:12:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21609 for ; Tue, 12 Apr 2005 14:12:14 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQ1c-0000sb-F9 for ltru@ietf.org; Tue, 12 Apr 2005 14:22:13 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Tue, 12 Apr 2005 11:12:05 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Tue, 12 Apr 2005 11:12:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] date B = 2005-01-01 Date: Tue, 12 Apr 2005 11:12:04 -0700 Message-ID: Thread-Topic: [Ltru] date B = 2005-01-01 Thread-Index: AcU/fcT67sCrwAf0TY6i7Ny/r8Ky5QACQC7w From: "Peter Constable" To: X-OriginalArrivalTime: 12 Apr 2005 18:12:05.0516 (UTC) FILETIME=[221B84C0:01C53F8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Frank Ellermann > Further I want to express that I do not trust anybody involved > in the registrations of MO-languages. That's a rather extreme and all-encompassing statement.=20 It strikes me as particularly extreme given information indicating that Chinese experts in the region would distinguish Mandarin/traditional content in Taiwan, Hong Kong, PRC and Macao. Moreover, use of zh-Hant-MO or zh-Hans-MO to distinguish Macao from other regions can be no more problematic than current use of zh-MO. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 14:14:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21891; Tue, 12 Apr 2005 14:14:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQ3e-0000wY-F2; Tue, 12 Apr 2005 14:24:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPrS-0006PH-Ts; Tue, 12 Apr 2005 14:11:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLPrR-0006Od-N8 for ltru@megatron.ietf.org; Tue, 12 Apr 2005 14:11:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21546 for ; Tue, 12 Apr 2005 14:11:31 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQ0t-0000pp-Ps for ltru@ietf.org; Tue, 12 Apr 2005 14:21:30 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3CIBJua184132 for ; Tue, 12 Apr 2005 14:11:20 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3CIBJ1K263166 for ; Tue, 12 Apr 2005 12:11:19 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3CIBJBj023143 for ; Tue, 12 Apr 2005 12:11:19 -0600 Received: from markdavis (sig-9-48-117-111.mts.ibm.com [9.48.117.111]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3CIBHoX023007; Tue, 12 Apr 2005 12:11:18 -0600 Message-ID: <017901c53f8b$0601c330$ab703009@sanjose.ibm.com> From: "Mark Davis" To: "Peter Constable" , "John Cowan" , References: Subject: Re: [Ltru] M. Morfin's attempt to undermine me with my employer Date: Tue, 12 Apr 2005 11:11:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j3CIBJua184132 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable I strongly agree. How long must we wait for this clearly-overdue action? =E2=80=8EMark ----- Original Message -----=20 From: "Peter Constable" To: "John Cowan" ; Sent: Tuesday, April 12, 2005 10:37 Subject: RE: [Ltru] M. Morfin's attempt to undermine me with my employer > I apologize for the off-topic nature of this post, but I feel I must > take this action to defend myself... This action on the part of JFC is way out of line, and leads me to second John's prior request for intervention on the part of the co-chairs. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 14:27:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22842; Tue, 12 Apr 2005 14:27:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQGE-0001LU-0d; Tue, 12 Apr 2005 14:37:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQ4a-000180-8i; Tue, 12 Apr 2005 14:25:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQ4Y-00017H-Co for ltru@megatron.ietf.org; Tue, 12 Apr 2005 14:25:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22631 for ; Tue, 12 Apr 2005 14:25:04 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQE1-0001Gl-F2 for ltru@ietf.org; Tue, 12 Apr 2005 14:35:03 -0400 Received: from lns-p19-1-idf-82-251-69-49.adsl.proxad.net ([82.251.69.49] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLQ4M-0003uK-C2 for ltru@ietf.org; Tue, 12 Apr 2005 11:25:02 -0700 Message-Id: <6.1.2.0.2.20050412184945.05538960@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 20:22:25 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] M. Morfin's attempt to undermine me with my employer In-Reply-To: <20050412163056.GE23496@skunk.reutershealth.com> References: <20050412163056.GE23496@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 I have been informed, I reviewed and I approved this mail which has been decided by my organisation. One should not reverse the roles. I often said I could survive the harassment I am subject from a very few number of supporters of the RFC 3066 Bis/Ter Draft since I opposed its Last Call, I supported the creation of the WG-ltru and I protest than thorny questions risen by its Charter have not been considered before the proposition of a WG Draft. However this is a permanent public attempt to undermine my own reputation and the reputation of the organisation I belong to. This organisation has direct relations with different press agencies and information centers. It has been questioned due to the appearance of John Cowan's mails through his organisation name's in search engines. Some of John Cowan's mails include a disclaimer about the responsibility of his organisation for his views, while many others are not. This make this organisation legally responsible for the positions expressed by John Cowan in his mails. A clarification is our obvious right. We think that a PR may be enough as soon as we receive a response from their legal department. We obviously wish this PR being common if possible. To write it we need to know who assume legal responsibilities of what. I note that this mailing list being public, this mail (noted JCRJFC) will be referenced on search engines, giving our interlocutors all the preliminary elements. jfc On 18:30 12/04/2005, John Cowan said: >I apologize for the off-topic nature of this post, but I feel I must >take this action to defend myself. > >Reuters, my employer, received the following message today through our >electronic customer help system. It was forwarded to me for disposition, >although it was addressed to "Mr. Chairman". > > > E-mail: info@afrac.org > > First Name: Legal Affairs > > Last Name: AFRAC > > E-Mail Address: info@afrac.org > > Address: > > City/Town: Versailles > > Postal Code/Zip: > > Country: France > > Company: AFRAC > > State: > > > > Mr. Chairman, > > we wish to know if Mr. John Cowan, who uses the e-mail address > > jcowan@reutershealth.com, belongs to the Reuters organization. If this > > is the case we desire to know if his participation to the IETF (Internet > > Engineering Task Force) is part of his Reuters assignments. If this was > > the case, if his attitude there results from a Reuters policy. > >The answers are yes, no, and no respectively. My supervisor and >other Reuters employees are aware of my membership in this WG, but my >participation in it is not an "assignment". As is well known, IETF >members speak for themselves and not for their employers. > > > The reason why we need to know this is that Mr. John Cowan has formally > > petitioned the Chair of the IETF WG-ltru to ban our VP R&D from this > > Working Group. Due to our VP R&D kind attitude in response to Mr. Cowan's > > periodic harassment and his technical, political, societal background > > and thirty years of high level experience in international networking > > this request is ... childish. > > > > However, this WG discusses what we consider the founding building blocks > > of the multilingual internet, resulting in an innovation demanded by the > > World Summit on the Information Society, some considerable commercial and > > political interests want to contain or at least constrain. We therefore > > fear that under the circumstances some could be tempted to take advantage > > of the name of your group as a cover for an action against what we > > consider the general interest we strive to support. This could only > > result in a public reaction from us against your supposed strategy which > > would be detrimental to all, as we believe that - as an international > > information group - we fully share the same values and will be among > > the first to technically benefit from our action (we are in relation > > with other press agencies technical departments and cooperated in the > > past with information services now amalgamated in your organization). > > > > If your intent is not figth us and our efforts for the common good, > > as we suppose, we could only suggest that Mr. John Cowan uses another > > e-mail name, apologizes to his fellow members of his Working Group > > for his attitude and continue his excellent contributions in a less > > acrimonious way. > >Mr. Cowan declines to do anything of the sort, and believes his actions >were fully justified. > > > This mail is sent in using your on-line [URL deleted] advised system. We > > will contact tomorrow the Reuters legal department in Paris we will then > > copy and ask an acknowledgment from. > > > > Sincerely yours. > > > > Legal Department > > info@afrac.org > > AFRAC > > http://afrac.org > > April 11th, 2005 > >WG members can draw their own conclusions about the actual author of this >document. > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 14:28:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23038; Tue, 12 Apr 2005 14:28:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQHW-0001Nh-Lz; Tue, 12 Apr 2005 14:38:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQ4a-000187-Ck; Tue, 12 Apr 2005 14:25:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQ4Y-00017I-Hh for ltru@megatron.ietf.org; Tue, 12 Apr 2005 14:25:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22634 for ; Tue, 12 Apr 2005 14:25:04 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQE2-0001Gp-Mz for ltru@ietf.org; Tue, 12 Apr 2005 14:35:04 -0400 Received: from lns-p19-1-idf-82-251-69-49.adsl.proxad.net ([82.251.69.49] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLQ4L-0003uK-DA; Tue, 12 Apr 2005 11:25:01 -0700 Message-Id: <6.1.2.0.2.20050412180548.04976550@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 18:47:30 +0200 To: "L.Gillam" , ltru From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Great Script Debate Part II: Formats... In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A362@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A21292A362@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 I think you are globally right. At 16:50 12/04/2005, L.Gillam wrote: Where did I make something forbidden Jefsey? Ah! I thought you wanted to forbid French and hooks for other languages. On the contrary, >I think you'll find I say there are certain things we should >not impose (just above here for example). This implies that default references should be autonyms? I was wrong reading you differently. >Quite the reverse. Please do not twist what I, or indeed others, write in >an attempt to validate your position. I have no position. Just observation. When I say that the lack of support of English and French is a blocking element. This is because I observe that it will be real world blocking, because applications are under current development and projects under financing which say otherwise. >There's a "forbid" if you want one. How rigth you are. jfc PS. I suppose you will want to respond I a wrong or unintelligible. No need, I have already taken your response into account. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 14:40:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23835; Tue, 12 Apr 2005 14:40:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQSr-0001h1-Kx; Tue, 12 Apr 2005 14:50:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQHP-0002jg-DZ; Tue, 12 Apr 2005 14:38:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQHO-0002jE-2q for ltru@megatron.ietf.org; Tue, 12 Apr 2005 14:38:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23601 for ; Tue, 12 Apr 2005 14:38:20 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime01.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQQs-0001cG-9S for ltru@ietf.org; Tue, 12 Apr 2005 14:48:19 -0400 Received: from eupig1 (unverified) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Tue, 12 Apr 2005 19:38:07 +0100 Message-ID: Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IEU001FNJRINW@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Tue, 12 Apr 2005 18:38:07 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Tue, 12 Apr 2005 19:38:06 +0100 Date: Tue, 12 Apr 2005 19:38:05 +0100 From: Misha Wolf Subject: RE: [Ltru] OT: A Modest Proposal To: LTRU Working Group MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] OT: A Modest Proposal Thread-Index: AcU/jbG/jcJT05XgSQeQ/afR0A1kOQAAJlxw content-class: urn:content-classes:message X-OriginalArrivalTime: 12 Apr 2005 18:38:06.0381 (UTC) FILETIME=[C4749DD0:01C53F8E] X-Spam-Score: 0.8 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable On behalf of Klingons and billions of other peoples, I strongly=20 object to your proposal which is completely Earth-centric. I=20 shall be contacting my legal department. Misha -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Mark Davis Sent: 12 April 2005 19:26 To: LTRU Working Group Subject: [Ltru] A Modest Proposal Since it is obvious that all applications in the world will require extremely fine-grained approach to languages, here is an initial proposal for development of a separate RFC to deal with them. The goal is to be able to describe the variety of speech that each person on earth may be using at a given time. Identification is by means of the location of the speaker and the time at which the speech could have occurred. The language tag is given by the following format (formal ABNF to follow). XLanguageTag ::=3D latitude "-" longitude "-" altitude "-" time [...] ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 15:01:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25574; Tue, 12 Apr 2005 15:01:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQnV-0002Ii-5F; Tue, 12 Apr 2005 15:11:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQcS-0006Br-RO; Tue, 12 Apr 2005 15:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQcQ-0006BZ-Tp for ltru@megatron.ietf.org; Tue, 12 Apr 2005 15:00:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25455 for ; Tue, 12 Apr 2005 15:00:12 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQlx-0002Gl-TR for ltru@ietf.org; Tue, 12 Apr 2005 15:10:09 -0400 Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLQcF-0000MW-00 for ltru@ietf.org; Tue, 12 Apr 2005 12:00:03 -0700 Message-ID: <009f01c53f92$09bec700$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] M. Morfin's attempt to undermine me with my employer Date: Tue, 12 Apr 2005 12:01:30 -0700 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: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi - > From: "Peter Constable" > To: "John Cowan" ; > Sent: Tuesday, April 12, 2005 10:37 AM > Subject: RE: [Ltru] M. Morfin's attempt to undermine me with my employer ... > This action on the part of JFC is way out of line, and leads me to > second John's prior request for intervention on the part of the > co-chairs. ... As co-chair I'm very reluctant to include off-list behaviour, no matter how reprehensible, in a decision to employ RFC 3934. I've already consulted with our AD on the question of what to do about Jefsey, and am waiting to sync up with my co-chair before taking action. In the meantime, my personal suggestion to all would be to not respond to anything he writes unless you think he has raised a valid technical point. It doesn't seem to be worthwhile to correct the errors in understanding. Normally, I'd take these as a sign that a document needs to be clearer, but his penchant for misreading even the clearest English suggest that these might not be worth worrying about. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 15:15:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27189; Tue, 12 Apr 2005 15:15:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLR0k-0002g0-7Z; Tue, 12 Apr 2005 15:25:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQkI-0007wJ-Po; Tue, 12 Apr 2005 15:08:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQkH-0007vk-Ld for ltru@megatron.ietf.org; Tue, 12 Apr 2005 15:08:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26316 for ; Tue, 12 Apr 2005 15:08:11 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQtm-0002Sv-V8 for ltru@ietf.org; Tue, 12 Apr 2005 15:18:11 -0400 Received: from lns-p19-1-idf-82-251-69-49.adsl.proxad.net ([82.251.69.49] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLQk7-0007ys-7D; Tue, 12 Apr 2005 12:08:12 -0700 Message-Id: <6.1.2.0.2.20050412203555.055667a0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 21:07:52 +0200 To: "Mark Davis" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] A Modest Proposal In-Reply-To: <017c01c53f8d$21e1c530$ab703009@sanjose.ibm.com> References: <017c01c53f8d$21e1c530$ab703009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA26316 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable Mark should be praised for this long overdue proposition. It however rises some questions. At 20:26 12/04/2005, Mark Davis wrote: >Since it is obvious that all applications in the world will require >extremely fine-grained approach to languages, here is an initial proposa= l >for development of a separate RFC to deal with them. Is this a private Draft or suggested by this WG-ltru? >The goal is to be able to describe the variety of speech that each perso= n=20 >on earth may be using at a given time. Identification is by means of the= =20 >location of the speaker and the time at which the speech could have occu= rred. "using" is imprecise. "spoken", "read", "though", etc. should be document= ed. Is the "could" voluntary, as it introduces a interesting complexity.=20 Obviously this one language can be tough, a second spoken, a third read a= t=20 the same time (real time translation, considering the directory of an=20 international meeting). >The language tag is given by the following format (formal ABNF to follow= ). > >XLanguageTag ::=3D latitude "-" longitude "-" altitude "-" time I thank you for disclosing your ultimate target. This implies a default=20 language, a default script. This is not compliant with the charter is you do not specify the ISO=20 standard being used? The real value of this proposition is its immediate support of IPv6=20 reference. There is already several propositions to allocate a /3 Block t= o=20 a geographic addressing in /64. The time value will be OK as an interface= =20 value. The interest is that the XLanguageTag can be encrypted. This means= =20 that you can have a protected hidden language tag, fully BCP 047 complian= t. >Latitude and longitude are specified by radians, and be measured from 0 = to >360 starting at the Prime Meridian going east, and from 0 to 180 startin= g at >the South Pole and going north. Sorry, wrong. A radian is equal to 360/2 pi. So, you mean 2 pi and pi. >The numeric values below zero are avoided >because the use of the terms "positive" and "negative" when applied to >location can clearly be prejudicial to many of the peoples of the world. Radian cannot be negative. >Should in the course of the development of this RFC, the use of the Prim= e >Meridian be viewed as representative of an English-speaking hegemony, a >random longitude will be chosen as the origin. Conforming to the IANA randomization process. But this process is biased = as=20 it uses the Wall Street Journal. > Use of latitude and longitude >does not, of course, imply in any way that those who believe in a flat e= arth >or the "four-elephant+turtle system" are in any way discouraged in the >observance of their faith, nor does the use of radians in any way denigr= ate >the goal of the Kansas State Education Board to recognize the value of =CF= =80 as >exactly 3.0. Fair enough. >Altitude is in meters above the center of the earth. While some may feel= the >likelihood of two speakers being exactly overhead is low, we do -- of >course -- want to plan for all eventualities. By avoiding measurement >against sea level, we again celebrate the diversity of the world's >population, and do not discriminate against the proud inhabitants of Dea= th >Valley and similar locations by in any way referring to them as "negativ= e". This obviously creates a problem, since the value of the Earth radius=20 varies with the move of people on Earth. There should be a function to=20 relate the language being used to the local position of the reviewer at t= he=20 time the language is heard. >For location, since people rarely overlap This seems to condemn the system in short delay if human cannot reproduce= .=20 A large part of the Hollywood industry may oppose. >in physical space, it will usually >be sufficient to have accuracy to within 10 cm. But since fractions can = be >supplied, applications can have arbitrarily high degree of accuracy. I am relieved. >The time is specified by seconds since 0000-01-00T00:00:00Z (using the >proleptic Gregorian calendar as specified in XML Schema), plus an offset= of >1,000,000,000,000,000,000. If finer granularity than seconds is desired, >then fractions can be specified. The reason for the offset is to again a= void >negative numbers, and their implied bias against historic inhabitants. I am afraid there is a problem with the quantum decoherence. You seem to=20 imply that the four dimensions can be simultaneously known? This will not= =20 scale. Please refer to RFC 1958. >The offset is chosen as to be well before all current estimates of the B= ig=20 >Bang. Which Big Bang, in which universe? Please consult=20 http://superstringtheory.com/ >Note, however, that this in no way implies any denigration of creationis= m, >or that believers are in any way discouraged in the observance of their >faith. Nor does it imply that any one system of creationism, such as Gre= ek >or Norse creation theory, is any way inferior to any other, such as that >espoused by the Kansas State Education Board. This constant reference to the Kansas dominance is not acceptable as it=20 introduces a single point of failure in this otherwise excellent=20 improvement on the previous Draft. Bravo! >Other parts of this proposal, such as security implications, will be >forthcoming. Please do not forget IANA and multilingual considerations. As Misha=20 indicated it, it will not fly the Last Call as Vint Cerf will certainly=20 object that it does not support space. >=E2=80=8EMark You see that at the end of the day we could reach a consensual position. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 15:18:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23042; Tue, 12 Apr 2005 14:28:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQHW-0001Nk-OY; Tue, 12 Apr 2005 14:38:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQ65-0001EA-N8; Tue, 12 Apr 2005 14:26:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLQ64-0001DN-Ob for ltru@megatron.ietf.org; Tue, 12 Apr 2005 14:26:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22767 for ; Tue, 12 Apr 2005 14:26:38 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLQFY-0001IX-3Y for ltru@ietf.org; Tue, 12 Apr 2005 14:36:37 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3CIQP5b539454 for ; Tue, 12 Apr 2005 14:26:25 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3CIQP1K243944 for ; Tue, 12 Apr 2005 12:26:25 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3CIQOPJ026819 for ; Tue, 12 Apr 2005 12:26:24 -0600 Received: from markdavis (sig-9-48-117-111.mts.ibm.com [9.48.117.111]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3CIQNPA026749 for ; Tue, 12 Apr 2005 12:26:24 -0600 Message-ID: <017c01c53f8d$21e1c530$ab703009@sanjose.ibm.com> From: "Mark Davis" To: "LTRU Working Group" Date: Tue, 12 Apr 2005 11:26:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id j3CIQP5b539454 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Subject: [Ltru] A Modest Proposal X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Since it is obvious that all applications in the world will require extremely fine-grained approach to languages, here is an initial proposal for development of a separate RFC to deal with them. The goal is to be ab= le to describe the variety of speech that each person on earth may be using = at a given time. Identification is by means of the location of the speaker a= nd the time at which the speech could have occurred. The language tag is giv= en by the following format (formal ABNF to follow). XLanguageTag ::=3D latitude "-" longitude "-" altitude "-" time Latitude and longitude are specified by radians, and be measured from 0 t= o 360 starting at the Prime Meridian going east, and from 0 to 180 starting= at the South Pole and going north. The numeric values below zero are avoided because the use of the terms "positive" and "negative" when applied to location can clearly be prejudicial to many of the peoples of the world. Should in the course of the development of this RFC, the use of the Prime Meridian be viewed as representative of an English-speaking hegemony, a random longitude will be chosen as the origin. Use of latitude and longit= ude does not, of course, imply in any way that those who believe in a flat ea= rth or the "four-elephant+turtle system" are in any way discouraged in the observance of their faith, nor does the use of radians in any way denigra= te the goal of the Kansas State Education Board to recognize the value of =CF= =80 as exactly 3.0. Altitude is in meters above the center of the earth. While some may feel = the likelihood of two speakers being exactly overhead is low, we do -- of course -- want to plan for all eventualities. By avoiding measurement against sea level, we again celebrate the diversity of the world's population, and do not discriminate against the proud inhabitants of Deat= h Valley and similar locations by in any way referring to them as "negative= ". For location, since people rarely overlap in physical space, it will usua= lly be sufficient to have accuracy to within 10 cm. But since fractions can b= e supplied, applications can have arbitrarily high degree of accuracy. The time is specified by seconds since 0000-01-00T00:00:00Z (using the proleptic Gregorian calendar as specified in XML Schema), plus an offset = of 1,000,000,000,000,000,000. If finer granularity than seconds is desired, then fractions can be specified. The reason for the offset is to again av= oid negative numbers, and their implied bias against historic inhabitants. Th= e offset is chosen as to be well before all current estimates of the Big Ba= ng. Note, however, that this in no way implies any denigration of creationism= , or that believers are in any way discouraged in the observance of their faith. Nor does it imply that any one system of creationism, such as Gree= k or Norse creation theory, is any way inferior to any other, such as that espoused by the Kansas State Education Board. Other parts of this proposal, such as security implications, will be forthcoming. =E2=80=8EMark _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 15:28:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28579; Tue, 12 Apr 2005 15:28:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLRDH-00031H-L8; Tue, 12 Apr 2005 15:38:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLR0l-00019T-Km; Tue, 12 Apr 2005 15:25:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLR0j-00018N-M9 for ltru@megatron.ietf.org; Tue, 12 Apr 2005 15:25:21 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28303 for ; Tue, 12 Apr 2005 15:25:10 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLQwg-00071T-Og for ltru@lists.ietf.org; Tue, 12 Apr 2005 21:21:11 +0200 Received: from c-134-92-247.hh.dial.de.ignite.net ([62.134.92.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 21:21:10 +0200 Received: from nobody by c-134-92-247.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 21:21:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 12 Apr 2005 21:20:55 +0200 Organization: Lines: 41 Message-ID: <425C1F97.1B7A@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-92-247.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: date B = 2005-01-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Peter Constable wrote: > That's a rather extreme and all-encompassing statement. It was as a personal statement, but maybe that's clearer in other forms: "Script debate closed by Chinese tags" (Ira) "Re: LANGUAGE TAG REGISTRATION FORM: mn-Mong-CN" (John) "Re: LANGUAGE TAG REGISTRATION FORM: mn-Mong-CN" (Harald) > Chinese experts in the region would distinguish > Mandarin/traditional content in Taiwan, Hong Kong, PRC and > Macao. See from Mark, he quotes: | If you were to ask most computer scientists in HK whether or | not it makes sense to distinguish zh-Hant-HK from zh-Hant-TW, | they'd say, "Of course, and don't forget Macao." That's no evidence, it's an assumption based on some fictitious hearsay. > use of zh-Hant-MO or zh-Hans-MO to distinguish Macao from > other regions can be no more problematic than current use of > zh-MO. If it ends as grandfathered "junk" under the future 3066bis there's a difference. Each additional grandfathered tag could be a reason to not implement / support RfC 3066bis at all and wait for some kind of "better" 3066ter. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 15:48:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00124; Tue, 12 Apr 2005 15:48:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLRWd-0003aB-1Z; Tue, 12 Apr 2005 15:58:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRKI-0003zu-9z; Tue, 12 Apr 2005 15:45:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRKG-0003yy-Gc for ltru@megatron.ietf.org; Tue, 12 Apr 2005 15:45:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29935 for ; Tue, 12 Apr 2005 15:45:05 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLRTU-0003Uj-68 for ltru@ietf.org; Tue, 12 Apr 2005 15:55:05 -0400 Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLRJo-0002Pc-00 for ltru@ietf.org; Tue, 12 Apr 2005 12:45:04 -0700 Message-ID: <00dc01c53f98$53616d80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <011a01c53ee2$4a1a5d60$7f1afea9@oemcomputer> <200504112220.j3BMK84I004532@smtp-los03.proxy.aol.com> <6.1.2.0.2.20050412014332.0309ceb0@mail.jefsey.com> <008801c53f05$6159f940$7f1afea9@oemcomputer> <20050412022051.GB25185@skunk.reutershealth.com> <6.1.2.0.2.20050412042736.0331a020@mail.jefsey.com> <000401c53f14$d30149e0$7f1afea9@oemcomputer> <6.1.2.0.2.20050412170519.063eda30@mail.jefsey.com> Subject: Re: [Ltru] [psg.com #882] registry should copy non-English fields from ISO documents Date: Tue, 12 Apr 2005 12:46:31 -0700 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: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Hi - > From: "JFC (Jefsey) Morfin" > To: "Randy Presuhn" > Sent: Tuesday, April 12, 2005 11:24 AM > Subject: Re: [Ltru] [psg.com #882] registry should copy non-Englishfields from ISO documents > > On 06:05 12/04/2005, Randy Presuhn said: > > > I note you use my comment to Debbie's as a basis for your gallop but do not > > > quote her. > > > >I am not able to figure out what this statement is supposed to mean. > >Do you have a problem or technical comment? > > You list people having commented positively or negatively your question and > do not list Debbie's position. > jfc > As far as I can tell, Debbie took no position in the debate other than to say that I had correctly summarized the state of agreement at that time. Debbie, please correct me if I mis-read your post. Currently, here's where I think we are: Those in opposition are Randy, Addison, Mark, Peter, and Robin. Those in support are Jefsey, John, Ned, and Doug. Both John and Doug, as well as several of those who are neutral, are opposed to Jefsey's provisos. Consequently, I think there is a consensus to reject Jefsey's provisos. On the basic question, there is now a slim majority in favor of rejecting the proposal, but I'm not willing to call it a consensus one way or the other until others on the list speak up or someone changes their mind. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 16:10:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03361; Tue, 12 Apr 2005 16:10:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLRs2-0004tZ-LL; Tue, 12 Apr 2005 16:20:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRbF-0006SP-D3; Tue, 12 Apr 2005 16:03:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRbE-0006Rn-Oi for ltru@megatron.ietf.org; Tue, 12 Apr 2005 16:03:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02127 for ; Tue, 12 Apr 2005 16:02:54 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLRkk-0004RN-Rr for ltru@ietf.org; Tue, 12 Apr 2005 16:12:55 -0400 Received: from lns-p19-1-idf-82-251-69-49.adsl.proxad.net ([82.251.69.49] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLRb4-0003oK-So for ltru@ietf.org; Tue, 12 Apr 2005 13:02:55 -0700 Message-Id: <6.1.2.0.2.20050412220121.0553a470@pop.online.fr> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 22:02:36 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Ltru] IANA update trough RFC X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca from a recent qui pro quo with Michael Everson resulted in an idea which may have some worth. I suggested Michael to come in here to jointly support the idea, also with his experience. I regret he refused because I think the idea interesting. We are discussing of first version of the "registry" to be loaded by the IANA and we experiment delays up to 6 months by the IANA. We also need to find a dissemination way which does not drain to much on the Internet public common resources. We have not discussed some of the Charter questions the idea, IMHO, could make easier to address. The idea use the present IETF WG and to transfer it under the Chairmanship of Michael (IESG assigned reviewer(s)) once the RFC published. - the WG-LTRU would be permanent - it would issue a yearly RFC which would be the language registry (the format to discuss) - this RFC would follow a Draft which would be updated every month by the WG. - the reference to the RFC would give the yearly reference. - the standard IETF (AD, Chairs, Charter, Last Calls,etc) Internet standard process would apply. A Draft is valid for 6 months. Drafts have a well established track. This would both match the IANA delay (6 months) and is acceptable as a normative document because this is a BCP (which describes a de facto practice). This would leave full control of the IESG over the evolution of the registry through the yearly review of the WG Charter and would permit to keep the format updated to the various applications demands. It would permit a permanent cooperation with other Application Area propositions/WGs (like OPES). The interest is also that an RFC includes the Security, IANA, etc consideration parts, permitting to easily document/maintain these aspects and is covered by the ISOC/IETF Intellectual Property Rights. Another advantage is that this would make langtags a standard IETF process without special procedures. The Internet standard process considers the case of lack of network expertise in a specialized WG and the assistance to provide to its Chairs. The load on IANA should be very reduced, due to the permitted stability of the RFC process, numerous replication servers, habit of developers, etc. This would certainly encourage the proposition of value added services on top of the yearly RFC/Draft publication. The addition of language names in different languages could then easily result from additional BPC. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 16:11:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03528; Tue, 12 Apr 2005 16:11:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLRsc-0004wP-3o; Tue, 12 Apr 2005 16:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRiM-0007oq-E3; Tue, 12 Apr 2005 16:10:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRiK-0007o4-Fi for ltru@megatron.ietf.org; Tue, 12 Apr 2005 16:10:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03341 for ; Tue, 12 Apr 2005 16:10:14 -0400 (EDT) Received: from rly-ip04.mx.aol.com ([64.12.138.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLRrq-0004sm-Im for ltru@ietf.org; Tue, 12 Apr 2005 16:20:14 -0400 Received: from smtp-los04.proxy.aol.com (smtp-los04.proxy.aol.com [195.93.24.101]) by rly-ip04.mx.aol.com (v98.19) with ESMTP id RELAYIN4-5425c2b122bb; Tue, 12 Apr 2005 16:09:54 -0400 Received: from DEBHOME (ACD86522.ipt.aol.com [172.216.101.34]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3CK9ks4031846; Tue, 12 Apr 2005 16:09:46 -0400 Message-Id: <200504122009.j3CK9ks4031846@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] [psg.com #882] registry should copy non-English fieldsfrom ISO documents Date: Tue, 12 Apr 2005 21:10:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU/mGV53vAecuYJTZCJMBb2oEJ+PAAAf5vQ In-Reply-To: <00dc01c53f98$53616d80$7f1afea9@oemcomputer> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.101 X-Spam-Score: 2.6 (++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Randy Presuhn Wrote: > As far as I can tell, Debbie took no position in the debate other than to > say > that I had correctly summarized the state of agreement at that time. > Debbie, > please correct me if I mis-read your post. You read my post correctly... my main comment was that IF the information is included it should be in a separate field... but as to whether it should or should not be included... effectively I am "on the fence". Additionally I stated that there is currently a separate "French Name" field in the proposed 639-6. Sorry... no help from me today! Kind regards Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > Sent: 12 April 2005 20:47 > To: LTRU Working Group > Subject: Re: [Ltru] [psg.com #882] registry should copy non-English > fieldsfrom ISO documents > > Hi - > > > From: "JFC (Jefsey) Morfin" > > To: "Randy Presuhn" > > Sent: Tuesday, April 12, 2005 11:24 AM > > Subject: Re: [Ltru] [psg.com #882] registry should copy non- > Englishfields from ISO documents > > > > > On 06:05 12/04/2005, Randy Presuhn said: > > > > I note you use my comment to Debbie's as a basis for your gallop but > do not > > > > quote her. > > > > > >I am not able to figure out what this statement is supposed to mean. > > >Do you have a problem or technical comment? > > > > You list people having commented positively or negatively your question > and > > do not list Debbie's position. > > jfc > > > > As far as I can tell, Debbie took no position in the debate other than to > say > that I had correctly summarized the state of agreement at that time. > Debbie, > please correct me if I mis-read your post. > > Currently, here's where I think we are: > > Those in opposition are Randy, Addison, Mark, Peter, and Robin. > Those in support are Jefsey, John, Ned, and Doug. > > Both John and Doug, as well as several of those who are neutral, > are opposed to Jefsey's provisos. > > Consequently, I think there is a consensus to reject Jefsey's provisos. > > On the basic question, there is now a slim majority in favor of rejecting > the > proposal, but I'm not willing to call it a consensus one way or the other > until others on the list speak up or someone changes their mind. > > Randy > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 16:47:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09455; Tue, 12 Apr 2005 16:47:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLSSA-00070u-Rk; Tue, 12 Apr 2005 16:57:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRzS-0003J9-5J; Tue, 12 Apr 2005 16:28:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRCi-0003cI-Rx for ltru@megatron.ietf.org; Tue, 12 Apr 2005 15:37:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29295 for ; Tue, 12 Apr 2005 15:37:34 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLRME-0003Hm-Ku for ltru@ietf.org; Tue, 12 Apr 2005 15:47:34 -0400 Received: from lns-p19-1-idf-82-251-69-49.adsl.proxad.net ([82.251.69.49] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLRCO-0000qO-ME for ltru@ietf.org; Tue, 12 Apr 2005 12:37:25 -0700 Message-Id: <6.1.2.0.2.20050412211214.05566960@pop.online.fr> X-Sender: jefsey@pop.online.fr X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 21:36:50 +0200 To: "ltru Working Group" From: Jefsey Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - online.fr X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Tue, 12 Apr 2005 16:28:05 -0400 Subject: [Ltru] IANA update trough RFC X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 from a recent qui pro quo with Michael Everson resulted in an idea which may have some worth. I suggested Michael to come in here to jointly support the idea, also with his experience. I regret he refused because I think the idea interesting. We are discussing of first version of the "registry" to be loaded by the IANA and we experiment delays up to 6 months by the IANA. We also need to find a dissemination way which does not drain to much on the Internet public common resources. We have not discussed some of the Charter questions the idea, IMHO, could make easier to address. The idea use the present IETF WG and to transfer it under the Chairmanship of Michael (IESG assigned reviewer(s)) once the RFC published. - the WG-LTRU would be permanent - it would issue a yearly RFC which would be the language registry (the format to discuss) - this RFC would follow a Draft which would be updated every month by the WG. - the reference to the RFC would give the yearly reference. - the standard IETF (AD, Chairs, Charter, Last Calls,etc) Internet standard process would apply. A Draft is valid for 6 months. Drafts have a well established track. This would both match the IANA delay (6 months) and is acceptable as a normative document because this is a BCP (which describes a de facto practice). This would leave full control of the IESG over the evolution of the registry through the yearly review of the WG Charter and would permit to keep the format updated to the various applications demands. It would permit a permanent cooperation with other Application Area propositions/WGs (like OPES). The interest is also that an RFC includes the Security, IANA, etc consideration parts, permitting to easily document/maintain these aspects and is covered by the ISOC/IETF Intellectual Property Rights. Another advantage is that this would make langtags a standard IETF process without special procedures. The Internet standard process considers the case of lack of network expertise in a specialized WG and the assistance to provide to its Chairs. The load on IANA should be very reduced, due to the permitted stability of the RFC process, numerous replication servers, habit of developers, etc. This would certainly encourage the proposition of value added services on top of the yearly RFC/Draft publication. The addition of language names in different languages could then easily result from additional BPC. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 16:57:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10490; Tue, 12 Apr 2005 16:57:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLSbk-0007Rs-3Q; Tue, 12 Apr 2005 17:07:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRQi-0004Z1-KH; Tue, 12 Apr 2005 15:52:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLRQh-0004Yo-RL for ltru@megatron.ietf.org; Tue, 12 Apr 2005 15:52:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00416 for ; Tue, 12 Apr 2005 15:52:01 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLRaD-0003qR-Ad for ltru@ietf.org; Tue, 12 Apr 2005 16:02:01 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3CJpn5b083058 for ; Tue, 12 Apr 2005 15:51:49 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3CJpn1K265892 for ; Tue, 12 Apr 2005 13:51:49 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3CJpniw029731 for ; Tue, 12 Apr 2005 13:51:49 -0600 Received: from markdavis (sig-9-48-117-111.mts.ibm.com [9.48.117.111]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3CJpmBB029691 for ; Tue, 12 Apr 2005 13:51:48 -0600 Message-ID: <01f501c53f99$10245590$ab703009@sanjose.ibm.com> From: "Mark Davis" To: "LTRU Working Group" Date: Tue, 12 Apr 2005 12:51:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id j3CJpn5b083058 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Subject: [Ltru] Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Coming back to this subject after being gone for a week, it appears to me that there is only one really substantial issue remaining, and that is th= e issue of what to do with the script. We have gone back and forth with thi= s issue, but it appears like we are spinning our wheels a bit. Addison and = I discussed this, and here's what we propose: 1. We add one field to the language records: Associated_Script: This field is optional; if present, it will occur 2 or more times. This field is used to indicate languages commonly written in two or more scrip= ts. Languages that have this field SHOULD use a script subtag. Other language= s SHOULD NOT use a script subtag unless it adds some useful information (fo= r example, the Brai subtag for a Braille text) or in the context of certain types of matching operations. It is expected that it would be populated over time, with the registratio= n process. We add this to the registration form, so that associated scripts can be added. We can put in values for the high-runner cases, since those are well-known. For example: %% Type: lang Subtag: sr Description: Serbian Associated_Script: Cyrl Associated_Script: Latn %% We describe (informatively) in the LT doc that these fields can be useful= in matching, and note that in many kinds of matching the script code should = be omitted to maximize compatibility unless there is more than one associated-script value present. We leave any further text to be worked o= ut in the matching document, since that is the scope of that document, and beyond the scope of the LT document. 2. We leave the script in the current position, since it follows the "most-significant-field-first" rule. While there may be cases where curre= nt implementations won't find the region code where one exists, they will be= no worse off than if there is no region code at all. And with #1, this will = be few cases. We have to have script; that is one of the main reasons for 3066bis. 3. We arrange for a telecon either at the end of this week or the first p= art of next week. We can have a common room for people in the S. San Francisc= o area to meet in person, and others can call in. By having an "in person" meeting, I think we might be able to make more progress than we seem to b= e doing in email. =E2=80=8EMark _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 17:08:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11554; Tue, 12 Apr 2005 17:08:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLSlv-0007up-RJ; Tue, 12 Apr 2005 17:18:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLSUr-0007hp-I9; Tue, 12 Apr 2005 17:00:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLSUq-0007hB-VL for ltru@megatron.ietf.org; Tue, 12 Apr 2005 17:00:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11045 for ; Tue, 12 Apr 2005 17:00:22 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLSeM-0007eb-H1 for ltru@ietf.org; Tue, 12 Apr 2005 17:10:23 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 14:00:14 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Tue, 12 Apr 2005 14:00:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Moving Forward Date: Tue, 12 Apr 2005 14:00:13 -0700 Message-ID: Thread-Topic: [Ltru] Moving Forward Thread-Index: AcU/n/+wrwy2R2O8SPu6I4WVkDH9iwAAiT3A From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 12 Apr 2005 21:00:14.0436 (UTC) FILETIME=[9F928A40:01C53FA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Mark Davis > Coming back to this subject after being gone for a week, it appears to me > that there is only one really substantial issue remaining, and that is the > issue of what to do with the script. We have gone back and forth with this > issue, but it appears like we are spinning our wheels a bit. Addison and I > discussed this, and here's what we propose: >=20 > 1. We add one field to the language records: >=20 > Associated_Script: ... > 2. We leave the script in the current position... I think this is a good solution to the concerns raised. I would suggest one minor change: since this field is to be populated only when there are two or more scripts commonly used, change the label for this field to "Associated_Scripts". Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 17:27:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13440; Tue, 12 Apr 2005 17:27:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLT4c-0000Ck-Mm; Tue, 12 Apr 2005 17:37:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLSjD-0001DN-5Q; Tue, 12 Apr 2005 17:15:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLSjC-0001DD-Ge for ltru@megatron.ietf.org; Tue, 12 Apr 2005 17:15:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12418 for ; Tue, 12 Apr 2005 17:15:19 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLSsr-0008DK-3T for ltru@ietf.org; Tue, 12 Apr 2005 17:25:21 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3CLFBf4002165; Tue, 12 Apr 2005 14:15:11 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AG9P0>; Tue, 12 Apr 2005 14:15:12 -0700 Message-ID: From: "McDonald, Ira" To: "'Randy Presuhn'" , LTRU Working Group Subject: RE: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt Date: Tue, 12 Apr 2005 14:15:05 -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: 2086112c730e13d5955355df27e3074b X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Hi, In light of recent threads here on script, a question. Are the RFC3066bis editors confident that 'Content-Script' will not be approved/adopted into HTTP/1.x and MIME headers? Because _two_ methods in wide use for tagging script in the same content is a good deal worse than none, IMHO. Frankly, Bruce Lilly's rationale for the separation looks sound to me. Script is intimately related to charset and merely usefully related to language. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Randy Presuhn > Sent: Friday, April 08, 2005 7:07 PM > To: LTRU Working Group > Subject: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt > > > Hi - > > I believe this may be of interest to many members of the ltru WG. > > Randy > > > From: > > To: > > Sent: Friday, April 08, 2005 7:25 AM > > Subject: I-D ACTION:draft-lilly-content-script-01.txt > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > > > Title : Indicating and Negotiating Text Script > > Author(s) : B. Lilly > > Filename : draft-lilly-content-script-01.txt > > Pages : 14 > > Date : 2005-4-7 > > > > Some written text in some languages can be represented in multiple > > scripts, or writing forms. This memo proposes mechanisms for > > identification and negotiation of script for written text. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in > the body of the message. > > You can also visit > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-lilly-content-script-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-lilly-content-script-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > -------------------------------------------------------------- > ------------------ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 17:29:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13594; Tue, 12 Apr 2005 17:29:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLT6c-0000HJ-Bs; Tue, 12 Apr 2005 17:39:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLSia-000177-OR; Tue, 12 Apr 2005 17:14:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLSiZ-00015h-5d for ltru@megatron.ietf.org; Tue, 12 Apr 2005 17:14:43 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12273 for ; Tue, 12 Apr 2005 17:14:31 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLScM-0006fu-D0 for ltru@lists.ietf.org; Tue, 12 Apr 2005 23:08:18 +0200 Received: from c-134-92-247.hh.dial.de.ignite.net ([62.134.92.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 23:08:18 +0200 Received: from nobody by c-134-92-247.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Apr 2005 23:08:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 12 Apr 2005 23:08:31 +0200 Organization: Lines: 19 Message-ID: <425C38CF.354E@xyzzy.claranet.de> References: <6.1.2.0.2.20050412211214.05566960@pop.online.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: c-134-92-247.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: IANA update trough RFC X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Jefsey Morfin wrote: > we experiment delays up to 6 months by the IANA IANA just updated its pages, so this special "date B" jumped from 2003-07-09 to 2005-04-12. The new tags: be-Latn http://www.iana.org/assignments/lang-tags/be-Latn bs-Cyrl http://www.iana.org/assignments/lang-tags/bs-Cyrl bs-Latn http://www.iana.org/assignments/lang-tags/bs-Latn iu-Cans http://www.iana.org/assignments/lang-tags/iu-Cans iu-Latn http://www.iana.org/assignments/lang-tags/iu-Latn mn-Cyrl http://www.iana.org/assignments/lang-tags/mn-Cyrl mn-Mong http://www.iana.org/assignments/lang-tags/mn-Mong tg-Arab http://www.iana.org/assignments/lang-tags/tg-Arab tg-Cyrl http://www.iana.org/assignments/lang-tags/tg-Cyrl Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 17:32:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13702; Tue, 12 Apr 2005 17:32:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLT9M-0000Jv-TB; Tue, 12 Apr 2005 17:42:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLSu9-0002Uc-O9; Tue, 12 Apr 2005 17:26:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLSu8-0002NV-51 for ltru@megatron.ietf.org; Tue, 12 Apr 2005 17:26:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13368 for ; Tue, 12 Apr 2005 17:26:23 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLT3Z-00009N-8I for ltru@ietf.org; Tue, 12 Apr 2005 17:36:25 -0400 Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLStr-0000Ov-00 for ltru@ietf.org; Tue, 12 Apr 2005 14:26:23 -0700 Message-ID: <003001c53fa6$7964d720$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <01f501c53f99$10245590$ab703009@sanjose.ibm.com> Subject: Re: [Ltru] Moving Forward Date: Tue, 12 Apr 2005 14:27:47 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Hi - > From: "Mark Davis" > To: "LTRU Working Group" > Sent: Tuesday, April 12, 2005 12:51 PM > Subject: [Ltru] Moving Forward > > Coming back to this subject after being gone for a week, it appears to me > that there is only one really substantial issue remaining, and that is the > issue of what to do with the script. We have gone back and forth with this > issue, but it appears like we are spinning our wheels a bit. Addison and I > discussed this, and here's what we propose: > > 1. We add one field to the language records: > > Associated_Script: > > This field is optional; if present, it will occur 2 or more times. This > field is used to indicate languages commonly written in two or more scripts. > Languages that have this field SHOULD use a script subtag. Other languages > SHOULD NOT use a script subtag unless it adds some useful information (for > example, the Brai subtag for a Braille text) or in the context of certain > types of matching operations. > > It is expected that it would be populated over time, with the registration > process. We add this to the registration form, so that associated scripts > can be added. We can put in values for the high-runner cases, since those > are well-known. For example: > > %% > Type: lang > Subtag: sr > Description: Serbian > Associated_Script: Cyrl > Associated_Script: Latn > %% > > We describe (informatively) in the LT doc that these fields can be useful in > matching, and note that in many kinds of matching the script code should be > omitted to maximize compatibility unless there is more than one > associated-script value present. We leave any further text to be worked out > in the matching document, since that is the scope of that document, and > beyond the scope of the LT document. Technical question: how do you envision the entries for languages like Vietnamese, which within relatively recent history have had multiple scripts, but which currently are written (exclusively, AFAIK) in a single script? > 2. We leave the script in the current position, since it follows the > "most-significant-field-first" rule. While there may be cases where current > implementations won't find the region code where one exists, they will be no > worse off than if there is no region code at all. And with #1, this will be > few cases. We have to have script; that is one of the main reasons for > 3066bis. > > 3. We arrange for a telecon either at the end of this week or the first part > of next week. We can have a common room for people in the S. San Francisco > area to meet in person, and others can call in. By having an "in person" > meeting, I think we might be able to make more progress than we seem to be > doing in email. I appreciate the spirit in which this is offered, and think that something like this would be helpful. However, as a co-chair, I remind you that we're subject to RFC 2418 section 3.1, which says: All working group actions shall be taken in a public forum, and wide participation is encouraged. A working group will conduct much of its business via electronic mail distribution lists but may meet periodically to discuss and review task status and progress, to resolve specific issues and to direct future activities. IETF Plenary meetings are the primary venue for these face-to-face working group sessions, and it is common (though not required) that active "interim" face-to-face meetings, telephone conferences, or video conferences may also be held. Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings. For the IESG's interpretation of this, see http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt It's fine for self-selected "design teams" to attempt to develop a consensus view off-list, though any proposals brought forth on the WG mailing list by the members of such a design team are still subject to discussion and normal rough consensus decision-making on the WG mailing list. It's good to announce such gatherings on-list; just don't advertise them as official WG Interims. Also, since this WG is fairly small, the following will apply: "Detailed minutes are required to be taken and submitted and a list of attendees must also be submitted. This applies to all in-person meetings to which a large part of the working group is invited, even if labeled as 'informal' to distinguish them from 'real' working group meetings." (from the IESG statement) For an official WG Interim meeting, we need AD approval, a posted agenda, and one month advance notice.. If members of the WG think an official interim meeting in mid-May would be helpful (or not) please post your views, and whether you'd be able to host, physically attend, or attend electronically. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 17:45:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15274; Tue, 12 Apr 2005 17:45:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTM8-0000xd-QS; Tue, 12 Apr 2005 17:55:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLTBc-0005wR-Q9; Tue, 12 Apr 2005 17:44:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLTBc-0005vM-1S for ltru@megatron.ietf.org; Tue, 12 Apr 2005 17:44:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15227 for ; Tue, 12 Apr 2005 17:44:33 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTL8-0000uX-82 for ltru@ietf.org; Tue, 12 Apr 2005 17:54:35 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3CLiLLg284326 for ; Tue, 12 Apr 2005 17:44:21 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3CLiL1K255174 for ; Tue, 12 Apr 2005 15:44:21 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3CLiKPG005228 for ; Tue, 12 Apr 2005 15:44:20 -0600 Received: from markdavis (sig-9-48-117-111.mts.ibm.com [9.48.117.111]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3CLiJJ6005181; Tue, 12 Apr 2005 15:44:20 -0600 Message-ID: <027701c53fa8$c85c3970$ab703009@sanjose.ibm.com> From: "Mark Davis" To: "McDonald, Ira" , "'Randy Presuhn'" , "LTRU Working Group" References: Subject: Re: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt Date: Tue, 12 Apr 2005 14:44:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j3CLiLLg284326 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: quoted-printable Well, script is necessary in language tags to distinguish the written for= ms of languages; and language tags are much broader in scope. Script is intimately related to the written form of language, and script = is only very remotely related to legacy charsets: a) Legacy charsets in very few cases contain all the characters in a scri= pt b) Legacy charsets often contain characters from multiple scripts (look a= t JIS, GBK, etc). c) And legacy charsets are in the process of being superceded by Unicode = / 10646 in any event. Having scripts cited in parallel, in some circumstances, to language tags= is a bad idea. =E2=80=8EMark ----- Original Message -----=20 From: "McDonald, Ira" To: "'Randy Presuhn'" ; "LTRU Working Group= " Sent: Tuesday, April 12, 2005 14:15 Subject: RE: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt > Hi, > > In light of recent threads here on script, a question. > > Are the RFC3066bis editors confident that 'Content-Script' > will not be approved/adopted into HTTP/1.x and MIME headers? > > Because _two_ methods in wide use for tagging script in the > same content is a good deal worse than none, IMHO. > > Frankly, Bruce Lilly's rationale for the separation looks sound > to me. Script is intimately related to charset and merely usefully > related to language. > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of Randy Presuhn > > Sent: Friday, April 08, 2005 7:07 PM > > To: LTRU Working Group > > Subject: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt > > > > > > Hi - > > > > I believe this may be of interest to many members of the ltru WG. > > > > Randy > > > > > From: > > > To: > > > Sent: Friday, April 08, 2005 7:25 AM > > > Subject: I-D ACTION:draft-lilly-content-script-01.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > > > > Title : Indicating and Negotiating Text Script > > > Author(s) : B. Lilly > > > Filename : draft-lilly-content-script-01.txt > > > Pages : 14 > > > Date : 2005-4-7 > > > > > > Some written text in some languages can be represented in multiple > > > scripts, or writing forms. This memo proposes mechanisms for > > > identification and negotiation of script for written text. > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt > > > > > > To remove yourself from the I-D Announcement list, send a message t= o > > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of the message. > > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > > "anonymous" and a password of your e-mail address. After logging in= , > > > type "cd internet-drafts" and then > > > "get draft-lilly-content-script-01.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE /internet-drafts/draft-lilly-content-script-01.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant mail reader= s > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > > > > -------------------------------------------------------------- > > ------------------ > > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 18:08:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17229; Tue, 12 Apr 2005 18:08:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTil-0001gd-Ei; Tue, 12 Apr 2005 18:19:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLTUK-0001Qm-UA; Tue, 12 Apr 2005 18:04:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLTUI-0001Q1-Ri for ltru@megatron.ietf.org; Tue, 12 Apr 2005 18:04:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16490 for ; Tue, 12 Apr 2005 18:03:51 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTdo-0001X0-QE for ltru@ietf.org; Tue, 12 Apr 2005 18:13:54 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 15:03:43 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Tue, 12 Apr 2005 15:03:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Fw: I-D ACTION:draft-lilly-content-script-01.txt Date: Tue, 12 Apr 2005 15:03:43 -0700 Message-ID: Thread-Topic: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt Thread-Index: AcU/puep0PUWX4jKTzOmBVoR6AcSeAABBL5Q From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 12 Apr 2005 22:03:44.0210 (UTC) FILETIME=[7E5FEB20:01C53FAB] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > McDonald, Ira > Frankly, Bruce Lilly's rationale for the separation looks sound > to me. Script is intimately related to charset and merely usefully > related to language. Frankly, Bruce's proposal is IMO inadequate for many scenarios and for other scenarios very problematic. Issues have been identified in recent posts by Addison, by Ned and by me. IMO, 'Content-Script' should not be approved. Peter _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 18:12:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17598; Tue, 12 Apr 2005 18:12:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTlp-0001l7-Me; Tue, 12 Apr 2005 18:22:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLTTO-0001NH-KK; Tue, 12 Apr 2005 18:03:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLTTM-0001JD-Nt for ltru@megatron.ietf.org; Tue, 12 Apr 2005 18:03:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16382 for ; Tue, 12 Apr 2005 18:02:56 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTcr-0001W8-TK for ltru@ietf.org; Tue, 12 Apr 2005 18:12:59 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3CM2a4I326154 for ; Tue, 12 Apr 2005 18:02:36 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3CM2a5a230074 for ; Tue, 12 Apr 2005 16:02:36 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3CM2a99005263 for ; Tue, 12 Apr 2005 16:02:36 -0600 Received: from markdavis (sig-9-48-117-111.mts.ibm.com [9.48.117.111]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3CM2Ynb005200; Tue, 12 Apr 2005 16:02:35 -0600 Message-ID: <031901c53fab$5548d080$ab703009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" , "Martin Duerst" References: <01f501c53f99$10245590$ab703009@sanjose.ibm.com> <003001c53fa6$7964d720$7f1afea9@oemcomputer> Subject: Re: [Ltru] Moving Forward Date: Tue, 12 Apr 2005 15:02:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j3CM2a4I326154 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Content-Transfer-Encoding: quoted-printable Thanks for outlining this. I'm not proposing an official meeting, just an informal discussion. But we can keep notes and minutes as per your description below. > It's fine for self-selected "design teams" to attempt to develop a consensus view > off-list, though any proposals brought forth on the WG mailing list > by the members of such a design team are still subject to discussion an= d > normal rough consensus decision-making on the WG mailing list. It's go= od to > announce such gatherings on-list; just don't advertise them as official= WG Interims. > Also, since this WG is fairly small, the following will apply: "Detaile= d minutes are > required to be taken and submitted and a list of attendees must also be submitted. > This applies to all in-person meetings to which a large part of the working group is > invited, even if labeled as 'informal' to distinguish them from 'real' > working group meetings." (from the IESG statement) You also comment: > If members of the WG think an official interim meeting in mid-May would= be helpful > (or not) please post your views, and whether you'd be able to host, physically attend, > or attend electronically. That may be useful, for further discussion once the draft is out; however= , the goal as per the charter is to have a draft ready by May 5. I am still hopeful that that date can be achieved. If it cannot be, that calls into question the ability of this group to make progress towards a successful RFC. > Technical question: how do you envision the entries for languages like Vietnamese, > which within relatively recent history have had multiple scripts, but which currently > are written (exclusively, AFAIK) in a single script? The main goal would be current modern usage. And there would be no prohibition against including other explicit scripts for other types of matching. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Tuesday, April 12, 2005 14:27 Subject: Re: [Ltru] Moving Forward > Hi - > > > From: "Mark Davis" > > To: "LTRU Working Group" > > Sent: Tuesday, April 12, 2005 12:51 PM > > Subject: [Ltru] Moving Forward > > > > > Coming back to this subject after being gone for a week, it appears t= o me > > that there is only one really substantial issue remaining, and that i= s the > > issue of what to do with the script. We have gone back and forth with this > > issue, but it appears like we are spinning our wheels a bit. Addison = and I > > discussed this, and here's what we propose: > > > > 1. We add one field to the language records: > > > > Associated_Script: > > > > This field is optional; if present, it will occur 2 or more times. Th= is > > field is used to indicate languages commonly written in two or more scripts. > > Languages that have this field SHOULD use a script subtag. Other languages > > SHOULD NOT use a script subtag unless it adds some useful information (for > > example, the Brai subtag for a Braille text) or in the context of certain > > types of matching operations. > > > > It is expected that it would be populated over time, with the registration > > process. We add this to the registration form, so that associated scripts > > can be added. We can put in values for the high-runner cases, since those > > are well-known. For example: > > > > %% > > Type: lang > > Subtag: sr > > Description: Serbian > > Associated_Script: Cyrl > > Associated_Script: Latn > > %% > > > > We describe (informatively) in the LT doc that these fields can be useful in > > matching, and note that in many kinds of matching the script code sho= uld be > > omitted to maximize compatibility unless there is more than one > > associated-script value present. We leave any further text to be work= ed out > > in the matching document, since that is the scope of that document, a= nd > > beyond the scope of the LT document. > > Technical question: how do you envision the entries for languages like Vietnamese, > which within relatively recent history have had multiple scripts, but which currently > are written (exclusively, AFAIK) in a single script? > > > 2. We leave the script in the current position, since it follows the > > "most-significant-field-first" rule. While there may be cases where current > > implementations won't find the region code where one exists, they wil= l be no > > worse off than if there is no region code at all. And with #1, this w= ill be > > few cases. We have to have script; that is one of the main reasons fo= r > > 3066bis. > > > > 3. We arrange for a telecon either at the end of this week or the fir= st part > > of next week. We can have a common room for people in the S. San Francisco > > area to meet in person, and others can call in. By having an "in pers= on" > > meeting, I think we might be able to make more progress than we seem = to be > > doing in email. > > I appreciate the spirit in which this is offered, and think that someth= ing like this would > be helpful. However, as a co-chair, I remind you that we're subject to RFC 2418 > section 3.1, which says: > > All working group actions shall be taken in a public forum, and wide > participation is encouraged. A working group will conduct much of it= s > business via electronic mail distribution lists but may meet > periodically to discuss and review task status and progress, to > resolve specific issues and to direct future activities. IETF > Plenary meetings are the primary venue for these face-to-face workin= g > group sessions, and it is common (though not required) that active > "interim" face-to-face meetings, telephone conferences, or video > conferences may also be held. Interim meetings are subject to the > same rules for advance notification, reporting, open participation, > and process, which apply to other working group meetings. > > For the IESG's interpretation of this, see > http://www.ietf.org/IESG/STATEMENTS/Interim-meetings.txt > > It's fine for self-selected "design teams" to attempt to develop a consensus view > off-list, though any proposals brought forth on the WG mailing list > by the members of such a design team are still subject to discussion an= d > normal rough consensus decision-making on the WG mailing list. It's go= od to > announce such gatherings on-list; just don't advertise them as official= WG Interims. > Also, since this WG is fairly small, the following will apply: "Detaile= d minutes are > required to be taken and submitted and a list of attendees must also be submitted. > This applies to all in-person meetings to which a large part of the working group is > invited, even if labeled as 'informal' to distinguish them from 'real' > working group meetings." (from the IESG statement) > > For an official WG Interim meeting, we need AD approval, a posted agend= a, > and one month advance notice.. > > If members of the WG think an official interim meeting in mid-May would= be helpful > (or not) please post your views, and whether you'd be able to host, physically attend, > or attend electronically. > > Randy > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 18:13:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17797; Tue, 12 Apr 2005 18:13:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTnW-0001mt-NC; Tue, 12 Apr 2005 18:23:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLTcu-0002It-Kl; Tue, 12 Apr 2005 18:12:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLTct-0002Hv-Do for ltru@megatron.ietf.org; Tue, 12 Apr 2005 18:12:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17659 for ; Tue, 12 Apr 2005 18:12:44 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTmQ-0001lT-Es for ltru@ietf.org; Tue, 12 Apr 2005 18:22:46 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 15:12:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Fw: I-D ACTION:draft-lilly-content-script-01.txt Date: Tue, 12 Apr 2005 15:12:34 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA4486@irvmbxw01.quest.com> Thread-Topic: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt Thread-Index: AcU/pt2f6nEMyKPBRfeV2HWsBrGVQQABZO+Q From: "Addison Phillips" To: "McDonald, Ira" , "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 12 Apr 2005 22:12:34.0647 (UTC) FILETIME=[BA8A2E70:01C53FAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Script is not useful if the charset is UTF-8 (for example). It is quite = useful in certain cases with language. I don't care if Content-Script is accepted or not. I suspect that no one = will ever use it. And it does no good outside of the Internet protocol = realm (as in an XML document, for example). Is there a reason not to include script *anywhere* in a language tag? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of McDonald, Ira > Sent: mardi 12 avril 2005 14:15 > To: 'Randy Presuhn'; LTRU Working Group > Subject: RE: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt >=20 > Hi, >=20 > In light of recent threads here on script, a question. >=20 > Are the RFC3066bis editors confident that 'Content-Script' > will not be approved/adopted into HTTP/1.x and MIME headers? >=20 > Because _two_ methods in wide use for tagging script in the > same content is a good deal worse than none, IMHO. >=20 > Frankly, Bruce Lilly's rationale for the separation looks sound > to me. Script is intimately related to charset and merely usefully > related to language. >=20 > Cheers, > - Ira >=20 > 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 >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of Randy Presuhn > > Sent: Friday, April 08, 2005 7:07 PM > > To: LTRU Working Group > > Subject: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt > > > > > > Hi - > > > > I believe this may be of interest to many members of the ltru WG. > > > > Randy > > > > > From: > > > To: > > > Sent: Friday, April 08, 2005 7:25 AM > > > Subject: I-D ACTION:draft-lilly-content-script-01.txt > > > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > > > > > > > > Title : Indicating and Negotiating Text Script > > > Author(s) : B. Lilly > > > Filename : draft-lilly-content-script-01.txt > > > Pages : 14 > > > Date : 2005-4-7 > > > > > > Some written text in some languages can be represented in multiple > > > scripts, or writing forms. This memo proposes mechanisms for > > > identification and negotiation of script for written text. > > > > > > A URL for this Internet-Draft is: > > > > > = http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt > > > > > > To remove yourself from the I-D Announcement list, send a message = to > > > i-d-announce-request@ietf.org with the word unsubscribe in > > the body of the message. > > > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > > to change your subscription settings. > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > > "anonymous" and a password of your e-mail address. After logging = in, > > > type "cd internet-drafts" and then > > > "get draft-lilly-content-script-01.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE /internet-drafts/draft-lilly-content-script-01.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant mail = readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > > > > -------------------------------------------------------------- > > ------------------ > > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > > > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 18:44:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20513; Tue, 12 Apr 2005 18:44:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLUHX-0002i9-6e; Tue, 12 Apr 2005 18:54:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLU3I-0006XQ-Fs; Tue, 12 Apr 2005 18:40:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLU3H-0006Vf-Pm for ltru@megatron.ietf.org; Tue, 12 Apr 2005 18:40:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20196 for ; Tue, 12 Apr 2005 18:40:03 -0400 (EDT) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLUCr-0002aO-8z for ltru@ietf.org; Tue, 12 Apr 2005 18:50:06 -0400 Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLU39-0003Ow-00 for ltru@ietf.org; Tue, 12 Apr 2005 15:40:03 -0700 Message-ID: <000e01c53fb0$c4ea2380$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0AFA4486@irvmbxw01.quest.com> Subject: Re: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt Date: Tue, 12 Apr 2005 15:41:14 -0700 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: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi - > From: "Addison Phillips" > To: "McDonald, Ira" ; "Randy Presuhn" ; "LTRU Working Group" > Sent: Tuesday, April 12, 2005 3:12 PM > Subject: RE: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt > > Script is not useful if the charset is UTF-8 (for example). It is quite useful in certain cases with language. ... I don't understand this comment. I don't see how the use of UTF-8 changes anything regarding the utility of script tags. Perhaps I'm reading too much into the proposal, but I thought the heart of the idea was while that a script is not an intrinsic property of a language, it is useful, in conjunction with language, in marking and selecting content. The question is whether it's better to represent these two pieces of information in a single tag or two tags, with the arguments pro and con being about interpretation of legacy data, tagging of new data, behavior of legacy applications, impact on existing standards which don't already provide for this kind of tagging, and evisioned future uses. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 19:11:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22523; Tue, 12 Apr 2005 19:11:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLUhF-0003Vq-2r; Tue, 12 Apr 2005 19:21:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLUUY-0002fg-VT; Tue, 12 Apr 2005 19:08:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLUUX-0002Vs-4S for ltru@megatron.ietf.org; Tue, 12 Apr 2005 19:08:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22337 for ; Tue, 12 Apr 2005 19:07:34 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLUdV-0003Qa-GY for ltru@ietf.org; Tue, 12 Apr 2005 19:17:37 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 16:07:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Fw: I-D ACTION:draft-lilly-content-script-01.txt Date: Tue, 12 Apr 2005 16:07:27 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA44A5@irvmbxw01.quest.com> Thread-Topic: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt Thread-Index: AcU/sQ85CmYKfcaOSOaI0Ts2jTGedAAAFcHw From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 12 Apr 2005 23:07:28.0053 (UTC) FILETIME=[65900E50:01C53FB4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable My response probably wasn't that clear. Script is not intimately related to charset in a number of interesting = cases. Such as Unicode cases. Adoption of Unicode character encodings = does increase the need to identify script (since the charset attribute = cannot be a surrogate for it).=20 Script *is* related to language identification in cases where a specific = "language" can be written in more than one script. Simplified vs. = Traditional Chinese, for example. This is only "two pieces of information" if you actually want to select = script separately (orthogonally) from language. What are the use cases = for this? When do you select text in 'Hant' in which you don't care = about the language? Conversely, when do you render text in (say) 'Latn' = but the individual language is not also important. Users needing to identify different attributes of text (script, = language, orthography, etc....) will have to separately identify each of = these attributes in conjunctions with one another. This greatly = increases the complexity of what should be a simple task. Legacy data formats cannot represent a separate attribute without being = modified. Legacy data must be retagged under the 3066bis design, of = course, to obtain the benefits of the new design. But this can be done = incrementally and only in cases where the script is actually a = differentiator.=20 Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: mardi 12 avril 2005 15:41 > To: LTRU Working Group > Subject: Re: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "McDonald, Ira" ; "Randy Presuhn" > ; "LTRU Working Group" > > > Sent: Tuesday, April 12, 2005 3:12 PM > > Subject: RE: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt > > >=20 > > Script is not useful if the charset is UTF-8 (for example). It is = quite > useful in certain cases with language. > ... >=20 > I don't understand this comment. I don't see > how the use of UTF-8 changes anything regarding the utility > of script tags. >=20 > Perhaps I'm reading too much into the proposal, but I thought > the heart of the idea was while that a script is not an intrinsic = property > of a language, it is useful, in conjunction with language, in marking = and > selecting content. The question is whether it's better to represent = these > two pieces of information in a single tag or two tags, with the = arguments > pro and con being about interpretation of legacy data, tagging of new = data, > behavior of legacy applications, impact on existing standards which = don't > already provide for this kind of tagging, and evisioned future uses. >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 19:16:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23095; Tue, 12 Apr 2005 19:16:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLUmT-0003gA-QN; Tue, 12 Apr 2005 19:26:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLUVU-0002jr-EZ; Tue, 12 Apr 2005 19:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLUVT-0002j4-GQ for ltru@megatron.ietf.org; Tue, 12 Apr 2005 19:09:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22389 for ; Tue, 12 Apr 2005 19:09:08 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLUey-0003T1-7s for ltru@ietf.org; Tue, 12 Apr 2005 19:19:11 -0400 Received: from lns-p19-1-idf-82-251-69-49.adsl.proxad.net ([82.251.69.49] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLUVG-0008W0-FB; Tue, 12 Apr 2005 16:09:06 -0700 Message-Id: <6.1.2.0.2.20050412234427.055ed070@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 23:58:22 +0200 To: "McDonald, Ira" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On 23:15 12/04/2005, McDonald, Ira said: >Frankly, Bruce Lilly's rationale for the separation looks sound to >me. Script is intimately related to charset and merely usefully related >to language. de facto script extend to much more. For example the need to support Greek characters is a must for math and scientific communities. There are the need to specify adapted scripts independently from the language. I know IDNs are banned, but we nevertheless need their Tables. A stupid question I have however is why (except for aged applications and for information) do we need scripts for applications? They are made of Unicode codes. Either the character is available or it is not? When is not a language side information or an independent information, used for different decisions (for choice and not for presentation). It seems reasonable to manage it separately, so we can use at a different times. Now, Addison may say this is a big problem for his XML. So what prevents to include it also in his XML lang3tag? As long as it can also be supported independently. I am always puzzled when one wants to hidde parameters and madatorily bundle them. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 19:18:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23275; Tue, 12 Apr 2005 19:18:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLUo1-0003jL-61; Tue, 12 Apr 2005 19:28:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLUVU-0002jn-AM; Tue, 12 Apr 2005 19:09:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLUVT-0002j3-ES for ltru@megatron.ietf.org; Tue, 12 Apr 2005 19:09:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22386 for ; Tue, 12 Apr 2005 19:09:07 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLUez-0003T4-0l for ltru@ietf.org; Tue, 12 Apr 2005 19:19:11 -0400 Received: from lns-p19-1-idf-82-251-69-49.adsl.proxad.net ([82.251.69.49] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLUVH-0008W0-J1; Tue, 12 Apr 2005 16:09:08 -0700 Message-Id: <6.1.2.0.2.20050413000436.055de640@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 13 Apr 2005 00:11:42 +0200 To: "Randy Presuhn" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Moving Forward In-Reply-To: <003001c53fa6$7964d720$7f1afea9@oemcomputer> References: <01f501c53f99$10245590$ab703009@sanjose.ibm.com> <003001c53fa6$7964d720$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 On 23:27 12/04/2005, Randy Presuhn said: >For an official WG Interim meeting, we need AD approval, a posted agenda, >and one month advance notice.. > >If members of the WG think an official interim meeting in mid-May would be >helpful (or not) please post your views, and whether you'd be able to >host, physically attend, or attend electronically. Before I consider the practicalities: I would be ready to organize a meeting on June 2nd or May 31st in Paris or Versailles (taking advantage from an ISO oriented day, if I am right, some may want to attend) for the participants to this WG. Would there be people interested? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 19:59:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26789; Tue, 12 Apr 2005 19:59:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLVSC-0004ey-VV; Tue, 12 Apr 2005 20:10:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLV8j-0000sl-2B; Tue, 12 Apr 2005 19:49:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLV8i-0000qN-63 for ltru@megatron.ietf.org; Tue, 12 Apr 2005 19:49:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25705 for ; Tue, 12 Apr 2005 19:49:48 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLVIN-0004Pu-Mr for ltru@ietf.org; Tue, 12 Apr 2005 19:59:52 -0400 Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLV8f-00079r-00 for ltru@ietf.org; Tue, 12 Apr 2005 16:49:49 -0700 Message-ID: <000401c53fba$842f81a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0AFA44A5@irvmbxw01.quest.com> Subject: Re: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt Date: Tue, 12 Apr 2005 16:51:15 -0700 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: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Hi - > From: "Addison Phillips" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Tuesday, April 12, 2005 4:07 PM > Subject: RE: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt ... > Script *is* related to language identification in cases where a specific > "language" can be written in more than one script. > Simplified vs. Traditional Chinese, for example. > > This is only "two pieces of information" if you actually want to > select script separately (orthogonally) from language. This depends on how you think about legacy data, legacy applications, and matching. Sometimes the information is absent from the data, sometimes it's absent from the query. How to interpret this absence has been problematic, and it *seems* harder when we try to combine the bits into a single string. Of course, in an information-theoretic sense, there's no difference, but when we speculate about existing data and existing applications dealing with new data, there could be a big difference. I'll be relying on the judgement of application implementors here. > What are the use cases for this? > When do you select text in 'Hant' in which > you don't care about the language? Not terribly useful to me, but I would like requests for Cantonese that did not specify a script to produce Cantonese documents regardless of whether they were marked as traditional, simplified, IPA transcription, or bore no script identifier at all. Some of the alternatives discussed do this with the various combinations of new and legacy apps with new and legacy data, some don't. Likewise, I'd like requests for specific varieties of German language, both in the formulation of the request and the selection of the results, to not be made overly complicated by whether I did (or didn't) care which orthography was in use. > Conversely, when do you render text in (say) 'Latn' > but the individual language is not also important. Rendering is not the problem, as far as I know. > Users needing to identify different attributes of text > (script, language, orthography, etc....) will have to separately > identify each of these attributes in conjunctions with one another. > This greatly increases the complexity of what should be a simple task. I agree, and that's why I'd hardly call myself a strong advocate of this view. It appeals to the linguist and programmer in me, but it does not seem to be aligned with how users view things. > Legacy data formats cannot represent a separate attribute without > being modified. Legacy data must be retagged under the 3066bis design, > of course, to obtain the benefits of the new design. This is what I think we'd all like to avoid or at least minimize, but it may be nothing more than a hope. > But this can be done incrementally and only in cases where the script > is actually a differentiator. ... This is true whether script is encoded as part of the language tag or as a separate field. For me personally the deciding factor will be the question of how well encoding it as a single string will work with existing applications, without hamstringing future ones. That's where the application implementors' perspectives are especially important. If they are convinced they can make it work, I'll be very happy. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 20:29:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29066; Tue, 12 Apr 2005 20:29:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLVup-0005Nw-9T; Tue, 12 Apr 2005 20:39:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLVjk-0003Wz-Cd; Tue, 12 Apr 2005 20:28:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLVjj-0003Wu-AB for ltru@megatron.ietf.org; Tue, 12 Apr 2005 20:28:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29033 for ; Tue, 12 Apr 2005 20:28:05 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLVtO-0005MN-Lf for ltru@ietf.org; Tue, 12 Apr 2005 20:38:07 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 17:27:55 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Tue, 12 Apr 2005 17:27:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Fw: I-D ACTION:draft-lilly-content-script-01.txt Date: Tue, 12 Apr 2005 17:27:55 -0700 Message-ID: Thread-Topic: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt Thread-Index: AcU/u9ziuUpoYRRaTCG45cK3rCUe7gAAtVNw From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 13 Apr 2005 00:27:56.0450 (UTC) FILETIME=[A382F820:01C53FBF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Randy Presuhn > Not terribly useful to me, but I would like requests for Cantonese > that did not specify a script to produce Cantonese documents regardless of > whether they were marked as traditional, simplified, IPA transcription, > or bore no script identifier at all. Some of the alternatives discussed do this > with the various combinations of new and legacy apps with new and legacy > data, some don't. What has been proposed in 3066bis should do this every bit as well as separating script into a separate metadata element.=20 The *only* scenarios in which there is any question about this are if someone were asking for (say) documents in *Taiwan* Mandarin (as opposed to Mandarin as used in PRC, HK, etc.) -- for such cases, we aim to describe new approaches to matching that would always work, but in some existing implementations this request would not match content tagged as (e.g.) zh-Hant-TW. Note, though, that such scenarios are fairly limited in number and commonness. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 21:08:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01467; Tue, 12 Apr 2005 21:08:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLWWR-00066k-Dc; Tue, 12 Apr 2005 21:18:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLWMg-0002vU-Hn; Tue, 12 Apr 2005 21:08:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLWMe-0002t2-Nn for ltru@megatron.ietf.org; Tue, 12 Apr 2005 21:08:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01444 for ; Tue, 12 Apr 2005 21:08:18 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLWWJ-000667-VY for ltru@ietf.org; Tue, 12 Apr 2005 21:18:21 -0400 Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLWMb-0000Ca-00 for ltru@ietf.org; Tue, 12 Apr 2005 18:08:17 -0700 Message-ID: <009e01c53fc5$79a52360$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #890] include character set information in tags Date: Tue, 12 Apr 2005 18:09:24 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi - > From: > Cc: > Sent: Thursday, April 07, 2005 6:21 PM > Subject: [Ltru] Re: [psg.com #890] include character set information in tags > > Hi - > > (co-chair hat ON) > > This Issue was raised in > http://www.ietf.org/mail-archive/web/ltru/current/msg00161.html > > Subsequent discussion revealed no support for the proposal. > Consequently, I plan to mark this one "rejected". > > Randy Ok, I've marked this one "rejected". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 21:11:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01817; Tue, 12 Apr 2005 21:11:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLWZa-0006Ea-3M; Tue, 12 Apr 2005 21:21:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLWPS-0003Ug-T3; Tue, 12 Apr 2005 21:11:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLWPR-0003Te-7k for ltru@megatron.ietf.org; Tue, 12 Apr 2005 21:11:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01684 for ; Tue, 12 Apr 2005 21:11:06 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLWZ2-0006Aw-0E for ltru@ietf.org; Tue, 12 Apr 2005 21:21:09 -0400 Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLWPJ-0000xj-00 for ltru@ietf.org; Tue, 12 Apr 2005 18:11:05 -0700 Message-ID: <00a301c53fc5$de8b3760$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #889] registry should be consistent with ISOlists Date: Tue, 12 Apr 2005 18:12:32 -0700 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: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi - > From: > To: > Cc: > Sent: Thursday, April 07, 2005 6:19 PM > Subject: [Ltru] Re: [psg.com #889] registry should be consistent with ISOlists > > Hi - > > (co-chair hat ON) > > This issue was raised in > http://www.ietf.org/mail-archive/web/ltru/current/msg00094.html > > Coping with changes in the ISO lists is one of the reasons for this work, > as documented in the WG charter. Consequently, I believe we have > little choice but to reject this one, unless I've completely misunderstood > the issue statement. > > Randy Ok, there's been nothing more on this thread, so I've marked this issue "rejected". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 21:20:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02419; Tue, 12 Apr 2005 21:20:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLWiC-0006Qt-LT; Tue, 12 Apr 2005 21:30:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLWVm-0004iB-FS; Tue, 12 Apr 2005 21:17:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLWVk-0004i5-9l for ltru@megatron.ietf.org; Tue, 12 Apr 2005 21:17:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02138 for ; Tue, 12 Apr 2005 21:17:42 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLWfR-0006M1-6U for ltru@ietf.org; Tue, 12 Apr 2005 21:27:45 -0400 Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLWVi-0002aq-00 for ltru@ietf.org; Tue, 12 Apr 2005 18:17:42 -0700 Message-ID: <00b001c53fc6$cac04580$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #883] language tag reviewers should be elected, rather than appointed Date: Tue, 12 Apr 2005 18:19:08 -0700 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: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi - > From: > To: > Cc: > Sent: Thursday, April 07, 2005 2:34 PM > Subject: [Ltru] Re: [psg.com #883] language tag reviewers should be elected,rather than appointed > > Hi - > > (co-chair hat ON) > > In http://www1.ietf.org/mail-archive/web/ltru/current/msg00083.html > it was suggested that language tag reviewers should be elected, rather > than appointed by the IESG. > > I have seen no support for this proposal. Consequently, I suggest that > we change the status of this request to "rejected". If there are objections > to closing this issue in this manner, now is the time to make them heard. > > Randy Since there have been no objections in this thread, I've marked the issue "rejected". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 22:21:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05904; Tue, 12 Apr 2005 22:21:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLXff-0007nc-3z; Tue, 12 Apr 2005 22:32:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLXUx-00014X-OY; Tue, 12 Apr 2005 22:20:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLX4j-0004Ej-Ec for ltru@megatron.ietf.org; Tue, 12 Apr 2005 21:53:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04265 for ; Tue, 12 Apr 2005 21:53:51 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLXEQ-0007At-Gy for ltru@ietf.org; Tue, 12 Apr 2005 22:03:54 -0400 Received: from lns-p19-1-idf-82-251-69-49.adsl.proxad.net ([82.251.69.49] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLRE4-0001vZ-5s for ltru@ietf.org; Tue, 12 Apr 2005 12:39:08 -0700 Message-Id: <6.1.2.0.2.20050412213834.0556d7f0@pop.online.fr> X-Sender: jefsey@pop.online.fr X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Apr 2005 21:38:49 +0200 To: "ltru Working Group" From: Jefsey Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - online.fr X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Tue, 12 Apr 2005 22:20:59 -0400 Subject: [Ltru] IANA update trough RFC X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 from a recent qui pro quo with Michael Everson resulted in an idea which may have some worth. I suggested Michael to come in here to jointly support the idea, also with his experience. I regret he refused because I think the idea interesting. We are discussing of first version of the "registry" to be loaded by the IANA and we experiment delays up to 6 months by the IANA. We also need to find a dissemination way which does not drain to much on the Internet public common resources. We have not discussed some of the Charter questions the idea, IMHO, could make easier to address. The idea use the present IETF WG and to transfer it under the Chairmanship of Michael (IESG assigned reviewer(s)) once the RFC published. - the WG-LTRU would be permanent - it would issue a yearly RFC which would be the language registry (the format to discuss) - this RFC would follow a Draft which would be updated every month by the WG. - the reference to the RFC would give the yearly reference. - the standard IETF (AD, Chairs, Charter, Last Calls,etc) Internet standard process would apply. A Draft is valid for 6 months. Drafts have a well established track. This would both match the IANA delay (6 months) and is acceptable as a normative document because this is a BCP (which describes a de facto practice). This would leave full control of the IESG over the evolution of the registry through the yearly review of the WG Charter and would permit to keep the format updated to the various applications demands. It would permit a permanent cooperation with other Application Area propositions/WGs (like OPES). The interest is also that an RFC includes the Security, IANA, etc consideration parts, permitting to easily document/maintain these aspects and is covered by the ISOC/IETF Intellectual Property Rights. Another advantage is that this would make langtags a standard IETF process without special procedures. The Internet standard process considers the case of lack of network expertise in a specialized WG and the assistance to provide to its Chairs. The load on IANA should be very reduced, due to the permitted stability of the RFC process, numerous replication servers, habit of developers, etc. This would certainly encourage the proposition of value added services on top of the yearly RFC/Draft publication. The addition of language names in different languages could then easily result from additional BPC. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 22:40:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06856; Tue, 12 Apr 2005 22:40:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLXxY-0008Bg-9w; Tue, 12 Apr 2005 22:50:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLXkH-0004CB-Bg; Tue, 12 Apr 2005 22:36:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLXkF-0004At-Qk for ltru@megatron.ietf.org; Tue, 12 Apr 2005 22:36:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06666 for ; Tue, 12 Apr 2005 22:36:29 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLXtg-00087A-Bi for ltru@ietf.org; Tue, 12 Apr 2005 22:46:33 -0400 Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLXjw-0006YX-00 for ltru@ietf.org; Tue, 12 Apr 2005 19:36:28 -0700 Message-ID: <000a01c53fd1$ca11b500$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #887] references to 3066 and 1766 should beinformative Date: Tue, 12 Apr 2005 19:37:51 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi - > From: > Cc: > Sent: Thursday, April 07, 2005 6:13 PM > Subject: [Ltru] Re: [psg.com #887] references to 3066 and 1766 should beinformative > > Hi - > > (co-chair hat ON) > > This issue was raised in > http://www1.ietf.org/mail-archive/web/ltru/current/msg00103.html > > I believe there is a rough Consensus to make the change, to wit, if > any references to 3066 and 1766 remain in the document, they should > be made informative rather than normative. Objections? > > Randy There have been no objections or further discussion on this thread, so I've marked this issue "resolved." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Tue Apr 12 23:20:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11515; Tue, 12 Apr 2005 23:20:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLYaG-0000qp-Mz; Tue, 12 Apr 2005 23:30:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLYMO-0004IA-6e; Tue, 12 Apr 2005 23:16:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLYMN-0004I5-4n for ltru@megatron.ietf.org; Tue, 12 Apr 2005 23:16:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10956 for ; Tue, 12 Apr 2005 23:16:08 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLYW3-0000gG-S3 for ltru@ietf.org; Tue, 12 Apr 2005 23:26:13 -0400 Received: from h-64-105-136-122.snvacaid.dynamic.covad.net ([64.105.136.122] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLYMK-00073E-00 for ltru@ietf.org; Tue, 12 Apr 2005 20:16:08 -0700 Message-ID: <000a01c53fd7$54f09a60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <01f501c53f99$10245590$ab703009@sanjose.ibm.com> <003001c53fa6$7964d720$7f1afea9@oemcomputer> <031901c53fab$5548d080$ab703009@sanjose.ibm.com> Subject: Re: [Ltru] Moving Forward Date: Tue, 12 Apr 2005 20:17:32 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hi - > From: "Mark Davis" > To: "Randy Presuhn" ; "LTRU Working Group" ; "Martin Duerst" > Sent: Tuesday, April 12, 2005 3:02 PM > Subject: Re: [Ltru] Moving Forward ... > > Technical question: how do you envision the entries for languages like Vietnamese, > > which within relatively recent history have had multiple scripts, but which currently > > are written (exclusively, AFAIK) in a single script? > > The main goal would be current modern usage. And there would be no > prohibition against including other explicit scripts for other types of > matching. This doesn't seem to match up completely with the description of Associated_Script, where it said: ... > > > Languages that have this field SHOULD use a script subtag. Other ... This would seem that to result in the situation that if "Associated_Script" entries were added to support historical scripts used for Vietnamese, then we'd be stuck using a script subtag for modern texts, where the question is (almost?) never relevant. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 01:47:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21177; Wed, 13 Apr 2005 01:47:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLasp-0004Lw-3s; Wed, 13 Apr 2005 01:57:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLaf5-0003Wn-BS; Wed, 13 Apr 2005 01:43:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLaf4-0003W0-74 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 01:43:38 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20854 for ; Wed, 13 Apr 2005 01:43:29 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050413054258.TMLK7277.mta10.adelphia.net@DEWELL> for ; Wed, 13 Apr 2005 01:42:58 -0400 Message-ID: <006801c53feb$9e95a980$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050412165808.CNZZ2140.mta3.adelphia.net@megatron.ietf.org> Date: Tue, 12 Apr 2005 22:42:44 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: date B = 2005-01-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: > After the intruduction of several nonsense MO-tags in the 3066 > system I propose to use 2005-01-01 as "date B" and ignore all > dubious 3066-tags introduced after 2005-01-01 (if they turn out > to be "redundant" this point is moot). > > Further I want to express that I do not trust anybody involved > in the registrations of MO-languages. Are you *sure* there is no discernible difference between Chinese as used in Macao and Chinese as used in other places? I know I'm not qualified to say whether there is or isn't. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 01:47:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21197; Wed, 13 Apr 2005 01:47:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLasr-0004ME-KB; Wed, 13 Apr 2005 01:57:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLaiF-0003nG-KY; Wed, 13 Apr 2005 01:46:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLaiE-0003mY-LZ for ltru@megatron.ietf.org; Wed, 13 Apr 2005 01:46:54 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21131 for ; Wed, 13 Apr 2005 01:46:45 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050413054612.MFWR2192.mta9.adelphia.net@DEWELL> for ; Wed, 13 Apr 2005 01:46:12 -0400 Message-ID: <006f01c53fec$14dd3400$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050412180453.BUHB2135.mta2.adelphia.net@megatron.ietf.org> Date: Tue, 12 Apr 2005 22:46:03 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> I'd draw the line at filling fields that were not available >> in the source documents. > > Of course, and IMHO better than Doug's line "Latn", bye, Frank > -- > I have no idea what this refers to. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 02:02:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24947; Wed, 13 Apr 2005 02:02:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLb7U-0004hN-UV; Wed, 13 Apr 2005 02:13:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLasz-0005xJ-0B; Wed, 13 Apr 2005 01:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLasy-0005wC-4T for ltru@megatron.ietf.org; Wed, 13 Apr 2005 01:58:00 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21809 for ; Wed, 13 Apr 2005 01:57:51 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050413055720.NDJH4618.mta13.adelphia.net@DEWELL> for ; Wed, 13 Apr 2005 01:57:20 -0400 Message-ID: <007a01c53fed$9e8a7400$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050412180453.BUHB2135.mta2.adelphia.net@megatron.ietf.org> Date: Tue, 12 Apr 2005 22:57:03 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: date B = 2005-01-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Frank Ellermann wrote: >> If they are redundant junk, so much the better. > > Sure, I still think that we don't need redundant junk tags in > the future registry. Recommended prefixes "zh-Hans ; zh-Hant" > for region MO are certainly not what we want, pt-Latn-MO might > be dubious, but it's not illegal. > >> If they are grandfathered junk, it won't make a difference. > > IBTD, only two of them are MO-junk, and all new grandfathered > tags that are really useful would be a PITA (deprecate them, > add a canonical value, the works). Just to make sure everyone's on the same page with this: The new zh-*-* tags will be "redundant" if and only if the order language-script-region is preserved. If a different order is chosen, then these tags would be grandfathered, which is obviously less desirable. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 02:11:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03100; Wed, 13 Apr 2005 02:11:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLbFV-0004rR-Gh; Wed, 13 Apr 2005 02:21:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLb22-00071W-5y; Wed, 13 Apr 2005 02:07:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLb20-0006zq-4h for ltru@megatron.ietf.org; Wed, 13 Apr 2005 02:07:20 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28989 for ; Wed, 13 Apr 2005 02:07:02 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050413060632.MQRE2192.mta9.adelphia.net@DEWELL> for ; Wed, 13 Apr 2005 02:06:32 -0400 Message-ID: <008301c53fee$ea35fc20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org> Date: Tue, 12 Apr 2005 23:06:19 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Currently, here's where I think we are: > > Those in opposition are Randy, Addison, Mark, Peter, and Robin. > Those in support are Jefsey, John, Ned, and Doug. I prefer to be counted as "neutral" rather than "in support." I meant it when I said 51-49: definitely not a decisive margin. I see both sides of this one. > Both John and Doug, as well as several of those who are neutral, > are opposed to Jefsey's provisos. Correct there. I note that if the inclusion of French continues to be portrayed as a first step toward adding more translations, I will change my vote on the French question to a clear "no." -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 02:16:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09074; Wed, 13 Apr 2005 02:16:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLbKv-0004yR-L0; Wed, 13 Apr 2005 02:26:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLb9a-0000K4-8s; Wed, 13 Apr 2005 02:15:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLb9U-0000G1-Jm for ltru@megatron.ietf.org; Wed, 13 Apr 2005 02:15:05 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06672 for ; Wed, 13 Apr 2005 02:14:54 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLb61-0005Ot-8S for ltru@lists.ietf.org; Wed, 13 Apr 2005 08:11:29 +0200 Received: from 212.82.251.36 ([212.82.251.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Apr 2005 08:11:29 +0200 Received: from nobody by 212.82.251.36 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Apr 2005 08:11:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 13 Apr 2005 08:11:08 +0200 Organization: Lines: 14 Message-ID: <425CB7FC.28A1@xyzzy.claranet.de> References: <20050412165808.CNZZ2140.mta3.adelphia.net@megatron.ietf.org> <006801c53feb$9e95a980$030aa8c0@DEWELL> 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.36 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: date B = 2005-01-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > Are you *sure* there is no discernible difference between > Chinese as used in Macao and Chinese as used in other places? As sure as for it-Latn-SM or fr-Latn-MC, in other words _no_ > I know I'm not qualified to say whether there is or isn't. The idea is to present facts _for_ a registration. Or that's what I thought before these MO-tags, now I think that there's a problem with the tag review procedure, "registered-language" tags should not be allowed, i-whatever was better. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 02:26:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21668; Wed, 13 Apr 2005 02:26:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLbUQ-0005Dh-J9; Wed, 13 Apr 2005 02:36:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLbIx-00035T-Bs; Wed, 13 Apr 2005 02:24:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLbIu-00033E-GU for ltru@megatron.ietf.org; Wed, 13 Apr 2005 02:24:48 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19606 for ; Wed, 13 Apr 2005 02:24:39 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050413062408.SYRB5402.mta11.adelphia.net@DEWELL> for ; Wed, 13 Apr 2005 02:24:08 -0400 Message-ID: <008a01c53ff1$5f473ea0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org> Date: Tue, 12 Apr 2005 23:23:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Mark Davis wrote: > 1. We add one field to the language records: > > Associated_Script: > > This field is optional; if present, it will occur 2 or more times. > This field is used to indicate languages commonly written in two or > more scripts. Languages that have this field SHOULD use a script > subtag. Other languages SHOULD NOT use a script subtag unless it adds > some useful information (for example, the Brai subtag for a Braille > text) or in the context of certain types of matching operations. That's a bit more palatable than some previous approaches. Would the recommendation against using a script subtag with a non-associated-script language subtag be on roughly the same level as the recommendation against using a variant subtag without its recommended prefix? (Tough sentence; read it again until it makes sense.) In other words, not forbidden, but sort of an eye-roller? > It is expected that it would be populated over time, with the > registration process. We add this to the registration form, so that > associated scripts can be added. We can put in values for the high- > runner cases, since those are well-known. For example: > > %% > Type: lang > Subtag: sr > Description: Serbian > Associated_Script: Cyrl > Associated_Script: Latn > %% I guess we got rid of multiple values separated by semicolons, since that became confusing with the language descriptions. *sigh* All right, I guess I can live with the multiple Associated_Script subtags. Please, let's try to keep this to a minimum as long as we're using record-jar and not XML. I'm still trying to figure out how to implement this. > We describe (informatively) in the LT doc that these fields can be > useful in matching, and note that in many kinds of matching the script > code should be omitted to maximize compatibility unless there is more > than one associated-script value present. We leave any further text to > be worked out in the matching document, since that is the scope of > that document, and beyond the scope of the LT document. So normal tag generation works the same as always, but there might be a red flag (or in my case, a yellow light) telling the user who generates "ru-Cyrl" that the script tag is not recommended. That's not too bad. My only lingering concern is that the user who generates "ru-Brai" gets the same message, and clearly that second user knows what she is doing, and is doing it on purpose. > 2. We leave the script in the current position, since it follows the > "most-significant-field-first" rule. While there may be cases where > current implementations won't find the region code where one exists, > they will be no worse off than if there is no region code at all. And > with #1, this will be few cases. We have to have script; that is one > of the main reasons for 3066bis. I am 100% in agreement with Mark on this, and to that end I oppose the Bruce Lilly draft, which attempts to pre-empt RFC 3066bis by duplicating one of its key functionalities. > 3. We arrange for a telecon either at the end of this week or the > first part of next week. We can have a common room for people in the > S. San Francisco area to meet in person, and others can call in. By > having an "in person" meeting, I think we might be able to make more > progress than we seem to be doing in email. No puedo. Better to keep it on the list, and try to impose a little more order. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 02:28:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23221; Wed, 13 Apr 2005 02:28:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLbVt-0005Ex-5w; Wed, 13 Apr 2005 02:38:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLbKo-0003Wi-2c; Wed, 13 Apr 2005 02:26:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLbKm-0003SM-Md for ltru@megatron.ietf.org; Wed, 13 Apr 2005 02:26:44 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21619 for ; Wed, 13 Apr 2005 02:26:35 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLbH6-0006EJ-VM for ltru@lists.ietf.org; Wed, 13 Apr 2005 08:22:56 +0200 Received: from 212.82.251.36 ([212.82.251.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Apr 2005 08:22:56 +0200 Received: from nobody by 212.82.251.36 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Apr 2005 08:22:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 13 Apr 2005 08:25:11 +0200 Organization: Lines: 20 Message-ID: <425CBB47.427F@xyzzy.claranet.de> References: <20050412180453.BUHB2135.mta2.adelphia.net@megatron.ietf.org> <006f01c53fec$14dd3400$030aa8c0@DEWELL> 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.36 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.2 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Doug Ewell wrote: >>> I'd draw the line at filling fields that were not available >>> in the source documents. >> Of course, and IMHO better than Doug's line "Latn" [...] > I have no idea what this refers to. http://search.gmane.org/search.php?query=Latin&email=dewell@adelphia.net&group=gmane.ietf.ltru Oops, sometimes this works, second hit: http://article.gmane.org/gmane.ietf.ltru/256/match=latin | I would be concerned about an attempt to expand "native name" | beyond Latin-1, though. Apparently I confused Latn and Latin-1, bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 02:45:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29770; Wed, 13 Apr 2005 02:45:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLbmb-0005dc-5f; Wed, 13 Apr 2005 02:55:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLbb0-0007y6-SG; Wed, 13 Apr 2005 02:43:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLbav-0007op-A5 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 02:43:25 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29668 for ; Wed, 13 Apr 2005 02:43:07 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050413064237.TEEX5402.mta11.adelphia.net@DEWELL> for ; Wed, 13 Apr 2005 02:42:37 -0400 Message-ID: <009401c53ff3$f0c25e80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050412220510.PWXC2124.mta7.adelphia.net@megatron.ietf.org> Date: Tue, 12 Apr 2005 23:42:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA29668 Subject: [Ltru] Re: Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Randy Presuhn > Technical question: how do you envision the entries for languages like > Vietnamese, which within relatively recent history have had multiple > scripts, but which currently are written (exclusively, AFAIK) in a > single script? As someone who has a fair amount of contact with Vietnamese, I would associate its modern use with Latin almost as much as I would English. Wikipedia is correct: "Although a vast cultural heritage and history remains written in ch=E1=BB=AF n=C3=B4m, few Vietnamese today can read it= ." For the same reason, I would associate Korean with Hangul rather than "either Hangul or Hanja." One often hears that South Koreans on either side of the Pacific continue to use hanja for decoration and personal names (unlike the North Koreans, for whom hanja are banned), but the fact is that even these uses are extremely limited. I recently scanned through a 12-page section of a Korean-language newspaper filled with decorative ads, and found not a single hanja. I guess Randy's question could be asked in the context of, say, Turkish. Turkish was once written almost exclusively in Arabic; now it is written almost exclusively in Latin. If the goal of indicating a default script (by whatever name) is to reflect modern usage, which seems reasonable, then Turkish should be associated with Latin (so no Associated_Script fields here). Naturally, this shows again that default-script is not incontrovertible. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 03:15:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01763; Wed, 13 Apr 2005 03:15:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLcFG-0006Mm-Bi; Wed, 13 Apr 2005 03:25:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLc2p-00049n-MA; Wed, 13 Apr 2005 03:12:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLc2Z-00042f-0Y for ltru@megatron.ietf.org; Wed, 13 Apr 2005 03:11:59 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01595 for ; Wed, 13 Apr 2005 03:11:56 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLbzI-0001xL-QK for ltru@lists.ietf.org; Wed, 13 Apr 2005 09:08:36 +0200 Received: from 212.82.251.36 ([212.82.251.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Apr 2005 09:08:36 +0200 Received: from nobody by 212.82.251.36 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Apr 2005 09:08:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 13 Apr 2005 09:09:01 +0200 Organization: Lines: 49 Message-ID: <425CC58D.5DA@xyzzy.claranet.de> References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org> <008a01c53ff1$5f473ea0$030aa8c0@DEWELL> 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.36 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Doug Ewell wrote: > Tough sentence; read it again until it makes sense. It's okay, can I use Latn or Brai with en ? Of course, without a default script Brai could be useful, or Latn could be useful. Mark's proposal doesn't answer this question, implementors have to invent default scripts. They'll invent different things for languages without "Associated_Script", some of these ad hoc inventions will be wrong. For en-Brai one hint would be "Brai is nowhere in the Associated-Script, it must be sound". For Latn, Cyrl, and anything else in any Associated_Script it's not clear for the _other_ (unassociated) languages. > I guess we got rid of multiple values separated by > semicolons, since that became confusing with the > language descriptions. Semicolon is fine, it only didn't work for the union of English and French descriptions, because you need it already to separate descriptions in the same group. > I can live with the multiple Associated_Script subtags Unnecessary, semicolon is okay. But the concept of the Associated_Script list (two or more) doesn't help with obscure languages without any Associated_Script. Just look in your alpha-3 list, I can guess the script in less than half of it. Would I need Latn for got ? Or is Goth the script for got ? > I oppose the Bruce Lilly draft, which attempts to pre-empt > RFC 3066bis by duplicating one of its key functionalities. With Bruce's draft I'd know how to implement got-Latn in an Accept-Script and HTTP. It could even work for content with a Content-Script. Dito MIME (mail and news) excl. RfC 2231. I'd know how to declare a Content-Script in XHTML 1 or HTML. Okay, I don't know a HTTP server extracting this from the document, and I've no idea how to do it in arbitrary XML. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 07:15:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15377; Wed, 13 Apr 2005 07:15:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLg0S-0003Ww-JU; Wed, 13 Apr 2005 07:26:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfoV-0001rV-QO; Wed, 13 Apr 2005 07:13:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfoU-0001oW-Ue for ltru@megatron.ietf.org; Wed, 13 Apr 2005 07:13:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15222 for ; Wed, 13 Apr 2005 07:13:15 -0400 (EDT) Received: from smtp04.mrf.mail.rcn.net ([207.172.4.63]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLfxs-0003Sd-Ox for ltru@ietf.org; Wed, 13 Apr 2005 07:23:25 -0400 Received: from c-24-6-51-238.hsd1.ca.comcast.net (HELO xencraft.com) (24.6.51.238) by smtp04.mrf.mail.rcn.net with ESMTP; 13 Apr 2005 07:13:13 -0400 Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.9.7]); Wed, 13 Apr 2005 04:13:14 -0700 Message-ID: <425CFEC6.E6FB9996@i18nguy.com> Date: Wed, 13 Apr 2005 04:13:10 -0700 From: Tex Texin Organization: http://www.XenCraft.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] A Modest Proposal References: <017c01c53f8d$21e1c530$ab703009@sanjose.ibm.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA15222 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable This is good, but ignores relativistic effects in the event the speaker is traveling at a high rate of speed. I guess that is why it is a modest proposal. Also, it has an inherent limitation in that for speakers moving at a high velocity, their position cannot be known accurately due to the Heisenberg uncertainty principal. The syntax ought to allow for a mapping between speed and location via Planck's constant. It also doesn't recognize interdimensional travel and so seems rather centric on 4 dimensions. The syntax should be made more extensible with an equation as follows: XLanguageTag for n-dimension universe ::=3D sum for dimensions i =3D 0 to n-1: -i (best I can do in plain text. Or is that plane text?) tex Mark Davis wrote: >=20 > Since it is obvious that all applications in the world will require > extremely fine-grained approach to languages, here is an initial propos= al > for development of a separate RFC to deal with them. The goal is to be = able > to describe the variety of speech that each person on earth may be usin= g at > a given time. Identification is by means of the location of the speaker= and > the time at which the speech could have occurred. The language tag is g= iven > by the following format (formal ABNF to follow). >=20 > XLanguageTag ::=3D latitude "-" longitude "-" altitude "-" time >=20 > Latitude and longitude are specified by radians, and be measured from 0= to > 360 starting at the Prime Meridian going east, and from 0 to 180 starti= ng at > the South Pole and going north. The numeric values below zero are avoid= ed > because the use of the terms "positive" and "negative" when applied to > location can clearly be prejudicial to many of the peoples of the world. > Should in the course of the development of this RFC, the use of the Pri= me > Meridian be viewed as representative of an English-speaking hegemony, a > random longitude will be chosen as the origin. Use of latitude and long= itude > does not, of course, imply in any way that those who believe in a flat = earth > or the "four-elephant+turtle system" are in any way discouraged in the > observance of their faith, nor does the use of radians in any way denig= rate > the goal of the Kansas State Education Board to recognize the value of = =CF=80 as > exactly 3.0. >=20 > Altitude is in meters above the center of the earth. While some may fee= l the > likelihood of two speakers being exactly overhead is low, we do -- of > course -- want to plan for all eventualities. By avoiding measurement > against sea level, we again celebrate the diversity of the world's > population, and do not discriminate against the proud inhabitants of De= ath > Valley and similar locations by in any way referring to them as "negati= ve". >=20 > For location, since people rarely overlap in physical space, it will us= ually > be sufficient to have accuracy to within 10 cm. But since fractions can= be > supplied, applications can have arbitrarily high degree of accuracy. >=20 > The time is specified by seconds since 0000-01-00T00:00:00Z (using the > proleptic Gregorian calendar as specified in XML Schema), plus an offse= t of > 1,000,000,000,000,000,000. If finer granularity than seconds is desired= , > then fractions can be specified. The reason for the offset is to again = avoid > negative numbers, and their implied bias against historic inhabitants. = The > offset is chosen as to be well before all current estimates of the Big = Bang. > Note, however, that this in no way implies any denigration of creationi= sm, > or that believers are in any way discouraged in the observance of their > faith. Nor does it imply that any one system of creationism, such as Gr= eek > or Norse creation theory, is any way inferior to any other, such as tha= t > espoused by the Kansas State Education Board. >=20 > Other parts of this proposal, such as security implications, will be > forthcoming. >=20 > =E2=80=8EMark >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru --=20 ------------------------------------------------------------- Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com Xen Master http://www.i18nGuy.com =20 XenCraft http://www.XenCraft.com Making e-Business Work Around the World ------------------------------------------------------------- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 07:16:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15408; Wed, 13 Apr 2005 07:16:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLg0f-0003XC-79; Wed, 13 Apr 2005 07:26:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfog-0001sp-1Z; Wed, 13 Apr 2005 07:13:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfof-0001rZ-8P for ltru@megatron.ietf.org; Wed, 13 Apr 2005 07:13:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15238 for ; Wed, 13 Apr 2005 07:13:42 -0400 (EDT) Received: from smtp04.mrf.mail.rcn.net ([207.172.4.63]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLfyJ-0003T1-F8 for ltru@ietf.org; Wed, 13 Apr 2005 07:23:51 -0400 Received: from c-24-6-51-238.hsd1.ca.comcast.net (HELO i18nguy.com) (24.6.51.238) by smtp04.mrf.mail.rcn.net with ESMTP; 13 Apr 2005 07:13:44 -0400 Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.9.7]); Wed, 13 Apr 2005 04:13:45 -0700 Message-ID: <425CFEE9.C9F3B37B@i18nguy.com> Date: Wed, 13 Apr 2005 04:13:45 -0700 From: Tex Texin Organization: http://www.XenCraft.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: [psg.com #882] registry should copy non-English fieldsfrom ISO documents References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org> <008301c53fee$ea35fc20$030aa8c0@DEWELL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit fwiw, I wouldn't favor adding the French at this time. As for Latin-1, if we move out of the ASCII realm, I would prefer Unicode. We might not use chars out of the latin-1 set, but we shouldn't hem ourselves into a limited architecture. My 2 cents. tex Doug Ewell wrote: > > Randy Presuhn wrote: > > > Currently, here's where I think we are: > > > > Those in opposition are Randy, Addison, Mark, Peter, and Robin. > > Those in support are Jefsey, John, Ned, and Doug. > > I prefer to be counted as "neutral" rather than "in support." I meant > it when I said 51-49: definitely not a decisive margin. I see both > sides of this one. > > > Both John and Doug, as well as several of those who are neutral, > > are opposed to Jefsey's provisos. > > Correct there. > > I note that if the inclusion of French continues to be portrayed as a > first step toward adding more translations, I will change my vote on the > French question to a clear "no." > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- ------------------------------------------------------------- Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com Xen Master http://www.i18nGuy.com XenCraft http://www.XenCraft.com Making e-Business Work Around the World ------------------------------------------------------------- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 07:17:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15499; Wed, 13 Apr 2005 07:17:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLg1w-0003aG-LV; Wed, 13 Apr 2005 07:27:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfpJ-0001wz-AL; Wed, 13 Apr 2005 07:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfpI-0001w3-Fd for ltru@megatron.ietf.org; Wed, 13 Apr 2005 07:14:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15271 for ; Wed, 13 Apr 2005 07:14:21 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLfyw-0003TM-6n for ltru@ietf.org; Wed, 13 Apr 2005 07:24:30 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 13 Apr 2005 12:00:29 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 12:00:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2005 12:00:28 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A385@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [slightly OT] Linguasphere (was Great Script Debate Part II: Formats...) Thread-Index: AcU/CuVgynR2jWyEQM6aBILe1uHKKwAMNCggAAzdttAAJPtWoA== From: "L.Gillam" To: ltru X-OriginalArrivalTime: 13 Apr 2005 11:00:28.0993 (UTC) FILETIME=[00FD7310:01C54018] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: quoted-printable Subject: [Ltru] [OT] Linguasphere X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: quoted-printable Peter, It appears we differ on the use of the fuzzy values "somewhat" and = "highly".=20 OTOH, we agree on the use of the word "interoperable", which is a good=20 starting point, and your valuable analysis below will help to show the = extent to which mappings can be made. If we select definitions for interoperable, say: "For the purposes of this document, "interoperable" means to be able to=20 interoperate over a data communications path." www.zvon.org/tmRFC/RFC2026/Output/chapter14.html or the OED: "Able to operate in conjunction" then the question, as I see it is: "where can they operate in conjunction, and to what extent". Let me generalise slightly to systems A and B: Where there is no overlap between A and B, conjunction is made using = items from either A or=20 B. Where one can interleave (consider e.g. animal -> dog vs. animal -> = mammal -> canine -> dog)=20 there is good interoperability - data loss would occur in interchange in = 1 direction, but the systems can be used in conjunction.=20 Where mappings can be created in one direction via generalisation, the = systems can interoperate. A similar data interchange issue exists. Where there is good overlap, there is good interoperability and good = interchange. Interoperability can provide the best (and worst) of both worlds = (systems). For me, such characteristics indicate a high degree (highly) rather than = a small degree (somewhat) of interoperability. I'm willing to concede the adverb, for the time = being, if you can put better values to "somewhat" and "highly" that we can standardi(s|z)e :-)=20 I have left aside the specific details of mappings etc., with respect to = Debbie's response about the 2000 vs current situation. Suffice to say that e.g. something = like /abcd =3D Afro-Asiatic/ <- /efgh =3D Coptic/ would be the resulting = parent/child relationship from below, where /efgh =3D Coptic/ satisfies characteristics at each = level of a model of zone / set / chain / net / (outer) language. Essentially, there are = abstract intermediate=20 concepts for which no name exists ("turtles all the way down"). = Hopefully Debbie can=20 point to any gross oversimplification I've made here. If Coptic is valid = in one system,=20 with no entry in another, the two will operate well in conjunction. Best Regards. > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Peter Constable > Sent: 12 April 2005 18:22 > To: ltru > Subject: [Ltru] [slightly OT] Linguasphere (was Great Script=20 > Debate Part > II: Formats...) >=20 >=20 > > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of L.Gillam >=20 >=20 > > The upper layers of the Linguasphere and what is proposed for 639-5 > are, > > based on a small sample, highly interoperable. >=20 > This is slightly overstated, I think.=20 >=20 > Linguasphere's upper-layer analysis divides the world into=20 > ten buckets. > Five correspond to linguistic phyla (which are genetic=20 > classifications), > and five correspond to regions of the world.=20 >=20 > For the five genetic buckets, the upper layers are somewhat, but not > highly, interoperable with 639-5. There are a couple of factors that > limit the extent to which the two align.=20 >=20 > First, you need to ignore several of Linguasphere's > artificially-constructed categories which are necessitated by fitting > everything into its model, which requires every language to be in some > net in some chain in some set in some zone in the given=20 > sector (phylum). > For instance, the analysis for Coptic is: >=20 > sector / zone / set / chain / net / (outer) language =3D=20 > Afro-Asiatic / Coptic / Coptic / Coptic / Coptic / Coptic >=20 > You won't find an entry for Coptic in the draft table for 639-5. >=20 > Secondly, Linguasphere appears to have more higher-level=20 > branching than > is currently reflected in the draft table for 639-5. Specifically, it > often treats as a level-2 node something that in the analysis used for > 639-5 is a level-3 node and as a result not included in the current > draft for 639-5. The result of this is that Linguasphere has several > level-2 nodes not found in the current draft of 639-5, and vice versa. >=20 > (Some notes: I believe the current draft for 639-5 was based=20 > largely on > Ethnologue, which itself is based on the Oxford International > Encyclopaedia of Linguistics and Tyron's Comparitive Austronesian > Dictionary. The number of layers included in the current=20 > draft of 639-5 > for a given family or phylum varies from two to four; I'm not sure on > what basis the editor for 639-5 decided how many layers to include, > though it appears to be partly related to the size of the phylum: > Austronesian, with >1200 languages, gets IDs for four layers while > Afroasiatic, with < 400 languages, gets IDs for two layers. My > understanding is that Linguasphere's analysis, to the extent that it > differs from the above sources, is novel.)=20 >=20 > Of Linguasphere's five "phylosectors", Indo-European gets the best > interop with the current draft for 639-5. The other four=20 > don't fair all > that well. This results from Linguasphere's unique analysis, which > appears to be driven largely by the insistence of fitting everything > into its five-layer model for upper levels of hierarchy and of having > ten top layers each with ten level-2 groupings. >=20 > As for Linguasphere's five "geosectors", the story is largely=20 > the same. > The draft for 639-5 has inherited "North American Indian=20 > languages" and > "South American Indian Languages" from 639-2, which match three of > Linguasphere's geosectors. The level-2 nodes for NAI align somewhat, > with a couple of issues. First, you must see past Linguasphere's > insistence on geographic designators where familiar genetic=20 > terms exist: > "Saint Lawrence" instead of Iroquioan, "Mississippi" instead=20 > of Siouan. > The bigger issue is Linguasphere's insistence on ten level-2 nodes in > each sector, forcing level-2 nodes that combining distinct families > while in some cases splitting others. So, for instance,=20 > instead of nodes > for Salishan and Penutian, it has a "Farwest" geozone; and the Hokan > family appears to largely match L's "Desert" geozone, though=20 > there are a > couple of Hokan outliers down in Oaxaca that appear to be=20 > somewhere else > in L. (I'm not sure where, though: one of L's problems is=20 > that it can be > really hard to find things since there's no index by name or=20 > by country, > and the hierarchies don't correspond with familiar analyses.) >=20 > The draft table for 639-5 has no category corresponding to=20 > L's top-level > "Eurasia" geosector, but some of L's geozones in that sector=20 > align with > 639-5 entries: Uralic, Causasus, Dravidic. The other level-2 nodes are > more of these geographic groupings artificially created to=20 > result in ten > zones within each sector. You won't find "Siberia" in 639-5, neither > will you find a node for Altaic in Linguasphere. >=20 > The story for L's "Africa" and "South America" geozones appear to be > similar to that for "North America" and "Eurasia"; "Australia" looks > like it would be less hopeful (but I haven't looked at it in detail). >=20 >=20 > So, all in all, the best I think can be said regarding=20 > interoperability > between 639-5 and Linguasphere is that the are somewhat=20 > interoperable. I > don't think it really can be said that they are highly interoperable. >=20 >=20 >=20 > Peter Constable >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 07:47:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17558; Wed, 13 Apr 2005 07:47:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLgUd-0004Kd-60; Wed, 13 Apr 2005 07:57:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLgIE-00086K-LS; Wed, 13 Apr 2005 07:44:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLgID-00085t-9Y for ltru@megatron.ietf.org; Wed, 13 Apr 2005 07:44:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17398 for ; Wed, 13 Apr 2005 07:44:16 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLgRq-0004FQ-J6 for ltru@ietf.org; Wed, 13 Apr 2005 07:54:23 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 13 Apr 2005 12:22:35 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 12:22:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Great Script Debate Part II: Formats... Date: Wed, 13 Apr 2005 12:22:34 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A38C@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Great Script Debate Part II: Formats... Thread-Index: AcU/k35mIIxFR5WASsyNPgFppxkcVgAhb8DA From: "L.Gillam" To: ltru X-OriginalArrivalTime: 13 Apr 2005 11:22:34.0878 (UTC) FILETIME=[174771E0:01C5401B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Jefsey, For once I find I might be able agree with you - I might=20 have misunderstood you however, so please don't comment it as a certainty. Reference name provides the "hook", as you refer to it. You (2nd person singular/plural) can provide whatever additional translations you (2nd person singular/plural) desire for such reference names, in whatever languages you (..) desire, keep whatever local copies you (..) wish, and so on. The problem you are making for people on this list is that you (2nd person singular) seem to be insisting that the registry=20 MUST contain names in EVERY language for EVERY language, or should produce translations where they are not available from the source=20 standards (e.g. reference names in 639-3). I see little purpose -=20 we are taking about "names" that help to identify tags, not=20 imposing restrictions on "languages", per se, which would=20 be somewhat different. Nobody is prevented from creating French names for these 7000 reference names, German names, Slovakian names, and so on. Making it a necessary and essential task is unrealistic - look at the army of translators needed by the EU, for example. As I said, feel free to create your own hooks in other=20 languages of your (2nd s/p) choice for your (2nd s/p) presentation - provided that in interchange the presented=20 item transforms into the correct tag there will be no=20 difficulties. > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > Sent: 12 April 2005 17:48 > To: Gillam L Dr (Computing); ltru > Subject: RE: [Ltru] Great Script Debate Part II: Formats... >=20 >=20 > I think you are globally right. >=20 > At 16:50 12/04/2005, L.Gillam wrote: > Where did I make something forbidden Jefsey? >=20 > Ah! I thought you wanted to forbid French and hooks for other=20 > languages. >=20 > On the contrary, > >I think you'll find I say there are certain things we should > >not impose (just above here for example). >=20 > This implies that default references should be autonyms? I was wrong=20 > reading you differently. >=20 > >Quite the reverse. Please do not twist what I, or indeed=20 > others, write in=20 > >an attempt to validate your position. >=20 > I have no position. Just observation. When I say that the=20 > lack of support=20 > of English and French is a blocking element. This is because=20 > I observe that=20 > it will be real world blocking, because applications are=20 > under current=20 > development and projects under financing which say otherwise. >=20 > >There's a "forbid" if you want one. >=20 > How rigth you are. > jfc >=20 > PS. I suppose you will want to respond I a wrong or=20 > unintelligible. No=20 > need, I have already taken your response into account.=20 >=20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 09:48:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26334; Wed, 13 Apr 2005 09:48:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLiOP-0007ga-Jd; Wed, 13 Apr 2005 09:58:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLiEC-0004PU-73; Wed, 13 Apr 2005 09:48:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLiEA-0004Ng-Ac for ltru@megatron.ietf.org; Wed, 13 Apr 2005 09:48:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26281 for ; Wed, 13 Apr 2005 09:48:20 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLiNw-0007fS-QA for ltru@ietf.org; Wed, 13 Apr 2005 09:58:30 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3DDmAwo000112; Wed, 13 Apr 2005 09:48:11 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 13 Apr 2005 09:48:02 -0400 Date: Wed, 13 Apr 2005 09:48:02 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: Moving Forward Message-ID: <20050413134801.GB9774@skunk.reutershealth.com> References: <20050412220510.PWXC2124.mta7.adelphia.net@megatron.ietf.org> <009401c53ff3$f0c25e80$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009401c53ff3$f0c25e80$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Doug Ewell scripsit: > I guess Randy's question could be asked in the context of, say, Turkish. > Turkish was once written almost exclusively in Arabic; now it is written > almost exclusively in Latin. If the goal of indicating a default script > (by whatever name) is to reflect modern usage, which seems reasonable, > then Turkish should be associated with Latin (so no Associated_Script > fields here). Indeed it should, the more so because Ottoman Turkish and modern Turkish are really two separate languages with a major vocabulary barrier (Persian and Perso-Arabic words in Ottoman that aren't found in modern Turkish) between them. Indeed, they have separate ISO 639-2 codes, ota and tur respecitvely. Geoffrey Lewis's book _The Turkish Language Reform: A Catastrophic Success_ is a witty and informative account of the ins and outs of the process that led to modern standard Turkish. (See http://www.oup.co.uk/isbn/0-19-823856-8 for details.) -- By Elbereth and Luthien the Fair, you shall jcowan@reutershealth.com have neither the Ring nor me! --Frodo http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 10:08:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28638; Wed, 13 Apr 2005 10:08:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLiht-0008HC-FD; Wed, 13 Apr 2005 10:19:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLiTL-0007RJ-TG; Wed, 13 Apr 2005 10:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLiTK-0007QW-OQ for ltru@megatron.ietf.org; Wed, 13 Apr 2005 10:04:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27929 for ; Wed, 13 Apr 2005 10:03:52 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLid0-00087f-2e for ltru@ietf.org; Wed, 13 Apr 2005 10:14:02 -0400 Received: from lns-p19-1-idf-82-251-86-165.adsl.proxad.net ([82.251.86.165] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLiT7-0005tM-Vf; Wed, 13 Apr 2005 07:03:50 -0700 Message-Id: <6.1.2.0.2.20050413144215.0de1e0c0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 13 Apr 2005 15:27:09 +0200 To: "L.Gillam" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Great Script Debate Part II: Formats... In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A38C@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A21292A38C@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Dear L.Guillam, this certainly is a right of everyone - and a possibility and a certain work. This is the same as for 10646: building a list of name of usage correcting or adapting the 100646 names to the reality of usage. And be sure this is exactly what we are working on as a prototype CRC. What I oppose in "your" position, is four things: dominance, lack of QA, complexity, inconsistency, decency. Since you certainly do not see where let me explain again. - dominance is not good because it is not appropriate to the network architecture. Since Paul Bahan in the 60s and the work carried in the 80s we know that networks can be centralized by a dominance, decentralised by a governance, distributed by an intergovernance. These are natural interest/forces/solutions which are the very architecture of every network. They mostly result of their granularity, which means for wide systems of their density. Today the internet itself which started in a centralised development phase (mid 80s) to a decentralised deployment phase (mid 90s) enter its distributed scalability phase. Dominance concepts (IANA, ICANN, ASCII, English) were until now acceptable as only "old". They become progressively totally outdated and an architectural flaw more and more people and concept will oppose and already suffer from. The idea of a reviewer in English for the language of the world, was a bizarre oddity, it is becoming an unacceptable bug. - lack of QA results from abandon of cross culture control and protection. Look at the ieft-languages list and at this list. How many people of English/non English culture/mother tongue when we are precisely discussing languages and cultures. Look at the number of represented nationalities when you know (and this is what is precisely discussed and acknowledged through the ISO 3166 country codes) a language is the first and basic social contract of a nation. I am not interested here in politics but in quality. Look at the number of wrong 10646 names in spite of all the accumulated efforts. Look at the ietf-languages lists which doubled the considered Greek languages tags when I called upon the Greek ccTLD and the University of Athens. There is a need for cross cultural control. This control is provided by French for centuries and at ISO. Be sure I will not accept that all of us we lose that QA. - complexity. The hook of a language is not an easy thing because printf("$stringNN") is not a programer reflex. In permitting to have a single reference name, you do not oblige programers to support several languages (when there are two, there are hooks for all). - inconsistency. We know that the reference names are just because France accepted not to delay ISO 639-3 (I concurred) in having not the budget/people to carry the work. The response was "we will use autonyms". Autonyms would be nice. But "fra french" is not really an autonym. Now, the problem is may be something we could fix. We have to discuss. - decency. A Draft has been introduced twice, and failed. We (ietf@ietf.org opponents) proposed a small rewrite of two or three point or a real WG. A WG and a charter have resulted, which uses the same Draft. And while the Draft is not even submitted to the IESG the Draft is enforced. This is playing a lot on a very well known idea: people today cannot be internet builder anymore, so they are afraid of being remembered as Internet wreckers, and they do not dare to oppose. It happens that I do not fear that: my past is behind me already. But I do not want to be remembered as the one "who could have" ... As pointed out in another mail, the problem here is that it is a call to extremism. Everyone serious outside of this long working together group, and interested (but IAB, IESG and IETF is not really interested in multilingualism), sees that the Draft is a clumsy attempt at proposing an XML patch (Addison well documented it) and will oppose it to be made a Multilingual Internet confusion. In the process these "everyone" will most likely fight and forget Addison's legitimate need for solution to the real, urgent and important (but not fundamental) need of an XML patch. all the best. jfc PS. Since you are going to tell me "and why IAB, IESG and IETF is not interested ???", what result from observation (for example the very odd RFC 3869 which is a call of IAB to Governments for Internet R&D financing and does not even allude to languages after 192 unanimous Governments made it their priority and it is the US year of multilingualism). I started a draft last summer on the way the Internet standard process could support the documentation of a Multilingual Internet. It was interrupted by the RFC 3066 bis saga. From this I think it is the syndrome I quoted above and Vint made his leit-motive "why to fix what ain't broke". The architectural change is huge. The problem is that the question is not "to fix what would be broken", but "to replace what is outdated". PS. In case you ask what the hell can be a "Multilingual Internet", I suggest to use http://minc.org . You may not know it, but it terms of users it is a substantial one. Not so far from the majority if not already the majority. But the growth of the ASCII Internet is so slow (800 millions against 1.4 billion mobiles). Vernacular is not supported. Architecture is too rigid. 13:22 13/04/2005, L.Gillam said: >Jefsey, > >For once I find I might be able agree with you - I might >have misunderstood you however, so please don't comment >it as a certainty. > >Reference name provides the "hook", as you refer to it. >You (2nd person singular/plural) can provide whatever additional >translations you (2nd person singular/plural) desire for such >reference names, in whatever languages you (..) desire, >keep whatever local copies you (..) wish, and so on. The >problem you are making for people on this list is that >you (2nd person singular) seem to be insisting that the registry >MUST contain names in EVERY language for EVERY language, or should >produce translations where they are not available from the source >standards (e.g. reference names in 639-3). I see little purpose - >we are taking about "names" that help to identify tags, not >imposing restrictions on "languages", per se, which would >be somewhat different. > >Nobody is prevented from creating French names for these >7000 reference names, German names, Slovakian names, and >so on. Making it a necessary and essential task is >unrealistic - look at the army of translators needed by >the EU, for example. > >As I said, feel free to create your own hooks in other >languages of your (2nd s/p) choice for your (2nd s/p) >presentation - provided that in interchange the presented >item transforms into the correct tag there will be no >difficulties. > > > -----Original Message----- > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > Sent: 12 April 2005 17:48 > > To: Gillam L Dr (Computing); ltru > > Subject: RE: [Ltru] Great Script Debate Part II: Formats... > > > > > > I think you are globally right. > > > > At 16:50 12/04/2005, L.Gillam wrote: > > Where did I make something forbidden Jefsey? > > > > Ah! I thought you wanted to forbid French and hooks for other > > languages. > > > > On the contrary, > > >I think you'll find I say there are certain things we should > > >not impose (just above here for example). > > > > This implies that default references should be autonyms? I was wrong > > reading you differently. > > > > >Quite the reverse. Please do not twist what I, or indeed > > others, write in > > >an attempt to validate your position. > > > > I have no position. Just observation. When I say that the > > lack of support > > of English and French is a blocking element. This is because > > I observe that > > it will be real world blocking, because applications are > > under current > > development and projects under financing which say otherwise. > > > > >There's a "forbid" if you want one. > > > > How rigth you are. > > jfc > > > > PS. I suppose you will want to respond I a wrong or > > unintelligible. No > > need, I have already taken your response into account. > > > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 10:08:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28662; Wed, 13 Apr 2005 10:08:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLihv-0008HN-Q2; Wed, 13 Apr 2005 10:19:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLiTL-0007RA-N4; Wed, 13 Apr 2005 10:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLiTK-0007QV-NR for ltru@megatron.ietf.org; Wed, 13 Apr 2005 10:04:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27926 for ; Wed, 13 Apr 2005 10:03:52 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLicz-00087Z-3I for ltru@ietf.org; Wed, 13 Apr 2005 10:14:02 -0400 Received: from lns-p19-1-idf-82-251-86-165.adsl.proxad.net ([82.251.86.165] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLiT9-0005tM-HX for ltru@ietf.org; Wed, 13 Apr 2005 07:03:51 -0700 Message-Id: <6.1.2.0.2.20050413152952.04903eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 13 Apr 2005 15:37:51 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #882] registry should copy non-English fieldsfrom ISO documents In-Reply-To: <425CFEE9.C9F3B37B@i18nguy.com> References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org> <008301c53fee$ea35fc20$030aa8c0@DEWELL> <425CFEE9.C9F3B37B@i18nguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 If I am correct there is on the issue, 1. consensus among French culture Members having expressed an opinion. 2. mixed feelings among English culture Members, where confusion results from the bundling of various questions in a single one "do you support Jefsey's non detailed provision". 3. a complete confusion between the use of English or autonym reference names. 4. consideration of the particulars of a non yet otherwise discussed (but by me) registration procedure. May be could we start in having #882-variants? As implied in the process I probably have not the neutrality to make a correct analysis. But I will certainly help in indicating if the proposed variants are adequate. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 10:13:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29254; Wed, 13 Apr 2005 10:13:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLimH-0008OI-Qf; Wed, 13 Apr 2005 10:23:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLibc-0000MR-P4; Wed, 13 Apr 2005 10:12:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLiba-0000LT-Gv for ltru@megatron.ietf.org; Wed, 13 Apr 2005 10:12:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29110 for ; Wed, 13 Apr 2005 10:12:24 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLilG-0008Mx-2N for ltru@ietf.org; Wed, 13 Apr 2005 10:22:34 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3DECGnl000225; Wed, 13 Apr 2005 10:12:17 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 13 Apr 2005 10:12:18 -0400 Date: Wed, 13 Apr 2005 10:12:18 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: Moving Forward Message-ID: <20050413141218.GC9774@skunk.reutershealth.com> References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org> <008a01c53ff1$5f473ea0$030aa8c0@DEWELL> <425CC58D.5DA@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425CC58D.5DA@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Frank Ellermann scripsit: > Unnecessary, semicolon is okay. But the concept of the > Associated_Script list (two or more) doesn't help with > obscure languages without any Associated_Script. Obscure languages are probably only written in one script, and don't need Associated_Script. Note that the purpose of Associated_Script is not to tell an implementer the usual script used with a language, but simply to serve notice which script *subtags*, if any, should normally be used with this language subtag. This difference is fundamental. Thus en has no Associated_Script, because English is almost always written in the Latin script, so no script subtag should be employed exceptis excipiendis. But az should have "Associated_Script: Latn; Cyrl; Arab" (in whatever syntax) to indicate that tags should normally appear with script information. A language tag generator UI, therefore, should have two modes, normal script mode and unusual script mode. In normal script mode, only the scripts in Associated_Script should be offered to the user (and if there is no such header, then no scripts should be offered). In unusual script mode, every script should be offered. (Hint, hint, Doug.) Note that this does not apply to a language *range* generator, which needs different rules. > Just look in your alpha-3 list, I can guess the script > in less than half of it. Would I need Latn for got ? > Or is Goth the script for got ? The specific answer is that for centuries Gothic has been written solely in the Latin script. (This may start to change with the presence of Gothic in Unicode and the ready availability of Gothic fonts, or it may not.) Therefore, no Associated_Script header should be present, and the tag got-Latn should be avoided (though got-Goth would be in order as an unusual script). -- John Cowan www.ccil.org/~cowan www.reutershealth.com jcowan@reutershealth.com SAXParserFactory [is] a hideous, evil monstrosity of a class that should be hung, shot, beheaded, drawn and quartered, burned at the stake, buried in unconsecrated ground, dug up, cremated, and the ashes tossed in the Tiber while the complete cast of Wicked sings "Ding dong, the witch is dead." --Elliotte Rusty Harold on xml-dev _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 10:18:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29865; Wed, 13 Apr 2005 10:18:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLir2-0008W3-Jt; Wed, 13 Apr 2005 10:28:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLifY-0001IT-Ep; Wed, 13 Apr 2005 10:16:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLifW-0001HA-Je for ltru@megatron.ietf.org; Wed, 13 Apr 2005 10:16:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29654 for ; Wed, 13 Apr 2005 10:16:28 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLipB-0008St-5F for ltru@ietf.org; Wed, 13 Apr 2005 10:26:38 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 13 Apr 2005 15:14:48 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 15:14:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] OT: A Modest Proposal Date: Wed, 13 Apr 2005 15:14:46 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A39D@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] OT: A Modest Proposal Thread-Index: AcU/jbG/jcJT05XgSQeQ/afR0A1kOQAAJlxwACkUDFA= From: "L.Gillam" To: ltru X-OriginalArrivalTime: 13 Apr 2005 14:14:47.0024 (UTC) FILETIME=[25B7CF00:01C54033] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Is there a native Klingon speaker who might be able to assist in=20 the geospatial abstraction required? Misha, you claim to represent billions of other peoples, yet I have seen no evidence of existence of these other peoples. Will your legal department be using stylistically similar writing to that you use when presenting its complaint? > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Misha Wolf > Sent: 12 April 2005 19:38 > To: LTRU Working Group > Subject: RE: [Ltru] OT: A Modest Proposal >=20 >=20 > On behalf of Klingons and billions of other peoples, I strongly=20 > object to your proposal which is completely Earth-centric. I=20 > shall be contacting my legal department. >=20 > Misha >=20 >=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On Behalf Of Mark Davis > Sent: 12 April 2005 19:26 > To: LTRU Working Group > Subject: [Ltru] A Modest Proposal >=20 > Since it is obvious that all applications in the world will require > extremely fine-grained approach to languages, here is an initial > proposal > for development of a separate RFC to deal with them. The goal is to be > able > to describe the variety of speech that each person on earth=20 > may be using > at > a given time. Identification is by means of the location of=20 > the speaker > and > the time at which the speech could have occurred. The language tag is > given > by the following format (formal ABNF to follow). >=20 > XLanguageTag ::=3D latitude "-" longitude "-" altitude "-" time >=20 > [...] _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 10:20:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00257; Wed, 13 Apr 2005 10:20:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLitS-000092-77; Wed, 13 Apr 2005 10:31:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLiie-00020K-S7; Wed, 13 Apr 2005 10:19:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLiib-0001zP-EV for ltru@megatron.ietf.org; Wed, 13 Apr 2005 10:19:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00034 for ; Wed, 13 Apr 2005 10:19:39 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLisH-00006I-7z for ltru@ietf.org; Wed, 13 Apr 2005 10:29:49 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3DEJVTx000265; Wed, 13 Apr 2005 10:19:32 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 13 Apr 2005 10:19:37 -0400 Date: Wed, 13 Apr 2005 10:19:37 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] Re: Moving Forward Message-ID: <20050413141937.GE9774@skunk.reutershealth.com> References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org> <008a01c53ff1$5f473ea0$030aa8c0@DEWELL> <425CC58D.5DA@xyzzy.claranet.de> <20050413141218.GC9774@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050413141218.GC9774@skunk.reutershealth.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Scripsi: > Obscure languages are probably only written in one script, This should of course have read "Obscure languages are probably written, *if at all*, in only one script." Most of the world's languages are unwritten. -- Values of beeta will give rise to dom! John Cowan (5th/6th edition 'mv' said this if you tried http://www.ccil.org/~cowan to rename '.' or '..' entries; see jcowan@reutershealth.com http://cm.bell-labs.com/cm/cs/who/dmr/odd.html) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 10:49:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02619; Wed, 13 Apr 2005 10:49:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLjKu-0000rr-Ix; Wed, 13 Apr 2005 10:59:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjAk-00008i-FT; Wed, 13 Apr 2005 10:48:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjAi-000085-HE for ltru@megatron.ietf.org; Wed, 13 Apr 2005 10:48:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02599 for ; Wed, 13 Apr 2005 10:48:42 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLjKN-0000r9-84 for ltru@ietf.org; Wed, 13 Apr 2005 10:58:52 -0400 Received: from uknsprd1 (unverified) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 13 Apr 2005 14:48:31 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IEW005ML3SV2E@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 13 Apr 2005 15:48:31 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Wed, 13 Apr 2005 15:48:27 +0100 Date: Wed, 13 Apr 2005 15:48:13 +0100 From: Misha Wolf Subject: RE: [Ltru] OT: A Modest Proposal To: ltru Message-id: <1987416CA83AC7499AC772F92E2DBF780388D5A2@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] OT: A Modest Proposal Thread-Index: AcU/jbG/jcJT05XgSQeQ/afR0A1kOQAAJlxwACkUDFAAASKxsA== content-class: urn:content-classes:message X-OriginalArrivalTime: 13 Apr 2005 14:48:27.0666 (UTC) FILETIME=[DA1D4F20:01C54037] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable L.Gillam wrote: > Is there a native Klingon speaker who might be able to assist in=20 > the geospatial abstraction required? >=20 > Misha, you claim to represent billions of other peoples, yet I have > seen no evidence of existence of these other peoples. I submit that ample evidence for the existence of extra-terrestrials=20 can be found in the ltru and ietf-languages archives. The mails I am=20 referring to all purport to come from the same source and show=20 unmistakable signs of being penned by a creature from some parallel=20 Universe. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 10:56:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03127; Wed, 13 Apr 2005 10:56:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLjRh-00013S-BP; Wed, 13 Apr 2005 11:06:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjFS-0000yE-C4; Wed, 13 Apr 2005 10:53:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjFR-0000vZ-HS for ltru@megatron.ietf.org; Wed, 13 Apr 2005 10:53:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02964 for ; Wed, 13 Apr 2005 10:53:30 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLjP2-00010P-5v for ltru@ietf.org; Wed, 13 Apr 2005 11:03:40 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 07:53:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: [psg.com #882] registry should copy non-English fieldsfrom ISO documents Date: Wed, 13 Apr 2005 07:53:20 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA4764@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #882] registry should copy non-English fieldsfrom ISO documents Thread-Index: AcVAGk8uOLbv7ARdQtaGUgBy/88g7gAHfrGA From: "Addison Phillips" To: "Tex Texin" , "Doug Ewell" X-OriginalArrivalTime: 13 Apr 2005 14:53:21.0456 (UTC) FILETIME=[893A1B00:01C54038] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable We don't. The character set is Unicode. We only restrict the description = field to the Latin script by rule. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Tex Texin > Sent: mercredi 13 avril 2005 04:14 > To: Doug Ewell > Cc: LTRU Working Group > Subject: Re: [Ltru] Re: [psg.com #882] registry should copy = non-English > fieldsfrom ISO documents >=20 > fwiw, I wouldn't favor adding the French at this time. >=20 > As for Latin-1, if we move out of the ASCII realm, I would prefer > Unicode. We might not use chars out of the latin-1 set, but we = shouldn't > hem ourselves into a limited architecture. >=20 > My 2 cents. > tex >=20 > Doug Ewell wrote: > > > > Randy Presuhn = wrote: > > > > > Currently, here's where I think we are: > > > > > > Those in opposition are Randy, Addison, Mark, Peter, and Robin. > > > Those in support are Jefsey, John, Ned, and Doug. > > > > I prefer to be counted as "neutral" rather than "in support." I = meant > > it when I said 51-49: definitely not a decisive margin. I see both > > sides of this one. > > > > > Both John and Doug, as well as several of those who are neutral, > > > are opposed to Jefsey's provisos. > > > > Correct there. > > > > I note that if the inclusion of French continues to be portrayed as = a > > first step toward adding more translations, I will change my vote on = the > > French question to a clear "no." > > > > -Doug Ewell > > Fullerton, California > > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 > -- > ------------------------------------------------------------- > Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com > Xen Master http://www.i18nGuy.com >=20 > XenCraft http://www.XenCraft.com > Making e-Business Work Around the World > ------------------------------------------------------------- >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 11:12:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04372; Wed, 13 Apr 2005 11:12:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLjgw-0001Ub-JE; Wed, 13 Apr 2005 11:22:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjTQ-0003Y1-Qx; Wed, 13 Apr 2005 11:08:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjTP-0003X1-F8 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 11:08:11 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04019 for ; Wed, 13 Apr 2005 11:07:53 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050413150723.IFNY5402.mta11.adelphia.net@DEWELL> for ; Wed, 13 Apr 2005 11:07:23 -0400 Message-ID: <002701c5403a$796266e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050412220510.PWXC2124.mta7.adelphia.net@megatron.ietf.org> <009401c53ff3$f0c25e80$030aa8c0@DEWELL> <20050413134801.GB9774@skunk.reutershealth.com> Subject: Re: [Ltru] Re: Moving Forward Date: Wed, 13 Apr 2005 08:07:12 -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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit John Cowan wrote: > Indeed it should, the more so because Ottoman Turkish and modern Turkish > are really two separate languages with a major vocabulary barrier > (Persian and Perso-Arabic words in Ottoman that aren't found in modern > Turkish) between them. Indeed, they have separate ISO 639-2 codes, > ota and tur respecitvely. Whoops, I forgot *yet again* about ota. Bad example. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 11:29:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06004; Wed, 13 Apr 2005 11:29:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLjxS-0001ut-K6; Wed, 13 Apr 2005 11:39:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjhx-0005vA-Cb; Wed, 13 Apr 2005 11:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjhv-0005ud-T4 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 11:23:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05286 for ; Wed, 13 Apr 2005 11:23:01 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLjrb-0001mF-6Y for ltru@ietf.org; Wed, 13 Apr 2005 11:33:12 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 08:22:49 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 13 Apr 2005 08:22:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Moving Forward Date: Wed, 13 Apr 2005 08:22:51 -0700 Message-ID: Thread-Topic: [Ltru] Re: Moving Forward Thread-Index: AcVAMvjOSQOWvBDrS6KVwYi0Zx099QACGlSA From: "Peter Constable" To: X-OriginalArrivalTime: 13 Apr 2005 15:22:49.0237 (UTC) FILETIME=[A6E81450:01C5403C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of John Cowan > Note that the purpose of Associated_Script is > not to tell an implementer the usual script used with a language, but > simply to serve notice which script *subtags*, if any, should normally > be used with this language subtag. This difference is fundamental. We could make it more obvious, though. What about changing the label for the field to Expected_Script_Subtags? (I.e. 'it is expected that one of the following script subtags will also be used'.) > The specific answer is that for centuries Gothic has been written solely > in the Latin script. (This may start to change with the presence of > Gothic in Unicode and the ready availability of Gothic fonts, or it > may not.) Therefore, no Associated_Script header should be present, > and the tag got-Latn should be avoided (though got-Goth would be in > order as an unusual script). The one concern for our plan would be what to do if some apparently stable mono-script situation suddenly changes. If we tag "got" today, with Latin script assumed, and "got-Goth" for the unusual scenario, and then next year a reform gets underway with the result that in five years the situation has reversed, then what do we do?=20 Of course, I'm describing another scenario like Turkish, and those aren't all that likely. But a scenario such as going from only Cyrillic today to Cyrillic and Latin next year might not be so far fetched. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 11:30:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06059; Wed, 13 Apr 2005 11:30:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLjyY-0001xX-9p; Wed, 13 Apr 2005 11:40:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjle-00069X-R9; Wed, 13 Apr 2005 11:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjld-00068r-2r for ltru@megatron.ietf.org; Wed, 13 Apr 2005 11:27:01 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05901 for ; Wed, 13 Apr 2005 11:26:49 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050413152620.LXEX7277.mta10.adelphia.net@DEWELL> for ; Wed, 13 Apr 2005 11:26:20 -0400 Message-ID: <003101c5403d$1e0bce00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050413142051.UDNA2128.mta1.adelphia.net@megatron.ietf.org> Date: Wed, 13 Apr 2005 08:26:07 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > 2. mixed feelings among English culture Members, where confusion > results from the bundling of various questions in a single one "do you > support Jefsey's non detailed provision". Speaking only for myself, I wasn't confused at all. Randy's blanket term, "Jefsey's provisos," was sufficiently vague that I had to actually go back and read the post(s) in question, which I had skimmed over before. After reading them, I clearly understood Jefsey's various suggestions, and was confident of my opposition to them. Partitioning the group into "French culture Members" and "English culture Members" and pitting the two against each other is not how I thought consensus was built within Working Groups, but I could easily be wrong here. I don't have 27 years of Internet experience to draw on. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 11:34:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06556; Wed, 13 Apr 2005 11:34:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLk2b-00025b-95; Wed, 13 Apr 2005 11:44:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjpi-0006WT-MR; Wed, 13 Apr 2005 11:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjph-0006VS-Gg for ltru@megatron.ietf.org; Wed, 13 Apr 2005 11:31:13 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06132 for ; Wed, 13 Apr 2005 11:30:54 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050413153025.DFXU4618.mta13.adelphia.net@DEWELL> for ; Wed, 13 Apr 2005 11:30:25 -0400 Message-ID: <003401c5403d$b0632f00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050413142051.UDNA2128.mta1.adelphia.net@megatron.ietf.org> Date: Wed, 13 Apr 2005 08:30:12 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit John Cowan wrote: > A language tag generator UI, therefore, should have two modes, normal > script mode and unusual script mode. In normal script mode, only the > scripts in Associated_Script should be offered to the user (and if > there is no such header, then no scripts should be offered). In > unusual script mode, every script should be offered. > > (Hint, hint, Doug.) Interesting thought. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 11:44:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07364; Wed, 13 Apr 2005 11:44:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkCo-0002O9-B9; Wed, 13 Apr 2005 11:55:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjzo-0007x8-4T; Wed, 13 Apr 2005 11:41:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLjzl-0007w2-Tt for ltru@megatron.ietf.org; Wed, 13 Apr 2005 11:41:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07088 for ; Wed, 13 Apr 2005 11:41:27 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLk9R-0002GG-A9 for ltru@ietf.org; Wed, 13 Apr 2005 11:51:38 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Wed, 13 Apr 2005 08:41:17 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 13 Apr 2005 08:41:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Great Script Debate Part II: Formats... Date: Wed, 13 Apr 2005 08:41:20 -0700 Message-ID: Thread-Topic: [Ltru] Great Script Debate Part II: Formats... Thread-Index: AcVAMuhvJe2QK1ybQPmUbB2TYsuWqQACkmfg From: "Peter Constable" To: "ltru Working Group" X-OriginalArrivalTime: 13 Apr 2005 15:41:17.0916 (UTC) FILETIME=[3BBB11C0:01C5403F] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of JFC (Jefsey) Morfin > What I oppose in "your" position, is four things: dominance, lack of QA, > complexity, inconsistency, decency. Since you certainly do not see where > let me explain again. >=20 > - dominance is not good because it is not appropriate to the network > architecture. *Prominance* of certain languages within international standards is an accepted reality. In limiting names to a single form, we are using a practice considered at least acceptable within ISO; and if we compare with the common ISO practice of using two languages, relative to the 6900+ living languages in the world today, we're talking about a 0.0145% difference. > - lack of QA results from abandon of cross culture control and protection. This is a preposterous claim. Limiting names to one language does not imply in any way that there is a lack of QA. The two are completely independent. Moreover, since the registry will use names taken from ISO source standards, we have little control over QA in most cases. > - complexity. The hook of a language is not an easy thing because > printf("$stringNN") is not a programer reflex. In permitting to have a > single reference name, you do not oblige programers to support several > languages (when there are two, there are hooks for all). This is another preposterous claim. If we included names in 1000 languages, we would not be obliging programmers to support more than one language. It is not the documentation within this registry that causes programmers to support multiple languages; it is the market in which they wish to sell their products. The fact that they are even looking at this registry, by virtue of the different languages for which there are tags, reflects that they already *are* supporting multiple languages, regardless of how many languages we use to document each entry. =20 > - inconsistency. We know that the reference names are just because France > accepted not to delay ISO 639-3 (I concurred) in having not the > budget/people to carry the work. Bingo! This is a question of resources, IMO. We should not burden the Language Tag Reviewer, IANA or anyone else by requiring names in multiple languages to be maintained. There is nothing inconsistent in this. > - decency... Everything you said does not even pertain to the issue of whether to include more than one language, hence is irrelevant to that discussion. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 11:46:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07492; Wed, 13 Apr 2005 11:46:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkED-0002Qa-KN; Wed, 13 Apr 2005 11:56:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLk3T-00004s-8F; Wed, 13 Apr 2005 11:45:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLk3S-0008VI-6Q for ltru@megatron.ietf.org; Wed, 13 Apr 2005 11:45:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07422 for ; Wed, 13 Apr 2005 11:45:15 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLkD7-0002Od-IK for ltru@ietf.org; Wed, 13 Apr 2005 11:55:26 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 13 Apr 2005 16:19:59 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 16:19:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] OT: A Modest Proposal Date: Wed, 13 Apr 2005 16:19:57 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A3A4@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] OT: A Modest Proposal Thread-Index: AcU/jbG/jcJT05XgSQeQ/afR0A1kOQAAJlxwACkUDFAAASKxsAABT/hQ From: "L.Gillam" To: ltru X-OriginalArrivalTime: 13 Apr 2005 15:19:58.0212 (UTC) FILETIME=[40F7BC40:01C5403C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable I see. Then we must stop all activity forthwith to take full account of the requirements of the creature and change the entire world accordingly without regard for cost, effort or other such pragmatic considerations.=20 Tell me, though, does it *need* language tags? > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Misha Wolf > Sent: 13 April 2005 15:48 > To: ltru > Subject: RE: [Ltru] OT: A Modest Proposal >=20 >=20 > L.Gillam wrote: >=20 > > Is there a native Klingon speaker who might be able to assist in=20 > > the geospatial abstraction required? > >=20 > > Misha, you claim to represent billions of other peoples, yet I have > > seen no evidence of existence of these other peoples. >=20 > I submit that ample evidence for the existence of extra-terrestrials=20 > can be found in the ltru and ietf-languages archives. The mails I am=20 > referring to all purport to come from the same source and show=20 > unmistakable signs of being penned by a creature from some parallel=20 > Universe. >=20 > Misha >=20 >=20 >=20 >=20 > ----------------------------------------------------------------- > Visit our Internet site at http://www.reuters.com >=20 > To find out more about Reuters Products and Services visit=20 > http://www.reuters.com/productinfo=20 >=20 > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be > the views of Reuters Ltd. >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 11:48:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07634; Wed, 13 Apr 2005 11:48:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkFm-0002Ty-N6; Wed, 13 Apr 2005 11:58:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLk5o-00013Y-Eo; Wed, 13 Apr 2005 11:47:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLk5n-0000v8-1h for ltru@megatron.ietf.org; Wed, 13 Apr 2005 11:47:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07607 for ; Wed, 13 Apr 2005 11:47:43 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkFV-0002TH-Hn for ltru@ietf.org; Wed, 13 Apr 2005 11:57:54 -0400 Received: from uknsprd1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 13 Apr 2005 15:47:32 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IEW003IE6J7Z6@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 13 Apr 2005 16:47:31 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Wed, 13 Apr 2005 16:47:25 +0100 Date: Wed, 13 Apr 2005 16:46:13 +0100 From: Misha Wolf Subject: RE: [Ltru] Moving Forward To: ltru Message-id: <1987416CA83AC7499AC772F92E2DBF780388D605@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Moving Forward Thread-Index: AcVAMvjOSQOWvBDrS6KVwYi0Zx099QACGlSAAADjDrA= content-class: urn:content-classes:message X-OriginalArrivalTime: 13 Apr 2005 15:47:25.0329 (UTC) FILETIME=[16B9D810:01C54040] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Peter Constable wrote: > The one concern for our plan would be what to do if some=20 > apparently stable mono-script situation suddenly changes. If we=20 > tag "got" today, with Latin script assumed, and "got-Goth" for the=20 > unusual scenario, and then next year a reform gets underway with=20 > the result that in five years the situation has reversed, then=20 > what do we do?=20 >=20 > Of course, I'm describing another scenario like Turkish, and those=20 > aren't all that likely. But a scenario such as going from only=20 > Cyrillic today to Cyrillic and Latin next year might not be so far=20 > fetched. Indeed. At that point we would change the record for the affected=20 language to have an Expected_Script_Subtags field. Old tags would=20 be "ll", while new tags would be "ll-Cyrl" or "ll-Latn". Search for=20 "ll" would work fine (ie return all stuff tagged with "ll*"), as=20 would searches for "ll-Cyrl" or "ll-Latn". Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 12:07:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09211; Wed, 13 Apr 2005 12:07:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkYG-000328-3B; Wed, 13 Apr 2005 12:17:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLkEP-0002aH-0N; Wed, 13 Apr 2005 11:56:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLkEN-0002ZZ-Ey for ltru@megatron.ietf.org; Wed, 13 Apr 2005 11:56:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08255 for ; Wed, 13 Apr 2005 11:56:33 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLkO3-0002iM-KW for ltru@ietf.org; Wed, 13 Apr 2005 12:06:44 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 13 Apr 2005 16:45:28 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 16:45:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Great Script Debate Part II: Formats... Date: Wed, 13 Apr 2005 16:45:27 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A3A6@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Great Script Debate Part II: Formats... Thread-Index: AcVAM/3HvgLxMcpmSMqRHTerbdtPQQACTcPg From: "L.Gillam" To: ltru X-OriginalArrivalTime: 13 Apr 2005 15:45:27.0639 (UTC) FILETIME=[D093C670:01C5403F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Content-Transfer-Encoding: quoted-printable I wonder what the most used 2nd (i.e. non-native spoken/written)=20 language in the world happens to be, which helps people to discuss where discussion may otherwise be limited? "language is the first and basic social contract of a nation" "printf("$stringNN") is not a programer reflex" These two statements, and the rest of what you've written, is impenetrable. http://minc.org?=20 Perhaps http://www.minc.org/WG/arabic/ and the key arabic language=20 documents for IDN deployment may help you? Perhaps a look at their history will help you? "After years of working on the multilingualisation of Internet content = and software with the vision of lowering linguistic barriers for = non-native English speakers of the Asian region, his attention was drawn = towards the naming problem.=20 .. Whereas content in the Internet was rapidly proliferating in native = languages, the URLs, email addresses, hostnames and domain names, still = did not support multilingual scripts. " They seem to have identified particular needs and have no trouble that I = can see with existing ISO standards. NB, though, "The Arabic working group does not have the mandate to look=20 after larger issues with regards to the Arabic language and=20 the Internet such as Arabicisation of ISO 3166, keyboard input,=20 Arabic internet glossary, and many other Arabic language IT issues." > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > Sent: 13 April 2005 14:27 > To: Gillam L Dr (Computing) > Cc: ltru Working Group > Subject: RE: [Ltru] Great Script Debate Part II: Formats... >=20 >=20 > Dear L.Guillam, > this certainly is a right of everyone - and a possibility and=20 > a certain=20 > work. This is the same as for 10646: building a list of name of usage=20 > correcting or adapting the 100646 names to the reality of=20 > usage. And be=20 > sure this is exactly what we are working on as a prototype CRC. >=20 > What I oppose in "your" position, is four things: dominance,=20 > lack of QA,=20 > complexity, inconsistency, decency. Since you certainly do=20 > not see where=20 > let me explain again. >=20 > - dominance is not good because it is not appropriate to the network=20 > architecture. Since Paul Bahan in the 60s and the work=20 > carried in the 80s=20 > we know that networks can be centralized by a dominance,=20 > decentralised by a=20 > governance, distributed by an intergovernance. These are natural=20 > interest/forces/solutions which are the very architecture of=20 > every network.=20 > They mostly result of their granularity, which means for wide=20 > systems of=20 > their density. Today the internet itself which started in a=20 > centralised=20 > development phase (mid 80s) to a decentralised deployment=20 > phase (mid 90s)=20 > enter its distributed scalability phase. Dominance concepts=20 > (IANA, ICANN,=20 > ASCII, English) were until now acceptable as only "old". They become=20 > progressively totally outdated and an architectural flaw more=20 > and more=20 > people and concept will oppose and already suffer from. The idea of a=20 > reviewer in English for the language of the world, was a=20 > bizarre oddity, it=20 > is becoming an unacceptable bug. >=20 > - lack of QA results from abandon of cross culture control=20 > and protection.=20 > Look at the ieft-languages list and at this list. How many people of=20 > English/non English culture/mother tongue when we are=20 > precisely discussing=20 > languages and cultures. Look at the number of represented=20 > nationalities=20 > when you know (and this is what is precisely discussed and=20 > acknowledged=20 > through the ISO 3166 country codes) a language is the first and basic=20 > social contract of a nation. I am not interested here in=20 > politics but in=20 > quality. Look at the number of wrong 10646 names in spite of all the=20 > accumulated efforts. Look at the ietf-languages lists which=20 > doubled the=20 > considered Greek languages tags when I called upon the Greek=20 > ccTLD and the=20 > University of Athens. There is a need for cross cultural=20 > control. This=20 > control is provided by French for centuries and at ISO. Be=20 > sure I will not=20 > accept that all of us we lose that QA. >=20 > - complexity. The hook of a language is not an easy thing because=20 > printf("$stringNN") is not a programer reflex. In permitting=20 > to have a=20 > single reference name, you do not oblige programers to=20 > support several=20 > languages (when there are two, there are hooks for all). >=20 > - inconsistency. We know that the reference names are just=20 > because France=20 > accepted not to delay ISO 639-3 (I concurred) in having not the=20 > budget/people to carry the work. The response was "we will=20 > use autonyms".=20 > Autonyms would be nice. But "fra french" is not really an=20 > autonym. Now, the=20 > problem is may be something we could fix. We have to discuss. >=20 > - decency. A Draft has been introduced twice, and failed. We=20 > (ietf@ietf.org=20 > opponents) proposed a small rewrite of two or three point or=20 > a real WG. A=20 > WG and a charter have resulted, which uses the same Draft.=20 > And while the=20 > Draft is not even submitted to the IESG the Draft is=20 > enforced. This is=20 > playing a lot on a very well known idea: people today cannot=20 > be internet=20 > builder anymore, so they are afraid of being remembered as Internet=20 > wreckers, and they do not dare to oppose. It happens that I=20 > do not fear=20 > that: my past is behind me already. But I do not want to be=20 > remembered as=20 > the one "who could have" ... As pointed out in another mail,=20 > the problem=20 > here is that it is a call to extremism. Everyone serious=20 > outside of this=20 > long working together group, and interested (but IAB, IESG=20 > and IETF is not=20 > really interested in multilingualism), sees that the Draft is=20 > a clumsy=20 > attempt at proposing an XML patch (Addison well documented=20 > it) and will=20 > oppose it to be made a Multilingual Internet confusion. In=20 > the process=20 > these "everyone" will most likely fight and forget Addison's=20 > legitimate=20 > need for solution to the real, urgent and important (but not=20 > fundamental)=20 > need of an XML patch. >=20 > all the best. > jfc >=20 > PS. Since you are going to tell me "and why IAB, IESG and IETF is not=20 > interested ???", what result from observation (for example=20 > the very odd RFC=20 > 3869 which is a call of IAB to Governments for Internet R&D=20 > financing and=20 > does not even allude to languages after 192 unanimous=20 > Governments made it=20 > their priority and it is the US year of multilingualism). I=20 > started a draft=20 > last summer on the way the Internet standard process could=20 > support the=20 > documentation of a Multilingual Internet. It was interrupted=20 > by the RFC=20 > 3066 bis saga. From this I think it is the syndrome I quoted=20 > above and Vint=20 > made his leit-motive "why to fix what ain't broke". The architectural=20 > change is huge. The problem is that the question is not "to=20 > fix what would=20 > be broken", but "to replace what is outdated". >=20 > PS. In case you ask what the hell can be a "Multilingual Internet", I=20 > suggest to use http://minc.org . You may not know it, but it=20 > terms of users=20 > it is a substantial one. Not so far from the majority if not=20 > already the=20 > majority. But the growth of the ASCII Internet is so slow=20 > (800 millions=20 > against 1.4 billion mobiles). Vernacular is not supported.=20 > Architecture is=20 > too rigid. >=20 >=20 >=20 > 13:22 13/04/2005, L.Gillam said: >=20 > >Jefsey, > > > >For once I find I might be able agree with you - I might > >have misunderstood you however, so please don't comment > >it as a certainty. > > > >Reference name provides the "hook", as you refer to it. > >You (2nd person singular/plural) can provide whatever additional > >translations you (2nd person singular/plural) desire for such > >reference names, in whatever languages you (..) desire, > >keep whatever local copies you (..) wish, and so on. The > >problem you are making for people on this list is that > >you (2nd person singular) seem to be insisting that the registry > >MUST contain names in EVERY language for EVERY language, or should > >produce translations where they are not available from the source > >standards (e.g. reference names in 639-3). I see little purpose - > >we are taking about "names" that help to identify tags, not > >imposing restrictions on "languages", per se, which would > >be somewhat different. > > > >Nobody is prevented from creating French names for these > >7000 reference names, German names, Slovakian names, and > >so on. Making it a necessary and essential task is > >unrealistic - look at the army of translators needed by > >the EU, for example. > > > >As I said, feel free to create your own hooks in other > >languages of your (2nd s/p) choice for your (2nd s/p) > >presentation - provided that in interchange the presented > >item transforms into the correct tag there will be no > >difficulties. > > > > > -----Original Message----- > > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > > Sent: 12 April 2005 17:48 > > > To: Gillam L Dr (Computing); ltru > > > Subject: RE: [Ltru] Great Script Debate Part II: Formats... > > > > > > > > > I think you are globally right. > > > > > > At 16:50 12/04/2005, L.Gillam wrote: > > > Where did I make something forbidden Jefsey? > > > > > > Ah! I thought you wanted to forbid French and hooks for other > > > languages. > > > > > > On the contrary, > > > >I think you'll find I say there are certain things we should > > > >not impose (just above here for example). > > > > > > This implies that default references should be autonyms?=20 > I was wrong > > > reading you differently. > > > > > > >Quite the reverse. Please do not twist what I, or indeed > > > others, write in > > > >an attempt to validate your position. > > > > > > I have no position. Just observation. When I say that the > > > lack of support > > > of English and French is a blocking element. This is because > > > I observe that > > > it will be real world blocking, because applications are > > > under current > > > development and projects under financing which say otherwise. > > > > > > >There's a "forbid" if you want one. > > > > > > How rigth you are. > > > jfc > > > > > > PS. I suppose you will want to respond I a wrong or > > > unintelligible. No > > > need, I have already taken your response into account. > > > > > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 12:23:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10839; Wed, 13 Apr 2005 12:23:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkoV-0003db-DE; Wed, 13 Apr 2005 12:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLkcV-00051o-R1; Wed, 13 Apr 2005 12:21:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLkcU-00050F-Bo for ltru@megatron.ietf.org; Wed, 13 Apr 2005 12:21:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10579 for ; Wed, 13 Apr 2005 12:21:27 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkmA-0003XL-DJ for ltru@ietf.org; Wed, 13 Apr 2005 12:31:39 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3DGLKXK010281 for ; Wed, 13 Apr 2005 12:21:20 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3DGLHEA241322 for ; Wed, 13 Apr 2005 12:21:20 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3DGL6p5032175 for ; Wed, 13 Apr 2005 12:21:06 -0400 Received: from markdavis (mark-davis.cupertino.ibm.com [9.52.67.128]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with SMTP id j3DGL40U031937; Wed, 13 Apr 2005 12:21:05 -0400 Message-ID: <002b01c54044$ca8ab950$4109fea9@sanjose.ibm.com> From: "Mark Davis" To: "L.Gillam" , "ltru" References: <4A7C6FA2AB31194E80E13FE585F6A21292A3A6@EVS-EC1-NODE1.surrey.ac.uk> Subject: Off Topic (was Re: [Ltru] Great Script Debate Part II: Formats...) Date: Wed, 13 Apr 2005 09:20:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e2.ny.us.ibm.com id j3DGLKXK010281 X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Content-Transfer-Encoding: quoted-printable For one metric, see "GDP by Language" http://www.unicode.org/notes/tn13/ =E2=80=8EMark ----- Original Message -----=20 From: "L.Gillam" To: "ltru" Sent: Wednesday, April 13, 2005 08:45 Subject: RE: [Ltru] Great Script Debate Part II: Formats... I wonder what the most used 2nd (i.e. non-native spoken/written) language in the world happens to be, which helps people to discuss where discussion may otherwise be limited? "language is the first and basic social contract of a nation" "printf("$stringNN") is not a programer reflex" These two statements, and the rest of what you've written, is impenetrable. http://minc.org? Perhaps http://www.minc.org/WG/arabic/ and the key arabic language documents for IDN deployment may help you? Perhaps a look at their history will help you? "After years of working on the multilingualisation of Internet content an= d software with the vision of lowering linguistic barriers for non-native English speakers of the Asian region, his attention was drawn towards the naming problem. .. Whereas content in the Internet was rapidly proliferating in native languages, the URLs, email addresses, hostnames and domain names, still d= id not support multilingual scripts. " They seem to have identified particular needs and have no trouble that I = can see with existing ISO standards. NB, though, "The Arabic working group does not have the mandate to look after larger issues with regards to the Arabic language and the Internet such as Arabicisation of ISO 3166, keyboard input, Arabic internet glossary, and many other Arabic language IT issues." > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > Sent: 13 April 2005 14:27 > To: Gillam L Dr (Computing) > Cc: ltru Working Group > Subject: RE: [Ltru] Great Script Debate Part II: Formats... > > > Dear L.Guillam, > this certainly is a right of everyone - and a possibility and > a certain > work. This is the same as for 10646: building a list of name of usage > correcting or adapting the 100646 names to the reality of > usage. And be > sure this is exactly what we are working on as a prototype CRC. > > What I oppose in "your" position, is four things: dominance, > lack of QA, > complexity, inconsistency, decency. Since you certainly do > not see where > let me explain again. > > - dominance is not good because it is not appropriate to the network > architecture. Since Paul Bahan in the 60s and the work > carried in the 80s > we know that networks can be centralized by a dominance, > decentralised by a > governance, distributed by an intergovernance. These are natural > interest/forces/solutions which are the very architecture of > every network. > They mostly result of their granularity, which means for wide > systems of > their density. Today the internet itself which started in a > centralised > development phase (mid 80s) to a decentralised deployment > phase (mid 90s) > enter its distributed scalability phase. Dominance concepts > (IANA, ICANN, > ASCII, English) were until now acceptable as only "old". They become > progressively totally outdated and an architectural flaw more > and more > people and concept will oppose and already suffer from. The idea of a > reviewer in English for the language of the world, was a > bizarre oddity, it > is becoming an unacceptable bug. > > - lack of QA results from abandon of cross culture control > and protection. > Look at the ieft-languages list and at this list. How many people of > English/non English culture/mother tongue when we are > precisely discussing > languages and cultures. Look at the number of represented > nationalities > when you know (and this is what is precisely discussed and > acknowledged > through the ISO 3166 country codes) a language is the first and basic > social contract of a nation. I am not interested here in > politics but in > quality. Look at the number of wrong 10646 names in spite of all the > accumulated efforts. Look at the ietf-languages lists which > doubled the > considered Greek languages tags when I called upon the Greek > ccTLD and the > University of Athens. There is a need for cross cultural > control. This > control is provided by French for centuries and at ISO. Be > sure I will not > accept that all of us we lose that QA. > > - complexity. The hook of a language is not an easy thing because > printf("$stringNN") is not a programer reflex. In permitting > to have a > single reference name, you do not oblige programers to > support several > languages (when there are two, there are hooks for all). > > - inconsistency. We know that the reference names are just > because France > accepted not to delay ISO 639-3 (I concurred) in having not the > budget/people to carry the work. The response was "we will > use autonyms". > Autonyms would be nice. But "fra french" is not really an > autonym. Now, the > problem is may be something we could fix. We have to discuss. > > - decency. A Draft has been introduced twice, and failed. We > (ietf@ietf.org > opponents) proposed a small rewrite of two or three point or > a real WG. A > WG and a charter have resulted, which uses the same Draft. > And while the > Draft is not even submitted to the IESG the Draft is > enforced. This is > playing a lot on a very well known idea: people today cannot > be internet > builder anymore, so they are afraid of being remembered as Internet > wreckers, and they do not dare to oppose. It happens that I > do not fear > that: my past is behind me already. But I do not want to be > remembered as > the one "who could have" ... As pointed out in another mail, > the problem > here is that it is a call to extremism. Everyone serious > outside of this > long working together group, and interested (but IAB, IESG > and IETF is not > really interested in multilingualism), sees that the Draft is > a clumsy > attempt at proposing an XML patch (Addison well documented > it) and will > oppose it to be made a Multilingual Internet confusion. In > the process > these "everyone" will most likely fight and forget Addison's > legitimate > need for solution to the real, urgent and important (but not > fundamental) > need of an XML patch. > > all the best. > jfc > > PS. Since you are going to tell me "and why IAB, IESG and IETF is not > interested ???", what result from observation (for example > the very odd RFC > 3869 which is a call of IAB to Governments for Internet R&D > financing and > does not even allude to languages after 192 unanimous > Governments made it > their priority and it is the US year of multilingualism). I > started a draft > last summer on the way the Internet standard process could > support the > documentation of a Multilingual Internet. It was interrupted > by the RFC > 3066 bis saga. From this I think it is the syndrome I quoted > above and Vint > made his leit-motive "why to fix what ain't broke". The architectural > change is huge. The problem is that the question is not "to > fix what would > be broken", but "to replace what is outdated". > > PS. In case you ask what the hell can be a "Multilingual Internet", I > suggest to use http://minc.org . You may not know it, but it > terms of users > it is a substantial one. Not so far from the majority if not > already the > majority. But the growth of the ASCII Internet is so slow > (800 millions > against 1.4 billion mobiles). Vernacular is not supported. > Architecture is > too rigid. > > > > 13:22 13/04/2005, L.Gillam said: > > >Jefsey, > > > >For once I find I might be able agree with you - I might > >have misunderstood you however, so please don't comment > >it as a certainty. > > > >Reference name provides the "hook", as you refer to it. > >You (2nd person singular/plural) can provide whatever additional > >translations you (2nd person singular/plural) desire for such > >reference names, in whatever languages you (..) desire, > >keep whatever local copies you (..) wish, and so on. The > >problem you are making for people on this list is that > >you (2nd person singular) seem to be insisting that the registry > >MUST contain names in EVERY language for EVERY language, or should > >produce translations where they are not available from the source > >standards (e.g. reference names in 639-3). I see little purpose - > >we are taking about "names" that help to identify tags, not > >imposing restrictions on "languages", per se, which would > >be somewhat different. > > > >Nobody is prevented from creating French names for these > >7000 reference names, German names, Slovakian names, and > >so on. Making it a necessary and essential task is > >unrealistic - look at the army of translators needed by > >the EU, for example. > > > >As I said, feel free to create your own hooks in other > >languages of your (2nd s/p) choice for your (2nd s/p) > >presentation - provided that in interchange the presented > >item transforms into the correct tag there will be no > >difficulties. > > > > > -----Original Message----- > > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > > Sent: 12 April 2005 17:48 > > > To: Gillam L Dr (Computing); ltru > > > Subject: RE: [Ltru] Great Script Debate Part II: Formats... > > > > > > > > > I think you are globally right. > > > > > > At 16:50 12/04/2005, L.Gillam wrote: > > > Where did I make something forbidden Jefsey? > > > > > > Ah! I thought you wanted to forbid French and hooks for other > > > languages. > > > > > > On the contrary, > > > >I think you'll find I say there are certain things we should > > > >not impose (just above here for example). > > > > > > This implies that default references should be autonyms? > I was wrong > > > reading you differently. > > > > > > >Quite the reverse. Please do not twist what I, or indeed > > > others, write in > > > >an attempt to validate your position. > > > > > > I have no position. Just observation. When I say that the > > > lack of support > > > of English and French is a blocking element. This is because > > > I observe that > > > it will be real world blocking, because applications are > > > under current > > > development and projects under financing which say otherwise. > > > > > > >There's a "forbid" if you want one. > > > > > > How rigth you are. > > > jfc > > > > > > PS. I suppose you will want to respond I a wrong or > > > unintelligible. No > > > need, I have already taken your response into account. > > > > > > > > > >_______________________________________________ > >Ltru mailing list > >Ltru@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 12:25:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10982; Wed, 13 Apr 2005 12:25:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkps-0003g6-KU; Wed, 13 Apr 2005 12:35:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLkfv-0006Ev-6y; Wed, 13 Apr 2005 12:25:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLkfu-0006Ck-4o for ltru@megatron.ietf.org; Wed, 13 Apr 2005 12:25:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10971 for ; Wed, 13 Apr 2005 12:24:59 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLkpa-0003fn-2V for ltru@ietf.org; Wed, 13 Apr 2005 12:35:11 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3DGOoSm001001; Wed, 13 Apr 2005 12:24:51 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 13 Apr 2005 12:24:55 -0400 Date: Wed, 13 Apr 2005 12:24:55 -0400 From: John Cowan To: "L.Gillam" Subject: Re: [Ltru] Great Script Debate Part II: Formats... Message-ID: <20050413162454.GA11166@skunk.reutershealth.com> References: <4A7C6FA2AB31194E80E13FE585F6A21292A3A6@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A3A6@EVS-EC1-NODE1.surrey.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 L.Gillam scripsit: > > I wonder what the most used 2nd (i.e. non-native spoken/written) > language in the world happens to be, which helps people to discuss > where discussion may otherwise be limited? Mandarin Chinese is the most widely taught *second* language in the world. English is the most widely taught *foreign* language in the world, however, since most people who are taught Mandarin Chinese as a second language are residents of China. Note also that those who are taught and those who learn may or may not be the same. > "language is the first and basic social contract of a nation" This remark isn't impenetrable; it's just true of some nations (Poland and Bangladesh come to mind) and false of others (Nigeria comes to mind). All nations have speakers of minority languages, but some nations make a common language central to their national identity. -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp. --Greenspun's Tenth Rule of Programming (rules 1-9 are unknown) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 12:44:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12359; Wed, 13 Apr 2005 12:44:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLl8h-0004Bl-76; Wed, 13 Apr 2005 12:54:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLkui-00006K-8U; Wed, 13 Apr 2005 12:40:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfbY-0008MR-2q for ltru@megatron.ietf.org; Wed, 13 Apr 2005 07:00:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14678 for ; Wed, 13 Apr 2005 07:00:09 -0400 (EDT) Received: from smtp04.mrf.mail.rcn.net ([207.172.4.63]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLflC-0003C1-0Z for ltru@ietf.org; Wed, 13 Apr 2005 07:10:18 -0400 Received: from c-24-6-51-238.hsd1.ca.comcast.net (HELO xencraft.com) (24.6.51.238) by smtp04.mrf.mail.rcn.net with ESMTP; 13 Apr 2005 07:00:11 -0400 Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.9.7]); Wed, 13 Apr 2005 04:00:12 -0700 Message-ID: <425CFBBC.636F3344@xencraft.com> Date: Wed, 13 Apr 2005 04:00:12 -0700 From: Tex Texin Organization: http://www.XenCraft.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Doug Ewell Subject: Re: [Ltru] Re: [psg.com #882] registry should copy non-English fieldsfrom ISO documents References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org> <008301c53fee$ea35fc20$030aa8c0@DEWELL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 13 Apr 2005 12:40:26 -0400 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit fwiw, I wouldn't favor adding the French at this time. As for Latin-1, if we move out of the ASCII realm, I would prefer Unicode. We might not use chars out of the latin-1 set, but we shouldn't hem ourselves into a limited architecture. My 2 cents. tex Doug Ewell wrote: > > Randy Presuhn wrote: > > > Currently, here's where I think we are: > > > > Those in opposition are Randy, Addison, Mark, Peter, and Robin. > > Those in support are Jefsey, John, Ned, and Doug. > > I prefer to be counted as "neutral" rather than "in support." I meant > it when I said 51-49: definitely not a decisive margin. I see both > sides of this one. > > > Both John and Doug, as well as several of those who are neutral, > > are opposed to Jefsey's provisos. > > Correct there. > > I note that if the inclusion of French continues to be portrayed as a > first step toward adding more translations, I will change my vote on the > French question to a clear "no." > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru -- ------------------------------------------------------------- Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com Xen Master http://www.i18nGuy.com XenCraft http://www.XenCraft.com Making e-Business Work Around the World ------------------------------------------------------------- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 12:55:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13355; Wed, 13 Apr 2005 12:55:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLlJG-0004Yg-E0; Wed, 13 Apr 2005 13:05:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLl77-0002Fo-6n; Wed, 13 Apr 2005 12:53:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLl75-0002Eh-O1 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 12:53:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13082 for ; Wed, 13 Apr 2005 12:53:04 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLlGk-0004TT-OT for ltru@ietf.org; Wed, 13 Apr 2005 13:03:17 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 13 Apr 2005 17:52:30 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 17:52:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: OT - RE: [Ltru] Great Script Debate Part II: Formats... Date: Wed, 13 Apr 2005 17:52:29 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A3AF@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Great Script Debate Part II: Formats... Thread-Index: AcVARalC9112BCQSRm2MiqAfDhXB5AAA5aKw From: "L.Gillam" To: ltru X-OriginalArrivalTime: 13 Apr 2005 16:52:29.0415 (UTC) FILETIME=[2DBE1770:01C54049] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable The remark itself, with the validation you document, I can understand. But the generalisation, and the purpose of the remark....... well, I am unable to pass through it to get somewhere useful.=20 > > "language is the first and basic social contract of a nation" >=20 > This remark isn't impenetrable; it's just true of some=20 > nations (Poland and > Bangladesh come to mind) and false of others (Nigeria comes to mind). > All nations have speakers of minority languages, but some nations make > a common language central to their national identity. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 12:57:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13510; Wed, 13 Apr 2005 12:57:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLlLD-0004cH-2o; Wed, 13 Apr 2005 13:07:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLl8y-0002XB-8v; Wed, 13 Apr 2005 12:55:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLl8x-0002Vn-36 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 12:55:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13276 for ; Wed, 13 Apr 2005 12:55:00 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLlId-0004WX-1z for ltru@ietf.org; Wed, 13 Apr 2005 13:05:12 -0400 Received: from eupig1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 13 Apr 2005 16:54:47 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IEW00JCM9NBSG@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 13 Apr 2005 16:54:47 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Wed, 13 Apr 2005 16:54:47 +0000 Date: Wed, 13 Apr 2005 17:54:47 +0100 From: Misha Wolf Subject: RE: [Ltru] OT: Cultural imperialism? To: ltru MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] OT: Cultural imperialism? Thread-Index: AcVASCGGjUn4v9XUTe6fTyjAIXVk7gAAPAuA content-class: urn:content-classes:message X-OriginalArrivalTime: 13 Apr 2005 16:54:47.0609 (UTC) FILETIME=[801CD290:01C54049] X-Spam-Score: 0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Tex Texin wrote: > My 2 cents. Are these US cents or Euro-cents? In either case, they discriminate against the billions of peoples who don't use cents. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 13:09:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14673; Wed, 13 Apr 2005 13:09:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLlWD-00054d-Oo; Wed, 13 Apr 2005 13:19:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLlKF-0005PI-Sn; Wed, 13 Apr 2005 13:06:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLlKE-0005Ox-HH for ltru@megatron.ietf.org; Wed, 13 Apr 2005 13:06:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14408 for ; Wed, 13 Apr 2005 13:06:39 -0400 (EDT) Received: from web42006.mail.yahoo.com ([66.218.93.174]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLlTv-0004xW-KW for ltru@ietf.org; Wed, 13 Apr 2005 13:16:52 -0400 Received: (qmail 5440 invoked by uid 60001); 13 Apr 2005 17:06:32 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=GLwOb1pFbfiu8KCoFjwewvwvBPUY6t2zJtHjA5psU3qjDPO5AWgC94/ZiYYdpTqRWmPbypiiYsd/q+bM8tJKgw02xlRhpXsiIj5Xtvz9p3ZyBNbMIL5f+1CDi20VhyJWUhmIbNdBv9potqC4qLg0SwHr8oiSjE+yY8mEHHAZyp4= ; Message-ID: <20050413170632.5438.qmail@web42006.mail.yahoo.com> Received: from [83.99.63.34] by web42006.mail.yahoo.com via HTTP; Wed, 13 Apr 2005 18:06:32 BST Date: Wed, 13 Apr 2005 18:06:32 +0100 (BST) From: "M.T. Carrasco Benitez" Subject: RE: [Ltru] Moving Forward To: ltru@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 8bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 8bit > [Wolf] > > [Constable] > > Of course, I'm describing another scenario like Turkish, and those > > aren't all that likely. But a scenario such as going from only > > Cyrillic today to Cyrillic and Latin next year might not be so far > > fetched. > > [Wolf] > Indeed. At that point we would change the record for the affected > language to have an Expected_Script_Subtags field. Old tags would > be "ll", while new tags would be "ll-Cyrl" or "ll-Latn". Search for > "ll" would work fine (ie return all stuff tagged with "ll*"), as > would searches for "ll-Cyrl" or "ll-Latn". In the very unlikely event that a language goes back to a previous script and the script subtag does not work anymore, one can handle this with: - New variant - New language code For example, with Turkish: - Code before 1500 ? - 1500-1928: tr-Arab (I assume); ISO-639-2 "ota" turc ottoman - Present: tr (in Latn) - Future back to Arab: tr-Arab, hence clash with 1500-1928. - New variant: tr-foo - New language code: foo The approach of 3066bis should be sufficient. Otherwise, we could generalize the Special David-Wolf Proposition. Regards Tomas Send instant messages to your online friends http://uk.messenger.yahoo.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 13:16:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15297; Wed, 13 Apr 2005 13:16:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLldX-0005J3-0K; Wed, 13 Apr 2005 13:26:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLlTW-0007jJ-Iv; Wed, 13 Apr 2005 13:16:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLlTV-0007c6-0j for ltru@megatron.ietf.org; Wed, 13 Apr 2005 13:16:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15230 for ; Wed, 13 Apr 2005 13:15:29 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLlcS-0005HX-81 for ltru@ietf.org; Wed, 13 Apr 2005 13:25:41 -0400 Received: from h-64-105-136-125.snvacaid.dynamic.covad.net ([64.105.136.125] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLlSa-0006y7-00 for ltru@ietf.org; Wed, 13 Apr 2005 10:15:28 -0700 Message-ID: <009501c5404c$978fc100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org><008301c53fee$ea35fc20$030aa8c0@DEWELL> <425CFBBC.636F3344@xencraft.com> Subject: Re: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents Date: Wed, 13 Apr 2005 10:16:54 -0700 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: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hi - > From: "Tex Texin" > To: "Doug Ewell" > Cc: "LTRU Working Group" > Sent: Wednesday, April 13, 2005 4:00 AM > Subject: Re: [Ltru] Re: [psg.com #882] registry should copy non-English fieldsfrom ISO documents Those now in opposition are Randy, Addison, Mark, Peter, Robin and Tex. Those now in support are Jefsey, John, and Ned. Inclusion of Jeffsey's provisos clearly weakens rather than strengthens support. At this point I think there's enough of a rough consensus that we can mark this issue "rejected". Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 13:33:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12360; Wed, 13 Apr 2005 12:44:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLl8h-0004Bj-5w; Wed, 13 Apr 2005 12:54:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLkui-00006G-1l; Wed, 13 Apr 2005 12:40:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLfVT-0007pI-U1 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 06:54:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14248 for ; Wed, 13 Apr 2005 06:53:53 -0400 (EDT) Received: from smtp04.mrf.mail.rcn.net ([207.172.4.63]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLff7-00030Y-Dj for ltru@ietf.org; Wed, 13 Apr 2005 07:04:01 -0400 Received: from c-24-6-51-238.hsd1.ca.comcast.net (HELO xencraft.com) (24.6.51.238) by smtp04.mrf.mail.rcn.net with ESMTP; 13 Apr 2005 06:52:53 -0400 Received: from 127.0.0.1 (AVG SMTP 7.0.308 [266.9.7]); Wed, 13 Apr 2005 03:52:55 -0700 Message-ID: <425CFA07.F3144FEF@xencraft.com> Date: Wed, 13 Apr 2005 03:52:55 -0700 From: Tex Texin Organization: http://www.XenCraft.com X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Davis Subject: Re: [Ltru] A Modest Proposal References: <017c01c53f8d$21e1c530$ab703009@sanjose.ibm.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA14248 X-Mailman-Approved-At: Wed, 13 Apr 2005 12:40:26 -0400 Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable This is good, but ignores relativistic effects in the event the speaker is traveling at a high rate of speed. I guess that is why it is a modest proposal. Also, it has an inherent limitation in that for speakers moving at a high velocity, their position cannot be known accurately due to the Heisenberg uncertainty principal. The syntax ought to allow for a mapping between speed and location via Planck's constant. It also doesn't recognize interdimensional travel and so seems rather centric on 4 dimensions. The syntax should be made more extensible with an equation as follows: XLanguageTag for n-dimension universe ::=3D sum for dimensions i =3D 0 to n-1: -i (best I can do in plain text. Or is that plane text?) tex Mark Davis wrote: >=20 > Since it is obvious that all applications in the world will require > extremely fine-grained approach to languages, here is an initial propos= al > for development of a separate RFC to deal with them. The goal is to be = able > to describe the variety of speech that each person on earth may be usin= g at > a given time. Identification is by means of the location of the speaker= and > the time at which the speech could have occurred. The language tag is g= iven > by the following format (formal ABNF to follow). >=20 > XLanguageTag ::=3D latitude "-" longitude "-" altitude "-" time >=20 > Latitude and longitude are specified by radians, and be measured from 0= to > 360 starting at the Prime Meridian going east, and from 0 to 180 starti= ng at > the South Pole and going north. The numeric values below zero are avoid= ed > because the use of the terms "positive" and "negative" when applied to > location can clearly be prejudicial to many of the peoples of the world. > Should in the course of the development of this RFC, the use of the Pri= me > Meridian be viewed as representative of an English-speaking hegemony, a > random longitude will be chosen as the origin. Use of latitude and long= itude > does not, of course, imply in any way that those who believe in a flat = earth > or the "four-elephant+turtle system" are in any way discouraged in the > observance of their faith, nor does the use of radians in any way denig= rate > the goal of the Kansas State Education Board to recognize the value of = =CF=80 as > exactly 3.0. >=20 > Altitude is in meters above the center of the earth. While some may fee= l the > likelihood of two speakers being exactly overhead is low, we do -- of > course -- want to plan for all eventualities. By avoiding measurement > against sea level, we again celebrate the diversity of the world's > population, and do not discriminate against the proud inhabitants of De= ath > Valley and similar locations by in any way referring to them as "negati= ve". >=20 > For location, since people rarely overlap in physical space, it will us= ually > be sufficient to have accuracy to within 10 cm. But since fractions can= be > supplied, applications can have arbitrarily high degree of accuracy. >=20 > The time is specified by seconds since 0000-01-00T00:00:00Z (using the > proleptic Gregorian calendar as specified in XML Schema), plus an offse= t of > 1,000,000,000,000,000,000. If finer granularity than seconds is desired= , > then fractions can be specified. The reason for the offset is to again = avoid > negative numbers, and their implied bias against historic inhabitants. = The > offset is chosen as to be well before all current estimates of the Big = Bang. > Note, however, that this in no way implies any denigration of creationi= sm, > or that believers are in any way discouraged in the observance of their > faith. Nor does it imply that any one system of creationism, such as Gr= eek > or Norse creation theory, is any way inferior to any other, such as tha= t > espoused by the Kansas State Education Board. >=20 > Other parts of this proposal, such as security implications, will be > forthcoming. >=20 > =E2=80=8EMark >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru --=20 ------------------------------------------------------------- Tex Texin cell: +1 781 789 1898 mailto:Tex@XenCraft.com Xen Master http://www.i18nGuy.com =20 XenCraft http://www.XenCraft.com Making e-Business Work Around the World ------------------------------------------------------------- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 13:34:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16579; Wed, 13 Apr 2005 13:34:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLlun-0005mJ-LK; Wed, 13 Apr 2005 13:44:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLlgz-0001of-UR; Wed, 13 Apr 2005 13:30:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLlgy-0001kX-Bq for ltru@megatron.ietf.org; Wed, 13 Apr 2005 13:30:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16181 for ; Wed, 13 Apr 2005 13:29:39 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLlqB-0005f8-4o for ltru@ietf.org; Wed, 13 Apr 2005 13:39:52 -0400 Received: from h-64-105-136-125.snvacaid.dynamic.covad.net ([64.105.136.125] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLlgJ-0003sL-00 for ltru@ietf.org; Wed, 13 Apr 2005 10:29:39 -0700 Message-ID: <00c001c5404e$938634c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #886] registry should add French translations Date: Wed, 13 Apr 2005 10:31:07 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hi - > From: > Cc: > Sent: Thursday, April 07, 2005 6:11 PM > Subject: [Ltru] Re: [psg.com #886] registry should add French translations > > Hi - > > (co-chair hat ON) > > The question of adding French translations of specific fields in the registry > was raised in http://www1.ietf.org/mail-archive/web/ltru/current/msg00094.html > > Though this was discussed at some length on the ietf-languages list, I'd like to > verify that we have a rough consensus in this WG. I believe that consensus is > to reject this proposal. Please speak up if you have compelling technical arguments > that this WG should add French translations of specific fields in the registry. > > Randy There were no follow-ups in this thread. The question did receive some discussion in the thread for issue [psg.com #882]. That discussion confirms what I believe is a rough consensus to reject this item, so I'm changing its tracker status to "rejected." Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 13:39:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16965; Wed, 13 Apr 2005 13:39:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLlzZ-0005vq-Ix; Wed, 13 Apr 2005 13:49:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLlpK-00030E-FY; Wed, 13 Apr 2005 13:38:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLlpH-0002u0-8u for ltru@megatron.ietf.org; Wed, 13 Apr 2005 13:38:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16926 for ; Wed, 13 Apr 2005 13:38:47 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLlz0-0005uy-OA for ltru@ietf.org; Wed, 13 Apr 2005 13:49:00 -0400 Received: from h-64-105-136-125.snvacaid.dynamic.covad.net ([64.105.136.125] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLlp8-0006xC-00 for ltru@ietf.org; Wed, 13 Apr 2005 10:38:46 -0700 Message-ID: <00cd01c5404f$d9a9b8e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #876] what should the format of the initial registry be? Date: Wed, 13 Apr 2005 10:40:14 -0700 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: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi - > From: > Cc: > Sent: Thursday, April 07, 2005 1:13 PM > Subject: [Ltru] Re: [psg.com #876] what whould the format of the initialregistry be? > > Hi - > > (Co-chair hat ON) > It looks like we have a rough consensus to use record-jar format for > the initial registry. Any serious objections? If not, we'll mark this issue > "resolved". > > Randy ... Ok, this format seems to be working well for the group, so I've marked the issue "resolved." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 13:40:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17048; Wed, 13 Apr 2005 13:40:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLm0Y-0005xQ-F9; Wed, 13 Apr 2005 13:50:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLlpG-000305-Bd; Wed, 13 Apr 2005 13:38:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLlpE-0002tx-G9 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 13:38:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16920 for ; Wed, 13 Apr 2005 13:38:44 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLlyy-0005u5-V5 for ltru@ietf.org; Wed, 13 Apr 2005 13:48:57 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3DHcW5u025343; Wed, 13 Apr 2005 10:38:32 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AHJJ9>; Wed, 13 Apr 2005 10:38:33 -0700 Message-ID: From: "McDonald, Ira" To: "'Peter Constable'" , ltru@ietf.org Subject: RE: [Ltru] Re: Moving Forward Date: Wed, 13 Apr 2005 10:38:32 -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: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Hi, A good deal of digital ink is being expended on a problem (Default/Associated/Expected Script) that _only_ occurs because RFC3066bis is infixing script between language and region. And there remains every possibility that a software vendor who sells a widely used application for mounting content on Web servers will ignore that SHOULD NOT about using tags like 'en-Latn-GB' and wreak a fair amount of havoc. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Peter Constable > Sent: Wednesday, April 13, 2005 11:23 AM > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Moving Forward > > > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of John Cowan > > > > Note that the purpose of Associated_Script is > > not to tell an implementer the usual script used with a > language, but > > simply to serve notice which script *subtags*, if any, > should normally > > be used with this language subtag. This difference is fundamental. > > We could make it more obvious, though. What about changing > the label for > the field to Expected_Script_Subtags? (I.e. 'it is expected > that one of > the following script subtags will also be used'.) > > > > The specific answer is that for centuries Gothic has been written > solely > > in the Latin script. (This may start to change with the presence of > > Gothic in Unicode and the ready availability of Gothic fonts, or it > > may not.) Therefore, no Associated_Script header should be present, > > and the tag got-Latn should be avoided (though got-Goth would be in > > order as an unusual script). > > The one concern for our plan would be what to do if some apparently > stable mono-script situation suddenly changes. If we tag "got" today, > with Latin script assumed, and "got-Goth" for the unusual > scenario, and > then next year a reform gets underway with the result that in > five years > the situation has reversed, then what do we do? > > Of course, I'm describing another scenario like Turkish, and those > aren't all that likely. But a scenario such as going from > only Cyrillic > today to Cyrillic and Latin next year might not be so far fetched. > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 13:46:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17446; Wed, 13 Apr 2005 13:46:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLm6R-00066Y-C5; Wed, 13 Apr 2005 13:56:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLluO-00049E-0L; Wed, 13 Apr 2005 13:44:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLluM-00047s-AQ for ltru@megatron.ietf.org; Wed, 13 Apr 2005 13:44:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17272 for ; Wed, 13 Apr 2005 13:42:54 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLm30-00062S-He for ltru@ietf.org; Wed, 13 Apr 2005 13:53:07 -0400 Received: from h-64-105-136-125.snvacaid.dynamic.covad.net ([64.105.136.125] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLlt8-0000ia-00 for ltru@ietf.org; Wed, 13 Apr 2005 10:42:54 -0700 Message-ID: <00e001c54050$6d79fe40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #877] move section (appendix C) on registryinitialization to IANA considerations Date: Wed, 13 Apr 2005 10:44:22 -0700 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: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi - > From: > Cc: > Sent: Thursday, April 07, 2005 1:32 PM > Subject: [Ltru] Re: [psg.com #877] move section (appendix C) on registryinitialization to IANA considerations > > Hi - > > (co-chair hat ON) > > I haven't seen any discussion of > http://www1.ietf.org/mail-archive/web/ltru/current/msg00015.html > > If there are no objections, the editors will move the material on > registry initialization (subject to any other modifications per other > issues), and we'll mark this issue "resolved". > > Randy This ticket's status has been changed to "resolved". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 13:52:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17888; Wed, 13 Apr 2005 13:52:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmCc-0006Gl-QM; Wed, 13 Apr 2005 14:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLm2F-0005A2-Uj; Wed, 13 Apr 2005 13:52:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLm2F-00059E-3n for ltru@megatron.ietf.org; Wed, 13 Apr 2005 13:52:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17851 for ; Wed, 13 Apr 2005 13:52:04 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmBq-0006GJ-Kz for ltru@ietf.org; Wed, 13 Apr 2005 14:02:15 -0400 Received: from h-64-105-136-125.snvacaid.dynamic.covad.net ([64.105.136.125] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLm1y-0003fB-00 for ltru@ietf.org; Wed, 13 Apr 2005 10:52:02 -0700 Message-ID: <00fc01c54051$b423c960$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #902] AutoReply: add "Name_Changed" field Date: Wed, 13 Apr 2005 10:53:30 -0700 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: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Hi - The only follow-up in this thread has been one person expressing opposition. Since there does not appear to be a consensus to make this change, I'm changing the ticket status to "rejected". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 13:57:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18099; Wed, 13 Apr 2005 13:57:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmGp-0006Nt-HW; Wed, 13 Apr 2005 14:07:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLm5u-0005U3-Oq; Wed, 13 Apr 2005 13:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLm5t-0005Th-HW for ltru@megatron.ietf.org; Wed, 13 Apr 2005 13:56:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18019 for ; Wed, 13 Apr 2005 13:55:56 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmFa-0006Kx-8u for ltru@ietf.org; Wed, 13 Apr 2005 14:06:07 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3DHtkhU001477; Wed, 13 Apr 2005 13:55:47 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 13 Apr 2005 13:55:42 -0400 Date: Wed, 13 Apr 2005 13:55:42 -0400 From: John Cowan To: "McDonald, Ira" Subject: Re: [Ltru] Re: Moving Forward Message-ID: <20050413175542.GE11166@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 McDonald, Ira scripsit: > A good deal of digital ink is being expended on a problem > (Default/Associated/Expected Script) that _only_ occurs > because RFC3066bis is infixing script between language > and region. Not so. If you can only read Azerbaijani in the Cyrillic script, and you ask for az-Cyrl, you will get RFC 2616 failures if the content is tagged az-XX or az-XX-Cyrl for any of the various national varieties of Azerbaijani. Yet the differences between national varieties are much smaller to the reader than the difference between Arabic, Cyrillic, or Latin script. > And there remains every possibility that a software vendor > who sells a widely used application for mounting content > on Web servers will ignore that SHOULD NOT about using tags > like 'en-Latn-GB' and wreak a fair amount of havoc. It is a proven fact that software vendors who sell widely used applications ignore MUST NOTs in RFCs. These things happen. We can warn, we can complain, and finally we can boycott. -- Newbies always ask: John Cowan "Elements or attributes? http://www.ccil.org/~cowan Which will serve me best?" http://www.reutershealth.com Those who know roar like lions; jcowan@reutershealth.com Wise hackers smile like tigers. --a tanka, or extended haiku _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 13:58:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18202; Wed, 13 Apr 2005 13:58:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmIM-0006PN-FU; Wed, 13 Apr 2005 14:08:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLm7k-0005go-5b; Wed, 13 Apr 2005 13:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLm7i-0005fm-26 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 13:57:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18134 for ; Wed, 13 Apr 2005 13:57:24 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmH1-0006OB-M5 for ltru@ietf.org; Wed, 13 Apr 2005 14:07:35 -0400 Received: from h-64-105-136-125.snvacaid.dynamic.covad.net ([64.105.136.125] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLm7A-0005Gj-00 for ltru@ietf.org; Wed, 13 Apr 2005 10:57:24 -0700 Message-ID: <010b01c54052$737d13c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #903] add "Former_Name" field Date: Wed, 13 Apr 2005 10:58:51 -0700 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: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Hi - As with issue #902, there's been no support for making the change and one person has written against it. Consequently, I've changed this ticket's status to "rejected." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 14:07:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18788; Wed, 13 Apr 2005 14:07:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmQi-0006cW-Lz; Wed, 13 Apr 2005 14:17:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLmCO-0006gZ-Qj; Wed, 13 Apr 2005 14:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLmCO-0006gH-00 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 14:02:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18504 for ; Wed, 13 Apr 2005 14:02:38 -0400 (EDT) Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmM5-0006Vc-7Y for ltru@ietf.org; Wed, 13 Apr 2005 14:12:49 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3DI2Fp5013934 for ; Wed, 13 Apr 2005 14:02:15 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3DI2EEA226890 for ; Wed, 13 Apr 2005 14:02:14 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3DI2E5Y005755 for ; Wed, 13 Apr 2005 14:02:14 -0400 Received: from markdavis (mark-davis.cupertino.ibm.com [9.52.67.128]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with SMTP id j3DI2Don005703; Wed, 13 Apr 2005 14:02:13 -0400 Message-ID: <04cd01c54052$eba5ba50$4109fea9@sanjose.ibm.com> From: "Mark Davis" To: "McDonald, Ira" , "'Peter Constable'" , References: Subject: Re: [Ltru] Re: Moving Forward Date: Wed, 13 Apr 2005 11:02:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e5.ny.us.ibm.com id j3DI2Fp5013934 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable There are very good reasons for having script second; I won't repeat them. The chances that a vendor would gratuitously use "'en-Latn-GB" in that ca= se, is vanishingly small, since it would cause clients grief for no purpose. =E2=80=8EMark ----- Original Message -----=20 From: "McDonald, Ira" To: "'Peter Constable'" ; Sent: Wednesday, April 13, 2005 10:38 Subject: RE: [Ltru] Re: Moving Forward > Hi, > > A good deal of digital ink is being expended on a problem > (Default/Associated/Expected Script) that _only_ occurs > because RFC3066bis is infixing script between language > and region. > > And there remains every possibility that a software vendor > who sells a widely used application for mounting content > on Web servers will ignore that SHOULD NOT about using tags > like 'en-Latn-GB' and wreak a fair amount of havoc. > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of Peter Constable > > Sent: Wednesday, April 13, 2005 11:23 AM > > To: ltru@ietf.org > > Subject: RE: [Ltru] Re: Moving Forward > > > > > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] > > On > > > Behalf Of John Cowan > > > > > > > Note that the purpose of Associated_Script is > > > not to tell an implementer the usual script used with a > > language, but > > > simply to serve notice which script *subtags*, if any, > > should normally > > > be used with this language subtag. This difference is fundamental. > > > > We could make it more obvious, though. What about changing > > the label for > > the field to Expected_Script_Subtags? (I.e. 'it is expected > > that one of > > the following script subtags will also be used'.) > > > > > > > The specific answer is that for centuries Gothic has been written > > solely > > > in the Latin script. (This may start to change with the presence o= f > > > Gothic in Unicode and the ready availability of Gothic fonts, or it > > > may not.) Therefore, no Associated_Script header should be present= , > > > and the tag got-Latn should be avoided (though got-Goth would be in > > > order as an unusual script). > > > > The one concern for our plan would be what to do if some apparently > > stable mono-script situation suddenly changes. If we tag "got" today, > > with Latin script assumed, and "got-Goth" for the unusual > > scenario, and > > then next year a reform gets underway with the result that in > > five years > > the situation has reversed, then what do we do? > > > > Of course, I'm describing another scenario like Turkish, and those > > aren't all that likely. But a scenario such as going from > > only Cyrillic > > today to Cyrillic and Latin next year might not be so far fetched. > > > > > > > > Peter Constable > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 14:48:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18092; Wed, 13 Apr 2005 13:57:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmGp-0006Nr-As; Wed, 13 Apr 2005 14:07:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLm4W-0005If-94; Wed, 13 Apr 2005 13:54:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLm4V-0005I1-GY for ltru@megatron.ietf.org; Wed, 13 Apr 2005 13:54:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17963 for ; Wed, 13 Apr 2005 13:54:30 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmEB-0006Ja-US for ltru@ietf.org; Wed, 13 Apr 2005 14:04:41 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 10:54:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Moving Forward Date: Wed, 13 Apr 2005 10:54:14 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0AFA48BF@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Moving Forward Thread-Index: AcVAT7i0Tf2ja551SsezVrVQhL4eqAAAB6lQ From: "Addison Phillips" To: "McDonald, Ira" , "Peter Constable" , X-OriginalArrivalTime: 13 Apr 2005 17:54:14.0775 (UTC) FILETIME=[CE4F2870:01C54051] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable So which of the alternate designs do you think is the right one? (I'm = not asking antagonistically, but because I want to see this item, the = last really major one, resolved in *some* way) I note that every alternative has a downside too. IMO, script is in the = best (most logical) position between language and country.=20 Moving it into the variant slot (by merging with variant or between = region and variant) produces content selection problems (see Misha's = message) and fallback problems. And you still have the problem of = omitted fields (my German examples, examples with script but no region, = etc.).=20 Using an extension is appealing in some ways, but would require many = currently stupid processors (XML, CSS, etc.) to become at least a little = bit smarter about handling subtags (something I'm not too keen on, but = maybe it could work). C'mon folks, we're offering different ways of addressing objections to = our design, but no one has offered a contrasting position around which = to build consensus.=20 I'm open-minded enough to consider any solution and I will abide by = whatever consensus emerges which results in us having the ability to = distinguish script in a language tag. But please don't just say "don't = put it there". Tell us which alternative and why you favor it. Or tell = us exactly how our design would have to be modified to be at least = minimally acceptable. Then Randy counts noses to see if one has reached = critical mass. That is what we've tried to do with our script proposals: work on = overcoming specific individual's most pressing objections in hopes of = building (at worst) a grudging harmony. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of McDonald, Ira > Sent: mercredi 13 avril 2005 10:39 > To: 'Peter Constable'; ltru@ietf.org > Subject: RE: [Ltru] Re: Moving Forward >=20 > Hi, >=20 > A good deal of digital ink is being expended on a problem > (Default/Associated/Expected Script) that _only_ occurs > because RFC3066bis is infixing script between language > and region. >=20 > And there remains every possibility that a software vendor > who sells a widely used application for mounting content > on Web servers will ignore that SHOULD NOT about using tags > like 'en-Latn-GB' and wreak a fair amount of havoc. >=20 > Cheers, > - Ira >=20 > 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 >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of Peter Constable > > Sent: Wednesday, April 13, 2005 11:23 AM > > To: ltru@ietf.org > > Subject: RE: [Ltru] Re: Moving Forward > > > > > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] > > On > > > Behalf Of John Cowan > > > > > > > Note that the purpose of Associated_Script is > > > not to tell an implementer the usual script used with a > > language, but > > > simply to serve notice which script *subtags*, if any, > > should normally > > > be used with this language subtag. This difference is = fundamental. > > > > We could make it more obvious, though. What about changing > > the label for > > the field to Expected_Script_Subtags? (I.e. 'it is expected > > that one of > > the following script subtags will also be used'.) > > > > > > > The specific answer is that for centuries Gothic has been written > > solely > > > in the Latin script. (This may start to change with the presence = of > > > Gothic in Unicode and the ready availability of Gothic fonts, or = it > > > may not.) Therefore, no Associated_Script header should be = present, > > > and the tag got-Latn should be avoided (though got-Goth would be = in > > > order as an unusual script). > > > > The one concern for our plan would be what to do if some apparently > > stable mono-script situation suddenly changes. If we tag "got" = today, > > with Latin script assumed, and "got-Goth" for the unusual > > scenario, and > > then next year a reform gets underway with the result that in > > five years > > the situation has reversed, then what do we do? > > > > Of course, I'm describing another scenario like Turkish, and those > > aren't all that likely. But a scenario such as going from > > only Cyrillic > > today to Cyrillic and Latin next year might not be so far fetched. > > > > > > > > Peter Constable > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 14:55:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22601; Wed, 13 Apr 2005 14:55:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLnB2-0007vD-PR; Wed, 13 Apr 2005 15:05:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLmzi-0006Vl-H2; Wed, 13 Apr 2005 14:53:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLmzh-0006VX-7u for ltru@megatron.ietf.org; Wed, 13 Apr 2005 14:53:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22519 for ; Wed, 13 Apr 2005 14:53:43 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLn9W-0007tN-Eb for ltru@ietf.org; Wed, 13 Apr 2005 15:03:55 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Wed, 13 Apr 2005 11:53:33 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 13 Apr 2005 11:53:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Moving Forward Date: Wed, 13 Apr 2005 11:53:33 -0700 Message-ID: Thread-Topic: [Ltru] Re: Moving Forward Thread-Index: AcVAT6nDPYCcqD/WQVOMP3P4Hm05MwACRcMw From: "Peter Constable" To: X-OriginalArrivalTime: 13 Apr 2005 18:53:33.0724 (UTC) FILETIME=[179BADC0:01C5405A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > And there remains every possibility that a software vendor > who sells a widely used application for mounting content > on Web servers will ignore that SHOULD NOT about using tags > like 'en-Latn-GB' and wreak a fair amount of havoc. I find these kinds of statements (just like "breaks back compat") to be so vague as to be unconstructive. This is particularly concerning because the statements are also alarmist in tone. I have no qualms with identifying serious problems with a proposal if it can be clearly shown what the problem is, that the problems are valid and have a reasonable likelihood of occurrence. Could we please qualify and quantify "a fair amount of havoc"? For a worst case scenario, what might the negative impact be to the vendor, to customers using that application to mount content on Web servers, and to end users interacting with those Web sights? For instance, I can easily imagine cases in which none of the parties involved notice that there has been some loss of functionality; and other scenarios in which loss of functionality is immediately noticed, prompting immediate corrective measures, during the course of which the vendor takes time to read the RFC and implement correctly, as they should have done in the first place. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 15:53:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27812; Wed, 13 Apr 2005 15:53:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLo5h-00018b-7J; Wed, 13 Apr 2005 16:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLnsy-0005UQ-IS; Wed, 13 Apr 2005 15:50:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLnsx-0005UC-DQ for ltru@megatron.ietf.org; Wed, 13 Apr 2005 15:50:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27489 for ; Wed, 13 Apr 2005 15:50:41 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLo2f-0000u3-R2 for ltru@ietf.org; Wed, 13 Apr 2005 16:00:54 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3DJoSHo001416; Wed, 13 Apr 2005 12:50:32 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AHK6G>; Wed, 13 Apr 2005 12:50:28 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , "McDonald, Ira" , Peter Constable , ltru@ietf.org Subject: RE: [Ltru] Re: Moving Forward Date: Wed, 13 Apr 2005 12:50:28 -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: e8c5db863102a3ada84e0cd52a81a79e X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Hi, With no disrespect meant, I'll ignore those blithe responses from Mark and Peter who seem to think the problem (loss of region utility) will never happen or will always get quickly fixed by some vendor. [The 'havoc' I meant was the complete loss of lookup capability for a deployed HTTP client application that has a configured 'en-GB' tag and tries to read Web content from an 'en-Latn-GB' tagged HTTP server. And the weeks of problems before "support" fudges some fix - since "support" didn't put the 'en-Latn-GB' tags there - the crummy content distribution application did.] To Addison's question I'll answer more seriously: Make script _third_ and allow (as always) the omission of the _second_ position region. That format has the desirable property that 'en-Latn' means "English in Latin script, don't care about region" (because region was explicitly omitted). That can never cause breakage in existing LDAP and other applications because of displacement of region and still gets you exactly what you want for script primacy. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Wednesday, April 13, 2005 1:54 PM > To: McDonald, Ira; Peter Constable; ltru@ietf.org > Subject: RE: [Ltru] Re: Moving Forward > > > So which of the alternate designs do you think is the right > one? (I'm not asking antagonistically, but because I want to > see this item, the last really major one, resolved in *some* way) > > I note that every alternative has a downside too. IMO, script > is in the best (most logical) position between language and country. > > Moving it into the variant slot (by merging with variant or > between region and variant) produces content selection > problems (see Misha's message) and fallback problems. And you > still have the problem of omitted fields (my German examples, > examples with script but no region, etc.). > > Using an extension is appealing in some ways, but would > require many currently stupid processors (XML, CSS, etc.) to > become at least a little bit smarter about handling subtags > (something I'm not too keen on, but maybe it could work). > > C'mon folks, we're offering different ways of addressing > objections to our design, but no one has offered a > contrasting position around which to build consensus. > > I'm open-minded enough to consider any solution and I will > abide by whatever consensus emerges which results in us > having the ability to distinguish script in a language tag. > But please don't just say "don't put it there". Tell us which > alternative and why you favor it. Or tell us exactly how our > design would have to be modified to be at least minimally > acceptable. Then Randy counts noses to see if one has reached > critical mass. > > That is what we've tried to do with our script proposals: > work on overcoming specific individual's most pressing > objections in hopes of building (at worst) a grudging harmony. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of McDonald, Ira > > Sent: mercredi 13 avril 2005 10:39 > > To: 'Peter Constable'; ltru@ietf.org > > Subject: RE: [Ltru] Re: Moving Forward > > > > Hi, > > > > A good deal of digital ink is being expended on a problem > > (Default/Associated/Expected Script) that _only_ occurs > > because RFC3066bis is infixing script between language > > and region. > > > > And there remains every possibility that a software vendor > > who sells a widely used application for mounting content > > on Web servers will ignore that SHOULD NOT about using tags > > like 'en-Latn-GB' and wreak a fair amount of havoc. > > > > Cheers, > > - Ira > > > > Ira McDonald (Musician / Software Architect) > > Blue Roof Music / High North Inc > > PO Box 221 Grand Marais, MI 49839 > > phone: +1-906-494-2434 > > email: imcdonald@sharplabs.com > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > > > [mailto:ltru-bounces@lists.ietf.org]On > > > Behalf Of Peter Constable > > > Sent: Wednesday, April 13, 2005 11:23 AM > > > To: ltru@ietf.org > > > Subject: RE: [Ltru] Re: Moving Forward > > > > > > > > > > From: ltru-bounces@lists.ietf.org > > > [mailto:ltru-bounces@lists.ietf.org] > > > On > > > > Behalf Of John Cowan > > > > > > > > > > Note that the purpose of Associated_Script is > > > > not to tell an implementer the usual script used with a > > > language, but > > > > simply to serve notice which script *subtags*, if any, > > > should normally > > > > be used with this language subtag. This difference is > fundamental. > > > > > > We could make it more obvious, though. What about changing > > > the label for > > > the field to Expected_Script_Subtags? (I.e. 'it is expected > > > that one of > > > the following script subtags will also be used'.) > > > > > > > > > > The specific answer is that for centuries Gothic has > been written > > > solely > > > > in the Latin script. (This may start to change with > the presence of > > > > Gothic in Unicode and the ready availability of Gothic > fonts, or it > > > > may not.) Therefore, no Associated_Script header > should be present, > > > > and the tag got-Latn should be avoided (though got-Goth > would be in > > > > order as an unusual script). > > > > > > The one concern for our plan would be what to do if some > apparently > > > stable mono-script situation suddenly changes. If we tag > "got" today, > > > with Latin script assumed, and "got-Goth" for the unusual > > > scenario, and > > > then next year a reform gets underway with the result that in > > > five years > > > the situation has reversed, then what do we do? > > > > > > Of course, I'm describing another scenario like Turkish, and those > > > aren't all that likely. But a scenario such as going from > > > only Cyrillic > > > today to Cyrillic and Latin next year might not be so far fetched. > > > > > > > > > > > > Peter Constable > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 16:32:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04746; Wed, 13 Apr 2005 16:32:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLohH-0003ZJ-6r; Wed, 13 Apr 2005 16:42:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLo7j-00083t-0D; Wed, 13 Apr 2005 16:06:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLo7h-00083V-DR for ltru@megatron.ietf.org; Wed, 13 Apr 2005 16:06:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29573 for ; Wed, 13 Apr 2005 16:05:55 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLoHP-0001kb-AM for ltru@ietf.org; Wed, 13 Apr 2005 16:16:08 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3DK5gga001981; Wed, 13 Apr 2005 16:05:42 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 13 Apr 2005 16:05:46 -0400 Date: Wed, 13 Apr 2005 16:05:46 -0400 From: John Cowan To: "McDonald, Ira" Subject: Re: [Ltru] Re: Moving Forward Message-ID: <20050413200546.GN11166@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 McDonald, Ira scripsit: > Make script _third_ and allow (as always) the omission of the _second_ > position region. That format has the desirable property that 'en-Latn' > means "English in Latin script, don't care about region" (because > region was explicitly omitted). That can never cause breakage in > existing LDAP and other applications because of displacement of > region and still gets you exactly what you want for script primacy. *sigh* Not so. An HTTP or LDAP request for "en-Latn" will not match existing content or entries tagged "en-GB" or "en-US". -- Deshil Holles eamus. Deshil Holles eamus. Deshil Holles eamus. Send us, bright one, light one, Horhorn, quickening, and wombfruit. (3x) Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! Hoopsa, boyaboy, hoopsa! -- Joyce, Ulysses, "Oxen of the Sun" jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 16:43:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05859; Wed, 13 Apr 2005 16:43:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLorN-0003te-VB; Wed, 13 Apr 2005 16:53:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLoey-0001JO-TD; Wed, 13 Apr 2005 16:40:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLoex-0001Gi-0Y for ltru@megatron.ietf.org; Wed, 13 Apr 2005 16:40:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05636 for ; Wed, 13 Apr 2005 16:40:16 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLooe-0003pf-HL for ltru@ietf.org; Wed, 13 Apr 2005 16:50:29 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 13:40:08 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 13 Apr 2005 13:40:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Moving Forward Date: Wed, 13 Apr 2005 13:39:57 -0700 Message-ID: Thread-Topic: [Ltru] Re: Moving Forward Thread-Index: AcVAYhu48GkvX1v9SniTR3a2E5aRWwAAelCA From: "Peter Constable" To: X-OriginalArrivalTime: 13 Apr 2005 20:40:07.0908 (UTC) FILETIME=[FAD6BA40:01C54068] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > With no disrespect meant, I'll ignore those blithe responses from > Mark and Peter who seem to think the problem (loss of region utility) > will never happen or will always get quickly fixed by some vendor. I'm sure Mark appreciates being ignored as much as I. Note that I did not say I thought that the problem will never happen or always get fixed. I said that your statement was too vague to evaluate. You simply painted a grave picture with a blanket statement for which it was impossible to tell what the real extent of the problem is. Just like the earlier blanket statement "this breaks backward compatibility" -- that simply was not a useful statement. In both cases, there really is a need to identify what are the specific kinds of scenarios that are a concern. =20 > [The 'havoc' I meant was the complete loss of lookup capability for > a deployed HTTP client application that has a configured 'en-GB' tag > and tries to read Web content from an 'en-Latn-GB' tagged HTTP server. > And the weeks of problems before "support" fudges some fix - since > "support" didn't put the 'en-Latn-GB' tags there - the crummy content > distribution application did.] Now I'll be "blithe" (well, blithe really isn't the appropriate term). If a software developer makes a bad choice because something is possible and they didn't give adequate thought to it, I think that's their problem, and that the issue really is the extent to which we are leading reasonably intelligent software developers into likely pitfalls.=20 Section 2.3 has the following statement: 2. Avoid using subtags that are not important for distinguishing content in an application. For example, including the script subtag in "en-Latn-US" is generally unnecessary, since nearly all English texts are written in the Latin script and it is generally not important to filter out those few that are not. It might be in order in section 2.3 to draw greater attention to and provide increased guidance on the matter of when to include or not include a script subtag, perhaps making that a separate subsection (2.3.1). =20 > To Addison's question I'll answer more seriously: >=20 > Make script _third_ and allow (as always) the omission of the _second_ > position region. That format has the desirable property that 'en-Latn' > means "English in Latin script, don't care about region" (because > region was explicitly omitted). That can never cause breakage in > existing LDAP and other applications because of displacement of > region and still gets you exactly what you want for script primacy. Sure it can. As has been stated before, there are problem scenarios no matter what order for subtags is used because of the limitations of left-prefix matching. If an existing client requests zh-Hant and an existing server has zh-HK-Hant, the match will fail. And note that your problem scenario involved a tag the use of which would be *discouraged* for general use, en-Latn-GB, this scenario would be involving the use of *recommended* tags. Again, you are making blanket statements -- "that wreaks havoc, this never breaks" where what is needed is to examine which things do and don't work, because no matter how we propose dealing with this, there will be some scenarios in which some things don't work. Not because there's a problem with the tags, but because there's a problem with inadequate matching algorithms. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 18:05:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11137; Wed, 13 Apr 2005 18:05:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLq8q-0005qV-RV; Wed, 13 Apr 2005 18:15:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLpxU-0003fr-8L; Wed, 13 Apr 2005 18:03:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLpxT-0003dA-JL for ltru@megatron.ietf.org; Wed, 13 Apr 2005 18:03:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10712 for ; Wed, 13 Apr 2005 18:02:56 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLq6g-0005nC-Q8 for ltru@ietf.org; Wed, 13 Apr 2005 18:13:11 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 15:02:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Moving Forward Date: Wed, 13 Apr 2005 15:02:41 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08D1BC@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Moving Forward Thread-Index: AcVAYlfUQXMzA9s1RPqC3yoB1Hw+bAAARmfw From: "Addison Phillips" To: "McDonald, Ira" , "Peter Constable" , X-OriginalArrivalTime: 13 Apr 2005 22:02:42.0220 (UTC) FILETIME=[83D6BEC0:01C54074] X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Content-Transfer-Encoding: quoted-printable The selection pairing: Range=3D en-Latn Content=3D en-US-Latn results in no matching in LDAP and other RFR/RFC 2616 matching = scenarios, unless you change the matching algorithm (at which point you = could have put script second...) to deal with the interpolated subtag = "US". I think your point is that the user explicitly did not select a region = in my example above, which is true. The problem is that the cases where = script is important, the region code tends to be something one would = want to strip first. Consider: Range=3D zh-Hant Content=3D zh-HK-Hant Content2=3D zh-TW-Hant RFR matching only works if the same fields are either all full or all = empty for a given subtag. Neither script in second or script in third = fixes all cases, only certain sets of cases. Notice that the fallback from range "en-Latn-US" for "en-US" tagged = content is "en" (for fallback type matching as in Apache or in my J2EE = example). This is also true for range "en-US" and "en-Latn-US" tagged = content. The work around is the same in both cases: to create content on = the "mezzanine" level of "en". (Notice that this *is* a problem for = languages that have multiple scripts like Chinese and which really = should use a script subtag: the vector really should go through the = script before falling to a bare language subtag because the language = content could be in either script and realistically is only in one of = the two or more scripts.) For Web applications, I think that we can assume that users will not go = modify their language preferences (Accept-Language) just because a = specific page returns the "wrong" language for their specified range or = the empty set of content for a given URI, just as you say. They will = just curse the 404 and move on. Most implementations do not look at the = second and subsequence Accept-Language value, so setting both "en-Latn" = and "en" doesn't do any good. It is important to harmonize the values = that content and the associated ranges use. And the subtags (given that = we use a script subtag) will produce erroneous behavior in both = script-second and script-third cases (but in different circumstances for = each). Hence our attempts to regularize those languages that need script or = allow script only in languages that need it or some similar formulation. = I think this would still be necessary with a script-comes-third approach = anyway. If we do a good enough job of this, then we can choose the most = logical design (which for me is script-second). Does this explanation (and those of others) sway you in the direction of = (accepting) script second? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: mercredi 13 avril 2005 12:50 > To: Addison Phillips; McDonald, Ira; Peter Constable; ltru@ietf.org > Subject: RE: [Ltru] Re: Moving Forward >=20 > Hi, >=20 > With no disrespect meant, I'll ignore those blithe responses from > Mark and Peter who seem to think the problem (loss of region utility) > will never happen or will always get quickly fixed by some vendor. >=20 > [The 'havoc' I meant was the complete loss of lookup capability for > a deployed HTTP client application that has a configured 'en-GB' tag > and tries to read Web content from an 'en-Latn-GB' tagged HTTP server. > And the weeks of problems before "support" fudges some fix - since > "support" didn't put the 'en-Latn-GB' tags there - the crummy content > distribution application did.] >=20 > To Addison's question I'll answer more seriously: >=20 > Make script _third_ and allow (as always) the omission of the _second_ > position region. That format has the desirable property that = 'en-Latn' > means "English in Latin script, don't care about region" (because > region was explicitly omitted). That can never cause breakage in > existing LDAP and other applications because of displacement of > region and still gets you exactly what you want for script primacy. >=20 > Cheers, > - Ira >=20 > 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 >=20 > > -----Original Message----- > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > Sent: Wednesday, April 13, 2005 1:54 PM > > To: McDonald, Ira; Peter Constable; ltru@ietf.org > > Subject: RE: [Ltru] Re: Moving Forward > > > > > > So which of the alternate designs do you think is the right > > one? (I'm not asking antagonistically, but because I want to > > see this item, the last really major one, resolved in *some* way) > > > > I note that every alternative has a downside too. IMO, script > > is in the best (most logical) position between language and country. > > > > Moving it into the variant slot (by merging with variant or > > between region and variant) produces content selection > > problems (see Misha's message) and fallback problems. And you > > still have the problem of omitted fields (my German examples, > > examples with script but no region, etc.). > > > > Using an extension is appealing in some ways, but would > > require many currently stupid processors (XML, CSS, etc.) to > > become at least a little bit smarter about handling subtags > > (something I'm not too keen on, but maybe it could work). > > > > C'mon folks, we're offering different ways of addressing > > objections to our design, but no one has offered a > > contrasting position around which to build consensus. > > > > I'm open-minded enough to consider any solution and I will > > abide by whatever consensus emerges which results in us > > having the ability to distinguish script in a language tag. > > But please don't just say "don't put it there". Tell us which > > alternative and why you favor it. Or tell us exactly how our > > design would have to be modified to be at least minimally > > acceptable. Then Randy counts noses to see if one has reached > > critical mass. > > > > That is what we've tried to do with our script proposals: > > work on overcoming specific individual's most pressing > > objections in hopes of building (at worst) a grudging harmony. > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] On > > > Behalf Of McDonald, Ira > > > Sent: mercredi 13 avril 2005 10:39 > > > To: 'Peter Constable'; ltru@ietf.org > > > Subject: RE: [Ltru] Re: Moving Forward > > > > > > Hi, > > > > > > A good deal of digital ink is being expended on a problem > > > (Default/Associated/Expected Script) that _only_ occurs > > > because RFC3066bis is infixing script between language > > > and region. > > > > > > And there remains every possibility that a software vendor > > > who sells a widely used application for mounting content > > > on Web servers will ignore that SHOULD NOT about using tags > > > like 'en-Latn-GB' and wreak a fair amount of havoc. > > > > > > Cheers, > > > - Ira > > > > > > Ira McDonald (Musician / Software Architect) > > > Blue Roof Music / High North Inc > > > PO Box 221 Grand Marais, MI 49839 > > > phone: +1-906-494-2434 > > > email: imcdonald@sharplabs.com > > > > > > > -----Original Message----- > > > > From: ltru-bounces@lists.ietf.org > > > > [mailto:ltru-bounces@lists.ietf.org]On > > > > Behalf Of Peter Constable > > > > Sent: Wednesday, April 13, 2005 11:23 AM > > > > To: ltru@ietf.org > > > > Subject: RE: [Ltru] Re: Moving Forward > > > > > > > > > > > > > From: ltru-bounces@lists.ietf.org > > > > [mailto:ltru-bounces@lists.ietf.org] > > > > On > > > > > Behalf Of John Cowan > > > > > > > > > > > > > Note that the purpose of Associated_Script is > > > > > not to tell an implementer the usual script used with a > > > > language, but > > > > > simply to serve notice which script *subtags*, if any, > > > > should normally > > > > > be used with this language subtag. This difference is > > fundamental. > > > > > > > > We could make it more obvious, though. What about changing > > > > the label for > > > > the field to Expected_Script_Subtags? (I.e. 'it is expected > > > > that one of > > > > the following script subtags will also be used'.) > > > > > > > > > > > > > The specific answer is that for centuries Gothic has > > been written > > > > solely > > > > > in the Latin script. (This may start to change with > > the presence of > > > > > Gothic in Unicode and the ready availability of Gothic > > fonts, or it > > > > > may not.) Therefore, no Associated_Script header > > should be present, > > > > > and the tag got-Latn should be avoided (though got-Goth > > would be in > > > > > order as an unusual script). > > > > > > > > The one concern for our plan would be what to do if some > > apparently > > > > stable mono-script situation suddenly changes. If we tag > > "got" today, > > > > with Latin script assumed, and "got-Goth" for the unusual > > > > scenario, and > > > > then next year a reform gets underway with the result that in > > > > five years > > > > the situation has reversed, then what do we do? > > > > > > > > Of course, I'm describing another scenario like Turkish, and = those > > > > aren't all that likely. But a scenario such as going from > > > > only Cyrillic > > > > today to Cyrillic and Latin next year might not be so far = fetched. > > > > > > > > > > > > > > > > Peter Constable > > > > > > > > _______________________________________________ > > > > Ltru mailing list > > > > Ltru@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 18:07:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11698; Wed, 13 Apr 2005 18:07:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLqAz-0005vT-PJ; Wed, 13 Apr 2005 18:17:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLpuS-0003ON-Sg; Wed, 13 Apr 2005 18:00:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLpuQ-0003Ia-PR for ltru@megatron.ietf.org; Wed, 13 Apr 2005 18:00:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10198 for ; Wed, 13 Apr 2005 17:59:32 -0400 (EDT) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLq3M-0005ew-FS for ltru@ietf.org; Wed, 13 Apr 2005 18:09:46 -0400 Received: from h-64-105-136-125.snvacaid.dynamic.covad.net ([64.105.136.125] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DLptO-0005Ob-00 for ltru@ietf.org; Wed, 13 Apr 2005 14:59:26 -0700 Message-ID: <005901c54074$42479a60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: Moving Forward Date: Wed, 13 Apr 2005 15:00:51 -0700 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: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Hi - > From: "Peter Constable" > To: > Sent: Wednesday, April 13, 2005 1:39 PM > Subject: RE: [Ltru] Re: Moving Forward ... > Section 2.3 has the following statement: > > > 2. Avoid using subtags that are not important for distinguishing content > in an application. For example, including the script subtag in > "en-Latn-US" is generally unnecessary, since nearly all English texts > are written in the Latin script and it is generally not important to > filter out those few that are not. > > > It might be in order in section 2.3 to draw greater attention to and > provide increased guidance on the matter of when to include or not > include a script subtag, perhaps making that a separate subsection > (2.3.1). I think part of the discomfort is that a statement like "generally unnecessary" is not strong enough. If it's easier for a programmer to write code that puts a script tag on everything, "generally unnecessary" will be read as permission. >From this discussion, it seems that putting a "-Latn" in the middle of en-US is not merely unnecessary; it's downright harmful. Could we make this strong enough to spell out conditions when script subtags MUST NOT be used in tagging information, and to find a way to represent these conditions in registry entries? This could take the form of some additional fine-tuning to the description of "Associated_Script", and might need an additional field. Examples of how it sounds like we want things to work: English & its varieties stay naked when latin, gets a -Brai when needed Vietnamese & its varieties stay naked when latin, marked when no^m, Mongolian and its varieties are always marked for script Gothic is naked when in latin transcription, marked when in its historic alphabet ... > Again, you are making blanket statements -- "that wreaks havoc, this > never breaks" where what is needed is to examine which things do and > don't work, because no matter how we propose dealing with this, there > will be some scenarios in which some things don't work. Not because > there's a problem with the tags, but because there's a problem with > inadequate matching algorithms. ... Agreed, but the extent to which these inadequate algorithms are implemented in existing software, we as a WG need to be very conscious and conscientious about which scenarios will and won't work in a net populated with new and old applications, as well as new and old data. In cases where we don't give MUST/MUST not rules, we need to be sure that our guidance is very clear. If not following a SHOULD causes things to *break*, then "SHOULD" isn't strong enough. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 18:43:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14877; Wed, 13 Apr 2005 18:43:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLqkP-0006ti-5Y; Wed, 13 Apr 2005 18:54:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLqYe-0001zf-02; Wed, 13 Apr 2005 18:42:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLqYa-0001zA-OT for ltru@megatron.ietf.org; Wed, 13 Apr 2005 18:42:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14757 for ; Wed, 13 Apr 2005 18:41:49 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLqiK-0006ri-9B for ltru@ietf.org; Wed, 13 Apr 2005 18:52:04 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3DMfeOx031920 for ; Wed, 13 Apr 2005 18:41:40 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3DMfeii090268 for ; Wed, 13 Apr 2005 18:41:40 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3DMfdau028276 for ; Wed, 13 Apr 2005 18:41:39 -0400 Received: from markdavis (mark-davis.cupertino.ibm.com [9.52.67.128]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with SMTP id j3DMfcmF028238; Wed, 13 Apr 2005 18:41:39 -0400 Message-ID: <069001c54079$f4581180$4109fea9@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , References: <005901c54074$42479a60$7f1afea9@oemcomputer> Subject: Re: [Ltru] Re: Moving Forward Date: Wed, 13 Apr 2005 15:41:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e3.ny.us.ibm.com id j3DMfeOx031920 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable > Could we make this strong enough to spell out conditions when script subtags > MUST NOT be used in tagging information, and to find a way to represent > these conditions in registry entries? This could take the form of some The problem is that this is really the province of matching, which we wer= e constrained to move into a separate document. There are absolutely circumstances, as I outlined early, where it is perfectly reasonable and correct to use something like en-Latn. In the base document we can just indicate that much; in the matching document we would set out when one wo= uld use script in tags and when not. I really do think this is making a mountain out of a molehill. As we've s= een from 3066, in practice people just don't use the tags that are unnecessar= y or don't make sense. We only see a very small number of the possible generative English tags in real life: en-AF, en-AL, en-DZ, en-AS, en-AD, en-AO, en-AI, en-AQ, en-AG, en-AR, en-= AM, en-AW, en-AU, en-AT, en-AZ, en-BS, en-BH, en-BD, en-BB, en-BY, en-BE, en-= BZ, en-BJ, en-BM, en-BT, en-BO, en-BA, en-BW, en-BV, en-BR, en-IO, en-BN, en-= BG, en-BF, en-BI, en-KH, en-CM, en-CA, en-CV, en-KY, en-CF, en-TD, en-CL, en-= CN, en-CX, en-CC, en-CO, en-KM, en-CG, en-CD, en-CK, en-CR, en-CI, en-HR, en-= CU, en-CY, en-CZ, en-DK, en-DJ, en-DM, en-DO, en-EC, en-EG, en-SV, en-GQ, en-= ER, en-EE, en-ET, en-FK, en-FO, en-FJ, en-FI, en-FR, en-GF, en-PF, en-TF, en-= GA, en-GM, en-GE, en-DE, en-GH, en-GI, en-GR, en-GL, en-GD, en-GP, en-GU, en-= GT, en-GN, en-GW, en-GY, en-HT, en-HM, en-VA, en-HN, en-HK, en-HU, en-IS, en-= IN, en-ID, en-IR, en-IQ, en-IE, en-IL, en-IT, en-JM, en-JP, en-JO, en-KZ, en-= KE, en-KI, en-KP, en-KR, en-KW, en-KG, en-LA, en-LV, en-LB, en-LS, en-LR, en-= LY, en-LI, en-LT, en-LU, en-MO, en-MK, en-MG, en-MW, en-MY, en-MV, en-ML, en-= MT, en-MH, en-MQ, en-MR, en-MU, en-YT, en-MX, en-FM, en-MD, en-MC, en-MN, en-= MS, en-MA, en-MZ, en-MM, en-NA, en-NR, en-NP, en-NL, en-AN, en-NC, en-NZ, en-= NI, en-NE, en-NG, en-NU, en-NF, en-MP, en-NO, en-OM, en-PK, en-PW, en-PS, en-= PA, en-PG, en-PY, en-PE, en-PH, en-PN, en-PL, en-PT, en-PR, en-QA, en-RE, en-= RO, en-RU, en-RW, en-SH, en-KN, en-LC, en-PM, en-VC, en-WS, en-SM, en-ST, en-= SA, en-SN, en-SC, en-SL, en-SG, en-SK, en-SI, en-SB, en-SO, en-ZA, en-GS, en-= ES, en-LK, en-SD, en-SR, en-SJ, en-SZ, en-SE, en-CH, en-SY, en-TW, en-TJ, en-= TZ, en-TH, en-TL, en-TG, en-TK, en-TO, en-TT, en-TN, en-TR, en-TM, en-TC, en-= TV, en-UG, en-UA, en-AE, en-GB, en-US, en-UM, en-UY, en-UZ, en-VU, en-VE, en-= VN, en-VG, en-VI, en-WF, en-EH, en-YE, en-YU, en-ZM, en-ZW =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: Sent: Wednesday, April 13, 2005 15:00 Subject: Re: [Ltru] Re: Moving Forward > Hi - > > > From: "Peter Constable" > > To: > > Sent: Wednesday, April 13, 2005 1:39 PM > > Subject: RE: [Ltru] Re: Moving Forward > ... > > Section 2.3 has the following statement: > > > > > > 2. Avoid using subtags that are not important for distinguishing cont= ent > > in an application. For example, including the script subtag in > > "en-Latn-US" is generally unnecessary, since nearly all English texts > > are written in the Latin script and it is generally not important to > > filter out those few that are not. > > > > > > It might be in order in section 2.3 to draw greater attention to and > > provide increased guidance on the matter of when to include or not > > include a script subtag, perhaps making that a separate subsection > > (2.3.1). > > I think part of the discomfort is that a statement like "generally unnecessary" > is not strong enough. If it's easier for a programmer to write code th= at puts > a script tag on everything, "generally unnecessary" will be read as permission. > >From this discussion, it seems that putting a "-Latn" in the middle of en-US > is not merely unnecessary; it's downright harmful. > > Could we make this strong enough to spell out conditions when script su= bta gs > MUST NOT be used in tagging information, and to find a way to represent > these conditions in registry entries? This could take the form of some > additional fine-tuning to the description of "Associated_Script", and might > need an additional field. > > Examples of how it sounds like we want things to work: > English & its varieties stay naked when latin, gets a -Brai when needed > Vietnamese & its varieties stay naked when latin, marked when no^m, > Mongolian and its varieties are always marked for script > Gothic is naked when in latin transcription, marked when in its historic alphabet > > ... > > Again, you are making blanket statements -- "that wreaks havoc, this > > never breaks" where what is needed is to examine which things do and > > don't work, because no matter how we propose dealing with this, there > > will be some scenarios in which some things don't work. Not because > > there's a problem with the tags, but because there's a problem with > > inadequate matching algorithms. > ... > > Agreed, but the extent to which these inadequate algorithms are implemented > in existing software, we as a WG need to be very conscious and conscientious > about which scenarios will and won't work in a net populated with new a= nd old > applications, as well as new and old data. In cases where we don't giv= e > MUST/MUST not rules, we need to be sure that our guidance is very clear. > If not following a SHOULD causes things to *break*, then "SHOULD" isn't > strong enough. > > Randy > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 18:45:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14964; Wed, 13 Apr 2005 18:45:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLqlu-0006wy-OL; Wed, 13 Apr 2005 18:55:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLqbX-0002S0-8E; Wed, 13 Apr 2005 18:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLqbV-0002Qy-TF for ltru@megatron.ietf.org; Wed, 13 Apr 2005 18:45:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14935 for ; Wed, 13 Apr 2005 18:44:51 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLqlF-0006vw-43 for ltru@ietf.org; Wed, 13 Apr 2005 18:55:06 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 15:44:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Moving Forward Date: Wed, 13 Apr 2005 15:44:42 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08D1E0@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Moving Forward Thread-Index: AcVAdKvToQ8bMdfbQl+LWe3M5yRJXwAA6yCw From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 13 Apr 2005 22:44:43.0360 (UTC) FILETIME=[628E2E00:01C5407A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Interlinear below. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 >=20 > Could we make this strong enough to spell out conditions when script > subtags > MUST NOT be used in tagging information, and to find a way to = represent > these conditions in registry entries? This could take the form of = some > additional fine-tuning to the description of "Associated_Script", and > might > need an additional field. [Addison Phillips]=20 How about: Subtags which are not important for distinguishing content in an = application SHOULD NOT be used to form language tags. In particular, you = MUST NOT use the script subtag unless (a) the language subtag has an = Expected_Script field or (b) the specific script distinction is = important to the application. For example, the tag "en-Latn-US" should = be used exceedingly rarely since nearly all English texts are written in = the Latin script and it is generally not important to filter out those = few that are not, while documents that use the primary language subtag = 'sr' (Serbian) must be distinguished by the choice of Latin or Cyrillic = script. >=20 > Examples of how it sounds like we want things to work: > English & its varieties stay naked when latin, gets a -Brai when > needed > Vietnamese & its varieties stay naked when latin, marked when = no^m, > Mongolian and its varieties are always marked for script > Gothic is naked when in latin transcription, marked when in its > historic alphabet >=20 [Addison Phillips]=20 Vietnamese or English might take a Latn subtag in cases where that = distinguishes between two choices in a document (en-Latn vs. en-Brai in = a stylesheet, for example) >=20 > Agreed, but the extent to which these inadequate algorithms are > implemented > in existing software, we as a WG need to be very conscious and > conscientious > about which scenarios will and won't work in a net populated with new = and > old > applications, as well as new and old data. In cases where we don't = give > MUST/MUST not rules, we need to be sure that our guidance is very = clear. > If not following a SHOULD causes things to *break*, then "SHOULD" = isn't > strong enough. [Addison Phillips]=20 Yes, but MUST is very strong. The problem stems in many but not all = cases from mixing with and without subtag usages together. Forbidding = en-Latn-* from ever occurring causes problems when you do get a script = subtag later and use RFR matching. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 18:51:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15224; Wed, 13 Apr 2005 18:51:33 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLqrk-00075X-Rm; Wed, 13 Apr 2005 19:01:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLqh7-0003Vp-D7; Wed, 13 Apr 2005 18:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLqh6-0003VT-Hj for ltru@megatron.ietf.org; Wed, 13 Apr 2005 18:50:48 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15210 for ; Wed, 13 Apr 2005 18:50:37 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLqcy-0000CJ-Lb for ltru@lists.ietf.org; Thu, 14 Apr 2005 00:46:32 +0200 Received: from 212.82.251.217 ([212.82.251.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2005 00:46:32 +0200 Received: from nobody by 212.82.251.217 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2005 00:46:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 14 Apr 2005 00:47:13 +0200 Organization: Lines: 35 Message-ID: <425DA171.5BC6@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.217 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Default script sine qua non (was: Moving Forward) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Peter Constable wrote: > a scenario such as going from only Cyrillic today to Cyrillic > and Latin next year might not be so far fetched. Okay, I've made up my mind, a "default_script" is absolutely necessary for the lang-script-region-variant scheme. It's less important for Bruce's draft or Ira's order of tags, but for Addison's order it's necessary. Your objection "what if the world changes, as always" is valid for all proposals (default_script, associated_scripts), and the solution is obvious: If the world changes the registry has to changed. With a default_script for some languages the _absence_ of this info means "you SHOULD specify the script if you're not prepared to get content in any script". The _presence_ of a default_script means "you SHOULD NOT use the default script in tags." Changing this info later in the registry (your TR scenario, or the got-Latn => got-Goth scenario) will be a *major* headache. It's the price that has to be paid for the lang-script-region scheme, if we don't like it we can use Bruce's or Ira's ideas. Maybe Bruce's idea will win over the lang-sript-region scheme where it can win (mail, news, http, html, xhtml), but we have seen that no proposal works everywhere without some problems. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 18:59:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16469; Wed, 13 Apr 2005 18:59:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLqz6-0007HO-OT; Wed, 13 Apr 2005 19:09:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLqmz-0004Nw-RX; Wed, 13 Apr 2005 18:56:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLqmy-0004Nb-0A for ltru@megatron.ietf.org; Wed, 13 Apr 2005 18:56:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15948 for ; Wed, 13 Apr 2005 18:56:41 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLqwh-0007DN-8z for ltru@ietf.org; Wed, 13 Apr 2005 19:06:56 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Wed, 13 Apr 2005 15:56:32 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 13 Apr 2005 15:56:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: field for indicating script (was RE: [Ltru] Re: Moving Forward Date: Wed, 13 Apr 2005 15:56:04 -0700 Message-ID: Thread-Topic: field for indicating script (was RE: [Ltru] Re: Moving Forward Thread-Index: AcVAdKvToQ8bMdfbQl+LWe3M5yRJXwAA6yCwAAC1CBA= From: "Peter Constable" To: X-OriginalArrivalTime: 13 Apr 2005 22:56:32.0928 (UTC) FILETIME=[097DAA00:01C5407C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > How about: >=20 > Subtags which are not important for distinguishing content in an application SHOULD > NOT be used to form language tags. In particular, you MUST NOT use the script > subtag unless (a) the language subtag has an Expected_Script field I suggest that the label for this field be "Expected_Script_Subtags". The original suggestion, "Associated_Script", had the weakness that it didn't really communicate that for typical usage scenarios it's expected that one of the enumerated script subtags will be used. It just seems to be informing you that some script(s) are associated with the given language. The alternative "Expected_Script" (different from the change I had suggested) has the same weakness. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 19:01:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17113; Wed, 13 Apr 2005 19:01:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLr1o-0007Me-IQ; Wed, 13 Apr 2005 19:12:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLqrR-00050m-2o; Wed, 13 Apr 2005 19:01:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLqrP-00050I-G4 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 19:01:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17088 for ; Wed, 13 Apr 2005 19:01:16 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLr18-0007Lo-Qi for ltru@ietf.org; Wed, 13 Apr 2005 19:11:32 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 16:01:08 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 13 Apr 2005 16:01:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Moving Forward Date: Wed, 13 Apr 2005 16:00:36 -0700 Message-ID: Thread-Topic: [Ltru] Re: Moving Forward Thread-Index: AcVAdKvToQ8bMdfbQl+LWe3M5yRJXwAA6yCwAACva2A= From: "Peter Constable" To: X-OriginalArrivalTime: 13 Apr 2005 23:01:08.0690 (UTC) FILETIME=[ADDB9B20:01C5407C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > How about: >=20 > Subtags which are not important for distinguishing content in an application SHOULD > NOT be used to form language tags. In particular, you MUST NOT use the script > subtag unless (a) the language subtag has an Expected_Script field or (b) the specific > script distinction is important to the application. For example, the tag "en-Latn-US" > should be used exceedingly rarely since nearly all English texts are written in the Latin > script and it is generally not important to filter out those few that are not, while > documents that use the primary language subtag 'sr' (Serbian) must be distinguished > by the choice of Latin or Cyrillic script. I'd change the last clause slightly: from "... while documents that use the primary language subtag 'sr' (Serbian) must be distinguished by the choice of Latin or Cyrillic script." to "... while documents that use the primary language subtag 'sr' (Serbian) generally need to be distinguished by the choice of Latin or Cyrillic script." I wouldn't want to suggest that someone can't use something like 'sr' or 'sr-CS' if that suits their needs in a given application. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 19:09:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17923; Wed, 13 Apr 2005 19:09:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLr9M-0007bq-9w; Wed, 13 Apr 2005 19:20:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLqz9-000644-07; Wed, 13 Apr 2005 19:09:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLqz8-00063d-66 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 19:09:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17905 for ; Wed, 13 Apr 2005 19:09:15 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLr8r-0007b9-IV for ltru@ietf.org; Wed, 13 Apr 2005 19:19:30 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 16:09:06 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 13 Apr 2005 16:09:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Default script sine qua non (was: Moving Forward) Date: Wed, 13 Apr 2005 16:08:36 -0700 Message-ID: Thread-Topic: [Ltru] Default script sine qua non (was: Moving Forward) Thread-Index: AcVAe45CfLjPzDt8Q3K5PZqCxtTcRQAAVVCg From: "Peter Constable" To: X-OriginalArrivalTime: 13 Apr 2005 23:09:06.0434 (UTC) FILETIME=[CA9D8E20:01C5407D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Frank Ellermann > Okay, I've made up my mind, a "default_script" is absolutely > necessary for the lang-script-region-variant scheme... > With a default_script for some languages the _absence_ of this > info means "you SHOULD specify the script if you're not > prepared to get content in any script". >=20 > The _presence_ of a default_script means "you SHOULD NOT use > the default script in tags." This is pretty much what I suggested a few days ago (with the qualification that we include these values when we know there's a clear value that can be indicated but not otherwise). =20 > Changing this info later in the registry (your TR scenario, or > the got-Latn =3D> got-Goth scenario) will be a *major* headache. >=20 > It's the price that has to be paid for the lang-script-region > scheme, if we don't like it we can use Bruce's or Ira's ideas. >=20 > Maybe Bruce's idea will win over the lang-sript-region scheme > where it can win (mail, news, http, html, xhtml), but we have > seen that no proposal works everywhere without some problems. Some have been saying for a long time now that no proposal works everywhere without some problems, and that the lang-script-region option yields the least overall pain. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 19:17:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18406; Wed, 13 Apr 2005 19:17:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLrGQ-0007os-QM; Wed, 13 Apr 2005 19:27:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLr35-0006VE-W5; Wed, 13 Apr 2005 19:13:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLr34-0006Ui-NO for ltru@megatron.ietf.org; Wed, 13 Apr 2005 19:13:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18166 for ; Wed, 13 Apr 2005 19:13:19 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLrCn-0007hu-ON for ltru@ietf.org; Wed, 13 Apr 2005 19:23:35 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3DNDCmR000924 for ; Wed, 13 Apr 2005 19:13:12 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3DNDCii116312 for ; Wed, 13 Apr 2005 19:13:12 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3DNDCW8014514 for ; Wed, 13 Apr 2005 19:13:12 -0400 Received: from markdavis (mark-davis.cupertino.ibm.com [9.52.67.128]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with SMTP id j3DNDBoN014065; Wed, 13 Apr 2005 19:13:11 -0400 Message-ID: <06c701c5407e$5c0d4e40$4109fea9@sanjose.ibm.com> From: "Mark Davis" To: "Peter Constable" , References: Subject: Re: [Ltru] Re: Moving Forward Date: Wed, 13 Apr 2005 16:12:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e3.ny.us.ibm.com id j3DNDCmR000924 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Agreed. =E2=80=8EMark ----- Original Message -----=20 From: "Peter Constable" To: Sent: Wednesday, April 13, 2005 16:00 Subject: RE: [Ltru] Re: Moving Forward > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > How about: > > Subtags which are not important for distinguishing content in an application SHOULD > NOT be used to form language tags. In particular, you MUST NOT use the script > subtag unless (a) the language subtag has an Expected_Script field or (b) the specific > script distinction is important to the application. For example, the tag "en-Latn-US" > should be used exceedingly rarely since nearly all English texts are written in the Latin > script and it is generally not important to filter out those few that are not, while > documents that use the primary language subtag 'sr' (Serbian) must be distinguished > by the choice of Latin or Cyrillic script. I'd change the last clause slightly: from "... while documents that use the primary language subtag 'sr' (Serbian) must be distinguished by the choice of Latin or Cyrillic script." to "... while documents that use the primary language subtag 'sr' (Serbian) generally need to be distinguished by the choice of Latin or Cyrillic script." I wouldn't want to suggest that someone can't use something like 'sr' or 'sr-CS' if that suits their needs in a given application. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 19:18:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18712; Wed, 13 Apr 2005 19:18:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLrHk-0007uQ-6G; Wed, 13 Apr 2005 19:28:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLr2t-0006Ua-PV; Wed, 13 Apr 2005 19:13:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLr2s-0006TU-4w for ltru@megatron.ietf.org; Wed, 13 Apr 2005 19:13:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18133 for ; Wed, 13 Apr 2005 19:13:03 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLrCX-0007hB-Iw for ltru@ietf.org; Wed, 13 Apr 2005 19:23:18 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3DNCtUs010582 for ; Wed, 13 Apr 2005 19:12:55 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3DNCtii116872 for ; Wed, 13 Apr 2005 19:12:55 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j3DNCjqg013791 for ; Wed, 13 Apr 2005 19:12:45 -0400 Received: from markdavis (mark-davis.cupertino.ibm.com [9.52.67.128]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with SMTP id j3DNCiQ4013682; Wed, 13 Apr 2005 19:12:45 -0400 Message-ID: <06c101c5407e$4c207660$4109fea9@sanjose.ibm.com> From: "Mark Davis" To: "Peter Constable" , References: Subject: Re: field for indicating script (was RE: [Ltru] Re: Moving Forward Date: Wed, 13 Apr 2005 16:12:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e4.ny.us.ibm.com id j3DNCtUs010582 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable This sounds reasonable to me. =E2=80=8EMark ----- Original Message -----=20 From: "Peter Constable" To: Sent: Wednesday, April 13, 2005 15:56 Subject: field for indicating script (was RE: [Ltru] Re: Moving Forward > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > How about: > > Subtags which are not important for distinguishing content in an application SHOULD > NOT be used to form language tags. In particular, you MUST NOT use the script > subtag unless (a) the language subtag has an Expected_Script field I suggest that the label for this field be "Expected_Script_Subtags". The original suggestion, "Associated_Script", had the weakness that it didn't really communicate that for typical usage scenarios it's expected that one of the enumerated script subtags will be used. It just seems to be informing you that some script(s) are associated with the given language. The alternative "Expected_Script" (different from the change I had suggested) has the same weakness. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 19:41:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20691; Wed, 13 Apr 2005 19:41:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLreI-00005K-Or; Wed, 13 Apr 2005 19:51:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLrTE-0000ob-R6; Wed, 13 Apr 2005 19:40:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLrTC-0000nY-OE for ltru@megatron.ietf.org; Wed, 13 Apr 2005 19:40:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20606 for ; Wed, 13 Apr 2005 19:40:19 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLrcw-0008Tr-EN for ltru@ietf.org; Wed, 13 Apr 2005 19:50:35 -0400 Received: by wproxy.gmail.com with SMTP id 49so430260wri for ; Wed, 13 Apr 2005 16:40:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cGjDo08GOU9eQseAraa+HyAawSirbh0ts54ljsqpx2HbrV9jSAOFVSsuFaYOZfAiYC5Au8xkIJ9/I/CrZcjProzjJv3JJmuQNiM4NWhhRjYJC2S2+nMd2063PyP/oLQc0221gSfdlKHDMvWy5yNBZRXuCYpakgSgbbsHyYJwEjk= Received: by 10.54.59.2 with SMTP id h2mr5645wra; Wed, 13 Apr 2005 16:40:05 -0700 (PDT) Received: by 10.54.59.17 with HTTP; Wed, 13 Apr 2005 16:39:05 -0700 (PDT) Message-ID: <6bb028490504131639605fa9ab@mail.gmail.com> Date: Wed, 13 Apr 2005 16:39:05 -0700 From: Markus Scherer To: ltru@ietf.org Subject: Re: [Ltru] Re: Moving Forward In-Reply-To: <04cd01c54052$eba5ba50$4109fea9@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <04cd01c54052$eba5ba50$4109fea9@sanjose.ibm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Markus Scherer List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable I completely agree with Mark Davis here: For the identification of written language it is important to specify the script when languages are written in multiple scripts; for technical reasons of identification and matching that have been discussed on this list, the script needs to go in second position, after the language code and certainly before the country code. Best regards, markus (also at markus.scherer@us.ibm.com) On 4/13/05, Mark Davis wrote: > There are very good reasons for having script second; I won't repeat them= . >=20 > The chances that a vendor would gratuitously use "'en-Latn-GB" in that ca= se, > is vanishingly small, since it would cause clients grief for no purpose. --=20 Opinions expressed here may not reflect my company's positions unless otherwise noted. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 19:59:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21638; Wed, 13 Apr 2005 19:59:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLrvx-0000Vv-4z; Wed, 13 Apr 2005 20:10:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLrfl-0002y8-QE; Wed, 13 Apr 2005 19:53:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLrfj-0002xT-Mr for ltru@megatron.ietf.org; Wed, 13 Apr 2005 19:53:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21216 for ; Wed, 13 Apr 2005 19:53:16 -0400 (EDT) From: ned.freed@mrochek.com Received: from mauve.mrochek.com ([209.55.107.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLrpT-0000KJ-C8 for ltru@ietf.org; Wed, 13 Apr 2005 20:03:32 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=utf-8 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LN1VXI2OEO00005R@mauve.mrochek.com> for ltru@ietf.org; Wed, 13 Apr 2005 16:53:10 -0700 (PDT) Date: Wed, 13 Apr 2005 16:43:25 -0700 (PDT) In-reply-to: "Your message dated Wed, 13 Apr 2005 11:02:09 -0700" <04cd01c54052$eba5ba50$4109fea9@sanjose.ibm.com> Message-id: <01LN1WFEX54S00005R@mauve.mrochek.com> References: <04cd01c54052$eba5ba50$4109fea9@sanjose.ibm.com> Subject: Re: [Ltru] Re: Moving Forward To: Mark Davis X-Spam-Score: 0.3 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7BIT Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7BIT > There are very good reasons for having script second; I won't repeat them. > The chances that a vendor would gratuitously use "'en-Latn-GB" in that case, > is vanishingly small, since it would cause clients grief for no purpose. I have to say I find your faith in implementors doing the right thing in the absence of guidance to be rather sweet. It is also at odds with my own past experience with many implementations. Cases abound where implementors have done things for no purpose that caused huge amounts of grief. As I have commented previously, given how easy it is to extract script information from many sorts of data objects it is entirely possible that implementors will do it in a misguided attempt to make things work "better". Ira concern is that implementors will do this no matter what we say. This is possible as well, but it is much easier (and more legitimate) to criticize an implementation ignoring a SHOULD NOT for no good reason than it is to criticize an implementation done in a guidance vacuum. Ned _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 20:18:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22515; Wed, 13 Apr 2005 20:18:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsE0-0000th-VU; Wed, 13 Apr 2005 20:28:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLs3k-0008OM-4W; Wed, 13 Apr 2005 20:18:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLs3i-0008N9-9g for ltru@megatron.ietf.org; Wed, 13 Apr 2005 20:18:14 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22474 for ; Wed, 13 Apr 2005 20:18:07 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLs0I-0004Rd-CR for ltru@lists.ietf.org; Thu, 14 Apr 2005 02:14:42 +0200 Received: from 212.82.251.217 ([212.82.251.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2005 02:14:42 +0200 Received: from nobody by 212.82.251.217 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2005 02:14:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 14 Apr 2005 02:13:46 +0200 Organization: Lines: 37 Message-ID: <425DB5BA.BC9@xyzzy.claranet.de> References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org> <008a01c53ff1$5f473ea0$030aa8c0@DEWELL> <425CC58D.5DA@xyzzy.claranet.de> <20050413141218.GC9774@skunk.reutershealth.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.217 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Default script sine qua non (was: Moving Forward) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit John Cowan wrote: > Obscure languages are probably only written in one script, > and don't need Associated_Script. Yes, that was my point, Associated_Script doesn't help to find the default script for any language I don't know. The absence of Associated_Scripts (plural) only means "there is a default script, but we don't tell you what it is" => FUBAR, I need exactly the opposite info. A way to have both, either a default or more associations, in a list Associated_Script with either one or more entries, is of course fine, but the important case is "one" => SHOULD NOT. > English is almost always written in the Latin script, so no > script subtag should be employed exceptis excipiendis. English is a bad example, beause we all know it. The other examples (Vietnamese, tr, got, fy, ...) are better, because an implementor of software trying to match scripts might not know them. The implementor is in a bad position. For a tagger and even for a user it's better, they should know what they want. But that will change, in some years users might not know that there once was a 1766/3066 and that 3066bis desperately tried to be compatible with an incompatible scheme. And invented the ugly kludge "default_script", because the only alternative was to close this WG. > the tag got-Latn should be avoided Okay. I didn't know this. If some implementors of apache / mozilla / IE / safari / opera / Java / ... also don't know it it cannot work. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 20:34:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23410; Wed, 13 Apr 2005 20:34:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsTe-0001GG-Oi; Wed, 13 Apr 2005 20:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsGb-0001mI-29; Wed, 13 Apr 2005 20:31:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsGZ-0001lx-Fo for ltru@megatron.ietf.org; Wed, 13 Apr 2005 20:31:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23110 for ; Wed, 13 Apr 2005 20:31:21 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsQJ-0001Ax-Gv for ltru@ietf.org; Wed, 13 Apr 2005 20:41:36 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Wed, 13 Apr 2005 17:31:12 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 13 Apr 2005 17:31:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Default script sine qua non (was: Moving Forward) Date: Wed, 13 Apr 2005 17:30:30 -0700 Message-ID: Thread-Topic: [Ltru] Default script sine qua non (was: Moving Forward) Thread-Index: AcVAh3/7DP7pnwJyRnWDcGgQfldKBQAAUMYw From: "Peter Constable" To: X-OriginalArrivalTime: 14 Apr 2005 00:31:12.0215 (UTC) FILETIME=[429C1670:01C54089] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Frank Ellermann > Yes, that was my point, Associated_Script doesn't help to find > the default script for any language I don't know. The absence > of Associated_Scripts (plural) only means "there is a default > script, but we don't tell you what it is" =3D> FUBAR, I need > exactly the opposite info. I think Frank is quite right here: what we want people to do is *not* use a script subtag in some cases, and we should be telling them in which cases they should observe this expectation, not a partial statement of the opposite. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 20:40:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23955; Wed, 13 Apr 2005 20:40:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsZZ-0001Ol-28; Wed, 13 Apr 2005 20:51:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsOf-0003BZ-JL; Wed, 13 Apr 2005 20:39:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsOe-0003BG-6j for ltru@megatron.ietf.org; Wed, 13 Apr 2005 20:39:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23911 for ; Wed, 13 Apr 2005 20:39:50 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsYW-0001Nn-VF for ltru@ietf.org; Wed, 13 Apr 2005 20:50:05 -0400 Received: from lns-p19-1-idf-82-251-83-105.adsl.proxad.net ([82.251.83.105] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLsOZ-0001lO-N2; Wed, 13 Apr 2005 17:39:48 -0700 Message-Id: <6.1.2.0.2.20050414015539.0ceb6d50@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 14 Apr 2005 02:05:34 +0200 To: "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Moving Forward In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B08D1E0@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0B08D1E0@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.9 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 On 00:44 14/04/2005, Addison Phillips said: >Subtags which are not important for distinguishing content in an >application SHOULD NOT be used to form language tags. In particular, you >MUST NOT use the script subtag unless (a) the language subtag has an >Expected_Script field or (b) the specific script distinction is important >to the application. For example, the tag "en-Latn-US" should be used >exceedingly rarely since nearly all English texts are written in the Latin >script and it is generally not important to filter out those few that are >not, while documents that use the primary language subtag 'sr' (Serbian) >must be distinguished by the choice of Latin or Cyrillic script. Even me, I understand what you mean. But I am afraid it does not make a difference for a parser developer? The parser is a piece of logic, not of comparative information. That something only occurs one time, or even should not occur or all the time: it must be supported? Or am I wrong? To respond your question. 1. you are stuck with an XML design bundling bug. You try to make a feature. I think you should make it a temporary feature (to assume legacy and transition) and to fix the bug. Please consider that even if _you_ think genuinely it is a feature, the experience of this tiny WG already shows various ways to understand it: you will never prevent developpers to workout "better" solutions (a one to one, tag/parameter, approach will always be considered as more flexible). Unless you have a very strong documented rationale to bundle langtag's elements and the cacapcity to preach to developers, you _are_ eventually to support langtag, scriptag, countrytag, etc.. 2. For your XML bundling bug: your 2-4-2 tag seems a well conceived temporary patch which will work until you have given XML the extensibility it needs. Unbundling, free format. 3. your solution should be part of the second document. The general guidelines to structure application oriented formats should be discussed in the first documen, with other language tag framework issues. The responses given to Ira shows the direact relation between the tag format and the filter. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 20:41:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23994; Wed, 13 Apr 2005 20:41:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsZk-0001PD-O6; Wed, 13 Apr 2005 20:51:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsOg-0003Bd-3k; Wed, 13 Apr 2005 20:39:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsOe-0003BL-DS for ltru@megatron.ietf.org; Wed, 13 Apr 2005 20:39:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23914 for ; Wed, 13 Apr 2005 20:39:50 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsYX-0001NZ-18 for ltru@ietf.org; Wed, 13 Apr 2005 20:50:05 -0400 Received: from lns-p19-1-idf-82-251-83-105.adsl.proxad.net ([82.251.83.105] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLsOX-0001lO-Ar; Wed, 13 Apr 2005 17:39:45 -0700 Message-Id: <6.1.2.0.2.20050413235345.0cea80d0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 14 Apr 2005 00:20:48 +0200 To: "L.Gillam" , ltru From: "JFC (Jefsey) Morfin" Subject: Re: OT - RE: [Ltru] Great Script Debate Part II: Formats... In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A3AF@EVS-EC1-NODE1.surre y.ac.uk> References: <4A7C6FA2AB31194E80E13FE585F6A21292A3AF@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.9 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 hmmmm... This may be because you use "nation" in thinking of "country", "government", "territory" etc. which seems also to be valid meanings in American/English. However the following meaning seems well included (and I use and understand the term in this sense): "a people who share common customs, origins, history, and frequently language;" or "an American tribe and territory". This is one of the key problem of the use of ISO 3166 to document languages. It implies that languages come from territories and administrative rules (like the erroneous comment made recently here about the French Academy). But the languages come from nations, as Governments may also do, nation conquer territories. The French Academy is a support of the people's liberty to be understood with precision all over the nation and throughout the times, to see meanings conserved and new meaning or words easily forged or aggegated to be quickly and efficiently supported and aggregated. A function current computerized systems will probably undertake. The reason why they tagging is so important to people. jfc At 18:52 13/04/2005, L.Gillam wrote: >The remark itself, with the validation you document, I can understand. >But the generalisation, and the purpose of the remark....... well, >I am unable to pass through it to get somewhere useful. > > > > "language is the first and basic social contract of a nation" > > > > This remark isn't impenetrable; it's just true of some > > nations (Poland and > > Bangladesh come to mind) and false of others (Nigeria comes to mind). > > All nations have speakers of minority languages, but some nations make > > a common language central to their national identity. > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 20:42:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24082; Wed, 13 Apr 2005 20:42:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsau-0001Rh-Gj; Wed, 13 Apr 2005 20:52:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsOg-0003Bh-7i; Wed, 13 Apr 2005 20:39:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsOe-0003BM-Dn for ltru@megatron.ietf.org; Wed, 13 Apr 2005 20:39:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23910 for ; Wed, 13 Apr 2005 20:39:50 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsYW-0001Nk-Tp for ltru@ietf.org; Wed, 13 Apr 2005 20:50:05 -0400 Received: from lns-p19-1-idf-82-251-83-105.adsl.proxad.net ([82.251.83.105] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLsOY-0001lO-Fb; Wed, 13 Apr 2005 17:39:46 -0700 Message-Id: <6.1.2.0.2.20050414004401.02df77d0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 14 Apr 2005 01:46:46 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents In-Reply-To: <003101c5403d$1e0bce00$030aa8c0@DEWELL> References: <20050413142051.UDNA2128.mta1.adelphia.net@megatron.ietf.org> <003101c5403d$1e0bce00$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.9 (++) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 At 17:26 13/04/2005, Doug Ewell wrote: >JFC (Jefsey) Morfin wrote: > > > 2. mixed feelings among English culture Members, where confusion > > results from the bundling of various questions in a single one "do you > > support Jefsey's non detailed provision". > >Speaking only for myself, I wasn't confused at all. Randy's blanket >term, "Jefsey's provisos," was sufficiently vague that I had to actually >go back and read the post(s) in question, which I had skimmed over >before. After reading them, I clearly understood Jefsey's various >suggestions, and was confident of my opposition to them. you increase the problem rather than clarifiy it. What you oppose is my bundled personal positions (plural). Not different questions (each singular). But may be this is a normal way of thinking in this group, since the main problem it faces is of same nature: the bundling of XML parameters. >Partitioning the group into "French culture Members" and "English culture >Members" See below. >and pitting the two against each other is not how I thought consensus was >built within Working Groups, but I could easily be wrong here. I feel the term "pitting" out of context. > I don't have 27 years of Internet experience to draw on. True. But this experience shown me that intelligence may replace it advantageously. BTW these different comments lead to realise how much one of the things which suprises non-English culture people on this kind of lists is the rudeness of people who are most probably very polite in normal life. I suppose this is part of the consensus undercovering in these IETF related Working Groups? Some IETF participants make a very common error using the formula "consensus building", which by essence has no meaning. This may result from the different motivations of people in participating in the IETF interestingly discussed on the main list rigth now. This seems to actually mean "to build a proposition" that "rough consensus rules" will permit to impose to the WG to obtain the publication of a document. By essence this is a Pyrhus victory, and the main reason why every RFC do not make a standard. By nature a consensus is something which pre-exists, otherwise it is a compromise or a trap. The difficulty is to discover it as it is hidden behind many conditions ("we are in agreement if you we agree on something else before" - governing by consensus is to make fulfil these condition so the consensus may survive). The reason why we need consensuses is it is the best hope we have that what is true in a WG will also be true in the real world. The reason why we are not interested in compromise, votes, positions, etc. is that they only concern the group which discusses them and not the real world. Here we have two consensuses (which is a normal possibility). One is clear and supported by determined and able people (the position of this WG will not affect the real world deployment and the plans we work on). The other is confuse and contradictory (it makes the registry empty since ISO 639-3 uses reference names which by essence are not of a language, therefore not English. And even if you twisted the text of the "consensus" in accepting ISO 639-3 reference names of English origin, the autonyms should stay blocked .... these people refusing "1000" languages, forgetting that ISO 639-3 uses probably more than 1000 languages ... So, we can only say from this that two opposing consensus emerged. These two consensus seem to be supported (a) by what seems to be an extended anglo-saxon culture group, (b) by a non-extended-anglo-saxon culture. The limited number of participants in (b) does not make it clear if that culture is limited to one single individual, extended to the cultures of the various authoritative entities he is related to. The response will be possibly observed during the Last Call, etc. , the IANA implementation and the MRP (market real practices). jfc >-Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 20:42:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24126; Wed, 13 Apr 2005 20:42:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLsbO-0001S0-Rv; Wed, 13 Apr 2005 20:53:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsRI-0003nB-SD; Wed, 13 Apr 2005 20:42:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLsRG-0003mG-PG for ltru@megatron.ietf.org; Wed, 13 Apr 2005 20:42:34 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24115 for ; Wed, 13 Apr 2005 20:42:32 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLsNp-0006Oy-3S for ltru@lists.ietf.org; Thu, 14 Apr 2005 02:39:01 +0200 Received: from 212.82.251.217 ([212.82.251.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2005 02:39:01 +0200 Received: from nobody by 212.82.251.217 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2005 02:39:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 14 Apr 2005 02:38:50 +0200 Organization: Lines: 26 Message-ID: <425DBB9A.2E3A@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.217 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Default script sine qua non X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Peter Constable wrote: > This is pretty much what I suggested a few days ago (with > the qualification that we include these values when we know > there's a clear value that can be indicated but not > otherwise). Yes, as discussed before the Great Script Debate, maybe we can delegate the task of populating the initial registry with the "default_script" values to the language tag review list. Or we do it on the fly in Doug's list, initial value for all languages is "TBD", the final draft must not have any "TBD". > Some have been saying for a long time now that no proposal > works everywhere without some problems, and that the > lang-script-region option yields the least overall pain. One thing we should explain in the registry draft is the Zyyy counter-kludge for the case "I really want _any_ script for a language with default_script". In practice this is probably highly irrelevant, but curious minds want to know (otherwise they'd ask what this WG was smoking, and that would be worse). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 21:07:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25635; Wed, 13 Apr 2005 21:07:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLszl-00023W-GD; Wed, 13 Apr 2005 21:18:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLspT-0007Tl-B1; Wed, 13 Apr 2005 21:07:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLspR-0007T1-9K for ltru@megatron.ietf.org; Wed, 13 Apr 2005 21:07:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25604 for ; Wed, 13 Apr 2005 21:07:23 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLszB-000231-Ow for ltru@ietf.org; Wed, 13 Apr 2005 21:17:39 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Wed, 13 Apr 2005 18:07:14 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 13 Apr 2005 18:07:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Default script sine qua non Date: Wed, 13 Apr 2005 18:07:21 -0700 Message-ID: Thread-Topic: [Ltru] Re: Default script sine qua non Thread-Index: AcVAiuQiPfgZ8YzSS1KWGsAEdySURQAAwH8g From: "Peter Constable" To: X-OriginalArrivalTime: 14 Apr 2005 01:07:14.0765 (UTC) FILETIME=[4B9707D0:01C5408E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Frank Ellermann > One thing we should explain in the registry draft is the Zyyy > counter-kludge for the case "I really want _any_ script for a > language with default_script". In practice this is probably > highly irrelevant, but curious minds want to know (otherwise > they'd ask what this WG was smoking, and that would be worse). Of course, the problem is someone wanting to request "I want only the default script -- don't dare give me anything in Braille, some transliteration or uncommon script, etc." Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 21:39:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27648; Wed, 13 Apr 2005 21:39:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLtUb-0002uK-VG; Wed, 13 Apr 2005 21:50:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLtJl-0004EP-Lm; Wed, 13 Apr 2005 21:38:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLtJj-0004ED-Uh for ltru@megatron.ietf.org; Wed, 13 Apr 2005 21:38:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27614 for ; Wed, 13 Apr 2005 21:38:42 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLtTU-0002tb-PK for ltru@ietf.org; Wed, 13 Apr 2005 21:48:58 -0400 Received: from lns-p19-1-idf-82-251-83-105.adsl.proxad.net ([82.251.83.105] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DLtJZ-000222-0P; Wed, 13 Apr 2005 18:38:41 -0700 Message-Id: <6.1.2.0.2.20050414024529.02e2a370@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 14 Apr 2005 03:38:20 +0200 To: Frank Ellermann , ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Default script sine qua non In-Reply-To: <425DBB9A.2E3A@xyzzy.claranet.de> References: <425DBB9A.2E3A@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 2.9 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 I agree with the position of Frank. But this is only an additional reason for scripttags. A default_script is a pre-entered scripttag. Flexibility in script is necessary to enlarge/reduce/change script in a page. For example in a form to permit uppercases only. To support mathematic formula. Are there Members of the TeX community on this list? I would be interested in comments from experience? jfc At 02:38 14/04/2005, Frank Ellermann wrote: >Peter Constable wrote: > > > This is pretty much what I suggested a few days ago (with > > the qualification that we include these values when we know > > there's a clear value that can be indicated but not > > otherwise). > >Yes, as discussed before the Great Script Debate, maybe we can >delegate the task of populating the initial registry with the >"default_script" values to the language tag review list. > >Or we do it on the fly in Doug's list, initial value for all >languages is "TBD", the final draft must not have any "TBD". > > > Some have been saying for a long time now that no proposal > > works everywhere without some problems, and that the > > lang-script-region option yields the least overall pain. > >One thing we should explain in the registry draft is the Zyyy >counter-kludge for the case "I really want _any_ script for a >language with default_script". In practice this is probably >highly irrelevant, but curious minds want to know (otherwise >they'd ask what this WG was smoking, and that would be worse). > > Bye, Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 22:05:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29036; Wed, 13 Apr 2005 22:05:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLtt0-0003UV-GR; Wed, 13 Apr 2005 22:15:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLtii-0007U6-PG; Wed, 13 Apr 2005 22:04:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLtig-0007TH-T9 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 22:04:39 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28996 for ; Wed, 13 Apr 2005 22:04:20 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DLted-0005gz-8Z for ltru@lists.ietf.org; Thu, 14 Apr 2005 04:00:27 +0200 Received: from 212.82.251.217 ([212.82.251.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2005 04:00:27 +0200 Received: from nobody by 212.82.251.217 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2005 04:00:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 14 Apr 2005 04:01:25 +0200 Organization: Lines: 15 Message-ID: <425DCEF5.74E4@xyzzy.claranet.de> References: <20050413142051.UDNA2128.mta1.adelphia.net@megatron.ietf.org> <003101c5403d$1e0bce00$030aa8c0@DEWELL> <6.1.2.0.2.20050414004401.02df77d0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.217 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: quoted-printable Subject: [Ltru] Re: registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable JFC (Jefsey) Morfin wrote: > supported (a) by what seems to be an extended anglo-saxon > culture group, (b) by a non-extended-anglo-saxon culture. Ground control to major Jefsey, are you talking about Randy's 5.49 : 3.51 decision ? None of these nine people represents any culture, they just have different _technical_ reasons to want more or less info in the registry. Among these reasons are the size of the registry, the problems for the tag review procedure, the "ugliness" of too many NCRs in the registry, and the bogosity of adding F=E9ro=E9 to Faroe if the real (native) name is F=F8royar (maybe). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 23:29:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04635; Wed, 13 Apr 2005 23:29:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvCr-0005PC-Nx; Wed, 13 Apr 2005 23:39:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLv08-000249-EF; Wed, 13 Apr 2005 23:26:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLuzy-00023r-Ff for ltru@megatron.ietf.org; Wed, 13 Apr 2005 23:26:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04542 for ; Wed, 13 Apr 2005 23:26:32 -0400 (EDT) Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLv9s-0005Lo-7A for ltru@ietf.org; Wed, 13 Apr 2005 23:36:49 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1DLuzo-0001Uw-IL; Wed, 13 Apr 2005 23:26:24 -0400 Date: Wed, 13 Apr 2005 23:26:24 -0400 To: Frank Ellermann Subject: Re: [Ltru] Default script sine qua non (was: Moving Forward) Message-ID: <20050414032624.GB835@ccil.org> References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org> <008a01c53ff1$5f473ea0$030aa8c0@DEWELL> <425CC58D.5DA@xyzzy.claranet.de> <20050413141218.GC9774@skunk.reutershealth.com> <425DB5BA.BC9@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425DB5BA.BC9@xyzzy.claranet.de> 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@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Frank Ellermann scripsit: > John Cowan wrote: > > > Obscure languages are probably only written in one script, > > and don't need Associated_Script. > > Yes, that was my point, Associated_Script doesn't help to find > the default script for any language I don't know. The absence > of Associated_Scripts (plural) only means "there is a default > script, but we don't tell you what it is" => FUBAR, I need > exactly the opposite info. For what purpose? The registry isn't supposed to be a general compendium of information on languages (and I repeat, most languages have no script because they aren't written). > A way to have both, either a default or more associations, in > a list Associated_Script with either one or more entries, is of > course fine, but the important case is "one" => SHOULD NOT. No, it's zero scripts that means SHOULD NOT. -- John Cowan cowan@ccil.org http://www.reutershealth.com 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 23:45:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05747; Wed, 13 Apr 2005 23:45:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvSV-0005oA-0K; Wed, 13 Apr 2005 23:56:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvHY-00052A-1o; Wed, 13 Apr 2005 23:44:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvHW-00051v-L9 for ltru@megatron.ietf.org; Wed, 13 Apr 2005 23:44:42 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05635 for ; Wed, 13 Apr 2005 23:44:39 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DLvDU-0006IP-3h for ltru@lists.ietf.org; Thu, 14 Apr 2005 05:40:32 +0200 Received: from 212.82.251.217 ([212.82.251.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2005 05:40:32 +0200 Received: from nobody by 212.82.251.217 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2005 05:40:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 14 Apr 2005 05:40:49 +0200 Organization: Lines: 6 Message-ID: <425DE641.1649@xyzzy.claranet.de> References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org> <008a01c53ff1$5f473ea0$030aa8c0@DEWELL> <425CC58D.5DA@xyzzy.claranet.de> <20050413141218.GC9774@skunk.reutershealth.com> <425DB5BA.BC9@xyzzy.claranet.de> <20050414032624.GB835@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.217 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Default script sine qua non X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit John Cowan wrote: > No, it's zero scripts that means SHOULD NOT. Let's close the WG. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Wed Apr 13 23:57:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06484; Wed, 13 Apr 2005 23:57:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLve0-0006Dl-LU; Thu, 14 Apr 2005 00:07:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvTe-0006kj-O9; Wed, 13 Apr 2005 23:57:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvTc-0006ka-To for ltru@megatron.ietf.org; Wed, 13 Apr 2005 23:57:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06397 for ; Wed, 13 Apr 2005 23:57:02 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvdP-0006Ch-S3 for ltru@ietf.org; Thu, 14 Apr 2005 00:07:20 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 20:56:53 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Wed, 13 Apr 2005 20:56:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Default script sine qua non (was: Moving Forward) Date: Wed, 13 Apr 2005 20:56:54 -0700 Message-ID: Thread-Topic: [Ltru] Default script sine qua non (was: Moving Forward) Thread-Index: AcVAolKCSC37WXTBRDea55TRkelepwAAi9XQ From: "Peter Constable" To: X-OriginalArrivalTime: 14 Apr 2005 03:56:52.0883 (UTC) FILETIME=[FE389630:01C540A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of John Cowan > > Yes, that was my point, Associated_Script doesn't help to find > > the default script for any language I don't know. The absence > > of Associated_Scripts (plural) only means "there is a default > > script, but we don't tell you what it is" =3D> FUBAR, I need > > exactly the opposite info. >=20 > For what purpose? The registry isn't supposed to be a general > compendium of information on languages (and I repeat, most languages > have no script because they aren't written). That isn't the intent Frank is getting at, or that I was getting at when I suggested this a few days ago. It's simply to make clear in what cases a script subtag should not generally be used. In the case of, say, the Ormuri language, if we don't even know if it's written, then no value would be given.=20 In the case of a language like Azeri, no value would be given because we know that no one script can be assumed to occur in a majority of content. In the case of languages like French, Russian, Arabic, Thai, etc. a single value would be given because we know that one script can be assumed in the vast majority of content. In that way, it will be clear to users which for languages a script subtag should not be included (expect for uncommon usage scenarios). >=20 > > A way to have both, either a default or more associations, in > > a list Associated_Script with either one or more entries, is of > > course fine, but the important case is "one" =3D> SHOULD NOT. >=20 > No, it's zero scripts that means SHOULD NOT. No, he's not talking about the Expected_Script_Subtags proposal, in which the subtags that should be used are enumerated. He's talking about his proposal, in which the script subtags that should *not* typically be included are enumerated. Under this proposal, e.g. exactly one script subtag would be listed for cases such as English, which are the cases in which we don't want a script subtag used. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 00:02:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06908; Thu, 14 Apr 2005 00:02:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLviL-0006K2-8B; Thu, 14 Apr 2005 00:12:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvXA-0007Kw-Ej; Thu, 14 Apr 2005 00:00:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvX8-0007Km-OG for ltru@megatron.ietf.org; Thu, 14 Apr 2005 00:00:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06800 for ; Thu, 14 Apr 2005 00:00:48 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvh2-0006Ho-MB for ltru@ietf.org; Thu, 14 Apr 2005 00:11:06 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3E40P3g021984; Wed, 13 Apr 2005 21:00:25 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AHPVV>; Wed, 13 Apr 2005 21:00:26 -0700 Message-ID: From: "McDonald, Ira" To: "'John Cowan'" , Frank Ellermann Subject: RE: [Ltru] Default script sine qua non (was: Moving Forward) Date: Wed, 13 Apr 2005 21:00:24 -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: 0fa76816851382eb71b0a882ccdc29ac Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Hi, Given Peter's excellent ExpectedScriptSubtags: - zero scripts ought to be MUST NOT for script subtag, - one script ought to be SHOULD NOT (with strong rationale for developers) - two or more scripts ought to be MAY (with examples of exceptions) I agree that the registry (as Peter has suggested) should tell the whole truth (as far as is known by linguists on the mailing list) for each registered base language about the legitimate scripts. (Braille is a hard exception here - we don't want to pollute the one script rule, if possible - I suppose this applies equally to Sign, but we already have the anomalous 'sgn-xxx' tags). If there are some real MUST NOTs and some well-explained SHOULD NOTs in RFC3066bis, I'm ready to quietly concede and accept that script is the second canonical position in the ABNF. Really, as Addison says, let's move on. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of John Cowan > Sent: Wednesday, April 13, 2005 11:26 PM > To: Frank Ellermann > Cc: ltru@ietf.org > Subject: Re: [Ltru] Default script sine qua non (was: Moving Forward) > > > Frank Ellermann scripsit: > > John Cowan wrote: > > > > > Obscure languages are probably only written in one script, > > > and don't need Associated_Script. > > > > Yes, that was my point, Associated_Script doesn't help to find > > the default script for any language I don't know. The absence > > of Associated_Scripts (plural) only means "there is a default > > script, but we don't tell you what it is" => FUBAR, I need > > exactly the opposite info. > > For what purpose? The registry isn't supposed to be a general > compendium of information on languages (and I repeat, most languages > have no script because they aren't written). > > > A way to have both, either a default or more associations, in > > a list Associated_Script with either one or more entries, is of > > course fine, but the important case is "one" => SHOULD NOT. > > No, it's zero scripts that means SHOULD NOT. > > -- > John Cowan cowan@ccil.org > http://www.reutershealth.com 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@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 00:06:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07236; Thu, 14 Apr 2005 00:06:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvmu-0006UA-Pr; Thu, 14 Apr 2005 00:17:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvaQ-0008Dt-0O; Thu, 14 Apr 2005 00:04:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLvaO-0008Dn-CL for ltru@megatron.ietf.org; Thu, 14 Apr 2005 00:04:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07147 for ; Thu, 14 Apr 2005 00:04:09 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLvkH-0006Qj-2x for ltru@ietf.org; Thu, 14 Apr 2005 00:14:27 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3E440ua375330 for ; Thu, 14 Apr 2005 00:04:00 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3E440of298368 for ; Wed, 13 Apr 2005 22:04:00 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3E43xVx000360 for ; Wed, 13 Apr 2005 22:03:59 -0600 Received: from markdavis (sig-9-48-118-75.mts.ibm.com [9.48.118.75]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3E43wMt000332; Wed, 13 Apr 2005 22:03:59 -0600 Message-ID: <001901c540a6$fbcfde20$4b763009@sanjose.ibm.com> From: "Mark Davis" To: "Peter Constable" , "LTRU Working Group" References: Subject: Re: [Ltru] Re: Default script sine qua non Date: Wed, 13 Apr 2005 21:03:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j3E440ua375330 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable I don't quite understand the proposal. The scenario that people were talk= ing about was: Q. What should I put in as my language in my browser, and what should a w= eb page provider use, en-US or en--US? A. Look in the registry and see if there are more than two Expected_Script_Subtags for en. If so, use one of the scripts there. If n= ot, don't. If there is another concrete implementation scenario that requires the script, where it is not easily obtainable outside of the registry, I'd li= ke to see that before we go any further. Otherwise, I see no reason to burde= n the registry with the addition of a default script as well. =E2=80=8EMark ----- Original Message -----=20 From: "Peter Constable" To: Sent: Wednesday, April 13, 2005 18:07 Subject: RE: [Ltru] Re: Default script sine qua non > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Frank Ellermann > One thing we should explain in the registry draft is the Zyyy > counter-kludge for the case "I really want _any_ script for a > language with default_script". In practice this is probably > highly irrelevant, but curious minds want to know (otherwise > they'd ask what this WG was smoking, and that would be worse). Of course, the problem is someone wanting to request "I want only the default script -- don't dare give me anything in Braille, some transliteration or uncommon script, etc." Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 01:33:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12389; Thu, 14 Apr 2005 01:33:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLx95-0000D3-7m; Thu, 14 Apr 2005 01:44:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLwxL-0003YN-Q8; Thu, 14 Apr 2005 01:31:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLwxJ-0003Xz-FJ for ltru@megatron.ietf.org; Thu, 14 Apr 2005 01:31:57 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12317 for ; Thu, 14 Apr 2005 01:31:48 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050414053117.YIZX5402.mta11.adelphia.net@DEWELL> for ; Thu, 14 Apr 2005 01:31:17 -0400 Message-ID: <008f01c540b3$2a804460$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050413225859.MWYT2132.mta5.adelphia.net@megatron.ietf.org> Date: Wed, 13 Apr 2005 22:31:09 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Addison Phillips > How about: > > Subtags which are not important for distinguishing content in an > application SHOULD NOT be used to form language tags. In particular, > you MUST NOT use the script subtag unless (a) the language subtag has > an Expected_Script field or (b) the specific script distinction is > important to the application. For example, the tag "en-Latn-US" should > be used exceedingly rarely since nearly all English texts are written > in the Latin script and it is generally not important to filter out > those few that are not, while documents that use the primary language > subtag 'sr' (Serbian) must be distinguished by the choice of Latin or > Cyrillic script. I can see I'm not going to win this "default script" argument, so I'm just going to back off and wait for the next draft that contains whatever solution the group agrees on. I do think that anyone proposing that the initial registry contain default-script information for all 479 ISO 639-1 and -2 languages (not just a few obvious multi-script cases that Addison and Mark had suggested) be prepared to recommend a reliable source for this information. Also, I still believe in the language-script-region order and strongly support it. IMHO the proponents of LRS order are relying solely on the argument that LSR doesn't work with certain scenarios of left-prefix matching where LRS does, ignoring the fact that for other, equally plausible scenarios, LRS doesn't work and LSR does. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 01:38:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12625; Thu, 14 Apr 2005 01:38:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLxDt-0000Kp-45; Thu, 14 Apr 2005 01:49:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLx2W-0004FX-Ir; Thu, 14 Apr 2005 01:37:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLx2U-0004FS-9A for ltru@megatron.ietf.org; Thu, 14 Apr 2005 01:37:18 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12537 for ; Thu, 14 Apr 2005 01:37:17 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050414053647.ZBIT2192.mta9.adelphia.net@DEWELL> for ; Thu, 14 Apr 2005 01:36:47 -0400 Message-ID: <009401c540b3$ee707c00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050413225859.MWYT2132.mta5.adelphia.net@megatron.ietf.org> Subject: Re: field for indicating script (was RE: [Ltru] Re: Moving Forward) Date: Wed, 13 Apr 2005 22:36:38 -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 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Peter Constable wrote: > I suggest that the label for this field be "Expected_Script_Subtags". > The original suggestion, "Associated_Script", had the weakness that it > didn't really communicate that for typical usage scenarios it's > expected that one of the enumerated script subtags will be used. It > just seems to be informing you that some script(s) are associated with > the given language. The alternative "Expected_Script" (different from > the change I had suggested) has the same weakness. The exact wording that is chosen for the draft will probably have much more to do with the strength or weakness of the "recommendation" than the name of the field itself. And it seems oddly redundant to me to use the word "Subtags" in the name of a field that contains subtags. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 02:02:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16973; Thu, 14 Apr 2005 02:02:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLxan-00010J-G2; Thu, 14 Apr 2005 02:12:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLxOv-0006RK-TK; Thu, 14 Apr 2005 02:00:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLxOt-0006Py-7P for ltru@megatron.ietf.org; Thu, 14 Apr 2005 02:00:27 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14609 for ; Thu, 14 Apr 2005 02:00:09 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050414055939.ZNNI2192.mta9.adelphia.net@DEWELL> for ; Thu, 14 Apr 2005 01:59:39 -0400 Message-ID: <00b101c540b7$1c35ae00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050414035745.MFTB4543.mta4.adelphia.net@megatron.ietf.org> Date: Wed, 13 Apr 2005 22:59:23 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: >> Speaking only for myself, I wasn't confused at all. Randy's blanket >> term, "Jefsey's provisos," was sufficiently vague that I had to >> actually go back and read the post(s) in question, which I had >> skimmed over before. After reading them, I clearly understood >> Jefsey's various suggestions, and was confident of my opposition to >> them. > > you increase the problem rather than clarifiy it. What you oppose is > my bundled personal positions (plural). Not different questions (each > singular). But may be this is a normal way of thinking in this group, > since the main problem it faces is of same nature: the bundling of XML > parameters. Would you prefer if I express my opposition to the points individually, rather than bundling them together? Very well: > 1. if an Englist or French (or other languages to be added) name for a > language is missing, it will be accepted as non fully documented until > a name is provided (a IANA procedure and Reviewer will have to be > designated). I oppose this because of the needless overhead involved in blacklisting a registry entry as "non fully documented" because it has not been retrofitted with both an English and a French name. As others have indicated, many of the ISO 639-3 names are neither demonstrably English nor demonstrably French. This is not an issue for ISO 639-1 and -2, ISO 15924, ISO 3166, and UN M.49 because those standards already have French names; however, the existing variant subtags and grandfathered and redundant tags would all have to be retrofitted. > 2. the same IANA registration could only be entered in English or > French. It will be up to the French/English Reviewer to make sure the > name in the missing language(s) is provided. I oppose the concept of appointing a separate French/English Reviewer to enforce the registration (and presumably the linguistic suitability) of dual names. The descriptions of items proposed for registration have always been the responsibility of the person submitting the proposal, and should continue to be so. If you had other provisos besides these two, please send them to the list so I can consider them as well. I hate asking people to re-send things they have already sent, but there has been a huge amount of traffic on this list lately and I may have missed something. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 03:39:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11358; Thu, 14 Apr 2005 03:39:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLz6J-0003a9-QN; Thu, 14 Apr 2005 03:49:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLytN-0004BY-Ky; Thu, 14 Apr 2005 03:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLytH-00048w-IM for ltru@megatron.ietf.org; Thu, 14 Apr 2005 03:35:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11231 for ; Thu, 14 Apr 2005 03:35:45 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLz36-0003VI-6d for ltru@ietf.org; Thu, 14 Apr 2005 03:46:04 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Thu, 14 Apr 2005 08:35:08 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 08:35:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents Date: Thu, 14 Apr 2005 08:35:06 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A2121A594A@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents Thread-Index: AcVAiys+txKc1QVMS3+Wcn0GAfZRuAAM/XPJ From: "L.Gillam" To: ltru X-OriginalArrivalTime: 14 Apr 2005 07:35:07.0051 (UTC) FILETIME=[7AF40FB0:01C540C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1267639909==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e This is a multi-part message in MIME format. --===============1267639909== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C540C4.7AD51F64" This is a multi-part message in MIME format. ------_=_NextPart_001_01C540C4.7AD51F64 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Jefsey, =20 It may surprise you to learn that 639-3 will emerge from ISO, not this = list. More specifically, it will emerge from ISO TC 37, whose title is = currently "Terminology and other language resources". Currently there is = a proposal to extend this title further to something like "Terminology = and other language and content resources". TC 37 is made up of nominated = representatives from national member bodies from a variety of countries. = Originally it just dealt with "Terminology". The various representatives = have in-depth understanding of, amongst other things, issues of = translation in relation to languages in specialisations - ISO/IEC = background, the work of Wuster (sans umlaut) and so forth. Such a = committee understands, very well, the principles of = conceptually-oriented systems. Based on this extensive expertise, the = current DIS document was created. Do you suggest that you have more = expertise in these matters than the entirety of TC 37 and the members of = this list on such matters?=20 =20 The purpose of reference names is to EXPLICITLY not be associated to a = single language. They are used to act as "conceptual" identifiers as I = have said previously on this very list. They are intended to be used to = avoid accusations of language preference. They might be in English, they = might be in French, they might be an autonym. The names are meant to = "exist" outside the context of a language, and the intention is that = they SHOULD NOT be analysed. A reference name COULD be /x1k4as5d6s7kb/ - = why not? The reference name stands in place of the documentary evidence = and so forth for that item. I don't see why this causes you a problem.=20 =20 For further reading, please, please, see: http://www.iso.org/iso/en/stdsdevelopment/tc/tclist/TechnicalCommitteeDet= ailPage.TechnicalCommitteeDetail?COMMID=3D1459 =20 I would also recommend reading, and fully digesting, documents including = ISO 10241, ISO 16642, ISO 12620, ISO 704 and ISO 1087 parts 1 and 2 and = other drafts as are emerging from TC 37. John Sowa's book on "Knowledge = Representation",=20 http://www.benjamins.com/jbp/series/TERM/9-2/art/0006a.pdf, and a = library-load of other such documents will help you understand better = what is being discussed. ________________________________ From: ltru-bounces@lists.ietf.org on behalf of JFC (Jefsey) Morfin Sent: Thu 14/04/2005 00:46 (it makes the registry empty since ISO 639-3 uses reference names which by essence are not of a language, therefore = not English. And even if you twisted the text of the "consensus" in = accepting ISO 639-3 reference names of English origin, the autonyms should stay blocked .... these people refusing "1000" languages, forgetting that ISO 639-3 uses probably more than 1000 languages ... ------_=_NextPart_001_01C540C4.7AD51F64 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= Re: [Ltru] Re: [psg.com #882] registry should copy non-English = fields from ISO documents=0A= =0A= =0A=
=0A=
 
=0A=
Jefsey,
=0A=
 
=0A=
It may surprise you to learn = that 639-3 =0A= will emerge from ISO, not this list. More specifically, it will emerge = from ISO =0A= TC 37, whose title is currently "Terminology and other language = resources". =0A= Currently there is a proposal to extend this title further to something = like =0A= "Terminology and other language and content resources". TC 37 is made up of nominated representatives from national = member =0A= bodies from a variety of countries. Originally it just dealt with =0A= "Terminology". The various representatives have in-depth understanding = of, =0A= amongst other things, issues of translation in relation to = languages in =0A= specialisations - ISO/IEC background, the work of Wuster (sans umlaut) = and so =0A= forth. Such a committee understands, very well,  the principles of =0A= conceptually-oriented systems. Based on this extensive expertise, = the =0A= current DIS document was created. Do you suggest that you have more = expertise in =0A= these matters than the entirety of TC 37 and the members of this = list on =0A= such matters? 
=0A=
 
=0A=
The purpose of reference = names is to =0A= EXPLICITLY not be associated to a single language. They are used to act = as =0A= "conceptual" identifiers as I have said previously on this very list. = They are =0A= intended to be used to avoid accusations of language preference. = They might =0A= be in English, they might be in French, they might be an autonym. The =0A= names are meant to "exist" outside the context of a language, and = the =0A= intention is that they SHOULD NOT be analysed. A reference name COULD =0A= be /x1k4as5d6s7kb/ - why not? The reference name stands in place of = the =0A= documentary evidence and so forth for that item. I don't see why this causes you a problem.
=0A=
 
=0A=
For further reading, please, =0A= please, see:
=0A= =0A=
 
=0A=
I would also recommend reading, and fully =0A= digesting, documents including ISO 10241, ISO 16642, ISO 12620, ISO = 704 and =0A= ISO 1087 parts 1 and 2 and other drafts as are emerging from TC 37. John = Sowa's =0A= book on "Knowledge Representation",
=0A=
http:= //www.benjamins.com/jbp/series/TERM/9-2/art/0006a.pdf, =0A= and a library-load of other such documents will help you understand = better what =0A= is being discussed.
=0A=

=0A=
=0A=
=0A=
=0A=
From: = ltru-bounces@lists.ietf.org =0A= on behalf of JFC (Jefsey) Morfin
Sent: Thu 14/04/2005 =0A= 00:46
=0A=
(it makes the registry empty since ISO = 639-3
uses =0A= reference names which by essence are not of a language, therefore =0A= not
English. And even if you twisted the text of the  = "consensus" in =0A= accepting
ISO 639-3 reference names of English origin, the autonyms = should =0A= stay
blocked .... these people refusing "1000" languages, forgetting = that =0A= ISO
639-3 uses probably more than 1000 languages =0A= ...

=0A= =0A= =0A= ------_=_NextPart_001_01C540C4.7AD51F64-- --===============1267639909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1267639909==-- From ltru-bounces@ietf.org Thu Apr 14 04:15:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14138; Thu, 14 Apr 2005 04:15:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLzfj-0004gk-Hx; Thu, 14 Apr 2005 04:25:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLzTa-0000Mr-PB; Thu, 14 Apr 2005 04:13:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLzSz-0000Cp-Qy for ltru@megatron.ietf.org; Thu, 14 Apr 2005 04:12:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13812 for ; Thu, 14 Apr 2005 04:12:23 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLzcX-0004b7-U8 for ltru@ietf.org; Thu, 14 Apr 2005 04:22:43 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Thu, 14 Apr 2005 09:09:39 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 09:09:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Off Topic (was Re: [Ltru] Great Script Debate Part II: Formats...) Date: Thu, 14 Apr 2005 09:09:37 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A3B2@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: Off Topic (was Re: [Ltru] Great Script Debate Part II: Formats...) Thread-Index: AcVARYyV4QbZ/oSkQzmOSLnt1aJzYwAg/3NA From: "L.Gillam" To: ltru X-OriginalArrivalTime: 14 Apr 2005 08:09:38.0239 (UTC) FILETIME=[4D7A44F0:01C540C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============2123286417==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d --===============2123286417== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpKZWZzZXkncyBsYXN0IGZldyBzdGF0ZW1lbnRzIG1hZGUgbWUgcmVhbGlzZSBhIHBvc3NpYmxl IHNvbHV0aW9uIGZvciBoaW0uDQoNCkhlIGlkZW50aWZpZWQgYSBkZXNpcmUgdG8gdXNlIGEgdGFn ICJqZWZzZXktMjAwNSIgb3Igc2ltaWxhci4NCg0KT2YgY291cnNlLCBoZSBjYW4gZG8gdGhpcyB3 aXRoIHByaXZhdGUgdXNlIGV4dGVuc2lvbnMuIFRoaXMgYWxzbyBzZWVtcyB0bw0KYmUgYW4gYXBw bGljYWJsZSBzb2x1dGlvbiBmb3IgaGlzICJuYXRpb25zIi4NCg0KU28sIGlmIEplZnNleSB0YWdz IGhpcyBjb250ZW50IHdpdGggImVuLXgtamVmc2V5LTIwMDUiLCB0aGUgbGlzdCBjYW4NCmNvbmZp Z3VyZSBpdHMgY29udGVudC1hY2NlcHRhbmNlIGFjY29yZGluZ2x5Lg0KDQpXaGV0aGVyIHN1Y2gg YSB0YWcgd291bGQgb25seSBiZSBhY2NlcHRlZCBpZiBpdCBoYXMgYmVlbiBnaXZlbiBhIG5hbWUN CmluIGV2ZXJ5IHBvc3NpYmxlIGxhbmd1YWdlIGlzIGFub3RoZXIgbWF0dGVyLiAgDQo= --===============2123286417== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2123286417==-- From ltru-bounces@ietf.org Thu Apr 14 04:39:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15680; Thu, 14 Apr 2005 04:39:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM02V-0005I5-Dv; Thu, 14 Apr 2005 04:49:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLzqQ-0003dT-Ez; Thu, 14 Apr 2005 04:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLzqK-0003Xu-Ti for ltru@megatron.ietf.org; Thu, 14 Apr 2005 04:36:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15458 for ; Thu, 14 Apr 2005 04:36:30 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLzzt-0005DQ-8V for ltru@ietf.org; Thu, 14 Apr 2005 04:46:50 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Thu, 14 Apr 2005 09:29:52 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 09:29:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Default script sine qua non (was: Moving Forward) Date: Thu, 14 Apr 2005 09:29:51 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A3B4@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Default script sine qua non (was: Moving Forward) Thread-Index: AcVAolKCSC37WXTBRDea55TRkelepwAAi9XQAAmCioA= From: "L.Gillam" To: ltru X-OriginalArrivalTime: 14 Apr 2005 08:29:51.0481 (UTC) FILETIME=[20A04E90:01C540CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Peter,=20 Let me just clarify the intention of these identifications - relates to Ira's mail also. > In the case of, say, the Ormuri language, if we don't even=20 > know if it's > written, then no value would be given.=20 >=20 > In the case of a language like Azeri, no value would be given=20 > because we > know that no one script can be assumed to occur in a majority of > content. These two cases - unknown script, no assumed script - result in the same empty value. Would empty be sufficient, or would a=20 UNKNOWN identifier be needed, or some similar mechanism? > In the case of languages like French, Russian, Arabic, Thai, etc. a > single value would be given because we know that one script can be > assumed in the vast majority of content. Is the option "no script" or "this script" here? - I'm not yet clear. > In that way, it will be clear to users which for languages a script > subtag should not be included (expect for uncommon usage scenarios). Is the option, then, "no script" or "one of these"? If = ExpectedScriptSubtags simply covers the range of possible scripts that are expected to be used = for a given language, would there be an impact on the programmatic = interpretation in systems if the extension from "one only" to "more than one" happens=20 (the Cyrl only to Cyrl + Latn case)? I'm not yet clear about this intended solution, or whether it helps the "put script here" discussion.=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 10:07:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14929; Thu, 14 Apr 2005 10:07:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM59m-0000ZL-Fi; Thu, 14 Apr 2005 10:17:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4zJ-0006RQ-Vs; Thu, 14 Apr 2005 10:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4zG-0006QZ-QF for ltru@megatron.ietf.org; Thu, 14 Apr 2005 10:06:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14727 for ; Thu, 14 Apr 2005 10:06:20 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM598-0000XQ-8Z for ltru@ietf.org; Thu, 14 Apr 2005 10:16:42 -0400 Received: from if12m5-235.d4.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DM4z2-00040f-0h; Thu, 14 Apr 2005 07:06:16 -0700 Message-Id: <6.1.2.0.2.20050414114602.043f93a0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 14 Apr 2005 11:50:32 +0200 To: Frank Ellermann From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: registry should copy non-English fields from ISO documents In-Reply-To: <425DCEF5.74E4@xyzzy.claranet.de> References: <20050413142051.UDNA2128.mta1.adelphia.net@megatron.ietf.org> <003101c5403d$1e0bce00$030aa8c0@DEWELL> <6.1.2.0.2.20050414004401.02df77d0@mail.jefsey.com> <425DCEF5.74E4@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA14727 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable On 04:01 14/04/2005, Frank Ellermann said: >JFC (Jefsey) Morfin wrote: > > > supported (a) by what seems to be an extended anglo-saxon > > culture group, (b) by a non-extended-anglo-saxon culture. > >Ground control to major Jefsey, are you talking about Randy's >5.49 : 3.51 decision ? None of these nine people represents >any culture, they just have different _technical_ reasons to >want more or less info in the registry. Among these reasons >are the size of the registry, the problems for the tag review >procedure, the "ugliness" of too many NCRs in the registry, >and the bogosity of adding F=E9ro=E9 to Faroe if the real (native) >name is F=F8royar (maybe). Dear Frank, we obviously are not here for the fun. But for the technical, political,=20 economical and societal implications every IETF standard and procedure ha= s.=20 IETF has made the choice of having no market study/review prior its=20 publications and to wait for the market inputs before making an RFC a=20 standard. This has lead some technical, political, economical and societa= l=20 interests to join the IETF to use its RFC mechanism to try to influence t= he=20 market in its favor. This is precisely right now under debate on the main= =20 list between the Chair and Members from various types of organizations -=20 including non-profits like me - and individual dedicated voluntaries like= =20 you (from what you explained). This creates a problem between people who=20 are paid and have time and people who pay and have far less. The diversity of their cultures and interests is precisely what permits t= he=20 IETF to propose valuable documents and acknowledge de facto standard=20 resulting from these documents. There are cases where the same need is=20 addressed by different solutions due to the impossibility to find a commo= n=20 background between two positions. I think we have fully demonstrated that in this case. As you indicate the= re=20 are 9 persons on side, attracting no more (*). There is one opponent=20 because no one in the real world seem to accept that what these nine=20 people propose makes enough sense to worry about. Let get real, if I am=20 the only opponent here it is because I probably am the only opponent who=20 instead of shrugging shoulders, acknowledge the real need expressed by Ad= dison. (*) we could obviously call upon number like in the MARID case. What woul= d=20 be the interest? We could also evaluate who is for that among paid and paying members=20 communities. This is usually a good way to evaluate what is of medium and= =20 what is of long range interest to the users. Commercial interest run mark= et=20 studies and if they are big enough will impact the market anyway. NonCom=20 have usually the liberty of the vision and the determination which "makes= =20 it happen". They have not the immediate time - but they have the long ter= m=20 time. In this case we have two opposed interests. People wanting to patch XML,=20 proceed with CLDR like plans, possibly sell their work and expertise=20 through ISO and similar channels. These are good and legitimate interests= .=20 But they conflict - and will not defeat - with the fact that a Multilinga= l=20 Internet is not an "Internationalized confusion" but based needs to be=20 based upon a clear, stable, user acceptable/ed, network architecture=20 integrated identification of the languages parameters. As long as they wa= nt=20 to lead the game, instead of serving it because they are as every other=20 frustrated by the (partly voluntary) lack of understanding of IESG/IETF,=20 they will not go through and are wasting time for their totally legitimat= e=20 need. IRT the practicalities you talk about, you should consider them in the=20 broader perspective of true relation assistance services (or extended=20 services) and economy. But this is another internet architectural aspect,= =20 parallel in need and similar to multilingualism (cf. OPES which, IMHO, ar= e=20 mudded by the problem as this WG). jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 10:08:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15407; Thu, 14 Apr 2005 10:08:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM5Ba-0000ie-SP; Thu, 14 Apr 2005 10:19:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4zH-0006R9-D2; Thu, 14 Apr 2005 10:06:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM4zG-0006QX-H3 for ltru@megatron.ietf.org; Thu, 14 Apr 2005 10:06:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14723 for ; Thu, 14 Apr 2005 10:06:20 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM598-0000XT-8U for ltru@ietf.org; Thu, 14 Apr 2005 10:16:42 -0400 Received: from if12m5-235.d4.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DM4z0-00040f-Gf; Thu, 14 Apr 2005 07:06:15 -0700 Message-Id: <6.1.2.0.2.20050414112729.03f3ea90@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 14 Apr 2005 16:05:51 +0200 To: John Cowan , Frank Ellermann From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Default script sine qua non (was: Moving Forward) In-Reply-To: <20050414032624.GB835@ccil.org> References: <20050412211520.IOVS2135.mta2.adelphia.net@megatron.ietf.org> <008a01c53ff1$5f473ea0$030aa8c0@DEWELL> <425CC58D.5DA@xyzzy.claranet.de> <20050413141218.GC9774@skunk.reutershealth.com> <425DB5BA.BC9@xyzzy.claranet.de> <20050414032624.GB835@ccil.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 At 05:26 14/04/2005, John Cowan wrote: >Frank Ellermann scripsit: > > John Cowan wrote: > > > > > Obscure languages are probably only written in one script, > > > and don't need Associated_Script. > > > > Yes, that was my point, Associated_Script doesn't help to find > > the default script for any language I don't know. The absence > > of Associated_Scripts (plural) only means "there is a default > > script, but we don't tell you what it is" => FUBAR, I need > > exactly the opposite info. > >For what purpose? The registry isn't supposed to be a general >compendium of information on languages The registry to be of use and to stay is to be a root file on languages. This can be achieved in two ways: - either the discussed IANA file is the Internet language root file. I do not push for that because this makes the cost to be beared by TLDs and the financial and political stability of the project is not warranted. - or the discussed registry is an RFC that can be used as a language root file by language compendia. I favor that approach because this means that the work is assumed by an IETF WG, can be taken back/completed by any specialised international body, etc. and has an operational cost extremely limited. Any other way brings not enough added value over ISO existing langtag, scriptag, countrytag, that non one will really pay attention to it. The XML patch will be carried otherwise (there will be the W3C XML, the M$ XML, etc. if needed - do not forget that the W3C is not an open structure as is IETF). >(and I repeat, most languages have no script because they aren't written). We are talking of a standard, not of news paper. As soon as a language is in the list, this becomes accidental because anyone you do not know may decide to make it written or may already have. jfc ps. I thank you for having reduced the risks of harm for my organization in changing your mail. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 10:22:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17778; Thu, 14 Apr 2005 10:22:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM5Oa-0001PJ-Fw; Thu, 14 Apr 2005 10:32:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM5Cu-0001H1-HI; Thu, 14 Apr 2005 10:20:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM5Ct-0001Bu-8W for ltru@megatron.ietf.org; Thu, 14 Apr 2005 10:20:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17465 for ; Thu, 14 Apr 2005 10:20:28 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM5Mn-0001KV-Ip for ltru@ietf.org; Thu, 14 Apr 2005 10:30:51 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Thu, 14 Apr 2005 07:20:18 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Thu, 14 Apr 2005 07:20:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Moving Forward Date: Thu, 14 Apr 2005 07:20:19 -0700 Message-ID: Thread-Topic: [Ltru] Re: Moving Forward Thread-Index: AcVAs5T7rMOmO+p4QbWao1O6YnUWxwASSRPg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 14 Apr 2005 14:20:16.0684 (UTC) FILETIME=[149FAEC0:01C540FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Doug Ewell > I do think that anyone proposing that the initial registry contain > default-script information for all 479 ISO 639-1 and -2 languages That is not what Frank or I have suggested. A default-script field only needs values for languages like English for which we don't want people to use script subtags in general. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 10:23:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18044; Thu, 14 Apr 2005 10:23:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM5Q1-0001Wg-4C; Thu, 14 Apr 2005 10:34:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM5FX-0001mI-I1; Thu, 14 Apr 2005 10:23:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM5FW-0001lt-PM for ltru@megatron.ietf.org; Thu, 14 Apr 2005 10:23:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17958 for ; Thu, 14 Apr 2005 10:23:08 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM5PO-0001RN-56 for ltru@ietf.org; Thu, 14 Apr 2005 10:33:31 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 07:22:58 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Thu, 14 Apr 2005 07:22:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: [psg.com #882] registry should copy non-English fieldsfrom ISO documents Date: Thu, 14 Apr 2005 07:23:01 -0700 Message-ID: Thread-Topic: [Ltru] Re: [psg.com #882] registry should copy non-English fieldsfrom ISO documents Thread-Index: AcVAuHEh5SxS8FRrTduLoXSQf1rUEwARNBfA From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 14 Apr 2005 14:22:58.0775 (UTC) FILETIME=[753CCE70:01C540FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Doug Ewell > Would you prefer... > If you had other provisos besides these two, please send them to the > list... Randy has already indicated that issue 882 has been closed as rejected. Please don't invite further discussion of this issue. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 11:10:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23099; Thu, 14 Apr 2005 11:10:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM691-0003eR-8v; Thu, 14 Apr 2005 11:20:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM5uq-0003BY-VZ; Thu, 14 Apr 2005 11:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM5up-00038F-Od for ltru@megatron.ietf.org; Thu, 14 Apr 2005 11:05:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22763 for ; Thu, 14 Apr 2005 11:05:57 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM64p-0003Ui-Kh for ltru@ietf.org; Thu, 14 Apr 2005 11:16:20 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3EF5hYL017934; Thu, 14 Apr 2005 08:05:43 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AH49T>; Thu, 14 Apr 2005 08:05:43 -0700 Message-ID: From: "McDonald, Ira" To: "'Peter Constable'" , LTRU Working Group Subject: RE: [Ltru] Re: Moving Forward Date: Thu, 14 Apr 2005 08:05:43 -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: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Hi, Peter - your proposal appears to be wobbling between (1) One new field - ExpectedScript (complete list) (2) Two new fields - DefaultScript (do NOT use a script subtag) - ExpectedScript (not including DefaultScript value??) If this registry (and RFC3066bis) don't make VERY clear when script subtags MUST NOT be used, then we're making no headway. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Peter Constable > Sent: Thursday, April 14, 2005 10:20 AM > To: LTRU Working Group > Subject: RE: [Ltru] Re: Moving Forward > > > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Doug Ewell > > > > I do think that anyone proposing that the initial registry contain > > default-script information for all 479 ISO 639-1 and -2 languages > > That is not what Frank or I have suggested. A default-script > field only > needs values for languages like English for which we don't want people > to use script subtags in general. > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 11:15:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23526; Thu, 14 Apr 2005 11:15:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6Dz-0003sN-M5; Thu, 14 Apr 2005 11:25:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM60i-0003rJ-T9; Thu, 14 Apr 2005 11:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM60h-0003ql-E1 for ltru@megatron.ietf.org; Thu, 14 Apr 2005 11:12:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23268 for ; Thu, 14 Apr 2005 11:11:53 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6AZ-0003kU-8G for ltru@ietf.org; Thu, 14 Apr 2005 11:22:16 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Thu, 14 Apr 2005 08:11:44 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Thu, 14 Apr 2005 08:11:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Default script sine qua non (was: Moving Forward) Date: Thu, 14 Apr 2005 08:11:47 -0700 Message-ID: Thread-Topic: [Ltru] Default script sine qua non (was: Moving Forward) Thread-Index: AcVAolKCSC37WXTBRDea55TRkelepwAAi9XQAAmCioAADNoucA== From: "Peter Constable" To: "ltru" X-OriginalArrivalTime: 14 Apr 2005 15:11:44.0738 (UTC) FILETIME=[453F5420:01C54104] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of L.Gillam > Let me just clarify the intention of these identifications - relates > to Ira's mail also. I think we have two options on the table here: 1) language subtags include a field called "Expected_Script_Subtags". Values and the meaning thereof are as follows: - languages like Ormuri: we have no knowledge of written form, so no value is entered; no guidance is provided regarding use of script subtags - languages like English, Russian, Arabic, Thai: known to use one script only in the vast majority of content (others may be used in specialized content, however); *exactly one value* is entered, meaning that that script subtag should not in general be used (but can be used in specialized applications) - languages like Azeri, Chinese: known to have more than one script in common use; multiple values are entered, meaning that inclusion of a script subtag is unrestricted, and that it's expected that one of the enumerated subtags will generally be used 2) language subtags include a field called "Default_Script". Values and the meaning thereof are as follows: - languages like Ormuri: we have no knowledge of written form; no value is entered; no guidance is provided regarding use of script subtags, also implying that there are no script subtags are identified as being dis-recommended from being used - languages like Azeri, Chinese: known to have more than one script in common use;=20 - sub-option a) no value is entered, meaning that no script subtags are dis-recommended from being used - sub-option b) multiple values are entered, meaning=20 that inclusion of a script subtag is unrestricted,=20 and that it's expected that one of the enumerated=20 subtags will generally be used - languages like English, Russian, Arabic, Thai: known to use one script only in the vast majority of content (others may be used in specialized content, however); exactly one value is entered, meaning that that script subtag should not in general be used (but can be used in specialized applications) > [for cases like Ormuri] would a > UNKNOWN identifier be needed, or some similar mechanism? I think it would be good to be explicit about what we do or don't know, though it would put a greater burden on us for sorting out the less-well-researched cases (more of a problem after we include 639-3).=20 What we know best is which languages we definitely don't want people using script subtags in general applications. Option 2a requires us to enter only that info.=20 For languages with multiple scripts in common use, we probably have pretty good knowledge about the scripts that are used for the most likely-to-be-encountered languages. The problem is that there is a continuum in our knowledge and in usage. E.g.,=20 - we know that Chinese has two commonly used scripts, Hans and Hant - we know that three scripts have been used for Tajik -- Latn, Cyrl and Arab -- but I seem to recall that one of these is not commonly used - it's not widely known but I happen to know that two scripts (Ethiopic and Latn) have been used for Wolaytta, but this may be (I don't know) a neo-literacy situation in which two scripts were in use only temporarily and the community has since rejected one and embraced the other. - I know that multiple scripts are used for Pwo Karen, but besides Thai I'm not sure which others have been used. - Out of many dozens of languages spoken in regions straddling borders in SE Asia, I know there are languages that are written and that have been written using more than one script, but I don't know much in the way of specifics. Option 1 requires us to make some decision about this continuum. > If ExpectedScriptSubtags > simply covers the range of possible scripts that are expected to be used > for > a given language, would there be an impact on the programmatic > interpretation > in systems if the extension from "one only" to "more than one" happens > (the Cyrl only to Cyrl + Latn case)? Good question. It would have to correspond to a scenario like (e.g.) a change from Ukranian being commonly written only in Cyrillic to widespread adoption within a significant proportion of users of (say) Latin script. These kinds of changes would be messy for us -- and that would be the case no matter what means we adopt for handling script distinctions except if we were to decide to ignore our meager 10 years of legacy usage and always included a script subtag, even for cases like English. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 11:21:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23961; Thu, 14 Apr 2005 11:21:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6Ju-00047f-7Q; Thu, 14 Apr 2005 11:31:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM67e-0004Uu-EQ; Thu, 14 Apr 2005 11:19:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM67b-0004UO-Kh for ltru@megatron.ietf.org; Thu, 14 Apr 2005 11:19:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23763 for ; Thu, 14 Apr 2005 11:19:01 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6HT-00040B-Ky for ltru@ietf.org; Thu, 14 Apr 2005 11:29:24 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 08:18:53 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Thu, 14 Apr 2005 08:18:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Moving Forward Date: Thu, 14 Apr 2005 08:18:56 -0700 Message-ID: Thread-Topic: [Ltru] Re: Moving Forward Thread-Index: AcVBA3r94gsTtNShRLCCkkpCRIWCowAANZfw From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 14 Apr 2005 15:18:53.0132 (UTC) FILETIME=[449710C0:01C54105] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Peter - your proposal appears to be wobbling between > (1) One new field > - ExpectedScript (complete list) > (2) Two new fields > - DefaultScript (do NOT use a script subtag) > - ExpectedScript (not including DefaultScript value??) No. Last week I proposed that there be one field along the lines of DefaultScript. Various people objected, promoting AssociatedScript instead, so I asked that that be changed to ExpectedScriptSubtags. Then yesterday Frank pointed out a problem with that approach, pushing for having a DefaultScript field, and I agreed with his argument. So, either way, I support one new field; I favour having that be DefaultScript, but if it's to be the other approach, I think it should be called ExpectedScriptSubtags. =20 > If this registry (and RFC3066bis) don't make VERY clear > when script subtags MUST NOT be used, then we're making > no headway. I'm in general agreement. I would not be so restrictive as to say MUST NOT, however: I think there are exceptional scenarios in which it may be appropriate to use en-Latn-GB. But it definitely should be made clear that such tags should not be used in general. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 11:24:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24202; Thu, 14 Apr 2005 11:24:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6MU-0004Ed-8p; Thu, 14 Apr 2005 11:34:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM64Q-0004CT-1o; Thu, 14 Apr 2005 11:15:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM64O-0004C6-7M for ltru@megatron.ietf.org; Thu, 14 Apr 2005 11:15:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23558 for ; Thu, 14 Apr 2005 11:15:41 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6EG-0003sL-6B for ltru@ietf.org; Thu, 14 Apr 2005 11:26:05 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 08:15:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Moving Forward Date: Thu, 14 Apr 2005 08:15:22 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08D461@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Moving Forward Thread-Index: AcVBA633qHttlL+FQvWHRyCn59YwwAAAOFHg From: "Addison Phillips" To: "McDonald, Ira" , "Peter Constable" , "LTRU Working Group" X-OriginalArrivalTime: 14 Apr 2005 15:15:23.0040 (UTC) FILETIME=[C75D9200:01C54104] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable All, I'm working on a prototype revision to section 2.3 (Choice of Language = Tag) that encapsulates this thread. I'll post it later this morning on = this list. I think it addresses your concerns Ira without being too onerous to = implement in the registry. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of McDonald, Ira > Sent: jeudi 14 avril 2005 08:06 > To: 'Peter Constable'; LTRU Working Group > Subject: RE: [Ltru] Re: Moving Forward >=20 > Hi, >=20 > Peter - your proposal appears to be wobbling between > (1) One new field > - ExpectedScript (complete list) > (2) Two new fields > - DefaultScript (do NOT use a script subtag) > - ExpectedScript (not including DefaultScript value??) >=20 > If this registry (and RFC3066bis) don't make VERY clear > when script subtags MUST NOT be used, then we're making > no headway. >=20 > Cheers, > - Ira >=20 > 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 >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of Peter Constable > > Sent: Thursday, April 14, 2005 10:20 AM > > To: LTRU Working Group > > Subject: RE: [Ltru] Re: Moving Forward > > > > > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] > > On > > > Behalf Of Doug Ewell > > > > > > > I do think that anyone proposing that the initial registry contain > > > default-script information for all 479 ISO 639-1 and -2 languages > > > > That is not what Frank or I have suggested. A default-script > > field only > > needs values for languages like English for which we don't want = people > > to use script subtags in general. > > > > > > > > Peter Constable > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 11:27:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24428; Thu, 14 Apr 2005 11:27:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6PJ-0004Lc-Mr; Thu, 14 Apr 2005 11:37:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM67s-0004ZS-UM; Thu, 14 Apr 2005 11:19:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM67r-0004Uw-Ma for ltru@megatron.ietf.org; Thu, 14 Apr 2005 11:19:27 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23796 for ; Thu, 14 Apr 2005 11:19:11 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050414151840.VLTY7277.mta10.adelphia.net@DEWELL> for ; Thu, 14 Apr 2005 11:18:40 -0400 Message-ID: <00d401c54105$37108a80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050414081358.QLCL4543.mta4.adelphia.net@megatron.ietf.org> Subject: Re: Off Topic (was Re: [Ltru] Great Script Debate Part II: Formats...) Date: Thu, 14 Apr 2005 08:18:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit L.Gillam wrote: > Jefsey's last few statements made me realise a possible solution for > him. > > He identified a desire to use a tag "jefsey-2005" or similar. > > Of course, he can do this with private use extensions. This also seems > to be an applicable solution for his "nations". > > So, if Jefsey tags his content with "en-x-jefsey-2005", the list can > configure its content-acceptance accordingly. > > Whether such a tag would only be accepted if it has been given a name > in every possible language is another matter. I agree with Lee. I've thought for quite some time that Jefsey's need to tag "referent" and "style" would be best met with private-use subtags. His example of "jefsey-2005" illustrates what he has said many times, that his "referent" subtag would go down to the level of "individual variations." Since nobody's ever going to register subtags for tens of thousands of individual speakers, let alone billions (no hyperbole here), it seems appropriate and reasonable to use the private-use mechanism for that. And until "style" is defined in somewhat more stable and concrete terms than what I have seen so far, that might be a good candidate for private-use subtags as well. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 11:39:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25277; Thu, 14 Apr 2005 11:39:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6bF-0004pP-Of; Thu, 14 Apr 2005 11:49:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6Qw-0007lI-Ez; Thu, 14 Apr 2005 11:39:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6Qu-0007jD-O5 for ltru@megatron.ietf.org; Thu, 14 Apr 2005 11:39:08 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25256 for ; Thu, 14 Apr 2005 11:38:58 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050414153829.WSMM7277.mta10.adelphia.net@DEWELL> for ; Thu, 14 Apr 2005 11:38:29 -0400 Message-ID: <00e301c54107$fb6b0ac0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050414152509.QJSZ2128.mta1.adelphia.net@megatron.ietf.org> Date: Thu, 14 Apr 2005 08:38:17 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Peter Constable wrote: >> I do think that anyone proposing that the initial registry contain >> default-script information for all 479 ISO 639-1 and -2 languages > > That is not what Frank or I have suggested. A default-script field > only needs values for languages like English for which we don't want > people to use script subtags in general. I thought somebody, possibly Frank, possibly Ira, had suggested that all languages that are commonly written in a single script should have that script indicated with this new tag. Many, perhaps the majority, of the existing ISO 639-1 and -2 languages are single-script (not to claim that the additional languages in ISO 639-3 are). We can count on two hands the examples of two-or-more-script languages that have been used on this list recently: Chinese, Azerbaijani, Serbian, Mongolian, Tajik -- did I miss any? Probably a great many Indian languages fall into this category too. But there are a lot of single-script languages too, and I noticed a shift from "don't indicate the script" to "do indicate the script so applications know what is being omitted." That second approach requires quite a bit more research. How do "languages like English" differ from other single-script languages in this regard? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 11:48:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26006; Thu, 14 Apr 2005 11:48:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6k2-0005Cy-T3; Thu, 14 Apr 2005 11:58:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6Tc-0000SQ-4x; Thu, 14 Apr 2005 11:41:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6Ta-0000RI-Iw for ltru@megatron.ietf.org; Thu, 14 Apr 2005 11:41:54 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25461 for ; Thu, 14 Apr 2005 11:41:36 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050414154107.WWYI7277.mta10.adelphia.net@DEWELL> for ; Thu, 14 Apr 2005 11:41:07 -0400 Message-ID: <00e801c54108$590571c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050414152509.QJSZ2128.mta1.adelphia.net@megatron.ietf.org> Date: Thu, 14 Apr 2005 08:40:54 -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 Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Peter Constable wrote: >> Would you prefer... > >> If you had other provisos besides these two, please send them to the >> list... > > Randy has already indicated that issue 882 has been closed as > rejected. Please don't invite further discussion of this issue. Sorry. It had been claimed that my objection was based on "confusion" and failure to consider the points on their individual merits, and I was just responding to that. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 12:06:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27310; Thu, 14 Apr 2005 12:06:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM71c-0005yd-1i; Thu, 14 Apr 2005 12:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6iI-0002UD-Q8; Thu, 14 Apr 2005 11:57:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM6iH-0002TE-Vi for ltru@megatron.ietf.org; Thu, 14 Apr 2005 11:57:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26606 for ; Thu, 14 Apr 2005 11:56:55 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM6s9-0005Z7-OZ for ltru@ietf.org; Thu, 14 Apr 2005 12:07:19 -0400 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3EFuj4I039696 for ; Thu, 14 Apr 2005 11:56:46 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3EFujV2209926 for ; Thu, 14 Apr 2005 09:56:45 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3EFuju2031625 for ; Thu, 14 Apr 2005 09:56:45 -0600 Received: from markdavis (sig-9-48-123-129.mts.ibm.com [9.48.123.129]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3EFuicF031599; Thu, 14 Apr 2005 09:56:44 -0600 Message-ID: <009101c5410a$8e4aeac0$4b763009@sanjose.ibm.com> From: "Mark Davis" To: "Peter Constable" , "LTRU Working Group" References: Subject: Re: [Ltru] Re: Moving Forward Date: Thu, 14 Apr 2005 08:56:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j3EFuj4I039696 X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: quoted-printable I think part of the problem is that it was not set out clearly, until you= r message Peter, exactly what data would be expected for the 3 cases: A. We know the language is customarily used with more than one script B. We know the language is customarily used with one script C. The information for A or B is not available in the registry: either ju= st not entered yet, or hard to find out. So we could have any of the following strategies, with XX, or YY, or ZZ chosen to be the least misleading label for whatever the situation is. A. XX: Cyrl XX: Latn B. XX: Latn C. or A. B. YY: Latn C. or A. ZZ: Cyrl ZZ: Latn B. C. As I said before, I have not yet seen an implementation scenario where we need the infomation in B, and both the strategies that use it require entering in much more data than the ZZ scenario. So I'd like to see a scenario that drives B clearly stated. But frankly, I don't care much abo= ut whichever approach is chosen as long as 1. it is documented so that C behaves reasonably, because it is reasonabl= y easy to fill out the values for A and B for either approach for the high-runner languages, but we don't want the absence of information to be misread. 2. As Peter says, we mustn't say MUST NOT, however: there are scenarios i= n which it may be appropriate to use en-Latn or ko-Latn. =E2=80=8EMark ----- Original Message -----=20 From: "Peter Constable" To: "LTRU Working Group" Sent: Thursday, April 14, 2005 08:18 Subject: RE: [Ltru] Re: Moving Forward > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Peter - your proposal appears to be wobbling between > (1) One new field > - ExpectedScript (complete list) > (2) Two new fields > - DefaultScript (do NOT use a script subtag) > - ExpectedScript (not including DefaultScript value??) No. Last week I proposed that there be one field along the lines of DefaultScript. Various people objected, promoting AssociatedScript instead, so I asked that that be changed to ExpectedScriptSubtags. Then yesterday Frank pointed out a problem with that approach, pushing for having a DefaultScript field, and I agreed with his argument. So, either way, I support one new field; I favour having that be DefaultScript, but if it's to be the other approach, I think it should be called ExpectedScriptSubtags. > If this registry (and RFC3066bis) don't make VERY clear > when script subtags MUST NOT be used, then we're making > no headway. I'm in general agreement. I would not be so restrictive as to say MUST NOT, however: I think there are exceptional scenarios in which it may be appropriate to use en-Latn-GB. But it definitely should be made clear that such tags should not be used in general. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 13:14:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03360; Thu, 14 Apr 2005 13:14:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM84r-0000U5-Qx; Thu, 14 Apr 2005 13:24:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM7rx-0000OE-6s; Thu, 14 Apr 2005 13:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM7rw-0000HJ-4P for ltru@megatron.ietf.org; Thu, 14 Apr 2005 13:11:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03233 for ; Thu, 14 Apr 2005 13:10:42 -0400 (EDT) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM81Z-0000NL-9C for ltru@ietf.org; Thu, 14 Apr 2005 13:21:07 -0400 Received: from h-64-105-137-86.snvacaid.dynamic.covad.net ([64.105.137.86] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DM7rU-0002QZ-00 for ltru@ietf.org; Thu, 14 Apr 2005 10:10:40 -0700 Message-ID: <003601c54115$17476240$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050414152509.QJSZ2128.mta1.adelphia.net@megatron.ietf.org> <00e801c54108$590571c0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: [psg.com #882] registry should copy non-English fields from ISO documents Date: Thu, 14 Apr 2005 10:12:08 -0700 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: 52e1467c2184c31006318542db5614d5 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Thursday, April 14, 2005 8:40 AM > Subject: [Ltru] Re: [psg.com #882] registry should copy non-English fieldsfrom ISO documents > > Peter Constable wrote: > > >> Would you prefer... > > > >> If you had other provisos besides these two, please send them to the > >> list... > > > > Randy has already indicated that issue 882 has been closed as > > rejected. Please don't invite further discussion of this issue. > > Sorry. It had been claimed that my objection was based on "confusion" > and failure to consider the points on their individual merits, and I was > just responding to that. > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ The follow-up clarifications by you and especially Lee's post on the language neutrality of reference names should have enlightened anyone who missed those points when they were previously made in this thread. Although issue 882 has been rejected and we should now move on, I'm glad the followup took place. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 13:14:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03380; Thu, 14 Apr 2005 13:14:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM84z-0000Xy-El; Thu, 14 Apr 2005 13:24:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM7rx-0000P3-MN; Thu, 14 Apr 2005 13:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM7rw-0000Hx-FC for ltru@megatron.ietf.org; Thu, 14 Apr 2005 13:11:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03252 for ; Thu, 14 Apr 2005 13:10:51 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM81k-0000Nm-9V for ltru@ietf.org; Thu, 14 Apr 2005 13:21:16 -0400 Received: from if12m5-235.d4.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DM7EY-0001W0-Mq; Thu, 14 Apr 2005 09:30:27 -0700 Message-Id: <6.1.2.0.2.20050414182053.05855c40@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 14 Apr 2005 18:29:44 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: Off Topic (was Re: [Ltru] Great Script Debate Part II: Formats...) In-Reply-To: <00d401c54105$37108a80$030aa8c0@DEWELL> References: <20050414081358.QLCL4543.mta4.adelphia.net@megatron.ietf.org> <00d401c54105$37108a80$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 I must rush and may be out of reach for 2 days. There is no real problem with this. Again, as long as the format for XML is fine and does not claim to be the format for the world and that the five level of multilingualism/vernacular are supported, if the QA and openess warranted by bilingual tables and the registration is opposed rather than accepted, I am OK. You just may want to consider that: - there may be some serious political reluctance to "x": it has been objected with "xn--" as meaning "exclusion" or "xenophobe" or "christian" - this is not a real problem for me, but be prepared to the "-x-" to be forgotten as soon as some one find a way to support it. - this will be all the more true that referent will register. Keep in mind that the more referent register it means they are interested. Then they will probably take over the register itself. In such a case, the RFC formula I propose will be a warranty of stability (there is only one RFC while there may be many reference centers, with different speed of access, added value, etc. jfc At 17:18 14/04/2005, Doug Ewell wrote: >L.Gillam wrote: > > > Jefsey's last few statements made me realise a possible solution for > > him. > > > > He identified a desire to use a tag "jefsey-2005" or similar. > > > > Of course, he can do this with private use extensions. This also seems > > to be an applicable solution for his "nations". > > > > So, if Jefsey tags his content with "en-x-jefsey-2005", the list can > > configure its content-acceptance accordingly. > > > > Whether such a tag would only be accepted if it has been given a name > > in every possible language is another matter. > >I agree with Lee. I've thought for quite some time that Jefsey's need >to tag "referent" and "style" would be best met with private-use >subtags. > >His example of "jefsey-2005" illustrates what he has said many times, >that his "referent" subtag would go down to the level of "individual >variations." Since nobody's ever going to register subtags for tens of >thousands of individual speakers, let alone billions (no hyperbole >here), it seems appropriate and reasonable to use the private-use >mechanism for that. > >And until "style" is defined in somewhat more stable and concrete terms >than what I have seen so far, that might be a good candidate for >private-use subtags as well. > >-Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 13:29:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04247; Thu, 14 Apr 2005 13:29:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8JU-00016I-6d; Thu, 14 Apr 2005 13:39:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM88P-000449-75; Thu, 14 Apr 2005 13:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM88O-00043X-LL for ltru@megatron.ietf.org; Thu, 14 Apr 2005 13:28:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04188 for ; Thu, 14 Apr 2005 13:27:57 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8IH-00011F-RG for ltru@ietf.org; Thu, 14 Apr 2005 13:38:23 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3EHRngr007054; Thu, 14 Apr 2005 13:27:49 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 14 Apr 2005 13:27:50 -0400 Date: Thu, 14 Apr 2005 13:27:49 -0400 From: John Cowan To: Peter Constable Subject: Re: [Ltru] Re: Moving Forward Message-ID: <20050414172749.GB9432@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Peter Constable scripsit: > > I do think that anyone proposing that the initial registry contain > > default-script information for all 479 ISO 639-1 and -2 languages > > That is not what Frank or I have suggested. A default-script field only > needs values for languages like English for which we don't want people > to use script subtags in general. Since almost all 639-2 languages are written, and since the great preponderance of those are written in just one script (things like Braille and IPA aside), that means that, indeed, almost all languages will require the default-script field to be populated. Addison's proposal involves populating only those languages customarily written in two or more scripts. This is much easier to deal with logistically. -- By Elbereth and Luthien the Fair, you shall jcowan@reutershealth.com have neither the Ring nor me! --Frodo http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 13:56:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06466; Thu, 14 Apr 2005 13:56:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8jZ-0002BB-RH; Thu, 14 Apr 2005 14:06:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8Wd-0001uz-PJ; Thu, 14 Apr 2005 13:53:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8Wc-0001uh-72 for ltru@megatron.ietf.org; Thu, 14 Apr 2005 13:53:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06277 for ; Thu, 14 Apr 2005 13:53:00 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime02.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8gV-000209-EU for ltru@ietf.org; Thu, 14 Apr 2005 14:03:24 -0400 Received: from eupig1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 14 Apr 2005 17:52:47 +0000 Message-ID: Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IEY00G2P6ZZWI@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 14 Apr 2005 17:52:47 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Thu, 14 Apr 2005 18:52:46 +0100 Date: Thu, 14 Apr 2005 18:52:46 +0100 From: Misha Wolf To: ltru MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Thread-Topic: zh-Bopo? Thread-Index: AcVBGsOt82j3ReMGQ1asgBWktJSkMQ== content-class: urn:content-classes:message X-OriginalArrivalTime: 14 Apr 2005 17:52:46.0672 (UTC) FILETIME=[C4357500:01C5411A] X-Spam-Score: 1.2 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Ltru] zh-Bopo? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0254348589==" Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is a multi-part message in MIME format. --===============0254348589== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C5411A.C41C5210" content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5411A.C41C5210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Whatever approach we choose for adding script info to the registry, would we include, eg, Bopo with Hant and Hans? =20 Misha =20 =20 ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. ------_=_NextPart_001_01C5411A.C41C5210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Whateve= r approach=20 we choose for adding script info to the registry, would we include,= eg, Bopo=20 with Hant and Hans?
 
Misha
 
 


-----------------------------------------------------------------
Visit our Internet site at http://www.reuters.com

To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo

Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Reuters Ltd.
 ------_=_NextPart_001_01C5411A.C41C5210-- --===============0254348589== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0254348589==-- From ltru-bounces@ietf.org Thu Apr 14 14:03:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07157; Thu, 14 Apr 2005 14:03:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8qr-0002So-Ss; Thu, 14 Apr 2005 14:14:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8ff-0003ld-CJ; Thu, 14 Apr 2005 14:02:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8fd-0003lY-KR for ltru@megatron.ietf.org; Thu, 14 Apr 2005 14:02:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07045 for ; Thu, 14 Apr 2005 14:02:20 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8pX-0002QV-3S for ltru@ietf.org; Thu, 14 Apr 2005 14:12:44 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3EI2AT4007263; Thu, 14 Apr 2005 14:02:11 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 14 Apr 2005 14:02:17 -0400 Date: Thu, 14 Apr 2005 14:02:17 -0400 From: John Cowan To: Misha Wolf Subject: Re: [Ltru] zh-Bopo? Message-ID: <20050414180217.GE9432@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Misha Wolf scripsit: > Whatever approach we choose for adding script info to the registry, > would we include, eg, Bopo with Hant and Hans? Good question. Are first-year textbooks in Chinese schools written in Bopo? I can hardly imagine any other application for a complete document in it. It would hardly be worth language-tagging Bopo ruby in an ordinary zh-Han? document. -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com In computer science, we stand on each other's feet. --Brian K. Reid _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 14:17:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08506; Thu, 14 Apr 2005 14:17:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM93p-00030o-JI; Thu, 14 Apr 2005 14:27:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8pK-00063w-1g; Thu, 14 Apr 2005 14:12:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM8pI-0005yh-J9 for ltru@megatron.ietf.org; Thu, 14 Apr 2005 14:12:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08070 for ; Thu, 14 Apr 2005 14:12:21 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM8zE-0002rF-Oo for ltru@ietf.org; Thu, 14 Apr 2005 14:22:46 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 11:12:10 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Thu, 14 Apr 2005 11:12:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Moving Forward Date: Thu, 14 Apr 2005 11:12:10 -0700 Message-ID: Thread-Topic: [Ltru] Re: Moving Forward Thread-Index: AcVBF1B02PYGwUSzSQiQS2QrS20nBgABduqA From: "Peter Constable" To: X-OriginalArrivalTime: 14 Apr 2005 18:12:10.0808 (UTC) FILETIME=[7A168380:01C5411D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable > From: John Cowan [mailto:jcowan@reutershealth.com] > Since almost all 639-2 languages are written, and since the great > preponderance > of those are written in just one script (things like Braille and IPA > aside), > that means that, indeed, almost all languages will require the default- > script > field to be populated. >=20 > Addison's proposal involves populating only those languages customarily > written in two or more scripts. This is much easier to deal with > logistically. Logistically, you're talking about a one-time process of putting in values. It is the process of developers looking at the registry and trying to glean from it what they should do that will be repeated many many times and is where errors may occur. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 14:39:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10646; Thu, 14 Apr 2005 14:39:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9Ps-0003wB-8Y; Thu, 14 Apr 2005 14:50:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9AQ-0002sn-Cx; Thu, 14 Apr 2005 14:34:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9AO-0002od-GA for ltru@megatron.ietf.org; Thu, 14 Apr 2005 14:34:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09891 for ; Thu, 14 Apr 2005 14:34:15 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9KP-0003gf-Pz for ltru@ietf.org; Thu, 14 Apr 2005 14:44:39 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3EIY33P007416; Thu, 14 Apr 2005 14:34:04 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 14 Apr 2005 14:34:08 -0400 Date: Thu, 14 Apr 2005 14:34:08 -0400 From: John Cowan To: Mark Davis Subject: Re: [Ltru] Re: Moving Forward Message-ID: <20050414183408.GF9432@skunk.reutershealth.com> References: <009101c5410a$8e4aeac0$4b763009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009101c5410a$8e4aeac0$4b763009@sanjose.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Mark Davis scripsit: > A. We know the language is customarily used with more than one script > B. We know the language is customarily used with one script > C. The information for A or B is not available in the registry: either just > not entered yet, or hard to find out. You omit: D. The language is not customarily used with any script. (Any language may be transcribed in writing, as any language may be spoken over the radio; but just the same, Chinese is written and Burushaski is not, as Navajo is regularly broadcast and Akkadian is not.) This does not apply to current 639-2 languages but will apply to 639-3 languages. > As I said before, I have not yet seen an implementation scenario where we > need the infomation in B, and both the strategies that use it require > entering in much more data than the ZZ scenario. So I'd like to see a > scenario that drives B clearly stated. >From what I can understand, which is by no means sure, the advocates for B information want it so that they can vet tags like en-Latn(-GB) and warn against or reject them. Without B information we cannot distinguish between en-Brai (anomalous, so correct) and en-Latn (undesirable). > 2. As Peter says, we mustn't say MUST NOT, however: there are scenarios in > which it may be appropriate to use en-Latn or ko-Latn. I believe the desire of this part of the WG is to reject en-Latn absolutely (because it is the default) while still retaining the possibility of ko-Latn. -- All Gaul is divided into three parts: the part John Cowan that cooks with lard and goose fat, the part www.ccil.org/~cowan that cooks with olive oil, and the part that www.reutershealth.com cooks with butter. -- David Chessler jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 15:07:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12939; Thu, 14 Apr 2005 15:07:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9qP-000525-8L; Thu, 14 Apr 2005 15:17:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9eu-0001q9-Lh; Thu, 14 Apr 2005 15:05:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9et-0001h5-0F; Thu, 14 Apr 2005 15:05:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12721; Thu, 14 Apr 2005 15:05:41 -0400 (EDT) Received: from pop-a065d10.pas.sa.earthlink.net ([207.217.121.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9or-00050Z-Bs; Thu, 14 Apr 2005 15:16:06 -0400 Received: from h-68-165-2-188.snvacaid.dynamic.covad.net ([68.165.2.188] helo=oemcomputer) by pop-a065d10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DM9ee-0006CZ-00; Thu, 14 Apr 2005 12:05:32 -0700 Message-ID: <000c01c54125$2342c160$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" , , "Disman" Date: Thu, 14 Apr 2005 12:06:57 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Ltru] Fw: Outages on IETF servers in the near future X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Hi - Forwarded for your information. Randy > From: > To: > Cc: ; > Sent: Thursday, April 14, 2005 11:35 AM > Subject: Outages on IETF servers in the near future > > > Hi All, > > I want to let you know about some scheduled maintenance activities > that may cause network and mail outages on ietf.org sites. The > activities, which are described below, have been scheduled for the > next four Saturday mornings, from 08:00 or 09:00 until 12:00 ET. > Please check the IETF System Status Page (http://noc.ietf.org/) > periodically for updates on the status of these activities. If you > have any questions, then please feel free to send them my way. > > sb. Scott Blomquist ietf-admin@techsquare.com > ----- > * Sat 4/16 - 08:00 EST - 12:00 EST > Task: reorganizing mailing list archives > Affected: The mailing lists will be down for a good portion of the morning > Comment: I am going to try and get this down in less than 2 hours > but I am giving myself a little extra time just in case > > * Sat 4/23 - 09:00 EST - 12:00 EST > Task: reorganizing CNRI network infrastructure part 1 > Affected: there should be no services affected > Comment: just in case there are some minor network outages this is > what is going on at CNRI > > * Sat 4/30 - 09:00 EST - 12:00 EST > Task: Reorganizing CNRI network infrastructure part 2 > Affected: There maybe some minor (up to 1/2hour) network outages on > ietf systems. > Comment: None > > * Sat 5/7 - 09:00 EST - 12:00 EST > Task: reorganizing CNRI network infrastructure part 3 > Affected: there should be no services affected > Comment: just in case there are some minor network outages this is > what is going on at CNRI > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 15:08:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13159; Thu, 14 Apr 2005 15:08:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9rm-00057g-Lw; Thu, 14 Apr 2005 15:19:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9hV-0002bE-Ez; Thu, 14 Apr 2005 15:08:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9hT-0002TT-N6 for ltru@megatron.ietf.org; Thu, 14 Apr 2005 15:08:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13062 for ; Thu, 14 Apr 2005 15:07:49 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9qv-00052f-7q for ltru@ietf.org; Thu, 14 Apr 2005 15:18:14 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 12:07:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed Text for Moving Forward Date: Thu, 14 Apr 2005 12:07:39 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08D5AC@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVBIQN8y2rdFgDvTkCatDriFts91gAAnW3w From: "Addison Phillips" To: "John Cowan" , "Mark Davis" X-OriginalArrivalTime: 14 Apr 2005 19:07:39.0794 (UTC) FILETIME=[3A517720:01C54125] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable Below is a proposed version of the section "Choice of Language Tag". In = writing this text, I began a heavy reorganization of the document's = sections. Too many forward references were being created, so I have = followed our previous discussion and: 1. Made the IANA Considerations section a very small separate section. 2. Made what was titled "IANA Considerations" into "Registry Format and = Maintenance" 3. Made a new section "Formation and Processing of Language Tags" = following the format and maintenance section. This contains "Choice", = "Meaning", "Canonicalization", and "Considerations of Private Use" = sections. I have not yet revised the registry handling text to reflect the = additional fields and so forth, so please don't look there. For this = discussion I have focused on the "Choice of Language Tag" section. The new versions are posted on: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.html http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.txt Here is the salient text from the "Choice" section: --- Many applications can benefit from the use of script subtags in language = tags, as long as the use is consistent for a given context. Script = subtags were not formally defined in RFC 3066 and their use may impact = matching and subtag identification by implementations of RFC 3066 and = its predecessor RFC 1766, as these subtags appear between the primary = language and region subtags. For example, if a user requests content in = an implementation of Section 2.5 of RFC 3066 [22] using the language = range "en-US", content labeled "en-Latn-US" will not match the request. = Therefore it is important to know when script subtags will customarily = be used and when they should not be used. The language subtag registry defines two informational fields to guide = users in the choice of whether to use script subtags for a specific = application. These fields SHOULD be used as follows: If the primary language subtag has an Expected_Script_Subtag field, = then the use of a script subtag is strongly RECOMMENDED for all = applications. This field is used in records for primary language subtags = that are customarily or frequently written in more than one script and = which may be ambiguous without script information. If the primary language subtag has a Default_Script field, then that = script subtag SHOULD NOT be used to form the language tag unless it = conveys additional information necessary to the specific application. = For example, the subtag 'Latn' should not be used with the primary = language 'en' because most English documents are written in the Latin = script and it adds no distinguishing information. However, if a document = were written in English mixing Latin script with another script such as = Braille ('Brai'), then the content author may choose to indicate both = scripts to aid in content selection, such as the application of a = stylesheet. If the primary language subtag has neither an Expected_Script_Subtag = field nor a Default_Script field, then the script subtag SHOULD NOT be = used to form the language tag unless it conveys additional information = necessary to the specific application. Most languages that have neither = field are either not customarily written or are written, but the script = is not known in the registry. Speakers of these languages are encouraged = to register the appropriate information in the registry. Extended language subtags (type 'extlang' in the registry, see Section = 3.1) also appear between the primary language and region subtags andare = reserved for future standardization. Applications may benefit from their = judicious use in forming language tags in the future and similar = recommendations are expected to apply to their use as apply to script = subtags. --- Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of John Cowan > Sent: jeudi 14 avril 2005 11:34 > To: Mark Davis > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Moving Forward >=20 > Mark Davis scripsit: >=20 > > A. We know the language is customarily used with more than one = script > > B. We know the language is customarily used with one script > > C. The information for A or B is not available in the registry: = either > just > > not entered yet, or hard to find out. >=20 > You omit: >=20 > D. The language is not customarily used with any script. (Any = language > may > be transcribed in writing, as any language may be spoken over the = radio; > but just the same, Chinese is written and Burushaski is not, as = Navajo > is > regularly broadcast and Akkadian is not.) This does not apply to > current > 639-2 languages but will apply to 639-3 languages. >=20 > > As I said before, I have not yet seen an implementation scenario = where > we > > need the infomation in B, and both the strategies that use it = require > > entering in much more data than the ZZ scenario. So I'd like to see = a > > scenario that drives B clearly stated. >=20 > >From what I can understand, which is by no means sure, the advocates > for B information want it so that they can vet tags like en-Latn(-GB) > and warn against or reject them. Without B information we cannot > distinguish between en-Brai (anomalous, so correct) and en-Latn > (undesirable). >=20 > > 2. As Peter says, we mustn't say MUST NOT, however: there are = scenarios > in > > which it may be appropriate to use en-Latn or ko-Latn. >=20 > I believe the desire of this part of the WG is to reject en-Latn > absolutely (because it is the default) while still retaining the > possibility of ko-Latn. >=20 > -- > All Gaul is divided into three parts: the part John Cowan > that cooks with lard and goose fat, the part > www.ccil.org/~cowan > that cooks with olive oil, and the part that > www.reutershealth.com > cooks with butter. -- David Chessler > jcowan@reutershealth.com >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 15:27:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15123; Thu, 14 Apr 2005 15:27:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMAA8-0005qb-AV; Thu, 14 Apr 2005 15:38:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9x9-00051F-0q; Thu, 14 Apr 2005 15:24:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9x7-00050q-IU for ltru@megatron.ietf.org; Thu, 14 Apr 2005 15:24:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14869 for ; Thu, 14 Apr 2005 15:24:27 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMA72-0005jR-DN for ltru@ietf.org; Thu, 14 Apr 2005 15:34:52 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 12:24:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed Text for Moving Forward Date: Thu, 14 Apr 2005 12:24:15 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08D5C2@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVBIQN8y2rdFgDvTkCatDriFts91gAAnW3wAAD2ZLA= From: "Addison Phillips" To: "Addison Phillips" , "John Cowan" , "Mark Davis" X-OriginalArrivalTime: 14 Apr 2005 19:24:16.0386 (UTC) FILETIME=[8C555620:01C54127] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: quoted-printable FWIW, I would prefer a design closer to what I originally proposed (with = only one field type), but I documented what appears to be currently = nearer consensus. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Addison Phillips > Sent: jeudi 14 avril 2005 12:08 > To: John Cowan; Mark Davis > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward >=20 > Below is a proposed version of the section "Choice of Language Tag". = In > writing this text, I began a heavy reorganization of the document's > sections. Too many forward references were being created, so I have > followed our previous discussion and: >=20 > 1. Made the IANA Considerations section a very small separate section. > 2. Made what was titled "IANA Considerations" into "Registry Format = and > Maintenance" > 3. Made a new section "Formation and Processing of Language Tags" > following the format and maintenance section. This contains "Choice", > "Meaning", "Canonicalization", and "Considerations of Private Use" > sections. >=20 > I have not yet revised the registry handling text to reflect the > additional fields and so forth, so please don't look there. For this > discussion I have focused on the "Choice of Language Tag" section. >=20 > The new versions are posted on: >=20 > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.html > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.txt >=20 > Here is the salient text from the "Choice" section: >=20 > --- > Many applications can benefit from the use of script subtags in = language > tags, as long as the use is consistent for a given context. Script = subtags > were not formally defined in RFC 3066 and their use may impact = matching > and subtag identification by implementations of RFC 3066 and its > predecessor RFC 1766, as these subtags appear between the primary = language > and region subtags. For example, if a user requests content in an > implementation of Section 2.5 of RFC 3066 [22] using the language = range > "en-US", content labeled "en-Latn-US" will not match the request. > Therefore it is important to know when script subtags will customarily = be > used and when they should not be used. >=20 > The language subtag registry defines two informational fields to guide > users in the choice of whether to use script subtags for a specific > application. These fields SHOULD be used as follows: >=20 > If the primary language subtag has an Expected_Script_Subtag = field, > then the use of a script subtag is strongly RECOMMENDED for all > applications. This field is used in records for primary language = subtags > that are customarily or frequently written in more than one script and > which may be ambiguous without script information. >=20 > If the primary language subtag has a Default_Script field, then = that > script subtag SHOULD NOT be used to form the language tag unless it > conveys additional information necessary to the specific application. = For > example, the subtag 'Latn' should not be used with the primary = language > 'en' because most English documents are written in the Latin script = and it > adds no distinguishing information. However, if a document were = written in > English mixing Latin script with another script such as Braille = ('Brai'), > then the content author may choose to indicate both scripts to aid in > content selection, such as the application of a stylesheet. >=20 > If the primary language subtag has neither an = Expected_Script_Subtag > field nor a Default_Script field, then the script subtag SHOULD NOT be > used to form the language tag unless it conveys additional information > necessary to the specific application. Most languages that have = neither > field are either not customarily written or are written, but the = script is > not known in the registry. Speakers of these languages are encouraged = to > register the appropriate information in the registry. >=20 > Extended language subtags (type 'extlang' in the registry, see Section = 3.1) > also appear between the primary language and region subtags andare > reserved for future standardization. Applications may benefit from = their > judicious use in forming language tags in the future and similar > recommendations are expected to apply to their use as apply to script > subtags. >=20 > --- >=20 >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of John Cowan > > Sent: jeudi 14 avril 2005 11:34 > > To: Mark Davis > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Re: Moving Forward > > > > Mark Davis scripsit: > > > > > A. We know the language is customarily used with more than one = script > > > B. We know the language is customarily used with one script > > > C. The information for A or B is not available in the registry: = either > > just > > > not entered yet, or hard to find out. > > > > You omit: > > > > D. The language is not customarily used with any script. (Any > language > > may > > be transcribed in writing, as any language may be spoken over the > radio; > > but just the same, Chinese is written and Burushaski is not, as = Navajo > > is > > regularly broadcast and Akkadian is not.) This does not apply to > > current > > 639-2 languages but will apply to 639-3 languages. > > > > > As I said before, I have not yet seen an implementation scenario = where > > we > > > need the infomation in B, and both the strategies that use it = require > > > entering in much more data than the ZZ scenario. So I'd like to = see a > > > scenario that drives B clearly stated. > > > > >From what I can understand, which is by no means sure, the = advocates > > for B information want it so that they can vet tags like = en-Latn(-GB) > > and warn against or reject them. Without B information we cannot > > distinguish between en-Brai (anomalous, so correct) and en-Latn > > (undesirable). > > > > > 2. As Peter says, we mustn't say MUST NOT, however: there are > scenarios > > in > > > which it may be appropriate to use en-Latn or ko-Latn. > > > > I believe the desire of this part of the WG is to reject en-Latn > > absolutely (because it is the default) while still retaining the > > possibility of ko-Latn. > > > > -- > > All Gaul is divided into three parts: the part John Cowan > > that cooks with lard and goose fat, the part > > www.ccil.org/~cowan > > that cooks with olive oil, and the part that > > www.reutershealth.com > > cooks with butter. -- David Chessler > > jcowan@reutershealth.com > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 15:33:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15475; Thu, 14 Apr 2005 15:33:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMAFN-00063t-0I; Thu, 14 Apr 2005 15:43:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9yf-0005Ai-5k; Thu, 14 Apr 2005 15:26:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM9ye-00058K-Ig for ltru@megatron.ietf.org; Thu, 14 Apr 2005 15:26:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15019 for ; Thu, 14 Apr 2005 15:26:02 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMA8Y-0005lT-Lt for ltru@ietf.org; Thu, 14 Apr 2005 15:36:28 -0400 Received: from eupig1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 14 Apr 2005 19:25:51 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IEY00IEVBB20Q@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 14 Apr 2005 19:25:50 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Thu, 14 Apr 2005 19:25:50 +0000 Date: Thu, 14 Apr 2005 20:25:50 +0100 From: Misha Wolf Subject: RE: [Ltru] Proposed Text for Moving Forward To: ltru MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Proposed Text for Moving Forward Thread-Index: AcVBIQN8y2rdFgDvTkCatDriFts91gAAnW3wAADkcpA= content-class: urn:content-classes:message X-OriginalArrivalTime: 14 Apr 2005 19:25:50.0830 (UTC) FILETIME=[C4A058E0:01C54127] X-Spam-Score: 0.8 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Some questions: 1. Is an Expected_Script_Subtag field and a Default_Script field mutually exclusive? 2. Why does Expected_Script_Subtag contain "_Subtag" but Default_Script not do so? Can we rename the former to Expected_Script? 3. Does an Expected_Script[_Subtag] field always contain at least two Scripts? 4. If so, can we rename it to Expected_Scripts? Note the plural form. Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 15:57:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17543; Thu, 14 Apr 2005 15:57:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMAdC-00078W-3K; Thu, 14 Apr 2005 16:08:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMAJi-0007wt-7Q; Thu, 14 Apr 2005 15:47:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMAJh-0007wH-4r for ltru@megatron.ietf.org; Thu, 14 Apr 2005 15:47:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16636 for ; Thu, 14 Apr 2005 15:47:46 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMATX-0006af-GX for ltru@ietf.org; Thu, 14 Apr 2005 15:58:12 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3EJlO4I496758 for ; Thu, 14 Apr 2005 15:47:25 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay01.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3EJlO9r263154 for ; Thu, 14 Apr 2005 13:47:24 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3EJlOJW003020 for ; Thu, 14 Apr 2005 13:47:24 -0600 Received: from markdavis (sig-9-48-125-8.mts.ibm.com [9.48.125.8]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3EJlLos002929; Thu, 14 Apr 2005 13:47:24 -0600 Message-ID: <003401c5412a$c60efcb0$087d3009@sanjose.ibm.com> From: "Mark Davis" To: "John Cowan" References: <009101c5410a$8e4aeac0$4b763009@sanjose.ibm.com> <20050414183408.GF9432@skunk.reutershealth.com> Subject: Re: [Ltru] Re: Moving Forward Date: Thu, 14 Apr 2005 12:47:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j3EJlO4I496758 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable 1. I don't see that separating out D from C adds anything. But if you hav= e a use-case, that would be interesting. > From what I can understand, which is by no means sure, the advocates > for B information want it so that they can vet tags like en-Latn(-GB) But for that, for the NC, they don't need the information that the defaul= t script is Latn. All they need to know is that if there are two scripts in the registry, then in that situation put no script in the tag. > I believe the desire of this part of the WG is to reject en-Latn > absolutely (because it is the default) while still retaining the > possibility of ko-Latn. *Requiring* the default to be rejected is absolutely the wrong thing to d= o. Suppose that I am querying a database of phrase books for Thai. They cont= ain a mixture of those using Latin and those using Thai script. I can issue 3 queries: 1. th-Thai - give me only the ones in Thai, and written in the Thai scrip= t 2. th-Latn - give me only the ones in Thai, using a Latin transcription 3. th - give me anything. This is a perfectly sensible thing to do. But if #1 is illegal, it does n= ot let users make a perfectly useful discrimination between #1 and #3. The right thing to do is to indicate, as others have indicated, is that i= n the normal case (NC) for stuff like webpage selection, you should not use the script unless there are two scripts listed in the registry. =E2=80=8EMark ----- Original Message -----=20 From: "John Cowan" To: "Mark Davis" Cc: Sent: Thursday, April 14, 2005 11:34 Subject: Re: [Ltru] Re: Moving Forward > Mark Davis scripsit: > > > A. We know the language is customarily used with more than one script > > B. We know the language is customarily used with one script > > C. The information for A or B is not available in the registry: eithe= r just > > not entered yet, or hard to find out. > > You omit: > > D. The language is not customarily used with any script. (Any langua= ge may > be transcribed in writing, as any language may be spoken over the rad= io; > but just the same, Chinese is written and Burushaski is not, as Navaj= o is > regularly broadcast and Akkadian is not.) This does not apply to current > 639-2 languages but will apply to 639-3 languages. > > > As I said before, I have not yet seen an implementation scenario wher= e we > > need the infomation in B, and both the strategies that use it require > > entering in much more data than the ZZ scenario. So I'd like to see a > > scenario that drives B clearly stated. > > From what I can understand, which is by no means sure, the advocates > for B information want it so that they can vet tags like en-Latn(-GB) > and warn against or reject them. Without B information we cannot > distinguish between en-Brai (anomalous, so correct) and en-Latn (undesirable). > > > 2. As Peter says, we mustn't say MUST NOT, however: there are scenari= os in > > which it may be appropriate to use en-Latn or ko-Latn. > > I believe the desire of this part of the WG is to reject en-Latn > absolutely (because it is the default) while still retaining the > possibility of ko-Latn. > > --=20 > All Gaul is divided into three parts: the part John Cowan > that cooks with lard and goose fat, the part www.ccil.org/~cowan > that cooks with olive oil, and the part that www.reutershealth.com > cooks with butter. -- David Chessler jcowan@reutershealth.com > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 17:15:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29754; Thu, 14 Apr 2005 17:15:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBqu-0003fU-NG; Thu, 14 Apr 2005 17:26:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMARl-0000CU-Ps; Thu, 14 Apr 2005 15:56:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMARi-0000Bz-5l for ltru@megatron.ietf.org; Thu, 14 Apr 2005 15:56:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17402 for ; Thu, 14 Apr 2005 15:55:59 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMAbX-00072r-GQ for ltru@ietf.org; Thu, 14 Apr 2005 16:06:24 -0400 Received: from h-68-166-188-127.snvacaid.dynamic.covad.net ([68.166.188.127] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DMARN-00062s-00 for ltru@ietf.org; Thu, 14 Apr 2005 12:55:53 -0700 Message-ID: <001001c5412c$2cc67fe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08D5AC@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Date: Thu, 14 Apr 2005 12:57:22 -0700 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: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi - > From: "Addison Phillips" > To: "John Cowan" ; "Mark Davis" Cc: > Sent: Thursday, April 14, 2005 12:07 PM > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > Below is a proposed version of the section "Choice of Language Tag". > In writing this text, I began a heavy reorganization of the document's sections. > Too many forward references were being created, > so I have followed our previous discussion and: > > 1. Made the IANA Considerations section a very small separate section. > 2. Made what was titled "IANA Considerations" into "Registry Format and Maintenance" I can tell you now that this would probably run into trouble. The "IANA Considerations" section must have all the information, or at least fairly precise pointers, to everything IANA would need to know. Minimizing forward references is a good thing, and the IANA considerations section may be located anywhere within the body of the memo. (See http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt section 4.) Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 17:17:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00260; Thu, 14 Apr 2005 17:17:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBse-0003rv-TO; Thu, 14 Apr 2005 17:28:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMAfL-00024m-Ku; Thu, 14 Apr 2005 16:10:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMAfH-0001kU-H7 for ltru@megatron.ietf.org; Thu, 14 Apr 2005 16:10:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18823 for ; Thu, 14 Apr 2005 16:10:04 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMApA-0007lG-I6 for ltru@ietf.org; Thu, 14 Apr 2005 16:20:30 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3EK9s4G007892; Thu, 14 Apr 2005 16:09:54 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 14 Apr 2005 16:09:55 -0400 Date: Thu, 14 Apr 2005 16:09:55 -0400 From: John Cowan To: Mark Davis Subject: Re: [Ltru] Re: Moving Forward Message-ID: <20050414200955.GA11008@skunk.reutershealth.com> References: <009101c5410a$8e4aeac0$4b763009@sanjose.ibm.com> <20050414183408.GF9432@skunk.reutershealth.com> <003401c5412a$c60efcb0$087d3009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003401c5412a$c60efcb0$087d3009@sanjose.ibm.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Mark Davis scripsit: > > From what I can understand, which is by no means sure, the advocates > > for B information want it so that they can vet tags like en-Latn(-GB) > > But for that, for the NC, they don't need the information that the default > script is Latn. All they need to know is that if there are two scripts in > the registry, then in that situation put no script in the tag. I don't understand that sentence at all. To reiterate: If I present the tag "en-Brai-YY" to a tag validator, it should reject the tag as invalid, because region YY does not exist. If I present the tag en-Latn, it should at least warn me that using Latn with en is undesirable. If I present the tag en-Brai, it should accept it. This can only be done if it's known that the default script for en is Latn. You may not consider this use case worth supporting, but it *is* a use case. > *Requiring* the default to be rejected is absolutely the wrong thing to do. > Suppose that I am querying a database of phrase books for Thai. They contain > a mixture of those using Latin and those using Thai script. I can issue 3 > queries: > > 1. th-Thai - give me only the ones in Thai, and written in the Thai script > 2. th-Latn - give me only the ones in Thai, using a Latin transcription > 3. th - give me anything. Ah, but that's a constraint on language *ranges*, which are not semantically the same as language *tags*. Language ranges are a concept belonging to the matching draft, which may want to end up supporting things like "th-*" or "th-*-*" that aren't tags at all. We are talking here about a constraint on tags and only on tags. > This is a perfectly sensible thing to do. But if #1 is illegal, it does not > let users make a perfectly useful discrimination between #1 and #3. What would be illegal on this view (not necessarily mine, I'm just trying to be a mediator) is a document or other object being tagged th-Thai, not a request for th-Thai. > 1. I don't see that separating out D from C adds anything. But if you have a > use-case, that would be interesting. I was thinking that if you know there is no script, then you should reject any attempt to add one except in "unusual script" mode. But perhaps that is the same treatment that should be given to script-unknown languages. -- Is not a patron, my Lord [Chesterfield], John Cowan one who looks with unconcern on a man http://www.ccil.org/~cowan struggling for life in the water, and when http://www.reutershealth.com he has reached ground encumbers him with help? jcowan@reutershealth.com --Samuel Johnson _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 17:55:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04207; Thu, 14 Apr 2005 17:55:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCSr-0005lD-Ri; Thu, 14 Apr 2005 18:05:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCHM-0006ky-Pg; Thu, 14 Apr 2005 17:53:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCHF-0006gV-H4 for ltru@megatron.ietf.org; Thu, 14 Apr 2005 17:53:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04122 for ; Thu, 14 Apr 2005 17:53:22 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMCRA-0005jX-Fb for ltru@ietf.org; Thu, 14 Apr 2005 18:03:50 -0400 Received: from smtp-los03.proxy.aol.com (smtp-los03.proxy.aol.com [195.93.24.41]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN1-2425ee63e1b1; Thu, 14 Apr 2005 17:53:03 -0500 Received: from DEBHOME (ACD5F9C4.ipt.aol.com [172.213.249.196]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3ELr0o4024786; Thu, 14 Apr 2005 17:53:00 -0400 Message-Id: <200504142153.j3ELr0o4024786@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Mark Davis'" , "'John Cowan'" Subject: RE: [Ltru] Re: Moving Forward Date: Thu, 14 Apr 2005 22:53:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVBLGR55b0UfTQgTqKMM9jroHpkCQACeYYA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <003401c5412a$c60efcb0$087d3009@sanjose.ibm.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.6 (++) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.6 (++) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Mark Davis wrote: > Suppose that I am querying a database of phrase books for Thai. They > contain > a mixture of those using Latin and those using Thai script. I can = issue 3 > queries: >=20 > 1. th-Thai - give me only the ones in Thai, and written in the Thai = script > 2. th-Latn - give me only the ones in Thai, using a Latin = transcription > 3. th - give me anything. >=20 > This is a perfectly sensible thing to do. But if #1 is illegal, it = does > not > let users make a perfectly useful discrimination between #1 and #3. >=20 > The right thing to do is to indicate, as others have indicated, is = that in > the normal case (NC) for stuff like webpage selection, you should not = use > the script unless there are two scripts listed in the registry. I agree with this, it seems perfectly logical... but...=20 If the tag for Sirenik is ysr-RU how do you know what the default script = is? Have I missed something here?=20 Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Mark Davis > Sent: 14 April 2005 20:47 > To: John Cowan > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Moving Forward >=20 > 1. I don't see that separating out D from C adds anything. But if you = have > a > use-case, that would be interesting. >=20 > > From what I can understand, which is by no means sure, the advocates > > for B information want it so that they can vet tags like = en-Latn(-GB) > But for that, for the NC, they don't need the information that the = default > script is Latn. All they need to know is that if there are two scripts = in > the registry, then in that situation put no script in the tag. >=20 > > I believe the desire of this part of the WG is to reject en-Latn > > absolutely (because it is the default) while still retaining the > > possibility of ko-Latn. > *Requiring* the default to be rejected is absolutely the wrong thing = to > do. > Suppose that I am querying a database of phrase books for Thai. They > contain > a mixture of those using Latin and those using Thai script. I can = issue 3 > queries: >=20 > 1. th-Thai - give me only the ones in Thai, and written in the Thai = script > 2. th-Latn - give me only the ones in Thai, using a Latin = transcription > 3. th - give me anything. >=20 > This is a perfectly sensible thing to do. But if #1 is illegal, it = does > not > let users make a perfectly useful discrimination between #1 and #3. >=20 > The right thing to do is to indicate, as others have indicated, is = that in > the normal case (NC) for stuff like webpage selection, you should not = use > the script unless there are two scripts listed in the registry. >=20 >=20 > =FDMark >=20 > ----- Original Message ----- > From: "John Cowan" > To: "Mark Davis" > Cc: > Sent: Thursday, April 14, 2005 11:34 > Subject: Re: [Ltru] Re: Moving Forward >=20 >=20 > > Mark Davis scripsit: > > > > > A. We know the language is customarily used with more than one = script > > > B. We know the language is customarily used with one script > > > C. The information for A or B is not available in the registry: = either > just > > > not entered yet, or hard to find out. > > > > You omit: > > > > D. The language is not customarily used with any script. (Any > language > may > > be transcribed in writing, as any language may be spoken over the > radio; > > but just the same, Chinese is written and Burushaski is not, as = Navajo > is > > regularly broadcast and Akkadian is not.) This does not apply to > current > > 639-2 languages but will apply to 639-3 languages. > > > > > As I said before, I have not yet seen an implementation scenario = where > we > > > need the infomation in B, and both the strategies that use it = require > > > entering in much more data than the ZZ scenario. So I'd like to = see a > > > scenario that drives B clearly stated. > > > > From what I can understand, which is by no means sure, the advocates > > for B information want it so that they can vet tags like = en-Latn(-GB) > > and warn against or reject them. Without B information we cannot > > distinguish between en-Brai (anomalous, so correct) and en-Latn > (undesirable). > > > > > 2. As Peter says, we mustn't say MUST NOT, however: there are > scenarios > in > > > which it may be appropriate to use en-Latn or ko-Latn. > > > > I believe the desire of this part of the WG is to reject en-Latn > > absolutely (because it is the default) while still retaining the > > possibility of ko-Latn. > > > > -- > > All Gaul is divided into three parts: the part John Cowan > > that cooks with lard and goose fat, the part > www.ccil.org/~cowan > > that cooks with olive oil, and the part that > www.reutershealth.com > > cooks with butter. -- David Chessler > jcowan@reutershealth.com > > > > >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 18:38:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08603; Thu, 14 Apr 2005 18:38:13 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMD8b-0007Vw-CG; Thu, 14 Apr 2005 18:48:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCqH-0004Zz-0p; Thu, 14 Apr 2005 18:29:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCqF-0004Z4-4u for ltru@megatron.ietf.org; Thu, 14 Apr 2005 18:29:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07863 for ; Thu, 14 Apr 2005 18:29:32 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMD0B-0007AA-KH for ltru@ietf.org; Thu, 14 Apr 2005 18:40:00 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 15:29:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Moving Forward Date: Thu, 14 Apr 2005 15:29:21 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08D6D6@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Moving Forward Thread-Index: AcVBLGR55b0UfTQgTqKMM9jroHpkCQACeYYAAAJsQ6A= From: "Addison Phillips" To: "Debbie Garside" , "Mark Davis" , "John Cowan" X-OriginalArrivalTime: 14 Apr 2005 22:29:22.0372 (UTC) FILETIME=[68045040:01C54141] X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: quoted-printable You don't, but you don't need to. The rule for that language is "don't use a script subtag" (unless it = adds something valuable to the tag). Whether there is a default script = or the language just isn't customarily written or not is not important = in that context. The only place where default script *is* important is in situations in = which a range such as "ysr-RU" is being matched to content that uses a = script subtag (let's say it's "ysr-Cyrl-RU"). But extended language = ranges ("ysr-*-RU") handle that case just as well. The benefit to a = Default_Script could be that implemented in an API of course (for tag = "ysr-RU", what is the result of getScript() in my little Java program? = Now it is "", but it could be "Cyrl" I suppose).=20 Notice that the only processors (as opposed to people) that can gain any = advantage from these fields are also implementations of RFC 3066bis. RFC = 3066 processors only benefit from humans choosing to include or not = include the subtag consistently. As a result, the processors that gain = advantage from the field already know what the fields values mean (by = their length) and thus aren't benefiting all that much from the = information about script use anyway. John's example of warning users not = to use a particular subtag, though, is a good one. In fact, I would say that once you have some content in a language--even = one that is "strongly scripted", such as English or French--that uses a = script subtag, all of your content should start to use script subtags = for consistency of processing *in that context*. The script problem = we're trying to deal with usually occurs when unequal fields are being = compared ("en-US" and "en-Brai-US"). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Debbie Garside > Sent: jeudi 14 avril 2005 14:53 > To: 'Mark Davis'; 'John Cowan' > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Moving Forward >=20 > Mark Davis wrote: >=20 > > Suppose that I am querying a database of phrase books for Thai. They > > contain > > a mixture of those using Latin and those using Thai script. I can = issue > 3 > > queries: > > > > 1. th-Thai - give me only the ones in Thai, and written in the Thai > script > > 2. th-Latn - give me only the ones in Thai, using a Latin = transcription > > 3. th - give me anything. > > > > This is a perfectly sensible thing to do. But if #1 is illegal, it = does > > not > > let users make a perfectly useful discrimination between #1 and #3. > > > > The right thing to do is to indicate, as others have indicated, is = that > in > > the normal case (NC) for stuff like webpage selection, you should = not > use > > the script unless there are two scripts listed in the registry. >=20 > I agree with this, it seems perfectly logical... but... >=20 > If the tag for Sirenik is ysr-RU how do you know what the default = script > is? >=20 > Have I missed something here? >=20 > Debbie >=20 >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Mark Davis > > Sent: 14 April 2005 20:47 > > To: John Cowan > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Re: Moving Forward > > > > 1. I don't see that separating out D from C adds anything. But if = you > have > > a > > use-case, that would be interesting. > > > > > From what I can understand, which is by no means sure, the = advocates > > > for B information want it so that they can vet tags like = en-Latn(-GB) > > But for that, for the NC, they don't need the information that the > default > > script is Latn. All they need to know is that if there are two = scripts > in > > the registry, then in that situation put no script in the tag. > > > > > I believe the desire of this part of the WG is to reject en-Latn > > > absolutely (because it is the default) while still retaining the > > > possibility of ko-Latn. > > *Requiring* the default to be rejected is absolutely the wrong thing = to > > do. > > Suppose that I am querying a database of phrase books for Thai. They > > contain > > a mixture of those using Latin and those using Thai script. I can = issue > 3 > > queries: > > > > 1. th-Thai - give me only the ones in Thai, and written in the Thai > script > > 2. th-Latn - give me only the ones in Thai, using a Latin = transcription > > 3. th - give me anything. > > > > This is a perfectly sensible thing to do. But if #1 is illegal, it = does > > not > > let users make a perfectly useful discrimination between #1 and #3. > > > > The right thing to do is to indicate, as others have indicated, is = that > in > > the normal case (NC) for stuff like webpage selection, you should = not > use > > the script unless there are two scripts listed in the registry. > > > > > > =FDMark > > > > ----- Original Message ----- > > From: "John Cowan" > > To: "Mark Davis" > > Cc: > > Sent: Thursday, April 14, 2005 11:34 > > Subject: Re: [Ltru] Re: Moving Forward > > > > > > > Mark Davis scripsit: > > > > > > > A. We know the language is customarily used with more than one > script > > > > B. We know the language is customarily used with one script > > > > C. The information for A or B is not available in the registry: > either > > just > > > > not entered yet, or hard to find out. > > > > > > You omit: > > > > > > D. The language is not customarily used with any script. (Any > > language > > may > > > be transcribed in writing, as any language may be spoken over = the > > radio; > > > but just the same, Chinese is written and Burushaski is not, as > Navajo > > is > > > regularly broadcast and Akkadian is not.) This does not apply = to > > current > > > 639-2 languages but will apply to 639-3 languages. > > > > > > > As I said before, I have not yet seen an implementation scenario > where > > we > > > > need the infomation in B, and both the strategies that use it > require > > > > entering in much more data than the ZZ scenario. So I'd like to = see > a > > > > scenario that drives B clearly stated. > > > > > > From what I can understand, which is by no means sure, the = advocates > > > for B information want it so that they can vet tags like = en-Latn(-GB) > > > and warn against or reject them. Without B information we cannot > > > distinguish between en-Brai (anomalous, so correct) and en-Latn > > (undesirable). > > > > > > > 2. As Peter says, we mustn't say MUST NOT, however: there are > > scenarios > > in > > > > which it may be appropriate to use en-Latn or ko-Latn. > > > > > > I believe the desire of this part of the WG is to reject en-Latn > > > absolutely (because it is the default) while still retaining the > > > possibility of ko-Latn. > > > > > > -- > > > All Gaul is divided into three parts: the part John Cowan > > > that cooks with lard and goose fat, the part > > www.ccil.org/~cowan > > > that cooks with olive oil, and the part that > > www.reutershealth.com > > > cooks with butter. -- David Chessler > > jcowan@reutershealth.com > > > > > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 18:47:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09098; Thu, 14 Apr 2005 18:47:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMDHu-0007rp-Dt; Thu, 14 Apr 2005 18:58:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCry-0004ky-0t; Thu, 14 Apr 2005 18:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMCrw-0004kf-Fq for ltru@megatron.ietf.org; Thu, 14 Apr 2005 18:31:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08096 for ; Thu, 14 Apr 2005 18:31:17 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMD1s-0007DB-9J for ltru@ietf.org; Thu, 14 Apr 2005 18:41:45 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 15:31:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed Text for Moving Forward Date: Thu, 14 Apr 2005 15:31:09 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08D6D9@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVBNvgdvVRfFe9dRxqx4FSBq3pJ3wAABSLg From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 14 Apr 2005 22:31:09.0970 (UTC) FILETIME=[A8267720:01C54141] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable The problem is that the IANA considerations section contained a lot of = materials that really were not of interest to IANA. It contained: 3.1 Format of the IANA Language Subtag Registry 3.2 Maintenance of the Registry 3.3 Stability of IANA Registry Entries 3.4 Registration Procedure for Subtags 3.5 Extensions and Extensions Namespace 3.6 Conversion of the RFC 3066 Language Tag Registry The new section can contain instructions to IANA explicitly. It doesn't = currently because we are in-flight and I haven't identified and moved = (or written) the text at present. I've posted a bit more of that work, = just so that it isn't unclear. Addison=20 Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: jeudi 14 avril 2005 12:57 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: Proposed Text for Moving Forward >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "John Cowan" ; "Mark Davis" > > Cc: > > Sent: Thursday, April 14, 2005 12:07 PM > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > >=20 > > Below is a proposed version of the section "Choice of Language Tag". > > In writing this text, I began a heavy reorganization of the = document's > sections. > > Too many forward references were being created, > > so I have followed our previous discussion and: > > > > 1. Made the IANA Considerations section a very small separate = section. > > 2. Made what was titled "IANA Considerations" into "Registry Format = and > Maintenance" >=20 > I can tell you now that this would probably run into trouble. The = "IANA > Considerations" > section must have all the information, or at least fairly precise = pointers, > to everything > IANA would need to know. Minimizing forward references is a good = thing, > and the IANA > considerations section may be located anywhere within the body of the = memo. > (See > http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt > section 4.) >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 19:20:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10974; Thu, 14 Apr 2005 19:20:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMDnl-0000gV-A7; Thu, 14 Apr 2005 19:31:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMDYz-0000WU-Dt; Thu, 14 Apr 2005 19:15:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMDYx-0000Vu-UU for ltru@megatron.ietf.org; Thu, 14 Apr 2005 19:15:56 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10536 for ; Thu, 14 Apr 2005 19:15:44 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DMDVP-0005Ee-IC for ltru@lists.ietf.org; Fri, 15 Apr 2005 01:12:15 +0200 Received: from 212.82.251.115 ([212.82.251.115]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Apr 2005 01:12:15 +0200 Received: from nobody by 212.82.251.115 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Apr 2005 01:12:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 15 Apr 2005 01:15:12 +0200 Organization: Lines: 21 Message-ID: <425EF980.69DE@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.115 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed Text for Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Misha Wolf wrote: > 1. Is an Expected_Script_Subtag field and a Default_Script > field mutually exclusive? No, the latter can be identified as "only one expected script" The rules are of course very different, SHOULD vs, SHOULD NOT. > 3. Does an Expected_Script[_Subtag] field always contain at > least two Scripts? Not if you combine them as in (1), Probably that was your real question, can they be used together for the same language. That's also possible, but then the "default" script cannot be "expected", otherwise you'd get a NOT RECOMMENDED SHOULD for this script. In this version the number of expected sripts can be also one, e.g. language got, default Latn, expected Goth. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 19:59:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13098; Thu, 14 Apr 2005 19:59:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMEP6-00026W-I9; Thu, 14 Apr 2005 20:09:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DME52-0003Vs-8j; Thu, 14 Apr 2005 19:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DME4x-0003UU-K2 for ltru@megatron.ietf.org; Thu, 14 Apr 2005 19:49:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12470 for ; Thu, 14 Apr 2005 19:48:50 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMEEu-0001eY-W5 for ltru@ietf.org; Thu, 14 Apr 2005 19:59:17 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 16:48:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed Text for Moving Forward Date: Thu, 14 Apr 2005 16:48:36 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08D712@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVBSQzlRcG+Eg1iQyavb4w8qOjS8QAAC1vQ From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 14 Apr 2005 23:48:37.0355 (UTC) FILETIME=[7A3523B0:01C5414C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Hmm... So I didn't write prototype text for that yet. Mentally I had thought = (and the text proposed implies rather strongly) that Expected_Script is = a 2*[subtag] field. And that it is mutually exclusive with default. The alternative I had thought of was letting Expected Script do both = jobs, as in: 0*1[script] =3D=3D SHOULD NOT use 2*[script] =3D=3D SHOULD use Let's consider for a moment a hypothetical case. Let's say language = 'xyz' is listed initially with no script information. A user asks to = register 'Cyrl' as the default script, produces information in language = "xyz-Cyrl" to prove the point, and the result is registered. Later another user complains that the language is also written in = 'Latn'.=20 1. Does the default script get removed and two expected scripts created? 2. Does the default script remain and a new expected script get created? 3. Does the default script remain and two expected scripts get created? Clearly the case for registering a default script should be pretty = darned convincing given the mess removing one makes. Perhaps we should = allow zero or more expected scripts and write the rules based on that. Perhaps the rules should be: 1. If the primary language has no associated script, you SHOULD NOT use = a script subtag unless it adds distinguishing information for that = context. 2. If the primary language has a single associated script and the = content uses that script, you SHOULD NOT use the script subtag (unless = etc.). 3. If the primary language has two or more associated scripts and the = content uses one of them, you SHOULD use the script subtag (unless it is = harmful to do so). 4. If the primary language has any number of associated scripts, but the = content uses a different script, you SHOULD use the script subtag = (unless it is harmful to do so). Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: jeudi 14 avril 2005 16:15 > To: ltru@ietf.org > Subject: [Ltru] Re: Proposed Text for Moving Forward >=20 > Misha Wolf wrote: >=20 > > 1. Is an Expected_Script_Subtag field and a Default_Script > > field mutually exclusive? >=20 > No, the latter can be identified as "only one expected script" > The rules are of course very different, SHOULD vs, SHOULD NOT. >=20 > > 3. Does an Expected_Script[_Subtag] field always contain at > > least two Scripts? >=20 > Not if you combine them as in (1), Probably that was your > real question, can they be used together for the same language. >=20 > That's also possible, but then the "default" script cannot be > "expected", otherwise you'd get a NOT RECOMMENDED SHOULD for > this script. >=20 > In this version the number of expected sripts can be also one, > e.g. language got, default Latn, expected Goth. Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 20:29:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15237; Thu, 14 Apr 2005 20:29:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMEsA-0003Fp-GW; Thu, 14 Apr 2005 20:39:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMEgB-0000CU-6Q; Thu, 14 Apr 2005 20:27:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMEg6-0000Bc-Pf for ltru@megatron.ietf.org; Thu, 14 Apr 2005 20:27:23 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15137 for ; Thu, 14 Apr 2005 20:27:12 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DMEcJ-0003l8-So for ltru@lists.ietf.org; Fri, 15 Apr 2005 02:23:27 +0200 Received: from 212.82.251.115 ([212.82.251.115]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Apr 2005 02:23:27 +0200 Received: from nobody by 212.82.251.115 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Apr 2005 02:23:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 15 Apr 2005 02:22:41 +0200 Organization: Lines: 52 Message-ID: <425F0951.4ABD@xyzzy.claranet.de> References: <20050413142051.UDNA2128.mta1.adelphia.net@megatron.ietf.org> <003101c5403d$1e0bce00$030aa8c0@DEWELL> <6.1.2.0.2.20050414004401.02df77d0@mail.jefsey.com> <425DCEF5.74E4@xyzzy.claranet.de> <6.1.2.0.2.20050414114602.043f93a0@mail.jefsey.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.115 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > we obviously are not here for the fun. I'm here because I didn't like the "country code" rules and effects in draft 9 and said so in the "last call". If I don't like it but have an idea how to fix it, now is my chance. Anything else are simply side-effects of this POV, trivial ABNF quirks, normative vs. informative references, STRONGLY, etc. > But for the technical, political, economical and societal > implications every IETF standard and procedure has. The registry will be essentially a frozen summary of four ISO standards (3166-1, 639-1/2, scripts), some grandfathered tags, and some UN numbers where ISO 3166-1 doesn't work as expected. Plus some simple rules to use these subtags in a combined tag. Any additional info in the source standards isn't lost only because it's not copied to the language tag registry. You're still free to use the sources as they are, e.g. Bruce's draft about scripts uses the ISO source. And you're free to use whatever source you like to find the French name for Faroe. The registry is about language tags, it's no all purpose dictionary. Descriptions ought to be the minimal "i-default" text we can get away with, but no headache for a poor tag reviewer. If you love headaches, the "default_script" is bad enough, but unfortunately necessary to address some compatibility issues. Losing regions under the current rules is also bad, I hope to discuss this here again _after_ the default script problem was solved in draft -01. But for the French name of Faroe I really don't care. It's no _technical_ problem for users, implementors, or taggers. From your POV it might be important, but solving it for you is no option, French is only one of many languages, and obviously we can't put descriptions in many languages in the LTRU registry. If you want a dictionary of language / script / region names just create it. IMHO it's unnecessary, dictionaries already exist. Here are two utter dubious Google translations: http://purl.net/net/en2fr/users.adelphia.net/~dewell/lstreg.html http://purl.net/net/en2de/users.adelphia.net/~dewell/lstreg.html Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 21:56:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20870; Thu, 14 Apr 2005 21:56:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMGEZ-0006Na-CT; Thu, 14 Apr 2005 22:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMG3R-0004qd-W6; Thu, 14 Apr 2005 21:55:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMG3P-0004nO-PG for ltru@megatron.ietf.org; Thu, 14 Apr 2005 21:55:32 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20825 for ; Thu, 14 Apr 2005 21:55:28 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DMFzg-0004AC-3g for ltru@lists.ietf.org; Fri, 15 Apr 2005 03:51:40 +0200 Received: from 212.82.251.115 ([212.82.251.115]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Apr 2005 03:51:40 +0200 Received: from nobody by 212.82.251.115 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Apr 2005 03:51:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 15 Apr 2005 03:51:03 +0200 Organization: Lines: 84 Message-ID: <425F1E07.2575@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B08D712@irvmbxw01.quest.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.115 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Subject: [Ltru] Re: Proposed Text for Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Addison Phillips wrote: > 0*1[script] == SHOULD NOT use > 2*[script] == SHOULD use That's the KISS variant, therefore I like it. Misha apparently wanted a more complex solution allowing to mix a default script with _additional_ expected scripts. I don't see where Misha's feature is necessary for 3066 compatibility, but it's possible. > a hypothetical case. Let's say language 'xyz' is listed > initially with no script information. That could be a spoken language without script, a case of two or more undetermined expected scripts, or a very dubious entry. > A user asks to register 'Cyrl' as the default script, > produces information in language "xyz-Cyrl" to prove the > point, and the result is registered. Better, now it has a script, xyz is processed as xyz-Cyrl. > Later another user complains that the language is also > written in 'Latn'. Bad, the first user and the tag review got it wrong. In the KISS-variant Latn would be simply added => no more default, all content tagged as "xyz implicitly xyz-Cyrl" should be updated. As soon as there's no more default script 3066-compatibility is impossible. It's one of the two points of RfC 3066bis that in this case the script should be used / added, a.s.a.p. Here a bit later than a.s.a.p. because the first user got it wrong, but the final effect for 3066-compatibility is the same, it's not possible for this language. [Misha's variant] > 1. Does the default script get removed and two expected scripts created? One solution, same effect as in the KISS-scenario. > 2. Does the default script remain and a new expected script get created? Possible, Misha's variant allows this. The hard question is which of the two scripts should be the default. And what's the purpose of the other script, for info, a hint for taggers, plausibility tests ? > 3. Does the default script remain and two expected scripts get created? That's not okay, it results in a NOT RECOMMENDED SHOULD. You could assign the same meaning for this case, but if it's the same as in (2) you better forbid (3). > 1. If the primary language has no associated script, you > SHOULD NOT use a script subtag unless it adds > distinguishing information for that context. What's that, a spoken language, pictures of hieroglyphs or knots, a WAV with Canarian whistles, Zxxx, Zyyy, or Zzzz ? Your points 2..4 are what I called the KISS-variant. > 3. If the primary language has two or more associated > scripts and the content uses one of them, you SHOULD use > the script subtag (unless it is harmful to do so). When would it be harmful ? It just doesn't work with RfC 3066 implementations or content. It's more like "unless it's useful to get any content, especially pre-3066bis content". > 4. If the primary language has any number of associated > scripts, but the content uses a different script, you > SHOULD use the script subtag (unless it is harmful to do > so). Same as 3, here it's only something like Brai, not Latn/Cyrl or Hans/Hant. RfC 3066bis is simply not fully compatible with RfC 3066, the awful "default script" kludge can only fix this for your case 2, but not for your cases 3 and 4. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 22:31:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22873; Thu, 14 Apr 2005 22:31:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMGm1-0007Uw-Oh; Thu, 14 Apr 2005 22:41:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMGbs-0003Fd-T3; Thu, 14 Apr 2005 22:31:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMGbr-0003Bq-Ub for ltru@megatron.ietf.org; Thu, 14 Apr 2005 22:31:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22837 for ; Thu, 14 Apr 2005 22:30:51 -0400 (EDT) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMGli-0007UO-4I for ltru@ietf.org; Thu, 14 Apr 2005 22:41:21 -0400 Received: from h-68-165-3-58.snvacaid.dynamic.covad.net ([68.165.3.58] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DMGbZ-0007Ph-00 for ltru@ietf.org; Thu, 14 Apr 2005 19:30:49 -0700 Message-ID: <001401c54163$58ecaa40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08D712@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Date: Thu, 14 Apr 2005 19:32:18 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Hi - > From: "Addison Phillips" > To: "Frank Ellermann" ; > Sent: Thursday, April 14, 2005 4:48 PM > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward ... > Perhaps the rules should be: > > 1. If the primary language has no associated script, > you SHOULD NOT use a script subtag > unless it adds distinguishing information for that context. > > 2. If the primary language has a single associated script > and the content uses that script, > you SHOULD NOT use the script subtag (unless etc.). > > 3. If the primary language has two or more associated scripts > and the content uses one of them, > you SHOULD use the script subtag (unless it is harmful to do so). > > 4. If the primary language has any number of associated scripts, > but the content uses a different script, > you SHOULD use the script subtag (unless it is harmful to do so). To get the desired results for Gothic, (no subtag for Gothic transcribed into latin alphabet, subtag required if using the historical Gothic alphabet) I think this would mean that the entry for Gothic could not identify Gothic as an associated script, and that the associated script (if any) would be latin. I guess this works, but I'd classify it as "obvious only if previously understood." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Thu Apr 14 23:58:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28717; Thu, 14 Apr 2005 23:58:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMI8G-0002AY-UH; Fri, 15 Apr 2005 00:08:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMHvr-0002AR-Ql; Thu, 14 Apr 2005 23:55:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMHvp-000279-An for ltru@megatron.ietf.org; Thu, 14 Apr 2005 23:55:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28616 for ; Thu, 14 Apr 2005 23:55:46 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMI5w-00025F-An for ltru@ietf.org; Fri, 15 Apr 2005 00:06:16 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3F3tcLg110448 for ; Thu, 14 Apr 2005 23:55:38 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3F3tcqi250988 for ; Thu, 14 Apr 2005 21:55:38 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3F3tcC8018895 for ; Thu, 14 Apr 2005 21:55:38 -0600 Received: from markdavis (sig-9-48-119-91.mts.ibm.com [9.48.119.91]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3F3tZ8I018869; Thu, 14 Apr 2005 21:55:37 -0600 Message-ID: <019501c5416e$fafa41c0$087d3009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "Randy Presuhn" , References: <634978A7DF025A40BFEF33EB191E13BC0B08D6D9@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Date: Thu, 14 Apr 2005 20:55:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j3F3tcLg110448 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable BTW, just for background information, I generated a more readable form of the CLDR language info (draft for the next release), at http://unicode.org/cldr/data/dropbox/language_info.txt =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "Randy Presuhn" ; Sent: Thursday, April 14, 2005 15:31 Subject: RE: [Ltru] Re: Proposed Text for Moving Forward The problem is that the IANA considerations section contained a lot of materials that really were not of interest to IANA. It contained: 3.1 Format of the IANA Language Subtag Registry 3.2 Maintenance of the Registry 3.3 Stability of IANA Registry Entries 3.4 Registration Procedure for Subtags 3.5 Extensions and Extensions Namespace 3.6 Conversion of the RFC 3066 Language Tag Registry The new section can contain instructions to IANA explicitly. It doesn't currently because we are in-flight and I haven't identified and moved (or written) the text at present. I've posted a bit more of that work, just s= o that it isn't unclear. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: jeudi 14 avril 2005 12:57 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: Proposed Text for Moving Forward > > Hi - > > > From: "Addison Phillips" > > To: "John Cowan" ; "Mark Davis" > > Cc: > > Sent: Thursday, April 14, 2005 12:07 PM > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > > > Below is a proposed version of the section "Choice of Language Tag". > > In writing this text, I began a heavy reorganization of the document'= s > sections. > > Too many forward references were being created, > > so I have followed our previous discussion and: > > > > 1. Made the IANA Considerations section a very small separate section. > > 2. Made what was titled "IANA Considerations" into "Registry Format a= nd > Maintenance" > > I can tell you now that this would probably run into trouble. The "IAN= A > Considerations" > section must have all the information, or at least fairly precise pointers, > to everything > IANA would need to know. Minimizing forward references is a good thin= g, > and the IANA > considerations section may be located anywhere within the body of the memo. > (See > http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt > section 4.) > > Randy > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 04:02:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04257; Fri, 15 Apr 2005 04:02:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMLwU-0002PJ-K7; Fri, 15 Apr 2005 04:12:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMLdP-0004Yq-9l; Fri, 15 Apr 2005 03:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMLdM-0004X9-II for ltru@megatron.ietf.org; Fri, 15 Apr 2005 03:53:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03357 for ; Fri, 15 Apr 2005 03:52:34 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMLn6-0001vW-2o for ltru@ietf.org; Fri, 15 Apr 2005 04:03:05 -0400 Received: from kotus.fi (pc163.kotus.fi [193.166.18.163]) by suomi.kotus.fi (8.12.10+Sun/8.12.9) with ESMTP id j3F7qSfp015629; Fri, 15 Apr 2005 10:52:28 +0300 (EEST) Message-ID: <425F72BC.5020402@kotus.fi> Date: Fri, 15 Apr 2005 10:52:28 +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: Mark Davis Subject: Re: [Ltru] Re: Proposed Text for Moving Forward References: <634978A7DF025A40BFEF33EB191E13BC0B08D6D9@irvmbxw01.quest.com> <019501c5416e$fafa41c0$087d3009@sanjose.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by suomi.kotus.fi id j3F7qSfp015629 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable Mark, A small addition: I understand that the old orthography of Moldavian=20 used/uses the Cyrillic sript (and the new one uses Latin). Regards, Erkki I. Kolehmainen Coordinator, Cultural Diversity Issues in ICT Research Institute for the Languages of Finland Mark Davis wrote: > BTW, just for background information, I generated a more readable form = of > the CLDR language info (draft for the next release), at > http://unicode.org/cldr/data/dropbox/language_info.txt >=20 > =E2=80=8EMark >=20 > ----- Original Message -----=20 > From: "Addison Phillips" > To: "Randy Presuhn" ; > Sent: Thursday, April 14, 2005 15:31 > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward >=20 >=20 > The problem is that the IANA considerations section contained a lot of > materials that really were not of interest to IANA. It contained: >=20 > 3.1 Format of the IANA Language Subtag Registry > 3.2 Maintenance of the Registry > 3.3 Stability of IANA Registry Entries > 3.4 Registration Procedure for Subtags > 3.5 Extensions and Extensions Namespace > 3.6 Conversion of the RFC 3066 Language Tag Registry >=20 > The new section can contain instructions to IANA explicitly. It doesn't > currently because we are in-flight and I haven't identified and moved (= or > written) the text at present. I've posted a bit more of that work, just= so > that it isn't unclear. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 >=20 >>-----Original Message----- >>From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On >>Behalf Of Randy Presuhn >>Sent: jeudi 14 avril 2005 12:57 >>To: ltru@ietf.org >>Subject: Re: [Ltru] Re: Proposed Text for Moving Forward >> >>Hi - >> >> >>>From: "Addison Phillips" >>>To: "John Cowan" ; "Mark Davis" >>> >> >>Cc: >> >>>Sent: Thursday, April 14, 2005 12:07 PM >>>Subject: RE: [Ltru] Re: Proposed Text for Moving Forward >>> >>> >>>Below is a proposed version of the section "Choice of Language Tag". >>>In writing this text, I began a heavy reorganization of the document's >>> >>sections. >> >>>Too many forward references were being created, >>>so I have followed our previous discussion and: >>> >>>1. Made the IANA Considerations section a very small separate section. >>>2. Made what was titled "IANA Considerations" into "Registry Format an= d >>> >>Maintenance" >> >>I can tell you now that this would probably run into trouble. The "IAN= A >>Considerations" >>section must have all the information, or at least fairly precise >> > pointers, >=20 >>to everything >>IANA would need to know. Minimizing forward references is a good thin= g, >>and the IANA >>considerations section may be located anywhere within the body of the >> > memo. >=20 >>(See >>http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-08.txt >>section 4.) >> >>Randy >> >> >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru >> >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 05:14:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10460; Fri, 15 Apr 2005 05:14:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMN4c-00057i-Ed; Fri, 15 Apr 2005 05:25:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMMtk-0005lk-82; Fri, 15 Apr 2005 05:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMMtT-0005jo-2T for ltru@megatron.ietf.org; Fri, 15 Apr 2005 05:13:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10350 for ; Fri, 15 Apr 2005 05:13:33 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMN3U-000538-DK for ltru@ietf.org; Fri, 15 Apr 2005 05:24:05 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Fri, 15 Apr 2005 09:58:08 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 09:58:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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: Off Topic (was Re: [Ltru] Great Script Debate Part II: Formats...) Date: Fri, 15 Apr 2005 09:58:06 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A3E6@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: Off Topic (was Re: [Ltru] Great Script Debate Part II: Formats...) Thread-Index: AcVBF+n+kMWZ/O1AT0C3OMotTW0yswAfbVVw From: "L.Gillam" To: ltru X-OriginalArrivalTime: 15 Apr 2005 08:58:07.0097 (UTC) FILETIME=[3DB48690:01C54199] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Jefsey, > I must rush and may be out of reach for 2 days. There is no=20 > real problem=20 > with this. Again, as long as the format for XML is fine and=20 > does not claim=20 > to be the format for the world and that the five level of=20 > multilingualism/vernacular are supported, if the QA and=20 > openess warranted=20 > by bilingual tables and the registration is opposed rather=20 > than accepted, I=20 > am OK. XML can claim what it wants as far as I am concerned. It is a consumer of tags, and may in some future be used as a tool for structuring (a) registr(y|ies) of tags. In PUE, all things are supported - I can't recall whether subtags still have to be 8*, but that's irrelevant anyway.=20 Since ISO standards are the basis, where is QA opposed? Where is openness opposed? These are fairly wild and unsubstantiated claims. > You just may want to consider that: > - there may be some serious political reluctance to "x": it has been=20 > objected with "xn--" as meaning "exclusion" or "xenophobe" or=20 > "christian" > - this is not a real problem for me, but be prepared to the=20 > "-x-" to be=20 > forgotten as soon as some one find a way to support it. Funny, but when I search for xenophobe with xn--, what do I find? A post by yourself pops up top (Google) in March 2003 (http://ops.ietf.org/lists/idn/idn.2003/msg00101.html). Clearly it MUST be a real problem for you - you've been dwelling on the issue for the past two years - but I've been unable to find further "serious political reluctance" as you refer to it. "x" to "xn--" to xenophobe, for a registry of language tags=20 (a registry of language tags with a fear of foreigners would be very small), is certainly both a leap and an interesting conspiracy=20 theory. alt.conspiracy should be your first target. Then perhaps you could campaign W3C to rename XML, XSLT, XPath, XPointer, .... perhaps the Unicode consortium and ASCII people also to prevent use of the letter on computers, and change the entire dictionary of a number of languages in the process. Besides, if you've read the current draft, you'll realise that other singletons are proposed also, syntax-wise. I'm sure it wouldn't=20 require a major quantum theoretical shift to assign a different=20 singleton to enable extension subtag use by those with serious=20 political reluctance to the letter x in tags. Doug? Of course, you'd need to find a letter which was politically acceptable in the process. > - this will be all the more true that referent will register. Register *what* exactly? =20 > Keep in mind=20 > that the more referent register it means they are interested.=20 No idea what this is meant to mean. > Then they=20 > will probably take over the register itself. In such a case, the RFC=20 > formula I propose will be a warranty of stability (there is=20 > only one RFC=20 > while there may be many reference centers, with different=20 > speed of access,=20 > added value, etc. Since this capability is already supported, as I've outlined before on more than one occassion, what is the novelty of this unseen proposition of yours? Bodies of all kinds CAN produce localised versions (names) for tags - national standards bodies CAN register and support them if they desire, DIN could provide a standard for German names and=20 so on. You propose a solution to a problem of your own invention. I wish you success. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 05:41:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11952; Fri, 15 Apr 2005 05:41:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMNUU-00063u-Fz; Fri, 15 Apr 2005 05:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMNHN-0003s9-Kx; Fri, 15 Apr 2005 05:38:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMNHK-0003pr-4F for ltru@megatron.ietf.org; Fri, 15 Apr 2005 05:38:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11766 for ; Fri, 15 Apr 2005 05:38:12 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMNRL-0005wH-P7 for ltru@ietf.org; Fri, 15 Apr 2005 05:48:45 -0400 Received: from if12m5-235.d4.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DMNH7-0001jg-Ml; Fri, 15 Apr 2005 02:38:10 -0700 Message-Id: <6.1.2.0.2.20050415103811.04defa90@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 15 Apr 2005 10:40:39 +0200 To: "Addison Phillips" , "John Cowan" , "Mark Davis" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Proposed Text for Moving Forward In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B08D5AC@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0B08D5AC@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad At 21:07 14/04/2005, Addison Phillips wrote: >http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.html >http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.txt Interesting. Would you have by any chance a .doc or .pdf version available? thank you. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 07:15:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17752; Fri, 15 Apr 2005 07:15:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMOxf-0000w2-Kw; Fri, 15 Apr 2005 07:26:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMOjy-0005BI-9E; Fri, 15 Apr 2005 07:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMOjp-00059n-Uo for ltru@megatron.ietf.org; Fri, 15 Apr 2005 07:11:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17571 for ; Fri, 15 Apr 2005 07:11:34 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime03.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMOtj-0000oE-Ax for ltru@ietf.org; Fri, 15 Apr 2005 07:22:08 -0400 Received: from uknsprd1 (unverified) by lonsmime03.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 15 Apr 2005 11:11:21 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IEZ00KWVJ2VUA@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 15 Apr 2005 12:11:20 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Fri, 15 Apr 2005 12:11:15 +0100 Date: Fri, 15 Apr 2005 12:11:13 +0100 From: Misha Wolf Subject: RE: [Ltru] Proposed Text for Moving Forward To: ltru@ietf.org Message-id: <1987416CA83AC7499AC772F92E2DBF780388DBDC@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Proposed Text for Moving Forward Thread-Index: AcVBSRDixxRNIslZSa6i9xeflvHPNAAYd1nQ content-class: urn:content-classes:message X-OriginalArrivalTime: 15 Apr 2005 11:11:15.0873 (UTC) FILETIME=[D7630110:01C541AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Hi Frank, I wasn't being so subtle :-( When I wrote: > 3. Does an Expected_Script[_Subtag] field always contain at > least two Scripts? I meant: 3. Are there always at least two Expected_Script values? There is a separate question of whether we're still using=20 semicolons to separate values in the registry or whether we're=20 repeating fields ... I've lost track of where we've got to on=20 that. If it is the former, then I'm suggesting, eg: Expected_Scripts: Hans; Hant; Bopo If it is the latter, then I'm suggesting, eg: Expected_Script: Hans Expected_Script: Hant Expected_Script: Bopo Misha -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Frank Ellermann Sent: 15 April 2005 00:15 To: ltru@ietf.org Subject: [Ltru] Re: Proposed Text for Moving Forward Misha Wolf wrote: =20 > 1. Is an Expected_Script_Subtag field and a Default_Script > field mutually exclusive? No, the latter can be identified as "only one expected script" The rules are of course very different, SHOULD vs, SHOULD NOT. > 3. Does an Expected_Script[_Subtag] field always contain at > least two Scripts? Not if you combine them as in (1), Probably that was your real question, can they be used together for the same language. ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 07:23:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18197; Fri, 15 Apr 2005 07:23:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMP4u-0001F8-Pf; Fri, 15 Apr 2005 07:33:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMOnq-0005XT-FK; Fri, 15 Apr 2005 07:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMOnf-0005U4-J2 for ltru@megatron.ietf.org; Fri, 15 Apr 2005 07:15:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17744 for ; Fri, 15 Apr 2005 07:15:26 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime01.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMOxT-0000vN-1c for ltru@ietf.org; Fri, 15 Apr 2005 07:25:59 -0400 Received: from eupig1 (unverified) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 15 Apr 2005 11:15:11 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IEZ00M1LJ958K@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 15 Apr 2005 11:15:05 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 15 Apr 2005 11:15:04 +0000 Date: Fri, 15 Apr 2005 12:15:04 +0100 From: Misha Wolf Subject: RE: [Ltru] Re: Proposed Text for Moving Forward To: ltru@ietf.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVBXom5za/HFz5GTAedE2UZDhybJgATV+oQ content-class: urn:content-classes:message X-OriginalArrivalTime: 15 Apr 2005 11:15:05.0080 (UTC) FILETIME=[60013780:01C541AC] X-Spam-Score: 0.8 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable As clarified in an earlier mail, the more complex solution was=20 hatched by an unauthorised copy of Misha, running in Frank's=20 brain :-) Misha -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Frank Ellermann Sent: 15 April 2005 02:51 To: ltru@ietf.org Subject: [Ltru] Re: Proposed Text for Moving Forward Addison Phillips wrote: =20 > 0*1[script] =3D=3D SHOULD NOT use > 2*[script] =3D=3D SHOULD use That's the KISS variant, therefore I like it. Misha apparently wanted a more complex solution allowing to mix a default script with _additional_ expected scripts. I don't see where Misha's feature is necessary for 3066 compatibility, but it's possible. ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 10:52:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06848; Fri, 15 Apr 2005 10:52:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMSLG-00012h-I9; Fri, 15 Apr 2005 11:02:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMS2Q-0004GV-ID; Fri, 15 Apr 2005 10:43:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMS2O-0004GB-MN for ltru@megatron.ietf.org; Fri, 15 Apr 2005 10:43:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06088 for ; Fri, 15 Apr 2005 10:43:14 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMSCa-0000h5-NK for ltru@ietf.org; Fri, 15 Apr 2005 10:53:49 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 07:43:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 07:42:59 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08D92F@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVBnthKeUa86JfJShOnDSlYnPcmFQAKgHsw From: "Addison Phillips" To: "JFC (Jefsey) Morfin" , "John Cowan" , "Mark Davis" X-OriginalArrivalTime: 15 Apr 2005 14:43:00.0701 (UTC) FILETIME=[6C0DE8D0:01C541C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable No.=20 Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > Sent: vendredi 15 avril 2005 01:41 > To: Addison Phillips; John Cowan; Mark Davis > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward >=20 > At 21:07 14/04/2005, Addison Phillips wrote: > >http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.html > >http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.txt >=20 > Interesting. > Would you have by any chance a .doc or .pdf version available? > thank you. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 13:20:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23106; Fri, 15 Apr 2005 13:20:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMUex-0001An-Ds; Fri, 15 Apr 2005 13:31:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMUM5-0000YX-Px; Fri, 15 Apr 2005 13:11:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMUM4-0000YH-12 for ltru@megatron.ietf.org; Fri, 15 Apr 2005 13:11:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22185 for ; Fri, 15 Apr 2005 13:11:41 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMUWH-0000cE-Jn for ltru@ietf.org; Fri, 15 Apr 2005 13:22:18 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 10:11:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 10:11:26 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DA4C@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVBYzgRGi+72FWtQ9CoECfKAqmRtgAePIqA From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 15 Apr 2005 17:11:26.0973 (UTC) FILETIME=[289B2AD0:01C541DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable I agree that the Gothic example might not be obvious, this would be a = good place to put a comment into the registry. It might be useful to actually distinguish between processing language = and content language (metadata). For example, one might use "got-Latn" = and "got-Goth" on

elements in an XHMTL document so that appropriate = fonts can by applied to each in a stylesheet and still use "got" = (meaning "got-Latn") in the element or in external references to = the document. See: = http://www.w3.org/TR/i18n-html-tech-lang/#ri20030510.102829377, which = helped form my thinking about this. I don't think that script associations need to pass an obviousness test. = But the temptation to register every script a language has ever been = written in should be guarded against since it will cause a lot of texts = to pick up "SHOULD" when they really should not. Perhaps having separate = fields (default and associated/expected) would help this, allowing = promiscuous registration of associated scripts. In that case, it is: 0*1[default_script] =3D SHOULD NOT 2*[default_script] =3D SHOULD always [associated_script] =3D informational list of additional scripts??? Comments? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: jeudi 14 avril 2005 19:32 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: Proposed Text for Moving Forward >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "Frank Ellermann" ; > > Sent: Thursday, April 14, 2005 4:48 PM > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > ... > > Perhaps the rules should be: > > > > 1. If the primary language has no associated script, > > you SHOULD NOT use a script subtag > > unless it adds distinguishing information for that context. > > > > 2. If the primary language has a single associated script > > and the content uses that script, > > you SHOULD NOT use the script subtag (unless etc.). > > > > 3. If the primary language has two or more associated scripts > > and the content uses one of them, > > you SHOULD use the script subtag (unless it is harmful to do so). > > > > 4. If the primary language has any number of associated scripts, > > but the content uses a different script, > > you SHOULD use the script subtag (unless it is harmful to do so). >=20 > To get the desired results for Gothic, (no subtag for Gothic = transcribed > into latin alphabet, subtag required if using the historical Gothic > alphabet) > I think this would mean that the entry for Gothic could not identify > Gothic > as an associated script, and that the associated script (if any) would = be > latin. I guess this works, but I'd classify it as "obvious only if > previously > understood." >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 15:28:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07557; Fri, 15 Apr 2005 15:28:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMWeK-0000nF-TT; Fri, 15 Apr 2005 15:38:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMWSx-0006pz-B2; Fri, 15 Apr 2005 15:26:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMWSw-0006pg-45 for ltru@megatron.ietf.org; Fri, 15 Apr 2005 15:26:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07415 for ; Fri, 15 Apr 2005 15:26:54 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMWd7-0000jx-FL for ltru@ietf.org; Fri, 15 Apr 2005 15:37:31 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 12:26:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 12:26:43 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DAFF@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVBYzgRGi+72FWtQ9CoECfKAqmRtgAePIqAAATO5jA= From: "Addison Phillips" To: "Addison Phillips" , "Randy Presuhn" , X-OriginalArrivalTime: 15 Apr 2005 19:26:43.0492 (UTC) FILETIME=[0E6DAE40:01C541F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable One more thought. Maybe we're trying to fix this the wrong way. Solutions that rely on = counting the number of script fields produce problems because what you = do is unstable and based on how many times a language has had a script = registered. Instead, we should create fields that exactly match what you do with = them. Subtag: en Suppress_Script: Latn Subtag: sr Require_Script: Cyrl, Latn Subtag: got Suppress_Script: Latn, Goth Comment: only an example With these rules: 1. Script subtags listed in the 'Suppress_Script' field SHOULD NOT be = used to form language tags unless they add specific information to the = language tag required by an application. 2. Script subtags listed in the 'Require_Script' field SHOULD always be = used to form language tags when the script used by the content being = identified matches the script unless there is a specific reason to omit = the script subtag in the application. 3. If the script of the content matches neither field (or the fields are = both unpopulated), the script subtag SHOULD NOT be used to form language = tags for that language unless it adds specific information to the = language tag which is required by the application. Suppress_Script is NOT guaranteed to be stable (values may be removed). = Require_Script IS guaranteed to be stable (values can be added only). = The two fields are mutually exclusive. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Addison Phillips > Sent: vendredi 15 avril 2005 10:11 > To: Randy Presuhn; ltru@ietf.org > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward >=20 > I agree that the Gothic example might not be obvious, this would be a = good > place to put a comment into the registry. >=20 > It might be useful to actually distinguish between processing language = and > content language (metadata). For example, one might use "got-Latn" and > "got-Goth" on

elements in an XHMTL document so that appropriate = fonts > can by applied to each in a stylesheet and still use "got" (meaning = "got- > Latn") in the element or in external references to the = document. > See: http://www.w3.org/TR/i18n-html-tech-lang/#ri20030510.102829377, = which > helped form my thinking about this. >=20 > I don't think that script associations need to pass an obviousness = test. > But the temptation to register every script a language has ever been > written in should be guarded against since it will cause a lot of = texts to > pick up "SHOULD" when they really should not. Perhaps having separate > fields (default and associated/expected) would help this, allowing > promiscuous registration of associated scripts. >=20 > In that case, it is: >=20 > 0*1[default_script] =3D SHOULD NOT > 2*[default_script] =3D SHOULD always > [associated_script] =3D informational list of additional scripts??? >=20 > Comments? >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Randy Presuhn > > Sent: jeudi 14 avril 2005 19:32 > > To: ltru@ietf.org > > Subject: Re: [Ltru] Re: Proposed Text for Moving Forward > > > > Hi - > > > > > From: "Addison Phillips" > > > To: "Frank Ellermann" ; > > > Sent: Thursday, April 14, 2005 4:48 PM > > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > ... > > > Perhaps the rules should be: > > > > > > 1. If the primary language has no associated script, > > > you SHOULD NOT use a script subtag > > > unless it adds distinguishing information for that context. > > > > > > 2. If the primary language has a single associated script > > > and the content uses that script, > > > you SHOULD NOT use the script subtag (unless etc.). > > > > > > 3. If the primary language has two or more associated scripts > > > and the content uses one of them, > > > you SHOULD use the script subtag (unless it is harmful to do so). > > > > > > 4. If the primary language has any number of associated scripts, > > > but the content uses a different script, > > > you SHOULD use the script subtag (unless it is harmful to do so). > > > > To get the desired results for Gothic, (no subtag for Gothic = transcribed > > into latin alphabet, subtag required if using the historical Gothic > > alphabet) > > I think this would mean that the entry for Gothic could not identify > > Gothic > > as an associated script, and that the associated script (if any) = would > be > > latin. I guess this works, but I'd classify it as "obvious only if > > previously > > understood." > > > > Randy > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 16:29:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21293; Fri, 15 Apr 2005 16:29:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMXbI-0007A0-TF; Fri, 15 Apr 2005 16:39:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXFj-0004Yb-HB; Fri, 15 Apr 2005 16:17:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXFi-0004YS-VS for ltru@megatron.ietf.org; Fri, 15 Apr 2005 16:17:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18983 for ; Fri, 15 Apr 2005 16:17:20 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMXPy-00066t-Pr for ltru@ietf.org; Fri, 15 Apr 2005 16:27:59 -0400 Received: from h-64-105-137-140.snvacaid.dynamic.covad.net ([64.105.137.140] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DMXFf-0007Ln-00 for ltru@ietf.org; Fri, 15 Apr 2005 13:17:20 -0700 Message-ID: <00b201c541f8$57c74860$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08DAFF@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 13:18:52 -0700 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: 2.9 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi - > From: "Addison Phillips" > To: "Addison Phillips" ; "Randy Presuhn" ; > Sent: Friday, April 15, 2005 12:26 PM > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward ... > Instead, we should create fields that exactly match what you do with them. Sounds like a good principle. ... > Subtag: got > Suppress_Script: Latn, Goth > Comment: only an example If the desired behaviour is for transcribed Gothic to be "got" and for Gothic in its historic alphabet to be "got-Goth", then I think this should have been: + Subtag: got + Supress_Script: Latn + Require_Script: Goth (It's been nearly a quarter century since I worked with Gothic, so I'm *not* making any claims that this would indeed be the desired behaviour now, though it would have been correct then.) Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 16:55:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24109; Fri, 15 Apr 2005 16:55:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMY0b-0000QJ-R2; Fri, 15 Apr 2005 17:05:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXjB-0000Y6-QX; Fri, 15 Apr 2005 16:47:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMXj8-0000Xi-QL for ltru@megatron.ietf.org; Fri, 15 Apr 2005 16:47:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23315 for ; Fri, 15 Apr 2005 16:47:44 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMXtO-0008OH-7A for ltru@ietf.org; Fri, 15 Apr 2005 16:58:23 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3FKlVCV014193; Fri, 15 Apr 2005 16:47:32 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 15 Apr 2005 16:47:34 -0400 Date: Fri, 15 Apr 2005 16:47:34 -0400 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Message-ID: <20050415204733.GF11008@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B08DAFF@irvmbxw01.quest.com> <00b201c541f8$57c74860$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00b201c541f8$57c74860$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Randy Presuhn scripsit: > (It's been nearly a quarter century since I worked with Gothic, so > I'm *not* making any claims that this would indeed be the desired > behaviour now, though it would have been correct then.) Michael Everson believes it's still true. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan Consider the matter of Analytic Philosophy. Dennett and Bennett are well-known. Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett. There is also one Dummett. By their works shall ye know them. However, just as no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly known by his works. Indeed, Bummett does not exist. It is part of the function of this and other e-mail messages, therefore, to do what they can to create him. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 17:09:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26146; Fri, 15 Apr 2005 17:09:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYEg-0001W0-Ph; Fri, 15 Apr 2005 17:20:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMY2I-0003Vo-NY; Fri, 15 Apr 2005 17:07:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMY2H-0003Vf-N7 for ltru@megatron.ietf.org; Fri, 15 Apr 2005 17:07:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25734 for ; Fri, 15 Apr 2005 17:07:31 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYCX-0001DT-0W for ltru@ietf.org; Fri, 15 Apr 2005 17:18:10 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 14:07:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 14:07:17 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DB6A@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVB+Y6zSPQXFIGRSZ65b2eZn+RC5QABURpQ From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 15 Apr 2005 21:07:18.0250 (UTC) FILETIME=[1B6CACA0:01C541FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Hence the comment... > > Comment: only an example So the mechanism works for you? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: vendredi 15 avril 2005 13:19 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: Proposed Text for Moving Forward >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "Addison Phillips" ; "Randy Presuhn" > ; > > Sent: Friday, April 15, 2005 12:26 PM > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > ... > > Instead, we should create fields that exactly match what you do with > them. >=20 > Sounds like a good principle. >=20 > ... > > Subtag: got > > Suppress_Script: Latn, Goth > > Comment: only an example >=20 > If the desired behaviour is for transcribed Gothic to be "got" and > for Gothic in its historic alphabet to be "got-Goth", then I > think this should have been: >=20 > + Subtag: got > + Supress_Script: Latn > + Require_Script: Goth >=20 > (It's been nearly a quarter century since I worked with Gothic, so > I'm *not* making any claims that this would indeed be the desired > behaviour now, though it would have been correct then.) >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 17:43:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01053; Fri, 15 Apr 2005 17:43:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYlN-0003WX-Vb; Fri, 15 Apr 2005 17:54:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMYSq-0006mL-59; Fri, 15 Apr 2005 17:35:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMYSp-0006mA-Cp for ltru@megatron.ietf.org; Fri, 15 Apr 2005 17:34:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28418 for ; Fri, 15 Apr 2005 17:34:57 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYd6-0002wC-8M for ltru@ietf.org; Fri, 15 Apr 2005 17:45:36 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3FLYgLP012633; Fri, 15 Apr 2005 14:34:46 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3A22XS>; Fri, 15 Apr 2005 14:34:43 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Randy Presuhn , ltru@ietf.org Subject: RE: [Ltru] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 14:34:36 -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: 8b6657e60309a1317174c9db2ae5f227 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 +1 Thanks for some good clear thought for a change. I agree that I hated this counting the field members approach. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Friday, April 15, 2005 3:27 PM > To: Addison Phillips; Randy Presuhn; ltru@ietf.org > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > One more thought. > > Maybe we're trying to fix this the wrong way. Solutions that > rely on counting the number of script fields produce problems > because what you do is unstable and based on how many times a > language has had a script registered. > > Instead, we should create fields that exactly match what you > do with them. > > Subtag: en > Suppress_Script: Latn > > Subtag: sr > Require_Script: Cyrl, Latn > > Subtag: got > Suppress_Script: Latn, Goth > Comment: only an example > > With these rules: > > 1. Script subtags listed in the 'Suppress_Script' field > SHOULD NOT be used to form language tags unless they add > specific information to the language tag required by an application. > > 2. Script subtags listed in the 'Require_Script' field SHOULD > always be used to form language tags when the script used by > the content being identified matches the script unless there > is a specific reason to omit the script subtag in the application. > > 3. If the script of the content matches neither field (or the > fields are both unpopulated), the script subtag SHOULD NOT be > used to form language tags for that language unless it adds > specific information to the language tag which is required by > the application. > > Suppress_Script is NOT guaranteed to be stable (values may be > removed). Require_Script IS guaranteed to be stable (values > can be added only). The two fields are mutually exclusive. > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Addison Phillips > > Sent: vendredi 15 avril 2005 10:11 > > To: Randy Presuhn; ltru@ietf.org > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > > I agree that the Gothic example might not be obvious, this > would be a good > > place to put a comment into the registry. > > > > It might be useful to actually distinguish between > processing language and > > content language (metadata). For example, one might use > "got-Latn" and > > "got-Goth" on

elements in an XHMTL document so that > appropriate fonts > > can by applied to each in a stylesheet and still use "got" > (meaning "got- > > Latn") in the element or in external references to > the document. > > See: > http://www.w3.org/TR/i18n-html-tech-lang/#ri20030510.102829377, which > > helped form my thinking about this. > > > > I don't think that script associations need to pass an > obviousness test. > > But the temptation to register every script a language has ever been > > written in should be guarded against since it will cause a > lot of texts to > > pick up "SHOULD" when they really should not. Perhaps > having separate > > fields (default and associated/expected) would help this, allowing > > promiscuous registration of associated scripts. > > > > In that case, it is: > > > > 0*1[default_script] = SHOULD NOT > > 2*[default_script] = SHOULD always > > [associated_script] = informational list of additional scripts??? > > > > Comments? > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] > > On > > > Behalf Of Randy Presuhn > > > Sent: jeudi 14 avril 2005 19:32 > > > To: ltru@ietf.org > > > Subject: Re: [Ltru] Re: Proposed Text for Moving Forward > > > > > > Hi - > > > > > > > From: "Addison Phillips" > > > > To: "Frank Ellermann" ; > > > > > Sent: Thursday, April 14, 2005 4:48 PM > > > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > ... > > > > Perhaps the rules should be: > > > > > > > > 1. If the primary language has no associated script, > > > > you SHOULD NOT use a script subtag > > > > unless it adds distinguishing information for that context. > > > > > > > > 2. If the primary language has a single associated script > > > > and the content uses that script, > > > > you SHOULD NOT use the script subtag (unless etc.). > > > > > > > > 3. If the primary language has two or more associated scripts > > > > and the content uses one of them, > > > > you SHOULD use the script subtag (unless it is harmful > to do so). > > > > > > > > 4. If the primary language has any number of associated scripts, > > > > but the content uses a different script, > > > > you SHOULD use the script subtag (unless it is harmful > to do so). > > > > > > To get the desired results for Gothic, (no subtag for > Gothic transcribed > > > into latin alphabet, subtag required if using the > historical Gothic > > > alphabet) > > > I think this would mean that the entry for Gothic could > not identify > > > Gothic > > > as an associated script, and that the associated script > (if any) would > > be > > > latin. I guess this works, but I'd classify it as > "obvious only if > > > previously > > > understood." > > > > > > Randy > > > > > > > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 17:53:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02725; Fri, 15 Apr 2005 17:53:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYvF-0004AO-Hz; Fri, 15 Apr 2005 18:04:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMYhA-00008p-1L; Fri, 15 Apr 2005 17:49:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMYh8-00008b-C9 for ltru@megatron.ietf.org; Fri, 15 Apr 2005 17:49:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02425 for ; Fri, 15 Apr 2005 17:49:44 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMYrO-0003uj-IM for ltru@ietf.org; Fri, 15 Apr 2005 18:00:23 -0400 Received: from h-64-105-137-140.snvacaid.dynamic.covad.net ([64.105.137.140] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DMYh5-0003zs-00 for ltru@ietf.org; Fri, 15 Apr 2005 14:49:43 -0700 Message-ID: <024601c54205$4034d0c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08DB6A@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 14:50:46 -0700 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: 2.9 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi - > From: "Addison Phillips" > To: "Randy Presuhn" ; > Sent: Friday, April 15, 2005 2:07 PM > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward ... > So the mechanism works for you? ... It seems to be able to produce the desired results for the cases where I have first-hand knowledge of the language, and is easier to understand than the approaches that required counting. If the WG converges on this approach, what will be critical is the clarity of the SHOULDs and SHOULD NOTs. It might be helpful to include an example explaining why tagging data with en-Latn would normally be a bad idea, in order to give implementers a serious clue about just how strong the SHOULD NOTs are meant to be. Now, probing a bit deeper, (and these may be purely theoretical problems, and could be dismissed as such) do we have any cases like this: language L in general is written in script S1 overwhelmingly, and there is a substantial corpus of data tagged simply "L". language L has several important variants, V1..Vn V2, a rather rare variant, uses script S2 overwhelmingly If there are cases like this (for example, a hypothetical community of German speakers using the Hebrew alphabet in a manner similar to Yiddish, or a community of Yiddish speakers using the latin alphabet) would there be any need to represent this in the registry? The tag L-S2-V2 would be preferred to the tag L-V2, right? How would a developer looking at the registry determine this? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 18:36:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06517; Fri, 15 Apr 2005 18:36:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMZav-0006Mo-AM; Fri, 15 Apr 2005 18:47:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMZ7k-00038H-GT; Fri, 15 Apr 2005 18:17:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMZ7i-000384-T6 for ltru@megatron.ietf.org; Fri, 15 Apr 2005 18:17:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05111 for ; Fri, 15 Apr 2005 18:17:12 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMZI0-0005Mx-1m for ltru@ietf.org; Fri, 15 Apr 2005 18:27:52 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 15:17:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 15:17:01 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DBB9@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVCBasKyxAlhmrmTfyBpqGwv+KRlgAAPBgA From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 15 Apr 2005 22:17:02.0880 (UTC) FILETIME=[D9A88A00:01C54208] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable > Now, probing a bit deeper, (and these may be purely theoretical > problems, and could be dismissed as such) do we have any > cases like this: > language L in general is written in script S1 overwhelmingly, > and there is a substantial corpus of data tagged simply "L". > language L has several important variants, V1..Vn > V2, a rather rare variant, uses script S2 overwhelmingly >=20 > If there are cases like this (for example, a hypothetical community > of German speakers using the Hebrew alphabet in a manner similar to > Yiddish, or a community of Yiddish speakers using the latin alphabet) > would there be any need to represent this in the registry? > The tag L-S2-V2 would be preferred to the tag L-V2, right? How would > a developer looking at the registry determine this? There is the beauty of "Suppress_Script": it only suppresses S1. It has = no effect on S2. A user might then choose (thanks to escape clauses in = the rules) to use L-S1 for some other content in the same context. I = think you're thinking of rule 3: 3. If the script of the content matches neither field (or the fields are = both unpopulated), the script subtag SHOULD NOT be used to form language = tags for that language unless it adds specific information to the = language tag which is required by the application. We should probably modify that to say: 3. If the script doesn't match any of the "Require_Script" subtags, then = the script subtag SHOULD be used to form the language tag as long as it = adds useful information to the tag or it matches a "Supress_Script" = subtag for that language (in which case it SHOULD NOT be used to form = the language tag). (IOW, these fields only affect scripts that match their entries and = nothing else. The previous rule about not using subtags that add no = information still applies.) Then consider: Subtag: de Suppress_Script: Latn "de-DE" // no Latn "de-Yiii-AQ" // Yiii not suppressed Subtag: zh Require_Script: Hant, Hans Suppress_Script: Yyyy // example only Zh-Hant-TW Zh-Hans-CN Zh-AQ // Yyyy suppressed Zh-Latn-AQ The only thing that matters in this design is the majority script. = Suppress only suppresses the named script. It has no effect on a = language variation that uses another script unless that script is = specifically suppressed. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: vendredi 15 avril 2005 14:51 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: Proposed Text for Moving Forward >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "Randy Presuhn" ; > > Sent: Friday, April 15, 2005 2:07 PM > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > ... > > So the mechanism works for you? > ... >=20 > It seems to be able to produce the desired results for the cases > where I have first-hand knowledge of the language, and is easier > to understand than the approaches that required counting. >=20 > If the WG converges on this approach, what will be critical is the > clarity of the SHOULDs and SHOULD NOTs. It might be helpful > to include an example explaining why tagging data with en-Latn > would normally be a bad idea, in order to give implementers a > serious clue about just how strong the SHOULD NOTs are > meant to be. >=20 > Now, probing a bit deeper, (and these may be purely theoretical > problems, and could be dismissed as such) do we have any > cases like this: > language L in general is written in script S1 overwhelmingly, > and there is a substantial corpus of data tagged simply "L". > language L has several important variants, V1..Vn > V2, a rather rare variant, uses script S2 overwhelmingly >=20 > If there are cases like this (for example, a hypothetical community > of German speakers using the Hebrew alphabet in a manner similar to > Yiddish, or a community of Yiddish speakers using the latin alphabet) > would there be any need to represent this in the registry? > The tag L-S2-V2 would be preferred to the tag L-V2, right? How would > a developer looking at the registry determine this? >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 18:47:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07103; Fri, 15 Apr 2005 18:47:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMZlg-0006tM-37; Fri, 15 Apr 2005 18:58:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMZUQ-00051J-2q; Fri, 15 Apr 2005 18:40:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMZUP-00051B-EK for ltru@megatron.ietf.org; Fri, 15 Apr 2005 18:40:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06801 for ; Fri, 15 Apr 2005 18:40:38 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMZeg-0006Xz-0L for ltru@ietf.org; Fri, 15 Apr 2005 18:51:18 -0400 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3FMeU5b006660 for ; Fri, 15 Apr 2005 18:40:30 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3FMeT3q207006 for ; Fri, 15 Apr 2005 16:40:30 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3FMeT41001518 for ; Fri, 15 Apr 2005 16:40:29 -0600 Received: from markdavis (sig-9-48-119-82.mts.ibm.com [9.48.119.82]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3FMeS8J001487; Fri, 15 Apr 2005 16:40:29 -0600 Message-ID: <034c01c5420c$1f2b9d80$087d3009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "Randy Presuhn" , References: <634978A7DF025A40BFEF33EB191E13BC0B08DAFF@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 15:40:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id j3FMeU5b006660 X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Content-Transfer-Encoding: quoted-printable This is a real improvement. But in terms of results, it appears that ther= e is no real difference in guidance in having the Suppress_Script field, an= d having nothing. So it is unclear why the 'Suppress_Script' is needed. >1. Script subtags listed in the 'Suppress_Script' field SHOULD NOT be us= ed to form language tags unless they add specific information to the languag= e tag required by an application. >3. If the script of the content matches neither field (or the fields are both unpopulated), the script subtag SHOULD NOT be used to form language tags for that language unless it adds specific information to the languag= e tag which is required by the application. >If the script of the content matches neither field... This doesn't seem right. Take: Subtag: sr Require_Script: Cyrl, Latn If I have data in sr-Kana, I really should tag it as such -- I don't want= it matching sr-Maya, etc. =3D=3D=3D=3D=3D So, based on the results you describe, this could be simplified down to o= ne field, Suppress_Script, and two rules. 1. Script subtags listed in the 'Suppress_Script' field SHOULD NOT be use= d to form language tags unless they add specific information to the languag= e tag required by an application. 2. Script subtags not listed in the 'Suppress_Script' field SHOULD always= be used to form language tags when the script used by the content being identified matches the script unless there is a specific reason to omit t= he script subtag in the application. So A. If the Suppress_Script is Latn, then en-Latn becomes en, while en-Cyrl stays as is B. If there is no Suppress_Script (say for zh), then zh-Hant, zh-Hans, zh-Cyrl, (and everything else) stay as is. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "Addison Phillips" ; "Randy Presuhn" ; Sent: Friday, April 15, 2005 12:26 Subject: RE: [Ltru] Re: Proposed Text for Moving Forward One more thought. Maybe we're trying to fix this the wrong way. Solutions that rely on counting the number of script fields produce problems because what you do= is unstable and based on how many times a language has had a script register= ed. Instead, we should create fields that exactly match what you do with them. Subtag: en Suppress_Script: Latn Subtag: sr Require_Script: Cyrl, Latn Subtag: got Suppress_Script: Latn, Goth Comment: only an example With these rules: 1. Script subtags listed in the 'Suppress_Script' field SHOULD NOT be use= d to form language tags unless they add specific information to the languag= e tag required by an application. 2. Script subtags listed in the 'Require_Script' field SHOULD always be u= sed to form language tags when the script used by the content being identifie= d matches the script unless there is a specific reason to omit the script subtag in the application. 3. If the script of the content matches neither field (or the fields are both unpopulated), the script subtag SHOULD NOT be used to form language tags for that language unless it adds specific information to the languag= e tag which is required by the application. Suppress_Script is NOT guaranteed to be stable (values may be removed). Require_Script IS guaranteed to be stable (values can be added only). The two fields are mutually exclusive. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture. > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Addison Phillips > Sent: vendredi 15 avril 2005 10:11 > To: Randy Presuhn; ltru@ietf.org > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > I agree that the Gothic example might not be obvious, this would be a g= ood > place to put a comment into the registry. > > It might be useful to actually distinguish between processing language = and > content language (metadata). For example, one might use "got-Latn" and > "got-Goth" on

elements in an XHMTL document so that appropriate fon= ts > can by applied to each in a stylesheet and still use "got" (meaning "go= t- > Latn") in the element or in external references to the document. > See: http://www.w3.org/TR/i18n-html-tech-lang/#ri20030510.102829377, wh= ich > helped form my thinking about this. > > I don't think that script associations need to pass an obviousness test. > But the temptation to register every script a language has ever been > written in should be guarded against since it will cause a lot of texts= to > pick up "SHOULD" when they really should not. Perhaps having separate > fields (default and associated/expected) would help this, allowing > promiscuous registration of associated scripts. > > In that case, it is: > > 0*1[default_script] =3D SHOULD NOT > 2*[default_script] =3D SHOULD always > [associated_script] =3D informational list of additional scripts??? > > Comments? > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org= ] > On > > Behalf Of Randy Presuhn > > Sent: jeudi 14 avril 2005 19:32 > > To: ltru@ietf.org > > Subject: Re: [Ltru] Re: Proposed Text for Moving Forward > > > > Hi - > > > > > From: "Addison Phillips" > > > To: "Frank Ellermann" ; > > > Sent: Thursday, April 14, 2005 4:48 PM > > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > ... > > > Perhaps the rules should be: > > > > > > 1. If the primary language has no associated script, > > > you SHOULD NOT use a script subtag > > > unless it adds distinguishing information for that context. > > > > > > 2. If the primary language has a single associated script > > > and the content uses that script, > > > you SHOULD NOT use the script subtag (unless etc.). > > > > > > 3. If the primary language has two or more associated scripts > > > and the content uses one of them, > > > you SHOULD use the script subtag (unless it is harmful to do so). > > > > > > 4. If the primary language has any number of associated scripts, > > > but the content uses a different script, > > > you SHOULD use the script subtag (unless it is harmful to do so). > > > > To get the desired results for Gothic, (no subtag for Gothic transcri= bed > > into latin alphabet, subtag required if using the historical Gothic > > alphabet) > > I think this would mean that the entry for Gothic could not identify > > Gothic > > as an associated script, and that the associated script (if any) woul= d > be > > latin. I guess this works, but I'd classify it as "obvious only if > > previously > > understood." > > > > Randy > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 18:48:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07181; Fri, 15 Apr 2005 18:48:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMZmb-0006u8-U2; Fri, 15 Apr 2005 18:59:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMZCF-0003Vq-O5; Fri, 15 Apr 2005 18:21:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMZCB-0003VP-RW for ltru@megatron.ietf.org; Fri, 15 Apr 2005 18:21:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05455 for ; Fri, 15 Apr 2005 18:21:48 -0400 (EDT) Received: from pop-a065c05.pas.sa.earthlink.net ([207.217.121.183]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMZMP-0005XE-Kf for ltru@ietf.org; Fri, 15 Apr 2005 18:32:28 -0400 Received: from h-64-105-137-140.snvacaid.dynamic.covad.net ([64.105.137.140] helo=oemcomputer) by pop-a065c05.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DMZC2-0006Zg-00 for ltru@ietf.org; Fri, 15 Apr 2005 15:21:42 -0700 Message-ID: <000a01c54209$b741aa40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08DBB9@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 15:23:14 -0700 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: 2.9 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Hi - > From: "Addison Phillips" > To: "Randy Presuhn" ; > Sent: Friday, April 15, 2005 3:17 PM > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward ... > The only thing that matters in this design is the majority script. > Suppress only suppresses the named script. It has no effect > on a language variation that uses another script unless that > script is specifically suppressed. ... Nice. Would it have any impact on the formulation of the matching algorithms? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 21:58:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18098; Fri, 15 Apr 2005 21:58:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMcjm-0007uP-JW; Fri, 15 Apr 2005 22:08:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMcUR-00054l-7f; Fri, 15 Apr 2005 21:52:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMcUP-00054d-Se for ltru@megatron.ietf.org; Fri, 15 Apr 2005 21:52:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17939 for ; Fri, 15 Apr 2005 21:52:52 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMcei-0007i2-6s for ltru@ietf.org; Fri, 15 Apr 2005 22:03:33 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 18:52:43 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Fri, 15 Apr 2005 18:52:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 18:52:44 -0700 Message-ID: Thread-Topic: [Ltru] Proposed Text for Moving Forward Thread-Index: AcVBIQN8y2rdFgDvTkCatDriFts91gAAnW3wAADkcpAAP8FPsA== From: "Peter Constable" To: "ltru" X-OriginalArrivalTime: 16 Apr 2005 01:52:42.0907 (UTC) FILETIME=[FA83F6B0:01C54226] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Misha Wolf > 2. Why does Expected_Script_Subtag contain "_Subtag" but Default_Script > not do so? Can we rename the former to Expected_Script? First off, I'm not sure that we need *both* of these fields. But if we are going to include "Expected_Script(_Subtags)", then I think "_Subtags" should be part of the label. The reason is that without it the meaning of the field isn't clear. The whole purpose for which the field was suggested IIRC was to indicate those cases in which a script subtag should be included in a tag (in contrast to those cases in which a script subtag should *not* be included in a tag). "Expected_Script" doesn't clearly convey that; indeed, someone seeing "Expected_Script: Cyrl, Arab" might possibly interpret that to me Cyrillic can be assumed, so they don't need to include "Cyrl" in a tag. But I'm more inclined to communicate directly what we want users or developers to understand -- in just which cases should a script subtag not be included for general use -- and that is done most directly by a single value listed in a "Default_Script" field. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 22:05:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18521; Fri, 15 Apr 2005 22:05:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMcr7-0008OX-98; Fri, 15 Apr 2005 22:16:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMcZA-0005VJ-NR; Fri, 15 Apr 2005 21:57:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMcZ9-0005V4-6O for ltru@megatron.ietf.org; Fri, 15 Apr 2005 21:57:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18080 for ; Fri, 15 Apr 2005 21:57:45 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMcjR-0007u8-JC for ltru@ietf.org; Fri, 15 Apr 2005 22:08:26 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Fri, 15 Apr 2005 18:57:36 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Fri, 15 Apr 2005 18:57:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 18:57:37 -0700 Message-ID: Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVBYzgRGi+72FWtQ9CoECfKAqmRtgAePIqAAATO5jAADgIcgA== From: "Peter Constable" To: X-OriginalArrivalTime: 16 Apr 2005 01:57:36.0437 (UTC) FILETIME=[A9791650:01C54227] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > Instead, we should create fields that exactly match what you do with them. >=20 > Subtag: en > Suppress_Script: Latn This approach addresses my concern: that we communicate clearly in what cases a script tag should not be included in a tag for general use. This field label communicates that better than "Default_Script" does. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Fri Apr 15 22:12:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22745; Fri, 15 Apr 2005 22:12:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMcy5-0000F7-Kq; Fri, 15 Apr 2005 22:23:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMceO-0005tM-Tr; Fri, 15 Apr 2005 22:03:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMceM-0005tH-TU for ltru@megatron.ietf.org; Fri, 15 Apr 2005 22:03:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18340 for ; Fri, 15 Apr 2005 22:03:09 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMcof-0008FP-Bb for ltru@ietf.org; Fri, 15 Apr 2005 22:13:50 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Fri, 15 Apr 2005 19:03:00 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Fri, 15 Apr 2005 19:02:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 19:03:01 -0700 Message-ID: Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVCDWa5NeKAUPRuRmO+s/5IibIWsAAGqw+w From: "Peter Constable" To: X-OriginalArrivalTime: 16 Apr 2005 02:03:00.0009 (UTC) FILETIME=[6A564190:01C54228] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Mark Davis > This is a real improvement. But in terms of results, it appears that there > is no real difference in guidance in having the Suppress_Script field, and > having nothing. So it is unclear why the 'Suppress_Script' is needed. This is the most useful field: it is the one that addresses the concern voiced by Ira and others: that we don't get users or application developers going off and thinking that now they should use (say) en-Latn-GB or that the inclusion of Latn in this case has no particular concerns associated with it. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 16 01:45:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03238; Sat, 16 Apr 2005 01:45:11 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMgHZ-00028Y-Mj; Sat, 16 Apr 2005 01:55:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMfu6-0005zX-Sf; Sat, 16 Apr 2005 01:31:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMfu5-0005zK-Pn for ltru@megatron.ietf.org; Sat, 16 Apr 2005 01:31:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02622 for ; Sat, 16 Apr 2005 01:31:36 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMg4N-0001U2-RM for ltru@ietf.org; Sat, 16 Apr 2005 01:42:18 -0400 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.195.12]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3G5VOLg300748 for ; Sat, 16 Apr 2005 01:31:24 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay03.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3G5VOAq230568 for ; Fri, 15 Apr 2005 23:31:24 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3G5VOE8021146 for ; Fri, 15 Apr 2005 23:31:24 -0600 Received: from markdavis (sig-9-48-116-242.mts.ibm.com [9.48.116.242]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3G5VLea021086; Fri, 15 Apr 2005 23:31:23 -0600 Message-ID: <03df01c54245$85acd400$087d3009@sanjose.ibm.com> From: "Mark Davis" To: "Peter Constable" , References: Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Date: Fri, 15 Apr 2005 22:25:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j3G5VOLg300748 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable I'm sorry, I really misworded what I wanted to say, so it must have been very confusing.. In the opening, I meant to say that I don't see the reas= on for the *Require_Script*. If you look below, you see that what I propose is: ...this could be simplified down to one field, Suppress_Script, and two rules. 1. Script subtags listed in the 'Suppress_Script' field SHOULD NOT be use= d to form language tags unless they add specific information to the languag= e tag required by an application. 2. Script subtags not listed in the 'Suppress_Script' field SHOULD always= be used to form language tags when the script used by the content being identified matches the script unless there is a specific reason to omit t= he script subtag in the application. So A. If the Suppress_Script is Latn, then en-Latn becomes en, while en-Cyrl stays as is B. If there is no Suppress_Script (say for zh), then zh-Hant, zh-Hans, zh-Cyrl, (and everything else) stay as is. =E2=80=8EMark ----- Original Message -----=20 From: "Peter Constable" To: Sent: Friday, April 15, 2005 19:03 Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Mark Davis > This is a real improvement. But in terms of results, it appears that there > is no real difference in guidance in having the Suppress_Script field, and > having nothing. So it is unclear why the 'Suppress_Script' is needed. This is the most useful field: it is the one that addresses the concern voiced by Ira and others: that we don't get users or application developers going off and thinking that now they should use (say) en-Latn-GB or that the inclusion of Latn in this case has no particular concerns associated with it. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 16 06:07:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09329; Sat, 16 Apr 2005 06:07:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMkNY-0006Zm-JZ; Sat, 16 Apr 2005 06:18:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMjkp-0004Q5-Eq; Sat, 16 Apr 2005 05:38:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMjkn-0004Pg-2m for ltru@megatron.ietf.org; Sat, 16 Apr 2005 05:38:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07803 for ; Sat, 16 Apr 2005 05:38:14 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMjvA-0005Et-CM for ltru@ietf.org; Sat, 16 Apr 2005 05:49:00 -0400 Received: from lns-p19-8-idf-82-65-69-216.adsl.proxad.net ([82.65.69.216] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DMjkV-000187-K8; Sat, 16 Apr 2005 02:38:00 -0700 Message-Id: <6.1.2.0.2.20050416111756.04ab9e70@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 16 Apr 2005 11:31:29 +0200 To: "Mark Davis" , "Peter Constable" , From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Proposed Text for Moving Forward In-Reply-To: <03df01c54245$85acd400$087d3009@sanjose.ibm.com> References: <03df01c54245$85acd400$087d3009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA07803 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable As a non English speaker I more or less understand the English of=20 "Suppress_Script" because I know its history. I am not sure an occasional= =20 developper will understand/remember the meaning of it. Unneeded, needless= ,=20 redundant_script would be clearer to me. jfc At 07:25 16/04/2005, Mark Davis wrote:understand >I'm sorry, I really misworded what I wanted to say, so it must have been >very confusing.. In the opening, I meant to say that I don't see the rea= son >for the *Require_Script*. >If you look below, you see that what I propose is: > >...this could be simplified down to one >field, Suppress_Script, and two rules. > >1. Script subtags listed in the 'Suppress_Script' field SHOULD NOT be us= ed >to form language tags unless they add specific information to the langua= ge >tag required by an application. > >2. Script subtags not listed in the 'Suppress_Script' field SHOULD alway= s be >used to form language tags when the script used by the content being >identified matches the script unless there is a specific reason to omit = the >script subtag in the application. > > >So >A. If the Suppress_Script is Latn, then en-Latn becomes en, while en-Cyr= l >stays as is >B. If there is no Suppress_Script (say for zh), then zh-Hant, zh-Hans, >zh-Cyrl, (and everything else) stay as is. > > > >=E2=80=8EMark > >----- Original Message ----- >From: "Peter Constable" >To: >Sent: Friday, April 15, 2005 19:03 >Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org= ] >On > > Behalf Of Mark Davis > > > > This is a real improvement. But in terms of results, it appears that >there > > is no real difference in guidance in having the Suppress_Script field= , >and > > having nothing. So it is unclear why the 'Suppress_Script' is needed. > >This is the most useful field: it is the one that addresses the concern >voiced by Ira and others: that we don't get users or application >developers going off and thinking that now they should use (say) >en-Latn-GB or that the inclusion of Latn in this case has no particular >concerns associated with it. > > > >Peter Constable > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru > > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@ietf.org Sat Apr 16 08:39:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20143; Sat, 16 Apr 2005 08:39:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMmkU-0004hC-CE; Sat, 16 Apr 2005 08:50:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMmVD-0000I2-DG; Sat, 16 Apr 2005 08:34:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMmVB-0000Hm-S3 for ltru@megatron.ietf.org; Sat, 16 Apr 2005 08:34:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20002 for ; Sat, 16 Apr 2005 08:34:20 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMmfZ-0004VJ-Mo for ltru@ietf.org; Sat, 16 Apr 2005 08:45:07 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 16 Apr 2005 05:34:11 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sat, 16 Apr 2005 05:34:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Proposed Text for Moving Forward Date: Sat, 16 Apr 2005 05:34:12 -0700 Message-ID: Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVCaAfAkiJRDr7DT6mHC+biM2gUHQAFmXLA From: "Peter Constable" To: X-OriginalArrivalTime: 16 Apr 2005 12:34:10.0949 (UTC) FILETIME=[972D1B50:01C54280] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@ietf.org Errors-To: ltru-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > As a non English speaker I more or less understand the English of > "Suppress_Script" because I know its history. I am not sure an occasional > developper will understand/remember the meaning of it. Unneeded, needless, > redundant_script would be clearer to me. Keep in mind, we do expect someone to have at least glanced at the RFC. But if "Suppress_Script" really doesn't communicate well enough, then what about "Implied_Script" or "Implicit_Script"? A side note: In a paper I wrote three years ago, I had a section entitled "Default values and implicit tagging", discussing specifically the issue of script subtags. I find it interesting that we started with a suggestion of a field called "Default_Script" and have now come around to a suggestion that it be called "Implicit_Script". FYI, here's an excerpt from the end of that section of that paper: The choice of whether or not to adopt the use of implicit default semantics amounts to a trade-off between simpler tags and compatibility with existing implementations on the one hand, and identifiers with more predictable forms, more predictable semantics, and therefore no need to maintain a database of implicit relationships on the other hand. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 16 14:53:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMsQK-0002z1-2u; Sat, 16 Apr 2005 14:53:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMsQJ-0002ys-5w for ltru@megatron.ietf.org; Sat, 16 Apr 2005 14:53:43 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23788 for ; Sat, 16 Apr 2005 14:53:40 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050416185311.IPZZ7277.mta10.adelphia.net@DEWELL> for ; Sat, 16 Apr 2005 14:53:11 -0400 Message-ID: <00a101c542b5$8715e500$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050414190919.MDVD4900.mta8.adelphia.net@megatron.ietf.org> Subject: Re: Off Topic (was Re: [Ltru] Great Script Debate Part II: Formats...) Date: Sat, 16 Apr 2005 11:53:06 -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 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin wrote: > You just may want to consider that: > - there may be some serious political reluctance to "x": it has been > objected with "xn--" as meaning "exclusion" or "xenophobe" or > "christian" > - this is not a real problem for me, but be prepared to the "-x-" to > be forgotten as soon as some one find a way to support it. It's a letter of the alphabet. Most people will cope. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 16 15:17:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMsn7-00073l-Ub; Sat, 16 Apr 2005 15:17:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMsn5-00073A-O5 for ltru@megatron.ietf.org; Sat, 16 Apr 2005 15:17:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27058 for ; Sat, 16 Apr 2005 15:17:11 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMrP1-0007zt-GW for ltru@ietf.org; Sat, 16 Apr 2005 13:48:19 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3GHbLxi023144; Sat, 16 Apr 2005 13:37:22 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 16 Apr 2005 13:37:21 -0400 Date: Sat, 16 Apr 2005 13:37:21 -0400 From: John Cowan To: Randy Presuhn Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Message-ID: <20050416173640.GA21496@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B08DB6A@irvmbxw01.quest.com> <024601c54205$4034d0c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <024601c54205$4034d0c0$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn scripsit: > language L in general is written in script S1 overwhelmingly, > and there is a substantial corpus of data tagged simply "L". > language L has several important variants, V1..Vn > V2, a rather rare variant, uses script S2 overwhelmingly > > If there are cases like this (for example, a hypothetical community > of German speakers using the Hebrew alphabet in a manner similar to > Yiddish, or a community of Yiddish speakers using the latin alphabet) Yiddish is in fact often written in the Latin alphabet nowadays, though the orthography (more than a transcription now, I think) is not associated with any one variety and is in fact deliberately cross-dialectal. The tag yi-Latn was accordingly approved by the Language Tag Reviewer on 2003-01-07, according to Michael's unofficial list at http://www.evertype.com/standards/iso639/iana-lang-assignments.html . Beser a tsebrokhene Yidish vi nisht kayn Yidish. As for Judaeo-German, it was indeed written in the Hebrew alphabet and was much closer to German than today's Yiddish is: it's normally called "Western Yiddish" and is nearly extinct due to the combined efforts of assimilation and extermination. > would there be any need to represent this in the registry? > The tag L-S2-V2 would be preferred to the tag L-V2, right? How would > a developer looking at the registry determine this? By determining that S2 is not a suppressed script for L. Cases are hard to find, however, because the Ethnologue jesuitically defines away the problem by viewing the minority variant as a separate language, which sociolinguistically it generally is. One of the main things preventing Maltese being treated as an Arabic colloquial, or Dzungan as a Mandarin diale, or Italkian (Judaeo-Italian) as just part of the Italo-Romance dialect/language continuum, is precisely the writing system, which has profound effects in separating the minority from the other speakers of the language or language group. (If this posting seems to be about Jewish languages, it's because they constitute a large number of the historical examples of languages written in a script not widely adopted by non-Jewish speakers of what were originally the same languages.) -- John Cowan www.reutershealth.com www.ccil.org/~cowan jcowan@reutershealth.com Shayt oyf ir ale ver nor shklafen / Vas hunger leiden mus in noyt! Der gayst er kokht unruft teu wafen / In shlakht uns firen is er grayt Di velt fun gvaldtaten un laydn / Tzrushteren velen mir, undan Fun freiheit gleikhheit a ganeiden / Bashayen vet der arbetsman! (This may not be quite YIVO-standard; sorry about that.) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 16 15:19:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMsoz-0007t0-Jj; Sat, 16 Apr 2005 15:19:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMsoy-0007sW-5d for ltru@megatron.ietf.org; Sat, 16 Apr 2005 15:19:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28577 for ; Sat, 16 Apr 2005 15:19:08 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMszO-0001gS-Av for ltru@ietf.org; Sat, 16 Apr 2005 15:29:58 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 16 Apr 2005 12:18:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed Text for Moving Forward Date: Sat, 16 Apr 2005 12:18:57 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DC1D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVCaAfAkiJRDr7DT6mHC+biM2gUHQAFmXLAAA6cMQA= From: "Addison Phillips" To: "Peter Constable" , X-OriginalArrivalTime: 16 Apr 2005 19:18:57.0787 (UTC) FILETIME=[23427CB0:01C542B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I dislike "default" because it implies way too many things that aren't = really true about the field. "Implicit" isn't bad, though. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Peter Constable > Sent: samedi 16 avril 2005 05:34 > To: ltru@ietf.org > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward >=20 > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] >=20 > > As a non English speaker I more or less understand the English of > > "Suppress_Script" because I know its history. I am not sure an > occasional > > developper will understand/remember the meaning of it. Unneeded, > needless, > > redundant_script would be clearer to me. >=20 > Keep in mind, we do expect someone to have at least glanced at the = RFC. > But if "Suppress_Script" really doesn't communicate well enough, then > what about "Implied_Script" or "Implicit_Script"? >=20 >=20 > A side note: In a paper I wrote three years ago, I had a section > entitled "Default values and implicit tagging", discussing = specifically > the issue of script subtags. I find it interesting that we started = with > a suggestion of a field called "Default_Script" and have now come = around > to a suggestion that it be called "Implicit_Script". FYI, here's an > excerpt from the end of that section of that paper: >=20 > > The choice of whether or not to adopt the use of implicit default > semantics amounts to a trade-off between simpler tags and = compatibility > with existing implementations on the one hand, and identifiers with = more > predictable forms, more predictable semantics, and therefore no need = to > maintain a database of implicit relationships on the other hand. > >=20 >=20 >=20 > Peter Constable >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 16 15:39:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMt8x-0004yp-JX; Sat, 16 Apr 2005 15:39:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMt8w-0004y8-Dn for ltru@megatron.ietf.org; Sat, 16 Apr 2005 15:39:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02521 for ; Sat, 16 Apr 2005 15:39:46 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMt9c-0004Mi-9w for ltru@ietf.org; Sat, 16 Apr 2005 15:40:32 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sat, 16 Apr 2005 12:29:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Proposed Text for Moving Forward Date: Sat, 16 Apr 2005 12:29:33 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DC1E@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVCRqft/nYyaztESx6FDN3PNKJ34AAcrJWw From: "Addison Phillips" To: "Mark Davis" , "Peter Constable" , X-OriginalArrivalTime: 16 Apr 2005 19:29:34.0069 (UTC) FILETIME=[9E836A50:01C542BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============2129439996==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============2129439996== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBhZ3JlZSwgTWFyaywgdGhhdCB0aGUgZnVsbCBlZmZlY3QgY2FuIGJlIGFjaGlldmVkIHdpdGgg b25seSBvbmUgZmllbGQgYW5kIHRoYXQgeW91ciBwcm9wb3NhbCBpcyBzdXBlcmlvciBpbiBhIG51 bWJlciBvZiByZWdhcmRzIChmZXdlciBtb3ZpbmcgcGFydHMsIGVhc2Ugb2YgbWFpbnRlbmFuY2Us IGVhc2Ugb2YgYXBwbGljYXRpb24pLg0KDQpJIHByb3Bvc2VkIHR3bywgdGhvdWdoLCBmb3IgYSBy ZWFzb24uIE9uZSBvZiB0aGUgb2JqZWN0aW9ucyB3YXMgdGhhdCB3ZSBkaWRuJ3QgZG9jdW1lbnQg d2hlbiBhIHBhcnRpY3VsYXIgc2NyaXB0IHJlYWxseSBvdWdodCB0byBiZSB1c2VkIChpLmUuIHRo YXQgeW91IHJlYWxseSBzaG91bGQgc3RhcnQgdG8gdXNlIHpoLUhhblgtWFggaW4gcHJlZmVyZW5j ZSB0byB6aC1YWCkuIA0KDQpOb3RpY2Ugd2hlcmUgSSBwdXQgdGhlIHN0YWJpbGl0eSBndWFyYW50 ZWU6IG9uIHRoZSByZXF1aXJlZCBzY3JpcHRzLiBTdXBwcmVzc2lvbiBvZiBhIHNjcmlwdCBzdWJ0 YWcgaXMgb25seSBzdGFibGUgYXMgbG9uZyBhcyBhIGxhbmd1YWdlIGlzIG9ubHkga25vd24gdG8g YmUgd3JpdHRlbiBpbiBvbmUgc2NyaXB0IChleGNlcHRpbmcgb2RkaXRpZXMpLiBSZXF1aXJlbWVu dCBvZiBhIHNjcmlwdCBzdWJ0YWcgaG93ZXZlciBjYW4gYmUgc3RhYmxlIChubyBtYXR0ZXIgaG93 IG1hbnkgeW91IGFkZCkuIFNlbGVjdGlvbiBvZiBhIHN1YnRhZywgb25jZSBzZWxlY3RlZCwgc2hv dWxkIGJlIHN0YWJsZS4gVGhlIHN1cHByZXNzIGZpZWxkIGNhbid0IHByb3ZpZGUgdGhhdC4NCg0K VGhlIGZhY3QgdGhhdCB5b3UgY2Fubm90IHR1cm4gdGhlIHJ1bGVzIGFyb3VuZCB1c2luZyB0aGUg cmVxdWlyZWQgc2NyaXB0cyAoeW91IHN0aWxsIGRvbid0IGtub3cgd2hlbiB0byBvbWl0IGEgc2Ny aXB0IHN1YnRhZykgbGVhZCBtZSBpbmV4b3JhYmx5IHRvIHR3byBmaWVsZHMuDQoNCkJ1dCBJJ2Qg YmUganVzdCBhcyBoYXBweSwgaWYgbm90IGhhcHBpZXIsIHdpdGggb25seSBvbmUgb2YgdGhlc2Ug aW5mb3JtYXRpdmUgZmllbGRzLiBUaGUgb25seSBvcHRpb24gZm9yIHRoYXQgaXMgdGhlIHN1cHBy ZXNzIGZpZWxkLg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRp b24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXph dGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEg ZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRy dS1ib3VuY2VzQGxpc3RzLmlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgTWFyayBEYXZpcw0KPiBT ZW50OiB2ZW5kcmVkaSAxNSBhdnJpbCAyMDA1IDIyOjI2DQo+IFRvOiBQZXRlciBDb25zdGFibGU7 IGx0cnVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBSZTogUHJvcG9zZWQgVGV4dCBm b3IgTW92aW5nIEZvcndhcmQNCj4gDQo+IEknbSBzb3JyeSwgSSByZWFsbHkgbWlzd29yZGVkIHdo YXQgSSB3YW50ZWQgdG8gc2F5LCBzbyBpdCBtdXN0IGhhdmUgYmVlbg0KPiB2ZXJ5IGNvbmZ1c2lu Zy4uIEluIHRoZSBvcGVuaW5nLCBJIG1lYW50IHRvIHNheSB0aGF0IEkgZG9uJ3Qgc2VlIHRoZQ0K PiByZWFzb24NCj4gZm9yIHRoZSAqUmVxdWlyZV9TY3JpcHQqLg0KPiBJZiB5b3UgbG9vayBiZWxv dywgeW91IHNlZSB0aGF0IHdoYXQgSSBwcm9wb3NlIGlzOg0KPiANCj4gLi4udGhpcyBjb3VsZCBi ZSBzaW1wbGlmaWVkIGRvd24gdG8gb25lDQo+IGZpZWxkLCBTdXBwcmVzc19TY3JpcHQsIGFuZCB0 d28gcnVsZXMuDQo+IA0KPiAxLiBTY3JpcHQgc3VidGFncyBsaXN0ZWQgaW4gdGhlICdTdXBwcmVz c19TY3JpcHQnIGZpZWxkIFNIT1VMRCBOT1QgYmUgdXNlZA0KPiB0byBmb3JtIGxhbmd1YWdlIHRh Z3MgdW5sZXNzIHRoZXkgYWRkIHNwZWNpZmljIGluZm9ybWF0aW9uIHRvIHRoZSBsYW5ndWFnZQ0K PiB0YWcgcmVxdWlyZWQgYnkgYW4gYXBwbGljYXRpb24uDQo+IA0KPiAyLiBTY3JpcHQgc3VidGFn cyBub3QgbGlzdGVkIGluIHRoZSAnU3VwcHJlc3NfU2NyaXB0JyBmaWVsZCBTSE9VTEQgYWx3YXlz DQo+IGJlDQo+IHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzIHdoZW4gdGhlIHNjcmlwdCB1c2Vk IGJ5IHRoZSBjb250ZW50IGJlaW5nDQo+IGlkZW50aWZpZWQgbWF0Y2hlcyB0aGUgc2NyaXB0IHVu bGVzcyB0aGVyZSBpcyBhIHNwZWNpZmljIHJlYXNvbiB0byBvbWl0DQo+IHRoZQ0KPiBzY3JpcHQg c3VidGFnIGluIHRoZSBhcHBsaWNhdGlvbi4NCj4gDQo+IA0KPiBTbw0KPiBBLiBJZiB0aGUgU3Vw cHJlc3NfU2NyaXB0IGlzIExhdG4sIHRoZW4gZW4tTGF0biBiZWNvbWVzIGVuLCB3aGlsZSBlbi1D eXJsDQo+IHN0YXlzIGFzIGlzDQo+IEIuIElmIHRoZXJlIGlzIG5vIFN1cHByZXNzX1NjcmlwdCAo c2F5IGZvciB6aCksIHRoZW4gemgtSGFudCwgemgtSGFucywNCj4gemgtQ3lybCwgKGFuZCBldmVy eXRoaW5nIGVsc2UpIHN0YXkgYXMgaXMuDQo+IA0KPiANCj4gDQo+IOKAjk1hcmsNCj4gDQo+IC0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogIlBldGVyIENvbnN0YWJsZSIgPHBl dGVyY29uQG1pY3Jvc29mdC5jb20+DQo+IFRvOiA8bHRydUBpZXRmLm9yZz4NCj4gU2VudDogRnJp ZGF5LCBBcHJpbCAxNSwgMjAwNSAxOTowMw0KPiBTdWJqZWN0OiBSRTogW0x0cnVdIFJlOiBQcm9w b3NlZCBUZXh0IGZvciBNb3ZpbmcgRm9yd2FyZA0KPiANCj4gDQo+ID4gRnJvbTogbHRydS1ib3Vu Y2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnXQ0K PiBPbg0KPiA+IEJlaGFsZiBPZiBNYXJrIERhdmlzDQo+IA0KPiANCj4gPiBUaGlzIGlzIGEgcmVh bCBpbXByb3ZlbWVudC4gQnV0IGluIHRlcm1zIG9mIHJlc3VsdHMsIGl0IGFwcGVhcnMgdGhhdA0K PiB0aGVyZQ0KPiA+IGlzIG5vIHJlYWwgZGlmZmVyZW5jZSBpbiBndWlkYW5jZSBpbiBoYXZpbmcg dGhlIFN1cHByZXNzX1NjcmlwdCBmaWVsZCwNCj4gYW5kDQo+ID4gaGF2aW5nIG5vdGhpbmcuIFNv IGl0IGlzIHVuY2xlYXIgd2h5IHRoZSAnU3VwcHJlc3NfU2NyaXB0JyBpcyBuZWVkZWQuDQo+IA0K PiBUaGlzIGlzIHRoZSBtb3N0IHVzZWZ1bCBmaWVsZDogaXQgaXMgdGhlIG9uZSB0aGF0IGFkZHJl c3NlcyB0aGUgY29uY2Vybg0KPiB2b2ljZWQgYnkgSXJhIGFuZCBvdGhlcnM6IHRoYXQgd2UgZG9u J3QgZ2V0IHVzZXJzIG9yIGFwcGxpY2F0aW9uDQo+IGRldmVsb3BlcnMgZ29pbmcgb2ZmIGFuZCB0 aGlua2luZyB0aGF0IG5vdyB0aGV5IHNob3VsZCB1c2UgKHNheSkNCj4gZW4tTGF0bi1HQiBvciB0 aGF0IHRoZSBpbmNsdXNpb24gb2YgTGF0biBpbiB0aGlzIGNhc2UgaGFzIG5vIHBhcnRpY3VsYXIN Cj4gY29uY2VybnMgYXNzb2NpYXRlZCB3aXRoIGl0Lg0KPiANCj4gDQo+IA0KPiBQZXRlciBDb25z dGFibGUNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+IGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCj4gDQo+IA0KPiANCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0 cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQo= --===============2129439996== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============2129439996==-- From ltru-bounces@lists.ietf.org Sat Apr 16 17:08:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMuXA-0002fX-Sq; Sat, 16 Apr 2005 17:08:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMuX8-0002ez-MX for ltru@megatron.ietf.org; Sat, 16 Apr 2005 17:08:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09609 for ; Sat, 16 Apr 2005 17:08:51 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMuha-0008G7-B1 for ltru@ietf.org; Sat, 16 Apr 2005 17:19:44 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3GL8TmS013309; Sat, 16 Apr 2005 14:08:33 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3A2S1X>; Sat, 16 Apr 2005 14:08:30 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Peter Constable , ltru@ietf.org Subject: RE: [Ltru] Re: Proposed Text for Moving Forward Date: Sat, 16 Apr 2005 14:08:28 -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: 287c806b254c6353fcb09ee0e53bbc5e Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, "Implicit" is not very clear - it's capable of being misread as "Default" (meaningless) and is not a verb like "Suppress" - it sure doesn't indicate Suppress in plain English. By the way, IETF standards do often use the construction MUST NOT followed by one or more exceptions. So a stronger rewrite of the Mark's two rule set would be: 1. Script subtags listed in the 'Suppress_Script' field MUST NOT be used to form language tags unless they add specific information to the language tag required by an application, to improve language tag matching for legacy content. 2. Script subtags not listed in the 'Suppress_Script' field SHOULD always be used to form language tags when the script used by the content being identified matches the script unless there is a specific reason to omit the script subtag in the application. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Saturday, April 16, 2005 3:19 PM > To: Peter Constable; ltru@ietf.org > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > I dislike "default" because it implies way too many things > that aren't really true about the field. "Implicit" isn't bad, though. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Peter Constable > > Sent: samedi 16 avril 2005 05:34 > > To: ltru@ietf.org > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > > > > As a non English speaker I more or less understand the English of > > > "Suppress_Script" because I know its history. I am not sure an > > occasional > > > developper will understand/remember the meaning of it. Unneeded, > > needless, > > > redundant_script would be clearer to me. > > > > Keep in mind, we do expect someone to have at least glanced > at the RFC. > > But if "Suppress_Script" really doesn't communicate well > enough, then > > what about "Implied_Script" or "Implicit_Script"? > > > > > > A side note: In a paper I wrote three years ago, I had a section > > entitled "Default values and implicit tagging", discussing > specifically > > the issue of script subtags. I find it interesting that we > started with > > a suggestion of a field called "Default_Script" and have > now come around > > to a suggestion that it be called "Implicit_Script". FYI, here's an > > excerpt from the end of that section of that paper: > > > > > > The choice of whether or not to adopt the use of implicit default > > semantics amounts to a trade-off between simpler tags and > compatibility > > with existing implementations on the one hand, and > identifiers with more > > predictable forms, more predictable semantics, and > therefore no need to > > maintain a database of implicit relationships on the other hand. > > > > > > > > > > Peter Constable > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 16 17:48:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMv9a-00080z-J6; Sat, 16 Apr 2005 17:48:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMv9Y-0007zw-8w for ltru@megatron.ietf.org; Sat, 16 Apr 2005 17:48:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12604 for ; Sat, 16 Apr 2005 17:48:33 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMvK1-0000XY-5k for ltru@ietf.org; Sat, 16 Apr 2005 17:59:26 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3GLmJ4I013266 for ; Sat, 16 Apr 2005 17:48:19 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3GLmIdo338990 for ; Sat, 16 Apr 2005 15:48:18 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3GLmI8W024305 for ; Sat, 16 Apr 2005 15:48:18 -0600 Received: from markdavis (sig-9-48-122-70.mts.ibm.com [9.48.122.70]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3GLmHG0024300; Sat, 16 Apr 2005 15:48:18 -0600 Message-ID: <005601c542cd$fef22c60$467a3009@sanjose.ibm.com> From: "Mark Davis" To: "McDonald, Ira" , "'Addison Phillips'" , "Peter Constable" , References: Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Date: Sat, 16 Apr 2005 14:48:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j3GLmJ4I013266 X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I'm ok with MUST NOT, if the exception is clearly stated (and it is not j= ust legacy that is at issue). For parallelism with #2, they could be: 1. Script subtags listed in the 'Suppress_Script' field MUST NOT be used to form language tags unless there is a specific reason to include the script subtag in the application. 2. Script subtags not listed in the 'Suppress_Script' field SHOULD always be used to form language tags when they match the script used by the cont= ent unless there is a specific reason to omit the script subtag in the application. =E2=80=8EMark ----- Original Message -----=20 From: "McDonald, Ira" To: "'Addison Phillips'" ; "Peter Constable" ; Sent: Saturday, April 16, 2005 14:08 Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > Hi, > > "Implicit" is not very clear - it's capable of being misread as > "Default" (meaningless) and is not a verb like "Suppress" - it sure > doesn't indicate Suppress in plain English. > > By the way, IETF standards do often use the construction MUST NOT > followed by one or more exceptions. So a stronger rewrite of the > Mark's two rule set would be: > > 1. Script subtags listed in the 'Suppress_Script' field MUST NOT be use= d > to form language tags unless they add specific information to the langu= age > tag required by an application, to improve language tag matching for legacy > content. > > 2. Script subtags not listed in the 'Suppress_Script' field SHOULD alwa= ys > be used to form language tags when the script used by the content being > identified matches the script unless there is a specific reason to omit > the script subtag in the application. > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of Addison Phillips > > Sent: Saturday, April 16, 2005 3:19 PM > > To: Peter Constable; ltru@ietf.org > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > > > > I dislike "default" because it implies way too many things > > that aren't really true about the field. "Implicit" isn't bad, though. > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] On > > > Behalf Of Peter Constable > > > Sent: samedi 16 avril 2005 05:34 > > > To: ltru@ietf.org > > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > > > > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > > > > > > As a non English speaker I more or less understand the English of > > > > "Suppress_Script" because I know its history. I am not sure an > > > occasional > > > > developper will understand/remember the meaning of it. Unneeded, > > > needless, > > > > redundant_script would be clearer to me. > > > > > > Keep in mind, we do expect someone to have at least glanced > > at the RFC. > > > But if "Suppress_Script" really doesn't communicate well > > enough, then > > > what about "Implied_Script" or "Implicit_Script"? > > > > > > > > > A side note: In a paper I wrote three years ago, I had a section > > > entitled "Default values and implicit tagging", discussing > > specifically > > > the issue of script subtags. I find it interesting that we > > started with > > > a suggestion of a field called "Default_Script" and have > > now come around > > > to a suggestion that it be called "Implicit_Script". FYI, here's an > > > excerpt from the end of that section of that paper: > > > > > > > > > The choice of whether or not to adopt the use of implicit default > > > semantics amounts to a trade-off between simpler tags and > > compatibility > > > with existing implementations on the one hand, and > > identifiers with more > > > predictable forms, more predictable semantics, and > > therefore no need to > > > maintain a database of implicit relationships on the other hand. > > > > > > > > > > > > > > > Peter Constable > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 16 17:53:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMvEL-0000HC-Vd; Sat, 16 Apr 2005 17:53:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMvEL-0000Gu-1f for ltru@megatron.ietf.org; Sat, 16 Apr 2005 17:53:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12796 for ; Sat, 16 Apr 2005 17:53:29 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMvOo-0000do-L9 for ltru@ietf.org; Sat, 16 Apr 2005 18:04:22 -0400 Received: from lns-p19-8-idf-82-65-69-216.adsl.proxad.net ([82.65.69.216] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DMvEI-0007Ww-R5; Sat, 16 Apr 2005 14:53:31 -0700 Message-Id: <6.1.2.0.2.20050416173457.041f3990@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 16 Apr 2005 23:53:27 +0200 To: "Peter Constable" , From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Proposed Text for Moving Forward In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I agree about the RFC. But there are 4000 of them a developer should know. Usually first implementations are discussed by people having read many of them and keeping sometimes confused memories. This explains most of the existing variations in codes. So, I have nothing against nothing. But what is clear should preferable be clearly described to be clearly understood by the proper person. From what I gather, we agreed that "default" was not the proper idea, because if there was nothing, there was no script. Implicit convey the correct idea. However from what I also gather, we want to teach developers not to use the script in that case. As a developer I understand "implicit" as something which is here if it is here, but there is no harm in adding anew (by security). I understand "redundant" as something which creates a waste of cpu resources, confusion or may be even, security leak. So I am more careful. But I also understand that someone registering a tag may see it otherwise. "implicit" is then more neutral, working for both. It is also shorter. jfc At 14:34 16/04/2005, Peter Constable wrote: > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > > As a non English speaker I more or less understand the English of > > "Suppress_Script" because I know its history. I am not sure an >occasional > > developper will understand/remember the meaning of it. Unneeded, >needless, > > redundant_script would be clearer to me. > >Keep in mind, we do expect someone to have at least glanced at the RFC. >But if "Suppress_Script" really doesn't communicate well enough, then >what about "Implied_Script" or "Implicit_Script"? > > >A side note: In a paper I wrote three years ago, I had a section >entitled "Default values and implicit tagging", discussing specifically >the issue of script subtags. I find it interesting that we started with >a suggestion of a field called "Default_Script" and have now come around >to a suggestion that it be called "Implicit_Script". FYI, here's an >excerpt from the end of that section of that paper: > > >The choice of whether or not to adopt the use of implicit default >semantics amounts to a trade-off between simpler tags and compatibility >with existing implementations on the one hand, and identifiers with more >predictable forms, more predictable semantics, and therefore no need to >maintain a database of implicit relationships on the other hand. > > > > >Peter Constable > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 16 19:13:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMwTN-00024t-OE; Sat, 16 Apr 2005 19:13:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMwTK-00023u-Ll for ltru@megatron.ietf.org; Sat, 16 Apr 2005 19:13:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17250 for ; Sat, 16 Apr 2005 19:13:02 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMwdk-00034L-1I for ltru@ietf.org; Sat, 16 Apr 2005 19:23:56 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3GNCZ1E023694; Sat, 16 Apr 2005 16:12:39 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3A2S62>; Sat, 16 Apr 2005 16:12:36 -0700 Message-ID: From: "McDonald, Ira" To: "'Mark Davis'" , "McDonald, Ira" , "'Addison Phillips'" , Peter Constable , ltru@ietf.org Subject: RE: [Ltru] Re: Proposed Text for Moving Forward Date: Sat, 16 Apr 2005 16:12:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Mark, I know that legacy's not the only problem, but it happens to be _the_ issue on which Kurt, Ned, and I have expressed concerns and deserves to be included in the rule set, e.g., 1. Script subtags listed in the 'Suppress_Script' field MUST NOT be = used to form language tags unless there is a specific reason to include the script subtag in the application. =20 ... Rationale: Rule 1 is designed to improve language tag matching by applications using the RFR (remove from right) algorithm that is=20 common among legacy applications. I dislike the standards style that says "don't state the rationale=20 - just be terse". Nothing is gained. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: Mark Davis [mailto:mark.davis@jtcsv.com] > Sent: Saturday, April 16, 2005 5:48 PM > To: McDonald, Ira; 'Addison Phillips'; Peter Constable; ltru@ietf.org > Subject: Re: [Ltru] Re: Proposed Text for Moving Forward >=20 >=20 > I'm ok with MUST NOT, if the exception is clearly stated (and=20 > it is not just > legacy that is at issue). For parallelism with #2, they could be: >=20 > 1. Script subtags listed in the 'Suppress_Script' field MUST=20 > NOT be used > to form language tags unless there is a specific reason to include > the script subtag in the application. >=20 > 2. Script subtags not listed in the 'Suppress_Script' field=20 > SHOULD always > be used to form language tags when they match the script used=20 > by the content > unless there is a specific reason to omit the script subtag in the > application. >=20 > =E2=80=8EMark >=20 > ----- Original Message -----=20 > From: "McDonald, Ira" > To: "'Addison Phillips'" ; "Peter=20 > Constable" > ; > Sent: Saturday, April 16, 2005 14:08 > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward >=20 >=20 > > Hi, > > > > "Implicit" is not very clear - it's capable of being misread as > > "Default" (meaningless) and is not a verb like "Suppress" - it sure > > doesn't indicate Suppress in plain English. > > > > By the way, IETF standards do often use the construction MUST NOT > > followed by one or more exceptions. So a stronger rewrite of the > > Mark's two rule set would be: > > > > 1. Script subtags listed in the 'Suppress_Script' field=20 > MUST NOT be used > > to form language tags unless they add specific information=20 > to the language > > tag required by an application, to improve language tag matching = for > legacy > > content. > > > > 2. Script subtags not listed in the 'Suppress_Script' field=20 > SHOULD always > > be used to form language tags when the script used by the=20 > content being > > identified matches the script unless there is a specific=20 > reason to omit > > the script subtag in the application. > > > > Cheers, > > - Ira > > > > Ira McDonald (Musician / Software Architect) > > Blue Roof Music / High North Inc > > PO Box 221 Grand Marais, MI 49839 > > phone: +1-906-494-2434 > > email: imcdonald@sharplabs.com > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > > > [mailto:ltru-bounces@lists.ietf.org]On > > > Behalf Of Addison Phillips > > > Sent: Saturday, April 16, 2005 3:19 PM > > > To: Peter Constable; ltru@ietf.org > > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > > > > > > > I dislike "default" because it implies way too many things > > > that aren't really true about the field. "Implicit" isn't=20 > bad, though. > > > > > > Addison > > > > > > Addison P. Phillips > > > Globalization Architect, Quest Software > > > Chair, W3C Internationalization Core Working Group > > > > > > Internationalization is not a feature. > > > It is an architecture. > > > > > > > -----Original Message----- > > > > From: ltru-bounces@lists.ietf.org > > > [mailto:ltru-bounces@lists.ietf.org] On > > > > Behalf Of Peter Constable > > > > Sent: samedi 16 avril 2005 05:34 > > > > To: ltru@ietf.org > > > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > > > > > > > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > > > > > > > > > As a non English speaker I more or less understand=20 > the English of > > > > > "Suppress_Script" because I know its history. I am not sure = an > > > > occasional > > > > > developper will understand/remember the meaning of=20 > it. Unneeded, > > > > needless, > > > > > redundant_script would be clearer to me. > > > > > > > > Keep in mind, we do expect someone to have at least glanced > > > at the RFC. > > > > But if "Suppress_Script" really doesn't communicate well > > > enough, then > > > > what about "Implied_Script" or "Implicit_Script"? > > > > > > > > > > > > A side note: In a paper I wrote three years ago, I had a = section > > > > entitled "Default values and implicit tagging", discussing > > > specifically > > > > the issue of script subtags. I find it interesting that we > > > started with > > > > a suggestion of a field called "Default_Script" and have > > > now come around > > > > to a suggestion that it be called "Implicit_Script".=20 > FYI, here's an > > > > excerpt from the end of that section of that paper: > > > > > > > > > > > > The choice of whether or not to adopt the use of=20 > implicit default > > > > semantics amounts to a trade-off between simpler tags and > > > compatibility > > > > with existing implementations on the one hand, and > > > identifiers with more > > > > predictable forms, more predictable semantics, and > > > therefore no need to > > > > maintain a database of implicit relationships on the other = hand. > > > > > > > > > > > > > > > > > > > > Peter Constable > > > > > > > > _______________________________________________ > > > > Ltru mailing list > > > > Ltru@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > >=20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 16 19:30:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMwjv-0004Vs-90; Sat, 16 Apr 2005 19:30:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMwjt-0004VQ-GQ for ltru@megatron.ietf.org; Sat, 16 Apr 2005 19:30:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17998 for ; Sat, 16 Apr 2005 19:30:09 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMwuN-0003Wi-5s for ltru@ietf.org; Sat, 16 Apr 2005 19:41:04 -0400 Received: from h-68-165-3-75.snvacaid.dynamic.covad.net ([68.165.3.75] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DMwjk-0006Y9-00 for ltru@ietf.org; Sat, 16 Apr 2005 16:30:04 -0700 Message-ID: <000401c542dc$70f267e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Date: Sat, 16 Apr 2005 16:31:39 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "McDonald, Ira" > To: "'Mark Davis'" ; "McDonald, Ira" ; "'Addison Phillips'" ; "Peter Constable" ; > Sent: Saturday, April 16, 2005 4:12 PM > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward ... > Rationale: Rule 1 is designed to improve language tag matching by > applications using the RFR (remove from right) algorithm that is > common among legacy applications. ... As co-chair, I'm all for including rationale in the specification when it helps us gain consensus or results in a clearer specification. As a technical contributor, I think that in this particular case the potential for harm makes it essential to explain why violating rule 1 is generally a bad idea, even though we haven't been able to make the prohibition absolute. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 16 22:13:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMzGd-0002r1-Vq; Sat, 16 Apr 2005 22:12:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMzGc-0002qY-52 for ltru@megatron.ietf.org; Sat, 16 Apr 2005 22:12:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25883 for ; Sat, 16 Apr 2005 22:12:05 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMzR5-0000et-CO for ltru@ietf.org; Sat, 16 Apr 2005 22:23:00 -0400 Received: from lns-p19-19-idf-82-249-4-172.adsl.proxad.net ([82.249.4.172] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DMzGW-0000HD-KZ for ltru@ietf.org; Sat, 16 Apr 2005 19:12:06 -0700 Message-Id: <6.1.2.0.2.20050417040701.04197390@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 17 Apr 2005 04:07:24 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Proposed Text for Moving Forward In-Reply-To: <000401c542dc$70f267e0$7f1afea9@oemcomputer> References: <000401c542dc$70f267e0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org +1 On 01:31 17/04/2005, Randy Presuhn said: >Hi - > > From: "McDonald, Ira" > > To: > > Sent: Saturday, April 16, 2005 4:12 PM > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward >... > > Rationale: Rule 1 is designed to improve language tag matching by > > applications using the RFR (remove from right) algorithm that is > > common among legacy applications. >... > >As co-chair, I'm all for including rationale in the specification when it >helps >us gain consensus or results in a clearer specification. As a technical >contributor, >I think that in this particular case the potential for harm makes it essential >to explain why violating rule 1 is generally a bad idea, even though we >haven't >been able to make the prohibition absolute. > >Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 02:15:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DN33w-0001U5-Bt; Sun, 17 Apr 2005 02:15:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DN33n-0001ST-Bs for ltru@megatron.ietf.org; Sun, 17 Apr 2005 02:15:11 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20031 for ; Sun, 17 Apr 2005 02:15:09 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050417061439.VWOE4618.mta13.adelphia.net@DEWELL> for ; Sun, 17 Apr 2005 02:14:39 -0400 Message-ID: <00c601c54314$b3bad520$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050415015651.XVTS5424.mta6.adelphia.net@megatron.ietf.org> Date: Sat, 16 Apr 2005 23:14:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: registry should copy non-English fields from ISO documents X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > If you want a dictionary of language / script / region names > just create it. IMHO it's unnecessary, dictionaries already > exist. Here are two utter dubious Google translations: > > http://purl.net/net/en2fr/users.adelphia.net/~dewell/lstreg.html > http://purl.net/net/en2de/users.adelphia.net/~dewell/lstreg.html Dubious is the word, all right. I especially like the way the subtags themselves were translated, so that 'av' for Avaric became "poids du commerce" in French, and 'bm' for Bambara became "Schwerpunktshandbuch" in German. Thankfully, the Google translator limited its own damage by giving up after the first ~400 translations. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 02:27:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DN3FH-0003jS-8L; Sun, 17 Apr 2005 02:27:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DN3F9-0003ij-PH for ltru@megatron.ietf.org; Sun, 17 Apr 2005 02:26:56 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26767 for ; Sun, 17 Apr 2005 02:26:54 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050417062624.PZY2192.mta9.adelphia.net@DEWELL> for ; Sun, 17 Apr 2005 02:26:24 -0400 Message-ID: <00cb01c54316$5900e6e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050415112258.QWYS2132.mta5.adelphia.net@megatron.ietf.org> Subject: Re: Off Topic (was Re: [Ltru] Great Script Debate Part II: Formats...) Date: Sat, 16 Apr 2005 23:26:09 -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 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org L.Gillam wrote: > Besides, if you've read the current draft, you'll realise that other > singletons are proposed also, syntax-wise. I'm sure it wouldn't > require a major quantum theoretical shift to assign a different > singleton to enable extension subtag use by those with serious > political reluctance to the letter x in tags. Doug? Of course, you'd > need to find a letter which was politically acceptable in the process. Section 3.4 of draft-00, "Extensions and Extensions Namespace" (renumbered as Section 3.6 in draft-01) is very clear on the process for creating extensions. I'm not sure whether the author of the extension RFC would typically request a particular singleton, or whether IANA would just assign one pseudo-randomly. I'm guessing it would be the former, but I can't see where it is stated. In any case, an extension obviously couldn't be associated with the letter X, since that is reserved for private-use subtags, so those who feel particular fear and loathing over the letter X might prefer this approach. However, the stability requirements for extension RFCs might make that mechanism unsuitable for inherently open-ended sets like "referent," whereas the whole point of private-use subtags is that they are semantically unregulated. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 04:06:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DN4nL-0005O5-Pf; Sun, 17 Apr 2005 04:06:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DN4nC-0005NO-JL for ltru@megatron.ietf.org; Sun, 17 Apr 2005 04:06:10 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01698 for ; Sun, 17 Apr 2005 04:06:08 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050417080539.LPWH5402.mta11.adelphia.net@DEWELL> for ; Sun, 17 Apr 2005 04:05:39 -0400 Message-ID: <00d201c54324$350179e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050416214852.QWXX4543.mta4.adelphia.net@megatron.ietf.org> Date: Sun, 17 Apr 2005 01:05:21 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Proposed Text for Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > I agree, Mark, that the full effect can be achieved with only one > field and that your proposal is superior in a number of regards (fewer > moving parts, ease of maintenance, ease of application). > > I proposed two, though, for a reason. One of the objections was that > we didn't document when a particular script really ought to be used > (i.e. that you really should start to use zh-HanX-XX in preference to > zh-XX). I know I said I would back off and not get involved in the default-script issue. OK, so I lied. Sorry about that. AFAICT, this whole issue started with the concern that people would use a script subtag in cases where it was generally thought to be (a) unnecessary, because the intended script would be obvious, and (b) undesirable, because it would interfere with left-prefix (RFR) matching. The standard example was "en-Latn-US." The case was made that the overwhelming majority of written U.S. English text is written in the Latin script, so the added flexibility of being able to specify the script would be largely unnecessary, and in particular it would be overshadowed by the inability of existing left-prefix matching algorithms to match "en-Latn-US" with "en-US" (sometimes generalized to "broken backward compatibility"). This was the foundation of "default script": certain languages like English could be listed as having a default script of Latin, so that tag generators could avoid creating tags like "en-Latn" or "en-Latn-US" whose disadvantages would outweigh their advantages. Of course, in certain circumstances you might have English written in Braille, or even in Cyrillic, and most if not all seemed to agree that in these rare circumstances it would be acceptable to generate "en-Brai-whatever" or "en-Cyrl-whatever." The standard counterexamples were "zh-Hans" and "zh-Hant." The case was made that Chinese is commonly written in both of these script variants, and it would often be beneficial to include script information, to the point of perhaps being more important than strict compatibility with left-prefix matching algorithms. Languages like Chinese and Azerbaijani and Serbian, after all, were the major use cases for the introduction of script subtags in the first place. So unlike "en-Latn", it would not be discouraged to write "zh-Hans" or "zh-Hant", or either of these followed by a region subtag. Of course, just like English, Chinese could also be written in a less obvious script like Braille or Cyrillic, and so "zh-Brai" and "zh-Cyrl" ought to be allowed as well. I concede that because of the stated predominance of processes that use left-prefix matching, it might be beneficial to define a default script for common languages that are written in a single script 99.9% of the time. I still don't know where the authority comes from to decide which languages and which scripts get marked in this way -- definitely not from ISO or documented registrations or deterministic rules, like everything else in the registry -- but I assume that would be worked out in due course. What I do NOT understand is how this has expanded to telling people when they SHOULD use script subtags, and how the set of allowable subtags should be limited in some way. There may well be cases where "zh" or "zh-CN' or "zh-TW" is all that is needed, and there is certainly existing data that uses such tags. I don't see any justification for discouraging such usage, even if we have defined a way to tag Chinese data more precisely. Likewise, if there is no prohibition against writing "en-Brai" or "en-Cyrl", then I see no reason to prohibit or discourage "zh-Brai" or "zh-Cyrl" either. A "required-script" field would do exactly this, by listing 'Hans' and 'Hant' but not others. This is too prescriptive. It tells people how they SHOULD tag data, not just in terms of "tag content wisely" or "don't be excessively precise," but on a specific language-by-language basis. It assumes, implicitly, that this group or ietf-languages has the expertise and authority to make this judgment. Unlike default-script, required-script does nothing to solve the left-prefix matching problem, and as such, I don't think it's within the scope of the charter. I propose the following: 1. An optional, informative default-script field that would suggest to tag generators that they not use that particular script subtag together with that particular language subtag. This field could be added, changed, or removed at any time. (It doesn't matter much what the field is called, and I renew my suggestion that we not try to inject too much deep meaning into the names of fields, or assume that users will derive deep meaning from them.) 2. NO requirement within the draft that tag generators "must not" use script subtags in any given scenario. The text in draft-01 that discourages the use of a script subtag "unless it conveys additional information" should be adequate. 3. NO mechanism to tell tag generators that they "should" use a script subtag together with any particular language subtag, and *especially* not one that lists the "expected" script subtags while excluding others. If tag generators opt to create a tag such as "zh-TW" that "may be ambiguous without script information," that should be up to them. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 11:54:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNC6l-0007k7-NM; Sun, 17 Apr 2005 11:54:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNC6j-0007jc-Tr for ltru@megatron.ietf.org; Sun, 17 Apr 2005 11:54:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01522 for ; Sun, 17 Apr 2005 11:54:46 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNCHN-0001Ii-3P for ltru@ietf.org; Sun, 17 Apr 2005 12:05:49 -0400 Received: from lns-p19-19-idf-82-249-4-172.adsl.proxad.net ([82.249.4.172] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DNC6a-000411-MV; Sun, 17 Apr 2005 08:54:41 -0700 Message-Id: <6.1.2.0.2.20050417140533.042117c0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 17 Apr 2005 17:54:36 +0200 To: "Doug Ewell" , "LTRU Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Proposed Text for Moving Forward In-Reply-To: <00d201c54324$350179e0$030aa8c0@DEWELL> References: <20050416214852.QWXX4543.mta4.adelphia.net@megatron.ietf.org> <00d201c54324$350179e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I am embarassed: I just started testing that I only need to support a point to rise a clever opposition. I will however note that this seem to confirm that all this discussion results from a conflict between trying to document general semantic rules (provide information on script, language, region, referent and style) and wanting to adapt them to the legacy of several particular applications. I understand these past-centric motivations, but they should not be our leading ones. I can only repeat my proposition which is to word the Draft as a framework for specific solutions, documenting by yearly RFCs the content of the core Registries, and to jointly address - on a case per case (application per application) basis - the format/filtering issues using these Registries in an ad-hoc maner - including some online IANA services when needed. jfc At 10:05 17/04/2005, Doug Ewell wrote: >Addison Phillips wrote: > > > I agree, Mark, that the full effect can be achieved with only one > > field and that your proposal is superior in a number of regards (fewer > > moving parts, ease of maintenance, ease of application). > > > > I proposed two, though, for a reason. One of the objections was that > > we didn't document when a particular script really ought to be used > > (i.e. that you really should start to use zh-HanX-XX in preference to > > zh-XX). > >I know I said I would back off and not get involved in the >default-script issue. OK, so I lied. Sorry about that. > >AFAICT, this whole issue started with the concern that people would use >a script subtag in cases where it was generally thought to be (a) >unnecessary, because the intended script would be obvious, and (b) >undesirable, because it would interfere with left-prefix (RFR) matching. > >The standard example was "en-Latn-US." The case was made that the >overwhelming majority of written U.S. English text is written in the >Latin script, so the added flexibility of being able to specify the >script would be largely unnecessary, and in particular it would be >overshadowed by the inability of existing left-prefix matching >algorithms to match "en-Latn-US" with "en-US" (sometimes generalized to >"broken backward compatibility"). > >This was the foundation of "default script": certain languages like >English could be listed as having a default script of Latin, so that tag >generators could avoid creating tags like "en-Latn" or "en-Latn-US" >whose disadvantages would outweigh their advantages. > >Of course, in certain circumstances you might have English written in >Braille, or even in Cyrillic, and most if not all seemed to agree that >in these rare circumstances it would be acceptable to generate >"en-Brai-whatever" or "en-Cyrl-whatever." > >The standard counterexamples were "zh-Hans" and "zh-Hant." The case was >made that Chinese is commonly written in both of these script variants, >and it would often be beneficial to include script information, to the >point of perhaps being more important than strict compatibility with >left-prefix matching algorithms. Languages like Chinese and Azerbaijani >and Serbian, after all, were the major use cases for the introduction of >script subtags in the first place. > >So unlike "en-Latn", it would not be discouraged to write "zh-Hans" or >"zh-Hant", or either of these followed by a region subtag. Of course, >just like English, Chinese could also be written in a less obvious >script like Braille or Cyrillic, and so "zh-Brai" and "zh-Cyrl" ought to >be allowed as well. > >I concede that because of the stated predominance of processes that use >left-prefix matching, it might be beneficial to define a default script >for common languages that are written in a single script 99.9% of the >time. I still don't know where the authority comes from to decide which >languages and which scripts get marked in this way -- definitely not >from ISO or documented registrations or deterministic rules, like >everything else in the registry -- but I assume that would be worked out >in due course. > >What I do NOT understand is how this has expanded to telling people when >they SHOULD use script subtags, and how the set of allowable subtags >should be limited in some way. > >There may well be cases where "zh" or "zh-CN' or "zh-TW" is all that is >needed, and there is certainly existing data that uses such tags. I >don't see any justification for discouraging such usage, even if we have >defined a way to tag Chinese data more precisely. Likewise, if there is >no prohibition against writing "en-Brai" or "en-Cyrl", then I see no >reason to prohibit or discourage "zh-Brai" or "zh-Cyrl" either. A >"required-script" field would do exactly this, by listing 'Hans' and >'Hant' but not others. > >This is too prescriptive. It tells people how they SHOULD tag data, not >just in terms of "tag content wisely" or "don't be excessively precise," >but on a specific language-by-language basis. It assumes, implicitly, >that this group or ietf-languages has the expertise and authority to >make this judgment. Unlike default-script, required-script does nothing >to solve the left-prefix matching problem, and as such, I don't think >it's within the scope of the charter. > >I propose the following: > >1. An optional, informative default-script field that would suggest to >tag generators that they not use that particular script subtag together >with that particular language subtag. This field could be added, >changed, or removed at any time. (It doesn't matter much what the field >is called, and I renew my suggestion that we not try to inject too much >deep meaning into the names of fields, or assume that users will derive >deep meaning from them.) > >2. NO requirement within the draft that tag generators "must not" use >script subtags in any given scenario. The text in draft-01 that >discourages the use of a script subtag "unless it conveys additional >information" should be adequate. > >3. NO mechanism to tell tag generators that they "should" use a script >subtag together with any particular language subtag, and *especially* >not one that lists the "expected" script subtags while excluding others. >If tag generators opt to create a tag such as "zh-TW" that "may be >ambiguous without script information," that should be up to them. > >-Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 15:07:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNF7T-0006Sg-5U; Sun, 17 Apr 2005 15:07:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNF7R-0006Sb-Dc for ltru@megatron.ietf.org; Sun, 17 Apr 2005 15:07:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14087 for ; Sun, 17 Apr 2005 15:07:43 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNFI6-0002Pj-1P for ltru@ietf.org; Sun, 17 Apr 2005 15:18:46 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 17 Apr 2005 12:07:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Proposed Text for Moving Forward Date: Sun, 17 Apr 2005 12:07:33 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DC62@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVDJG11CnfERiVdTEGXFPc1okhHwQAVsBzQ From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 17 Apr 2005 19:07:34.0861 (UTC) FILETIME=[B69DFFD0:01C54380] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1517169367==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1517169367== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIHlvdSAxMDAlLCBEb3VnLCBiZWNhdXNlIEkgdGhpbmsgdGhhdCB3ZSBoYXZl IGl0IDE4MCBkZWdyZWVzIHJldmVyc2VkLg0KDQpUaGUgcHJvYmxlbSB3aXRoIGRlZmF1bHQgc2Ny aXB0LCBhcyB5b3UgcG9pbnQgb3V0LCBpcyB0aGF0IGl0IHB1dHMgdGhlIHJlZ2lzdHJ5IG1haW50 YWluZXJzIGludG8gYSBwb3NpdGlvbiBvZiBoYXZpbmcgdG8gYWRqdWRpY2F0ZSBhYm91dCBhIGxh bmd1YWdlJ3Mgc2NyaXB0LiAiZW4iIGlzIGEgdmVyeSBwb29yIHRlc3QgY2FzZSBiZWNhdXNlIGl0 IGlzIG5vd2hlcmUgbmVhciBhbiBlZGdlIGNhc2UuIA0KDQpUaGUgcHJvYmxlbSBpcyB0aGF0IHJl Z2lzdGVyaW5nIGEgZGVmYXVsdCBzY3JpcHQgZm9yIGEgbGFuZ3VhZ2UgaXMgbGlrZSB0cnlpbmcg dG8gcHJvdmUgYSBuZWdhdGl2ZS4gTGV0J3MgcGljayBvbiBTZXJiaWFuIG9yIEF6ZXJiYWlqYW5p IGZvciBhIG1pbnV0ZS4gTGV0J3Mgc2F5IHNvbWVvbmUgdHJpZWQgdG8gcmVnaXN0ZXIgYSBkZWZh dWx0IHNjcmlwdCBmb3Igb25lIG9mIHRoZXNlLiBZb3UgY291bGQgcG9pbnQgdG8gYWxsIG9mIHRo ZSBzci1DeXJsIG9yIGF6LUxhdG4gdGV4dHMgeW91IHdhbnQuIFRoYXQgZG9lc24ndCBwcm92ZSB0 aGUgbm9uLWV4aXN0ZW5jZSBvciBub24taW1wb3J0YW5jZSBvZiBvdGhlciBzY3JpcHRzIGZvciB0 aGF0IGxhbmd1YWdlLiBJJ20gY29uY2VybmVkIHRoYXQgbGF0ZXIgcmVnaXN0cmF0aW9ucyBtaWdo dCBjYXVzZSBhIG5lZWQgZm9yIGdlbmVyYWwgcmV0YWdnaW5nIGFuZCB0aGF0IGlzIEJBRC4NCg0K Rm9yIHRoZSByZWdpc3RyeSBwcm9jZXNzIHRvIGhhdmUgbWVhbmluZywgSSB0aGluayB0aGF0IHdl IHNob3VsZCBzdGljayB0byB3aGF0IGlzIGFjdHVhbGx5IGRlbW9uc3RyYWJsZTogeW91IGNhbiBy ZWdpc3RlciB0aGUgZmFjdCB0aGF0IGEgbGFuZ3VhZ2UgaXMgY29tbW9ubHkgd3JpdHRlbiBpbiB0 d28gb3IgbW9yZSBzY3JpcHRzIGJlY2F1c2UgeW91IGNhbiBkZW1vbnN0cmF0ZSB0aGF0LiBUaGlz IHdvdWxkIG1ha2UgdGhlIHJ1bGVzIGFuZCBkZXNpZ24gc2ltcGxlciBhbmQgKmFsc28qIG1ha2Ug dGhlIGVudHJpZXMgbW9yZSByb2J1c3QuIFRoZSBydWxlcyB3b3VsZCB0aGVuIGJlOg0KDQoxLiBT Y3JpcHQgc3VidGFncyBTSE9VTEQgTk9UIGJlIHVzZWQgdG8gZm9ybSBhIGxhbmd1YWdlIHRhZyB1 bmxlc3MgdGhleSBhZGQgc29tZSBkaXN0aW5ndWlzaGluZyBpbmZvcm1hdGlvbi4gRm9yIGV4YW1w bGUsIHRoZSAnTGF0bicgc3VidGFnIGlzIGdlbmVyYWxseSB1bm5lY2Vzc2FyeSB3aXRoIHRoZSBw cmltYXJ5IGxhbmd1YWdlICdlbicgYmVjYXVzZSBuZWFybHkgYWxsIEVuZ2xpc2ggZG9jdW1lbnRz IGFyZSB3cml0dGVuIGluIExhdGluIHNjcmlwdC4NCg0KMi4gVGhlIHNjcmlwdCBzdWJ0YWcgU0hP VUxEIGFsd2F5cyBiZSB1c2VkIHRvIGZvcm0gYSBsYW5ndWFnZSB0YWcgd2hlbiB0aGUgc2NyaXB0 IG9mIHRoZSB0YWdnZWQgY29udGVudCBtYXRjaGVzIGEgJ1JlcXVpcmVkX1NjcmlwdCcgZmllbGQg Zm9yIHRoZSBhc3NvY2lhdGVkIHByaW1hcnkgbGFuZ3VhZ2UuIEZvciBleGFtcGxlLCB5b3Ugc2hv dWxkIHVzZSB0aGUgJ0hhbnQnIHNjcmlwdCBzdWJ0YWcgdG8gZm9ybSB0aGUgbGFuZ3VhZ2UgdGFn ICJ6aC1IYW50LVRXIiwgZXZlbiB0aG91Z2ggbW9zdCBDaGluZXNlIGxhbmd1YWdlIGRvY3VtZW50 cyBpbiBUYWl3YW4gYXJlIHdyaXR0ZW4gaW4gdGhlIFRyYWRpdGlvbmFsIENoaW5lc2Ugc2NyaXB0 LiBUaGUgJ1JlcXVpcmVkX1NjcmlwdCcgZmllbGQgZ2VuZXJhbGx5IGFwcGVhcnMgaW4gcHJpbWFy eSBsYW5ndWFnZXMgdGhhdCBhcmUgd3JpdHRlbiBpbiBtb3JlIHRoYW4gb25lIHNjcmlwdCBhbmQg d2hpY2ggbWlnaHQgb3RoZXJ3aXNlIGJlIGFtYmlndW91cy4NCg0KSU9XLCBJIGFkZGVkIHNjcmlw dCBzdXBwcmVzc2lvbiBhcyBhIHNvcCB0byBkZWZhdWx0IHNjcmlwdCwgYSBjb25jZXB0IHRoYXQg aXMgZWFzeSB0byB1bmRlcnN0YW5kIGFuZCBzZWVtcyBkZXNpcmFibGUsIGJ1dCB3aGljaCBtYXkg YmUgZGlmZmljdWx0IHRvIG1haW50YWluIGluIHByYWN0aWNlIChzZWUgYWxsIHRoZSBkZXByZWNh dGVkIHByaW1hcnkgbGFuZ3VhZ2UgcmVnaXN0cmF0aW9ucyBmb3IgZXhhbXBsZXMgb2YgdGhlIHJl Z2lzdHJhdGlvbiBwcm9jZXNzIGJlaW5nIHVzZWQgaW4gdW5wcm9kdWN0aXZlIHdheXMpLiANCg0K QmVzdCBSZWdhcmRzLA0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6 YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFs aXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90 IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86 bHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgRG91ZyBFd2VsbA0K PiBTZW50OiBkaW1hbmNoZSAxNyBhdnJpbCAyMDA1IDAxOjA1DQo+IFRvOiBMVFJVIFdvcmtpbmcg R3JvdXANCj4gU3ViamVjdDogW0x0cnVdIFJlOiBQcm9wb3NlZCBUZXh0IGZvciBNb3ZpbmcgRm9y d2FyZA0KPiANCj4gQWRkaXNvbiBQaGlsbGlwcyA8YWRkaXNvbiBkb3QgcGhpbGxpcHMgYXQgcXVl c3QgZG90IGNvbT4gd3JvdGU6DQo+IA0KPiA+IEkgYWdyZWUsIE1hcmssIHRoYXQgdGhlIGZ1bGwg ZWZmZWN0IGNhbiBiZSBhY2hpZXZlZCB3aXRoIG9ubHkgb25lDQo+ID4gZmllbGQgYW5kIHRoYXQg eW91ciBwcm9wb3NhbCBpcyBzdXBlcmlvciBpbiBhIG51bWJlciBvZiByZWdhcmRzIChmZXdlcg0K PiA+IG1vdmluZyBwYXJ0cywgZWFzZSBvZiBtYWludGVuYW5jZSwgZWFzZSBvZiBhcHBsaWNhdGlv bikuDQo+ID4NCj4gPiBJIHByb3Bvc2VkIHR3bywgdGhvdWdoLCBmb3IgYSByZWFzb24uIE9uZSBv ZiB0aGUgb2JqZWN0aW9ucyB3YXMgdGhhdA0KPiA+IHdlIGRpZG4ndCBkb2N1bWVudCB3aGVuIGEg cGFydGljdWxhciBzY3JpcHQgcmVhbGx5IG91Z2h0IHRvIGJlIHVzZWQNCj4gPiAoaS5lLiB0aGF0 IHlvdSByZWFsbHkgc2hvdWxkIHN0YXJ0IHRvIHVzZSB6aC1IYW5YLVhYIGluIHByZWZlcmVuY2Ug dG8NCj4gPiB6aC1YWCkuDQo+IA0KPiBJIGtub3cgSSBzYWlkIEkgd291bGQgYmFjayBvZmYgYW5k IG5vdCBnZXQgaW52b2x2ZWQgaW4gdGhlDQo+IGRlZmF1bHQtc2NyaXB0IGlzc3VlLiAgT0ssIHNv IEkgbGllZC4gIFNvcnJ5IGFib3V0IHRoYXQuDQo+IA0KPiBBRkFJQ1QsIHRoaXMgd2hvbGUgaXNz dWUgc3RhcnRlZCB3aXRoIHRoZSBjb25jZXJuIHRoYXQgcGVvcGxlIHdvdWxkIHVzZQ0KPiBhIHNj cmlwdCBzdWJ0YWcgaW4gY2FzZXMgd2hlcmUgaXQgd2FzIGdlbmVyYWxseSB0aG91Z2h0IHRvIGJl IChhKQ0KPiB1bm5lY2Vzc2FyeSwgYmVjYXVzZSB0aGUgaW50ZW5kZWQgc2NyaXB0IHdvdWxkIGJl IG9idmlvdXMsIGFuZCAoYikNCj4gdW5kZXNpcmFibGUsIGJlY2F1c2UgaXQgd291bGQgaW50ZXJm ZXJlIHdpdGggbGVmdC1wcmVmaXggKFJGUikgbWF0Y2hpbmcuDQo+IA0KPiBUaGUgc3RhbmRhcmQg ZXhhbXBsZSB3YXMgImVuLUxhdG4tVVMuIiAgVGhlIGNhc2Ugd2FzIG1hZGUgdGhhdCB0aGUNCj4g b3ZlcndoZWxtaW5nIG1ham9yaXR5IG9mIHdyaXR0ZW4gVS5TLiBFbmdsaXNoIHRleHQgaXMgd3Jp dHRlbiBpbiB0aGUNCj4gTGF0aW4gc2NyaXB0LCBzbyB0aGUgYWRkZWQgZmxleGliaWxpdHkgb2Yg YmVpbmcgYWJsZSB0byBzcGVjaWZ5IHRoZQ0KPiBzY3JpcHQgd291bGQgYmUgbGFyZ2VseSB1bm5l Y2Vzc2FyeSwgYW5kIGluIHBhcnRpY3VsYXIgaXQgd291bGQgYmUNCj4gb3ZlcnNoYWRvd2VkIGJ5 IHRoZSBpbmFiaWxpdHkgb2YgZXhpc3RpbmcgbGVmdC1wcmVmaXggbWF0Y2hpbmcNCj4gYWxnb3Jp dGhtcyB0byBtYXRjaCAiZW4tTGF0bi1VUyIgd2l0aCAiZW4tVVMiIChzb21ldGltZXMgZ2VuZXJh bGl6ZWQgdG8NCj4gImJyb2tlbiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IikuDQo+IA0KPiBUaGlz IHdhcyB0aGUgZm91bmRhdGlvbiBvZiAiZGVmYXVsdCBzY3JpcHQiOiBjZXJ0YWluIGxhbmd1YWdl cyBsaWtlDQo+IEVuZ2xpc2ggY291bGQgYmUgbGlzdGVkIGFzIGhhdmluZyBhIGRlZmF1bHQgc2Ny aXB0IG9mIExhdGluLCBzbyB0aGF0IHRhZw0KPiBnZW5lcmF0b3JzIGNvdWxkIGF2b2lkIGNyZWF0 aW5nIHRhZ3MgbGlrZSAiZW4tTGF0biIgb3IgImVuLUxhdG4tVVMiDQo+IHdob3NlIGRpc2FkdmFu dGFnZXMgd291bGQgb3V0d2VpZ2ggdGhlaXIgYWR2YW50YWdlcy4NCj4gDQo+IE9mIGNvdXJzZSwg aW4gY2VydGFpbiBjaXJjdW1zdGFuY2VzIHlvdSBtaWdodCBoYXZlIEVuZ2xpc2ggd3JpdHRlbiBp bg0KPiBCcmFpbGxlLCBvciBldmVuIGluIEN5cmlsbGljLCBhbmQgbW9zdCBpZiBub3QgYWxsIHNl ZW1lZCB0byBhZ3JlZSB0aGF0DQo+IGluIHRoZXNlIHJhcmUgY2lyY3Vtc3RhbmNlcyBpdCB3b3Vs ZCBiZSBhY2NlcHRhYmxlIHRvIGdlbmVyYXRlDQo+ICJlbi1CcmFpLXdoYXRldmVyIiBvciAiZW4t Q3lybC13aGF0ZXZlci4iDQo+IA0KPiBUaGUgc3RhbmRhcmQgY291bnRlcmV4YW1wbGVzIHdlcmUg InpoLUhhbnMiIGFuZCAiemgtSGFudC4iICBUaGUgY2FzZSB3YXMNCj4gbWFkZSB0aGF0IENoaW5l c2UgaXMgY29tbW9ubHkgd3JpdHRlbiBpbiBib3RoIG9mIHRoZXNlIHNjcmlwdCB2YXJpYW50cywN Cj4gYW5kIGl0IHdvdWxkIG9mdGVuIGJlIGJlbmVmaWNpYWwgdG8gaW5jbHVkZSBzY3JpcHQgaW5m b3JtYXRpb24sIHRvIHRoZQ0KPiBwb2ludCBvZiBwZXJoYXBzIGJlaW5nIG1vcmUgaW1wb3J0YW50 IHRoYW4gc3RyaWN0IGNvbXBhdGliaWxpdHkgd2l0aA0KPiBsZWZ0LXByZWZpeCBtYXRjaGluZyBh bGdvcml0aG1zLiAgTGFuZ3VhZ2VzIGxpa2UgQ2hpbmVzZSBhbmQgQXplcmJhaWphbmkNCj4gYW5k IFNlcmJpYW4sIGFmdGVyIGFsbCwgd2VyZSB0aGUgbWFqb3IgdXNlIGNhc2VzIGZvciB0aGUgaW50 cm9kdWN0aW9uIG9mDQo+IHNjcmlwdCBzdWJ0YWdzIGluIHRoZSBmaXJzdCBwbGFjZS4NCj4gDQo+ IFNvIHVubGlrZSAiZW4tTGF0biIsIGl0IHdvdWxkIG5vdCBiZSBkaXNjb3VyYWdlZCB0byB3cml0 ZSAiemgtSGFucyIgb3INCj4gInpoLUhhbnQiLCBvciBlaXRoZXIgb2YgdGhlc2UgZm9sbG93ZWQg YnkgYSByZWdpb24gc3VidGFnLiAgT2YgY291cnNlLA0KPiBqdXN0IGxpa2UgRW5nbGlzaCwgQ2hp bmVzZSBjb3VsZCBhbHNvIGJlIHdyaXR0ZW4gaW4gYSBsZXNzIG9idmlvdXMNCj4gc2NyaXB0IGxp a2UgQnJhaWxsZSBvciBDeXJpbGxpYywgYW5kIHNvICJ6aC1CcmFpIiBhbmQgInpoLUN5cmwiIG91 Z2h0IHRvDQo+IGJlIGFsbG93ZWQgYXMgd2VsbC4NCj4gDQo+IEkgY29uY2VkZSB0aGF0IGJlY2F1 c2Ugb2YgdGhlIHN0YXRlZCBwcmVkb21pbmFuY2Ugb2YgcHJvY2Vzc2VzIHRoYXQgdXNlDQo+IGxl ZnQtcHJlZml4IG1hdGNoaW5nLCBpdCBtaWdodCBiZSBiZW5lZmljaWFsIHRvIGRlZmluZSBhIGRl ZmF1bHQgc2NyaXB0DQo+IGZvciBjb21tb24gbGFuZ3VhZ2VzIHRoYXQgYXJlIHdyaXR0ZW4gaW4g YSBzaW5nbGUgc2NyaXB0IDk5LjklIG9mIHRoZQ0KPiB0aW1lLiAgSSBzdGlsbCBkb24ndCBrbm93 IHdoZXJlIHRoZSBhdXRob3JpdHkgY29tZXMgZnJvbSB0byBkZWNpZGUgd2hpY2gNCj4gbGFuZ3Vh Z2VzIGFuZCB3aGljaCBzY3JpcHRzIGdldCBtYXJrZWQgaW4gdGhpcyB3YXkgLS0gZGVmaW5pdGVs eSBub3QNCj4gZnJvbSBJU08gb3IgZG9jdW1lbnRlZCByZWdpc3RyYXRpb25zIG9yIGRldGVybWlu aXN0aWMgcnVsZXMsIGxpa2UNCj4gZXZlcnl0aGluZyBlbHNlIGluIHRoZSByZWdpc3RyeSAtLSBi dXQgSSBhc3N1bWUgdGhhdCB3b3VsZCBiZSB3b3JrZWQgb3V0DQo+IGluIGR1ZSBjb3Vyc2UuDQo+ IA0KPiBXaGF0IEkgZG8gTk9UIHVuZGVyc3RhbmQgaXMgaG93IHRoaXMgaGFzIGV4cGFuZGVkIHRv IHRlbGxpbmcgcGVvcGxlIHdoZW4NCj4gdGhleSBTSE9VTEQgdXNlIHNjcmlwdCBzdWJ0YWdzLCBh bmQgaG93IHRoZSBzZXQgb2YgYWxsb3dhYmxlIHN1YnRhZ3MNCj4gc2hvdWxkIGJlIGxpbWl0ZWQg aW4gc29tZSB3YXkuDQo+IA0KPiBUaGVyZSBtYXkgd2VsbCBiZSBjYXNlcyB3aGVyZSAiemgiIG9y ICJ6aC1DTicgb3IgInpoLVRXIiBpcyBhbGwgdGhhdCBpcw0KPiBuZWVkZWQsIGFuZCB0aGVyZSBp cyBjZXJ0YWlubHkgZXhpc3RpbmcgZGF0YSB0aGF0IHVzZXMgc3VjaCB0YWdzLiAgSQ0KPiBkb24n dCBzZWUgYW55IGp1c3RpZmljYXRpb24gZm9yIGRpc2NvdXJhZ2luZyBzdWNoIHVzYWdlLCBldmVu IGlmIHdlIGhhdmUNCj4gZGVmaW5lZCBhIHdheSB0byB0YWcgQ2hpbmVzZSBkYXRhIG1vcmUgcHJl Y2lzZWx5LiAgTGlrZXdpc2UsIGlmIHRoZXJlIGlzDQo+IG5vIHByb2hpYml0aW9uIGFnYWluc3Qg d3JpdGluZyAiZW4tQnJhaSIgb3IgImVuLUN5cmwiLCB0aGVuIEkgc2VlIG5vDQo+IHJlYXNvbiB0 byBwcm9oaWJpdCBvciBkaXNjb3VyYWdlICJ6aC1CcmFpIiBvciAiemgtQ3lybCIgZWl0aGVyLiAg QQ0KPiAicmVxdWlyZWQtc2NyaXB0IiBmaWVsZCB3b3VsZCBkbyBleGFjdGx5IHRoaXMsIGJ5IGxp c3RpbmcgJ0hhbnMnIGFuZA0KPiAnSGFudCcgYnV0IG5vdCBvdGhlcnMuDQo+IA0KPiBUaGlzIGlz IHRvbyBwcmVzY3JpcHRpdmUuICBJdCB0ZWxscyBwZW9wbGUgaG93IHRoZXkgU0hPVUxEIHRhZyBk YXRhLCBub3QNCj4ganVzdCBpbiB0ZXJtcyBvZiAidGFnIGNvbnRlbnQgd2lzZWx5IiBvciAiZG9u J3QgYmUgZXhjZXNzaXZlbHkgcHJlY2lzZSwiDQo+IGJ1dCBvbiBhIHNwZWNpZmljIGxhbmd1YWdl LWJ5LWxhbmd1YWdlIGJhc2lzLiAgSXQgYXNzdW1lcywgaW1wbGljaXRseSwNCj4gdGhhdCB0aGlz IGdyb3VwIG9yIGlldGYtbGFuZ3VhZ2VzIGhhcyB0aGUgZXhwZXJ0aXNlIGFuZCBhdXRob3JpdHkg dG8NCj4gbWFrZSB0aGlzIGp1ZGdtZW50LiAgVW5saWtlIGRlZmF1bHQtc2NyaXB0LCByZXF1aXJl ZC1zY3JpcHQgZG9lcyBub3RoaW5nDQo+IHRvIHNvbHZlIHRoZSBsZWZ0LXByZWZpeCBtYXRjaGlu ZyBwcm9ibGVtLCBhbmQgYXMgc3VjaCwgSSBkb24ndCB0aGluaw0KPiBpdCdzIHdpdGhpbiB0aGUg c2NvcGUgb2YgdGhlIGNoYXJ0ZXIuDQo+IA0KPiBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZzoNCj4g DQo+IDEuICBBbiBvcHRpb25hbCwgaW5mb3JtYXRpdmUgZGVmYXVsdC1zY3JpcHQgZmllbGQgdGhh dCB3b3VsZCBzdWdnZXN0IHRvDQo+IHRhZyBnZW5lcmF0b3JzIHRoYXQgdGhleSBub3QgdXNlIHRo YXQgcGFydGljdWxhciBzY3JpcHQgc3VidGFnIHRvZ2V0aGVyDQo+IHdpdGggdGhhdCBwYXJ0aWN1 bGFyIGxhbmd1YWdlIHN1YnRhZy4gIFRoaXMgZmllbGQgY291bGQgYmUgYWRkZWQsDQo+IGNoYW5n ZWQsIG9yIHJlbW92ZWQgYXQgYW55IHRpbWUuICAoSXQgZG9lc24ndCBtYXR0ZXIgbXVjaCB3aGF0 IHRoZSBmaWVsZA0KPiBpcyBjYWxsZWQsIGFuZCBJIHJlbmV3IG15IHN1Z2dlc3Rpb24gdGhhdCB3 ZSBub3QgdHJ5IHRvIGluamVjdCB0b28gbXVjaA0KPiBkZWVwIG1lYW5pbmcgaW50byB0aGUgbmFt ZXMgb2YgZmllbGRzLCBvciBhc3N1bWUgdGhhdCB1c2VycyB3aWxsIGRlcml2ZQ0KPiBkZWVwIG1l YW5pbmcgZnJvbSB0aGVtLikNCj4gDQo+IDIuICBOTyByZXF1aXJlbWVudCB3aXRoaW4gdGhlIGRy YWZ0IHRoYXQgdGFnIGdlbmVyYXRvcnMgIm11c3Qgbm90IiB1c2UNCj4gc2NyaXB0IHN1YnRhZ3Mg aW4gYW55IGdpdmVuIHNjZW5hcmlvLiAgVGhlIHRleHQgaW4gZHJhZnQtMDEgdGhhdA0KPiBkaXNj b3VyYWdlcyB0aGUgdXNlIG9mIGEgc2NyaXB0IHN1YnRhZyAidW5sZXNzIGl0IGNvbnZleXMgYWRk aXRpb25hbA0KPiBpbmZvcm1hdGlvbiIgc2hvdWxkIGJlIGFkZXF1YXRlLg0KPiANCj4gMy4gIE5P IG1lY2hhbmlzbSB0byB0ZWxsIHRhZyBnZW5lcmF0b3JzIHRoYXQgdGhleSAic2hvdWxkIiB1c2Ug YSBzY3JpcHQNCj4gc3VidGFnIHRvZ2V0aGVyIHdpdGggYW55IHBhcnRpY3VsYXIgbGFuZ3VhZ2Ug c3VidGFnLCBhbmQgKmVzcGVjaWFsbHkqDQo+IG5vdCBvbmUgdGhhdCBsaXN0cyB0aGUgImV4cGVj dGVkIiBzY3JpcHQgc3VidGFncyB3aGlsZSBleGNsdWRpbmcgb3RoZXJzLg0KPiBJZiB0YWcgZ2Vu ZXJhdG9ycyBvcHQgdG8gY3JlYXRlIGEgdGFnIHN1Y2ggYXMgInpoLVRXIiB0aGF0ICJtYXkgYmUN Cj4gYW1iaWd1b3VzIHdpdGhvdXQgc2NyaXB0IGluZm9ybWF0aW9uLCIgdGhhdCBzaG91bGQgYmUg dXAgdG8gdGhlbS4NCj4gDQo+IC1Eb3VnIEV3ZWxsDQo+ICBGdWxsZXJ0b24sIENhbGlmb3JuaWEN Cj4gIGh0dHA6Ly91c2Vycy5hZGVscGhpYS5uZXQvfmRld2VsbC8NCj4gDQo+IA0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWls aW5nIGxpc3QNCj4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --===============1517169367== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1517169367==-- From ltru-bounces@lists.ietf.org Sun Apr 17 15:12:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNFBc-0006mc-Qi; Sun, 17 Apr 2005 15:12:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNFBa-0006mX-31 for ltru@megatron.ietf.org; Sun, 17 Apr 2005 15:12:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14638 for ; Sun, 17 Apr 2005 15:11:59 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNFME-0002z2-QV for ltru@ietf.org; Sun, 17 Apr 2005 15:23:03 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3HJBk9N004638; Sun, 17 Apr 2005 12:11:46 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3A25BV>; Sun, 17 Apr 2005 12:11:46 -0700 Message-ID: From: "McDonald, Ira" To: "'Doug Ewell'" , LTRU Working Group Subject: RE: [Ltru] Re: Proposed Text for Moving Forward Date: Sun, 17 Apr 2005 12:11:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org -1 Sigh...until this message we had an emerging concensus. Non-specific "use tags wisely" is much WORSE than no statement at all. Addison has proposed a low-cost unambiguous solution to a real-world problem. Tag matching may go into some other spec (lousy idea IMHO, because the registry format has to be intimately coupled to standard matching algorithms). But actually generating tags in client applications needs to have normative guidance in RFC3066bis itself or we're all wasting our time. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Doug Ewell > Sent: Sunday, April 17, 2005 4:05 AM > To: LTRU Working Group > Subject: [Ltru] Re: Proposed Text for Moving Forward > > > Addison Phillips wrote: > > > I agree, Mark, that the full effect can be achieved with only one > > field and that your proposal is superior in a number of > regards (fewer > > moving parts, ease of maintenance, ease of application). > > > > I proposed two, though, for a reason. One of the objections was that > > we didn't document when a particular script really ought to be used > > (i.e. that you really should start to use zh-HanX-XX in > preference to > > zh-XX). > > I know I said I would back off and not get involved in the > default-script issue. OK, so I lied. Sorry about that. > > AFAICT, this whole issue started with the concern that people > would use > a script subtag in cases where it was generally thought to be (a) > unnecessary, because the intended script would be obvious, and (b) > undesirable, because it would interfere with left-prefix > (RFR) matching. > > The standard example was "en-Latn-US." The case was made that the > overwhelming majority of written U.S. English text is written in the > Latin script, so the added flexibility of being able to specify the > script would be largely unnecessary, and in particular it would be > overshadowed by the inability of existing left-prefix matching > algorithms to match "en-Latn-US" with "en-US" (sometimes > generalized to > "broken backward compatibility"). > > This was the foundation of "default script": certain languages like > English could be listed as having a default script of Latin, > so that tag > generators could avoid creating tags like "en-Latn" or "en-Latn-US" > whose disadvantages would outweigh their advantages. > > Of course, in certain circumstances you might have English written in > Braille, or even in Cyrillic, and most if not all seemed to agree that > in these rare circumstances it would be acceptable to generate > "en-Brai-whatever" or "en-Cyrl-whatever." > > The standard counterexamples were "zh-Hans" and "zh-Hant." > The case was > made that Chinese is commonly written in both of these script > variants, > and it would often be beneficial to include script information, to the > point of perhaps being more important than strict compatibility with > left-prefix matching algorithms. Languages like Chinese and > Azerbaijani > and Serbian, after all, were the major use cases for the > introduction of > script subtags in the first place. > > So unlike "en-Latn", it would not be discouraged to write "zh-Hans" or > "zh-Hant", or either of these followed by a region subtag. Of course, > just like English, Chinese could also be written in a less obvious > script like Braille or Cyrillic, and so "zh-Brai" and > "zh-Cyrl" ought to > be allowed as well. > > I concede that because of the stated predominance of > processes that use > left-prefix matching, it might be beneficial to define a > default script > for common languages that are written in a single script 99.9% of the > time. I still don't know where the authority comes from to > decide which > languages and which scripts get marked in this way -- definitely not > from ISO or documented registrations or deterministic rules, like > everything else in the registry -- but I assume that would be > worked out > in due course. > > What I do NOT understand is how this has expanded to telling > people when > they SHOULD use script subtags, and how the set of allowable subtags > should be limited in some way. > > There may well be cases where "zh" or "zh-CN' or "zh-TW" is > all that is > needed, and there is certainly existing data that uses such tags. I > don't see any justification for discouraging such usage, even > if we have > defined a way to tag Chinese data more precisely. Likewise, > if there is > no prohibition against writing "en-Brai" or "en-Cyrl", then I see no > reason to prohibit or discourage "zh-Brai" or "zh-Cyrl" either. A > "required-script" field would do exactly this, by listing 'Hans' and > 'Hant' but not others. > > This is too prescriptive. It tells people how they SHOULD > tag data, not > just in terms of "tag content wisely" or "don't be > excessively precise," > but on a specific language-by-language basis. It assumes, implicitly, > that this group or ietf-languages has the expertise and authority to > make this judgment. Unlike default-script, required-script > does nothing > to solve the left-prefix matching problem, and as such, I don't think > it's within the scope of the charter. > > I propose the following: > > 1. An optional, informative default-script field that would > suggest to > tag generators that they not use that particular script > subtag together > with that particular language subtag. This field could be added, > changed, or removed at any time. (It doesn't matter much > what the field > is called, and I renew my suggestion that we not try to > inject too much > deep meaning into the names of fields, or assume that users > will derive > deep meaning from them.) > > 2. NO requirement within the draft that tag generators "must not" use > script subtags in any given scenario. The text in draft-01 that > discourages the use of a script subtag "unless it conveys additional > information" should be adequate. > > 3. NO mechanism to tell tag generators that they "should" > use a script > subtag together with any particular language subtag, and *especially* > not one that lists the "expected" script subtags while > excluding others. > If tag generators opt to create a tag such as "zh-TW" that "may be > ambiguous without script information," that should be up to them. > > -Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 15:14:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNFDp-0006yi-4o; Sun, 17 Apr 2005 15:14:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNFDo-0006yd-7B for ltru@megatron.ietf.org; Sun, 17 Apr 2005 15:14:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14956 for ; Sun, 17 Apr 2005 15:14:18 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNFOT-00030o-5B for ltru@ietf.org; Sun, 17 Apr 2005 15:25:21 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3HJE4Lx004837; Sun, 17 Apr 2005 12:14:04 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3A25CL>; Sun, 17 Apr 2005 12:14:04 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Doug Ewell , LTRU Working Group Subject: RE: [Ltru] Re: Proposed Text for Moving Forward Date: Sun, 17 Apr 2005 12:14:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org -1 Ah, I see, we _are_ all wasting our time. 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: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Sunday, April 17, 2005 3:08 PM > To: Doug Ewell; LTRU Working Group > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > I agree with you 100%, Doug, because I think that we have it > 180 degrees reversed. > > The problem with default script, as you point out, is that it > puts the registry maintainers into a position of having to > adjudicate about a language's script. "en" is a very poor > test case because it is nowhere near an edge case. > > The problem is that registering a default script for a > language is like trying to prove a negative. Let's pick on > Serbian or Azerbaijani for a minute. Let's say someone tried > to register a default script for one of these. You could > point to all of the sr-Cyrl or az-Latn texts you want. That > doesn't prove the non-existence or non-importance of other > scripts for that language. I'm concerned that later > registrations might cause a need for general retagging and > that is BAD. > > For the registry process to have meaning, I think that we > should stick to what is actually demonstrable: you can > register the fact that a language is commonly written in two > or more scripts because you can demonstrate that. This would > make the rules and design simpler and *also* make the entries > more robust. The rules would then be: > > 1. Script subtags SHOULD NOT be used to form a language tag > unless they add some distinguishing information. For example, > the 'Latn' subtag is generally unnecessary with the primary > language 'en' because nearly all English documents are > written in Latin script. > > 2. The script subtag SHOULD always be used to form a language > tag when the script of the tagged content matches a > 'Required_Script' field for the associated primary language. > For example, you should use the 'Hant' script subtag to form > the language tag "zh-Hant-TW", even though most Chinese > language documents in Taiwan are written in the Traditional > Chinese script. The 'Required_Script' field generally appears > in primary languages that are written in more than one script > and which might otherwise be ambiguous. > > IOW, I added script suppression as a sop to default script, a > concept that is easy to understand and seems desirable, but > which may be difficult to maintain in practice (see all the > deprecated primary language registrations for examples of the > registration process being used in unproductive ways). > > Best Regards, > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Doug Ewell > > Sent: dimanche 17 avril 2005 01:05 > > To: LTRU Working Group > > Subject: [Ltru] Re: Proposed Text for Moving Forward > > > > Addison Phillips wrote: > > > > > I agree, Mark, that the full effect can be achieved with only one > > > field and that your proposal is superior in a number of > regards (fewer > > > moving parts, ease of maintenance, ease of application). > > > > > > I proposed two, though, for a reason. One of the > objections was that > > > we didn't document when a particular script really ought > to be used > > > (i.e. that you really should start to use zh-HanX-XX in > preference to > > > zh-XX). > > > > I know I said I would back off and not get involved in the > > default-script issue. OK, so I lied. Sorry about that. > > > > AFAICT, this whole issue started with the concern that > people would use > > a script subtag in cases where it was generally thought to be (a) > > unnecessary, because the intended script would be obvious, and (b) > > undesirable, because it would interfere with left-prefix > (RFR) matching. > > > > The standard example was "en-Latn-US." The case was made that the > > overwhelming majority of written U.S. English text is written in the > > Latin script, so the added flexibility of being able to specify the > > script would be largely unnecessary, and in particular it would be > > overshadowed by the inability of existing left-prefix matching > > algorithms to match "en-Latn-US" with "en-US" (sometimes > generalized to > > "broken backward compatibility"). > > > > This was the foundation of "default script": certain languages like > > English could be listed as having a default script of > Latin, so that tag > > generators could avoid creating tags like "en-Latn" or "en-Latn-US" > > whose disadvantages would outweigh their advantages. > > > > Of course, in certain circumstances you might have English > written in > > Braille, or even in Cyrillic, and most if not all seemed to > agree that > > in these rare circumstances it would be acceptable to generate > > "en-Brai-whatever" or "en-Cyrl-whatever." > > > > The standard counterexamples were "zh-Hans" and "zh-Hant." > The case was > > made that Chinese is commonly written in both of these > script variants, > > and it would often be beneficial to include script > information, to the > > point of perhaps being more important than strict compatibility with > > left-prefix matching algorithms. Languages like Chinese > and Azerbaijani > > and Serbian, after all, were the major use cases for the > introduction of > > script subtags in the first place. > > > > So unlike "en-Latn", it would not be discouraged to write > "zh-Hans" or > > "zh-Hant", or either of these followed by a region subtag. > Of course, > > just like English, Chinese could also be written in a less obvious > > script like Braille or Cyrillic, and so "zh-Brai" and > "zh-Cyrl" ought to > > be allowed as well. > > > > I concede that because of the stated predominance of > processes that use > > left-prefix matching, it might be beneficial to define a > default script > > for common languages that are written in a single script > 99.9% of the > > time. I still don't know where the authority comes from to > decide which > > languages and which scripts get marked in this way -- definitely not > > from ISO or documented registrations or deterministic rules, like > > everything else in the registry -- but I assume that would > be worked out > > in due course. > > > > What I do NOT understand is how this has expanded to > telling people when > > they SHOULD use script subtags, and how the set of allowable subtags > > should be limited in some way. > > > > There may well be cases where "zh" or "zh-CN' or "zh-TW" is > all that is > > needed, and there is certainly existing data that uses such tags. I > > don't see any justification for discouraging such usage, > even if we have > > defined a way to tag Chinese data more precisely. > Likewise, if there is > > no prohibition against writing "en-Brai" or "en-Cyrl", then I see no > > reason to prohibit or discourage "zh-Brai" or "zh-Cyrl" either. A > > "required-script" field would do exactly this, by listing 'Hans' and > > 'Hant' but not others. > > > > This is too prescriptive. It tells people how they SHOULD > tag data, not > > just in terms of "tag content wisely" or "don't be > excessively precise," > > but on a specific language-by-language basis. It assumes, > implicitly, > > that this group or ietf-languages has the expertise and authority to > > make this judgment. Unlike default-script, required-script > does nothing > > to solve the left-prefix matching problem, and as such, I > don't think > > it's within the scope of the charter. > > > > I propose the following: > > > > 1. An optional, informative default-script field that > would suggest to > > tag generators that they not use that particular script > subtag together > > with that particular language subtag. This field could be added, > > changed, or removed at any time. (It doesn't matter much > what the field > > is called, and I renew my suggestion that we not try to > inject too much > > deep meaning into the names of fields, or assume that users > will derive > > deep meaning from them.) > > > > 2. NO requirement within the draft that tag generators > "must not" use > > script subtags in any given scenario. The text in draft-01 that > > discourages the use of a script subtag "unless it conveys additional > > information" should be adequate. > > > > 3. NO mechanism to tell tag generators that they "should" > use a script > > subtag together with any particular language subtag, and > *especially* > > not one that lists the "expected" script subtags while > excluding others. > > If tag generators opt to create a tag such as "zh-TW" that "may be > > ambiguous without script information," that should be up to them. > > > > -Doug Ewell > > Fullerton, California > > http://users.adelphia.net/~dewell/ > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 15:25:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNFOT-0007mW-9M; Sun, 17 Apr 2005 15:25:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNFOR-0007mR-2H for ltru@megatron.ietf.org; Sun, 17 Apr 2005 15:25:19 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15670 for ; Sun, 17 Apr 2005 15:25:16 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNFK5-0002Lh-Cu for ltru@lists.ietf.org; Sun, 17 Apr 2005 21:20:49 +0200 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Apr 2005 21:20:49 +0200 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Apr 2005 21:20:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 17 Apr 2005 21:22:57 +0200 Organization: Lines: 10 Message-ID: <4262B791.7348@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Proposed Text for Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Misha Wolf wrote: > the more complex solution was hatched by an unauthorised > copy of Misha, running in Frank's brain :-) I'll delete this copy a.s.a.p., the KISS variant is okay for the matching kludge and less trouble for the draft ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 16:00:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNFwT-0001vH-0Z; Sun, 17 Apr 2005 16:00:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNFwR-0001vC-1N for ltru@megatron.ietf.org; Sun, 17 Apr 2005 16:00:27 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17572 for ; Sun, 17 Apr 2005 16:00:24 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNFsL-0005tF-Nw for ltru@lists.ietf.org; Sun, 17 Apr 2005 21:56:13 +0200 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Apr 2005 21:56:13 +0200 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Apr 2005 21:56:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 17 Apr 2005 21:56:38 +0200 Organization: Lines: 21 Message-ID: <4262BF76.30@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B08DB6A@irvmbxw01.quest.com> <024601c54205$4034d0c0$7f1afea9@oemcomputer> <20050416173640.GA21496@skunk.reutershealth.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.1 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Proposed Text for Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: > Beser a tsebrokhene Yidish vi nisht kayn Yidish. Okay, I understand it... meschugge ;-) For Randy's problem L-S2-V2 we could (ab)use L-S2 as a prefix of V2, and S1 as an "suppress_script" for L. I don't see a solution allowing to suppress S2 for L only in conjunction with V2. Unless we'd allow a "suppress_script" in the variant entry to overrule the normal "suppress_script". But is this needed anywhere ? The "suppress" kludge is for compatibility with existing 3066 content and implementations, not for hypothetical L-V2 cases. > the Ethnologue jesuitically defines away the problem by > viewing the minority variant as a separate language, which > sociolinguistically it generally is. Apparently a good idea. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 16:07:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNG3B-0002QE-J4; Sun, 17 Apr 2005 16:07:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNG3A-0002Q9-EW for ltru@megatron.ietf.org; Sun, 17 Apr 2005 16:07:24 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17873 for ; Sun, 17 Apr 2005 16:07:21 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNFzA-0006Wc-Ig for ltru@lists.ietf.org; Sun, 17 Apr 2005 22:03:16 +0200 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Apr 2005 22:03:16 +0200 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Apr 2005 22:03:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 17 Apr 2005 22:06:42 +0200 Organization: Lines: 11 Message-ID: <4262C1D2.515E@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Proposed Text for Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org McDonald, Ira wrote: > +1 > Thanks for some good clear thought for a change. I agree > that I hated this counting the field members approach. I still don't get the idea of more than one "suppress_script" for the same language, how's that supposed to work ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 16:25:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNGKc-0003tt-PK; Sun, 17 Apr 2005 16:25:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNGKb-0003to-O0 for ltru@megatron.ietf.org; Sun, 17 Apr 2005 16:25:26 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19055 for ; Sun, 17 Apr 2005 16:25:22 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNGGa-0007wl-S2 for ltru@lists.ietf.org; Sun, 17 Apr 2005 22:21:16 +0200 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Apr 2005 22:21:16 +0200 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Apr 2005 22:21:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 17 Apr 2005 22:23:14 +0200 Organization: Lines: 21 Message-ID: <4262C5B2.52A1@xyzzy.claranet.de> References: <005601c542cd$fef22c60$467a3009@sanjose.ibm.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.1 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Proposed Text for Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis wrote: > 1. Script subtags listed in the 'Suppress_Script' field > MUST NOT be used to form language tags unless there is a > specific reason to include the script subtag in the > application. That's almost exactly the same as this shorter rule: | 1. Script subtags listed in the 'Suppress_Script' field | SHOULD NOT be used to form language tags. The difference between MUST NOT and SHOULD NOT is what you say in your "unless..." clause, you need specific and good reasons to violate a SHOULD NOT. Or at least that's my interpretation of RfC 2119, sometimes Bruce apparently didn't agree (only my personal impression). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 16:49:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNGhm-0005kv-4C; Sun, 17 Apr 2005 16:49:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNGhb-0005kU-3R for ltru@megatron.ietf.org; Sun, 17 Apr 2005 16:49:11 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20771 for ; Sun, 17 Apr 2005 16:49:08 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNGdY-0001Sj-Hp for ltru@lists.ietf.org; Sun, 17 Apr 2005 22:45:00 +0200 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Apr 2005 22:45:00 +0200 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Apr 2005 22:45:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 17 Apr 2005 22:46:22 +0200 Organization: Lines: 28 Message-ID: <4262CB1E.12E1@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B08DC62@irvmbxw01.quest.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.1 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Proposed Text for Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > 1. Script subtags SHOULD NOT be used to form a language tag > unless they add some distinguishing information. For example, > the 'Latn' subtag is generally unnecessary with the primary > language 'en' because nearly all English documents are > written in Latin script. The "because" doesn't work with undocumented "suppress_script" concepts. I didn't know that Goth is _not_ the default for got, I also didn't know that Latn is _not_ the default for yi. Now after John mentioned it the latter is convincing, I don't even bother to check it. OTOH it's clear that all yi content I've seen so far was yi-Latn, my knowledge of Hebrew is limited to what I needed to read mathematical texts (= mainly "aleph"). > 2. The script subtag SHOULD always be used to form a language > tag when the script of the tagged content matches a > 'Required_Script' field for the associated primary language. Less convincing, in a hrefang= to a WAV or MP3 I don't need any Hans or Hant. As far as I'm concerned the only function of the "required_script" field is to block erroneous registrations of a "suppress_script" for the same language (if you say so in the rules for these fields). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 19:27:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNJAv-0003EN-CU; Sun, 17 Apr 2005 19:27:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNJAs-0003EA-1S for ltru@megatron.ietf.org; Sun, 17 Apr 2005 19:27:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03106 for ; Sun, 17 Apr 2005 19:27:30 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNJLZ-0000cH-0G for ltru@ietf.org; Sun, 17 Apr 2005 19:38:37 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 17 Apr 2005 16:27:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Proposed Text for Moving Forward Date: Sun, 17 Apr 2005 16:27:22 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DC6D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVDgaiEBx161xdtTpqwhn+45E4wDwAIo3Sw From: "Addison Phillips" To: "McDonald, Ira" , "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 17 Apr 2005 23:27:23.0287 (UTC) FILETIME=[020B0A70:01C543A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1602798709==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1602798709== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 TG9vaywgSSdtIGhhcHB5ICplbm91Z2gqIHdpdGggbXkgbG93LWNvc3QsIHR3by1waWVjZSBzb2x1 dGlvbi4NCg0KV2hhdCB0dXJuZWQgeW91IG9mZj8gV2FzIGl0IHRoYXQgeW91IGZvdW5kIG15IGxv Z2ljIGJlbG93IGNvbXBlbGxpbmcgb3IganVzdCB0aGF0IHlvdSBkaWRuJ3QgYWdyZWUgd2l0aCB0 aGUgZGVzaWduIGJlbG93PyBJZiBpdCBpcyBqdXN0IHRoZSBkZXNpZ24sIEkgY2FuIGdvIHdpdGgg dGhlIG9yaWdpbmFsIHByb3Bvc2FsLiBJZiBpdCBpcyB0aGUgbG9naWMsIHRoZW4gaGVscCBtZSBv dXQgaGVyZTogd2hhdCB3b3Jrcz8gDQoNCkNvbnNlbnN1cyBpcyBnb29kLiBJJ20gaGFwcHkgdG8g dGFrZSBhIGRlc2lnbiBJIGRvbid0IGxpa2UgZm9yIHNvbWUgcGVyc29uYWwgcmVhc29uIChJIG1p Z2h0IGJlIHdyb25nIGluIG15IHJlYXNvbmluZywgYWZ0ZXIgYWxsKS4gQnV0IGl0IHNob3VsZCBi ZSB0aGUgcmlnaHQgc29sdXRpb24gZm9yIHRoZSBwcm9ibGVtLCBpZiBwb3NzaWJsZS4NCg0KQWRk aXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVl c3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5n IEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBh biBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IE1jRG9uYWxkLCBJcmEgW21haWx0bzppbWNkb25hbGRAc2hhcnBsYWJzLmNvbV0NCj4gU2VudDog ZGltYW5jaGUgMTcgYXZyaWwgMjAwNSAxMjoxNA0KPiBUbzogQWRkaXNvbiBQaGlsbGlwczsgRG91 ZyBFd2VsbDsgTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJFOiBbTHRydV0gUmU6IFBy b3Bvc2VkIFRleHQgZm9yIE1vdmluZyBGb3J3YXJkDQo+IA0KPiAtMQ0KPiANCj4gQWgsIEkgc2Vl LCB3ZSBfYXJlXyBhbGwgd2FzdGluZyBvdXIgdGltZS4NCj4gDQo+IElyYSBNY0RvbmFsZCAoTXVz aWNpYW4gLyBTb2Z0d2FyZSBBcmNoaXRlY3QpDQo+IEJsdWUgUm9vZiBNdXNpYyAvIEhpZ2ggTm9y dGggSW5jDQo+IFBPIEJveCAyMjEgIEdyYW5kIE1hcmFpcywgTUkgIDQ5ODM5DQo+IHBob25lOiAr MS05MDYtNDk0LTI0MzQNCj4gZW1haWw6IGltY2RvbmFsZEBzaGFycGxhYnMuY29tDQo+IA0KPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogbHRydS1ib3VuY2VzQGxpc3Rz LmlldGYub3JnDQo+ID4gW21haWx0bzpsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmddT24NCj4g PiBCZWhhbGYgT2YgQWRkaXNvbiBQaGlsbGlwcw0KPiA+IFNlbnQ6IFN1bmRheSwgQXByaWwgMTcs IDIwMDUgMzowOCBQTQ0KPiA+IFRvOiBEb3VnIEV3ZWxsOyBMVFJVIFdvcmtpbmcgR3JvdXANCj4g PiBTdWJqZWN0OiBSRTogW0x0cnVdIFJlOiBQcm9wb3NlZCBUZXh0IGZvciBNb3ZpbmcgRm9yd2Fy ZA0KPiA+DQo+ID4NCj4gPiBJIGFncmVlIHdpdGggeW91IDEwMCUsIERvdWcsIGJlY2F1c2UgSSB0 aGluayB0aGF0IHdlIGhhdmUgaXQNCj4gPiAxODAgZGVncmVlcyByZXZlcnNlZC4NCj4gPg0KPiA+ IFRoZSBwcm9ibGVtIHdpdGggZGVmYXVsdCBzY3JpcHQsIGFzIHlvdSBwb2ludCBvdXQsIGlzIHRo YXQgaXQNCj4gPiBwdXRzIHRoZSByZWdpc3RyeSBtYWludGFpbmVycyBpbnRvIGEgcG9zaXRpb24g b2YgaGF2aW5nIHRvDQo+ID4gYWRqdWRpY2F0ZSBhYm91dCBhIGxhbmd1YWdlJ3Mgc2NyaXB0LiAi ZW4iIGlzIGEgdmVyeSBwb29yDQo+ID4gdGVzdCBjYXNlIGJlY2F1c2UgaXQgaXMgbm93aGVyZSBu ZWFyIGFuIGVkZ2UgY2FzZS4NCj4gPg0KPiA+IFRoZSBwcm9ibGVtIGlzIHRoYXQgcmVnaXN0ZXJp bmcgYSBkZWZhdWx0IHNjcmlwdCBmb3IgYQ0KPiA+IGxhbmd1YWdlIGlzIGxpa2UgdHJ5aW5nIHRv IHByb3ZlIGEgbmVnYXRpdmUuIExldCdzIHBpY2sgb24NCj4gPiBTZXJiaWFuIG9yIEF6ZXJiYWlq YW5pIGZvciBhIG1pbnV0ZS4gTGV0J3Mgc2F5IHNvbWVvbmUgdHJpZWQNCj4gPiB0byByZWdpc3Rl ciBhIGRlZmF1bHQgc2NyaXB0IGZvciBvbmUgb2YgdGhlc2UuIFlvdSBjb3VsZA0KPiA+IHBvaW50 IHRvIGFsbCBvZiB0aGUgc3ItQ3lybCBvciBhei1MYXRuIHRleHRzIHlvdSB3YW50LiBUaGF0DQo+ ID4gZG9lc24ndCBwcm92ZSB0aGUgbm9uLWV4aXN0ZW5jZSBvciBub24taW1wb3J0YW5jZSBvZiBv dGhlcg0KPiA+IHNjcmlwdHMgZm9yIHRoYXQgbGFuZ3VhZ2UuIEknbSBjb25jZXJuZWQgdGhhdCBs YXRlcg0KPiA+IHJlZ2lzdHJhdGlvbnMgbWlnaHQgY2F1c2UgYSBuZWVkIGZvciBnZW5lcmFsIHJl dGFnZ2luZyBhbmQNCj4gPiB0aGF0IGlzIEJBRC4NCj4gPg0KPiA+IEZvciB0aGUgcmVnaXN0cnkg cHJvY2VzcyB0byBoYXZlIG1lYW5pbmcsIEkgdGhpbmsgdGhhdCB3ZQ0KPiA+IHNob3VsZCBzdGlj ayB0byB3aGF0IGlzIGFjdHVhbGx5IGRlbW9uc3RyYWJsZTogeW91IGNhbg0KPiA+IHJlZ2lzdGVy IHRoZSBmYWN0IHRoYXQgYSBsYW5ndWFnZSBpcyBjb21tb25seSB3cml0dGVuIGluIHR3bw0KPiA+ IG9yIG1vcmUgc2NyaXB0cyBiZWNhdXNlIHlvdSBjYW4gZGVtb25zdHJhdGUgdGhhdC4gVGhpcyB3 b3VsZA0KPiA+IG1ha2UgdGhlIHJ1bGVzIGFuZCBkZXNpZ24gc2ltcGxlciBhbmQgKmFsc28qIG1h a2UgdGhlIGVudHJpZXMNCj4gPiBtb3JlIHJvYnVzdC4gVGhlIHJ1bGVzIHdvdWxkIHRoZW4gYmU6 DQo+ID4NCj4gPiAxLiBTY3JpcHQgc3VidGFncyBTSE9VTEQgTk9UIGJlIHVzZWQgdG8gZm9ybSBh IGxhbmd1YWdlIHRhZw0KPiA+IHVubGVzcyB0aGV5IGFkZCBzb21lIGRpc3Rpbmd1aXNoaW5nIGlu Zm9ybWF0aW9uLiBGb3IgZXhhbXBsZSwNCj4gPiB0aGUgJ0xhdG4nIHN1YnRhZyBpcyBnZW5lcmFs bHkgdW5uZWNlc3Nhcnkgd2l0aCB0aGUgcHJpbWFyeQ0KPiA+IGxhbmd1YWdlICdlbicgYmVjYXVz ZSBuZWFybHkgYWxsIEVuZ2xpc2ggZG9jdW1lbnRzIGFyZQ0KPiA+IHdyaXR0ZW4gaW4gTGF0aW4g c2NyaXB0Lg0KPiA+DQo+ID4gMi4gVGhlIHNjcmlwdCBzdWJ0YWcgU0hPVUxEIGFsd2F5cyBiZSB1 c2VkIHRvIGZvcm0gYSBsYW5ndWFnZQ0KPiA+IHRhZyB3aGVuIHRoZSBzY3JpcHQgb2YgdGhlIHRh Z2dlZCBjb250ZW50IG1hdGNoZXMgYQ0KPiA+ICdSZXF1aXJlZF9TY3JpcHQnIGZpZWxkIGZvciB0 aGUgYXNzb2NpYXRlZCBwcmltYXJ5IGxhbmd1YWdlLg0KPiA+IEZvciBleGFtcGxlLCB5b3Ugc2hv dWxkIHVzZSB0aGUgJ0hhbnQnIHNjcmlwdCBzdWJ0YWcgdG8gZm9ybQ0KPiA+IHRoZSBsYW5ndWFn ZSB0YWcgInpoLUhhbnQtVFciLCBldmVuIHRob3VnaCBtb3N0IENoaW5lc2UNCj4gPiBsYW5ndWFn ZSBkb2N1bWVudHMgaW4gVGFpd2FuIGFyZSB3cml0dGVuIGluIHRoZSBUcmFkaXRpb25hbA0KPiA+ IENoaW5lc2Ugc2NyaXB0LiBUaGUgJ1JlcXVpcmVkX1NjcmlwdCcgZmllbGQgZ2VuZXJhbGx5IGFw cGVhcnMNCj4gPiBpbiBwcmltYXJ5IGxhbmd1YWdlcyB0aGF0IGFyZSB3cml0dGVuIGluIG1vcmUg dGhhbiBvbmUgc2NyaXB0DQo+ID4gYW5kIHdoaWNoIG1pZ2h0IG90aGVyd2lzZSBiZSBhbWJpZ3Vv dXMuDQo+ID4NCj4gPiBJT1csIEkgYWRkZWQgc2NyaXB0IHN1cHByZXNzaW9uIGFzIGEgc29wIHRv IGRlZmF1bHQgc2NyaXB0LCBhDQo+ID4gY29uY2VwdCB0aGF0IGlzIGVhc3kgdG8gdW5kZXJzdGFu ZCBhbmQgc2VlbXMgZGVzaXJhYmxlLCBidXQNCj4gPiB3aGljaCBtYXkgYmUgZGlmZmljdWx0IHRv IG1haW50YWluIGluIHByYWN0aWNlIChzZWUgYWxsIHRoZQ0KPiA+IGRlcHJlY2F0ZWQgcHJpbWFy eSBsYW5ndWFnZSByZWdpc3RyYXRpb25zIGZvciBleGFtcGxlcyBvZiB0aGUNCj4gPiByZWdpc3Ry YXRpb24gcHJvY2VzcyBiZWluZyB1c2VkIGluIHVucHJvZHVjdGl2ZSB3YXlzKS4NCj4gPg0KPiA+ IEJlc3QgUmVnYXJkcywNCj4gPg0KPiA+IEFkZGlzb24NCj4gPg0KPiA+IEFkZGlzb24gUC4gUGhp bGxpcHMNCj4gPiBHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCj4gPiBD aGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KPiA+DQo+ ID4gSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCj4gPiBJdCBpcyBhbiBh cmNoaXRlY3R1cmUuDQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g PiBGcm9tOiBsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmcNCj4gPiBbbWFpbHRvOmx0cnUtYm91 bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gPiA+IEJlaGFsZiBPZiBEb3VnIEV3ZWxsDQo+ID4g PiBTZW50OiBkaW1hbmNoZSAxNyBhdnJpbCAyMDA1IDAxOjA1DQo+ID4gPiBUbzogTFRSVSBXb3Jr aW5nIEdyb3VwDQo+ID4gPiBTdWJqZWN0OiBbTHRydV0gUmU6IFByb3Bvc2VkIFRleHQgZm9yIE1v dmluZyBGb3J3YXJkDQo+ID4gPg0KPiA+ID4gQWRkaXNvbiBQaGlsbGlwcyA8YWRkaXNvbiBkb3Qg cGhpbGxpcHMgYXQgcXVlc3QgZG90IGNvbT4gd3JvdGU6DQo+ID4gPg0KPiA+ID4gPiBJIGFncmVl LCBNYXJrLCB0aGF0IHRoZSBmdWxsIGVmZmVjdCBjYW4gYmUgYWNoaWV2ZWQgd2l0aCBvbmx5IG9u ZQ0KPiA+ID4gPiBmaWVsZCBhbmQgdGhhdCB5b3VyIHByb3Bvc2FsIGlzIHN1cGVyaW9yIGluIGEg bnVtYmVyIG9mDQo+ID4gcmVnYXJkcyAoZmV3ZXINCj4gPiA+ID4gbW92aW5nIHBhcnRzLCBlYXNl IG9mIG1haW50ZW5hbmNlLCBlYXNlIG9mIGFwcGxpY2F0aW9uKS4NCj4gPiA+ID4NCj4gPiA+ID4g SSBwcm9wb3NlZCB0d28sIHRob3VnaCwgZm9yIGEgcmVhc29uLiBPbmUgb2YgdGhlDQo+ID4gb2Jq ZWN0aW9ucyB3YXMgdGhhdA0KPiA+ID4gPiB3ZSBkaWRuJ3QgZG9jdW1lbnQgd2hlbiBhIHBhcnRp Y3VsYXIgc2NyaXB0IHJlYWxseSBvdWdodA0KPiA+IHRvIGJlIHVzZWQNCj4gPiA+ID4gKGkuZS4g dGhhdCB5b3UgcmVhbGx5IHNob3VsZCBzdGFydCB0byB1c2UgemgtSGFuWC1YWCBpbg0KPiA+IHBy ZWZlcmVuY2UgdG8NCj4gPiA+ID4gemgtWFgpLg0KPiA+ID4NCj4gPiA+IEkga25vdyBJIHNhaWQg SSB3b3VsZCBiYWNrIG9mZiBhbmQgbm90IGdldCBpbnZvbHZlZCBpbiB0aGUNCj4gPiA+IGRlZmF1 bHQtc2NyaXB0IGlzc3VlLiAgT0ssIHNvIEkgbGllZC4gIFNvcnJ5IGFib3V0IHRoYXQuDQo+ID4g Pg0KPiA+ID4gQUZBSUNULCB0aGlzIHdob2xlIGlzc3VlIHN0YXJ0ZWQgd2l0aCB0aGUgY29uY2Vy biB0aGF0DQo+ID4gcGVvcGxlIHdvdWxkIHVzZQ0KPiA+ID4gYSBzY3JpcHQgc3VidGFnIGluIGNh c2VzIHdoZXJlIGl0IHdhcyBnZW5lcmFsbHkgdGhvdWdodCB0byBiZSAoYSkNCj4gPiA+IHVubmVj ZXNzYXJ5LCBiZWNhdXNlIHRoZSBpbnRlbmRlZCBzY3JpcHQgd291bGQgYmUgb2J2aW91cywgYW5k IChiKQ0KPiA+ID4gdW5kZXNpcmFibGUsIGJlY2F1c2UgaXQgd291bGQgaW50ZXJmZXJlIHdpdGgg bGVmdC1wcmVmaXgNCj4gPiAoUkZSKSBtYXRjaGluZy4NCj4gPiA+DQo+ID4gPiBUaGUgc3RhbmRh cmQgZXhhbXBsZSB3YXMgImVuLUxhdG4tVVMuIiAgVGhlIGNhc2Ugd2FzIG1hZGUgdGhhdCB0aGUN Cj4gPiA+IG92ZXJ3aGVsbWluZyBtYWpvcml0eSBvZiB3cml0dGVuIFUuUy4gRW5nbGlzaCB0ZXh0 IGlzIHdyaXR0ZW4gaW4gdGhlDQo+ID4gPiBMYXRpbiBzY3JpcHQsIHNvIHRoZSBhZGRlZCBmbGV4 aWJpbGl0eSBvZiBiZWluZyBhYmxlIHRvIHNwZWNpZnkgdGhlDQo+ID4gPiBzY3JpcHQgd291bGQg YmUgbGFyZ2VseSB1bm5lY2Vzc2FyeSwgYW5kIGluIHBhcnRpY3VsYXIgaXQgd291bGQgYmUNCj4g PiA+IG92ZXJzaGFkb3dlZCBieSB0aGUgaW5hYmlsaXR5IG9mIGV4aXN0aW5nIGxlZnQtcHJlZml4 IG1hdGNoaW5nDQo+ID4gPiBhbGdvcml0aG1zIHRvIG1hdGNoICJlbi1MYXRuLVVTIiB3aXRoICJl bi1VUyIgKHNvbWV0aW1lcw0KPiA+IGdlbmVyYWxpemVkIHRvDQo+ID4gPiAiYnJva2VuIGJhY2t3 YXJkIGNvbXBhdGliaWxpdHkiKS4NCj4gPiA+DQo+ID4gPiBUaGlzIHdhcyB0aGUgZm91bmRhdGlv biBvZiAiZGVmYXVsdCBzY3JpcHQiOiBjZXJ0YWluIGxhbmd1YWdlcyBsaWtlDQo+ID4gPiBFbmds aXNoIGNvdWxkIGJlIGxpc3RlZCBhcyBoYXZpbmcgYSBkZWZhdWx0IHNjcmlwdCBvZg0KPiA+IExh dGluLCBzbyB0aGF0IHRhZw0KPiA+ID4gZ2VuZXJhdG9ycyBjb3VsZCBhdm9pZCBjcmVhdGluZyB0 YWdzIGxpa2UgImVuLUxhdG4iIG9yICJlbi1MYXRuLVVTIg0KPiA+ID4gd2hvc2UgZGlzYWR2YW50 YWdlcyB3b3VsZCBvdXR3ZWlnaCB0aGVpciBhZHZhbnRhZ2VzLg0KPiA+ID4NCj4gPiA+IE9mIGNv dXJzZSwgaW4gY2VydGFpbiBjaXJjdW1zdGFuY2VzIHlvdSBtaWdodCBoYXZlIEVuZ2xpc2gNCj4g PiB3cml0dGVuIGluDQo+ID4gPiBCcmFpbGxlLCBvciBldmVuIGluIEN5cmlsbGljLCBhbmQgbW9z dCBpZiBub3QgYWxsIHNlZW1lZCB0bw0KPiA+IGFncmVlIHRoYXQNCj4gPiA+IGluIHRoZXNlIHJh cmUgY2lyY3Vtc3RhbmNlcyBpdCB3b3VsZCBiZSBhY2NlcHRhYmxlIHRvIGdlbmVyYXRlDQo+ID4g PiAiZW4tQnJhaS13aGF0ZXZlciIgb3IgImVuLUN5cmwtd2hhdGV2ZXIuIg0KPiA+ID4NCj4gPiA+ IFRoZSBzdGFuZGFyZCBjb3VudGVyZXhhbXBsZXMgd2VyZSAiemgtSGFucyIgYW5kICJ6aC1IYW50 LiINCj4gPiBUaGUgY2FzZSB3YXMNCj4gPiA+IG1hZGUgdGhhdCBDaGluZXNlIGlzIGNvbW1vbmx5 IHdyaXR0ZW4gaW4gYm90aCBvZiB0aGVzZQ0KPiA+IHNjcmlwdCB2YXJpYW50cywNCj4gPiA+IGFu ZCBpdCB3b3VsZCBvZnRlbiBiZSBiZW5lZmljaWFsIHRvIGluY2x1ZGUgc2NyaXB0DQo+ID4gaW5m b3JtYXRpb24sIHRvIHRoZQ0KPiA+ID4gcG9pbnQgb2YgcGVyaGFwcyBiZWluZyBtb3JlIGltcG9y dGFudCB0aGFuIHN0cmljdCBjb21wYXRpYmlsaXR5IHdpdGgNCj4gPiA+IGxlZnQtcHJlZml4IG1h dGNoaW5nIGFsZ29yaXRobXMuICBMYW5ndWFnZXMgbGlrZSBDaGluZXNlDQo+ID4gYW5kIEF6ZXJi YWlqYW5pDQo+ID4gPiBhbmQgU2VyYmlhbiwgYWZ0ZXIgYWxsLCB3ZXJlIHRoZSBtYWpvciB1c2Ug Y2FzZXMgZm9yIHRoZQ0KPiA+IGludHJvZHVjdGlvbiBvZg0KPiA+ID4gc2NyaXB0IHN1YnRhZ3Mg aW4gdGhlIGZpcnN0IHBsYWNlLg0KPiA+ID4NCj4gPiA+IFNvIHVubGlrZSAiZW4tTGF0biIsIGl0 IHdvdWxkIG5vdCBiZSBkaXNjb3VyYWdlZCB0byB3cml0ZQ0KPiA+ICJ6aC1IYW5zIiBvcg0KPiA+ ID4gInpoLUhhbnQiLCBvciBlaXRoZXIgb2YgdGhlc2UgZm9sbG93ZWQgYnkgYSByZWdpb24gc3Vi dGFnLg0KPiA+IE9mIGNvdXJzZSwNCj4gPiA+IGp1c3QgbGlrZSBFbmdsaXNoLCBDaGluZXNlIGNv dWxkIGFsc28gYmUgd3JpdHRlbiBpbiBhIGxlc3Mgb2J2aW91cw0KPiA+ID4gc2NyaXB0IGxpa2Ug QnJhaWxsZSBvciBDeXJpbGxpYywgYW5kIHNvICJ6aC1CcmFpIiBhbmQNCj4gPiAiemgtQ3lybCIg b3VnaHQgdG8NCj4gPiA+IGJlIGFsbG93ZWQgYXMgd2VsbC4NCj4gPiA+DQo+ID4gPiBJIGNvbmNl ZGUgdGhhdCBiZWNhdXNlIG9mIHRoZSBzdGF0ZWQgcHJlZG9taW5hbmNlIG9mDQo+ID4gcHJvY2Vz c2VzIHRoYXQgdXNlDQo+ID4gPiBsZWZ0LXByZWZpeCBtYXRjaGluZywgaXQgbWlnaHQgYmUgYmVu ZWZpY2lhbCB0byBkZWZpbmUgYQ0KPiA+IGRlZmF1bHQgc2NyaXB0DQo+ID4gPiBmb3IgY29tbW9u IGxhbmd1YWdlcyB0aGF0IGFyZSB3cml0dGVuIGluIGEgc2luZ2xlIHNjcmlwdA0KPiA+IDk5Ljkl IG9mIHRoZQ0KPiA+ID4gdGltZS4gIEkgc3RpbGwgZG9uJ3Qga25vdyB3aGVyZSB0aGUgYXV0aG9y aXR5IGNvbWVzIGZyb20gdG8NCj4gPiBkZWNpZGUgd2hpY2gNCj4gPiA+IGxhbmd1YWdlcyBhbmQg d2hpY2ggc2NyaXB0cyBnZXQgbWFya2VkIGluIHRoaXMgd2F5IC0tIGRlZmluaXRlbHkgbm90DQo+ ID4gPiBmcm9tIElTTyBvciBkb2N1bWVudGVkIHJlZ2lzdHJhdGlvbnMgb3IgZGV0ZXJtaW5pc3Rp YyBydWxlcywgbGlrZQ0KPiA+ID4gZXZlcnl0aGluZyBlbHNlIGluIHRoZSByZWdpc3RyeSAtLSBi dXQgSSBhc3N1bWUgdGhhdCB3b3VsZA0KPiA+IGJlIHdvcmtlZCBvdXQNCj4gPiA+IGluIGR1ZSBj b3Vyc2UuDQo+ID4gPg0KPiA+ID4gV2hhdCBJIGRvIE5PVCB1bmRlcnN0YW5kIGlzIGhvdyB0aGlz IGhhcyBleHBhbmRlZCB0bw0KPiA+IHRlbGxpbmcgcGVvcGxlIHdoZW4NCj4gPiA+IHRoZXkgU0hP VUxEIHVzZSBzY3JpcHQgc3VidGFncywgYW5kIGhvdyB0aGUgc2V0IG9mIGFsbG93YWJsZSBzdWJ0 YWdzDQo+ID4gPiBzaG91bGQgYmUgbGltaXRlZCBpbiBzb21lIHdheS4NCj4gPiA+DQo+ID4gPiBU aGVyZSBtYXkgd2VsbCBiZSBjYXNlcyB3aGVyZSAiemgiIG9yICJ6aC1DTicgb3IgInpoLVRXIiBp cw0KPiA+IGFsbCB0aGF0IGlzDQo+ID4gPiBuZWVkZWQsIGFuZCB0aGVyZSBpcyBjZXJ0YWlubHkg ZXhpc3RpbmcgZGF0YSB0aGF0IHVzZXMgc3VjaCB0YWdzLiAgSQ0KPiA+ID4gZG9uJ3Qgc2VlIGFu eSBqdXN0aWZpY2F0aW9uIGZvciBkaXNjb3VyYWdpbmcgc3VjaCB1c2FnZSwNCj4gPiBldmVuIGlm IHdlIGhhdmUNCj4gPiA+IGRlZmluZWQgYSB3YXkgdG8gdGFnIENoaW5lc2UgZGF0YSBtb3JlIHBy ZWNpc2VseS4NCj4gPiBMaWtld2lzZSwgaWYgdGhlcmUgaXMNCj4gPiA+IG5vIHByb2hpYml0aW9u IGFnYWluc3Qgd3JpdGluZyAiZW4tQnJhaSIgb3IgImVuLUN5cmwiLCB0aGVuIEkgc2VlIG5vDQo+ ID4gPiByZWFzb24gdG8gcHJvaGliaXQgb3IgZGlzY291cmFnZSAiemgtQnJhaSIgb3IgInpoLUN5 cmwiIGVpdGhlci4gIEENCj4gPiA+ICJyZXF1aXJlZC1zY3JpcHQiIGZpZWxkIHdvdWxkIGRvIGV4 YWN0bHkgdGhpcywgYnkgbGlzdGluZyAnSGFucycgYW5kDQo+ID4gPiAnSGFudCcgYnV0IG5vdCBv dGhlcnMuDQo+ID4gPg0KPiA+ID4gVGhpcyBpcyB0b28gcHJlc2NyaXB0aXZlLiAgSXQgdGVsbHMg cGVvcGxlIGhvdyB0aGV5IFNIT1VMRA0KPiA+IHRhZyBkYXRhLCBub3QNCj4gPiA+IGp1c3QgaW4g dGVybXMgb2YgInRhZyBjb250ZW50IHdpc2VseSIgb3IgImRvbid0IGJlDQo+ID4gZXhjZXNzaXZl bHkgcHJlY2lzZSwiDQo+ID4gPiBidXQgb24gYSBzcGVjaWZpYyBsYW5ndWFnZS1ieS1sYW5ndWFn ZSBiYXNpcy4gIEl0IGFzc3VtZXMsDQo+ID4gaW1wbGljaXRseSwNCj4gPiA+IHRoYXQgdGhpcyBn cm91cCBvciBpZXRmLWxhbmd1YWdlcyBoYXMgdGhlIGV4cGVydGlzZSBhbmQgYXV0aG9yaXR5IHRv DQo+ID4gPiBtYWtlIHRoaXMganVkZ21lbnQuICBVbmxpa2UgZGVmYXVsdC1zY3JpcHQsIHJlcXVp cmVkLXNjcmlwdA0KPiA+IGRvZXMgbm90aGluZw0KPiA+ID4gdG8gc29sdmUgdGhlIGxlZnQtcHJl Zml4IG1hdGNoaW5nIHByb2JsZW0sIGFuZCBhcyBzdWNoLCBJDQo+ID4gZG9uJ3QgdGhpbmsNCj4g PiA+IGl0J3Mgd2l0aGluIHRoZSBzY29wZSBvZiB0aGUgY2hhcnRlci4NCj4gPiA+DQo+ID4gPiBJ IHByb3Bvc2UgdGhlIGZvbGxvd2luZzoNCj4gPiA+DQo+ID4gPiAxLiAgQW4gb3B0aW9uYWwsIGlu Zm9ybWF0aXZlIGRlZmF1bHQtc2NyaXB0IGZpZWxkIHRoYXQNCj4gPiB3b3VsZCBzdWdnZXN0IHRv DQo+ID4gPiB0YWcgZ2VuZXJhdG9ycyB0aGF0IHRoZXkgbm90IHVzZSB0aGF0IHBhcnRpY3VsYXIg c2NyaXB0DQo+ID4gc3VidGFnIHRvZ2V0aGVyDQo+ID4gPiB3aXRoIHRoYXQgcGFydGljdWxhciBs YW5ndWFnZSBzdWJ0YWcuICBUaGlzIGZpZWxkIGNvdWxkIGJlIGFkZGVkLA0KPiA+ID4gY2hhbmdl ZCwgb3IgcmVtb3ZlZCBhdCBhbnkgdGltZS4gIChJdCBkb2Vzbid0IG1hdHRlciBtdWNoDQo+ID4g d2hhdCB0aGUgZmllbGQNCj4gPiA+IGlzIGNhbGxlZCwgYW5kIEkgcmVuZXcgbXkgc3VnZ2VzdGlv biB0aGF0IHdlIG5vdCB0cnkgdG8NCj4gPiBpbmplY3QgdG9vIG11Y2gNCj4gPiA+IGRlZXAgbWVh bmluZyBpbnRvIHRoZSBuYW1lcyBvZiBmaWVsZHMsIG9yIGFzc3VtZSB0aGF0IHVzZXJzDQo+ID4g d2lsbCBkZXJpdmUNCj4gPiA+IGRlZXAgbWVhbmluZyBmcm9tIHRoZW0uKQ0KPiA+ID4NCj4gPiA+ IDIuICBOTyByZXF1aXJlbWVudCB3aXRoaW4gdGhlIGRyYWZ0IHRoYXQgdGFnIGdlbmVyYXRvcnMN Cj4gPiAibXVzdCBub3QiIHVzZQ0KPiA+ID4gc2NyaXB0IHN1YnRhZ3MgaW4gYW55IGdpdmVuIHNj ZW5hcmlvLiAgVGhlIHRleHQgaW4gZHJhZnQtMDEgdGhhdA0KPiA+ID4gZGlzY291cmFnZXMgdGhl IHVzZSBvZiBhIHNjcmlwdCBzdWJ0YWcgInVubGVzcyBpdCBjb252ZXlzIGFkZGl0aW9uYWwNCj4g PiA+IGluZm9ybWF0aW9uIiBzaG91bGQgYmUgYWRlcXVhdGUuDQo+ID4gPg0KPiA+ID4gMy4gIE5P IG1lY2hhbmlzbSB0byB0ZWxsIHRhZyBnZW5lcmF0b3JzIHRoYXQgdGhleSAic2hvdWxkIg0KPiA+ IHVzZSBhIHNjcmlwdA0KPiA+ID4gc3VidGFnIHRvZ2V0aGVyIHdpdGggYW55IHBhcnRpY3VsYXIg bGFuZ3VhZ2Ugc3VidGFnLCBhbmQNCj4gPiAqZXNwZWNpYWxseSoNCj4gPiA+IG5vdCBvbmUgdGhh dCBsaXN0cyB0aGUgImV4cGVjdGVkIiBzY3JpcHQgc3VidGFncyB3aGlsZQ0KPiA+IGV4Y2x1ZGlu ZyBvdGhlcnMuDQo+ID4gPiBJZiB0YWcgZ2VuZXJhdG9ycyBvcHQgdG8gY3JlYXRlIGEgdGFnIHN1 Y2ggYXMgInpoLVRXIiB0aGF0ICJtYXkgYmUNCj4gPiA+IGFtYmlndW91cyB3aXRob3V0IHNjcmlw dCBpbmZvcm1hdGlvbiwiIHRoYXQgc2hvdWxkIGJlIHVwIHRvIHRoZW0uDQo+ID4gPg0KPiA+ID4g LURvdWcgRXdlbGwNCj4gPiA+ICBGdWxsZXJ0b24sIENhbGlmb3JuaWENCj4gPiA+ICBodHRwOi8v dXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gTHRy dSBtYWlsaW5nIGxpc3QNCj4gPiA+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCj4gPg0KPiA+DQoNCg== --===============1602798709== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1602798709==-- From ltru-bounces@lists.ietf.org Sun Apr 17 19:33:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNJGf-0003QW-Bj; Sun, 17 Apr 2005 19:33:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNJGe-0003QR-09 for ltru@megatron.ietf.org; Sun, 17 Apr 2005 19:33:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03445 for ; Sun, 17 Apr 2005 19:33:28 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNJRL-0000un-EN for ltru@ietf.org; Sun, 17 Apr 2005 19:44:35 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 17 Apr 2005 16:33:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed Text for Moving Forward Date: Sun, 17 Apr 2005 16:33:19 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DC6E@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVDjwQ3jqQecB3tRweVwvGNj7ieqgAFgkEQ From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 17 Apr 2005 23:33:20.0405 (UTC) FILETIME=[D6E6EC50:01C543A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Okay, so we put suppress back for the reasons I put it in there in the = first place. Never mind my contributions to this weekend's thread. :-) > The "because" doesn't work with undocumented "suppress_script" > concepts. I didn't know that Goth is _not_ the default for > got, I also didn't know that Latn is _not_ the default for yi. Yes, I see that. You are trying to achieve clarity in tag choice (trying = to limit the cases in which content authors must "guess" whether to use = the script or not). What you aim to do can *only* be done if you = document both sides of the equation (require and suppress). If we try to short one side or the other, we will end up with a larger = set of nebulous cases, which is apparently the sticking point. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: dimanche 17 avril 2005 13:46 > To: ltru@ietf.org > Subject: [Ltru] Re: Proposed Text for Moving Forward >=20 > Addison Phillips wrote: >=20 > > 1. Script subtags SHOULD NOT be used to form a language tag > > unless they add some distinguishing information. For example, > > the 'Latn' subtag is generally unnecessary with the primary > > language 'en' because nearly all English documents are > > written in Latin script. >=20 > The "because" doesn't work with undocumented "suppress_script" > concepts. I didn't know that Goth is _not_ the default for > got, I also didn't know that Latn is _not_ the default for yi. >=20 > Now after John mentioned it the latter is convincing, I don't > even bother to check it. OTOH it's clear that all yi content > I've seen so far was yi-Latn, my knowledge of Hebrew is limited > to what I needed to read mathematical texts (=3D mainly "aleph"). >=20 > > 2. The script subtag SHOULD always be used to form a language > > tag when the script of the tagged content matches a > > 'Required_Script' field for the associated primary language. >=20 > Less convincing, in a hrefang=3D to a WAV or MP3 I don't need any > Hans or Hant. As far as I'm concerned the only function of the > "required_script" field is to block erroneous registrations of > a "suppress_script" for the same language (if you say so in the > rules for these fields). > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 19:35:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNJIr-0003eX-0T; Sun, 17 Apr 2005 19:35:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNJIq-0003eS-HT for ltru@megatron.ietf.org; Sun, 17 Apr 2005 19:35:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03568 for ; Sun, 17 Apr 2005 19:35:45 -0400 (EDT) Received: from mta11.adelphia.net ([68.168.78.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNJTX-0000zG-5u for ltru@ietf.org; Sun, 17 Apr 2005 19:46:52 -0400 Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050417233533.HSBH5402.mta11.adelphia.net@DEWELL> for ; Sun, 17 Apr 2005 19:35:33 -0400 Message-ID: <001c01c543a6$1d219760$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: Proposed Text for Moving Forward Date: Sun, 17 Apr 2005 16:35:16 -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.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org McDonald, Ira wrote: > Sigh...until this message we had an emerging concensus. I thought you were one of the primary objectors to excessive use of script subtags. Now you're supporting an invention that tells tag generators when they MUST insert a script subtag? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 19:40:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNJMx-00046K-8X; Sun, 17 Apr 2005 19:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNJMu-00046D-Uo for ltru@megatron.ietf.org; Sun, 17 Apr 2005 19:40:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04031 for ; Sun, 17 Apr 2005 19:39:59 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNJXc-00019H-J2 for ltru@ietf.org; Sun, 17 Apr 2005 19:51:04 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 17 Apr 2005 16:39:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Proposed Text for Moving Forward Date: Sun, 17 Apr 2005 16:39:50 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DC6F@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVDiTe8HnoBwz0/TBiSqokUnp7UZAAHPf9A From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 17 Apr 2005 23:39:51.0757 (UTC) FILETIME=[C02A7FD0:01C543A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Well, one might register scripts in which a language is never written, I = suppose...... The problem is when you name the field something other than suppress (or = choose your synonym) and have it give the impression that it is a script = commonly used to write the language. Then you get: Zh (commonly written with 'hant' and 'hans') And you're counting the fields in order to know whether you should use = the script. So if someone registers a second script then you get to = retag all of your data (bad). Suppress's rules as I put them down only said that require trumps = suppress and the require set of subtags must be disjoint from the = suppress set. We could allow only one suppress easily enough. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: dimanche 17 avril 2005 13:07 > To: ltru@ietf.org > Subject: [Ltru] Re: Proposed Text for Moving Forward >=20 > McDonald, Ira wrote: >=20 > > +1 > > Thanks for some good clear thought for a change. I agree > > that I hated this counting the field members approach. >=20 > I still don't get the idea of more than one "suppress_script" > for the same language, how's that supposed to work ? >=20 > Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 20:27:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNK6e-0001Gi-JQ; Sun, 17 Apr 2005 20:27:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNK6d-0001Gd-6D for ltru@megatron.ietf.org; Sun, 17 Apr 2005 20:27:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06433 for ; Sun, 17 Apr 2005 20:27:12 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNKHJ-0003TR-HX for ltru@ietf.org; Sun, 17 Apr 2005 20:38:18 -0400 Received: from h-64-105-34-127.snvacaid.dynamic.covad.net ([64.105.34.127] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DNK6V-0004SG-00 for ltru@ietf.org; Sun, 17 Apr 2005 17:27:08 -0700 Message-ID: <009e01c543ad$936685a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08DC6F@irvmbxw01.quest.com> Date: Sun, 17 Apr 2005 17:28:42 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Subject: [Ltru] Supress & Require Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - This discussion has cycled a few times, and I'd like to see whether I understand where we are. I'm not proclaiming consensus yet, but just testing the waters, hoping that someone will post a chunk of text (like the helpful proposals in the "Proposed Text for Moving Forward" thread) that we can agree to. 1) a general consensus has emerged that the "supress_script" concept is helpful, though it might be good to find a better name it. "implicit_script" has been suggested and found some support. "default script" is strongly opposed, and seems to trigger ratholes. We might even belabor the point with something like "do_not_tag_script". :-) * 0.5 2) there seems to be general support for wording the guidelines on the use of script subtags fairly strongly, using "MUST ... except" rather than "SHOULD" and giving clear rationale for why they'd work the way that is proposed. An important part of this rationale is coping with material that has already been tagged, and another important part of this rationale is the desire to work with existing matching algorithms. 3) it's less clear to me whether we're getting a consensus on "require_script". There were clear cases where a "supress_script" was needed to prevent implementors from doing the "obvious" (but undesirable) thing with languages like Yiddish and Gothic. For "require_script", it seems that the zh-Hant / zh-Hans cases appear to be the favored examples. (Presumably because the non-specialist wouldn't know that the distinction needs to be made. However, this leads to the question of whether the non-specialist who is tagging material would be able to tell the difference. Do we care?) Have I missed something major? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 20:49:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNKRg-0002WF-82; Sun, 17 Apr 2005 20:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNKRe-0002WA-LX for ltru@megatron.ietf.org; Sun, 17 Apr 2005 20:48:59 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07706 for ; Sun, 17 Apr 2005 20:48:56 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNKNo-0002QE-DN for ltru@lists.ietf.org; Mon, 18 Apr 2005 02:45:00 +0200 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 02:45:00 +0200 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 02:45:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 18 Apr 2005 02:46:04 +0200 Organization: Lines: 22 Message-ID: <4263034C.77AE@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B08DC6E@irvmbxw01.quest.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.1 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Proposed Text for Moving Forward X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > What you aim to do can *only* be done if you document both > sides of the equation (require and suppress). I've no serious problems with required_script, but from my POV it's not strictly necessary, unlike suppress_script. If the only idea of required_script is to block erroneous attempts to get a suppress_script, you could also define a "Multiscript: 1". Of course that's too ugly to consider it, but it illustrates my POV on required_script. > If we try to short one side or the other, we will end up > with a larger set of nebulous cases, which is apparently the > sticking point. We only want to get rid of an explicit Latn for languages like en, got, fy, or an explicit Cyrl for ru, etc. That's why I don't understand the idea of more than one suppress_script for the same language, IMO that should not be allowed. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 21:27:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNL2S-0006t2-6R; Sun, 17 Apr 2005 21:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNL2Q-0006su-84 for ltru@megatron.ietf.org; Sun, 17 Apr 2005 21:26:58 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09820 for ; Sun, 17 Apr 2005 21:26:55 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNKyP-0004wX-6U for ltru@lists.ietf.org; Mon, 18 Apr 2005 03:22:49 +0200 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 03:22:49 +0200 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 03:22:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 18 Apr 2005 03:25:36 +0200 Organization: Lines: 10 Message-ID: <42630C90.2602@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B08DC6F@irvmbxw01.quest.com> <009e01c543ad$936685a0$7f1afea9@oemcomputer> 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.1 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Supress & Require Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > 2) there seems to be general support for wording the > guidelines on the use of script subtags fairly strongly, > using "MUST ... except" rather than "SHOULD" Only "rough consensus" for the proposed "MUST NOT ... unless", see - I'd like a "SHOULD NOT ..." without "unless" clause better. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 23:00:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNMUi-0005rx-89; Sun, 17 Apr 2005 23:00:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNMUg-0005rs-4T for ltru@megatron.ietf.org; Sun, 17 Apr 2005 23:00:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14216 for ; Sun, 17 Apr 2005 23:00:11 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNMfO-0001ZC-EU for ltru@ietf.org; Sun, 17 Apr 2005 23:11:19 -0400 Received: from h-64-105-34-127.snvacaid.dynamic.covad.net ([64.105.34.127] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DNMUc-0003gp-00 for ltru@ietf.org; Sun, 17 Apr 2005 20:00:11 -0700 Message-ID: <000c01c543c2$f5c6f3a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08DC6F@irvmbxw01.quest.com><009e01c543ad$936685a0$7f1afea9@oemcomputer> <42630C90.2602@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Supress & Require Script Date: Sun, 17 Apr 2005 20:01:46 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Sunday, April 17, 2005 6:25 PM > Subject: [Ltru] Re: Supress & Require Script > > Randy Presuhn wrote: > > > 2) there seems to be general support for wording the > > guidelines on the use of script subtags fairly strongly, > > using "MUST ... except" rather than "SHOULD" > > Only "rough consensus" for the proposed "MUST NOT ... unless", > see - I'd like > a "SHOULD NOT ..." without "unless" clause better. Bye, Frank ... My personal opinion... There *is* a difference between the construct "MUST NOT x unless Y" and the construct "SHOULD NOT x". Any "good reason" Z could be claimed by an implementor as justification for violating the latter. In the case of the former, Z would be a justification only if it also satisfied condition Y. However, I admit that Y could be so broad as to render the whole thing logically equivalent to a SHOULD. More important than technical difference between the two in this case would be the perception of the strength of the warning. If folks want to willfully mis-interpret a specification, that's their problem, there's little we can do about it. We can, however, make the specification painfully clear on the points where we're particularly worried about mis-implementation, either due to the likelihood of error or the gravity of the consequences. It's harder for an implementor to mistakenly violate a "MUST NOT x unless Y" than a "SHOULD NOT x", even when a logician might say they're the same. As co-chair: *if* "MUST NOT x unless Y" gets us a rough consensus, and "SHOULD NOT x" breaks that rough consensus, then the choice is clear to me, and I'd be willing to defend it if asked by the IESG whether we're in line with RFC 2119. But at this moment I'm still trying to see whether this discussion has converged. A general question: are we at least agreed that this is a case where we want the document to give a clear rationale for the recommended behaviour? (as contributor): It sounds like we have several examples where we know the desired behaviour and how to get that behaviour with supress_script, where the "naive" implementor would, in the absence of supress_script, likely do the wrong thing. Including these examples might be helpful. If we agree on require_script, we should probably do the same for it. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 17 23:44:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNNBc-00015N-4o; Sun, 17 Apr 2005 23:44:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNNBb-00015I-0I for ltru@megatron.ietf.org; Sun, 17 Apr 2005 23:44:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17058 for ; Sun, 17 Apr 2005 23:44:31 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNNMJ-0004b5-6K for ltru@ietf.org; Sun, 17 Apr 2005 23:55:40 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3I3iN4I589836 for ; Sun, 17 Apr 2005 23:44:23 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3I3iMst356920 for ; Sun, 17 Apr 2005 21:44:22 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3I3iMlr018083 for ; Sun, 17 Apr 2005 21:44:22 -0600 Received: from markdavis (sig-9-48-121-81.mts.ibm.com [9.48.121.81]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3I3iLbW018078; Sun, 17 Apr 2005 21:44:22 -0600 Message-ID: <016901c543c8$e712db20$467a3009@sanjose.ibm.com> From: "Mark Davis" To: , "Frank Ellermann" References: <634978A7DF025A40BFEF33EB191E13BC0B08DC6F@irvmbxw01.quest.com><009e01c543ad$936685a0$7f1afea9@oemcomputer> <42630C90.2602@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Supress & Require Script Date: Sun, 17 Apr 2005 20:44:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j3I3iN4I589836 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org It sounds to me like we have rough consensus for suppress_script SHOULD NOT (but maybe a follow-on sentence or so) no real need for required_script =E2=80=8EMark ----- Original Message -----=20 From: "Frank Ellermann" To: Sent: Sunday, April 17, 2005 18:25 Subject: [Ltru] Re: Supress & Require Script > Randy Presuhn wrote: > > > 2) there seems to be general support for wording the > > guidelines on the use of script subtags fairly strongly, > > using "MUST ... except" rather than "SHOULD" > > Only "rough consensus" for the proposed "MUST NOT ... unless", > see - I'd like > a "SHOULD NOT ..." without "unless" clause better. Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 00:03:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNNTx-0001vU-JA; Mon, 18 Apr 2005 00:03:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNNTu-0001vM-7M for ltru@megatron.ietf.org; Mon, 18 Apr 2005 00:03:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18186 for ; Mon, 18 Apr 2005 00:03:27 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNNee-0005ha-0e for ltru@ietf.org; Mon, 18 Apr 2005 00:14:36 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 17 Apr 2005 21:03:19 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sun, 17 Apr 2005 21:03:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Supress & Require Script Date: Sun, 17 Apr 2005 21:03:25 -0700 Message-ID: Thread-Topic: [Ltru] Supress & Require Script Thread-Index: AcVDr1TTFkYSvTHxSsCt4Nt1i9zoQQAGV81A From: "Peter Constable" To: X-OriginalArrivalTime: 18 Apr 2005 04:03:18.0231 (UTC) FILETIME=[8D8F0670:01C543CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > I'm ... just testing the waters... > 1) a general consensus has emerged that the "supress_script" > concept is helpful... I agree, whatever the name (IMO, "suppress_script" or "implicit_script" are better than "default_script"). > 2) there seems to be general support for wording the guidelines > on the use of script subtags fairly strongly, using "MUST ... except" > rather than "SHOULD" and giving clear rationale for why they'd > work the way that is proposed... I've no strong preference between "MUST... except" or a strong "SHOULD"; I agree on inclusion of rational. > 3) it's less clear to me whether we're getting a consensus on > "require_script"... I'm not convinced of the need, and lean toward excluding this, but am not strongly opposed. One thought about a possible option moving forward: the reason for identifying suppress_script cases is to ensure desired functionality with existing implementations and usage of tags such as en-GB, de-DE, ar-SA, etc. A couple of secondary concerns have been pointed out, though: - If a language is written today 99.9% with one particular script, but that changes in the future, then all of the legacy usage without any script subtag will become problematic. - It won't be the easiest task to determine for less-well-known languages when it's appropriate to add a suppress_script value. Thinking down the road to when we include ISO 639-3, one thing would could perhaps do to limit these problems would be to determine that we will only specify suppress_script values for languages that are included in ISO 639-2; indeed, perhaps we get them set in the initial registry, and no other suppress_script fields are ever added in the future (barring some case getting overlooked in preparing the initial registry). The idea would be that when people start tagging using IDs currently only ISO 639-3, they would be encouraged to include script subtags even if they appear to be redundant at present. This would be following Debbie Garside's suggestion from a while back: include all relevant details since you never know when they might be needed. Just a thought... Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 00:04:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNNV2-0002BR-FL; Mon, 18 Apr 2005 00:04:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNNV1-0002BM-CL for ltru@megatron.ietf.org; Mon, 18 Apr 2005 00:04:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18246 for ; Mon, 18 Apr 2005 00:04:36 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNNfk-0005if-BZ for ltru@ietf.org; Mon, 18 Apr 2005 00:15:45 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 17 Apr 2005 21:04:29 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sun, 17 Apr 2005 21:03:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Proposed Text for Moving Forward Date: Sun, 17 Apr 2005 21:04:36 -0700 Message-ID: Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVDsKMtIQrLVdQFSb+deAV+i6AjsQAGwiEw From: "Peter Constable" To: X-OriginalArrivalTime: 18 Apr 2005 04:03:27.0455 (UTC) FILETIME=[930E7EF0:01C543CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > We only want to get rid of an explicit Latn for languages like > en, got, fy, or an explicit Cyrl for ru, etc. That's why I > don't understand the idea of more than one suppress_script for > the same language, IMO that should not be allowed. +1 Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 00:15:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNNf2-0004Si-QH; Mon, 18 Apr 2005 00:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNNf0-0004SJ-Sw for ltru@megatron.ietf.org; Mon, 18 Apr 2005 00:14:59 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19141 for ; Mon, 18 Apr 2005 00:14:54 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNNau-00084u-SN for ltru@lists.ietf.org; Mon, 18 Apr 2005 06:10:44 +0200 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 06:10:44 +0200 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 06:10:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 18 Apr 2005 06:11:28 +0200 Organization: Lines: 42 Message-ID: <42633370.D07@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B08DC6F@irvmbxw01.quest.com><009e01c543ad$936685a0$7f1afea9@oemcomputer> <42630C90.2602@xyzzy.claranet.de> <000c01c543c2$f5c6f3a0$7f1afea9@oemcomputer> 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.1 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Supress & Require Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > There *is* a difference between the construct "MUST NOT x > unless Y" and the construct "SHOULD NOT x". Any "good > reason" Z could be claimed by an implementor as justification > for violating the latter. True, but in the case of Mark's proposal Y degenerated into a | unless there is a specific reason That's even less than my hallucinated "specific and good" Z - the actual wording in RfC 2199 is "valid reasons in particular circumstances". If the "specific reasons" are not specified a plain "SHOULD NOT x" is clearer than the "MUST NOT x unless specific reasons". Debbie had "specific reasons" to add scripts whereever she can. But she had no valid reasons to violate a SHOULD NOT (talking about my parallel universe of course, probably not Debbie's). > More important than technical difference between the two in > this case would be the perception of the strength of the > warning. "SHOULD NOT x" is cut-your-throat-and-then-do-x. The best excuse is old software implemented before the SHOULD NOT was introduced. Or obvious cases like Web cams operating as HTTP server which simply have no timestamp for a valid Date: header. Or using a domain literal if there's no FQDN. "MUST NOT x unless specific reasons" is fuzzy, for me it sounds like "do what you like, but it's nice that we talked about x". It would be very different if the reasons are really specified. > are we at least agreed that this is a case where we want > the document to give a clear rationale for the recommended > behaviour? The MUST vs. SHOULD issue is the only point where I disagree, anything else in your two articles is fine for me. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 00:50:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNODh-0005mF-Fr; Mon, 18 Apr 2005 00:50:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNODe-0005mA-Ql for ltru@megatron.ietf.org; Mon, 18 Apr 2005 00:50:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21542 for ; Mon, 18 Apr 2005 00:50:43 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNOOO-00089p-2a for ltru@ietf.org; Mon, 18 Apr 2005 01:01:53 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Sun, 17 Apr 2005 21:50:33 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sun, 17 Apr 2005 21:49:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: Proposed Text for Moving Forward Date: Sun, 17 Apr 2005 21:50:43 -0700 Message-ID: Thread-Topic: [Ltru] Re: Proposed Text for Moving Forward Thread-Index: AcVDjwTNBpScasXDRC+Z+6AkZYsqQgAQt6Fg From: "Peter Constable" To: X-OriginalArrivalTime: 18 Apr 2005 04:49:27.0735 (UTC) FILETIME=[004FCC70:01C543D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > > 2. The script subtag SHOULD always be used to form a language > > tag when the script of the tagged content matches a > > 'Required_Script' field for the associated primary language. >=20 > Less convincing, in a hrefang=3D to a WAV or MP3 I don't need any > Hans or Hant. I'm not a proponent of the "Required_Script" field, but I'll observe that this concern could be resolved by indicating that the script subtag should be included when tagging *text* content/resources, not non-textual content/resources. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 00:58:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNOKg-00079F-Cj; Mon, 18 Apr 2005 00:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNOKe-00079A-8K for ltru@megatron.ietf.org; Mon, 18 Apr 2005 00:58:00 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21741 for ; Mon, 18 Apr 2005 00:57:56 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNOGj-0002LO-Ih for ltru@lists.ietf.org; Mon, 18 Apr 2005 06:53:57 +0200 Received: from 212.82.251.1 ([212.82.251.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 06:53:57 +0200 Received: from nobody by 212.82.251.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 06:53:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 18 Apr 2005 06:55:50 +0200 Organization: Lines: 40 Message-ID: <42633DD6.263A@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.1 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Suppress & Require Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable wrote: > If a language is written today 99.9% with one particular > script, but that changes in the future, then all of the > legacy usage without any script subtag will become > problematic. As long as the registry sticks to its legacy suppress_script there should be no problem. If yi somehow drifts to Latn, or if got drifts to Goth, then new content can simply say so, as it can "today" (one day after the final date-B). > It won't be the easiest task to determine for less-well-known > languages when it's appropriate to add a suppress_script > value. If we go for this idea: Doug could add "Suppress_script: TBD" everywhere, and we have to clean this mess before the final date-B. Maybe the languages list can help out with this task. For scripts where it's so obscure that nobody knows how to determine a suppress_script the TBD can be silently removed - it's probably no case breaking LDAP, browsers, or Web servers worldwide. > determine that we will only specify suppress_script values > for languages that are included in ISO 639-2 Because otherwise there can't be any problem with old content etc., yes, that's a good idea. > no other suppress_script fields are ever added in the future Better, no complex rules for the poor language tag reviewer. > This would be following Debbie Garside's suggestion Yes. The "suppress_script" is a compatibility kludge, and not a wonderful way to save five bytes where possible. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 01:03:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNOPm-0008BC-4E; Mon, 18 Apr 2005 01:03:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNOPi-0008B2-2T for ltru@megatron.ietf.org; Mon, 18 Apr 2005 01:03:14 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22027 for ; Mon, 18 Apr 2005 01:03:13 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050418050242.CERM4618.mta13.adelphia.net@DEWELL> for ; Mon, 18 Apr 2005 01:02:42 -0400 Message-ID: <003701c543d3$d2230cc0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050418040412.EQWJ5424.mta6.adelphia.net@megatron.ietf.org> Date: Sun, 17 Apr 2005 22:02:27 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Supress & Require Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > Have I missed something major? Where do we get the initial data from? We know all about English and Chinese and Serbian -- they've been beaten to death in this thread -- but what about the other 470+ languages in the registry? Does the initial data come from anything resembling an authoritative source, or do we start out with nothing and wait for registrations to come in? We've been able to defend the initial registry data as having come from ISO and UN standards and (in the case of variants) from previously registered tags. I don't believe we can say the same for language-script associations. Anyway, I did my best with regard to "required script," and I still think it's going to be a real can of worms, but apparently a lot of people really like it. So just let me know what needs to be added to the registry, both syntax and initial data, and I'll do it. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 09:21:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNWCE-0004dB-8X; Mon, 18 Apr 2005 09:21:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNWCC-0004d6-Bu for ltru@megatron.ietf.org; Mon, 18 Apr 2005 09:21:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17600 for ; Mon, 18 Apr 2005 09:21:46 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNWMz-0005gx-SM for ltru@ietf.org; Mon, 18 Apr 2005 09:32:59 -0400 Received: from lns-p19-1-idf-82-251-65-221.adsl.proxad.net ([82.251.65.221] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DNWC9-0002Sa-Ez; Mon, 18 Apr 2005 06:21:45 -0700 Message-Id: <6.1.2.0.2.20050418082214.04404ba0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 18 Apr 2005 15:21:35 +0200 To: "Peter Constable" , From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Supress & Require Script In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 06:03 18/04/2005, Peter Constable wrote: >Thinking down the road to when we include ISO 639-3, one thing would >could perhaps do to limit these problems would be to determine that we >will only specify suppress_script values for languages that are included >in ISO 639-2; indeed, perhaps we get them set in the initial registry, >and no other suppress_script fields are ever added in the future >(barring some case getting overlooked in preparing the initial >registry). The idea would be that when people start tagging using IDs >currently only ISO 639-3, they would be encouraged to include script >subtags even if they appear to be redundant at present. This would be >following Debbie Garside's suggestion from a while back: include all >relevant details since you never know when they might be needed. This seems to be a MUST. As well as for the IANA registrations. All this is to patch legacy problems, let them not continue. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 10:08:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNWvL-0001g0-Rj; Mon, 18 Apr 2005 10:08:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNWvL-0001fs-28 for ltru@megatron.ietf.org; Mon, 18 Apr 2005 10:08:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21771 for ; Mon, 18 Apr 2005 10:08:25 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNX68-0000Pg-UF for ltru@ietf.org; Mon, 18 Apr 2005 10:19:38 -0400 Received: from lns-p19-1-idf-82-251-65-221.adsl.proxad.net ([82.251.65.221] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DNWvI-0002BF-1w for ltru@ietf.org; Mon, 18 Apr 2005 07:08:24 -0700 Message-Id: <6.1.2.0.2.20050418153620.0401eba0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 18 Apr 2005 15:36:32 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Re: Proposed Text for Moving Forward Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org +1 (with the provisio of my other remarks, that this implicit_script story is only for legacy) On 06:04 18/04/2005, Peter Constable said: > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] >On > > Behalf Of Frank Ellermann > > > > We only want to get rid of an explicit Latn for languages like > > en, got, fy, or an explicit Cyrl for ru, etc. That's why I > > don't understand the idea of more than one suppress_script for > > the same language, IMO that should not be allowed. > >+1 > > > >Peter Constable > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 10:08:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNWvS-0001gc-5S; Mon, 18 Apr 2005 10:08:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNWvN-0001gT-Qg for ltru@megatron.ietf.org; Mon, 18 Apr 2005 10:08:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21779 for ; Mon, 18 Apr 2005 10:08:28 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNX6D-0000Po-1J for ltru@ietf.org; Mon, 18 Apr 2005 10:19:41 -0400 Received: from lns-p19-1-idf-82-251-65-221.adsl.proxad.net ([82.251.65.221] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DNWvM-0002BF-GB for ltru@ietf.org; Mon, 18 Apr 2005 07:08:28 -0700 Message-Id: <6.1.2.0.2.20050418153647.0401c640@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 18 Apr 2005 16:07:54 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Supress & Require Script Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I do not understand this SHOULD and MUST issue. If I am correct, what we mean is: 1. in every case the script, language (region, referent, style) information MUST to be given (depending on the role of the tag). Full stop. 2. in some legacy cases, the script is implied and mentionning it may make the application break. We have listed the possible implied scripts from experience for your convenience. This is a warning about an old practice. Not a moral case calling for an 11th commandment? jfc On 06:11 18/04/2005, Frank Ellermann said: >Randy Presuhn wrote: > > > There *is* a difference between the construct "MUST NOT x > > unless Y" and the construct "SHOULD NOT x". Any "good > > reason" Z could be claimed by an implementor as justification > > for violating the latter. > >True, but in the case of Mark's proposal Y degenerated into a >| unless there is a specific reason > >That's even less than my hallucinated "specific and good" Z - >the actual wording in RfC 2199 is "valid reasons in particular >circumstances". If the "specific reasons" are not specified >a plain "SHOULD NOT x" is clearer than the "MUST NOT x unless >specific reasons". > >Debbie had "specific reasons" to add scripts whereever she can. >But she had no valid reasons to violate a SHOULD NOT (talking >about my parallel universe of course, probably not Debbie's). > > > More important than technical difference between the two in > > this case would be the perception of the strength of the > > warning. > >"SHOULD NOT x" is cut-your-throat-and-then-do-x. The best >excuse is old software implemented before the SHOULD NOT was >introduced. Or obvious cases like Web cams operating as HTTP >server which simply have no timestamp for a valid Date: header. >Or using a domain literal if there's no FQDN. > >"MUST NOT x unless specific reasons" is fuzzy, for me it sounds >like "do what you like, but it's nice that we talked about x". > >It would be very different if the reasons are really specified. > > > are we at least agreed that this is a case where we want > > the document to give a clear rationale for the recommended > > behaviour? > >The MUST vs. SHOULD issue is the only point where I disagree, >anything else in your two articles is fine for me. Bye, Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 10:08:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNWvX-0001h8-Db; Mon, 18 Apr 2005 10:08:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNWvV-0001h3-E5 for ltru@megatron.ietf.org; Mon, 18 Apr 2005 10:08:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21788 for ; Mon, 18 Apr 2005 10:08:35 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNX6J-0000Py-AQ for ltru@ietf.org; Mon, 18 Apr 2005 10:19:48 -0400 Received: from lns-p19-1-idf-82-251-65-221.adsl.proxad.net ([82.251.65.221] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DNWvR-0002BF-CL for ltru@ietf.org; Mon, 18 Apr 2005 07:08:33 -0700 Message-Id: <6.1.2.0.2.20050418153710.04000260@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 18 Apr 2005 15:37:22 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Supress & Require Script Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org +1 On 07:02 18/04/2005, Doug Ewell said: >Randy Presuhn wrote: > > > Have I missed something major? > >Where do we get the initial data from? We know all about English and >Chinese and Serbian -- they've been beaten to death in this thread -- >but what about the other 470+ languages in the registry? Does the >initial data come from anything resembling an authoritative source, or >do we start out with nothing and wait for registrations to come in? > >We've been able to defend the initial registry data as having come from >ISO and UN standards and (in the case of variants) from previously >registered tags. I don't believe we can say the same for >language-script associations. > >Anyway, I did my best with regard to "required script," and I still >think it's going to be a real can of worms, but apparently a lot of >people really like it. So just let me know what needs to be added to >the registry, both syntax and initial data, and I'll do it. > >-Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 11:33:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNYFu-0002Vr-7O; Mon, 18 Apr 2005 11:33:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNYFs-0002Vg-VS for ltru@megatron.ietf.org; Mon, 18 Apr 2005 11:33:45 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29630 for ; Mon, 18 Apr 2005 11:33:42 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050418153312.HOPF2192.mta9.adelphia.net@DEWELL> for ; Mon, 18 Apr 2005 11:33:12 -0400 Message-ID: <000501c5442b$e7e8bfc0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 18 Apr 2005 08:33:00 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] "Pitting" (was: Re: [psg.com #882]) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin wrote: >> and pitting the two against each other is not how I thought consensus >> was built within Working Groups, but I could easily be wrong here. > > I feel the term "pitting" out of context. To "pit" one individual or group against another means "to set into contest or competition" (Webster's II New Riverside Desk Dictionary, 1988). I regret any confusion caused by this usage. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 12:07:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNYm4-0007ht-VC; Mon, 18 Apr 2005 12:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNYm2-0007hl-1G for ltru@megatron.ietf.org; Mon, 18 Apr 2005 12:06:58 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02167 for ; Mon, 18 Apr 2005 12:06:54 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNYgQ-0000ER-7J for ltru@lists.ietf.org; Mon, 18 Apr 2005 18:01:10 +0200 Received: from c-134-89-50.hh.dial.de.ignite.net ([62.134.89.50]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 18:01:10 +0200 Received: from nobody by c-134-89-50.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 18:01:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 18 Apr 2005 18:03:42 +0200 Organization: Lines: 23 Message-ID: <4263DA5E.17D0@xyzzy.claranet.de> References: <6.1.2.0.2.20050418153647.0401c640@mail.jefsey.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: c-134-89-50.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Supress & Require Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin wrote: > I do not understand this SHOULD and MUST issue. It's explained in RfC 2119: "they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm". If en-US won't match en-Latn-US that's harmful. > 2. in some legacy cases, the script is implied and > mentionning it may make the application break. > We have listed the possible implied scripts from > experience for your convenience. > This is a warning about an old practice. Not a moral > case calling for an 11th commandment? It's a case calling for a SHOULD NOT or a MUST NOT. The discussion was about using "MUST NOT ... unless specific reasons" instead of a simple "SHOULD NOT ...". I'm the KISS-fan here, I prefer the simple "SHOULD NOT ...". Bye _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 12:15:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNYt3-0000TV-7x; Mon, 18 Apr 2005 12:14:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNYt1-0000TN-LD for ltru@megatron.ietf.org; Mon, 18 Apr 2005 12:14:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02790 for ; Mon, 18 Apr 2005 12:14:08 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNZ3q-0000rB-GS for ltru@ietf.org; Mon, 18 Apr 2005 12:25:23 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 09:13:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Supress & Require Script Date: Mon, 18 Apr 2005 09:13:53 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DEFA@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Supress & Require Script Thread-Index: AcVDyyYDhjrE5aOWRMWHDPm6vgGOcwAZdVnA From: "Addison Phillips" To: X-OriginalArrivalTime: 18 Apr 2005 16:13:54.0587 (UTC) FILETIME=[9E101EB0:01C54431] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0300561112==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0300561112== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGVyZSBpcyB0aGUgcHJvcG9zZWQgdGV4dCBmb3IgdGhlIGRyYWZ0LiBJIGhhdmUgaW5jbHVkZXMg YWxsIG9mIHRoZSBydWxlcyB0b2dldGhlci4gQ29tbWVudHM/DQoNCkFkZGlzb24NCg0KLS0NCjx0 PlRoZSBjaG9pY2Ugb2Ygc3VidGFncyB1c2VkIHRvIGZvcm0gYSBsYW5ndWFnZSB0YWcgc2hvdWxk IGJlIGd1aWRlZCBieSB0aGUgZm9sbG93aW5nIHJ1bGVzOg0KDQo8bGlzdCBzdHlsZT0ibnVtYmVy cyI+DQogICA8dD5Vc2UgYXMgcHJlY2lzZSBhIHRhZyBhcyBwb3NzaWJsZSwgYnV0IG5vIG1vcmUg c3BlY2lmaWMgdGhhbiBpcyAgIA0KICAganVzdGlmaWVkLiBBdm9pZCB1c2luZyBzdWJ0YWdzIHRo YXQgYXJlIG5vdCBpbXBvcnRhbnQgZm9yIA0KICAgZGlzdGluZ3Vpc2hpbmcgY29udGVudCBpbiBh biBhcHBsaWNhdGlvbi4gDQoNCiAgIDxsaXN0Pg0KICAgICAgPHQ+Rm9yIGV4YW1wbGUsICdkZScg bWlnaHQgc3VmZmljZSBmb3IgdGFnZ2luZyBhbiBlbWFpbCB3cml0dGVuIA0KICAgICAgICAgaW4g R2VybWFuLCB3aGlsZSAiZGUtQ0gtMTk5NiIgaXMgcHJvYmFibHkgdW5uZWNlc3NhcmlseSBwcmVj aXNlIA0KICAgICAgICAgZm9yIHN1Y2ggYSB0YXNrLjwvdD4NCiAgIDwvbGlzdD48L3Q+DQoNCiAg IDx0PlRoZSBzY3JpcHQgc3VidGFnIFNIT1VMRCBOT1QgYmUgdXNlZCB0byBmb3JtIGxhbmd1YWdl IA0KICAgdGFncyB1bmxlc3MgdGhlIHNjcmlwdCBhZGRzIHNvbWUgZGlzdGluZ3Vpc2hpbmcgaW5m b3JtYXRpb24gdG8gDQogICB0aGUgdGFnLiBUaGUgZmllbGQgJ1N1cHByZXNzX1NjcmlwdCcgaW4g dGhlIHByaW1hcnkgbGFuZ3VhZ2UgDQogICByZWNvcmQgaW4gdGhlIHJlZ2lzdHJ5IGluZGljYXRl cyB3aGljaCBzY3JpcHQgc3VidGFncyBkbyBub3QgDQogICBhZGQgZGlzdGluZ3Vpc2hpbmcgaW5m b3JtYXRpb24gZm9yIG1vc3QgYXBwbGljYXRpb25zLg0KDQogICA8bGlzdD4NCiAgICAgIDx0PkZv ciBleGFtcGxlLCB0aGUgc3VidGFnICdMYXRuJyBzaG91bGQgbm90IGJlIHVzZWQgd2l0aCB0aGUg DQogICAgICBwcmltYXJ5IGxhbmd1YWdlICdlbicgYmVjYXVzZSBtb3N0IEVuZ2xpc2ggZG9jdW1l bnRzIGFyZSB3cml0dGVuIA0KICAgICAgaW4gdGhlIExhdGluIHNjcmlwdCBhbmQgaXQgYWRkcyBu byBkaXN0aW5ndWlzaGluZyBpbmZvcm1hdGlvbi4gDQogICAgICBIb3dldmVyLCBpZiBhIGRvY3Vt ZW50IHdlcmUgd3JpdHRlbiBpbiBFbmdsaXNoIG1peGluZyBMYXRpbiANCiAgICAgIHNjcmlwdCB3 aXRoIGFub3RoZXIgc2NyaXB0IHN1Y2ggYXMgQnJhaWxsZSAoJ0JyYWknKSwgdGhlbiBpdCANCiAg ICAgIG1heSBiZSBhcHByb3ByaWF0ZSB0byBjaG9vc2UgdG8gaW5kaWNhdGUgYm90aCBzY3JpcHRz IHRvIGFpZCANCiAgICAgIGluIGNvbnRlbnQgc2VsZWN0aW9uLCBzdWNoIGFzIHRoZSBhcHBsaWNh dGlvbiBvZiBhIA0KICAgICAgc3R5bGVzaGVldC48L3Q+DQogICA8L2xpc3Q+PC90Pg0KDQogICA8 dD5JZiBhIHN1YnRhZyBoYXMgYSAnQ2Fub25pY2FsJyBmaWVsZCBpbiBpdHMgcmVnaXN0cnkgZW50 cnksIHlvdSANCiAgIFNIT1VMRCB1c2UgdGhlIGNhbm9uaWNhbCBzdWJ0YWcgaW4gcHJlZmVyZW5j ZSB0byBhbnkNCiAgIG9mIGl0cyBhbGlhc2VzLiANCg0KICAgPGxpc3Q+DQogICAgICA8dD5Gb3Ig ZXhhbXBsZSwgeW91IHNob3VsZCB1c2UgJ2hlJyBmb3IgSGVicmV3IGluIA0KICAgICAgUHJlZmVy ZW5jZSB0byAnaXcnLjwvdD4NCiAgIDwvbGlzdD48L3Q+DQoNCiAgIDx0PllvdSBTSE9VTEQgTk9U IHVzZSB0aGUgJ1VORCcgKFVuZGV0ZXJtaW5lZCkgbGFuZ3VhZ2Ugc3VidGFnIHRvIA0KICAgbGFi ZWwgY29udGVudCwgZXZlbiBpZiB0aGUgbGFuZ3VhZ2UgaXMgdW5rbm93bi4gT21pdHRpbmcgdGhl IHRhZyANCiAgIGlzIHByZWZlcnJlZC4gU29tZSBwcm90b2NvbHMgbWF5IGZvcmNlIHlvdSB0byBn aXZlIGEgdmFsdWUgZm9yIHRoZQ0KICAgbGFuZ3VhZ2UgdGFnIGFuZCB0aGUgJ1VORCcgc3VidGFn IG1heSBiZSB1c2VmdWwgd2hlbiBtYXRjaGluZyANCiAgIGxhbmd1YWdlIHRhZ3MgaW4gY2VydGFp biBzaXR1YXRpb25zLjwvdD4NCg0KICAgPHQ+WW91IFNIT1VMRCBOT1QgdXNlIHRoZSAnTVVMJyAo TXVsdGlwbGUpIHN1YnRhZyBpZiB0aGUgcHJvdG9jb2wgDQogICBhbGxvd3MgeW91IHRvIHVzZSBt dWx0aXBsZSBsYW5ndWFnZXMsIGFzIGlzIHRoZSBjYXNlIGZvciB0aGUgDQogICBDb250ZW50LUxh bmd1YWdlIGhlYWRlciBpbiBIVFRQLjwvdD4NCg0KICAgPHQ+WW91IFNIT1VMRCBOT1QgdXNlIHRo ZSBzYW1lIHZhcmlhbnQgc3VidGFnIG1vcmUgdGhhbiBvbmNlIHdpdGhpbiANCiAgIGEgbGFuZ3Vh Z2UgdGFnLg0KDQogICA8bGlzdD4NCiAgICAgIDx0PkZvciBleGFtcGxlLCB5b3Ugc2hvdWxkIG5v dCB1c2UgImVuLUdCLXNjb3VzZS1zY291c2UiLjwvdD4NCiAgIDwvbGlzdD4gPC90Pg0KPC9saXN0 PjwvdD4NCi0tDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0 LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdv cmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0 IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogbHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxp c3RzLmlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgTWFyayBEYXZpcw0KPiBTZW50OiBkaW1hbmNo ZSAxNyBhdnJpbCAyMDA1IDIwOjQ0DQo+IFRvOiBsdHJ1QGlldGYub3JnOyBGcmFuayBFbGxlcm1h bm4NCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBSZTogU3VwcmVzcyAmIFJlcXVpcmUgU2NyaXB0DQo+ IA0KPiBJdCBzb3VuZHMgdG8gbWUgbGlrZSB3ZSBoYXZlIHJvdWdoIGNvbnNlbnN1cyBmb3INCj4g DQo+IHN1cHByZXNzX3NjcmlwdA0KPiBTSE9VTEQgTk9UIChidXQgbWF5YmUgYSBmb2xsb3ctb24g c2VudGVuY2Ugb3Igc28pDQo+IG5vIHJlYWwgbmVlZCBmb3IgcmVxdWlyZWRfc2NyaXB0DQo+IA0K PiDigI5NYXJrDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJG cmFuayBFbGxlcm1hbm4iIDxub2JvZHlAeHl6enkuY2xhcmFuZXQuZGU+DQo+IFRvOiA8bHRydUBp ZXRmLm9yZz4NCj4gU2VudDogU3VuZGF5LCBBcHJpbCAxNywgMjAwNSAxODoyNQ0KPiBTdWJqZWN0 OiBbTHRydV0gUmU6IFN1cHJlc3MgJiBSZXF1aXJlIFNjcmlwdA0KPiANCj4gDQo+ID4gUmFuZHkg UHJlc3VobiB3cm90ZToNCj4gPg0KPiA+ID4gMikgdGhlcmUgc2VlbXMgdG8gYmUgZ2VuZXJhbCBz dXBwb3J0IGZvciB3b3JkaW5nIHRoZQ0KPiA+ID4gICAgZ3VpZGVsaW5lcyBvbiB0aGUgdXNlIG9m IHNjcmlwdCBzdWJ0YWdzIGZhaXJseSBzdHJvbmdseSwNCj4gPiA+ICAgIHVzaW5nICJNVVNUIC4u LiBleGNlcHQiIHJhdGhlciB0aGFuICJTSE9VTEQiDQo+ID4NCj4gPiBPbmx5ICJyb3VnaCBjb25z ZW5zdXMiIGZvciB0aGUgcHJvcG9zZWQgIk1VU1QgTk9UIC4uLiB1bmxlc3MiLA0KPiA+IHNlZSA8 aHR0cDovL2FydGljbGUuZ21hbmUub3JnL2dtYW5lLmlldGYubHRydToxMjQwPiAtIEknZCBsaWtl DQo+ID4gYSAiU0hPVUxEIE5PVCAuLi4iIHdpdGhvdXQgInVubGVzcyIgY2xhdXNlIGJldHRlci4g IEJ5ZSwgRnJhbmsNCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEx0cnUgbWFpbGluZyBsaXN0DQo+ID4gTHRydUBs aXN0cy5pZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2x0cnUNCj4gPg0KPiA+DQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAbGlzdHMu aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0K DQo= --===============0300561112== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0300561112==-- From ltru-bounces@lists.ietf.org Mon Apr 18 12:16:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNYvB-0000bc-TT; Mon, 18 Apr 2005 12:16:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNYvA-0000bX-Ep for ltru@megatron.ietf.org; Mon, 18 Apr 2005 12:16:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02916 for ; Mon, 18 Apr 2005 12:16:21 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNZ5z-0000y7-TE for ltru@ietf.org; Mon, 18 Apr 2005 12:27:36 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 09:16:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Re: Supress & Require Script Date: Mon, 18 Apr 2005 09:16:12 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DEFF@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Supress & Require Script Thread-Index: AcVD17GI/XENxUY6QX2QXdXwCHeRrgAWiZZA From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 18 Apr 2005 16:16:14.0004 (UTC) FILETIME=[F1297740:01C54431] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1267017495==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1267017495== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 V2UgZG8gdGhlIG9uZXMgd2Uga25vdyAocHJvYmFibHkgbW9zdCBvZiB0aGUgSVNPIDYzOS0xIGNv ZGVzKSBhbmQgbGVhdmUgdGhlIHJlc3QgdG8gdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzPw0KDQpB ZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBR dWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtp bmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlz IGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogbHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3Rz LmlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgRG91ZyBFd2VsbA0KPiBTZW50OiBkaW1hbmNoZSAx NyBhdnJpbCAyMDA1IDIyOjAyDQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDog W0x0cnVdIFJlOiBTdXByZXNzICYgUmVxdWlyZSBTY3JpcHQNCj4gDQo+IFJhbmR5IFByZXN1aG4g PHJhbmR5IHVuZGVyc2NvcmUgcHJlc3VobiBhdCBtaW5kc3ByaW5nIGRvdCBjb20+IHdyb3RlOg0K PiANCj4gPiBIYXZlIEkgbWlzc2VkIHNvbWV0aGluZyBtYWpvcj8NCj4gDQo+IFdoZXJlIGRvIHdl IGdldCB0aGUgaW5pdGlhbCBkYXRhIGZyb20/ICBXZSBrbm93IGFsbCBhYm91dCBFbmdsaXNoIGFu ZA0KPiBDaGluZXNlIGFuZCBTZXJiaWFuIC0tIHRoZXkndmUgYmVlbiBiZWF0ZW4gdG8gZGVhdGgg aW4gdGhpcyB0aHJlYWQgLS0NCj4gYnV0IHdoYXQgYWJvdXQgdGhlIG90aGVyIDQ3MCsgbGFuZ3Vh Z2VzIGluIHRoZSByZWdpc3RyeT8gIERvZXMgdGhlDQo+IGluaXRpYWwgZGF0YSBjb21lIGZyb20g YW55dGhpbmcgcmVzZW1ibGluZyBhbiBhdXRob3JpdGF0aXZlIHNvdXJjZSwgb3INCj4gZG8gd2Ug c3RhcnQgb3V0IHdpdGggbm90aGluZyBhbmQgd2FpdCBmb3IgcmVnaXN0cmF0aW9ucyB0byBjb21l IGluPw0KPiANCj4gV2UndmUgYmVlbiBhYmxlIHRvIGRlZmVuZCB0aGUgaW5pdGlhbCByZWdpc3Ry eSBkYXRhIGFzIGhhdmluZyBjb21lIGZyb20NCj4gSVNPIGFuZCBVTiBzdGFuZGFyZHMgYW5kIChp biB0aGUgY2FzZSBvZiB2YXJpYW50cykgZnJvbSBwcmV2aW91c2x5DQo+IHJlZ2lzdGVyZWQgdGFn cy4gIEkgZG9uJ3QgYmVsaWV2ZSB3ZSBjYW4gc2F5IHRoZSBzYW1lIGZvcg0KPiBsYW5ndWFnZS1z Y3JpcHQgYXNzb2NpYXRpb25zLg0KPiANCj4gQW55d2F5LCBJIGRpZCBteSBiZXN0IHdpdGggcmVn YXJkIHRvICJyZXF1aXJlZCBzY3JpcHQsIiBhbmQgSSBzdGlsbA0KPiB0aGluayBpdCdzIGdvaW5n IHRvIGJlIGEgcmVhbCBjYW4gb2Ygd29ybXMsIGJ1dCBhcHBhcmVudGx5IGEgbG90IG9mDQo+IHBl b3BsZSByZWFsbHkgbGlrZSBpdC4gIFNvIGp1c3QgbGV0IG1lIGtub3cgd2hhdCBuZWVkcyB0byBi ZSBhZGRlZCB0bw0KPiB0aGUgcmVnaXN0cnksIGJvdGggc3ludGF4IGFuZCBpbml0aWFsIGRhdGEs IGFuZCBJJ2xsIGRvIGl0Lg0KPiANCj4gLURvdWcgRXdlbGwNCj4gIEZ1bGxlcnRvbiwgQ2FsaWZv cm5pYQ0KPiAgaHR0cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiANCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1 IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg0K --===============1267017495== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1267017495==-- From ltru-bounces@lists.ietf.org Mon Apr 18 12:48:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZQM-0004A6-2r; Mon, 18 Apr 2005 12:48:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZQK-00048d-Mm for ltru@megatron.ietf.org; Mon, 18 Apr 2005 12:48:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05337 for ; Mon, 18 Apr 2005 12:48:33 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNZb1-0003Lw-A9 for ltru@ietf.org; Mon, 18 Apr 2005 12:59:49 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3IGmBua360846 for ; Mon, 18 Apr 2005 12:48:11 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3IGmBxw228412 for ; Mon, 18 Apr 2005 10:48:11 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3IGmBg0015175 for ; Mon, 18 Apr 2005 10:48:11 -0600 Received: from markdavis (sig-9-48-120-203.mts.ibm.com [9.48.120.203]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3IGm9Zw015134; Mon, 18 Apr 2005 10:48:10 -0600 Message-ID: <026f01c54436$66d82050$467a3009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , References: <634978A7DF025A40BFEF33EB191E13BC0B08DEFA@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: Supress & Require Script Date: Mon, 18 Apr 2005 09:48:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j3IGmBua360846 X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Looks good. Some wording: > For example, the subtag 'Latn' should not be used with the > primary language 'en' because most English documents are written > most English documents are written > in the Latin script and it adds no distinguishing information. >However, if a document were written in English mixing Latin ... =3D> For example, the subtag 'Latn' should not normally be used with the prima= ry language 'en' because the overwhelming majority of English documents are written in the Latin script, thus 'Latn' does not normally add useful distinguishing information. However, if a document were written in English mixing Latin ... [If it were only 'most' (eg > 50%) we would still need it, plus some othe= r wording to bridge to the next sentence.] > We do the ones we know (probably most of the ISO 639-1 codes) and leave the rest to the registration process? agreed =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: Sent: Monday, April 18, 2005 09:13 Subject: RE: [Ltru] Re: Supress & Require Script > Here is the proposed text for the draft. I have includes all of the rul= es together. Comments? > > Addison > > -- > The choice of subtags used to form a language tag should be guided b= y the following rules: > > > Use as precise a tag as possible, but no more specific than is > justified. Avoid using subtags that are not important for > distinguishing content in an application. > > > For example, 'de' might suffice for tagging an email written > in German, while "de-CH-1996" is probably unnecessarily precis= e > for such a task. > > > The script subtag SHOULD NOT be used to form language > tags unless the script adds some distinguishing information to > the tag. The field 'Suppress_Script' in the primary language > record in the registry indicates which script subtags do not > add distinguishing information for most applications. > > > For example, the subtag 'Latn' should not be used with the > primary language 'en' because most English documents are written > in the Latin script and it adds no distinguishing information. > However, if a document were written in English mixing Latin > script with another script such as Braille ('Brai'), then it > may be appropriate to choose to indicate both scripts to aid > in content selection, such as the application of a > stylesheet. > > > If a subtag has a 'Canonical' field in its registry entry, you > SHOULD use the canonical subtag in preference to any > of its aliases. > > > For example, you should use 'he' for Hebrew in > Preference to 'iw'. > > > You SHOULD NOT use the 'UND' (Undetermined) language subtag to > label content, even if the language is unknown. Omitting the tag > is preferred. Some protocols may force you to give a value for the > language tag and the 'UND' subtag may be useful when matching > language tags in certain situations. > > You SHOULD NOT use the 'MUL' (Multiple) subtag if the protocol > allows you to use multiple languages, as is the case for the > Content-Language header in HTTP. > > You SHOULD NOT use the same variant subtag more than once within > a language tag. > > > For example, you should not use "en-GB-scouse-scouse". > > > -- > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org= ] On > > Behalf Of Mark Davis > > Sent: dimanche 17 avril 2005 20:44 > > To: ltru@ietf.org; Frank Ellermann > > Subject: Re: [Ltru] Re: Supress & Require Script > > > > It sounds to me like we have rough consensus for > > > > suppress_script > > SHOULD NOT (but maybe a follow-on sentence or so) > > no real need for required_script > > > > =E2=80=8EMark > > > > ----- Original Message ----- > > From: "Frank Ellermann" > > To: > > Sent: Sunday, April 17, 2005 18:25 > > Subject: [Ltru] Re: Supress & Require Script > > > > > > > Randy Presuhn wrote: > > > > > > > 2) there seems to be general support for wording the > > > > guidelines on the use of script subtags fairly strongly, > > > > using "MUST ... except" rather than "SHOULD" > > > > > > Only "rough consensus" for the proposed "MUST NOT ... unless", > > > see - I'd like > > > a "SHOULD NOT ..." without "unless" clause better. Bye, Frank > > > > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > -------------------------------------------------------------------------= --- ---- > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 12:49:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZQn-0004Ji-87; Mon, 18 Apr 2005 12:49:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZQl-0004JZ-Bj for ltru@megatron.ietf.org; Mon, 18 Apr 2005 12:49:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05394 for ; Mon, 18 Apr 2005 12:49:00 -0400 (EDT) Received: from mail06.svc.cra.dublin.eircom.net ([159.134.118.22]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DNZbb-0003MR-Fg for ltru@ietf.org; Mon, 18 Apr 2005 13:00:16 -0400 Received: (qmail 62260 messnum 2898086 invoked from network[194.125.220.22/ts05-022.dublin.indigo.ie]); 18 Apr 2005 16:48:50 -0000 Received: from ts05-022.dublin.indigo.ie (HELO egt.ie) (194.125.220.22) by mail06.svc.cra.dublin.eircom.net (qp 62260) with SMTP; 18 Apr 2005 16:48:50 -0000 Message-ID: <4263E481.61465A9D@egt.ie> Date: Mon, 18 Apr 2005 17:46:57 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [Ltru] Re: Supress & Require Script References: <634978A7DF025A40BFEF33EB191E13BC0B08DEFA@irvmbxw01.quest.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA05394 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Is there any particular need to use 'YOU' forms, Addison?=20 For example:=20 (a) 'You should not use X'; rather than=20 (b) 'X should not be used'. I ask this, because your document contains an admixture of the two. This creates problems of translation if taken literally, because the YOU forms come across as rude in many languages (in the context of instructio= ns/commands). Indeed, I should prefer form (b) to be used throughout, even in English. Hope this helps, mg Addison Phillips wrote: >=20 > Here is the proposed text for the draft. I have includes all of the rul= es together. Comments? >=20 > Addison >=20 > -- > The choice of subtags used to form a language tag should be guided b= y the following rules: >=20 > > Use as precise a tag as possible, but no more specific than is > justified. Avoid using subtags that are not important for > distinguishing content in an application. >=20 > > For example, 'de' might suffice for tagging an email written > in German, while "de-CH-1996" is probably unnecessarily precis= e > for such a task. > >=20 > The script subtag SHOULD NOT be used to form language > tags unless the script adds some distinguishing information to > the tag. The field 'Suppress_Script' in the primary language > record in the registry indicates which script subtags do not > add distinguishing information for most applications. >=20 > > For example, the subtag 'Latn' should not be used with the > primary language 'en' because most English documents are written > in the Latin script and it adds no distinguishing information. > However, if a document were written in English mixing Latin > script with another script such as Braille ('Brai'), then it > may be appropriate to choose to indicate both scripts to aid > in content selection, such as the application of a > stylesheet. > >=20 > If a subtag has a 'Canonical' field in its registry entry, you > SHOULD use the canonical subtag in preference to any > of its aliases. >=20 > > For example, you should use 'he' for Hebrew in > Preference to 'iw'. > >=20 > You SHOULD NOT use the 'UND' (Undetermined) language subtag to > label content, even if the language is unknown. Omitting the tag > is preferred. Some protocols may force you to give a value for the > language tag and the 'UND' subtag may be useful when matching > language tags in certain situations. >=20 > You SHOULD NOT use the 'MUL' (Multiple) subtag if the protocol > allows you to use multiple languages, as is the case for the > Content-Language header in HTTP. >=20 > You SHOULD NOT use the same variant subtag more than once within > a language tag. >=20 > > For example, you should not use "en-GB-scouse-scouse". > > > -- >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org= ] On > > Behalf Of Mark Davis > > Sent: dimanche 17 avril 2005 20:44 > > To: ltru@ietf.org; Frank Ellermann > > Subject: Re: [Ltru] Re: Supress & Require Script > > > > It sounds to me like we have rough consensus for > > > > suppress_script > > SHOULD NOT (but maybe a follow-on sentence or so) > > no real need for required_script > > > > =E2=80*Mark > > > > ----- Original Message ----- > > From: "Frank Ellermann" > > To: > > Sent: Sunday, April 17, 2005 18:25 > > Subject: [Ltru] Re: Supress & Require Script > > > > > > > Randy Presuhn wrote: > > > > > > > 2) there seems to be general support for wording the > > > > guidelines on the use of script subtags fairly strongly, > > > > using "MUST ... except" rather than "SHOULD" > > > > > > Only "rough consensus" for the proposed "MUST NOT ... unless", > > > see - I'd like > > > a "SHOULD NOT ..." without "unless" clause better. Bye, Frank > > > > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 > ---------------------------------------------------------------------= --- > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 12:54:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZVY-0004tN-59; Mon, 18 Apr 2005 12:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZVW-0004sR-UT for ltru@megatron.ietf.org; Mon, 18 Apr 2005 12:53:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05748 for ; Mon, 18 Apr 2005 12:53:56 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNZgN-0003jq-Dr for ltru@ietf.org; Mon, 18 Apr 2005 13:05:11 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 09:53:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Supress & Require Script Date: Mon, 18 Apr 2005 09:53:46 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DF3E@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Supress & Require Script Thread-Index: AcVENqHsnhgkU/cvSIe15FqMTDtVIgAACxxw From: "Addison Phillips" To: "Marion Gunn" X-OriginalArrivalTime: 18 Apr 2005 16:53:47.0384 (UTC) FILETIME=[3047F780:01C54437] X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Sadly, most of the 'you' forms are holdovers from RFC 3066. I'll happily = change them. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Marion Gunn > Sent: lundi 18 avril 2005 09:47 > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Supress & Require Script >=20 > Is there any particular need to use 'YOU' forms, Addison? >=20 > For example: > (a) 'You should not use X'; > rather than > (b) 'X should not be used'. >=20 > I ask this, because your document contains an admixture of the two. >=20 > This creates problems of translation if taken literally, because the = YOU > forms come across as rude in many languages (in the context of > instructions/commands). >=20 > Indeed, I should prefer form (b) to be used throughout, even in = English. >=20 > Hope this helps, > mg >=20 > Addison Phillips wrote: > > > > Here is the proposed text for the draft. I have includes all of the > rules together. Comments? > > > > Addison > > > > -- > > The choice of subtags used to form a language tag should be = guided by > the following rules: > > > > > > Use as precise a tag as possible, but no more specific than is > > justified. Avoid using subtags that are not important for > > distinguishing content in an application. > > > > > > For example, 'de' might suffice for tagging an email = written > > in German, while "de-CH-1996" is probably unnecessarily = precise > > for such a task. > > > > > > The script subtag SHOULD NOT be used to form language > > tags unless the script adds some distinguishing information to > > the tag. The field 'Suppress_Script' in the primary language > > record in the registry indicates which script subtags do not > > add distinguishing information for most applications. > > > > > > For example, the subtag 'Latn' should not be used with the > > primary language 'en' because most English documents are = written > > in the Latin script and it adds no distinguishing information. > > However, if a document were written in English mixing Latin > > script with another script such as Braille ('Brai'), then it > > may be appropriate to choose to indicate both scripts to aid > > in content selection, such as the application of a > > stylesheet. > > > > > > If a subtag has a 'Canonical' field in its registry entry, you > > SHOULD use the canonical subtag in preference to any > > of its aliases. > > > > > > For example, you should use 'he' for Hebrew in > > Preference to 'iw'. > > > > > > You SHOULD NOT use the 'UND' (Undetermined) language subtag to > > label content, even if the language is unknown. Omitting the tag > > is preferred. Some protocols may force you to give a value for = the > > language tag and the 'UND' subtag may be useful when matching > > language tags in certain situations. > > > > You SHOULD NOT use the 'MUL' (Multiple) subtag if the protocol > > allows you to use multiple languages, as is the case for the > > Content-Language header in HTTP. > > > > You SHOULD NOT use the same variant subtag more than once = within > > a language tag. > > > > > > For example, you should not use "en-GB-scouse-scouse". > > > > > > -- > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > > Behalf Of Mark Davis > > > Sent: dimanche 17 avril 2005 20:44 > > > To: ltru@ietf.org; Frank Ellermann > > > Subject: Re: [Ltru] Re: Supress & Require Script > > > > > > It sounds to me like we have rough consensus for > > > > > > suppress_script > > > SHOULD NOT (but maybe a follow-on sentence or so) > > > no real need for required_script > > > > > > =E2EUR*Mark > > > > > > ----- Original Message ----- > > > From: "Frank Ellermann" > > > To: > > > Sent: Sunday, April 17, 2005 18:25 > > > Subject: [Ltru] Re: Supress & Require Script > > > > > > > > > > Randy Presuhn wrote: > > > > > > > > > 2) there seems to be general support for wording the > > > > > guidelines on the use of script subtags fairly strongly, > > > > > using "MUST ... except" rather than "SHOULD" > > > > > > > > Only "rough consensus" for the proposed "MUST NOT ... unless", > > > > see - I'd like > > > > a "SHOULD NOT ..." without "unless" clause better. Bye, Frank > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ltru mailing list > > > > Ltru@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > = ---------------------------------------------------------------------- > -- > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 > -- >=20 > Marion Gunn * EGTeo (Estab.1991) > 27 P=E1irc an Fh=E9ithlinn, Baile an > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > * mgunn@egt.ie * eamonn@egt.ie * >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 13:02:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZdn-0006Oy-OU; Mon, 18 Apr 2005 13:02:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZdk-0006Ot-VX for ltru@megatron.ietf.org; Mon, 18 Apr 2005 13:02:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06496 for ; Mon, 18 Apr 2005 13:02:26 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNZoZ-0004FH-CV for ltru@ietf.org; Mon, 18 Apr 2005 13:13:41 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3IH28fA014438; Mon, 18 Apr 2005 10:02:08 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AJCY4>; Mon, 18 Apr 2005 10:02:08 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Marion Gunn Subject: RE: [Ltru] Re: Supress & Require Script Date: Mon, 18 Apr 2005 10:02:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sharplabs.com id j3IH28fA014438 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, Please don't change them by just removing "YOU". "X SHOULD NOT be used..." is not a valid conformance requirement. There's no actor (the missing "YOU"). However, "YOU" should _never_ be used. A verifiable conformance requirement should be written as a simple subject/verb/object sentence like "Client applications=20 (such as Web browsers) SHOULD NOT use X", with any needed exception clause(s) trailing at the end. Software entities (not human beings) are subjects for protocol requirements. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Monday, April 18, 2005 12:54 PM > To: Marion Gunn > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Supress & Require Script >=20 >=20 > Sadly, most of the 'you' forms are holdovers from RFC 3066.=20 > I'll happily change them. >=20 > Addison >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture.=20 >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Marion Gunn > > Sent: lundi 18 avril 2005 09:47 > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Re: Supress & Require Script > >=20 > > Is there any particular need to use 'YOU' forms, Addison? > >=20 > > For example: > > (a) 'You should not use X'; > > rather than > > (b) 'X should not be used'. > >=20 > > I ask this, because your document contains an admixture of the two. > >=20 > > This creates problems of translation if taken literally,=20 > because the YOU > > forms come across as rude in many languages (in the context of > > instructions/commands). > >=20 > > Indeed, I should prefer form (b) to be used throughout,=20 > even in English. > >=20 > > Hope this helps, > > mg > >=20 > > Addison Phillips wrote: > > > > > > Here is the proposed text for the draft. I have includes=20 > all of the > > rules together. Comments? > > > > > > Addison > > > > > > -- > > > The choice of subtags used to form a language tag=20 > should be guided by > > the following rules: > > > > > > > > > Use as precise a tag as possible, but no more=20 > specific than is > > > justified. Avoid using subtags that are not important for > > > distinguishing content in an application. > > > > > > > > > For example, 'de' might suffice for tagging an=20 > email written > > > in German, while "de-CH-1996" is probably=20 > unnecessarily precise > > > for such a task. > > > > > > > > > The script subtag SHOULD NOT be used to form language > > > tags unless the script adds some distinguishing information to > > > the tag. The field 'Suppress_Script' in the primary language > > > record in the registry indicates which script subtags do not > > > add distinguishing information for most applications. > > > > > > > > > For example, the subtag 'Latn' should not be=20 > used with the > > > primary language 'en' because most English=20 > documents are written > > > in the Latin script and it adds no distinguishing=20 > information. > > > However, if a document were written in English mixing Latin > > > script with another script such as Braille ('Brai'), then it > > > may be appropriate to choose to indicate both scripts to aid > > > in content selection, such as the application of a > > > stylesheet. > > > > > > > > > If a subtag has a 'Canonical' field in its registry=20 > entry, you > > > SHOULD use the canonical subtag in preference to any > > > of its aliases. > > > > > > > > > For example, you should use 'he' for Hebrew in > > > Preference to 'iw'. > > > > > > > > > You SHOULD NOT use the 'UND' (Undetermined)=20 > language subtag to > > > label content, even if the language is unknown.=20 > Omitting the tag > > > is preferred. Some protocols may force you to give a=20 > value for the > > > language tag and the 'UND' subtag may be useful when matching > > > language tags in certain situations. > > > > > > You SHOULD NOT use the 'MUL' (Multiple) subtag if=20 > the protocol > > > allows you to use multiple languages, as is the case for the > > > Content-Language header in HTTP. > > > > > > You SHOULD NOT use the same variant subtag more=20 > than once within > > > a language tag. > > > > > > > > > For example, you should not use=20 > "en-GB-scouse-scouse". > > > > > > > > > -- > > > > > > Addison P. Phillips > > > Globalization Architect, Quest Software > > > Chair, W3C Internationalization Core Working Group > > > > > > Internationalization is not a feature. > > > It is an architecture. > > > > > > > -----Original Message----- > > > > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org] > > On > > > > Behalf Of Mark Davis > > > > Sent: dimanche 17 avril 2005 20:44 > > > > To: ltru@ietf.org; Frank Ellermann > > > > Subject: Re: [Ltru] Re: Supress & Require Script > > > > > > > > It sounds to me like we have rough consensus for > > > > > > > > suppress_script > > > > SHOULD NOT (but maybe a follow-on sentence or so) > > > > no real need for required_script > > > > > > > > =E2EUR*Mark > > > > > > > > ----- Original Message ----- > > > > From: "Frank Ellermann" > > > > To: > > > > Sent: Sunday, April 17, 2005 18:25 > > > > Subject: [Ltru] Re: Supress & Require Script > > > > > > > > > > > > > Randy Presuhn wrote: > > > > > > > > > > > 2) there seems to be general support for wording the > > > > > > guidelines on the use of script subtags fairly strongly, > > > > > > using "MUST ... except" rather than "SHOULD" > > > > > > > > > > Only "rough consensus" for the proposed "MUST NOT ... unless", > > > > > see - I'd like > > > > > a "SHOULD NOT ..." without "unless" clause better. Bye, Frank > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ltru mailing list > > > > > Ltru@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Ltru mailing list > > > > Ltru@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > =20 > ---------------------------------------------------------------------- > > -- > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > >=20 > > -- > >=20 > > Marion Gunn * EGTeo (Estab.1991) > > 27 P=E1irc an Fh=E9ithlinn, Baile an > > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > > * mgunn@egt.ie * eamonn@egt.ie * > >=20 > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 13:04:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZg0-0006R0-9N; Mon, 18 Apr 2005 13:04:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNZfy-0006Qv-K6 for ltru@megatron.ietf.org; Mon, 18 Apr 2005 13:04:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06689 for ; Mon, 18 Apr 2005 13:04:43 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNZqp-0004Oj-3n for ltru@ietf.org; Mon, 18 Apr 2005 13:15:59 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 10:04:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Supress & Require Script Date: Mon, 18 Apr 2005 10:04:36 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DF58@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Supress & Require Script Thread-Index: AcVEOGklJS7mfefqQni9HDPqQiKNtwAAAwMA From: "Addison Phillips" To: "McDonald, Ira" , "Marion Gunn" X-OriginalArrivalTime: 18 Apr 2005 17:04:37.0060 (UTC) FILETIME=[B384A840:01C54438] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org No, each requires a rewrite to make it grammatically correct and to have = a proper subject. 1. Use as precise a tag as possible, but no more specific than is = justified. Avoid using subtags that are not important for distinguishing = content in an application. * For example, 'de' might suffice for tagging an email written = in German, while "de-CH-1996" is probably unnecessarily precise for such = a task. 2. The script subtag SHOULD NOT be used to form language tags unless = the script adds some distinguishing information to the tag. The field = 'Suppress_Script' in the primary language record in the registry = indicates which script subtags do not add distinguishing information for = most applications. * For example, the subtag 'Latn' should not be used with the = primary language 'en' because nearly all English documents are written = in the Latin script and it adds no distinguishing information. However, = if a document were written in English mixing Latin script with another = script such as Braille ('Brai'), then it may be appropriate to choose to = indicate both scripts to aid in content selection, such as the = application of a stylesheet. 3. If a subtag has a 'Canonical' field in its registry entry, the = canonical subtag SHOULD be used to form the language tag in preference = to any of its aliases. * For example, use 'he' for Hebrew in preference to 'iw'. 4. The 'UND' (Undetermined) primary language subtag SHOULD NOT be = used to label content, even if the language is unknown. Omitting the tag = is preferred. Some protocols may force you to give a value for the = language tag and the 'UND' subtag may be useful when matching language = tags in certain situations. 5. The 'MUL' (Multiple) primary language subtag SHOULD NOT be used if = the protocol allows you to use multiple languages, as is the case for = the Content-Language header in HTTP. 6. The same variant subtag SHOULD NOT be used more than once within a = language tag. * For example, do not use "en-GB-scouse-scouse". Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: lundi 18 avril 2005 10:02 > To: Addison Phillips; Marion Gunn > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Supress & Require Script >=20 > Hi, >=20 > Please don't change them by just removing "YOU". >=20 > "X SHOULD NOT be used..." is not a valid conformance > requirement. There's no actor (the missing "YOU"). >=20 > However, "YOU" should _never_ be used. A verifiable > conformance requirement should be written as a simple > subject/verb/object sentence like "Client applications > (such as Web browsers) SHOULD NOT use X", with any needed > exception clause(s) trailing at the end. >=20 > Software entities (not human beings) are subjects for > protocol requirements. >=20 > Cheers, > - Ira >=20 > 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 >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org]On > > Behalf Of Addison Phillips > > Sent: Monday, April 18, 2005 12:54 PM > > To: Marion Gunn > > Cc: ltru@ietf.org > > Subject: RE: [Ltru] Re: Supress & Require Script > > > > > > Sadly, most of the 'you' forms are holdovers from RFC 3066. > > I'll happily change them. > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > Chair, W3C Internationalization Core Working Group > > > > Internationalization is not a feature. > > It is an architecture. > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] On > > > Behalf Of Marion Gunn > > > Sent: lundi 18 avril 2005 09:47 > > > Cc: ltru@ietf.org > > > Subject: Re: [Ltru] Re: Supress & Require Script > > > > > > Is there any particular need to use 'YOU' forms, Addison? > > > > > > For example: > > > (a) 'You should not use X'; > > > rather than > > > (b) 'X should not be used'. > > > > > > I ask this, because your document contains an admixture of the = two. > > > > > > This creates problems of translation if taken literally, > > because the YOU > > > forms come across as rude in many languages (in the context of > > > instructions/commands). > > > > > > Indeed, I should prefer form (b) to be used throughout, > > even in English. > > > > > > Hope this helps, > > > mg > > > > > > Addison Phillips wrote: > > > > > > > > Here is the proposed text for the draft. I have includes > > all of the > > > rules together. Comments? > > > > > > > > Addison > > > > > > > > -- > > > > The choice of subtags used to form a language tag > > should be guided by > > > the following rules: > > > > > > > > > > > > Use as precise a tag as possible, but no more > > specific than is > > > > justified. Avoid using subtags that are not important for > > > > distinguishing content in an application. > > > > > > > > > > > > For example, 'de' might suffice for tagging an > > email written > > > > in German, while "de-CH-1996" is probably > > unnecessarily precise > > > > for such a task. > > > > > > > > > > > > The script subtag SHOULD NOT be used to form language > > > > tags unless the script adds some distinguishing information = to > > > > the tag. The field 'Suppress_Script' in the primary language > > > > record in the registry indicates which script subtags do not > > > > add distinguishing information for most applications. > > > > > > > > > > > > For example, the subtag 'Latn' should not be > > used with the > > > > primary language 'en' because most English > > documents are written > > > > in the Latin script and it adds no distinguishing > > information. > > > > However, if a document were written in English mixing = Latin > > > > script with another script such as Braille ('Brai'), then = it > > > > may be appropriate to choose to indicate both scripts to = aid > > > > in content selection, such as the application of a > > > > stylesheet. > > > > > > > > > > > > If a subtag has a 'Canonical' field in its registry > > entry, you > > > > SHOULD use the canonical subtag in preference to any > > > > of its aliases. > > > > > > > > > > > > For example, you should use 'he' for Hebrew in > > > > Preference to 'iw'. > > > > > > > > > > > > You SHOULD NOT use the 'UND' (Undetermined) > > language subtag to > > > > label content, even if the language is unknown. > > Omitting the tag > > > > is preferred. Some protocols may force you to give a > > value for the > > > > language tag and the 'UND' subtag may be useful when matching > > > > language tags in certain situations. > > > > > > > > You SHOULD NOT use the 'MUL' (Multiple) subtag if > > the protocol > > > > allows you to use multiple languages, as is the case for the > > > > Content-Language header in HTTP. > > > > > > > > You SHOULD NOT use the same variant subtag more > > than once within > > > > a language tag. > > > > > > > > > > > > For example, you should not use > > "en-GB-scouse-scouse". > > > > > > > > > > > > -- > > > > > > > > Addison P. Phillips > > > > Globalization Architect, Quest Software > > > > Chair, W3C Internationalization Core Working Group > > > > > > > > Internationalization is not a feature. > > > > It is an architecture. > > > > > > > > > -----Original Message----- > > > > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] > > > On > > > > > Behalf Of Mark Davis > > > > > Sent: dimanche 17 avril 2005 20:44 > > > > > To: ltru@ietf.org; Frank Ellermann > > > > > Subject: Re: [Ltru] Re: Supress & Require Script > > > > > > > > > > It sounds to me like we have rough consensus for > > > > > > > > > > suppress_script > > > > > SHOULD NOT (but maybe a follow-on sentence or so) > > > > > no real need for required_script > > > > > > > > > > =E2EUR*Mark > > > > > > > > > > ----- Original Message ----- > > > > > From: "Frank Ellermann" > > > > > To: > > > > > Sent: Sunday, April 17, 2005 18:25 > > > > > Subject: [Ltru] Re: Supress & Require Script > > > > > > > > > > > > > > > > Randy Presuhn wrote: > > > > > > > > > > > > > 2) there seems to be general support for wording the > > > > > > > guidelines on the use of script subtags fairly = strongly, > > > > > > > using "MUST ... except" rather than "SHOULD" > > > > > > > > > > > > Only "rough consensus" for the proposed "MUST NOT ... = unless", > > > > > > see - I'd = like > > > > > > a "SHOULD NOT ..." without "unless" clause better. Bye, = Frank > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > Ltru mailing list > > > > > > Ltru@lists.ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Ltru mailing list > > > > > Ltru@lists.ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > > > = ---------------------------------------------------------------------- > > > -- > > > > _______________________________________________ > > > > Ltru mailing list > > > > Ltru@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > -- > > > > > > Marion Gunn * EGTeo (Estab.1991) > > > 27 P=E1irc an Fh=E9ithlinn, Baile an > > > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > > > * mgunn@egt.ie * eamonn@egt.ie * > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 13:32:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNa6a-0007xD-Hr; Mon, 18 Apr 2005 13:32:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNa6Z-0007wd-9S for ltru@megatron.ietf.org; Mon, 18 Apr 2005 13:32:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08941 for ; Mon, 18 Apr 2005 13:32:13 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNaHO-0006R6-7c for ltru@ietf.org; Mon, 18 Apr 2005 13:43:27 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 10:32:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Apr 2005 10:32:00 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08DF7A@irvmbxw01.quest.com> Thread-Topic: new version posted online Thread-Index: AcVEPIQm1p6GhqPxSU63jERFJ22XQA== From: "Addison Phillips" To: X-OriginalArrivalTime: 18 Apr 2005 17:32:02.0538 (UTC) FILETIME=[884CACA0:01C5443C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] new version posted online X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1729046713==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1729046713== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhlIGRyYWZ0LTAxIHByb3RvdHlwZSBoYXMgYmVlbiB1cGRhdGVkIGFuZCBwb3N0ZWQgYXQ6DQoN Cmh0dHA6Ly93d3cuaW50ZXItbG9jYWxlLmNvbS9JRC9kcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnkt MDEudHh0DQpodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHVyLXJl Z2lzdHJ5LTAxLmh0bWwNCg0KSSBoYXZlIGluY29ycG9yYXRlZCAnU3VwcHJlc3NfU2NyaXB0JyBp bnRvIHRoZSB2YXJpb3VzIHBsYWNlcyByZXF1aXJlZCB0byBkZWZpbmUgaXQgKG1hbnkgcGFydHMg b2Ygc2VjdGlvbiAzKS4gT2YgY291cnNlIHdlIGNhbiBkZWNpZGUgb24gYSBkaWZmZXJlbnQgbmFt ZSBpZiBzbyBkZXNpcmVkLiBSaWdodCBub3cgdGhlIHRleHQgaXMgdGhlIGtleS4gTm90ZSB0aGF0 IEkgdXNlZCBhIGRpZmZlcmVudCBleGFtcGxlIGZyb20gZW4vZW4tTGF0biBpbiBzZWN0aW9uIDMu MS4gSSBhbHNvIHB1dCBhIHNjcmlwdCBvZiAnQXJhYicgb24gdGhlIGxhbmd1YWdlICdhcicgaW4g dGhlIGV4YW1wbGUgcmVnaXN0cnkuDQoNCk90aGVyIG1pbm9yIGNoYW5nZXMvY29ycmVjdGlvbnMg YXJlIGxpc3RlZCBpbiB0aGUgY2hhbmdlcyBzZWN0aW9uLg0KDQpBcmUgd2UgY2xvc2UgdG8gZG9u ZSB3aXRoIHRoaXMgaXNzdWUsIGVub3VnaCBmb3IgbWUgdG8gc3RhcnQgd29yayBvbiBwcmVwYXJp bmcgdGhlIG5leHQgb2ZmaWNpYWxseSBzdWJtaXR0ZWQgZHJhZnQ/DQoNCkJlc3QgUmVnYXJkcywN Cg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVj dCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkNoYWlyLCBXM0MgSW50 ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRwOi8vd3d3LnczLm9yZy9J bnRlcm5hdGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJ dCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQoNCg== --===============1729046713== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1729046713==-- From ltru-bounces@lists.ietf.org Mon Apr 18 13:49:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNaN5-0002nL-8m; Mon, 18 Apr 2005 13:49:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNaN4-0002nG-2O for ltru@megatron.ietf.org; Mon, 18 Apr 2005 13:49:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10437 for ; Mon, 18 Apr 2005 13:49:17 -0400 (EDT) Received: from mail03.svc.cra.dublin.eircom.net ([159.134.118.19]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DNaXt-0007m7-56 for ltru@ietf.org; Mon, 18 Apr 2005 14:00:31 -0400 Received: (qmail 36838 messnum 271198 invoked from network[194.125.207.67/ts11-067.dublin.indigo.ie]); 18 Apr 2005 17:49:04 -0000 Received: from ts11-067.dublin.indigo.ie (HELO egt.ie) (194.125.207.67) by mail03.svc.cra.dublin.eircom.net (qp 36838) with SMTP; 18 Apr 2005 17:49:04 -0000 Message-ID: <4263F29F.9AFA1AC2@egt.ie> Date: Mon, 18 Apr 2005 18:47:11 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [Ltru] Re: Supress & Require Script References: Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA10437 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Ira's suggestion would certainly make it easier to read/translate/quote. Best, mg "McDonald, Ira" wrote: >=20 > Hi, >=20 > Please don't change them by just removing "YOU". >=20 > "X SHOULD NOT be used..." is not a valid conformance > requirement. There's no actor (the missing "YOU"). >=20 > However, "YOU" should _never_ be used. A verifiable > conformance requirement should be written as a simple > subject/verb/object sentence like "Client applications > (such as Web browsers) SHOULD NOT use X", with any needed > exception clause(s) trailing at the end. >=20 > Software entities (not human beings) are subjects for > protocol requirements. >=20 > Cheers, > - Ira >=20 > 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 > > --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 13:54:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNaRl-0002uh-5L; Mon, 18 Apr 2005 13:54:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNaRj-0002uc-WA for ltru@megatron.ietf.org; Mon, 18 Apr 2005 13:54:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10946 for ; Mon, 18 Apr 2005 13:54:07 -0400 (EDT) Received: from mail13.svc.cra.dublin.eircom.net ([159.134.118.29]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DNaca-00082m-6F for ltru@ietf.org; Mon, 18 Apr 2005 14:05:21 -0400 Received: (qmail 18374 messnum 4212033 invoked from network[194.125.207.67/ts11-067.dublin.indigo.ie]); 18 Apr 2005 17:53:56 -0000 Received: from ts11-067.dublin.indigo.ie (HELO egt.ie) (194.125.207.67) by mail13.svc.cra.dublin.eircom.net (qp 18374) with SMTP; 18 Apr 2005 17:53:56 -0000 Message-ID: <4263F3C3.EAF0C4FA@egt.ie> Date: Mon, 18 Apr 2005 18:52:03 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ltru@ietf.org Subject: Re: [Ltru] Re: Supress & Require Script References: Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA10946 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Ira's suggestion would certainly make it easier to read/translate/quote. Best, mg "McDonald, Ira" wrote: >=20 > Hi, >=20 > Please don't change them by just removing "YOU". >=20 > "X SHOULD NOT be used..." is not a valid conformance > requirement. There's no actor (the missing "YOU"). >=20 > However, "YOU" should _never_ be used. A verifiable > conformance requirement should be written as a simple > subject/verb/object sentence like "Client applications > (such as Web browsers) SHOULD NOT use X", with any needed > exception clause(s) trailing at the end. >=20 > Software entities (not human beings) are subjects for > protocol requirements. >=20 > Cheers, > - Ira >=20 > 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 > > --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 13:55:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNaSq-00032H-H2; Mon, 18 Apr 2005 13:55:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNaSp-000328-Hd for ltru@megatron.ietf.org; Mon, 18 Apr 2005 13:55:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11052 for ; Mon, 18 Apr 2005 13:55:14 -0400 (EDT) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNade-000841-39 for ltru@ietf.org; Mon, 18 Apr 2005 14:06:28 -0400 Received: from smtp-los04.proxy.aol.com (smtp-los04.proxy.aol.com [195.93.24.101]) by rly-ip03.mx.aol.com (v98.19) with ESMTP id RELAYIN5-64263f4747c; Mon, 18 Apr 2005 13:55:01 -0500 Received: from DEBHOME (ACBC22BD.ipt.aol.com [172.188.34.189]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3IHswKX013157; Mon, 18 Apr 2005 13:54:58 -0400 Message-Id: <200504181754.j3IHswKX013157@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'Peter Constable'" , Subject: RE: [Ltru] Supress & Require Script Date: Mon, 18 Apr 2005 18:55:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVDr1TTFkYSvTHxSsCt4Nt1i9zoQQAGV81AAB2G2rA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.101 X-Spam-Score: 2.7 (++) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable wrote: > Thinking down the road to when we include ISO 639-3, one thing would > could perhaps do to limit these problems would be to determine that we > will only specify suppress_script values for languages that are included > in ISO 639-2; indeed, perhaps we get them set in the initial registry, > and no other suppress_script fields are ever added in the future > (barring some case getting overlooked in preparing the initial > registry). The idea would be that when people start tagging using IDs > currently only ISO 639-3, they would be encouraged to include script > subtags even if they appear to be redundant at present. This would be > following Debbie Garside's suggestion from a while back: include all > relevant details since you never know when they might be needed. > > Just a thought... And... a VERY good thought, at that... ;-) As for populating the registry... as Lee would say... "the devil is in the detail"... Debbie Garside www.linguasphere.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Peter Constable > Sent: 18 April 2005 05:03 > To: ltru@ietf.org > Subject: RE: [Ltru] Supress & Require Script > > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Randy Presuhn > > > > I'm ... just testing the waters... > > > > 1) a general consensus has emerged that the "supress_script" > > concept is helpful... > > I agree, whatever the name (IMO, "suppress_script" or "implicit_script" > are better than "default_script"). > > > > 2) there seems to be general support for wording the guidelines > > on the use of script subtags fairly strongly, using "MUST ... except" > > rather than "SHOULD" and giving clear rationale for why they'd > > work the way that is proposed... > > I've no strong preference between "MUST... except" or a strong "SHOULD"; > I agree on inclusion of rational. > > > > > 3) it's less clear to me whether we're getting a consensus on > > "require_script"... > > I'm not convinced of the need, and lean toward excluding this, but am > not strongly opposed. > > > > One thought about a possible option moving forward: the reason for > identifying suppress_script cases is to ensure desired functionality > with existing implementations and usage of tags such as en-GB, de-DE, > ar-SA, etc. A couple of secondary concerns have been pointed out, > though: > > - If a language is written today 99.9% with one particular script, but > that changes in the future, then all of the legacy usage without any > script subtag will become problematic. > > - It won't be the easiest task to determine for less-well-known > languages when it's appropriate to add a suppress_script value. > > Thinking down the road to when we include ISO 639-3, one thing would > could perhaps do to limit these problems would be to determine that we > will only specify suppress_script values for languages that are included > in ISO 639-2; indeed, perhaps we get them set in the initial registry, > and no other suppress_script fields are ever added in the future > (barring some case getting overlooked in preparing the initial > registry). The idea would be that when people start tagging using IDs > currently only ISO 639-3, they would be encouraged to include script > subtags even if they appear to be redundant at present. This would be > following Debbie Garside's suggestion from a while back: include all > relevant details since you never know when they might be needed. > > Just a thought... > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 14:13:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNahy-0004nK-S5; Mon, 18 Apr 2005 14:10:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNahx-0004mP-Dr for ltru@megatron.ietf.org; Mon, 18 Apr 2005 14:10:54 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12658 for ; Mon, 18 Apr 2005 14:10:51 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNadY-00062e-79 for ltru@lists.ietf.org; Mon, 18 Apr 2005 20:06:20 +0200 Received: from 212.82.251.75 ([212.82.251.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 20:06:20 +0200 Received: from nobody by 212.82.251.75 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 20:06:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 18 Apr 2005 20:06:52 +0200 Organization: Lines: 25 Message-ID: <4263F73C.4816@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B08DEFA@irvmbxw01.quest.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.75 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Suppress & Require Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: >| The script subtag SHOULD NOT be used to form language tags >| unless the script adds some distinguishing information to >| the tag. The field 'Suppress_Script' in the primary language >| record in the registry indicates which script subtags do not >| add distinguishing information for most applications. Minor modification: | The script subtag should not be used to form language tags | unless the script adds some distinguishing information to | the tag. The field 'Suppress_Script' in the primary language | record in the registry indicates which script subtag SHOULD | NOT be used in tags with the given language. >| You SHOULD NOT use the same variant subtag more than once >| within a language tag. | Don't use the same variant subtag more than once within a | language tag. Any SHOULD or MUST less makes the remaining SHOULD and MUST stronger. Probably that's only a matter of taste. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 14:55:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbPA-0000ma-Vy; Mon, 18 Apr 2005 14:55:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbPA-0000mK-65 for ltru@megatron.ietf.org; Mon, 18 Apr 2005 14:55:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17294 for ; Mon, 18 Apr 2005 14:55:30 -0400 (EDT) Received: from [63.247.76.195] (helo=montage.altserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNba1-0002rt-TV for ltru@ietf.org; Mon, 18 Apr 2005 15:06:46 -0400 Received: from lns-p19-1-idf-82-251-65-221.adsl.proxad.net ([82.251.65.221] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DNbOz-0003AZ-67; Mon, 18 Apr 2005 11:55:21 -0700 Message-Id: <6.1.2.0.2.20050418185247.03dbe720@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 18 Apr 2005 20:55:16 +0200 To: Frank Ellermann , ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: Supress & Require Script In-Reply-To: <4263DA5E.17D0@xyzzy.claranet.de> References: <6.1.2.0.2.20050418153647.0401c640@mail.jefsey.com> <4263DA5E.17D0@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Franck, sorry I mean the whole issue of using an RFC 2119 wording, whatever it is. At 18:03 18/04/2005, Frank Ellermann wrote: >JFC (Jefsey) Morfin wrote: > > > I do not understand this SHOULD and MUST issue. > >It's explained in RfC 2119: "they MUST only be used where it >is actually required for interoperation or to limit behavior >which has potential for causing harm". Dear Frank, I mean, I see no "requirement". I just see that there are legacy cases (developped before the proposed new format) which can fail (that depends on the library being used). So the only thing to do is to warn the people this may happen if they add the script when it is not needed. As far as I understand, the problem should fade away, when new libraries are developped. So, the "implicit_script" is only usueful in case there is a problem. This is for the writter of a page. Not for the library developper, for who supporting scripts is a MUST from now on? Being presented that way (I understand correct), i.e. just useful decreases a lot the pressure on the registry to be accurate. We only say that when someone meets a problem he should report it so we can update the list? >If en-US won't match en-Latn-US that's harmful. > > > 2. in some legacy cases, the script is implied and > > mentionning it may make the application break. > > We have listed the possible implied scripts from > > experience for your convenience. > > > This is a warning about an old practice. Not a moral > > case calling for an 11th commandment? > >It's a case calling for a SHOULD NOT or a MUST NOT. The >discussion was about using "MUST NOT ... unless specific >reasons" instead of a simple "SHOULD NOT ...". I'm the >KISS-fan here, I prefer the simple "SHOULD NOT ...". I understand the discussion, - what I question is if it discusses adequately the problem you rose and support the solution you propose. - also, as a developper I know what MUST/MUST NOT mean in a C program. I have more problems with SHOULD/SHOULD NOT. But this is to be discussed with some proposed code as there may be tricks I did not think of. jfc >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 14:57:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbRH-0000xo-HQ; Mon, 18 Apr 2005 14:57:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbRH-0000xj-2M for ltru@megatron.ietf.org; Mon, 18 Apr 2005 14:57:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17433 for ; Mon, 18 Apr 2005 14:57:41 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNbc7-0002vs-OL for ltru@ietf.org; Mon, 18 Apr 2005 15:08:57 -0400 Received: from h-68-165-4-21.snvacaid.dynamic.covad.net ([68.165.4.21] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DNbRD-0003OH-00 for ltru@ietf.org; Mon, 18 Apr 2005 11:57:39 -0700 Message-ID: <008301c54448$b9e8c120$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08DEFA@irvmbxw01.quest.com> <4263E481.61465A9D@egt.ie> Subject: Re: [Ltru] Re: Supress & Require Script Date: Mon, 18 Apr 2005 11:59:19 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Marion Gunn" > Cc: > Sent: Monday, April 18, 2005 9:46 AM > Subject: Re: [Ltru] Re: Supress & Require Script ... > For example: > (a) 'You should not use X'; > rather than > (b) 'X should not be used'. ... > This creates problems of translation if taken literally, because the YOU > forms come across as rude in many languages (in the context of instructions/commands). Any translator worth his/her salt would use the correct form for the target language. Likewise, if one were translating German "man" or French "on" into colloquial American English, I'd hope that the result would be an appropriate "you" or "they", rather than the stuffy, though literal, "one". I do, however, agree that the use of "you" in this way seems odd in a specification, which by nature is relatively formal. > Indeed, I should prefer form (b) to be used throughout, even in English. ... I really dislike passive voice, even though there are times when it is useful. I suspect it may cause more problems for non-native speakers than the colloquial "you". To your list of alternatives I'd add a third option: (c) Implementations SHOULD NOT use X However, I'm personally content to leave these matters to the editors' discretion. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 15:07:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbaY-0002BR-S0; Mon, 18 Apr 2005 15:07:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNbaX-0002As-MM for ltru@megatron.ietf.org; Mon, 18 Apr 2005 15:07:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18784 for ; Mon, 18 Apr 2005 15:07:15 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNblN-0003NT-GC for ltru@ietf.org; Mon, 18 Apr 2005 15:18:30 -0400 Received: from h-68-165-4-21.snvacaid.dynamic.covad.net ([68.165.4.21] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DNbaS-0006JV-00 for ltru@ietf.org; Mon, 18 Apr 2005 12:07:12 -0700 Message-ID: <00b101c5444a$0f80dfe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08DEFA@irvmbxw01.quest.com> <4263F73C.4816@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Suppress & Require Script Date: Mon, 18 Apr 2005 12:08:52 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Monday, April 18, 2005 11:06 AM > Subject: [Ltru] Re: Suppress & Require Script ... > Minor modification: > > | The script subtag should not be used to form language tags > | unless the script adds some distinguishing information to > | the tag. The field 'Suppress_Script' in the primary language > | record in the registry indicates which script subtag SHOULD > | NOT be used in tags with the given language. > > >| You SHOULD NOT use the same variant subtag more than once > >| within a language tag. > > | Don't use the same variant subtag more than once within a > | language tag. > > Any SHOULD or MUST less makes the remaining SHOULD and MUST > stronger. Probably that's only a matter of taste. Bye, Frank ... It's more than a matter of taste, and I'd be willing to bet that if we handed something like that to the IESG it'd come back with questions about why we mixed "should" and "SHOULD" in the same paragraph, and I, as a co-chair, would want to be able to give a coherent reply. RFC 2119 tells us to use these sparingly, but whenever they are truly necessary. If we need to constrain the use of certain subatags in certain contexts in order to preserve interoperability, that's precisely the kind of situation where SHOULD/MUST language is appropriate. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 15:47:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcD7-00068i-73; Mon, 18 Apr 2005 15:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcD5-00068W-Ss for ltru@megatron.ietf.org; Mon, 18 Apr 2005 15:47:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23022 for ; Mon, 18 Apr 2005 15:47:06 -0400 (EDT) Received: from rly-ip04.mx.aol.com ([64.12.138.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNcNv-0004aY-IR for ltru@ietf.org; Mon, 18 Apr 2005 15:58:22 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip04.mx.aol.com (v98.19) with ESMTP id RELAYIN9-a42640ea4180; Mon, 18 Apr 2005 15:46:45 -0400 Received: from DEBHOME (ACBC22BD.ipt.aol.com [172.188.34.189]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3IJkgcJ030411; Mon, 18 Apr 2005 15:46:42 -0400 Message-Id: <200504181946.j3IJkgcJ030411@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Addison Phillips'" , Subject: RE: [Ltru] new version posted online Date: Mon, 18 Apr 2005 20:47: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 Thread-Index: AcVEPIQm1p6GhqPxSU63jERFJ22XQAAEshJg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B08DF7A@irvmbxw01.quest.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 X-Spam-Score: 2.7 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Addison (on list this time :-)) Will you be incorporating a reserved alpha4 for ISO 639-6 in the next draft? I believe consensus was reached on this issue... as raised by Doug. Kind regards Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > Sent: 18 April 2005 18:32 > To: ltru@ietf.org > Subject: [Ltru] new version posted online > > The draft-01 prototype has been updated and posted at: > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.txt > http://www.inter-locale.com/ID/draft-ietf-ltur-registry-01.html > > I have incorporated 'Suppress_Script' into the various places required to > define it (many parts of section 3). Of course we can decide on a > different name if so desired. Right now the text is the key. Note that I > used a different example from en/en-Latn in section 3.1. I also put a > script of 'Arab' on the language 'ar' in the example registry. > > Other minor changes/corrections are listed in the changes section. > > Are we close to done with this issue, enough for me to start work on > preparing the next officially submitted draft? > > Best Regards, > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > http://www.quest.com > > Chair, W3C Internationalization Core Working Group > http://www.w3.org/International > > Internationalization is not a feature. > It is an architecture. > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 15:49:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcFH-0006aA-6O; Mon, 18 Apr 2005 15:49:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcFF-0006Zl-3B for ltru@megatron.ietf.org; Mon, 18 Apr 2005 15:49:22 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23370 for ; Mon, 18 Apr 2005 15:49:17 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNcAu-0004ga-Os for ltru@lists.ietf.org; Mon, 18 Apr 2005 21:44:52 +0200 Received: from 212.82.251.75 ([212.82.251.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 21:44:52 +0200 Received: from nobody by 212.82.251.75 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 21:44:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 18 Apr 2005 21:44:29 +0200 Organization: Lines: 78 Message-ID: <42640E1D.BF8@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B08DF7A@irvmbxw01.quest.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.75 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: new version posted online X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.txt Very quick scan: | lang = 2*3ALPHA ; shortest ISO 639 code We discussed 2*4ALPHA and a change of registered-lang, and/or to replace registered-lang by "individual" (i-* split off from grandfathered) | subtlety in the ABNF for 'variant' Yes, let's eliminate it, how about this: variant = (5*8alphanum) ; registered variants / (DIGIT 3alphanum) Why do you get [RFC2234] in your xref, if the reference is the 2234bis I-D, is that an xml2rfc oddity ? | However, in the tags defined by this document, the uppercase | US-ASCII letters in the range 'A' (ABNF: %x41) through 'Z' | (ABNF: %x5A) are considered equivalent and mapped directly | to their US-ASCII lowercase equivalents in the range 'a' | (ABNF: %x61) through 'z' (ABNF: %x7A). Thus the tag | "mn-Cyrl-MN [...] The mysteries of case insensitive ASCII, please replace it by: The tags defined by this document are case insensitive. Thus the tag "mn-Cyrl-MN [...] For the "missing" empty line before "However" you could use... ...near the end of the bullet-list. | Any such a limitation MUST be clearly documented MUST instead of "pray" is ugly. The text after the RfC 2231 example is obscure, do you need it ? Why not simply say that the only way to truncate tags is to remove subtags RTL ? | Single letter and digit subtags are reserved for There are no single digits in the ABNF. | The primary subtag is the first subtag in a language tag | and cannot be empty No subtag can be empty, how about s/empty/omitted/ ? | All language subtags of 4 to 8 characters in length 5 to 8, ecause 4 was set aside for Debbie. Don't forget to get rid of "STRONGLY" in this chapter. | Other values MUST NOT be assigned to the primary subtag I don't see any i-whatever before this item, is this a trick, the i-whatever case is no primary subtag ? OTOH there must be a primary subtag. | There MAY be any additional number of extended language | subtags Oops, indeed, the ABNF says *("-" extlang). What's the idea ? | Users who wished to utilize SIL Ethnologue IMHO that needs an informative reference URL. I'll scan chapter 3 ff. later, bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 15:55:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcL0-0000wd-0d; Mon, 18 Apr 2005 15:55:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcKy-0000wP-L0 for ltru@megatron.ietf.org; Mon, 18 Apr 2005 15:55:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25374 for ; Mon, 18 Apr 2005 15:55:14 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNcVq-0005UB-9l for ltru@ietf.org; Mon, 18 Apr 2005 16:06:30 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 12:54:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] considerations for ISO 639-6 at consensus? (was: new version posted online) Date: Mon, 18 Apr 2005 12:54:59 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08E08E@irvmbxw01.quest.com> Thread-Topic: [Ltru] considerations for ISO 639-6 at consensus? (was: new version posted online) Thread-Index: AcVEPIQm1p6GhqPxSU63jERFJ22XQAAEshJgAAAJAQA= From: "Addison Phillips" To: "Debbie Garside" , X-OriginalArrivalTime: 18 Apr 2005 19:54:59.0758 (UTC) FILETIME=[80B894E0:01C54450] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Debbie, I agree that we probably did reach consensus and support the changes = you'd like to make but am waiting for Randy to bless same. I only made changes to section 8 [Changes] (you'll find your name there = next to the entry describing what I did).=20 Personally, I'd favor changing the rules in Section 3.5 (possibilities = for registration) to say that alpha4 subtags will not be considered for = registration of primary languages "anticipating work that is currently = under way on ISO 639".=20 We should also change this item in section 2.2.1: Other values MUST NOT be assigned to the primary subtag except by = revision or update of this document.=20 To say: Other values MUST NOT be assigned to the primary subtag except by = revision or update of this document. Work on additional parts of ISO 639 = is the most likely source for future assignments. If we change the ABNF I think it should be to: lang =3D 2*8ALPHA ; ISO 639 code or other registered value But I don't think the ABNF really needs to be changed. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Sent: lundi 18 avril 2005 12:47 > To: Addison Phillips; ltru@ietf.org > Subject: RE: [Ltru] new version posted online >=20 > Hi Addison (on list this time :-)) >=20 > Will you be incorporating a reserved alpha4 for ISO 639-6 in the next > draft? > I believe consensus was reached on this issue... as raised by Doug. >=20 > Kind regards >=20 > Debbie >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Addison Phillips > > Sent: 18 April 2005 18:32 > > To: ltru@ietf.org > > Subject: [Ltru] new version posted online > > > > The draft-01 prototype has been updated and posted at: > > > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.txt > > http://www.inter-locale.com/ID/draft-ietf-ltur-registry-01.html > > > > I have incorporated 'Suppress_Script' into the various places = required > to > > define it (many parts of section 3). Of course we can decide on a > > different name if so desired. Right now the text is the key. Note = that I > > used a different example from en/en-Latn in section 3.1. I also put = a > > script of 'Arab' on the language 'ar' in the example registry. > > > > Other minor changes/corrections are listed in the changes section. > > > > Are we close to done with this issue, enough for me to start work on > > preparing the next officially submitted draft? > > > > Best Regards, > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > http://www.quest.com > > > > Chair, W3C Internationalization Core Working Group > > http://www.w3.org/International > > > > Internationalization is not a feature. > > It is an architecture. > > >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 16:29:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcrx-0004HE-QN; Mon, 18 Apr 2005 16:29:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcrx-0004Gw-4E for ltru@megatron.ietf.org; Mon, 18 Apr 2005 16:29:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05004 for ; Mon, 18 Apr 2005 16:29:18 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNd2m-0000cs-R2 for ltru@ietf.org; Mon, 18 Apr 2005 16:40:35 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 13:29:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: new version posted online Date: Mon, 18 Apr 2005 13:29:02 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08E0D1@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: new version posted online Thread-Index: AcVEUlmqvWaLIUi5SlSFXzURpU7aEwAAGhKA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 18 Apr 2005 20:29:03.0302 (UTC) FILETIME=[42C4A660:01C54455] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Interlinear below. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: lundi 18 avril 2005 12:44 > To: ltru@ietf.org > Subject: [Ltru] Re: new version posted online >=20 > Addison Phillips wrote: >=20 > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.txt >=20 > Very quick scan: >=20 > | lang =3D 2*3ALPHA ; shortest ISO 639 code >=20 > We discussed 2*4ALPHA and a change of registered-lang, and/or > to replace registered-lang by "individual" (i-* split off from > grandfathered) [Addison Phillips]=20 I strongly dislike the i-* being put back. Why separate registered = values of any type? We have a registry: that makes things clean. I support reserving the alpha4 for the possibility of ISO 639-6 (we know = it exists, why pretend otherwise?) But I'd prefer we do it by rule = rather than in the ABNF. See previous email. >=20 > | subtlety in the ABNF for 'variant' >=20 > Yes, let's eliminate it, how about this: >=20 > variant =3D (5*8alphanum) ; registered variants > / (DIGIT 3alphanum) [Addison Phillips]=20 Because that's fairly subtle too? And incorrect as written. Should be: Variant =3D 5*8alphanum=20 / DIGIT 3*7alphanum That is, we don't have the Y10K problem :-) >=20 > Why do you get [RFC2234] in your xref, if the reference is the > 2234bis I-D, is that an xml2rfc oddity ? [Addison Phillips]=20 Fixed the text. It is obliquely an xml2rfc oddity. >=20 > | However, in the tags defined by this document, the uppercase > | US-ASCII letters in the range 'A' (ABNF: %x41) through 'Z' > | (ABNF: %x5A) are considered equivalent and mapped directly > | to their US-ASCII lowercase equivalents in the range 'a' > | (ABNF: %x61) through 'z' (ABNF: %x7A). Thus the tag > | "mn-Cyrl-MN > [...] >=20 > The mysteries of case insensitive ASCII, please replace it by: >=20 > The tags defined by this document are case insensitive. > Thus the tag "mn-Cyrl-MN > [...] [Addison Phillips]=20 Argh. Somebody make up their mind. We put them in, we take them out. I put them in globally during recent rounds for consistency. They are = ugly and I'd prefer them to go away. So they're gone now. >=20 > For the "missing" empty line before "However" you could use... > > ...near the end of the bullet-list. [Addison Phillips]=20 Yes, but created a separate element instead. Thanks. >=20 > | Any such a limitation MUST be clearly documented >=20 > MUST instead of "pray" is ugly. The text after the RfC 2231 > example is obscure, do you need it ? Why not simply say that > the only way to truncate tags is to remove subtags RTL ? [Addison Phillips]=20 This text was agreed to in a long thread previously (I believe during = the old last call). I am loathe to change normative language without = consensus. But I agree that this text is hideous. >=20 > | Single letter and digit subtags are reserved for >=20 > There are no single digits in the ABNF. [Addison Phillips]=20 No, there aren't. Be we reserve them here so that people don't think we = overlooked them. Question: should we reserve them for extensions now? Or = preserve them for unforeseen circumstances? >=20 > | The primary subtag is the first subtag in a language tag > | and cannot be empty >=20 > No subtag can be empty, how about s/empty/omitted/ ? [Addison Phillips]=20 Okay. Changed to omitted.=20 >=20 > | All language subtags of 4 to 8 characters in length >=20 > 5 to 8, ecause 4 was set aside for Debbie. Don't forget to get > rid of "STRONGLY" in this chapter. [Addison Phillips]=20 Waiting on consensus. >=20 > | Other values MUST NOT be assigned to the primary subtag >=20 > I don't see any i-whatever before this item, is this a trick, > the i-whatever case is no primary subtag ? OTOH there must be > a primary subtag. [Addison Phillips]=20 i-* are all grandfathered by rule. >=20 > | There MAY be any additional number of extended language > | subtags >=20 > Oops, indeed, the ABNF says *("-" extlang). What's the idea ? [Addison Phillips]=20 The idea is that there may be any number of them. Such as "zh-min-nan". = This doesn't break the ABNF or subtag-length-based matching by 3066bis = processors and the like.=20 >=20 > | Users who wished to utilize SIL Ethnologue >=20 > IMHO that needs an informative reference URL. [Addison Phillips]=20 Agreed. I'll dig one up. >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 16:31:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcuB-0004po-09; Mon, 18 Apr 2005 16:31:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcu9-0004pD-Ah for ltru@megatron.ietf.org; Mon, 18 Apr 2005 16:31:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05441 for ; Mon, 18 Apr 2005 16:31:31 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNd4x-0000nD-24 for ltru@ietf.org; Mon, 18 Apr 2005 16:42:48 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3IKVAuC023498; Mon, 18 Apr 2005 13:31:10 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AJFAM>; Mon, 18 Apr 2005 13:31:11 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Marion Gunn Subject: RE: [Ltru] Re: Supress & Require Script Date: Mon, 18 Apr 2005 13:31:10 -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: b19722fc8d3865b147c75ae2495625f2 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Monday, April 18, 2005 1:05 PM > To: McDonald, Ira; Marion Gunn > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Supress & Require Script > > No, each requires a rewrite to make it grammatically correct > and to have a proper subject. > > 1. Use as precise a tag as possible, but no more specific > than is justified. Addison, did you perhaps learn grammar from an unusual source? The _first_ sentence in your "grammatically correct" rewrite is at least no longer in passive voice, but it now lacks a _subject_ who will take the "Use...a tag" action. Every conformance statement in any standard that contains an uppercase imperative (MUST, SHOULD, etc.) should be written with a very explicit subject. In your fragment of a sentence above, was your intended subject: (a) a human or software content searcher; (b) a human or software content creator; (c) a content distribution application; or (d) whatever? Cheers, - Ira _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 16:35:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcyC-0005ZV-52; Mon, 18 Apr 2005 16:35:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcyA-0005ZE-6r for ltru@megatron.ietf.org; Mon, 18 Apr 2005 16:35:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06194 for ; Mon, 18 Apr 2005 16:35:44 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNd91-00019H-Ql for ltru@ietf.org; Mon, 18 Apr 2005 16:47:01 -0400 Received: from h-68-165-4-21.snvacaid.dynamic.covad.net ([68.165.4.21] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DNcy4-0003Ih-00 for ltru@ietf.org; Mon, 18 Apr 2005 13:35:40 -0700 Message-ID: <00f601c54456$6b483e20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08E08E@irvmbxw01.quest.com> Subject: Re: [Ltru] considerations for ISO 639-6 at consensus? (was: newversion posted online) Date: Mon, 18 Apr 2005 13:37:20 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "Debbie Garside" ; > Sent: Monday, April 18, 2005 12:54 PM > Subject: RE: [Ltru] considerations for ISO 639-6 at consensus? (was: newversion posted online) > > Hi Debbie, > > I agree that we probably did reach consensus and support > the changes you'd like to make but am waiting for Randy to > bless same. As co-chair: There certainly seems to be enough agreement (I don't recall any dissent) to warrant incorporating them at this time. I'd like to see an updated i-d posted sooner rather than later. If there are problems in the updated i-d, I'm sure they will be pointed out on this list. This WG's members are not shy. > I only made changes to section 8 [Changes] (you'll find your name there > next to the entry describing what I did). > > Personally, I'd favor changing the rules in Section 3.5 (possibilities for > registration) to say that alpha4 subtags will not be considered for registration > of primary languages "anticipating work that is currently under way on ISO 639". ... As a contributor: this seems reasonable, along with the related mods so that it does the right thing once the ISO 639 alpha4s become available. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 16:35:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcyI-0005aZ-DL; Mon, 18 Apr 2005 16:35:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNcyG-0005aU-Tc for ltru@megatron.ietf.org; Mon, 18 Apr 2005 16:35:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06218 for ; Mon, 18 Apr 2005 16:35:50 -0400 (EDT) Received: from mail02.svc.cra.dublin.eircom.net ([159.134.118.18]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DNd98-00019E-Do for ltru@ietf.org; Mon, 18 Apr 2005 16:47:07 -0400 Received: (qmail 71177 messnum 5247956 invoked from network[194.125.134.97/ts01-097.dublin.indigo.ie]); 18 Apr 2005 20:35:40 -0000 Received: from ts01-097.dublin.indigo.ie (HELO egt.ie) (194.125.134.97) by mail02.svc.cra.dublin.eircom.net (qp 71177) with SMTP; 18 Apr 2005 20:35:40 -0000 Message-ID: <426419AB.C9752235@egt.ie> Date: Mon, 18 Apr 2005 21:33:47 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [Ltru] Re: Supress & Require Script References: <634978A7DF025A40BFEF33EB191E13BC0B08DEFA@irvmbxw01.quest.com> <4263E481.61465A9D@egt.ie> <008301c54448$b9e8c120$7f1afea9@oemcomputer> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA06218 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Scr=EDobh Randy Presuhn: > ... > I do, however, agree that the use of "you" in this way seems odd in > a specification, which by nature is relatively formal. GRMA (Irish acronym for 'Thanks'). > ...=20 > To your list of alternatives I'd add a third option: >=20 > (c) Implementations SHOULD NOT use X >=20 > However, I'm personally content to leave these matters to the editors' > discretion. >=20 As am I. mg --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 16:39:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNd1h-0007HM-5r; Mon, 18 Apr 2005 16:39:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNd1f-0007Gy-So for ltru@megatron.ietf.org; Mon, 18 Apr 2005 16:39:24 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07364 for ; Mon, 18 Apr 2005 16:39:20 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNcvo-0003Bk-2d for ltru@lists.ietf.org; Mon, 18 Apr 2005 22:33:20 +0200 Received: from 212.82.251.75 ([212.82.251.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 22:33:20 +0200 Received: from nobody by 212.82.251.75 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 22:33:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 18 Apr 2005 22:34:52 +0200 Organization: Lines: 40 Message-ID: <426419EC.7E6D@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B08DEFA@irvmbxw01.quest.com> <4263F73C.4816@xyzzy.claranet.de> <00b101c5444a$0f80dfe0$7f1afea9@oemcomputer> 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.75 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Suppress & Require Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > I'd be willing to bet that if we handed something like that > to the IESG it'd come back with questions about why we mixed > "should" and "SHOULD" in the same paragraph, I accept this bet, send them to me... ;-) The problem here is that we want to attach the SHOULD NOT to the "Suppress_script". That's the critical point in this paragraph, "Supprees_script" SHOULD NOT be used. Addison's text doesn't say so, it attaches the SHOULD NOT to a completely different and obvious issue: >| The script subtag SHOULD NOT be used to form language tags >| unless the script adds some distinguishing information to >| the tag. In other words, don't use script for e.g. audio data. That's interesting and correct, but not the really critical case of a "Suppress_script" in the next sentence. The rationale is also incomplete, it doesn't say why we had the "Great Script Debate", and that "Suppress_script" is for compatibility with existing content and 3066 implementations. > If we need to constrain the use of certain subatags in > certain contexts in order to preserve interoperability Is that the case ? An en-scouse-scouse-scouse is obviously nonsense, there's no interoperability issue, the user will get what he wants, some random garbage. But en-Latn-US is critical, and Addison's text doesn't say so. The "Latn" _is_ a "distinguishing information", and the point is that it nevertheless SHOULD NOT be used. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 16:42:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNd4I-0008F3-S3; Mon, 18 Apr 2005 16:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNd4F-0008EW-40 for ltru@megatron.ietf.org; Mon, 18 Apr 2005 16:42:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08104 for ; Mon, 18 Apr 2005 16:42:00 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdF6-0001uM-CU for ltru@ietf.org; Mon, 18 Apr 2005 16:53:17 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3IKffDN024032; Mon, 18 Apr 2005 13:41:41 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AJFFF>; Mon, 18 Apr 2005 13:41:41 -0700 Message-ID: From: "McDonald, Ira" To: "'Debbie Garside'" , "'Addison Phillips'" , ltru@ietf.org Subject: RE: [Ltru] new version posted online Date: Mon, 18 Apr 2005 13:41:41 -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: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, Please reserve the alpha4, rather than just changing the single line of ABNF to "lang = 2*8ALPHA". Keeping the distinction between ISO-based tags and registered tags is important and has rough concensus on this list, IMHO. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Debbie Garside > Sent: Monday, April 18, 2005 3:47 PM > To: 'Addison Phillips'; ltru@ietf.org > Subject: RE: [Ltru] new version posted online > > > Hi Addison (on list this time :-)) > > Will you be incorporating a reserved alpha4 for ISO 639-6 in > the next draft? > I believe consensus was reached on this issue... as raised by Doug. > > Kind regards > > Debbie > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Addison Phillips > > Sent: 18 April 2005 18:32 > > To: ltru@ietf.org > > Subject: [Ltru] new version posted online > > > > The draft-01 prototype has been updated and posted at: > > > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.txt > > http://www.inter-locale.com/ID/draft-ietf-ltur-registry-01.html > > > > I have incorporated 'Suppress_Script' into the various > places required to > > define it (many parts of section 3). Of course we can decide on a > > different name if so desired. Right now the text is the > key. Note that I > > used a different example from en/en-Latn in section 3.1. I > also put a > > script of 'Arab' on the language 'ar' in the example registry. > > > > Other minor changes/corrections are listed in the changes section. > > > > Are we close to done with this issue, enough for me to start work on > > preparing the next officially submitted draft? > > > > Best Regards, > > > > Addison > > > > Addison P. Phillips > > Globalization Architect, Quest Software > > http://www.quest.com > > > > Chair, W3C Internationalization Core Working Group > > http://www.w3.org/International > > > > Internationalization is not a feature. > > It is an architecture. > > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 16:46:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNd8B-0001Ug-32; Mon, 18 Apr 2005 16:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNd86-0001Tq-Qw for ltru@megatron.ietf.org; Mon, 18 Apr 2005 16:46:05 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09223 for ; Mon, 18 Apr 2005 16:46:00 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DNd2o-0004Ed-JP for ltru@lists.ietf.org; Mon, 18 Apr 2005 22:40:34 +0200 Received: from 212.82.251.75 ([212.82.251.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 22:40:34 +0200 Received: from nobody by 212.82.251.75 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 22:40:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 18 Apr 2005 22:13:51 +0200 Organization: Lines: 10 Message-ID: <426414FF.47D8@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B08DEFA@irvmbxw01.quest.com> <4263E481.61465A9D@egt.ie> <008301c54448$b9e8c120$7f1afea9@oemcomputer> 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.75 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Supress & Require Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > I really dislike passive voice Me too. It's an ugly 20th century pseudo-scientific style. It tries to eliminate the subjects and the responsibility. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 16:49:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdBU-0002aO-Pe; Mon, 18 Apr 2005 16:49:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdBS-0002aI-Vv for ltru@megatron.ietf.org; Mon, 18 Apr 2005 16:49:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10108 for ; Mon, 18 Apr 2005 16:49:28 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdMK-0002ms-N6 for ltru@ietf.org; Mon, 18 Apr 2005 17:00:46 -0400 Received: from h-68-165-4-21.snvacaid.dynamic.covad.net ([68.165.4.21] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DNdBP-0007JK-00 for ltru@ietf.org; Mon, 18 Apr 2005 13:49:28 -0700 Message-ID: <010901c54458$58e8f4c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08DEFA@irvmbxw01.quest.com><4263F73C.4816@xyzzy.claranet.de><00b101c5444a$0f80dfe0$7f1afea9@oemcomputer> <426419EC.7E6D@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Suppress & Require Script Date: Mon, 18 Apr 2005 13:51:08 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Monday, April 18, 2005 1:34 PM > Subject: [Ltru] Re: Suppress & Require Script ... > But en-Latn-US is critical, and Addison's text doesn't say so. > The "Latn" _is_ a "distinguishing information", and the point > is that it nevertheless SHOULD NOT be used. ... The fact that several (including you) see "en-Latn-us" as "critical" is precisely what leads me, as a technical contributor, to believe that "MUST NOT" is closer to what we intend. Regarding the need for claritiy that the value of including rationale, I think you and I are in violent agreement. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 16:57:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdIk-0004Cs-PO; Mon, 18 Apr 2005 16:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdIf-0004Ck-WA for ltru@megatron.ietf.org; Mon, 18 Apr 2005 16:56:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11290 for ; Mon, 18 Apr 2005 16:56:55 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdTX-0003J3-On for ltru@ietf.org; Mon, 18 Apr 2005 17:08:13 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3IKuj8G024609; Mon, 18 Apr 2005 13:56:46 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AJFJ4>; Mon, 18 Apr 2005 13:56:46 -0700 Message-ID: From: "McDonald, Ira" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: Supress & Require Script Date: Mon, 18 Apr 2005 13:56:45 -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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org +1 If there are any passive voice sentences anywhere in RFC3066bis they should be rewritten to active voice with precise subjects or deleted. Every single one of them. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Frank Ellermann > Sent: Monday, April 18, 2005 4:14 PM > To: ltru@ietf.org > Subject: [Ltru] Re: Supress & Require Script > > > Randy Presuhn wrote: > > > I really dislike passive voice > > Me too. It's an ugly 20th century pseudo-scientific style. > It tries to eliminate the subjects and the responsibility. > > Bye, Frank > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 16:57:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdIy-0004Eu-Ef; Mon, 18 Apr 2005 16:57:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdIv-0004Ea-20 for ltru@megatron.ietf.org; Mon, 18 Apr 2005 16:57:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11312 for ; Mon, 18 Apr 2005 16:57:10 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdTm-0003JT-Sm for ltru@ietf.org; Mon, 18 Apr 2005 17:08:28 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 13:57:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: Supress & Require Script Date: Mon, 18 Apr 2005 13:57:01 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08E114@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Supress & Require Script Thread-Index: AcVEVaCCjWPKmk0DRx+u9V2ivT/3xQAALJUQ From: "Addison Phillips" To: "McDonald, Ira" , "Marion Gunn" X-OriginalArrivalTime: 18 Apr 2005 20:57:02.0609 (UTC) FILETIME=[2BB69010:01C54459] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > Addison, did you perhaps learn grammar from an unusual source? Don't insult my English teachers. They did a fine job, thank you. For starters, I didn't modify either of those sentences in the rewrite. = Here they are from draft-00: # Use as precise a tag as possible, but no more specific than is = justified.=20 # Avoid using subtags that are not important for distinguishing content = in an application.=20 They've been that way for a long time. They were that way in = draft-phillips-langtags-01, for example. And they inherit from RFC = 3066's rather chewy: 1. Use the most precise tagging known to the sender that can be ascertained and is useful within the application context. These can't really be considered "conformance statements". They embody = the famous (but unstated) Rule Zero: tag content wisely and are directed = to the person selecting the tag. In this they differ from the other = items in the list and I left them in a different form to set them out = from the others. In all of these cases, the text is not missing a subject. The subject is = implied, as these sentences are written in the imperative. Go look it = up. (Dang, he did it again) I don't see how we can rewrite them as conformance statements, as those = two sentences represent individual judgment rather than ironclad = requirements. We could move them outside the list, I suppose. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: lundi 18 avril 2005 13:31 > To: Addison Phillips; Marion Gunn > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Supress & Require Script >=20 > > -----Original Message----- > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > Sent: Monday, April 18, 2005 1:05 PM > > To: McDonald, Ira; Marion Gunn > > Cc: ltru@ietf.org > > Subject: RE: [Ltru] Re: Supress & Require Script > > > > No, each requires a rewrite to make it grammatically correct > > and to have a proper subject. > > > > 1. Use as precise a tag as possible, but no more specific > > than is justified. >=20 > Addison, did you perhaps learn grammar from an unusual source? >=20 > The _first_ sentence in your "grammatically correct" rewrite > is at least no longer in passive voice, but it now lacks a > _subject_ who will take the "Use...a tag" action. >=20 > Every conformance statement in any standard that contains an > uppercase imperative (MUST, SHOULD, etc.) should be written > with a very explicit subject. In your fragment of a sentence > above, was your intended subject: >=20 > (a) a human or software content searcher; > (b) a human or software content creator; > (c) a content distribution application; or > (d) whatever? >=20 > Cheers, > - Ira >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 16:58:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdJj-0004Gy-2x; Mon, 18 Apr 2005 16:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdJd-0004Gm-UE for ltru@megatron.ietf.org; Mon, 18 Apr 2005 16:57:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11336 for ; Mon, 18 Apr 2005 16:57:55 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdUV-0003K6-7Y for ltru@ietf.org; Mon, 18 Apr 2005 17:09:12 -0400 Received: from h-68-165-4-21.snvacaid.dynamic.covad.net ([68.165.4.21] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DNdJY-0001jQ-00 for ltru@ietf.org; Mon, 18 Apr 2005 13:57:52 -0700 Message-ID: <010c01c54459$85714be0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08E0D1@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: new version posted online Date: Mon, 18 Apr 2005 13:59:32 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "Frank Ellermann" ; > Sent: Monday, April 18, 2005 1:29 PM > Subject: RE: [Ltru] Re: new version posted online ... > This text was agreed to in a long thread previously > (I believe during the old last call). I am loathe to change > normative language without consensus. But I agree that > this text is hideous. ... This is a new working group, and we shouldn't get hung up on what happened during the old last call on ietf-languages. If there are purely editorial repairs you'd like to propose to the text in question, I think it suffices to float them on this list, and, if no one objects, go ahead and make them. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 17:06:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdRV-0005nu-2a; Mon, 18 Apr 2005 17:06:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdRT-0005np-75 for ltru@megatron.ietf.org; Mon, 18 Apr 2005 17:06:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12075 for ; Mon, 18 Apr 2005 17:06:01 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdcL-0003f2-6g for ltru@ietf.org; Mon, 18 Apr 2005 17:17:18 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 14:05:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: new version posted online Date: Mon, 18 Apr 2005 14:05:51 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08E121@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: new version posted online Thread-Index: AcVEWcDVumqN4sqmRMuucp09A4B96AAADV6g From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 18 Apr 2005 21:05:53.0124 (UTC) FILETIME=[67ECBA40:01C5445A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Editorial repairs, yes. Normative text, though, is substantive and should require more than = Frank and I agreeing to it? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Randy Presuhn > Sent: lundi 18 avril 2005 14:00 > To: ltru@ietf.org > Subject: Re: [Ltru] Re: new version posted online >=20 > Hi - >=20 > > From: "Addison Phillips" > > To: "Frank Ellermann" ; > > Sent: Monday, April 18, 2005 1:29 PM > > Subject: RE: [Ltru] Re: new version posted online > ... > > This text was agreed to in a long thread previously > > (I believe during the old last call). I am loathe to change > > normative language without consensus. But I agree that > > this text is hideous. > ... >=20 > This is a new working group, and we shouldn't get hung up > on what happened during the old last call on ietf-languages. > If there are purely editorial repairs you'd like to propose to > the text in question, I think it suffices to float them on this > list, and, if no one objects, go ahead and make them. >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 17:10:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdVe-0006q9-45; Mon, 18 Apr 2005 17:10:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdVc-0006q4-Gk for ltru@megatron.ietf.org; Mon, 18 Apr 2005 17:10:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12276 for ; Mon, 18 Apr 2005 17:10:18 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdgU-0003jt-EB for ltru@ietf.org; Mon, 18 Apr 2005 17:21:35 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3ILA55G025183; Mon, 18 Apr 2005 14:10:05 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AJF3V>; Mon, 18 Apr 2005 14:10:05 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , "McDonald, Ira" , Marion Gunn Subject: RE: [Ltru] Re: Supress & Require Script Date: Mon, 18 Apr 2005 14:10:05 -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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Monday, April 18, 2005 4:57 PM > To: McDonald, Ira; Marion Gunn > Cc: ltru@ietf.org > Subject: RE: [Ltru] Re: Supress & Require Script > > <...snip...> > > In all of these cases, the text is not missing a subject. The > subject is implied, as these sentences are written in the > imperative. Go look it up. (Dang, he did it again) > > I don't see how we can rewrite them as conformance > statements, as those two sentences represent individual > judgment rather than ironclad requirements. We could move > them outside the list, I suppose. Your grammar's still shaky. An imperative sentence can only be grammatically correct if, in the _preceding_ context, there is exactly one possible implied subject. As my list of possible subjects demonstrated, that's not the case here. And yes, certainly those sentences can be rewritten to be conformance statements. If they can't, then delete them. The IESG may well do so anyway. RFC3066bis will become a BCP which is binding on many other future RFCs. It should be unambiguous enough to yield a largely useable translation by direct machine translation. Otherwise, it's a loose cannon. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 17:10:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdWD-0006x0-Bs; Mon, 18 Apr 2005 17:10:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdWB-0006wr-Dh for ltru@megatron.ietf.org; Mon, 18 Apr 2005 17:10:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12317 for ; Mon, 18 Apr 2005 17:10:51 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdh1-0003kR-9q for ltru@ietf.org; Mon, 18 Apr 2005 17:22:08 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3ILAfqX011652; Mon, 18 Apr 2005 17:10:41 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 18 Apr 2005 17:10:42 -0400 Date: Mon, 18 Apr 2005 17:10:41 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] Re: new version posted online Message-ID: <20050418211041.GD26788@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B08E0D1@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B08E0D1@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips scripsit: > > Oops, indeed, the ABNF says *("-" extlang). What's the idea ? > > The idea is that there may be any number of them. Such as > "zh-min-nan". This doesn't break the ABNF or subtag-length-based > matching by 3066bis processors and the like. zh-min-nan is an evolutionary dead end; we aren't going to represent languages with this sort of (truncated) genealogical tree. When 639-3 comes on line, Min Nan will be zh-nan, and the other Min languages will be zh-mnp (Min Bei), zh-cdo (Min Dong), and zh-czo (Min Zhong). Consequently, I'd be in favor of allowing just a single extlang subtag. > > | Users who wished to utilize SIL Ethnologue > > > > IMHO that needs an informative reference URL. > > Agreed. I'll dig one up. I think it's a poor example, given that the current (15th) edition of the Ethnologue uses DIS 639-3 codes, which we expect to incorporate in a different way. -- John Cowan www.ccil.org/~cowan www.reutershealth.com jcowan@reutershealth.com There are books that are at once excellent and boring. Those that at once leap to the mind are Thoreau's Walden, Emerson's Essays, George Eliot's Adam Bede, and Landor's Dialogues. --Somerset Maugham _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 17:13:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdYZ-0007Ta-Ng; Mon, 18 Apr 2005 17:13:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdYY-0007SZ-74 for ltru@megatron.ietf.org; Mon, 18 Apr 2005 17:13:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12678 for ; Mon, 18 Apr 2005 17:13:19 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdjR-0003nl-2J for ltru@ietf.org; Mon, 18 Apr 2005 17:24:37 -0400 Received: from h-68-165-4-21.snvacaid.dynamic.covad.net ([68.165.4.21] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DNdYV-0006UX-00 for ltru@ietf.org; Mon, 18 Apr 2005 14:13:19 -0700 Message-ID: <012a01c5445b$ae6cb640$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: Supress & Require Script Date: Mon, 18 Apr 2005 14:14:38 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "McDonald, Ira" > To: "'Frank Ellermann'" ; > Sent: Monday, April 18, 2005 1:56 PM > Subject: RE: [Ltru] Re: Supress & Require Script ... > If there are any passive voice sentences anywhere in RFC3066bis > they should be rewritten to active voice with precise subjects > or deleted. Every single one of them. ... Let's not micro-manage our editors. The job is tough enough as it is. Having made our preferences known, let's trust them to make sensible editorial choices. When the updated i-d appears, if there are specific problematic passages that are worth spending WG time on, we can discuss them then. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 17:15:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdai-0007jw-VU; Mon, 18 Apr 2005 17:15:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdah-0007jr-EI for ltru@megatron.ietf.org; Mon, 18 Apr 2005 17:15:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13099 for ; Mon, 18 Apr 2005 17:15:33 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdlZ-0003r9-Ft for ltru@ietf.org; Mon, 18 Apr 2005 17:26:50 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 14:15:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: new version posted online Date: Mon, 18 Apr 2005 14:15:24 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08E131@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: new version posted online Thread-Index: AcVEWxwf0aFSeU7oTJyU/YQ/WP/3RQAACR0g From: "Addison Phillips" To: "John Cowan" X-OriginalArrivalTime: 18 Apr 2005 21:15:25.0085 (UTC) FILETIME=[BCD70CD0:01C5445B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: Frank Ellermann , ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org >=20 > > > Oops, indeed, the ABNF says *("-" extlang). What's the idea ? > > > > The idea is that there may be any number of them. Such as > > "zh-min-nan". This doesn't break the ABNF or subtag-length-based > > matching by 3066bis processors and the like. >=20 > zh-min-nan is an evolutionary dead end; we aren't going to represent > languages > with this sort of (truncated) genealogical tree. When 639-3 comes on = line, > Min Nan will be zh-nan, and the other Min languages will be zh-mnp = (Min > Bei), > zh-cdo (Min Dong), and zh-czo (Min Zhong). [Addison Phillips]=20 Yes, I know, but I needed an example. And it wasn't clear if when we = last examined the issue whether one-layer would be enough or not. = Multiple extlangs don't necessarily hurt anything, although they are a = royal pain to process. Is there consensus to limit to one? >=20 > Consequently, I'd be in favor of allowing just a single extlang = subtag. >=20 > > > | Users who wished to utilize SIL Ethnologue > > > > > > IMHO that needs an informative reference URL. > > > > Agreed. I'll dig one up. >=20 > I think it's a poor example, given that the current (15th) edition of > the Ethnologue uses DIS 639-3 codes, which we expect to incorporate > in a different way. >=20 It is now. It wasn't historically so. Any suggestions? How about a = transliteration example? Addison _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 17:15:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdas-0007ko-9b; Mon, 18 Apr 2005 17:15:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdaq-0007kj-Uv for ltru@megatron.ietf.org; Mon, 18 Apr 2005 17:15:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13110 for ; Mon, 18 Apr 2005 17:15:42 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdli-0003rd-RK for ltru@ietf.org; Mon, 18 Apr 2005 17:27:00 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3ILFX9k025452; Mon, 18 Apr 2005 14:15:33 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3AJFRR>; Mon, 18 Apr 2005 14:15:34 -0700 Message-ID: From: "McDonald, Ira" To: "'Randy Presuhn'" , ltru@ietf.org Subject: RE: [Ltru] Re: Supress & Require Script Date: Mon, 18 Apr 2005 14:15:32 -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: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, Agreed - the job of editor in this WG is both mostly thankless and very underpaid (smile). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Randy Presuhn > Sent: Monday, April 18, 2005 5:15 PM > To: ltru@ietf.org > Subject: Re: [Ltru] Re: Supress & Require Script > > > Hi - > > From: "McDonald, Ira" > > To: "'Frank Ellermann'" ; > > Sent: Monday, April 18, 2005 1:56 PM > > Subject: RE: [Ltru] Re: Supress & Require Script > ... > > If there are any passive voice sentences anywhere in RFC3066bis > > they should be rewritten to active voice with precise subjects > > or deleted. Every single one of them. > ... > > Let's not micro-manage our editors. The job is tough enough as > it is. Having made our preferences known, let's trust them to make > sensible editorial choices. When the updated i-d appears, if there > are specific problematic passages that are worth spending WG > time on, we can discuss them then. > > Randy > > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 17:19:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdeM-0007wq-Tw; Mon, 18 Apr 2005 17:19:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdeM-0007wl-0W for ltru@megatron.ietf.org; Mon, 18 Apr 2005 17:19:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13538 for ; Mon, 18 Apr 2005 17:19:19 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdpE-0003zb-O0 for ltru@ietf.org; Mon, 18 Apr 2005 17:30:37 -0400 Received: from h-68-165-4-21.snvacaid.dynamic.covad.net ([68.165.4.21] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DNdeJ-0000W5-00 for ltru@ietf.org; Mon, 18 Apr 2005 14:19:19 -0700 Message-ID: <012b01c5445c$84f5abe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0B08E121@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: new version posted online Date: Mon, 18 Apr 2005 14:21:00 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Addison Phillips" > To: "Randy Presuhn" ; > Sent: Monday, April 18, 2005 2:05 PM > Subject: RE: [Ltru] Re: new version posted online > > Editorial repairs, yes. > > Normative text, though, is substantive and should require more > than Frank and I agreeing to it? ... If the change alters the *meaning*, or if the specific wording was the result of on-list wordsmithing (not just a long discussion to get agreement on the concept), then we should specifically look for consensus. Otherwise, If a section of text is merely "ugly", and your belief is that the change would not represent a change in meaning, then I'm content if you simply float it to the list so no one is surprised. If your change unintentionally extends or limits the semantics, this list provides ample opportunity for that change to be corrected. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 17:26:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdlj-0000Z7-3R; Mon, 18 Apr 2005 17:26:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdlg-0000YQ-Ai for ltru@megatron.ietf.org; Mon, 18 Apr 2005 17:26:57 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14412 for ; Mon, 18 Apr 2005 17:26:52 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNdgT-0001Nm-8R for ltru@lists.ietf.org; Mon, 18 Apr 2005 23:21:33 +0200 Received: from 212.82.251.75 ([212.82.251.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 23:21:33 +0200 Received: from nobody by 212.82.251.75 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 23:21:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 18 Apr 2005 23:22:33 +0200 Organization: Lines: 59 Message-ID: <42642519.7B38@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B08E0D1@irvmbxw01.quest.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.75 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: new version posted online X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > I strongly dislike the i-* being put back. Okay, let's solve the alpha-4 issue in -01 and discuss the need of any other registered-lang after -01, it's unrelated. >> variant = (5*8alphanum) ; registered variants >> / (DIGIT 3alphanum) > Because that's fairly subtle too? And incorrect as written. No, it's okay, anything with 5 up to 8 let-dig uses the first alternative, the second alternative handles the special case "length 4" (starting with a digit). > Variant = 5*8alphanum > / DIGIT 3*7alphanum Also correct, but then both alternatives match for length > 4 starting with a digit. I'd prefer an unambiguous ABNF where possible. Your subtle ABNF (reflected in the text later) is "alpha or digit", my less subtle variant is "length 5..8 or 4". [case insensitive US ASCII] > Argh. Somebody make up their mind. We put them in, we take > them out. It's not that important. Arguing formally you could say that it's explained in 2234bis. Or reference RfC 20 just for fun. >>| Single letter and digit subtags are reserved for >> There are no single digits in the ABNF. > No, there aren't. Be we reserve them here so that people > don't think we overlooked them. Okay, you could add DIGIT to singleton in the ABNF. Otherwise it makes me nervous if the text talks about something that's not in the ABNF or vice versa. >> I don't see any i-whatever before this item, is this a >> trick, the i-whatever case is no primary subtag ? OTOH >> there must be a primary subtag. > i-* are all grandfathered by rule. Sure, but your text says: | The primary subtag is the first subtag in a language tag Then you enumerate all cases incl. x-, but not i-. Somewhere I miss i-. Maybe you need something like this: The primary subtag is the first subtag in a language tag, if the language tag is no grandfathered tag (see 2.2.8). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 17:29:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdnp-00015J-12; Mon, 18 Apr 2005 17:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdnn-00015E-Er for ltru@megatron.ietf.org; Mon, 18 Apr 2005 17:29:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14583 for ; Mon, 18 Apr 2005 17:29:05 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNdyf-0004MC-JZ for ltru@ietf.org; Mon, 18 Apr 2005 17:40:22 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 18 Apr 2005 14:29:14 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 18 Apr 2005 14:28:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] considerations for ISO 639-6 at consensus? (was: newversion posted online) Date: Mon, 18 Apr 2005 14:26:54 -0700 Message-ID: Thread-Topic: [Ltru] considerations for ISO 639-6 at consensus? (was: newversion posted online) Thread-Index: AcVEPIQm1p6GhqPxSU63jERFJ22XQAAEshJgAAAJAQAAAxiLQA== From: "Peter Constable" To: X-OriginalArrivalTime: 18 Apr 2005 21:28:52.0083 (UTC) FILETIME=[9DD92C30:01C5445D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > Personally, I'd favor changing the rules in Section 3.5 (possibilities for registration) to > say that alpha4 subtags will not be considered for registration of primary languages > "anticipating work that is currently under way on ISO 639". I have a bit of reservation about this wording. In contrast to the situation with ISO 639-3, which had passed a CD ballot prior to any suggestion that anything anticipatory be done in the RFC, the ISO 639-6 project is just beginning; I believe a working draft hasn't yet been registered. It's entirely possible that the ISO 639-6 project may not result in an alpha-4 code.=20 I've no problem with reserving alpha4 subtags; it's just the wording "anticipating work that is currently under way on ISO 639" on which I have some reservations: it causes this document to create a level of expectation regarding ISO deliverables that are not appropriate for IETF to be setting. I'd rather see a vaguer wording, something like, "allowing for the possibility of an alpha4 code in some future addition to the ISO 639 family of standards." Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 17:36:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNduq-0002SH-8p; Mon, 18 Apr 2005 17:36:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNdup-0002Rp-D2 for ltru@megatron.ietf.org; Mon, 18 Apr 2005 17:36:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14862 for ; Mon, 18 Apr 2005 17:36:21 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNe5i-0004YS-JY for ltru@ietf.org; Mon, 18 Apr 2005 17:47:38 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3ILaD0A011933; Mon, 18 Apr 2005 17:36:14 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 18 Apr 2005 17:36:33 -0400 Date: Mon, 18 Apr 2005 17:36:33 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] Re: new version posted online Message-ID: <20050418213633.GE26788@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B08E131@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B08E131@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips scripsit: > > > > Oops, indeed, the ABNF says *("-" extlang). What's the idea ? > > > > > > The idea is that there may be any number of them. Such as > > > "zh-min-nan". This doesn't break the ABNF or subtag-length-based > > > matching by 3066bis processors and the like. > > > > zh-min-nan is an evolutionary dead end; we aren't going to represent > > languages > > with this sort of (truncated) genealogical tree. When 639-3 comes on line, > > Min Nan will be zh-nan, and the other Min languages will be zh-mnp (Min > > Bei), > > zh-cdo (Min Dong), and zh-czo (Min Zhong). > [Addison Phillips] > > Yes, I know, but I needed an example. And it wasn't clear if when > we last examined the issue whether one-layer would be enough or > not. The only way that multiple extlang subtags would be needed in the 639-3 context is if one of the 365 individual languages that are components of a macrolanguage (about 0.5% of the total) was itself determined to be a macrolanguage; that is, if ISO 639-3/RA decided that some of its dialects were really distinct languages. Since Ethnologue is already quite far toward the splitter end of the lumper/splitter continuum, I'd be comfortable with betting against that. In any case, if we'd already registered the dialects as variants, stability would require that we keep them that way. > Multiple extlangs don't necessarily hurt anything, although they > are a royal pain to process. Being a pain to process does indeed "hurt something", namely implementation cost. > Is there consensus to limit to one? > > > > Consequently, I'd be in favor of allowing just a single extlang subtag. > > > > > > | Users who wished to utilize SIL Ethnologue > > > > > > > > IMHO that needs an informative reference URL. > > > > > > Agreed. I'll dig one up. > > > > I think it's a poor example, given that the current (15th) edition of > > the Ethnologue uses DIS 639-3 codes, which we expect to incorporate > > in a different way. > > > It is now. It wasn't historically so. Any suggestions? How about a > transliteration example? Frankly, I have a lot of trouble thinking of anything that would be closely coupled to languages but isn't already covered by our quadripartite scheme. -- Do I contradict myself? John Cowan Very well then, I contradict myself. jcowan@reutershealth.com I am large, I contain multitudes. http://www.ccil.org/~cowan --Walt Whitman, Leaves of Grass http://www.reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 17:51:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNe8z-0005wm-Kh; Mon, 18 Apr 2005 17:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNe8y-0005wh-U4 for ltru@megatron.ietf.org; Mon, 18 Apr 2005 17:51:01 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15810 for ; Mon, 18 Apr 2005 17:50:58 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNe4H-0004aw-LQ for ltru@lists.ietf.org; Mon, 18 Apr 2005 23:46:09 +0200 Received: from 212.82.251.75 ([212.82.251.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 23:46:09 +0200 Received: from nobody by 212.82.251.75 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Apr 2005 23:46:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 18 Apr 2005 23:48:46 +0200 Organization: Lines: 23 Message-ID: <42642B3D.693F@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.75 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Suppress & Require Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org McDonald, Ira wrote: > The _first_ sentence in your "grammatically correct" rewrite > is at least no longer in passive voice, but it now lacks a > _subject_ who will take the "Use...a tag" action. What's wrong with an imperative ? | Note that the force of these words is modified by the | requirement level of the document in which they are used. The subject of Addison's "Use" or this "Note" is the reader. That covers your cases (a)..(d). Is there a reason why you think that not all readers are directly affected ? As far as I'm concered the complete "Use..." imperative is hot air, I read "be precise but OTOH don't exaggerate it". It would be much more interesting with reasons WHY very precise tags are not always useful, or even counterproductive. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 18:05:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNeN5-0006Xg-Aj; Mon, 18 Apr 2005 18:05:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNeN4-0006Xb-D8 for ltru@megatron.ietf.org; Mon, 18 Apr 2005 18:05:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16815 for ; Mon, 18 Apr 2005 18:05:31 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNeXx-0005ze-QZ for ltru@ietf.org; Mon, 18 Apr 2005 18:16:50 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 15:05:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: new version posted online Date: Mon, 18 Apr 2005 15:05:22 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B08E182@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: new version posted online Thread-Index: AcVEXV/mlvj89+ClQJKWCv2MKJbSCwABLjZw From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 18 Apr 2005 22:05:23.0121 (UTC) FILETIME=[B7CF0A10:01C54462] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Some more interlinear, elision as necessary. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann >=20 > >> variant =3D (5*8alphanum) ; registered variants > >> / (DIGIT 3alphanum) >=20 > > Because that's fairly subtle too? And incorrect as written. >=20 > No, it's okay, anything with 5 up to 8 let-dig uses the first > alternative, the second alternative handles the special case > "length 4" (starting with a digit). [Addison Phillips]=20 Yes, I caught that. >=20 > > Variant =3D 5*8alphanum > > / DIGIT 3*7alphanum >=20 > Also correct, but then both alternatives match for length > 4 > starting with a digit. I'd prefer an unambiguous ABNF where > possible. Your subtle ABNF (reflected in the text later) is > "alpha or digit", my less subtle variant is "length 5..8 or 4". [Addison Phillips]=20 Yes, I saw that. You appear to be the only other person who liked my = original date subtag from draft-phillips-langtags-less-than-zero :-). I = think there is a diminishing return to ruling out various subtag forms. = Why allow '1dr5' and not '1234567'?=20 >=20 > [case insensitive US ASCII] > > Argh. Somebody make up their mind. We put them in, we take > > them out. >=20 > It's not that important. Arguing formally you could say that > it's explained in 2234bis. Or reference RfC 20 just for fun. [Addison Phillips]=20 (laughing) I took them out. >=20 > >>| Single letter and digit subtags are reserved for > >> There are no single digits in the ABNF. >=20 > > No, there aren't. Be we reserve them here so that people > > don't think we overlooked them. >=20 > Okay, you could add DIGIT to singleton in the ABNF. Otherwise > it makes me nervous if the text talks about something that's > not in the ABNF or vice versa. [Addison Phillips]=20 Okay. >=20 > >> I don't see any i-whatever before this item, is this a > >> trick, the i-whatever case is no primary subtag ? OTOH > >> there must be a primary subtag. >=20 > > i-* are all grandfathered by rule. >=20 > Sure, but your text says: >=20 > | The primary subtag is the first subtag in a language tag >=20 > Then you enumerate all cases incl. x-, but not i-. Somewhere > I miss i-. Maybe you need something like this: >=20 > The primary subtag is the first subtag in a language tag, > if the language tag is no grandfathered tag (see 2.2.8). >=20 That's an excellent idea. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 18:27:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNeiH-0001R1-EC; Mon, 18 Apr 2005 18:27:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNeiG-0001Qv-Lz for ltru@megatron.ietf.org; Mon, 18 Apr 2005 18:27:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19270 for ; Mon, 18 Apr 2005 18:27:25 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNet9-000707-Qm for ltru@ietf.org; Mon, 18 Apr 2005 18:38:44 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3IMRIua214394 for ; Mon, 18 Apr 2005 18:27:18 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3IMRIIA294080 for ; Mon, 18 Apr 2005 16:27:18 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j3IMRHaP008562 for ; Mon, 18 Apr 2005 16:27:17 -0600 Received: from markdavis (mark-davis.sanjose.ibm.com [9.43.213.112]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3IMRGt0008534; Mon, 18 Apr 2005 16:27:17 -0600 Message-ID: <039301c54465$c6804d50$467a3009@sanjose.ibm.com> From: "Mark Davis" To: "Peter Constable" , References: Subject: Re: [Ltru] considerations for ISO 639-6 at consensus? (was:newversion posted online) Date: Mon, 18 Apr 2005 15:27:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j3IMRIua214394 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org That wording sounds reasonable. =E2=80=8EMark ----- Original Message -----=20 From: "Peter Constable" To: Sent: Monday, April 18, 2005 14:26 Subject: RE: [Ltru] considerations for ISO 639-6 at consensus? (was:newversion posted online) > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Addison Phillips > Personally, I'd favor changing the rules in Section 3.5 (possibilities for registration) to > say that alpha4 subtags will not be considered for registration of primary languages > "anticipating work that is currently under way on ISO 639". I have a bit of reservation about this wording. In contrast to the situation with ISO 639-3, which had passed a CD ballot prior to any suggestion that anything anticipatory be done in the RFC, the ISO 639-6 project is just beginning; I believe a working draft hasn't yet been registered. It's entirely possible that the ISO 639-6 project may not result in an alpha-4 code. I've no problem with reserving alpha4 subtags; it's just the wording "anticipating work that is currently under way on ISO 639" on which I have some reservations: it causes this document to create a level of expectation regarding ISO deliverables that are not appropriate for IETF to be setting. I'd rather see a vaguer wording, something like, "allowing for the possibility of an alpha4 code in some future addition to the ISO 639 family of standards." Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 18:31:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNem9-0003jn-Cg; Mon, 18 Apr 2005 18:31:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNem7-0003hx-PE for ltru@megatron.ietf.org; Mon, 18 Apr 2005 18:31:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19671 for ; Mon, 18 Apr 2005 18:31:25 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNex0-00077b-Et for ltru@ietf.org; Mon, 18 Apr 2005 18:42:43 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 15:31:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] considerations for ISO 639-6 at consensus? (was:newversionposted online) Date: Mon, 18 Apr 2005 15:31:16 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B166C55@irvmbxw01.quest.com> Thread-Topic: [Ltru] considerations for ISO 639-6 at consensus? (was:newversionposted online) Thread-Index: AcVEZdp7lLTJDjvuQk2QSkmg3JWF+gAAE6wQ From: "Addison Phillips" To: "Mark Davis" , "Peter Constable" , X-OriginalArrivalTime: 18 Apr 2005 22:31:17.0191 (UTC) FILETIME=[561B4D70:01C54466] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0813451913==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0813451913== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBwdXQgc29tZXRoaW5nIGV2ZW4gdmFndWVyIGluIDIuMi4xOg0KDQoiQWxsIDQtY2hhcmFjdGVy IGxhbmd1YWdlIHN1YnRhZ3MgYXJlIHJlc2VydmVkIGZvciBwb3NzaWJsZSBmdXR1cmUgc3RhbmRh cmRpemF0aW9uLiINCg0KSSB1c2VkIFBldGVyJ3MgZm9ybXVsYXRpb24gaW4gU2VjdGlvbiAzLjUN Cg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVj dCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBX b3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJ dCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0Bs aXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIE1hcmsgRGF2aXMNCj4gU2VudDogbHVuZGkg MTggYXZyaWwgMjAwNSAxNToyNw0KPiBUbzogUGV0ZXIgQ29uc3RhYmxlOyBsdHJ1QGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbTHRydV0gY29uc2lkZXJhdGlvbnMgZm9yIElTTyA2MzktNiBhdCBj b25zZW5zdXM/DQo+ICh3YXM6bmV3dmVyc2lvbnBvc3RlZCBvbmxpbmUpDQo+IA0KPiBUaGF0IHdv cmRpbmcgc291bmRzIHJlYXNvbmFibGUuDQo+IA0KPiDigI5NYXJrDQo+IA0KPiAtLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206ICJQZXRlciBDb25zdGFibGUiIDxwZXRlcmNvbkBt aWNyb3NvZnQuY29tPg0KPiBUbzogPGx0cnVAaWV0Zi5vcmc+DQo+IFNlbnQ6IE1vbmRheSwgQXBy aWwgMTgsIDIwMDUgMTQ6MjYNCj4gU3ViamVjdDogUkU6IFtMdHJ1XSBjb25zaWRlcmF0aW9ucyBm b3IgSVNPIDYzOS02IGF0IGNvbnNlbnN1cz8NCj4gKHdhczpuZXd2ZXJzaW9uIHBvc3RlZCBvbmxp bmUpDQo+IA0KPiANCj4gPiBGcm9tOiBsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmcgW21haWx0 bzpsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmddDQo+IE9uIEJlaGFsZiBPZg0KPiA+IEFkZGlz b24gUGhpbGxpcHMNCj4gDQo+IA0KPiA+IFBlcnNvbmFsbHksIEknZCBmYXZvciBjaGFuZ2luZyB0 aGUgcnVsZXMgaW4gU2VjdGlvbiAzLjUgKHBvc3NpYmlsaXRpZXMNCj4gZm9yIHJlZ2lzdHJhdGlv bikgdG8NCj4gPiBzYXkgdGhhdCBhbHBoYTQgc3VidGFncyB3aWxsIG5vdCBiZSBjb25zaWRlcmVk IGZvciByZWdpc3RyYXRpb24gb2YNCj4gcHJpbWFyeSBsYW5ndWFnZXMNCj4gPiAiYW50aWNpcGF0 aW5nIHdvcmsgdGhhdCBpcyBjdXJyZW50bHkgdW5kZXIgd2F5IG9uIElTTyA2MzkiLg0KPiANCj4g SSBoYXZlIGEgYml0IG9mIHJlc2VydmF0aW9uIGFib3V0IHRoaXMgd29yZGluZy4gSW4gY29udHJh c3QgdG8gdGhlDQo+IHNpdHVhdGlvbiB3aXRoIElTTyA2MzktMywgd2hpY2ggaGFkIHBhc3NlZCBh IENEIGJhbGxvdCBwcmlvciB0byBhbnkNCj4gc3VnZ2VzdGlvbiB0aGF0IGFueXRoaW5nIGFudGlj aXBhdG9yeSBiZSBkb25lIGluIHRoZSBSRkMsIHRoZSBJU08gNjM5LTYNCj4gcHJvamVjdCBpcyBq dXN0IGJlZ2lubmluZzsgSSBiZWxpZXZlIGEgd29ya2luZyBkcmFmdCBoYXNuJ3QgeWV0IGJlZW4N Cj4gcmVnaXN0ZXJlZC4gSXQncyBlbnRpcmVseSBwb3NzaWJsZSB0aGF0IHRoZSBJU08gNjM5LTYg cHJvamVjdCBtYXkgbm90DQo+IHJlc3VsdCBpbiBhbiBhbHBoYS00IGNvZGUuDQo+IA0KPiBJJ3Zl IG5vIHByb2JsZW0gd2l0aCByZXNlcnZpbmcgYWxwaGE0IHN1YnRhZ3M7IGl0J3MganVzdCB0aGUg d29yZGluZw0KPiAiYW50aWNpcGF0aW5nIHdvcmsgdGhhdCBpcyBjdXJyZW50bHkgdW5kZXIgd2F5 IG9uIElTTyA2MzkiIG9uIHdoaWNoIEkNCj4gaGF2ZSBzb21lIHJlc2VydmF0aW9uczogaXQgY2F1 c2VzIHRoaXMgZG9jdW1lbnQgdG8gY3JlYXRlIGEgbGV2ZWwgb2YNCj4gZXhwZWN0YXRpb24gcmVn YXJkaW5nIElTTyBkZWxpdmVyYWJsZXMgdGhhdCBhcmUgbm90IGFwcHJvcHJpYXRlIGZvciBJRVRG DQo+IHRvIGJlIHNldHRpbmcuIEknZCByYXRoZXIgc2VlIGEgdmFndWVyIHdvcmRpbmcsIHNvbWV0 aGluZyBsaWtlLA0KPiAiYWxsb3dpbmcgZm9yIHRoZSBwb3NzaWJpbGl0eSBvZiBhbiBhbHBoYTQg Y29kZSBpbiBzb21lIGZ1dHVyZSBhZGRpdGlvbg0KPiB0byB0aGUgSVNPIDYzOSBmYW1pbHkgb2Yg c3RhbmRhcmRzLiINCj4gDQo+IA0KPiANCj4gUGV0ZXIgQ29uc3RhYmxlDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcg bGlzdA0KPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2x0cnUNCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVA bGlzdHMuaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bHRydQ0KDQo= --===============0813451913== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0813451913==-- From ltru-bounces@lists.ietf.org Mon Apr 18 18:31:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNemT-0003zW-Qd; Mon, 18 Apr 2005 18:31:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNemR-0003wW-JF for ltru@megatron.ietf.org; Mon, 18 Apr 2005 18:31:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19723 for ; Mon, 18 Apr 2005 18:31:44 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNexL-00078I-38 for ltru@ietf.org; Mon, 18 Apr 2005 18:43:03 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 15:31:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: new version posted online Date: Mon, 18 Apr 2005 15:31:31 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B166C56@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: new version posted online Thread-Index: AcVEXV/mlvj89+ClQJKWCv2MKJbSCwABLjZwAACMHjA= From: "Addison Phillips" To: "Addison Phillips" , "Frank Ellermann" , X-OriginalArrivalTime: 18 Apr 2005 22:31:32.0915 (UTC) FILETIME=[5F7A9830:01C54466] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Okay, I did some work on primary language subtag. See if this works = better: --- 2.2.1 Primary Language Subtag The primary language subtag is the first subtag in a language tag (with the exception of private-use and certain grandfathered tags) and cannot be omitted. The following rules apply to the primary language subtag: o All 2-character language subtags were defined in the IANA registry according to the assignments found in the standard ISO 639 Part 1, "ISO 639-1:2002, Codes for the representation of names of languages -- Part 1: Alpha-2 code" [ISO 639-1] [1], or using assignments subsequently made by the ISO 639 Part 1 maintenance agency or governing standardization bodies. o All 3-character language subtags were defined in the IANA registry according to the assignments found in ISO 639 Part 2, "ISO 639-2:1998 - Codes for the representation of names of languages -- Part 2: Alpha-3 code - edition 1" [ISO 639-2] [2], or assignments subsequently made by the ISO 639 Part 2 maintenance agency or governing standardization bodies. o The subtags in the range 'qaa' through 'qtz' are reserved for private use in language tags. These subtags correspond to codes reserved by ISO 639-2 for private use. These codes MAY be used for non-registered primary-language subtags (instead of using private-use subtags following 'x-'). Please refer to Section 4.4 for more information on private use subtags. o All language subtags of 5 to 8 characters in length in the IANA registry were defined via the registration process in Section 3.4 and MAY be used to form the primary language subtag. At the time this document was created, there were no examples of this kind of subtag and future registrations of this type will be discouraged: primary languages are STRONGLY RECOMMENDED for registration with ISO 639 and subtags rejected by ISO 639 will be closely scrutinized before they are registered with IANA. o The single character subtag 'x' as the primary subtag indicates that the language tag consists solely of subtags whose meaning is defined by private agreement. For example, in the tag "x-fr-CH", the subtags 'fr' and 'CH' should not be taken to represent the French language or the country of Switzerland (or any other value in the IANA registry) unless there is a private agreement in place to do so. See Section 4.4. o The single character subtag 'i' is used by some grandfathered tags (see Section 2.2.8) such as "i-klingon" and "i-bnn". (Other = grandfathered tags have a primary language subtag in their first = position) o All 4-character language subtags are reserved for possible future = standardization. o Other values MUST NOT be assigned to the primary subtag except by revision or update of this document. --- Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Addison Phillips > Sent: lundi 18 avril 2005 15:05 > To: Frank Ellermann; ltru@ietf.org > Subject: RE: [Ltru] Re: new version posted online >=20 > Some more interlinear, elision as necessary. >=20 > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group >=20 > Internationalization is not a feature. > It is an architecture. >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Frank Ellermann >=20 > > > > >> variant =3D (5*8alphanum) ; registered variants > > >> / (DIGIT 3alphanum) > > > > > Because that's fairly subtle too? And incorrect as written. > > > > No, it's okay, anything with 5 up to 8 let-dig uses the first > > alternative, the second alternative handles the special case > > "length 4" (starting with a digit). > [Addison Phillips] >=20 > Yes, I caught that. >=20 > > > > > Variant =3D 5*8alphanum > > > / DIGIT 3*7alphanum > > > > Also correct, but then both alternatives match for length > 4 > > starting with a digit. I'd prefer an unambiguous ABNF where > > possible. Your subtle ABNF (reflected in the text later) is > > "alpha or digit", my less subtle variant is "length 5..8 or 4". > [Addison Phillips] >=20 > Yes, I saw that. You appear to be the only other person who liked my > original date subtag from draft-phillips-langtags-less-than-zero :-). = I > think there is a diminishing return to ruling out various subtag = forms. > Why allow '1dr5' and not '1234567'? >=20 > > > > [case insensitive US ASCII] > > > Argh. Somebody make up their mind. We put them in, we take > > > them out. > > > > It's not that important. Arguing formally you could say that > > it's explained in 2234bis. Or reference RfC 20 just for fun. > [Addison Phillips] >=20 > (laughing) I took them out. > > > > >>| Single letter and digit subtags are reserved for > > >> There are no single digits in the ABNF. > > > > > No, there aren't. Be we reserve them here so that people > > > don't think we overlooked them. > > > > Okay, you could add DIGIT to singleton in the ABNF. Otherwise > > it makes me nervous if the text talks about something that's > > not in the ABNF or vice versa. > [Addison Phillips] >=20 > Okay. > > > > >> I don't see any i-whatever before this item, is this a > > >> trick, the i-whatever case is no primary subtag ? OTOH > > >> there must be a primary subtag. > > > > > i-* are all grandfathered by rule. > > > > Sure, but your text says: > > > > | The primary subtag is the first subtag in a language tag > > > > Then you enumerate all cases incl. x-, but not i-. Somewhere > > I miss i-. Maybe you need something like this: > > > > The primary subtag is the first subtag in a language tag, > > if the language tag is no grandfathered tag (see 2.2.8). > > > That's an excellent idea. >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 18:49:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNf3d-0004wv-47; Mon, 18 Apr 2005 18:49:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNf3b-0004wq-9z for ltru@megatron.ietf.org; Mon, 18 Apr 2005 18:49:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20834 for ; Mon, 18 Apr 2005 18:49:28 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNfEV-0007tJ-50 for ltru@ietf.org; Mon, 18 Apr 2005 19:00:47 -0400 Received: from smtp-los03.proxy.aol.com (smtp-los03.proxy.aol.com [195.93.24.41]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN3-44264396f335; Mon, 18 Apr 2005 18:49:19 -0500 Received: from DEBHOME (ACBC22BD.ipt.aol.com [172.188.34.189]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j3IMnC1a002523; Mon, 18 Apr 2005 18:49:12 -0400 Message-Id: <200504182249.j3IMnC1a002523@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Peter Constable'" , Subject: RE: [Ltru] considerations for ISO 639-6 at consensus? (was:newversion posted online) Date: Mon, 18 Apr 2005 23:49:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcVEPIQm1p6GhqPxSU63jERFJ22XQAAEshJgAAAJAQAAAxiLQAAAqFHg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.7 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable wrote: > I've no problem with reserving alpha4 subtags; it's just the wording > "anticipating work that is currently under way on ISO 639" on which I > have some reservations: it causes this document to create a level of > expectation regarding ISO deliverables that are not appropriate for IETF > to be setting. I'd rather see a vaguer wording, something like, > "allowing for the possibility of an alpha4 code in some future addition > to the ISO 639 family of standards." I think this is entirely appropriate. Debbie Garside > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Peter Constable > Sent: 18 April 2005 22:27 > To: ltru@ietf.org > Subject: RE: [Ltru] considerations for ISO 639-6 at consensus? > (was:newversion posted online) > > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On Behalf Of > > Addison Phillips > > > > Personally, I'd favor changing the rules in Section 3.5 (possibilities > for registration) to > > say that alpha4 subtags will not be considered for registration of > primary languages > > "anticipating work that is currently under way on ISO 639". > > I have a bit of reservation about this wording. In contrast to the > situation with ISO 639-3, which had passed a CD ballot prior to any > suggestion that anything anticipatory be done in the RFC, the ISO 639-6 > project is just beginning; I believe a working draft hasn't yet been > registered. It's entirely possible that the ISO 639-6 project may not > result in an alpha-4 code. > > I've no problem with reserving alpha4 subtags; it's just the wording > "anticipating work that is currently under way on ISO 639" on which I > have some reservations: it causes this document to create a level of > expectation regarding ISO deliverables that are not appropriate for IETF > to be setting. I'd rather see a vaguer wording, something like, > "allowing for the possibility of an alpha4 code in some future addition > to the ISO 639 family of standards." > > > > Peter Constable > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 18:55:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNf9H-0005OO-Ps; Mon, 18 Apr 2005 18:55:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNf9G-0005OH-OB for ltru@megatron.ietf.org; Mon, 18 Apr 2005 18:55:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21262 for ; Mon, 18 Apr 2005 18:55:19 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNfKA-0008Dk-Do for ltru@ietf.org; Mon, 18 Apr 2005 19:06:38 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 15:55:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] considerations for ISO 639-6 at consensus? (was:newversionposted online) Date: Mon, 18 Apr 2005 15:55:11 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B166C6F@irvmbxw01.quest.com> Thread-Topic: [Ltru] considerations for ISO 639-6 at consensus? (was:newversionposted online) Thread-Index: AcVEPIQm1p6GhqPxSU63jERFJ22XQAAEshJgAAAJAQAAAxiLQAAAqFHgAALBuDA= From: "Addison Phillips" To: "Debbie Garside" , "Peter Constable" , X-OriginalArrivalTime: 18 Apr 2005 22:55:12.0970 (UTC) FILETIME=[ADE5CAA0:01C54469] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I have posted Yet Another Editor's Copy. In section 3.5 you'll find: Note: 4-character primary language subtags are currently reserved to = allow for the possibility of alpha4 codes in some future addition to the = ISO 639 family of standards. I'm dropping the word 'currently', btw. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Debbie Garside > Sent: lundi 18 avril 2005 15:50 > To: 'Peter Constable'; ltru@ietf.org > Subject: RE: [Ltru] considerations for ISO 639-6 at consensus? > (was:newversionposted online) >=20 > Peter Constable wrote: >=20 > > I've no problem with reserving alpha4 subtags; it's just the wording > > "anticipating work that is currently under way on ISO 639" on which = I > > have some reservations: it causes this document to create a level of > > expectation regarding ISO deliverables that are not appropriate for = IETF > > to be setting. I'd rather see a vaguer wording, something like, > > "allowing for the possibility of an alpha4 code in some future = addition > > to the ISO 639 family of standards." >=20 > I think this is entirely appropriate. >=20 > Debbie Garside >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Peter Constable > > Sent: 18 April 2005 22:27 > > To: ltru@ietf.org > > Subject: RE: [Ltru] considerations for ISO 639-6 at consensus? > > (was:newversion posted online) > > > > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > > On Behalf Of > > > Addison Phillips > > > > > > > Personally, I'd favor changing the rules in Section 3.5 = (possibilities > > for registration) to > > > say that alpha4 subtags will not be considered for registration of > > primary languages > > > "anticipating work that is currently under way on ISO 639". > > > > I have a bit of reservation about this wording. In contrast to the > > situation with ISO 639-3, which had passed a CD ballot prior to any > > suggestion that anything anticipatory be done in the RFC, the ISO = 639-6 > > project is just beginning; I believe a working draft hasn't yet been > > registered. It's entirely possible that the ISO 639-6 project may = not > > result in an alpha-4 code. > > > > I've no problem with reserving alpha4 subtags; it's just the wording > > "anticipating work that is currently under way on ISO 639" on which = I > > have some reservations: it causes this document to create a level of > > expectation regarding ISO deliverables that are not appropriate for = IETF > > to be setting. I'd rather see a vaguer wording, something like, > > "allowing for the possibility of an alpha4 code in some future = addition > > to the ISO 639 family of standards." > > > > > > > > Peter Constable > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 19:59:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNg8v-0006js-8J; Mon, 18 Apr 2005 19:59:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNg8t-0006jb-Rm for ltru@megatron.ietf.org; Mon, 18 Apr 2005 19:59:04 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25466 for ; Mon, 18 Apr 2005 19:59:01 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNg4i-000102-5o for ltru@lists.ietf.org; Tue, 19 Apr 2005 01:54:44 +0200 Received: from 212.82.251.75 ([212.82.251.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Apr 2005 01:54:44 +0200 Received: from nobody by 212.82.251.75 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Apr 2005 01:54:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 19 Apr 2005 01:55:57 +0200 Organization: Lines: 71 Message-ID: <4264490D.5175@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B08E182@irvmbxw01.quest.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.75 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: new version posted online X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > I think there is a diminishing return to ruling out various > subtag forms. Why allow '1dr5' and not '1234567'? Just to be sure, 1dr5 matches the less subtle DIGIT 3alphanum, and it matches DIGIT 3*7alphanum, so it's okay in all discussed ABNF versions. 1234567 matches a less subtle 5*8alphanum, and it matches a subtle DIGIT 3*7alphanum, also okay. The subtle ABNF and the less subtle ABNF for a variant are equivalent. Starting with chapter 3 - I like to read ABNF, it's addictive: | field-name = *(ALPHA/NUM/%x5F) IMHO it's better to enumerate them. Do we have any convincing reasons to use "_" instead of "-" in field names ? Mail and news header field names use "-" (no rule, an observation). You use uppercase for character names everywhere (HYPHEN-MINUS, COLON, AMPERSAND, EURO-SIGN), I'm not sure about this style. The XML-URl is still the 3rd ed., not the shorter generic URL of the latest version: http://www.w3.org/TR/REC-xml/#dt-charref For an explanation of "folding" you could reference RfC 822, but actually the FWS in 2822 is better than the LWSP in 2234bis for this purpose. LWSP allows "empty" lines (trailing blanks), we don't need or want this in the registry. Better _copy_ FWS from RfC 2822, we also don't need or want obs-FWS: field-body = *( ASCCHAR / FWS ) FWS = [*WSP CRLF] 1*WSP ; Folding white space For 'subtag' you say "MUST only..." enumerating the five types. For 'tag' you say "MUST" (gradfathered / redundant) followed by a "MUST NOT...". The "MUST only..." style without "MUST NOT" is less verbose. | Description values are restricted to the Basic Latin and | Latin-1 blocks as defined by Unicode [7] (that is, ISO/IEC | 10646 character numbers less than U+0100). Why this restriction ? What's wrong with say Zcaron, Yuml, or OElig ? You even have the Euro as example elsewhere. | For example: 2004-06-28 represents June 28, 2004, in the | Gregorian calendar. Once is enough, you have it in Added _and_ Depreated. But an example for Recommended_Prefix where it's defined could be useful. You could say that it's _never_ used for a 'Language', like you later say that Suppress_Script MAY _only_ be used for a 'Language'. Some field definitios have a period, others don't. In "Either 'Subtag' or 'Tag'" that results in two unseparated sentences. I'm not happy with the canonical rules, they have undesirable effects for region codes => JFTR, after draft -01. But there's another STRONGLY in this section. | Comments The examples use "Comment" (singular). Later there's another "Comments". Quite a lot of examples, maybe you can delete some less interesting examples, e.g. either Africa or North America. I'll scan 3.2 ff. later, bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 20:19:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNgSs-0002e6-A6; Mon, 18 Apr 2005 20:19:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNgSr-0002dr-3d for ltru@megatron.ietf.org; Mon, 18 Apr 2005 20:19:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26659 for ; Mon, 18 Apr 2005 20:19:39 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNgdl-00035b-8p for ltru@ietf.org; Mon, 18 Apr 2005 20:30:57 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 17:19:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: new version posted online Date: Mon, 18 Apr 2005 17:19:24 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B166CC2@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: new version posted online Thread-Index: AcVEcsD9Nr2DaOt1SF6W2cBKS/VmKAAACOVA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 19 Apr 2005 00:19:24.0779 (UTC) FILETIME=[7102ABB0:01C54475] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Some notes below. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: lundi 18 avril 2005 16:56 > To: ltru@ietf.org > Subject: [Ltru] Re: new version posted online >=20 > Addison Phillips wrote: >=20 > > I think there is a diminishing return to ruling out various > > subtag forms. Why allow '1dr5' and not '1234567'? >=20 > Just to be sure, 1dr5 matches the less subtle DIGIT 3alphanum, > and it matches DIGIT 3*7alphanum, so it's okay in all discussed > ABNF versions. 1234567 matches a less subtle 5*8alphanum, and > it matches a subtle DIGIT 3*7alphanum, also okay. The subtle > ABNF and the less subtle ABNF for a variant are equivalent. [Addison Phillips]=20 Something like that. >=20 > Starting with chapter 3 - I like to read ABNF, it's addictive: >=20 > | field-name =3D *(ALPHA/NUM/%x5F) >=20 > IMHO it's better to enumerate them. Do we have any convincing > reasons to use "_" instead of "-" in field names ? Mail and > news header field names use "-" (no rule, an observation). [Addison Phillips]=20 No reason. Actually, hyphen-minus would be more in keeping with the = spirit of 3066 I suppose. >=20 > You use uppercase for character names everywhere (HYPHEN-MINUS, > COLON, AMPERSAND, EURO-SIGN), I'm not sure about this style. [Addison Phillips]=20 The names are all Unicode character names. Thankfully we don't have any = examples that use Indic zero digits :-).=20 >=20 > The XML-URl is still the 3rd ed., not the shorter generic URL > of the latest version: http://www.w3.org/TR/REC-xml/#dt-charref [Addison Phillips]=20 Will correct. >=20 > For an explanation of "folding" you could reference RfC 822, > but actually the FWS in 2822 is better than the LWSP in 2234bis > for this purpose. LWSP allows "empty" lines (trailing blanks), > we don't need or want this in the registry. Better _copy_ FWS > from RfC 2822, we also don't need or want obs-FWS: >=20 > field-body =3D *( ASCCHAR / FWS ) > FWS =3D [*WSP CRLF] 1*WSP ; Folding white space [Addison Phillips]=20 I thought I referenced the right thing (2234bis) for the ABNF itself. = Using LWSP is a tad bit obscure. Blank lines in the registry don't hurt = anything. Especially if there aren't any. And this ABNF is ultra-tight. >=20 > For 'subtag' you say "MUST only..." enumerating the five types. >=20 > For 'tag' you say "MUST" (gradfathered / redundant) followed by > a "MUST NOT...". The "MUST only..." style without "MUST NOT" > is less verbose. [Addison Phillips]=20 Agreed. >=20 > | Description values are restricted to the Basic Latin and > | Latin-1 blocks as defined by Unicode [7] (that is, ISO/IEC > | 10646 character numbers less than U+0100). >=20 > Why this restriction ? What's wrong with say Zcaron, Yuml, or > OElig ? You even have the Euro as example elsewhere. [Addison Phillips]=20 Description is separate from Comment. Comment allows anything. = Description is fixed to Latin-1. Various folks wanted that limitation to = reference ISO 8859-1, but as a Unicadet I fudged and used Unicode = blocks. And saved a reference.=20 Limiting to "script =3D Latn" is messy, since so many characters might = be construed to be Latin. Personally, I don't agree with having to have = a limitation. Why restrict ourselves unnecessarily? >=20 > | For example: 2004-06-28 represents June 28, 2004, in the > | Gregorian calendar. >=20 > Once is enough, you have it in Added _and_ Depreated.=20 [Addison Phillips]=20 Yes, well... I try to be thorough. It might be better to define date = values and then say that each of these fields (and File_Date) uses that = format. But an > example for Recommended_Prefix where it's defined could be > useful. You could say that it's _never_ used for a 'Language', > like you later say that Suppress_Script MAY _only_ be used for > a 'Language'. [Addison Phillips]=20 Agreed. >=20 > Some field definitios have a period, others don't. In "Either > 'Subtag' or 'Tag'" that results in two unseparated sentences. [Addison Phillips]=20 Will correct. >=20 > I'm not happy with the canonical rules, they have undesirable > effects for region codes =3D> JFTR, after draft -01.=20 [Addison Phillips]=20 I'd like to run out of drafts soon and go to LC on schedule. But let's = get draft-01 out first. But there's > another STRONGLY in this section. [Addison Phillips]=20 I'll step on the STRONG strongly. >=20 > | Comments >=20 > The examples use "Comment" (singular). Later there's another > "Comments". Quite a lot of examples, maybe you can delete some > less interesting examples, e.g. either Africa or North America. [Addison Phillips]=20 Intended to blow some away, will do that now. Perhaps we should also = move the example registry to an Appendix. >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 22:44:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNiiX-0004oP-Vf; Mon, 18 Apr 2005 22:44:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNeS1-0006mi-5d for ltru@megatron.ietf.org; Mon, 18 Apr 2005 18:10:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17441 for ; Mon, 18 Apr 2005 18:10:38 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNect-000649-BX for ltru@ietf.org; Mon, 18 Apr 2005 18:21:56 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Apr 2005 15:10:40 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Mon, 18 Apr 2005 15:10:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Apr 2005 15:08:22 -0700 Message-ID: Thread-Topic: Generic variant subtags in RFC 3066bis Thread-Index: AcVEYAEy9TF4kPXITFeqd2ZVw9WxFgAAIEew From: "Peter Constable" To: , X-OriginalArrivalTime: 18 Apr 2005 22:10:26.0206 (UTC) FILETIME=[6C7623E0:01C54463] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 18 Apr 2005 22:44:01 -0400 Cc: Subject: [Ltru] RE: Generic variant subtags in RFC 3066bis X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages- > bounces@alvestrand.no] On Behalf Of John Cowan > When the RFC 3066bis registry is up and running, I intend to propose some > highly generic variant subtags which may be used with many languages. > Some examples that come to mind are -northern, -southern, -eastern, -western, > and -central for geographical dialects; -ancient and -middle for earlier > versions of languages (-old being too short); Note that ISO 639 does distinguish historic varieties at a low level of granularity. E.g.,=20 ang =3D Old English (ca. 450 - 1100) enm =3D Middle English (1100 - 1500) eng =3D (Modern) English (1500 - present) ISO 639-3 will continue using this approach; the draft code table has 34 "Old" entries and 14 "Middle" entries. The criterion for inclusion is that there candidate historic language must have a body of literature and must be treated as distinct from other historic stages by the scholarly community. > and -highreg, -midreg, and -lowreg > for sociolinguistic registers. Is this really a commonly-used basis for distinction between sociolinguistic registers? Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 18 22:51:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNipJ-0005MD-Dh; Mon, 18 Apr 2005 22:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNipH-0005Kt-KK for ltru@megatron.ietf.org; Mon, 18 Apr 2005 22:50:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06576 for ; Mon, 18 Apr 2005 22:50:55 -0400 (EDT) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNj0B-0007tt-2T for ltru@ietf.org; Mon, 18 Apr 2005 23:02:16 -0400 Received: from h-68-165-4-21.snvacaid.dynamic.covad.net ([68.165.4.21] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DNipC-0002nk-00; Mon, 18 Apr 2005 19:50:54 -0700 Message-ID: <003f01c5448a$d787bd20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: , "LTRU Working Group" References: Subject: Re: [Ltru] RE: Generic variant subtags in RFC 3066bis Date: Mon, 18 Apr 2005 19:52:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - I'm surprised that this message made it to the ltru@ietf.org list, given that it and its predecessors weren't sent to that address. Randy ----- Original Message ----- From: "Peter Constable" To: ; Sent: Monday, April 18, 2005 3:08 PM Subject: [Ltru] RE: Generic variant subtags in RFC 3066bis > From: ietf-languages-bounces@alvestrand.no [mailto:ietf-languages- > bounces@alvestrand.no] On Behalf Of John Cowan > When the RFC 3066bis registry is up and running, I intend to propose some > highly generic variant subtags which may be used with many languages. > Some examples that come to mind are -northern, -southern, -eastern, -western, > and -central for geographical dialects; -ancient and -middle for earlier > versions of languages (-old being too short); Note that ISO 639 does distinguish historic varieties at a low level of granularity. E.g., ang = Old English (ca. 450 - 1100) enm = Middle English (1100 - 1500) eng = (Modern) English (1500 - present) ISO 639-3 will continue using this approach; the draft code table has 34 "Old" entries and 14 "Middle" entries. The criterion for inclusion is that there candidate historic language must have a body of literature and must be treated as distinct from other historic stages by the scholarly community. > and -highreg, -midreg, and -lowreg > for sociolinguistic registers. Is this really a commonly-used basis for distinction between sociolinguistic registers? Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 19 03:10:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNmsL-0005xA-Np; Tue, 19 Apr 2005 03:10:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNmsH-0005wz-GU for ltru@megatron.ietf.org; Tue, 19 Apr 2005 03:10:22 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12835 for ; Tue, 19 Apr 2005 03:10:19 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050419070949.ZOIX5402.mta11.adelphia.net@DEWELL> for ; Tue, 19 Apr 2005 03:09:49 -0400 Message-ID: <00b301c544ae$bfd17260$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 19 Apr 2005 00:09:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA12835 Cc: Subject: [Ltru] Re: new version posted online X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: >> IMHO it's better to enumerate them. Do we have any convincing >> reasons to use "_" instead of "-" in field names ? Mail and >> news header field names use "-" (no rule, an observation). > [Addison Phillips] > > No reason. Actually, hyphen-minus would be more in keeping with the > spirit of 3066 I suppose. I would greatly prefer hyphen over underscore. > The names are all Unicode character names. Thankfully we don't have > any examples that use Indic zero digits :-). Or worse yet, Tamil Aytham. We could be held criminally liable for that one. >> | Latin-1 blocks as defined by Unicode [7] (that is, ISO/IEC >> | 10646 character numbers less than U+0100). >> >> Why this restriction ? What's wrong with say Zcaron, Yuml, or >> OElig ? You even have the Euro as example elsewhere. > [Addison Phillips] > > Description is separate from Comment. Comment allows anything. > Description is fixed to Latin-1. Various folks wanted that limitation > to reference ISO 8859-1, but as a Unicadet I fudged and used Unicode > blocks. And saved a reference. This doesn't have to be carved in stone. I thought it would make things easier for existing non-Unicode display mechanisms. The only effect this restriction has on the items in the draft registry is to remove the u-with-breve spelling of Hangul (Hang=C5=ADl) and a couple of directional single-quotes, also in script names. I've also replaced the acute accent U+00B4 (=C2=B4) with an ordinary apostrophe in the name Gwich'in, since I could find no evidence that the acute accent was used there as anything other than a fancy apostrophe, and plenty of examples that an ordinary apostrophe was just fine. I think the Euro example is a bit goofy since that particular character would never appear in the description of a language, script, region, etc., but it's harmless. >> | Comments >> >> The examples use "Comment" (singular). Later there's another >> "Comments". Quite a lot of examples, maybe you can delete some >> less interesting examples, e.g. either Africa or North America. I prefer "Comment" myself, but it doesn't make much difference. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 19 03:41:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNnMV-0001IM-V1; Tue, 19 Apr 2005 03:41:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNnMU-0001Hm-Dc for ltru@megatron.ietf.org; Tue, 19 Apr 2005 03:41:34 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14437 for ; Tue, 19 Apr 2005 03:41:31 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050419074102.CUFX2192.mta9.adelphia.net@DEWELL> for ; Tue, 19 Apr 2005 03:41:02 -0400 Message-ID: <00cd01c544b3$19cc95c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 19 Apr 2005 00:40:45 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] New registry with Suppress_Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Now that there's a draft that reflects the apparent consensus on Suppress_Script, I've posted a revised registry that reflects the draft. http://users.adelphia.net/~dewell/lstreg.txt For the initial Suppress_Script data, I used the "language_info.txt" file that Mark Davis mentioned a day or so ago. This file lists 125 languages that have only one associated script each. Note that 85 of these 125 listings, or 68 percent, are for Latin; the next most common script (Cyrillic) is listed only 6 times. The only other significant change is the addition of 10 new redundant records, matching the 10 new scripts registered under RFC 3066 last week. For the next version, I'd like to consider re-sorting the language and region entries. Currently the 2-letter language subtags are separate from, and sorted before, the 3-letter language subtags, while the 2-letter ISO 3166-based region subtags all appear before the 3-digit UN M.49-based subtags. Sorting these properly would cause the language subtags to be intermixed, and would place the numeric region subtags ahead of the alphabetic subtags. If anyone opposes this for the next registry, please speak up. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 19 10:19:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNtZM-0001qi-5e; Tue, 19 Apr 2005 10:19:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNtZK-0001qd-D9 for ltru@megatron.ietf.org; Tue, 19 Apr 2005 10:19:14 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14722 for ; Tue, 19 Apr 2005 10:19:11 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNtUQ-00016b-3H for ltru@lists.ietf.org; Tue, 19 Apr 2005 16:14:10 +0200 Received: from c-134-88-154.hh.dial.de.ignite.net ([62.134.88.154]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Apr 2005 16:14:10 +0200 Received: from nobody by c-134-88-154.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Apr 2005 16:14:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 19 Apr 2005 16:15:36 +0200 Organization: Lines: 28 Message-ID: <42651288.35D6@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B166CC2@irvmbxw01.quest.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: c-134-88-154.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] subtle ABNF (was: new version posted online) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: >> equivalent. > Something like that. Sigh, I give up, the equivalent subtle version is good enough. After I checked 2234bis 3.5 and 3.10 (Shame on me, I didn't know that ABNF concatenation comes before alternative - maybe you could use =/ instead of / in the subtle 'variant' ABNF ;-) If I got it right (2234bis 3.3) that would be: variant = ALPHA (4*7alphanum) variant =/ DIGIT (3*7alphanum) Or with 2234bis 3.5 groups instead of 3.3: variant = ( ALPHA 4*7alphanum ) / ( DIGIT 3*7alphanum ) JFTR the equivalent "less subtle" variant in this context: variant = 5*8alphanum / ( DIGIT 3alphanum ) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 19 11:13:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNuPf-0000zY-QO; Tue, 19 Apr 2005 11:13:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNuPd-0000zL-Fi for ltru@megatron.ietf.org; Tue, 19 Apr 2005 11:13:17 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18763 for ; Tue, 19 Apr 2005 11:13:14 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNuJZ-0003b6-Q1 for ltru@lists.ietf.org; Tue, 19 Apr 2005 17:07:02 +0200 Received: from c-134-88-154.hh.dial.de.ignite.net ([62.134.88.154]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Apr 2005 17:07:01 +0200 Received: from nobody by c-134-88-154.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Apr 2005 17:07:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 19 Apr 2005 17:07:57 +0200 Organization: Lines: 50 Message-ID: <42651ECD.68B9@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B166CC2@irvmbxw01.quest.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: c-134-88-154.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] hyphen-minus (was: new version posted online) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: >> Do we have any convincing reasons to use "_" instead of "-" >> in field names ? Mail and news header field names use "-" >> (no rule, an observation). > No reason. Actually, hyphen-minus would be more in keeping > with the spirit of 3066 I suppose. With Doug 3:0 for HYPHEN-MINUS (a.k.a. 'dash' in 2234bis) > The names are all Unicode character names. The x-refs in U40M030411.lst use lower case: | 2010 HYPHEN | x (hyphen-minus - 002D) | x (soft hyphen - 00AD) > Thankfully we don't have any examples that use Indic zero > digits :-). Checking, yes, thanks. One of the many advantages of Unicode, it's impossible to have a worse idea that still makes sense. [yuml but no Yuml] > Various folks wanted that limitation to reference ISO 8859-1, > but as a Unicadet I fudged and used Unicode blocks. The but-part is clear, I don't get the premise: If now Doug or later IANA are forced to filter "official" descriptions found in the source standards against Latin-1 it could be a problem. What if the only official description uses Latin-0 characters not covered by Latin-1 ? Yuml is on the letterbase list with characters required for French, Jefsey wil kill us if that's true and we exclude it without good reasons: http://www.eki.ee/letter/chardata.cgi?lang=fr+French&imgonly=on&script=latin > Limiting to "script = Latn" is messy True, why not simply copy whatever the official source says ? Let them do their own limiting. > Personally, I don't agree with having to have a limitation. > Why restrict ourselves unnecessarily? Add me. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 19 12:02:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNvBU-0008CU-SQ; Tue, 19 Apr 2005 12:02:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNvBT-0008CC-31 for ltru@megatron.ietf.org; Tue, 19 Apr 2005 12:02:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22301 for ; Tue, 19 Apr 2005 12:02:39 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNvMV-0003va-Vf for ltru@ietf.org; Tue, 19 Apr 2005 12:14:08 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 09:02:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] hyphen-minus (was: new version posted online) Date: Tue, 19 Apr 2005 09:02:31 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B166F9A@irvmbxw01.quest.com> Thread-Topic: [Ltru] hyphen-minus (was: new version posted online) Thread-Index: AcVE8nOO0wsiOvV0SQ6qQ5/NzR+DogABJH0g From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 19 Apr 2005 16:02:32.0737 (UTC) FILETIME=[320FD110:01C544F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org If no one objects, I'll remove the restriction to Latin-1 from = description. Variant registrations will be asked to provide a = Description using or transcribed into the Latin script. Perhaps: --- The 'Description' field must contain a description of the tag being = registered written or transcribed into the Latin script; it may also = include a description in a non-Latin script. Non-ASCII characters must = be escaped using the syntax described in Section 3.1. The 'Description' = field is used for identification purposes and should not be taken to = represent the actual native name of the language or variation or to be = in any particular language. Most descriptions are taken directly from = source standards such as ISO 639 or ISO 3166.=20 While the 'Description' field is not guaranteed to be stable and errata = corrections may be undertaken from time to time, attempts to provide = translations or transcriptions of entries in the registry itself will = probably be frowned upon by the community or rejected outright. --- Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: mardi 19 avril 2005 08:08 > To: ltru@ietf.org > Subject: [Ltru] hyphen-minus (was: new version posted online) >=20 > Addison Phillips wrote: >=20 > >> Do we have any convincing reasons to use "_" instead of "-" > >> in field names ? Mail and news header field names use "-" > >> (no rule, an observation). >=20 > > No reason. Actually, hyphen-minus would be more in keeping > > with the spirit of 3066 I suppose. >=20 > With Doug 3:0 for HYPHEN-MINUS (a.k.a. 'dash' in 2234bis) >=20 > > The names are all Unicode character names. >=20 > The x-refs in U40M030411.lst use lower case: >=20 > | 2010 HYPHEN > | x (hyphen-minus - 002D) > | x (soft hyphen - 00AD) >=20 > > Thankfully we don't have any examples that use Indic zero > > digits :-). >=20 > Checking, yes, thanks. One of the many advantages of Unicode, > it's impossible to have a worse idea that still makes sense. >=20 > [yuml but no Yuml] > > Various folks wanted that limitation to reference ISO 8859-1, > > but as a Unicadet I fudged and used Unicode blocks. >=20 > The but-part is clear, I don't get the premise: If now Doug or > later IANA are forced to filter "official" descriptions found > in the source standards against Latin-1 it could be a problem. >=20 > What if the only official description uses Latin-0 characters > not covered by Latin-1 ? Yuml is on the letterbase list with > characters required for French, Jefsey wil kill us if that's > true and we exclude it without good reasons: >=20 > = http://www.eki.ee/letter/chardata.cgi?lang=3Dfr+French&imgonly=3Don&scrip= t=3Dlat > in >=20 > > Limiting to "script =3D Latn" is messy >=20 > True, why not simply copy whatever the official source says ? > Let them do their own limiting. >=20 > > Personally, I don't agree with having to have a limitation. > > Why restrict ourselves unnecessarily? >=20 > Add me. Bye, Frank >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 19 14:20:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNxL5-0002jR-Nd; Tue, 19 Apr 2005 14:20:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNxL4-0002jH-LH for ltru@megatron.ietf.org; Tue, 19 Apr 2005 14:20:47 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04918 for ; Tue, 19 Apr 2005 14:20:43 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNxGn-0003tK-CJ for ltru@lists.ietf.org; Tue, 19 Apr 2005 20:16:21 +0200 Received: from 212.82.251.170 ([212.82.251.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Apr 2005 20:16:21 +0200 Received: from nobody by 212.82.251.170 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Apr 2005 20:16:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 19 Apr 2005 20:16:37 +0200 Organization: Lines: 75 Message-ID: <42654B05.2439@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B166CC2@irvmbxw01.quest.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.170 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] FWS vs. LWSP (was: new version posted online) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: [folding] >> the FWS in 2822 is better than the LWSP in 2234bis for this >> purpose. LWSP allows "empty" lines (trailing blanks), we >> don't need or want this in the registry. Better _copy_ FWS >> from RfC 2822, we also don't need or want obs-FWS: >> field-body = *( ASCCHAR / FWS ) >> FWS = [*WSP CRLF] 1*WSP ; Folding white space > I thought I referenced the right thing (2234bis) for the ABNF > itself. Using LWSP is a tad bit obscure. Blank lines in the > registry don't hurt anything. Especially if there aren't any. > And this ABNF is ultra-tight. That's true, but the reasons _why_ it's true are interesting, it's a feature of the "%%" in the record-jar format. | Example: one two three Some obvious ways to fold this example are: | Example: one | two three | Example: one | two | three Now I use _ for SP in the same examples: | Example:_one | _two__three | Example:_one | _two | __three So far all is fine, now I fold __three at the second SP: | Example:_one | _two_ | _three The trailing SP in the line _two_ won't survive simple editors and other tools not expecting trailig spaces, but that's no problem. Now I fold all SP wherever they are: | Example: | _one | _two | _ | _three Still okay, but after a simple editor or another tool removed the trailing space you'd get: | Example: | _one | _two | | _three In something like mail or news the line _three would now be the first line of the body. In a format where empty lines instead of %% terminate entries the entry would be broken. With LWSP the latter is possible, with FWS it's not. But as you said in reality we have %% and this is all irrelevant ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 19 16:20:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNzCX-0007oH-I2; Tue, 19 Apr 2005 16:20:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNzCW-0007o8-I4 for ltru@megatron.ietf.org; Tue, 19 Apr 2005 16:20:04 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23291 for ; Tue, 19 Apr 2005 16:19:59 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DNz7l-00054O-Tp for ltru@lists.ietf.org; Tue, 19 Apr 2005 22:15:09 +0200 Received: from 212.82.251.170 ([212.82.251.170]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Apr 2005 22:15:09 +0200 Received: from nobody by 212.82.251.170 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Apr 2005 22:15:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 19 Apr 2005 21:54:36 +0200 Organization: Lines: 37 Message-ID: <426561FC.3294@xyzzy.claranet.de> References: <00cd01c544b3$19cc95c0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="-" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.170 X-Mailer: Mozilla 3.0 (OS/2; U) Cc: Subject: [Ltru] Re: New registry with Suppress_Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --- Doug Ewell wrote: > http://users.adelphia.net/~dewell/lstreg.txt Thanks. How do you want to handle missing Suppress-Script entries ? I risk to propose Latn for fy, li, and oc, but discussing this here could be messy. A temporary list of languages known to have no or more than one script could help to fill the gaps. > 10 new scripts registered under RFC 3066 last week. Scripts registered under 3066 ? Oh, the zh-landrush, if and only if IANA publishes these tags, so far they didn't. IANA is the relevant source for this part of the registry. > I'd like to consider re-sorting the language and region > entries. Alphabetically by (sub)tags per type is fine. With types in the order language, script, region, etc. as you have it. Region numbers before or after codes: whatever you like, I'd use ASCII order. Mixing alpha-2 and alpha-3 language tags alphabetically: good idea. But please don't try to sort tags based on the Description. Bye, Frank --- Content-Laguage: fy Lever dod as slav --- Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ----- From ltru-bounces@lists.ietf.org Tue Apr 19 16:40:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNzWV-0004uY-PJ; Tue, 19 Apr 2005 16:40:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNzWT-0004rL-Ja for ltru@megatron.ietf.org; Tue, 19 Apr 2005 16:40:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24956 for ; Tue, 19 Apr 2005 16:40:38 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNzhX-0007QF-PG for ltru@ietf.org; Tue, 19 Apr 2005 16:52:09 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Apr 2005 13:40:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Re: New registry with Suppress_Script Date: Tue, 19 Apr 2005 13:40:21 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B1671E0@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: New registry with Suppress_Script Thread-Index: AcVFHT/txhFSBXM6TFyx5gOp1oub/gAAqCog From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 19 Apr 2005 20:40:22.0401 (UTC) FILETIME=[01F4AF10:01C54520] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Actually, I prefer to have the alpha2 and alpha3 codes listed = separately. It is nice to be able to view these as separate lists and = the alpha2 list isn't that long anyway. But that's a nit.=20 Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: mardi 19 avril 2005 12:55 > To: ltru@ietf.org > Subject: [Ltru] Re: New registry with Suppress_Script >=20 > Doug Ewell wrote: >=20 > > http://users.adelphia.net/~dewell/lstreg.txt >=20 > Thanks. How do you want to handle missing Suppress-Script > entries ? I risk to propose Latn for fy, li, and oc, but > discussing this here could be messy. A temporary list of > languages known to have no or more than one script could > help to fill the gaps. >=20 > > 10 new scripts registered under RFC 3066 last week. >=20 > Scripts registered under 3066 ? Oh, the zh-landrush, if > and only if IANA publishes these tags, so far they didn't. > IANA is the relevant source for this part of the registry. >=20 > > I'd like to consider re-sorting the language and region > > entries. >=20 > Alphabetically by (sub)tags per type is fine. With types > in the order language, script, region, etc. as you have it. >=20 > Region numbers before or after codes: whatever you like, > I'd use ASCII order. Mixing alpha-2 and alpha-3 language > tags alphabetically: good idea. >=20 > But please don't try to sort tags based on the Description. >=20 > Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 19 21:41:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO4Dx-0002Qm-UW; Tue, 19 Apr 2005 21:41:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO4Du-0002QA-GG for ltru@megatron.ietf.org; Tue, 19 Apr 2005 21:41:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15912 for ; Tue, 19 Apr 2005 21:41:48 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO4P1-0007zb-KP for ltru@ietf.org; Tue, 19 Apr 2005 21:53:20 -0400 Received: from lns-p19-2-idf-82-251-108-132.adsl.proxad.net ([82.251.108.132] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DO4Dr-0005D7-OO; Tue, 19 Apr 2005 18:41:48 -0700 Message-Id: <6.2.1.2.2.20050420020517.03d2c7f0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 20 Apr 2005 02:23:25 +0200 To: "Addison Phillips" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] hyphen-minus (was: new version posted online) In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B166F9A@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0B166F9A@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 18:02 19/04/2005, Addison Phillips said: >attempts to provide translations or transcriptions of entries in the >registry itself will probably be frowned upon by the community or rejected >outright. I do not see the need for this. It would certainly kill the remaining chance of possible consensus if some of my still undiscussed points were positively addressed. If maintained and accepted by the IESG it could only lead to an appeal, most probably supported by many authorities. In my opinion the purpose of BCP 047 is to give a common framework to the various language identification classes, schemes, formats and filters and to permit the provision of coherent translations and transcriptions of each registry entries to each lingual community. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Apr 20 16:12:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOLYc-0004Ym-HK; Wed, 20 Apr 2005 16:12:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOLYa-0004Yh-L0 for ltru@megatron.ietf.org; Wed, 20 Apr 2005 16:12:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14417 for ; Wed, 20 Apr 2005 16:12:18 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOLjs-0006v0-Ab for ltru@ietf.org; Wed, 20 Apr 2005 16:24:00 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 13:12:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] hyphen-minus (was: new version posted online) Date: Wed, 20 Apr 2005 13:12:09 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B1677BE@irvmbxw01.quest.com> Thread-Topic: [Ltru] hyphen-minus (was: new version posted online) Thread-Index: AcVFSh8F08t6TcerTZ6B2VLqWaDsnAAmJqLw From: "Addison Phillips" To: "JFC (Jefsey) Morfin" X-OriginalArrivalTime: 20 Apr 2005 20:12:10.0561 (UTC) FILETIME=[3BF42310:01C545E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org The need for the text I proposed is precisely to discourage using the = registry as a repository for localized names of the various subtags and = other registration activity that could be considered spamming. The = description field serves as a bit of human readable (informative) = documentation in a registry intended for machine processing.=20 It is not intended as the normative name for that subtag in any = language, not even English.=20 In fact, my proposed text is far less restrictive than the current RFC = 3066 or what I perceive to be the consensus on this list. It allows for = native names to appear in the description field (although transcribed = into numeric character references to Unicode if they are not ASCII). None of this impacts any person or entity's ability to: > to permit the provision of coherent translations and transcriptions of > each > registry entries to each lingual community. Anyone can do that. An additional, informative registry could be created = with that purpose in mind. *This* registry exists to enumerate the valid = subtag tokens to be used in language identifiers (tags). Your idea of what constitutes a 'consensus' is utterly obscure to me. I = will not attempt to explain (what I perceive to be) the IETF definition = of it again. If you feel that the document resulting from this work = contains insuperable objections, then you are welcome to appeal it as = described in RFC 2026 or its successor. I note once again that you have not suggested alternative text. Removing = this phrasing will result in a dangling sentence fragment. What do you = propose that the text should say? Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] > Sent: Tuesday, April 19, 2005 5:23 PM > To: Addison Phillips > Cc: ltru Working Group > Subject: RE: [Ltru] hyphen-minus (was: new version posted online) >=20 > On 18:02 19/04/2005, Addison Phillips said: > >attempts to provide translations or transcriptions of entries in the > >registry itself will probably be frowned upon by the community or > rejected > >outright. >=20 > I do not see the need for this. It would certainly kill the remaining > chance of possible consensus if some of my still undiscussed points = were > positively addressed. If maintained and accepted by the IESG it could = only > lead to an appeal, most probably supported by many authorities. >=20 > In my opinion the purpose of BCP 047 is to give a common framework to = the > various language identification classes, schemes, formats and filters = and > to permit the provision of coherent translations and transcriptions of > each > registry entries to each lingual community. >=20 > jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Apr 20 19:27:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOObo-0007hI-T8; Wed, 20 Apr 2005 19:27:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOObn-0007eV-5U for ltru@megatron.ietf.org; Wed, 20 Apr 2005 19:27:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07214 for ; Wed, 20 Apr 2005 19:27:46 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOOn3-0004gL-C6 for ltru@ietf.org; Wed, 20 Apr 2005 19:39:30 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 16:27:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 20 Apr 2005 16:27:31 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B1678B6@irvmbxw01.quest.com> Thread-Topic: New version posted: ready for publication?? Thread-Index: AcVGAIVUbTdTxfrORgmfToM+AIFViQ== From: "Addison Phillips" To: "ltru Working Group" X-OriginalArrivalTime: 20 Apr 2005 23:27:32.0120 (UTC) FILETIME=[868C1980:01C54600] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] New version posted: ready for publication?? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1257744303==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1257744303== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 QWxsLA0KDQpJIGhhdmUganVzdCBwb3N0ZWQgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIGRyYWZ0LTAx IGVkaXRvcidzIGNvcHkuIFRoaXMgaW5jbHVkZXMgYWxsIG9mIHRoZSBlZGl0cyBJJ20gY3VycmVu dGx5IGF3YXJlLCBpbmNsdWRpbmcgdGhlIGxlc3Mgc3VidGxlIHZhcmlhbnQgQUJORi4gSXQgaGFz IGJlZW4gdXBkYXRlZCB1c2luZyB0aGUgbmV3IHhtbDJyZmMgYW5kIHJlZmVyZW5jZXMgdGhlIGxh dGVzdCBhbmQgZ3JlYXRlc3QgSUVURiBwcm9jZXNzIFJGQ3MuDQoNCkknbSBwcmVwYXJlZCB0byBz dWJtaXQgdGhpcywgYmFycmluZyBlcnJvcnMgaW4gdGhlIGRvY3VtZW50Lg0KDQpRdWVzdGlvbjog d2hhdCBpc3N1ZXMgcmVtYWluIGJlZm9yZSB0aGlzIGRvY3VtZW50IGNhbiBiZSBjb25zaWRlcmVk IGluIGl0cyBmaW5hbCBmb3JtPw0KDQpCZXN0IFJlZ2FyZHMsDQoNCkFkZGlzb24NCg0KQWRkaXNv biBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpo dHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENv cmUgV29ya2luZyBHcm91cA0KaHR0cDovL3d3dy53My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRl cm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJl LiANCg0KDQo= --===============1257744303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1257744303==-- From ltru-bounces@lists.ietf.org Thu Apr 21 12:52:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOeuZ-0004pO-RR; Thu, 21 Apr 2005 12:52:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOeuW-0004om-Ve for ltru@megatron.ietf.org; Thu, 21 Apr 2005 12:52:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16579 for ; Thu, 21 Apr 2005 12:52:14 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOf5z-0004Ya-3G for ltru@ietf.org; Thu, 21 Apr 2005 13:04:07 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 09:52:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] New version posted: ready for publication?? Date: Thu, 21 Apr 2005 09:52:01 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B167BF7@irvmbxw01.quest.com> Thread-Topic: [Ltru] New version posted: ready for publication?? Thread-Index: AcVGjXejK0JYVCMbR9qRuVZMja5z1wAAWrEg From: "Addison Phillips" To: "Mark Davis" , "Addison Phillips" , "ltru Working Group" X-OriginalArrivalTime: 21 Apr 2005 16:52:02.0285 (UTC) FILETIME=[70E061D0:01C54692] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0787296932==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0787296932== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhhdCdzIHRoZSBkb2N1bWVudCEgU29ycnkgSSBkaWRuJ3Qgc2VuZCBhIGxpbmsgcHJldmlvdXNs eS4gQXQgdGhhdCBwb2ludCBJIHdhcyBydXNoaW5nIHRvIGdldCB0byB0aGUgYWlycG9ydCBvbiB0 aW1lLg0KDQpPdXRsb29rIGF0ZSB0aGUgZXh0cmEgY2FycmlhZ2UgcmV0dXJucyBpbiB5b3VyIG1l c3NhZ2UuIENoZWNrIHRvIHNlZSBpZiBJIGNhcHR1cmVkIHlvdXIgY29tbWVudHMgY29ycmVjdGx5 Lg0KDQpOb3RlcyBmb2xsb3cuDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24g QXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlv biBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVh dHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IE1hcmsgRGF2aXMgW21haWx0bzptYXJrLmRhdmlzLm1hcmsuZGF2aXNAanRj c3YuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMjEsIDIwMDUgOToxNiBBTQ0KPiBUbzog QWRkaXNvbiBQaGlsbGlwczsgbHRydSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJlOiBbTHRy dV0gTmV3IHZlcnNpb24gcG9zdGVkOiByZWFkeSBmb3IgcHVibGljYXRpb24/Pw0KPiANCj4gSSBk aWRuJ3QgZ2V0IGFuIGF0dGFjaG1lbnQgYW5kIHRoZXJlIHdhc24ndCBhIGxpbmsgSSBhc3N1bWUg eW91IG1lYW4gdGhlDQo+IGRvY3VtZW50IGF0DQo+IA0KPiBodHRwOi8vaW50ZXItbG9jYWxlLmNv bS9JRC9kcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMDEuaHRtbA0KPiANCj4gSXQgbG9va3MgZ29v ZC4gSSBvbmx5IGZvdW5kIHNvbWUgbWlub3Igc3R1ZmYuDQo+IA0KPiANCj4gMi4xDQo+IFtJbiB0 aGUgQUJORiwgdmFyaWFudCBoYXMgZXh0cmEgc3BhY2VzIGluIGZyb250Ll0NCltBZGRpc29uIFBo aWxsaXBzXSANCg0KU3BhY2UgcmVtb3ZlZC4NCj4gDQo+IDIuMS4xDQo+IFthZGRdIEFsbCBzdWJ0 YWdzIGFyZSBmcm9tIDEgdG8gOCBjaGFyYWN0ZXJzIGluIGxlbmd0aC4NCltBZGRpc29uIFBoaWxs aXBzXSANCg0KTm90IHN1cmUgd2hlcmUgeW91IHdhbnQgbWUgdG8gcHV0IHRoaXMuIDIuMS4xIGlz IHRoZSBsZW5ndGggY29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhbmQgSSBkb24ndCBzZWUgYSBwYXJ0 aWN1bGFyIHNwb3QgdG8gc3RpY2sgdGhpcyB0ZXh0Lg0KPiANCj4gDQo+IDIuMi41DQo+IFtyZW1v dmVdIFRoZSBtYXhpbXVtIGxlbmd0aCBvZiBhIHZhcmlhbnQgc3VidGFnIGlzIGVpZ2h0IGNoYXJh Y3RlcnMgbG9uZy4NCltBZGRpc29uIFBoaWxsaXBzXSANCg0KRG9uZS4NCj4gDQo+IA0KPiAzLjEN Cj4gZmllbGQgPSBmaWVsZC1uYW1lICpTUCAiOiIgZmllbGQtYm9keSBDUkxGPT5maWVsZCA9IGZp ZWxkLW5hbWUgKlNQICI6IiAqU1ANCj4gZmllbGQtYm9keSBDUkxGW0xlYWRpbmcgc3BhY2VzIHNo b3VsZG4ndCBiZSBjb25zaWRlcmVkIHBhcnQgb2YgdGhlDQo+IGZpZWxkLWJvZHksIGZvciBjb25z aXN0ZW5jeS5dIA0KW0FkZGlzb24gUGhpbGxpcHNdIA0KDQpHb29kIGNhdGNoLiBEb25lLg0KDQpT dWJzZXF1ZW50IHJlY29yZHMgcmVwcmVzZW50IHN1YnRhZ3MgaW4gdGhlDQo+IHJlZ2lzdHJ5LiBF YWNoIHJlY29yZCBNVVNUIGNvbnRhaW4gdGhlIGZvbGxvd2luZyBmaWVsZHM6ID0+IFN1YnNlcXVl bnQNCj4gcmVjb3JkcyByZXByZXNlbnQgc3VidGFncyBpbiB0aGUgcmVnaXN0cnkuIEVhY2ggb2Yg dGhlIGZpZWxkcyBpbiBlYWNoDQo+IHJlY29yZA0KPiBNVVNUIG9jY3VyIG5vIG1vcmUgdGhhbiBv bmNlLCB1bmxlc3Mgb3RoZXJ3aXNlIG5vdGVkIGJlbG93LiBFYWNoIHJlY29yZA0KPiBNVVNUDQo+ IGNvbnRhaW4gdGhlIGZvbGxvd2luZyBmaWVsZHM6DQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCkRv bmUuDQoNCj4gNC4xIFtzb21lIGV4dHJhIHlvdSdzXQ0KPiAgU29tZSBwcm90b2NvbHMgbWF5IGZv cmNlIHlvdSB0byBnaXZlIGEgdmFsdWUgZm9yIHRoZSBsYW5ndWFnZSB0YWcgYW5kIHRoZQ0KPiAn VU5EJyBzdWJ0YWcgbWF5IGJlIHVzZWZ1bCB3aGVuIG1hdGNoaW5nIGxhbmd1YWdlIHRhZ3MgaW4g Y2VydGFpbg0KPiBzaXR1YXRpb25zLg0KPiA9Pg0KPiAgVGhlICdVTkQnIHN1YnRhZyBtYXkgYmUg bmVjZXNzYXJ5IHdoZW4gYSBwcm90b2NvbCByZXF1aXJlcyBhIHZhbHVlIGZvcg0KPiB0aGUNCj4g bGFuZ3VhZ2UgdGFnLCBvciB3aGVuIG1hdGNoaW5nIGxhbmd1YWdlIHRhZ3MgaW4gY2VydGFpbiBz aXR1YXRpb25zLg0KW0FkZGlzb24gUGhpbGxpcHNdIA0KDQpJIGRpZCBhIHNsaWdodGx5IGRpZmZl cmVudCByZXdyaXRlOg0KDQpTb21lIHByb3RvY29scyBtYXkgcmVxdWlyZSBhIHZhbHVlIGZvciB0 aGUgbGFuZ3VhZ2UgdGFnIGFuZCB0aGUgJ1VORCcgc3VidGFnIG1heSBiZSB1c2VmdWwgd2hlbiBt YXRjaGluZyBsYW5ndWFnZSB0YWdzIGluIGNlcnRhaW4gc2l0dWF0aW9ucy4NCj4gDQo+ICBUaGUg J01VTCcgKE11bHRpcGxlKSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBTSE9VTEQgTk9UIGJlIHVz ZWQgaWYgdGhlDQo+IHByb3RvY29sIGFsbG93cyB5b3UgdG8gdXNlIG11bHRpcGxlIGxhbmd1YWdl cywgYXMgaXMgdGhlIGNhc2UgZm9yIHRoZQ0KPiBDb250ZW50LUxhbmd1YWdlIGhlYWRlciBpbiBI VFRQLg0KPiA9Pg0KPiAgVGhlICdNVUwnIChNdWx0aXBsZSkgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0 YWcgU0hPVUxEIE5PVCBiZSB1c2VkIHdoZW5ldmVyDQo+IGENCj4gcHJvdG9jb2wgYWxsb3dzIHRo ZSB1c2Ugb2YgbXVsdGlwbGUgbGFuZ3VhZ2VzLCBhcyBpcyB0aGUgY2FzZSBmb3IgdGhlDQo+IENv bnRlbnQtTGFuZ3VhZ2UgaGVhZGVyIGluIEhUVFAuDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCkRv bmUuIFNob3VsZCB0aGVyZSBiZSBhIGdlbmVyYWwgd2FybmluZyBhZ2FpbnN0IHVzaW5nICdNVUwn PyBTb21ldGhpbmcgbGlrZToNCg0KLS0NClRoZSAnTVVMJyBzdWJ0YWcgY29udmV5cyBsaXR0bGUg dXNlZnVsIGluZm9ybWF0aW9uOiBjb250ZW50IGluIG11bHRpcGxlIGxhbmd1YWdlcyBzaG91bGQg aW5kaXZpZHVhbGx5IHRhZyB0aGUgbGFuZ3VhZ2VzIHdoZXJlIHRoZXkgYXBwZWFyIG9yIG90aGVy d2lzZSBpbmRpY2F0ZSB0aGUgYWN0dWFsIGxhbmd1YWdlIGluIHByZWZlcmVuY2UgdG8gdGhlICdN VUwnIHN1YnRhZy4NCi0tDQo+IA0KPiA2Lg0KPiAgVGhpcyBpcyBhIHNwZWNpYWwgY2FzZSBvZiB0 aGUgZ2VuZXJhbCBwcm9ibGVtIHRoYXQgYW55dGhpbmcgeW91IHNlbmQgaXMNCj4gdmlzaWJsZSB0 byB0aGUgcmVjZWl2aW5nIHBhcnR5LiBJdCBpcyB1c2VmdWwgdG8gYmUgYXdhcmUgdGhhdCBzdWNo DQo+IGNvbmNlcm5zDQo+IGNhbiBleGlzdCBpbiBzb21lIGNhc2VzLg0KPiA9Pg0KPiAgVGhpcyBp cyBhIHNwZWNpYWwgY2FzZSBvZiB0aGUgZ2VuZXJhbCBwcm9ibGVtIHRoYXQgYW55dGhpbmcgc2Vu dCBpcw0KPiB2aXNpYmxlDQo+IHRvIHRoZSByZWNlaXZpbmcgcGFydHkuIEl0IGlzIHVzZWZ1bCB0 byBiZSBhd2FyZSB0aGF0IHN1Y2ggY29uY2VybnMgY2FuDQo+IGV4aXN0IGluIHNvbWUgY2FzZXMu DQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCkRvbmUuIFdpbGwgcG9zdCBzaG9ydGx5Lg0KPiANCj4g TWFyaw0KPiANCj4g4oCOTWFyaw0KPiANCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0K PiBGcm9tOiAiQWRkaXNvbiBQaGlsbGlwcyIgPGFkZGlzb24ucGhpbGxpcHNAcXVlc3QuY29tPg0K PiBUbzogImx0cnUgV29ya2luZyBHcm91cCIgPGx0cnVAaWV0Zi5vcmc+DQo+IFNlbnQ6IFdlZG5l c2RheSwgQXByaWwgMjAsIDIwMDUgMTY6MjcNCj4gU3ViamVjdDogW0x0cnVdIE5ldyB2ZXJzaW9u IHBvc3RlZDogcmVhZHkgZm9yIHB1YmxpY2F0aW9uPz8NCj4gDQo+IA0KPiA+IEFsbCwNCj4gPg0K PiA+IEkgaGF2ZSBqdXN0IHBvc3RlZCBhbiB1cGRhdGVkIHZlcnNpb24gb2YgZHJhZnQtMDEgZWRp dG9yJ3MgY29weS4gVGhpcw0KPiBpbmNsdWRlcyBhbGwgb2YgdGhlIGVkaXRzIEknbSBjdXJyZW50 bHkgYXdhcmUsIGluY2x1ZGluZyB0aGUgbGVzcyBzdWJ0bGUNCj4gdmFyaWFudCBBQk5GLiBJdCBo YXMgYmVlbiB1cGRhdGVkIHVzaW5nIHRoZSBuZXcgeG1sMnJmYyBhbmQgcmVmZXJlbmNlcyB0aGUN Cj4gbGF0ZXN0IGFuZCBncmVhdGVzdCBJRVRGIHByb2Nlc3MgUkZDcy4NCj4gPg0KPiA+IEknbSBw cmVwYXJlZCB0byBzdWJtaXQgdGhpcywgYmFycmluZyBlcnJvcnMgaW4gdGhlIGRvY3VtZW50Lg0K PiA+DQo+ID4gUXVlc3Rpb246IHdoYXQgaXNzdWVzIHJlbWFpbiBiZWZvcmUgdGhpcyBkb2N1bWVu dCBjYW4gYmUgY29uc2lkZXJlZCBpbg0KPiBpdHMNCj4gZmluYWwgZm9ybT8NCj4gPg0KPiA+IEJl c3QgUmVnYXJkcywNCj4gPg0KPiA+IEFkZGlzb24NCj4gPg0KPiA+IEFkZGlzb24gUC4gUGhpbGxp cHMNCj4gPiBHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCj4gPiBodHRw Oi8vd3d3LnF1ZXN0LmNvbQ0KPiA+DQo+ID4gQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlv biBDb3JlIFdvcmtpbmcgR3JvdXANCj4gPiBodHRwOi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFs DQo+ID4NCj4gPiBJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KPiA+IEl0 IGlzIGFuIGFyY2hpdGVjdHVyZS4NCj4gPg0KPiA+DQo+ID4NCj4gDQo+IA0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiAtLQ0KPiAtLS0tDQo+IA0KPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEx0cnUgbWFpbGluZyBsaXN0DQo+ID4gTHRy dUBsaXN0cy5pZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2x0cnUNCj4gPg0KPiANCg0KDQo= --===============0787296932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0787296932==-- From ltru-bounces@lists.ietf.org Thu Apr 21 14:00:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOfyF-0004oy-LV; Thu, 21 Apr 2005 14:00:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOfyD-0004nt-Ig for ltru@megatron.ietf.org; Thu, 21 Apr 2005 14:00:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22449 for ; Thu, 21 Apr 2005 14:00:06 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOg9d-0006P4-HS for ltru@ietf.org; Thu, 21 Apr 2005 14:11:58 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 10:59:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] New version posted: ready for publication?? Date: Thu, 21 Apr 2005 10:59:55 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B20967F@irvmbxw01.quest.com> Thread-Topic: [Ltru] New version posted: ready for publication?? Thread-Index: AcVGlSDia+6OJaiaSqOWJ9g2K+8d+gABPuKw From: "Addison Phillips" To: "ltru Working Group" X-OriginalArrivalTime: 21 Apr 2005 17:59:56.0233 (UTC) FILETIME=[ED238390:01C5469B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0597923275==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0597923275== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 U2VlIGJlbG93LiBFeGNpc2VkIGV4Y2VzcyB0ZXh0Lg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4g UGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIs IFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRp b25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoN Cj4gDQo+ID4gPg0KPiA+ID4gMi4xLjENCj4gPiA+IFthZGRdIEFsbCBzdWJ0YWdzIGFyZSBmcm9t IDEgdG8gOCBjaGFyYWN0ZXJzIGluIGxlbmd0aC4NCj4gPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4g Pg0KPiA+IE5vdCBzdXJlIHdoZXJlIHlvdSB3YW50IG1lIHRvIHB1dCB0aGlzLiAyLjEuMSBpcyB0 aGUgbGVuZ3RoDQo+IGNvbnNpZGVyYXRpb25zDQo+IHNlY3Rpb24gYW5kIEkgZG9uJ3Qgc2VlIGEg cGFydGljdWxhciBzcG90IHRvIHN0aWNrIHRoaXMgdGV4dC4NCj4gDQo+IFdlIGNhbiBwdXQgdGhp cyBiZWxvdyB0aGUgQUJORiBpdHNlbGYgaW4gYSBub3RlLiBJbiB0aGUgTGVuZ3RoDQo+IGNvbnNp ZGVyYXRpb25zLCBwZXJoYXBzIHRoZSBmb2xsb3dpbmcNCj4gIiBUaGlzIGxpbWl0cyBtb3N0IHRh Z3MgdG8gYSBzZXF1ZW5jZSBvZiBmb3VyIHN1YnRhZ3MgKGV4Y2x1ZGluZyBhbnkNCj4gZXh0ZW5z aW9ucyBvciBwcml2YXRlIHVzZSBzZXF1ZW5jZXMpLiAiDQo+ID0+DQo+ICBJbiBwcmFjdGljZSwg dGhpcyBsaW1pdHMgbW9zdCB0YWdzIHRvIGEgc2VxdWVuY2Ugb2YgZm91ciBzdWJ0YWdzIC0tIGFu ZA0KPiB0aHVzIGEgbGVuZ3RoIG9mIDM1LCBiZWNhdXNlIHN1YnRhZ3MgYXJlIGxpbWl0ZWQgdG8g YSBsZW5ndGggb2YgOCBlYWNoDQo+IChleGNsdWRpbmcgYW55IGV4dGVuc2lvbnMgb3IgcHJpdmF0 ZSB1c2Ugc2VxdWVuY2VzKS4NCltBZGRpc29uIFBoaWxsaXBzXSANCg0KVGhlcmUgd2VyZSBhIGNv dXBsZSBvZiBwcm9ibGVtcyB3aXRoIHRoYXQgdGV4dCAoaXQgc2VlbWVkIHRvIHN1Z2dlc3QgdGhh dCBleHRlbnNpb25zIGFuZCBwcml2YXRlIHVzZSB3ZXJlIG5vdCBsaW1pdGVkIHRvIDggY2hhcmFj dGVyIHN1YnRhZ3MpLCBzbyBJIHB1dDoNCg0KPHQ+SW4gcGFydGljdWxhciwgIHZhcmlhbnQgc3Vi dGFncyBTSE9VTEQgYmUgdXNlZCBvbmx5IHdpdGggdGhlaXIgcmVjb21tZW5kZWQgcHJlZml4LiAg SW4gcHJhY3RpY2UsIHRoaXMgbGltaXRzIG1vc3QgdGFncyB0byBhIHNlcXVlbmNlIG9mIGZvdXIg c3VidGFncywgYW5kDQp0aHVzIGEgbGVuZ3RoIG9mIDM1IChleGNsdWRpbmcgYW55IGV4dGVuc2lv bnMgb3IgcHJpdmF0ZSB1c2Ugc2VxdWVuY2VzKSwgYmVjYXVzZSBzdWJ0YWdzIGFyZSBsaW1pdGVk IHRvIGEgbGVuZ3RoIG9mIGVpZ2h0IGNoYXJhY3RlcnMuIFNlZSA8eHJlZiB0YXJnZXQ9ImNob2lj ZSI+PC94cmVmPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBzZWxlY3RpbmcgdGhlIG1vc3QgYXBw cm9wcmlhdGUgTGFuZ3VhZ2UgVGFnLjwvdD4NCj4gDQo+ID4NCj4gPiA+IDQuMSBbc29tZSBleHRy YSB5b3Unc10NCj4gPiA+ICBTb21lIHByb3RvY29scyBtYXkgZm9yY2UgeW91IHRvIGdpdmUgYSB2 YWx1ZSBmb3IgdGhlIGxhbmd1YWdlIHRhZyBhbmQNCj4gdGhlDQo+ID4gPiAnVU5EJyBzdWJ0YWcg bWF5IGJlIHVzZWZ1bCB3aGVuIG1hdGNoaW5nIGxhbmd1YWdlIHRhZ3MgaW4gY2VydGFpbg0KPiA+ ID4gc2l0dWF0aW9ucy4NCj4gPiA+ID0+DQo+ID4gPiAgVGhlICdVTkQnIHN1YnRhZyBtYXkgYmUg bmVjZXNzYXJ5IHdoZW4gYSBwcm90b2NvbCByZXF1aXJlcyBhIHZhbHVlDQo+IGZvcg0KPiA+ID4g dGhlDQo+ID4gPiBsYW5ndWFnZSB0YWcsIG9yIHdoZW4gbWF0Y2hpbmcgbGFuZ3VhZ2UgdGFncyBp biBjZXJ0YWluIHNpdHVhdGlvbnMuDQo+ID4gW0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPiBJ IGRpZCBhIHNsaWdodGx5IGRpZmZlcmVudCByZXdyaXRlOg0KPiA+DQo+ID4gU29tZSBwcm90b2Nv bHMgbWF5IHJlcXVpcmUgYSB2YWx1ZSBmb3IgdGhlIGxhbmd1YWdlIHRhZyBhbmQgdGhlICdVTkQn DQo+IHN1YnRhZyBtYXkgYmUgdXNlZnVsIHdoZW4gbWF0Y2hpbmcgbGFuZ3VhZ2UgdGFncyBpbiBj ZXJ0YWluIHNpdHVhdGlvbnMuDQo+IA0KPiBJIGRpZCBhIGJpdCBtb3JlIHNodWZmbGluZyBhcm91 bmQsIGJlY2F1c2UgdGhlIHNlbnRlbmNlcyB3YXMgdmVyeSBjbHVtc3kuDQo+IFRoZSB0d28gY2xh dXNlcyBhcmUgcmVhbGx5IGRpc2Nvbm5lY3RlZCwgc2VwYXJhdGUgcmVhc29ucyBmb3Igd2h5IHNv bWVvbmUNCj4gbWlnaHQgd2FudCB0byB1c2UgVU5ELCBidXQgdGhlICJhbmQiIG1ha2VzIHRoZW0g c291bmQgbGlrZSB0aGV5IGFyZQ0KPiBzdXBwb3NlZA0KPiB0byBiZSBjb25uZWN0ZWQuIFNvIEkg cHJlZmVyIG15IHJld3JpdGUuDQpbQWRkaXNvbiBQaGlsbGlwc10gDQoNCkkgaGVhciB5b3UuIEkg Y2hhbmdlZCBpdCB0bzoNCg0KPHQ+VGhlICdVTkQnIChVbmRldGVybWluZWQpIHByaW1hcnkgbGFu Z3VhZ2Ugc3VidGFnIFNIT1VMRCBOT1QgYmUgdXNlZCB0byBsYWJlbCBjb250ZW50LCBldmVuIGlm IHRoZSBsYW5ndWFnZSBpcyB1bmtub3duLiBPbWl0dGluZyB0aGUgdGFnIGlzIHByZWZlcnJlZC4g U29tZSBwcm90b2NvbHMgbWF5IHJlcXVpcmUgYSB2YWx1ZSBmb3IgdGhlIGxhbmd1YWdlIHRhZy4g VGhlICdVTkQnIHN1YnRhZyBtYXkgYWxzbyBiZSB1c2VmdWwgd2hlbiBtYXRjaGluZyBsYW5ndWFn ZSB0YWdzIGluIGNlcnRhaW4gc2l0dWF0aW9ucy48L3Q+DQo+IA0KPiA+ID4NCj4gDQo+ID4NCj4g PiAtLQ0KPiA+IFRoZSAnTVVMJyBzdWJ0YWcgY29udmV5cyBsaXR0bGUgdXNlZnVsIGluZm9ybWF0 aW9uOiBjb250ZW50IGluIG11bHRpcGxlDQo+IGxhbmd1YWdlcyBzaG91bGQgaW5kaXZpZHVhbGx5 IHRhZyB0aGUgbGFuZ3VhZ2VzIHdoZXJlIHRoZXkgYXBwZWFyIG9yDQo+IG90aGVyd2lzZSBpbmRp Y2F0ZSB0aGUgYWN0dWFsIGxhbmd1YWdlIGluIHByZWZlcmVuY2UgdG8gdGhlICdNVUwnIHN1YnRh Zy4NCj4gU1VSRQ0KPiANCj4gPiAtLQ0KW0FkZGlzb24gUGhpbGxpcHNdIA0KDQpJbnNlcnRlZC4N Cj4gPiA+DQoNCg== --===============0597923275== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0597923275==-- From ltru-bounces@lists.ietf.org Thu Apr 21 14:13:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOg9M-00061E-8l; Thu, 21 Apr 2005 14:11:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOg9L-000619-4f for ltru@megatron.ietf.org; Thu, 21 Apr 2005 14:11:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23314 for ; Thu, 21 Apr 2005 14:11:38 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOgKn-0006fI-Lz for ltru@ietf.org; Thu, 21 Apr 2005 14:23:30 -0400 Received: from uknsprd1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 21 Apr 2005 18:11:19 +0000 Received: from dtcsmsxb01.emea.ime.reuters.com ([10.5.150.13]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IFB007596IUV3@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 21 Apr 2005 19:11:18 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by dtcsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (5.0.2195.6713); Thu, 21 Apr 2005 19:11:17 +0100 Date: Thu, 21 Apr 2005 19:10:18 +0100 From: Misha Wolf Subject: RE: [Ltru] New version posted: ready for publication?? To: ltru Working Group Message-id: <1987416CA83AC7499AC772F92E2DBF7803956C6C@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] New version posted: ready for publication?? Thread-Index: AcVGlSDia+6OJaiaSqOWJ9g2K+8d+gABPuKwAACZ0BA= content-class: urn:content-classes:message X-OriginalArrivalTime: 21 Apr 2005 18:11:17.0256 (UTC) FILETIME=[830F6080:01C5469D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > The 'UND' (Undetermined) primary language subtag SHOULD NOT be used to > label content, even if the language is unknown. Omitting the tag is=20 > preferred. Some protocols may require a value for the language tag.=20 > The 'UND' subtag may also be useful when matching language tags in=20 > certain situations. This makes me feel as if a bunch of sentences ended up accidentally=20 in the same para. How about: Omitting the tag is preferred. Some protocols, however, may=20 require a value for the language tag.=20 I also don't like "require a value for the language tag". How about=20 "require a language tag"? Or "require a non-empty language tag"? Misha ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 14:47:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOghZ-0001cY-Ao; Thu, 21 Apr 2005 14:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOghX-0001cQ-RB for ltru@megatron.ietf.org; Thu, 21 Apr 2005 14:46:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25803 for ; Thu, 21 Apr 2005 14:46:58 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOgt0-0007Qt-0V for ltru@ietf.org; Thu, 21 Apr 2005 14:58:51 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 11:46:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] New version posted: ready for publication?? Date: Thu, 21 Apr 2005 11:46:47 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B2096E4@irvmbxw01.quest.com> Thread-Topic: [Ltru] New version posted: ready for publication?? Thread-Index: AcVGlSDia+6OJaiaSqOWJ9g2K+8d+gABPuKwAACZ0BAAAXgp4A== From: "Addison Phillips" To: "Misha Wolf" , "ltru Working Group" X-OriginalArrivalTime: 21 Apr 2005 18:46:48.0521 (UTC) FILETIME=[79649B90:01C546A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Yes, I agree. How about: -- The 'UND' (Undetermined) primary language subtag SHOULD NOT be used = to label content, even if the language is unknown. Omitting the tag is = preferred. The 'UND' tag may be useful for protocols that require a = language tag to be provided. The 'UND' subtag may also be useful when = matching language tags in certain situations. -- Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Misha Wolf > Sent: Thursday, April 21, 2005 11:10 AM > To: ltru Working Group > Subject: RE: [Ltru] New version posted: ready for publication?? >=20 > Addison Phillips wrote: >=20 > > The 'UND' (Undetermined) primary language subtag SHOULD NOT be used = to >=20 > > label content, even if the language is unknown. Omitting the tag is > > preferred. Some protocols may require a value for the language tag. > > The 'UND' subtag may also be useful when matching language tags in > > certain situations. >=20 > This makes me feel as if a bunch of sentences ended up accidentally > in the same para. How about: >=20 > Omitting the tag is preferred. Some protocols, however, may > require a value for the language tag. >=20 > I also don't like "require a value for the language tag". How about > "require a language tag"? Or "require a non-empty language tag"? >=20 > Misha >=20 >=20 >=20 > ----------------------------------------------------------------- > Visit our Internet site at http://www.reuters.com >=20 > To find out more about Reuters Products and Services visit > http://www.reuters.com/productinfo >=20 > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be > the views of Reuters Ltd. >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 14:48:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgjM-0001mf-RZ; Thu, 21 Apr 2005 14:48:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgjK-0001ma-VD for ltru@megatron.ietf.org; Thu, 21 Apr 2005 14:48:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25929 for ; Thu, 21 Apr 2005 14:48:49 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOgun-0007TN-OT for ltru@ietf.org; Thu, 21 Apr 2005 15:00:43 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 11:48:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] New version posted: ready for publication?? Date: Thu, 21 Apr 2005 11:48:39 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B2096E8@irvmbxw01.quest.com> Thread-Topic: [Ltru] New version posted: ready for publication?? Thread-Index: AcVGmXC4uQslP3JNS/GNfH3n/QXxzwACUEpg From: "Addison Phillips" To: "ltru Working Group" X-OriginalArrivalTime: 21 Apr 2005 18:48:40.0459 (UTC) FILETIME=[BC1CFDB0:01C546A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1931208951==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1931208951== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 RG9uZS4NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1 ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2lu ZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMg YW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBNYXJrIERhdmlzIFttYWlsdG86bWFyay5kYXZpcy5tYXJrLmRhdmlzQGp0Y3N2LmNvbV0NCj4g U2VudDogVGh1cnNkYXksIEFwcmlsIDIxLCAyMDA1IDEwOjQyIEFNDQo+IFRvOiBBZGRpc29uIFBo aWxsaXBzOyBNYXJrIERhdmlzOyBBZGRpc29uIFBoaWxsaXBzOyBsdHJ1IFdvcmtpbmcgR3JvdXAN Cj4gU3ViamVjdDogUmU6IFtMdHJ1XSBOZXcgdmVyc2lvbiBwb3N0ZWQ6IHJlYWR5IGZvciBwdWJs aWNhdGlvbj8/DQo+IA0KPiBPaCwgYWxtb3N0IGZvcmdvdC4NCj4gDQo+IFVORCwgTVVMIGFuZCBG UiBzaG91bGQgdXNlIHJlY29tbWVuZGVkIFtJU08gNjM5XSBjYXNpbmcgKGxvd2VyY2FzZSkgaW4g dGhlDQo+IGZvbGxvd2luZzoNCj4gDQo+ID4gVGhlICdVTkQnIChVbmRldGVybWluZWQpIHByaW1h cnkgbGFuZ3VhZ2Ugc3VidGFnIFNIT1VMRCBOT1QgYmUgdXNlZCB0bw0KPiBsYWJlbCBjb250ZW50 LCBldmVuIGlmIHRoZSBsYW5ndWFnZSBpcyB1bmtub3duLiBPbWl0dGluZyB0aGUgdGFnIGlzDQo+ IHByZWZlcnJlZC4gU29tZSBwcm90b2NvbHMgbWF5IGZvcmNlIHlvdSB0byBnaXZlIGEgdmFsdWUg Zm9yIHRoZSBsYW5ndWFnZQ0KPiB0YWcNCj4gYW5kIHRoZSAnVU5EJyBzdWJ0YWcgbWF5IGJlIHVz ZWZ1bCB3aGVuIG1hdGNoaW5nIGxhbmd1YWdlIHRhZ3MgaW4gY2VydGFpbg0KPiBzaXR1YXRpb25z Lg0KPiANCj4gPlRoZSAnTVVMJyAoTXVsdGlwbGUpIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIFNI T1VMRCBOT1QgYmUgdXNlZCBpZiB0aGUNCj4gcHJvdG9jb2wgYWxsb3dzIHlvdSB0byB1c2UgbXVs dGlwbGUgbGFuZ3VhZ2VzLCBhcyBpcyB0aGUgY2FzZSBmb3IgdGhlDQo+IENvbnRlbnQtTGFuZ3Vh Z2UgaGVhZGVyIGluIEhUVFAuDQo+IA0KPiA+ICA8c3BhbiBsYW5nPSJGUiI+Qydlc3QgbGEgdmll Ljwvc3Bhbj4gaW4NCj4gDQoNCg0K --===============1931208951== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============1931208951==-- From ltru-bounces@lists.ietf.org Thu Apr 21 14:51:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOglc-000295-2f; Thu, 21 Apr 2005 14:51:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgla-000290-DY for ltru@megatron.ietf.org; Thu, 21 Apr 2005 14:51:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26094 for ; Thu, 21 Apr 2005 14:51:09 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOgx3-0007WR-AI for ltru@ietf.org; Thu, 21 Apr 2005 15:03:02 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 11:50:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 21 Apr 2005 11:50:59 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B2096EC@irvmbxw01.quest.com> Thread-Topic: edits posted Thread-Index: AcVGow3hvHFRIZuRS765gQ0RPO1FHQ== From: "Addison Phillips" To: "ltru Working Group" X-OriginalArrivalTime: 21 Apr 2005 18:51:00.0085 (UTC) FILETIME=[0F563A50:01C546A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Ltru] edits posted X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0026821873==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0026821873== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 aHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tL0lEL2RyYWZ0LWlldGYtbHRydS1yZWdpc3RyeS0w MS5odG1sIChvciAudHh0KQ0KDQpBbGwgZWRpdHMgaW5jb3Jwb3JhdGVkLg0KDQpBZGRpc29uIFAu IFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6 Ly93d3cucXVlc3QuY29tDQoNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBX b3JraW5nIEdyb3VwDQpodHRwOi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsDQoNCkludGVybmF0 aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0K DQo= --===============0026821873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0026821873==-- From ltru-bounces@lists.ietf.org Thu Apr 21 14:52:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgn1-0002CT-EV; Thu, 21 Apr 2005 14:52:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgn0-0002CO-Nv for ltru@megatron.ietf.org; Thu, 21 Apr 2005 14:52:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26144 for ; Thu, 21 Apr 2005 14:52:37 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime01.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOgyT-0007YD-IM for ltru@ietf.org; Thu, 21 Apr 2005 15:04:30 -0400 Received: from uknsprd1 (unverified) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 21 Apr 2005 18:52:25 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IFB00IEU8FCCM@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 21 Apr 2005 19:52:25 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Thu, 21 Apr 2005 18:52:24 +0000 Date: Thu, 21 Apr 2005 19:51:31 +0100 From: Misha Wolf Subject: RE: [Ltru] New version posted: ready for publication?? To: ltru Working Group Message-id: <1987416CA83AC7499AC772F92E2DBF7803956C70@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] New version posted: ready for publication?? Thread-Index: AcVGlSDia+6OJaiaSqOWJ9g2K+8d+gABPuKwAACZ0BAAAXgp4AAAFKEg content-class: urn:content-classes:message X-OriginalArrivalTime: 21 Apr 2005 18:52:24.0721 (UTC) FILETIME=[41C8A810:01C546A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org We're getting there :-) I think I'm clear why 'UND' is referred to below sometimes as a tag=20 and sometimes as a subtag. Will the reader be equally clear? Thanks, Misha The 'UND' (Undetermined) primary language subtag SHOULD NOT be used to label content, even if the language is unknown. Omitting the tag is preferred. The 'UND' tag may be useful for protocols that require a language tag to be provided. The 'UND' subtag may also be useful when matching language tags in certain situations. ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 14:59:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgtk-0002zs-9K; Thu, 21 Apr 2005 14:59:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgti-0002zm-Tq for ltru@megatron.ietf.org; Thu, 21 Apr 2005 14:59:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26599 for ; Thu, 21 Apr 2005 14:59:33 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOh59-0007gy-Rp for ltru@ietf.org; Thu, 21 Apr 2005 15:11:27 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 11:59:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] New version posted: ready for publication?? Date: Thu, 21 Apr 2005 11:59:22 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B209705@irvmbxw01.quest.com> Thread-Topic: [Ltru] New version posted: ready for publication?? Thread-Index: AcVGlSDia+6OJaiaSqOWJ9g2K+8d+gABPuKwAACZ0BAAAXgp4AAAFKEgAABSC9A= From: "Addison Phillips" To: "Misha Wolf" , "ltru Working Group" X-OriginalArrivalTime: 21 Apr 2005 18:59:22.0752 (UTC) FILETIME=[3AF32000:01C546A4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org No, probably not. More holdover text, I'm afraid. How about: > The 'UND' (Undetermined) primary language subtag SHOULD NOT be used > to label content, even if the language is unknown. Omitting the = language tag altogether is preferred to using a tag with a primary = language subtag of 'und'. The 'UND' subtag may be useful for protocols = that require a > language tag to be provided. The 'UND' subtag may also be useful when > matching language tags in certain situations. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Misha Wolf > Sent: Thursday, April 21, 2005 11:52 AM > To: ltru Working Group > Subject: RE: [Ltru] New version posted: ready for publication?? >=20 > We're getting there :-) >=20 > I think I'm clear why 'UND' is referred to below sometimes as a tag > and sometimes as a subtag. Will the reader be equally clear? >=20 > Thanks, > Misha >=20 > The 'UND' (Undetermined) primary language subtag SHOULD NOT be used > to label content, even if the language is unknown. Omitting the tag is > preferred. The 'UND' tag may be useful for protocols that require a > language tag to be provided. The 'UND' subtag may also be useful when > matching language tags in certain situations. >=20 >=20 >=20 > ----------------------------------------------------------------- > Visit our Internet site at http://www.reuters.com >=20 > To find out more about Reuters Products and Services visit > http://www.reuters.com/productinfo >=20 > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be > the views of Reuters Ltd. >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 15:04:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgyV-0003So-62; Thu, 21 Apr 2005 15:04:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgyT-0003Sb-Qs for ltru@megatron.ietf.org; Thu, 21 Apr 2005 15:04:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26920 for ; Thu, 21 Apr 2005 15:04:28 -0400 (EDT) Received: from lonsmimeo.rit.reuters.com ([192.165.213.23] helo=lonsmime04.rit.reuters.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOh9w-0007nF-LG for ltru@ietf.org; Thu, 21 Apr 2005 15:16:22 -0400 Received: from eupig1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 21 Apr 2005 19:04:17 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.5.75.142]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IFB00LRX8Z5TU@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 21 Apr 2005 19:04:17 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by lonsmsxb01.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Thu, 21 Apr 2005 19:04:17 +0000 Date: Thu, 21 Apr 2005 20:03:48 +0100 From: Misha Wolf Subject: RE: [Ltru] New version posted: ready for publication?? To: ltru Working Group MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] New version posted: ready for publication?? Thread-Index: AcVGlSDia+6OJaiaSqOWJ9g2K+8d+gABPuKwAACZ0BAAAXgp4AAAFKEgAABSC9AAAC0gIA== content-class: urn:content-classes:message X-OriginalArrivalTime: 21 Apr 2005 19:04:17.0463 (UTC) FILETIME=[EA9C7470:01C546A4] X-Spam-Score: 0.8 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org If you reconcile that and Mark's text, it'll be fine. Thanks, Misha -----Original Message----- From: Addison Phillips [mailto:addison.phillips@quest.com]=20 Sent: 21 April 2005 19:59 To: Misha Wolf; ltru Working Group Subject: RE: [Ltru] New version posted: ready for publication?? No, probably not. More holdover text, I'm afraid. How about: > The 'UND' (Undetermined) primary language subtag SHOULD NOT be used > to label content, even if the language is unknown. Omitting the language tag altogether is preferred to using a tag with a primary language subtag of 'und'. The 'UND' subtag may be useful for protocols that require a > language tag to be provided. The 'UND' subtag may also be useful when > matching language tags in certain situations. ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reute= rs.com/productinfo=20 Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 15:09:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOh3X-0003w0-4S; Thu, 21 Apr 2005 15:09:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOh3V-0003vv-42 for ltru@megatron.ietf.org; Thu, 21 Apr 2005 15:09:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27712 for ; Thu, 21 Apr 2005 15:09:39 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOhEx-0007tm-2S for ltru@ietf.org; Thu, 21 Apr 2005 15:21:33 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 12:09:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] New version posted: ready for publication?? Date: Thu, 21 Apr 2005 12:09:28 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B20971C@irvmbxw01.quest.com> Thread-Topic: [Ltru] New version posted: ready for publication?? Thread-Index: AcVGlSDia+6OJaiaSqOWJ9g2K+8d+gABPuKwAACZ0BAAAXgp4AAAFKEgAABSC9AAAC0gIAAANJlQ From: "Addison Phillips" To: "Misha Wolf" , "ltru Working Group" X-OriginalArrivalTime: 21 Apr 2005 19:09:29.0342 (UTC) FILETIME=[A48169E0:01C546A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org That's the reconciled version (except that I didn't fix the case on UND = in my message). I'll make the change. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Misha Wolf > Sent: Thursday, April 21, 2005 12:04 PM > To: ltru Working Group > Subject: RE: [Ltru] New version posted: ready for publication?? >=20 > If you reconcile that and Mark's text, it'll be fine. >=20 > Thanks, > Misha >=20 > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: 21 April 2005 19:59 > To: Misha Wolf; ltru Working Group > Subject: RE: [Ltru] New version posted: ready for publication?? >=20 > No, probably not. More holdover text, I'm afraid. >=20 > How about: >=20 > > The 'UND' (Undetermined) primary language subtag SHOULD NOT be = used > > to label content, even if the language is unknown. Omitting the > language tag altogether is preferred to using a tag with a primary > language subtag of 'und'. The 'UND' subtag may be useful for protocols > that require a > > language tag to be provided. The 'UND' subtag may also be useful = when > > matching language tags in certain situations. >=20 >=20 >=20 > ----------------------------------------------------------------- > Visit our Internet site at http://www.reuters.com >=20 > To find out more about Reuters Products and Services visit > http://www.reuters.com/productinfo >=20 > Any views expressed in this message are those of the individual > sender, except where the sender specifically states them to be > the views of Reuters Ltd. >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 15:36:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhTs-0007Tf-W6; Thu, 21 Apr 2005 15:36:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhTr-0007Sa-Vq for ltru@megatron.ietf.org; Thu, 21 Apr 2005 15:36:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00795 for ; Thu, 21 Apr 2005 15:36:53 -0400 (EDT) Received: from mail00.svc.cra.dublin.eircom.net ([159.134.118.16]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DOhfK-0000Bf-Di for ltru@ietf.org; Thu, 21 Apr 2005 15:48:47 -0400 Received: (qmail 26236 messnum 6387770 invoked from network[194.125.205.100/ts07-100.dublin.indigo.ie]); 21 Apr 2005 19:36:33 -0000 Received: from ts07-100.dublin.indigo.ie (HELO egt.ie) (194.125.205.100) by mail00.svc.cra.dublin.eircom.net (qp 26236) with SMTP; 21 Apr 2005 19:36:33 -0000 Message-ID: <4268004E.353D909B@egt.ie> Date: Thu, 21 Apr 2005 20:34:38 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: ltru Working Group Subject: Re: [Ltru] New version posted: ready for publication?? References: <1987416CA83AC7499AC772F92E2DBF7803956C70@LONSMSXM02.emea.ime.reuters.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA00795 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Tag 'UND' still worries me a bit, as it echoes 'UN' (United Nations).=20 Would it be possible to use some other combination (say, XXX)?=20 Only a suggestion (not wishing to add to your difficulties). mg Scr=EDobh Misha Wolf: > ... > I think I'm clear why 'UND' is referred to below sometimes as a tag > and sometimes as a subtag. Will the reader be equally clear? >=20 > Thanks, > Misha Scr=EDobh Addison Phillips: >=20 > Yes, I agree. How about: >=20 > -- >=20 > The 'UND' (Undetermined) primary language subtag SHOULD NOT be used = to label content, even if the language is unknown. Omitting the tag is pr= eferred. The 'UND' tag may be useful for protocols that require a languag= e tag to be provided. The 'UND' subtag may also be useful when matching l= anguage tags in certain situations. >=20 > -- >=20 > Addison --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 15:40:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhX8-0007xo-Hw; Thu, 21 Apr 2005 15:40:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhX6-0007xd-MK for ltru@megatron.ietf.org; Thu, 21 Apr 2005 15:40:17 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01208 for ; Thu, 21 Apr 2005 15:40:14 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DOhS7-0000KZ-LD for ltru@lists.ietf.org; Thu, 21 Apr 2005 21:35:07 +0200 Received: from 212.82.251.14 ([212.82.251.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2005 21:35:07 +0200 Received: from nobody by 212.82.251.14 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2005 21:35:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 21 Apr 2005 21:35:04 +0200 Organization: Lines: 35 Message-ID: <42680068.5357@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B20967F@irvmbxw01.quest.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.14 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] in practice only 25 (was: New version posted: ready for publication??) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > In practice, this limits most tags to a sequence of four > subtags, and thus a length of 35 (excluding any extensions > or private use sequences), because subtags are limited to a > length of eight characters. 35 = 4*8 + 3 dashes is clear, but not "in practice". This is something Bruce and the RfC 2231 cohorts will find. BTW, you still have 2*3ALPHA / registered-lang and *("-" extlang) Assuming that you fix it to 2*4ALPHA / registered-lang and at most one extlang you get 22 = 8 + 4 + 3 + 8 + 3 dashes for a registered-lang without extlang or 25 = 3 + 3 + 4 + 3 + 8 + 4 dashes for an alpha-3 language with extlang. A worst case 25 is much more friendly than 35 for the encoded words in mail headers. =?pc-multilingual-850+euro*xxx-yyy-Latn-999-limerick?Q?yes?= ....5...10....5...20....5...30....5...40....5...50....5...60 Excellent, the RfC 2047 limit is 75 => 13 characters left for the content, that's nine characters for base64, and certainly more than one B64 encoded UTF-8. Something I've tested for USEFOR: =?UTF-8*de-DE-1996?B?RG9uYXVkYW1wZnNjaGlmZmZhaHJ0c2thcGl0w6Ruc23DvHR6ZQ==?= ....5...10....5...20....5...30....5...40....5...50....5...60....5...70....5. Yes, it's ridiculous. But Ned didn't like my idea to obsolete RfC 2231 for "various reasons". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 15:41:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhYE-00082b-6a; Thu, 21 Apr 2005 15:41:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhYD-00082V-Bn for ltru@megatron.ietf.org; Thu, 21 Apr 2005 15:41:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01415 for ; Thu, 21 Apr 2005 15:41:23 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOhje-0000Kv-6C for ltru@ietf.org; Thu, 21 Apr 2005 15:53:17 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Apr 2005 12:41:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] New version posted: ready for publication?? Date: Thu, 21 Apr 2005 12:41:10 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B209759@irvmbxw01.quest.com> Thread-Topic: [Ltru] New version posted: ready for publication?? Thread-Index: AcVGqYKOXqu3VtgJTe2xmo4y2+9zSgAABP/w From: "Addison Phillips" To: "Marion Gunn" , "ltru Working Group" X-OriginalArrivalTime: 21 Apr 2005 19:41:11.0448 (UTC) FILETIME=[123FC180:01C546AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org 'und' is a primary language code, i.e. it is an ISO 639-2 language code = whose meaning is 'Undetermined Language'. Its meaning is not assigned by = the draft. In fact, this particular recommendation dates to RFC 3066 and = we are merely prettying up the language. Best Regards, Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Marion Gunn > Sent: Thursday, April 21, 2005 12:35 PM > To: ltru Working Group > Subject: Re: [Ltru] New version posted: ready for publication?? >=20 > Tag 'UND' still worries me a bit, as it echoes 'UN' (United Nations). >=20 > Would it be possible to use some other combination (say, XXX)? >=20 > Only a suggestion (not wishing to add to your difficulties). > mg >=20 > Scr=EDobh Misha Wolf: > > ... > > I think I'm clear why 'UND' is referred to below sometimes as a tag > > and sometimes as a subtag. Will the reader be equally clear? > > > > Thanks, > > Misha >=20 > Scr=EDobh Addison Phillips: > > > > Yes, I agree. How about: > > > > -- > > > > The 'UND' (Undetermined) primary language subtag SHOULD NOT be = used > to label content, even if the language is unknown. Omitting the tag is > preferred. The 'UND' tag may be useful for protocols that require a > language tag to be provided. The 'UND' subtag may also be useful when > matching language tags in certain situations. > > > > -- > > > > Addison >=20 > -- >=20 > Marion Gunn * EGTeo (Estab.1991) > 27 P=E1irc an Fh=E9ithlinn, Baile an > Bh=F3thair, Co. =C1tha Cliath, =C9ire. > * mgunn@egt.ie * eamonn@egt.ie * >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 15:42:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhZ3-0008Ks-C5; Thu, 21 Apr 2005 15:42:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhZ1-0008KW-Vf for ltru@megatron.ietf.org; Thu, 21 Apr 2005 15:42:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01531 for ; Thu, 21 Apr 2005 15:42:14 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOhkS-0000Lk-F2 for ltru@ietf.org; Thu, 21 Apr 2005 15:54:08 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3LJfxV9001484; Thu, 21 Apr 2005 15:42:00 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 21 Apr 2005 15:42:02 -0400 Date: Thu, 21 Apr 2005 15:42:02 -0400 From: John Cowan To: Addison Phillips Subject: Re: [Ltru] New version posted: ready for publication?? Message-ID: <20050421194202.GD26781@skunk.reutershealth.com> References: <634978A7DF025A40BFEF33EB191E13BC0B209705@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B209705@irvmbxw01.quest.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Misha Wolf , ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips scripsit: > The 'UND' (Undetermined) primary language subtag SHOULD NOT be > used to label content, even if the language is unknown. Omitting the > language tag altogether is preferred to using a tag with a primary > language subtag of 'und'. The 'UND' subtag may be useful for protocols > that require a language tag to be provided. The 'UND' subtag may > also be useful when matching language tags in certain situations. Now that I think about it, I don't think I believe this. What about when you are tagging documents you don't understand? I, for example, can recognize Devanagari script accurately, but I can't tell one such language from another. Tagging such a document und-Deva would at least tell the recipient something about it, as opposed to no tag at all. By the same token, I may not be able to identify either the script or the language of a random document from India, but tagging it und-IN carries at least some information. How about this? The 'und' (undetermined) primary language subtag MAY be used in conjunction with other subtags when the language is unknown but the script or region is known. It SHOULD NOT be used without other subtags except in a protocol that requires a language tag to be provided; otherwise, omitting a language tag altogether is preferable. (I don't understand the last sentence and have left it out.) -- John Cowan www.ccil.org/~cowan www.reutershealth.com jcowan@reutershealth.com SAXParserFactory [is] a hideous, evil monstrosity of a class that should be hung, shot, beheaded, drawn and quartered, burned at the stake, buried in unconsecrated ground, dug up, cremated, and the ashes tossed in the Tiber while the complete cast of Wicked sings "Ding dong, the witch is dead." --Elliotte Rusty Harold on xml-dev _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 15:44:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhaj-00009L-F9; Thu, 21 Apr 2005 15:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhai-00009G-Es for ltru@megatron.ietf.org; Thu, 21 Apr 2005 15:44:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01901 for ; Thu, 21 Apr 2005 15:43:59 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOhmB-0000Va-JB for ltru@ietf.org; Thu, 21 Apr 2005 15:55:53 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Thu, 21 Apr 2005 12:43:48 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Thu, 21 Apr 2005 12:43:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2005 12:43:49 -0700 Message-ID: Thread-Topic: [OT] How should "fa" be handled in the future? Thread-Index: AcVGqnBzxB1NeIp6S/y9Rh+jKKa+fw== From: "Peter Constable" To: X-OriginalArrivalTime: 21 Apr 2005 19:43:47.0309 (UTC) FILETIME=[6F2641D0:01C546AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Cc: Subject: [Ltru] [OT] How should "fa" be handled in the future? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I've a question that's a bit off topic -- it has no bearing on the content we want in our Internet drafts. But, it does involve a future implication for RFC 3066ter tags and a decision that needs to go into ISO/DIS 639-3, and right now this list is particularly appropriate for providing feedback. In the course of developing ISO 639-3, there are various issues in ISO 639-2 that I have asked the ISO 639/RA Joint Advisory Committee to resolve. (I need this to know how items in ISO 639-2 relate to items in the Ethnologue, and hence what the code table and macrolanguage-mapping table in part 3 should include.) One of these issues pertains to Persian / Farsi: ISO 639-1: fa ISO 639-2/T: fas ISO 639-2/B: per I want to ask people here what their thoughts about this case are since, given what we have been anticipating wrt 3066ter and 639-3, it will impact the recommended tag for content related to that part of the world. Ethnologue makes a distinction between Persian and Dari. (It uses different names as the reference names for those entries: the reference name used for the national language of Iran, aka "Persian", is "Western Farsi"; the reference name used for the national language of Afghanistan, aka Dari, is "Eastern Farsi".) I don't think there's really much debate about that distinction, though occasionally I've seen people say they're the same. The question is what the relationship to the existing ISO 639 category fa/fas/per has to these two items in Ethnologue. The options are: 1) fa/fas/per corresponds exactly to the national language of Iran, Persian 2) fa/fas/per is a macrolanguage encompassing both Persian and Dari In the draft for 639-3, I ended up assuming the second choice. A couple of factors prompted me in that direction: - the MARC Language Code List treats the ISO 639-2/B ID per as encompassing Dari - in the UNDP-sponsored specification for locale requirements for Afghanistan (http://www.evertype.com/standards/af/), the locale ID used for Dari is "fa_AF"; this has also been used in CLDR. Now, the recommended RFC 3066ter language tags for these two languages under the two options listed above would be as follows: [Note: in the draft code table for ISO/DIS 639-3, the ID for "Western Farsi" is "pes", and that for "Eastern Farsi" is "prs". These may possibly change before 639-3 is published.] 1) fa/fas/per =3D Persian only: Persian: "fa" or "fa-IR" Dari: "prs" or "prs-AF" 2) fa/fas/per =3D macrolangauge encompassing Persian and Dari: Persian: "fa-pes" or "fa-pes-IR" Dari: "fa-prs" or "fa-prs-AF" That is, these would be the tags if option 2 is adopted in ISO 639 and the idea we have had for implementing extlang subtags is adopted in RFC 3066ter without any grandfathering clauses or other complications. The impact of each of these would be as follows: - Option 1 would impact MARC records and any other Dari content that has been tagged using fa/fas/per -- it would now be considered incorrectly tagged (though the error would only be found on inspection of the content). It would also impact locale naming for Dari used by CLDR or any other existing locale implementation that bases names on RFC 3066bis/ter conventions.=20 - Option 2 would have a potential modest impact on existing Persian/Farsi content: if any user or application assumed that fa/fas/per specifically excluded Dari, that would no longer be the case; for existing content tagged with fa/fas/per, that tag would still be valid though not as specific as possible. Also, the locale name for Persian used by CLDR or other similar implementations would be impacted. Neither choice is completely clean. Comments? Thanks. =20 Peter Constable GIFT | GPTS | MICROSOFT =20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 15:46:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhcg-0000ZM-58; Thu, 21 Apr 2005 15:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhce-0000Z5-Bm for ltru@megatron.ietf.org; Thu, 21 Apr 2005 15:46:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02051 for ; Thu, 21 Apr 2005 15:45:58 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOho7-0000Yt-0l for ltru@ietf.org; Thu, 21 Apr 2005 15:57:52 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3LJjlSM001498; Thu, 21 Apr 2005 15:45:47 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 21 Apr 2005 15:45:48 -0400 Date: Thu, 21 Apr 2005 15:45:47 -0400 From: John Cowan To: Marion Gunn Subject: Re: [Ltru] New version posted: ready for publication?? Message-ID: <20050421194547.GE26781@skunk.reutershealth.com> References: <1987416CA83AC7499AC772F92E2DBF7803956C70@LONSMSXM02.emea.ime.reuters.com> <4268004E.353D909B@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4268004E.353D909B@egt.ie> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Marion Gunn scripsit: > Tag 'UND' still worries me a bit, as it echoes 'UN' (United Nations). > > Would it be possible to use some other combination (say, XXX)? The assignment of RFC 639-2 tags like this one is entirely out of our hands. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan "The exception proves the rule." Dimbulbs think: "Your counterexample proves my theory." Latin students think "'Probat' means 'tests': the exception puts the rule to the proof." But legal historians know it means "Evidence for an exception is evidence of the existence of a rule in cases not excepted from." _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 15:52:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhii-0002bf-Bu; Thu, 21 Apr 2005 15:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOhig-0002bI-Ol for ltru@megatron.ietf.org; Thu, 21 Apr 2005 15:52:14 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03753 for ; Thu, 21 Apr 2005 15:52:12 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DOhdR-0001v3-Kb for ltru@lists.ietf.org; Thu, 21 Apr 2005 21:46:49 +0200 Received: from 212.82.251.14 ([212.82.251.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2005 21:46:49 +0200 Received: from nobody by 212.82.251.14 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Apr 2005 21:46:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 21 Apr 2005 21:49:15 +0200 Organization: Lines: 9 Message-ID: <426803BB.29E3@xyzzy.claranet.de> References: <1987416CA83AC7499AC772F92E2DBF7803956C70@LONSMSXM02.emea.ime.reuters.com> <4268004E.353D909B@egt.ie> 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.14 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: New version posted: ready for publication?? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Marion Gunn wrote: > Tag 'UND' still worries me a bit, as it echoes 'UN' (United > Nations). UNDetermined was NIH (not invented here), bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 21 18:32:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOkE7-0005Y9-6F; Thu, 21 Apr 2005 18:32:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOkE5-0005Y4-CD for ltru@megatron.ietf.org; Thu, 21 Apr 2005 18:32:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24931 for ; Thu, 21 Apr 2005 18:32:47 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOkPa-0007Yo-63 for ltru@ietf.org; Thu, 21 Apr 2005 18:44:43 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3LMWcqW002336; Thu, 21 Apr 2005 18:32:39 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 21 Apr 2005 18:32:40 -0400 Date: Thu, 21 Apr 2005 18:32:39 -0400 From: John Cowan To: Peter Constable Subject: Re: [Ltru] [OT] How should "fa" be handled in the future? Message-ID: <20050421223239.GM26781@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable scripsit: > - Option 2 would have a potential modest impact on existing > Persian/Farsi content: if any user or application assumed that > fa/fas/per specifically excluded Dari, that would no longer be the case; > for existing content tagged with fa/fas/per, that tag would still be > valid though not as specific as possible. Also, the locale name for > Persian used by CLDR or other similar implementations would be impacted. I think Option 2 is the clear winner, given that there are already Dari resources tagged fa. From what I can make out, people who can read high-register Farsi don't have much trouble with written Dari. I think your last point isn't necessarily valid: fa-IR and fa-AF still work; the whole point of a macrolanguage is that you use it when you don't care about details. -- He made the Legislature meet at one-horse John Cowan tank-towns out in the alfalfa belt, so that jcowan@reutershealth.com hardly nobody could get there and most of http://www.reutershealth.com the leaders would stay home and let him go http://www.ccil.org/~cowan to work and do things as he pleased. --Mencken, Declaration of Independence _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Apr 22 04:52:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOttZ-0001gZ-N4; Fri, 22 Apr 2005 04:52:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOttY-0001gJ-Hy for ltru@megatron.ietf.org; Fri, 22 Apr 2005 04:52:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25865 for ; Fri, 22 Apr 2005 04:52:14 -0400 (EDT) Received: from mail02.svc.cra.dublin.eircom.net ([159.134.118.18]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DOu58-0004Q9-DU for ltru@ietf.org; Fri, 22 Apr 2005 05:04:15 -0400 Received: (qmail 84324 messnum 5250793 invoked from network[194.125.148.116/ts03-116.dublin.indigo.ie]); 22 Apr 2005 08:52:03 -0000 Received: from ts03-116.dublin.indigo.ie (HELO egt.ie) (194.125.148.116) by mail02.svc.cra.dublin.eircom.net (qp 84324) with SMTP; 22 Apr 2005 08:52:03 -0000 Message-ID: <4268BABF.74CBBF26@egt.ie> Date: Fri, 22 Apr 2005 09:50:07 +0100 From: Marion Gunn X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Subject: Re: [Ltru] New version posted: ready for publication?? References: <634978A7DF025A40BFEF33EB191E13BC0B209759@irvmbxw01.quest.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA25865 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I know. Was just half-hoping that could be changed for LTRU purposes as part of 'prettying up'. If it can't, it can't (God knows, it's not the worst thing in 639 circles). Best, Addison Phillips wrote: >=20 > 'und' is a primary language code, i.e. it is an ISO 639-2 language code= whose meaning is 'Undetermined Language'. Its meaning is not assigned by= the draft. In fact, this particular recommendation dates to RFC 3066 and= we are merely prettying up the language. >=20 > Best Regards, >=20 > Addison --=20 Marion Gunn * EGTeo (Estab.1991) 27 P=E1irc an Fh=E9ithlinn, Baile an=20 Bh=F3thair, Co. =C1tha Cliath, =C9ire. * mgunn@egt.ie * eamonn@egt.ie * _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Apr 22 05:35:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOuZN-0007OL-OZ; Fri, 22 Apr 2005 05:35:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOuZM-0007O6-I5 for ltru@megatron.ietf.org; Fri, 22 Apr 2005 05:35:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28912 for ; Fri, 22 Apr 2005 05:35:26 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOukw-0005Nr-VG for ltru@ietf.org; Fri, 22 Apr 2005 05:47:28 -0400 Received: from lns-p19-4-idf-82-65-248-117.adsl.proxad.net ([82.65.248.117] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DOuZJ-0007tN-JQ for ltru@ietf.org; Fri, 22 Apr 2005 02:35:25 -0700 Message-Id: <6.2.1.2.2.20050422113504.043b6c10@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 22 Apr 2005 11:35:17 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [Ltru] Support of JAVA X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I am not a Java developper. I am told there are equivalent problems in Java to support RFC 3066 and to include the script, Java not permitting the use of "-" and "_" in the initial part of the tag? If I am correct the proposed format does not consider/coordinate with Java's needs. This would be a lack of extensibility of the format? Thank you for the comments. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Apr 22 10:48:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOzRs-0005nh-Ps; Fri, 22 Apr 2005 10:48:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOzRq-0005nI-Q0 for ltru@megatron.ietf.org; Fri, 22 Apr 2005 10:48:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24639 for ; Fri, 22 Apr 2005 10:48:00 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOzdS-0004Wm-Jf for ltru@ietf.org; Fri, 22 Apr 2005 11:00:05 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Fri, 22 Apr 2005 07:47:51 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Fri, 22 Apr 2005 07:47:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Support of JAVA Date: Fri, 22 Apr 2005 07:48:01 -0700 Message-ID: Thread-Topic: [Ltru] Support of JAVA Thread-Index: AcVHHte6VfWHN/0BR4qT6OuKW4yI9gAKeKNQ From: "Peter Constable" To: "ltru Working Group" X-OriginalArrivalTime: 22 Apr 2005 14:47:50.0194 (UTC) FILETIME=[417F4920:01C5474A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of JFC (Jefsey) Morfin > I am not a Java developper. I am told there are equivalent problems in > Java > to support RFC 3066 and to include the script, Java not permitting the use > of "-" and "_" in the initial part of the tag? If I am correct the > proposed > format does not consider/coordinate with Java's needs. This would be a > lack > of extensibility of the format? I think this is not a concern for us. If Java has some API that passes RFC 3066 language tags and it can't handle - "in the initial part of the tag" then it's already not conforming to RFC 3066. If it has some API that passes a locale ID and their locale IDs can't handle =3D or _ "in = the initial part of the tag", then that's not an RFC 3066 application that we need to worry about. The ISO 639 JAC has received requests for alpha-2 IDs from people working on Unix/Linux localization projects saying that they were told they needed an alpha-2 ID for their language because it couldn't handle alpha-3 IDs. That is not the JAC's problem, and we will not throw away the criteria for additions to ISO 639-1 just to make things easier for some software projects (and turn the limited alpha-2 codespace into a first-come-first-served land-grab).=20 In just the same way, I think this Java issue is just that: an issue for Java to deal with, not us. I seem to recall that at some point JFC was saying that an Internet specification for language tags should not be driven by the needs of XML. If so (my memory may be failing me), then I'm surprised, then, that he's bringing up this issue. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Apr 22 12:15:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP0os-0000zW-DC; Fri, 22 Apr 2005 12:15:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP0or-0000zO-2z for ltru@megatron.ietf.org; Fri, 22 Apr 2005 12:15:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01281 for ; Fri, 22 Apr 2005 12:15:50 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP10V-0006fl-2u for ltru@ietf.org; Fri, 22 Apr 2005 12:27:56 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Apr 2005 09:15:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Support of JAVA Date: Fri, 22 Apr 2005 09:15:35 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.com> Thread-Topic: [Ltru] Support of JAVA Thread-Index: AcVHHwKuDk6645zdR9iKQT7lTmTtXwAM8uSg From: "Addison Phillips" To: "JFC (Jefsey) Morfin" , "ltru Working Group" X-OriginalArrivalTime: 22 Apr 2005 16:15:37.0062 (UTC) FILETIME=[84CB9060:01C54756] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I am a Java developer and Java java.util.Locale objects are not to be = confused with language tags. What Java does internally has nothing to do with language tags. The only = real touchpoint is in J2EE, in which the Accept-Language header in an = HTTP request is mapped onto Locale objects in a rather brain-dead = fashion (I mentioned this on-list recently). The use of "_" as a token separator in Java locales has nothing to do = with language tags. The fact that Java locales use ISO 639-1 and ISO = 3166 internally is nice, but that doesn't make a Locale object into a = language tag. Perhaps you should read up on the alleged problem before = proposing it as one? The folks at Sun in the J2SE group are aware of the work going on this = area. I believe they are waiting to see the outcome before creating an = implementation. In any case, I fail to see how making language tags compatible with = every proprietary locale tagging scheme in the world (and there are many = of these) serves the greater good. It is up to proprietary schemes to = adapt to standards and not the other way around. Hey, while we're all = boggling about the potential effects, I notice that Microsoft's = CultureInfo class in C# and their LangID/LCID system might be affected = too! And what about those POSIX locales?=20 Oh, the horror of it all. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of JFC (Jefsey) Morfin > Sent: Friday, April 22, 2005 2:35 AM > To: ltru Working Group > Subject: [Ltru] Support of JAVA >=20 > I am not a Java developper. I am told there are equivalent problems in > Java > to support RFC 3066 and to include the script, Java not permitting the = use > of "-" and "_" in the initial part of the tag? If I am correct the > proposed > format does not consider/coordinate with Java's needs. This would be a > lack > of extensibility of the format? > Thank you for the comments. > jfc >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Apr 22 20:43:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP8kP-0005pF-DL; Fri, 22 Apr 2005 20:43:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP8kO-0005p5-Pz for ltru@megatron.ietf.org; Fri, 22 Apr 2005 20:43:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19477 for ; Fri, 22 Apr 2005 20:43:45 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP8w5-0005rG-4K for ltru@ietf.org; Fri, 22 Apr 2005 20:55:54 -0400 Received: from lns-p19-4-idf-82-65-248-117.adsl.proxad.net ([82.65.248.117] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DP8kF-0002MJ-VK for ltru@ietf.org; Fri, 22 Apr 2005 17:43:40 -0700 Message-Id: <6.2.1.2.2.20050423010220.03f44690@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 23 Apr 2005 02:43:31 +0200 To: "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Support of JAVA Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 16:48 22/04/2005, Peter Constable said: >I think this is not a concern for us. Dear Peter, this WG results from the lack of consensus during two Last Calls. The main objection during that Last Call is the refusal of the authors to consider that the Internet may include other needs than the XML, HTML and CLDR need. 1. The HTML needs have not been discussed. I do know any problem but I am not an HTML expert. 2. The CLDR needs have never been discussed, in spite of my questions. 3. The XML needs have been fully described as resulting from a lack of foreseeing (exansibility) and propositions have been made. This does not addresses the other needs which up to now have been denied (DNS, LDAP, ONES, CRC, etc.) >In just the same way, I think this Java issue is just that: an issue for >Java to deal with, not us. Who is "us"? Your "us" is obviously the same as mine. Mine is, scalably, every Internet user, every internet protocol, every internet application. XML, HTML, CLDR are just some of these applications as are Java, LDAP, C, DNS, ONES, CRC, .NET, etc. >I seem to recall that at some point JFC was saying that an Internet >specification for language tags should not be driven by the needs of XML. >If so (my memory may be failing me), then I'm surprised, then, that he's >bringing up this issue. I am glad you eventually heard me, even if you did not understand. IANA languages tags cannot ne driven by the needs of XML, nor Java, nor CLDR, nor DNS, etc. they must all be consistent with the Internet architecture, to be cross consistent. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Apr 22 20:43:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP8kP-0005pd-Hv; Fri, 22 Apr 2005 20:43:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP8kO-0005p6-Py for ltru@megatron.ietf.org; Fri, 22 Apr 2005 20:43:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19479 for ; Fri, 22 Apr 2005 20:43:45 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DP8w5-0005rI-4O for ltru@ietf.org; Fri, 22 Apr 2005 20:55:54 -0400 Received: from lns-p19-4-idf-82-65-248-117.adsl.proxad.net ([82.65.248.117] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DP8kH-0002MJ-1i; Fri, 22 Apr 2005 17:43:41 -0700 Message-Id: <6.2.1.2.2.20050423010354.02bc35a0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 23 Apr 2005 02:40:28 +0200 To: "Addison Phillips" , "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: RE: [Ltru] Support of JAVA In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 18:15 22/04/2005, Addison Phillips wrote: >I am a Java developer and Java java.util.Locale objects are not to be >confused with language tags. > >What Java does internally has nothing to do with language tags. The only >real touchpoint is in J2EE, in which the Accept-Language header in an HTTP >request is mapped onto Locale objects in a rather brain-dead fashion (I >mentioned this on-list recently). > >The use of "_" as a token separator in Java locales has nothing to do with >language tags. The fact that Java locales use ISO 639-1 and ISO 3166 >internally is nice, but that doesn't make a Locale object into a language >tag. Perhaps you should read up on the alleged problem before proposing it >as one? I only ask if there is a problem. I am not interested in each problem and each solution, but to make sure to offer the possibility of a solution in every case. The charter says one of the problems to address is the "Lack of parseability and the ability to verify well-formedness". You presume that the only format you discuss offers the best parseability. I presume nothing because this prevents scalability. The charter says "The RFC 3066 standard for language tags has been widely adopted in various protocols and text formats". This rises "thorny" questions: 1. there is no RFC 3066 standard since RFC 3066 is only a BCP and not a standard 2. this implies - what is true - that the language tags are used in various formats. For example, I submit that the best parseability is a fixed hexa format, which in addition permits - in being used as an interface ID - a direct IPv6 access to an information server, for example for accessing the locale data. This is only a debate to better the Draft after two lasts calls, not a full discussion of the Charter. >The folks at Sun in the J2SE group are aware of the work going on this >area. I believe they are waiting to see the outcome before creating an >implementation. I doubt this is a response acceptable to the IESG. >In any case, I fail to see how making language tags compatible with every >proprietary locale tagging scheme in the world (and there are many of >these) serves the greater good. It is up to proprietary schemes to adapt >to standards and not the other way around. Hey, while we're all boggling >about the potential effects, I notice that Microsoft's CultureInfo class >in C# and their LangID/LCID system might be affected too! And what about >those POSIX locales? Question is how does your proposition help them all to converge, to best develop? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Apr 22 21:10:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP99o-0001VL-Ig; Fri, 22 Apr 2005 21:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP99n-0001VF-Dc for ltru@megatron.ietf.org; Fri, 22 Apr 2005 21:10:03 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20946 for ; Fri, 22 Apr 2005 21:10:01 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DP94x-0005G9-Sf for ltru@lists.ietf.org; Sat, 23 Apr 2005 03:05:03 +0200 Received: from 212.82.251.181 ([212.82.251.181]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Apr 2005 03:05:03 +0200 Received: from nobody by 212.82.251.181 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Apr 2005 03:05:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 23 Apr 2005 03:06:46 +0200 Organization: Lines: 24 Message-ID: <42699FA6.CA7@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.com> <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.c om> <6.2.1.2.2.20050423010354.02bc35a0@mail.jefsey.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.181 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] BCP 47 (was: Support of JAVA) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin wrote: > there is no RFC 3066 standard since RFC 3066 is only a BCP > and not a standard I've asked almost the same question here in or resp. It's one of those IETF mysteries I don't get, and reading draft-hoffman-taobis-02 and its references didn't help. :-( I'm almost sure that BCP 47 (3066) _is_ wrong, the 3166-1 business. And we're sure that 3066bis is only a temporary solution until a future 3066ter allows to list ISO 639-3 with extlang etc. Finally I'd bet that my idea to go back to standards track instead of a BCP is "dubious" or worse, but I'd really like to know why. Are BCPs a dead end, is it impossible to get rid of them and to return to standards track ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Apr 22 23:01:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPAtU-0000BB-Fs; Fri, 22 Apr 2005 23:01:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPAtS-0000B6-7q for ltru@megatron.ietf.org; Fri, 22 Apr 2005 23:01:18 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28769 for ; Fri, 22 Apr 2005 23:01:15 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DPAol-0005F4-8l for ltru@lists.ietf.org; Sat, 23 Apr 2005 04:56:27 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Apr 2005 04:56:27 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Apr 2005 04:56:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 23 Apr 2005 04:59:45 +0200 Organization: Lines: 24 Message-ID: <4269BA21.7675@xyzzy.claranet.de> References: <005901c54074$42479a60$7f1afea9@oemcomputer> <069001c54079$f4581180$4109fea9@sanjose.ibm.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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] 003 vs. 021 (was: Moving Forward) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis wrote: > We only see a very small number of the possible generative > English tags in real life: > en-AF, en-AL, en-DZ, en-AS, en-AD, en-AO, en-AI, en-AQ [...] If that's supposed to be a complete list I would miss en-AX and some odd 3066bis cases: en-AA, en-AX, en-BU, en-CS, en-DD, en-FX, en-NT, en-SU, en-TP en-YD, en-ZR, en-ZZ, en-001, en-002, en-003, en-005, en-009 en-011, en-013, en-014, en-015, en-017, en-018, en-019, en-021 en-029, en-030, en-035, en-039, en-053, en-054, en-057, en-061 en-062, en-142, en-145, en-150, en-151, en-154, en-155, en-200 en-419, en-830, en-833 Based on a lstreg.txt with 'File_Date: 2005-04-19' and a quick and dirty script. BTW, what's the difference between the '003 North America' and '021 Northern America' ? The 200 should be deleted IIRC. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Apr 22 23:10:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPB2G-0001RU-TY; Fri, 22 Apr 2005 23:10:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPB26-0001PZ-Fg for ltru@megatron.ietf.org; Fri, 22 Apr 2005 23:10:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29471 for ; Fri, 22 Apr 2005 23:10:12 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPBDq-0000cv-B7 for ltru@ietf.org; Fri, 22 Apr 2005 23:22:23 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3N3A3VM009915; Fri, 22 Apr 2005 23:10:03 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 22 Apr 2005 23:10:10 -0400 Date: Fri, 22 Apr 2005 23:10:10 -0400 From: John Cowan To: Frank Ellermann Subject: Re: [Ltru] 003 vs. 021 (was: Moving Forward) Message-ID: <20050423031010.GC4500@skunk.reutershealth.com> References: <005901c54074$42479a60$7f1afea9@oemcomputer> <069001c54079$f4581180$4109fea9@sanjose.ibm.com> <4269BA21.7675@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4269BA21.7675@xyzzy.claranet.de> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > BTW, what's the difference between the '003 North America' and > '021 Northern America' ? The 200 should be deleted IIRC. Bye. Northern America is an economic grouping, and refers to Canada and the U.S. North America is a geographical grouping, and includes Northern America, Central America, and the Caribbean. -- Yes, chili in the eye is bad, but so is your John Cowan ear. However, I would suggest you wash your jcowan@reutershealth.com hands thoroughly before going to the toilet. http://www.reutershealth.com --gadicath http://www.ccil.org/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 00:24:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPCBi-0003nA-Nn; Sat, 23 Apr 2005 00:24:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPCBg-0003n5-9C for ltru@megatron.ietf.org; Sat, 23 Apr 2005 00:24:12 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03490 for ; Sat, 23 Apr 2005 00:24:08 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DPC6p-00040Q-CU for ltru@lists.ietf.org; Sat, 23 Apr 2005 06:19:11 +0200 Received: from c-134-88-3.hh.dial.de.ignite.net ([62.134.88.3]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Apr 2005 06:19:11 +0200 Received: from nobody by c-134-88-3.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 23 Apr 2005 06:19:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 23 Apr 2005 06:22:41 +0200 Organization: Lines: 31 Message-ID: <4269CD91.50F4@xyzzy.claranet.de> References: <005901c54074$42479a60$7f1afea9@oemcomputer> <069001c54079$f4581180$4109fea9@sanjose.ibm.com> <4269BA21.7675@xyzzy.claranet.de> <20050423031010.GC4500@skunk.reutershealth.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: c-134-88-3.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: >> what's the difference between the '003 North America' and >> '021 Northern America' ? The 200 should be deleted IIRC. > Northern America is an economic grouping, and refers to > Canada and the U.S. North America is a geographical > grouping, and includes Northern America, Central America, > and the Caribbean. I'm not sure, "economic groupings" shouldn't be registered: | B. UN numeric codes for 'economic groupings' or 'other | groupings' are _not_ defined in the IANA registry and | MUST NOT be used to form language tags. On the page http://unstats.un.org/unsd/methods/m49/m49regin.htm 003 apparently only exists in footnote "b" for 021: | b/ The continent of North America (003) comprises Northern | America (021), Caribbean (029), and Central America (013). Obscure region numbers existing only as footnotes should not be registered, it's too confusing. Another dubious region number is 062 "South-central Asia" vs. "Southern Asia". The UN page first introduces 034 "Southern Asia" and later uses 062 with the same name "Southern Asia". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 08:50:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPK5A-0002aN-LJ; Sat, 23 Apr 2005 08:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPK57-0002Xf-4t for ltru@megatron.ietf.org; Sat, 23 Apr 2005 08:49:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26191 for ; Sat, 23 Apr 2005 08:49:55 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPKEA-0004Pa-TO for ltru@ietf.org; Sat, 23 Apr 2005 08:59:20 -0400 Received: from lns-p19-4-idf-82-65-248-117.adsl.proxad.net ([82.65.248.117] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DPK2I-00019P-MW; Sat, 23 Apr 2005 05:47:03 -0700 Message-Id: <6.2.1.2.2.20050423131448.03690eb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 23 Apr 2005 13:27:18 +0200 To: Frank Ellermann From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: 003 vs. 021 In-Reply-To: <4269CD91.50F4@xyzzy.claranet.de> References: <005901c54074$42479a60$7f1afea9@oemcomputer> <069001c54079$f4581180$4109fea9@sanjose.ibm.com> <4269BA21.7675@xyzzy.claranet.de> <20050423031010.GC4500@skunk.reutershealth.com> <4269CD91.50F4@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org What should be registered is what people identify themselves with. Registrations should result from RFCs updating the BPC 047 by a WG-TAGS the strategy of which should be defined by the IESG under the review of the IAB. Each registration should be supported be three persons of reference authoritative in the area of the registration. jfc On 06:22 23/04/2005, Frank Ellermann said: >John Cowan wrote: > > >> what's the difference between the '003 North America' and > >> '021 Northern America' ? The 200 should be deleted IIRC. > > > Northern America is an economic grouping, and refers to > > Canada and the U.S. North America is a geographical > > grouping, and includes Northern America, Central America, > > and the Caribbean. > >I'm not sure, "economic groupings" shouldn't be registered: > >| B. UN numeric codes for 'economic groupings' or 'other >| groupings' are _not_ defined in the IANA registry and >| MUST NOT be used to form language tags. > >On the page http://unstats.un.org/unsd/methods/m49/m49regin.htm >003 apparently only exists in footnote "b" for 021: > >| b/ The continent of North America (003) comprises Northern >| America (021), Caribbean (029), and Central America (013). > >Obscure region numbers existing only as footnotes should not >be registered, it's too confusing. > >Another dubious region number is 062 "South-central Asia" vs. >"Southern Asia". The UN page first introduces 034 "Southern >Asia" and later uses 062 with the same name "Southern Asia". > > Bye, Frank > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 08:50:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPK5B-0002ag-05; Sat, 23 Apr 2005 08:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPK57-0002Xg-6q for ltru@megatron.ietf.org; Sat, 23 Apr 2005 08:49:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26193 for ; Sat, 23 Apr 2005 08:49:55 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPKEB-0004Pc-DK for ltru@ietf.org; Sat, 23 Apr 2005 08:59:19 -0400 Received: from lns-p19-4-idf-82-65-248-117.adsl.proxad.net ([82.65.248.117] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DPK2J-00019P-SI; Sat, 23 Apr 2005 05:47:04 -0700 Message-Id: <6.2.1.2.2.20050423135722.0379e590@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 23 Apr 2005 14:42:59 +0200 To: Frank Ellermann , ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] BCP 47 In-Reply-To: <42699FA6.CA7@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.com> <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.c om> <6.2.1.2.2.20050423010354.02bc35a0@mail.jefsey.com> <42699FA6.CA7@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 03:06 23/04/2005, Frank Ellermann wrote: >JFC (Jefsey) Morfin wrote: > > > there is no RFC 3066 standard since RFC 3066 is only a BCP > > and not a standard >Finally I'd bet that my idea to go back to standards track >instead of a BCP is "dubious" or worse, but I'd really like >to know why. Are BCPs a dead end, is it impossible to get >rid of them and to return to standards track ? This idea is correct and does not contradict the RFC 3066 bis project. My only opposition to the current Draft is precisely that it does not respect the spirit of the Standard Internet process. Let review this main and first thorny question risen by the Charter. There are three problems discussed by the charter. - the identification of the languages in the Internet standard process (first sentences). - the difficulties of applying RFC 3066 as it is, and the ways to remedy to that. - the filtering solutions. I say that they should be resolved in the following way 1. in having an language identification framework applicable to _every_ Internet Standard Process needs, past and future. This should be accompanied by a letter to the IESG or a part in the Draft to provide further guidance on the Charter revisions. It should document why this brings consistency, stability, security and capacity for Internet standards scalability. This general framework should succeed to RFC 3066 as RFC 047. IMHO as a BCP it should stabilize a WG-TAGS as the maintainer of the subtag registry, the current status would be provided in annex. Being a BCP (which should be a description of real common practices) it can be easily updated by RFC (I suggest every year - as there are RFCs describing the historic status of RFCs); using monthly drafts to keep an accurate status of the subtags (a BCP is not normative but descriptive, so a Draft can be a snapshot of an evolving situation - with a 6 month validity). The advantage is this corresponds to a well defined, stable and acknowledged process. That there are mirrors of RFC everywhere. That an RFC annex is not necessarily the place a browser will parse. Another important advantage is that the WG-TAGS charter is revised every year by the IESG under IAB guidance/review. This permits to adapt to the Internet standard process and to ISO evolution without problem. Another advantage is that each yearly RFC is timestamped (I would say every January 1st). This gives a good historic spine to leave totally open to imaginative thinking the way to address standard evolution question on a per application basis (if a new system starts on today document, they will not care about the past, while the common BCP 047 will keep them consistent with every other application). 2. to evaluate, from the RFC 3066 four years experience, what belongs to the general needs of the Internet standard process, which should go to the general framework and what is specific to which applications. From this to provision in the framework the links to specialised RFCs, to describe the requirement an RFC must match to adequately describe an application language tag, etc. I submit that problems difficult to address in the current Draft way, result from a lack of underlaying framework, and oblige to the "SHOULD", "MUST", etc debate which should only be cases of a framework. 3. to discuss in detail the filtering solution, starting from the objective/target for each application (to the light of the framework and of possible legacies of _that_ application and of its own standardisers evolution strategy) to write the BPC 047 compliant RFC 3066 nth, for each application. Please remember RFC 1958 basic principle: but that principle everything in the Internet may change and solutions must keep this as normal possibility. In the status of the current debate this means two (or more) documents, as described by the charter. 1. a BCP 047 replacement providing a language description framework, also supporting the much needed tag names and including the registry present yearly status. 2. an RFC 3066 bis documenting most of the areas of use of the present RFC 3066 bis (HTML, XML, CLDR, etc.): tags, filters, use of the implicits, 3. on demand additional RFCs by members of this group or others groups documenting the use of language related information in LDAP, Java, MPEG, DNS, OPES, CRC, Internet Architecture, etc. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 17:11:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPRui-0005oZ-7W; Sat, 23 Apr 2005 17:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPRuf-0005oR-SJ for ltru@megatron.ietf.org; Sat, 23 Apr 2005 17:11:41 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25277 for ; Sat, 23 Apr 2005 17:11:39 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050423211110.HXGL8952.mta9.adelphia.net@DEWELL> for ; Sat, 23 Apr 2005 17:11:10 -0400 Message-ID: <01a101c54848$ed01f1e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050420160557.UOZB4900.mta8.adelphia.net@megatron.ietf.org> Date: Sat, 23 Apr 2005 14:10:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA25277 Cc: Subject: [Ltru] Re: hyphen-minus (was: new version posted online) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > If no one objects, I'll remove the restriction to Latin-1 from > description. Variant registrations will be asked to provide a > Description using or transcribed into the Latin script. I don't object. As a reminder, I've restricted the existing entries in the draft registry to Latin-1 characters, and so far nobody has objected to this. The descriptions that appear in ISO standards, together with the corresponding description in the registry, are as follows (warning: UTF-8 ahead): Hangul (Hang=C5=ADl, Hangeul) --> Hangul (Hangeul) Ge=E2=80=98ez --> Ge'ez N=E2=80=99ko --> N'ko Gwich=C2=B4in --> Gwich'in (The character replaced in the last example is actually in Latin-1, but seems not to be the correct character for the purpose.) -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 17:30:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPSD0-0007ek-QJ; Sat, 23 Apr 2005 17:30:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPSCz-0007ef-1v for ltru@megatron.ietf.org; Sat, 23 Apr 2005 17:30:37 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26140 for ; Sat, 23 Apr 2005 17:30:34 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050423213005.CKTJ13270.mta11.adelphia.net@DEWELL> for ; Sat, 23 Apr 2005 17:30:05 -0400 Message-ID: <01a401c5484b$8b73db20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050420160557.UOZB4900.mta8.adelphia.net@megatron.ietf.org> Date: Sat, 23 Apr 2005 14:29:33 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: FWS vs. LWSP (was: new version posted online) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > | Example: one two three > > Some obvious ways to fold this example are: > > | Example: one > | two three > > | Example: one > | two > | three > > Now I use _ for SP in the same examples: > > | Example:_one > | _two__three > > | Example:_one > | _two > | __three These examples seem to imply that multiple spaces *are* preserved by line folding, and thus the examples in Appendix C of the draft: Comment: Use private use codes in preference to the x- singleton for primary language are not correct since they use two spaces instead of one. The draft registry follows the examples in the draft, and also uses two spaces. Does this need to be changed to a single space? (I hope not, since I find two spaces much more readable.) -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 18:26:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPT4d-0004vx-Rl; Sat, 23 Apr 2005 18:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPT4c-0004tA-Eh for ltru@megatron.ietf.org; Sat, 23 Apr 2005 18:26:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00391 for ; Sat, 23 Apr 2005 18:25:59 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPTGV-0002zF-Sg for ltru@ietf.org; Sat, 23 Apr 2005 18:38:21 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j3NMPhAL029303; Sat, 23 Apr 2005 15:25:43 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <2R3ALBKS>; Sat, 23 Apr 2005 15:25:42 -0700 Message-ID: From: "McDonald, Ira" To: "'Doug Ewell'" , LTRU Working Group Subject: RE: [Ltru] Re: hyphen-minus (was: new version posted online) Date: Sat, 23 Apr 2005 15:25:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Doug, I'm confused here. Are you really mixing Latin-1 in plaintext=20 with Unicode via NCRs in the Registry? Latin-1 is only mentioned once in the current LTRU draft, in the change log comment: "o Remove the Latin-1 restriction on the 'Description' field." Latin-1 (ISO 8859 Part 1) is NOT the same thing as "the=20 Latin script" as used in a number of places in the latest=20 LTRU draft (the Latin script includes a larger character repertoire). Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of Doug Ewell > Sent: Saturday, April 23, 2005 5:11 PM > To: LTRU Working Group > Subject: [Ltru] Re: hyphen-minus (was: new version posted online) >=20 >=20 > Addison Phillips wrote: >=20 > > If no one objects, I'll remove the restriction to Latin-1 from > > description. Variant registrations will be asked to provide a > > Description using or transcribed into the Latin script. >=20 > I don't object. As a reminder, I've restricted the existing=20 > entries in > the draft registry to Latin-1 characters, and so far nobody=20 > has objected > to this. >=20 > The descriptions that appear in ISO standards, together with the > corresponding description in the registry, are as follows (warning: > UTF-8 ahead): >=20 > Hangul (Hang=C5=ADl, Hangeul) --> Hangul (Hangeul) > Ge=E2=80=98ez --> Ge'ez > N=E2=80=99ko --> N'ko > Gwich=C2=B4in --> Gwich'in >=20 > (The character replaced in the last example is actually in=20 > Latin-1, but > seems not to be the correct character for the purpose.) >=20 > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 21:15:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPViN-00059N-67; Sat, 23 Apr 2005 21:15:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPViL-00059I-5F for ltru@megatron.ietf.org; Sat, 23 Apr 2005 21:15:13 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08440 for ; Sat, 23 Apr 2005 21:15:10 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DPVdT-0002nn-2y for ltru@lists.ietf.org; Sun, 24 Apr 2005 03:10:11 +0200 Received: from du-001-092.access.de.clara.net ([212.82.227.92]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Apr 2005 03:10:11 +0200 Received: from nobody by du-001-092.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Apr 2005 03:10:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 24 Apr 2005 03:14:18 +0200 Organization: Lines: 36 Message-ID: <426AF2EA.4BB2@xyzzy.claranet.de> References: <20050420160557.UOZB4900.mta8.adelphia.net@megatron.ietf.org> <01a101c54848$ed01f1e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-092.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: quoted-printable Cc: Subject: [Ltru] Re: hyphen-minus X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: = > As a reminder, I've restricted the existing entries in the > draft registry to Latin-1 characters, and so far nobody has > objected to this. Not sure about Addison, but I certainly did, IMHO you or IANA or the future tag reviewer shouldn't be forced to second guess the "official" ISO sources. [pseudo-QP by me] > Hangul (Hang=3DC5=3DAD=ADl, Hangeul) --> Hangul (Hangeul) please use ŭ LATIN SMALL LETTER U WITH BREVE > Ge=3DE2=3D80=3D98ez --> Ge'ez better use ‘ LEFT SINGLE QUOTATION MARK > N=3DE2=3D80=3D99ko --> N'ko better use ’ RIGHT SINGLE QUOTATION MARK > Gwich=3DC2=3DB4in --> Gwich'in better use ´ ACUTE ACCENT > The character replaced in the last example is actually > in Latin-1, but seems not to be the correct character > for the purpose. Excluding the "small u breve" all these examples appear to be errors, let them fix it. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 21:41:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPW7Z-0007Qh-9N; Sat, 23 Apr 2005 21:41:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPW7Y-0007Q6-0b for ltru@megatron.ietf.org; Sat, 23 Apr 2005 21:41:16 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09534 for ; Sat, 23 Apr 2005 21:41:13 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DPW2j-0004Pc-3e for ltru@lists.ietf.org; Sun, 24 Apr 2005 03:36:17 +0200 Received: from du-001-092.access.de.clara.net ([212.82.227.92]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Apr 2005 03:36:17 +0200 Received: from nobody by du-001-092.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Apr 2005 03:36:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 24 Apr 2005 03:36:38 +0200 Organization: Lines: 35 Message-ID: <426AF826.65C3@xyzzy.claranet.de> References: <20050420160557.UOZB4900.mta8.adelphia.net@megatron.ietf.org> <01a401c5484b$8b73db20$030aa8c0@DEWELL> 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: du-001-092.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: FWS vs. LWSP X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > These examples seem to imply that multiple spaces *are* > preserved by line folding Not, that was only a simplification by me, because it didn't matter. In reality you'd match as much as possible against FWS (or LWSP), and then you're free to replace _one_ maximal FWS (or LWSP) by _one_ other FWS (or LWSP). In the case with two adjacent spaces it was one FWS (or LWSP). You could replace it by one other FWS, e.g. SP CRLF SP or CRLF SP SP SP or CRLF SP, the important point is that it has at most one CRLF, and at least one WSP, and if it has CRLF, then it has at least one WSP after the CRLF. For the LWSP case it's very similar, but you can have more than one CRLF, each CRLF followed by at least one WSP. And that's the way how you could get "empty" lines with LWSP, a line with one or more trailing spaces and nothing else. > Does this need to be changed to a single space? No. You can use as much WSP as you like, but at least one. In theory you could also use HT or SP SP SP SP SP SP SP SP - but better stay away from horizontal TABs ;-) > I find two spaces much more readable. Yes, they are nice, Sh*t, the new 2234bis doesn't follow its own recommendation, it says LWSP = *(WSP / CRLF WSP) instead of LWSP = *(WSP / (CRLF WSP)) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 21:45:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPWC3-0007m7-Fh; Sat, 23 Apr 2005 21:45:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPWC2-0007m2-34 for ltru@megatron.ietf.org; Sat, 23 Apr 2005 21:45:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09725 for ; Sat, 23 Apr 2005 21:45:52 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPWNx-00006N-Vq for ltru@ietf.org; Sat, 23 Apr 2005 21:58:15 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3O1jgxG015033; Sat, 23 Apr 2005 21:45:43 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 23 Apr 2005 21:45:42 -0400 Date: Sat, 23 Apr 2005 21:45:42 -0400 From: John Cowan To: "McDonald, Ira" Subject: Re: [Ltru] Re: hyphen-minus (was: new version posted online) Message-ID: <20050424014542.GG4500@skunk.reutershealth.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org McDonald, Ira scripsit: > I'm confused here. Are you really mixing Latin-1 in plaintext > with Unicode via NCRs in the Registry? The entity encoding (charset) is ASCII; the document encoding (on which the NCRs are based) is Unicode; the repertoire is restricted to Latin-1. Those are three different things. -- XQuery Blueberry DOM John Cowan Entity parser dot-com jcowan@reutershealth.com Abstract schemata http://www.reutershealth.com XPointer errata http://www.ccil.org/~cowan Infoset Unicode BOM --Richard Tobin _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 22:02:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPWSR-0001BN-G7; Sat, 23 Apr 2005 22:02:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPWSQ-0001BI-4N for ltru@megatron.ietf.org; Sat, 23 Apr 2005 22:02:50 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10548 for ; Sat, 23 Apr 2005 22:02:47 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DPWNZ-0006Gg-1g for ltru@lists.ietf.org; Sun, 24 Apr 2005 03:57:49 +0200 Received: from du-001-092.access.de.clara.net ([212.82.227.92]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Apr 2005 03:57:49 +0200 Received: from nobody by du-001-092.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Apr 2005 03:57:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 24 Apr 2005 04:01:48 +0200 Organization: Lines: 19 Message-ID: <426AFE0C.D5A@xyzzy.claranet.de> References: <005901c54074$42479a60$7f1afea9@oemcomputer> <069001c54079$f4581180$4109fea9@sanjose.ibm.com> <4269BA21.7675@xyzzy.claranet.de> <20050423031010.GC4500@skunk.reutershealth.com> <4269CD91.50F4@xyzzy.claranet.de> <6.2.1.2.2.20050423131448.03690eb0@mail.jefsey.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: du-001-092.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin wrote: > What should be registered is what people identify themselves > with. No, it should be as the registry draft says. For the region numbers it says (in other words) "anything not covered by a registered 3166-1 alpha-2 CC, excl. the economic and other groupings, as found in the list of valid UN region numbers." My source has no valid 003 under these rules, maybe Doug has a "better" source. Splitting the same continent in different overlapping ways is a fundamentally flawed idea, I certainly hope that my source "wins". North vs. Northern America is a headache for language tags. 3066bis isn't about geography or geology. Show me one language where 003 is really useful, and I shut up. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 22:47:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPX9M-0005Ok-ID; Sat, 23 Apr 2005 22:47:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOns4-00063p-8I for ltru@megatron.ietf.org; Thu, 21 Apr 2005 22:26:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10833 for ; Thu, 21 Apr 2005 22:26:18 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOo3b-0004ZH-5I for ltru@ietf.org; Thu, 21 Apr 2005 22:38:16 -0400 Received: from lns-p19-4-idf-82-65-248-117.adsl.proxad.net ([82.65.248.117] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DOnru-0002cA-Hu for ltru@ietf.org; Thu, 21 Apr 2005 19:26:11 -0700 Message-Id: <6.2.1.2.2.20050422042154.046cfe30@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 22 Apr 2005 04:25:46 +0200 To: "ltru Working Group" From: Jefsey Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - online.fr X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Sat, 23 Apr 2005 22:47:12 -0400 Cc: Subject: [Ltru] Support of JAVA X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I am not a Java developper. I am told there are equivalent problems in Java to support RFC 3066 and to include the script, Java not permitting the use of "-" and "_" in the initial part of the tag? If I am correct the proposed format does not consider/coordinate with Java's needs. This would be the extensibility of the format is limited? Thank you for the comments. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 22:48:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPXAQ-0005R1-MP; Sat, 23 Apr 2005 22:48:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOeLY-0006Re-2F for ltru@megatron.ietf.org; Thu, 21 Apr 2005 12:16:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13106 for ; Thu, 21 Apr 2005 12:16:03 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOeWs-0003T8-33 for ltru@ietf.org; Thu, 21 Apr 2005 12:27:56 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3LGFjeE424062 for ; Thu, 21 Apr 2005 12:15:45 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3LGFiqa230218 for ; Thu, 21 Apr 2005 10:15:44 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3LGFioT013381 for ; Thu, 21 Apr 2005 10:15:44 -0600 Received: from markdavis (sig-9-48-120-132.mts.ibm.com [9.48.120.132]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3LGFhQw013269; Thu, 21 Apr 2005 10:15:44 -0600 Message-ID: <002b01c5468d$5e770a80$84783009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "ltru Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B1678B6@irvmbxw01.quest.com> Subject: Re: [Ltru] New version posted: ready for publication?? Date: Thu, 21 Apr 2005 09:15:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id j3LGFjeE424062 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 23 Apr 2005 22:48:17 -0400 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I didn't get an attachment and there wasn't a link I assume you mean the document at http://inter-locale.com/ID/draft-ietf-ltru-registry-01.html It looks good. I only found some minor stuff. 2.1 [In the ABNF, variant has extra spaces in front.] 2.1.1 [add] All subtags are from 1 to 8 characters in length. 2.2.5 [remove] The maximum length of a variant subtag is eight characters long. 3.1 field =3D field-name *SP ":" field-body CRLF=3D>field =3D field-name *SP = ":" *SP field-body CRLF[Leading spaces shouldn't be considered part of the field-body, for consistency.] Subsequent records represent subtags in the registry. Each record MUST contain the following fields: =3D> Subsequent records represent subtags in the registry. Each of the fields in each rec= ord MUST occur no more than once, unless otherwise noted below. Each record M= UST contain the following fields: 4.1 [some extra you's] Some protocols may force you to give a value for the language tag and th= e 'UND' subtag may be useful when matching language tags in certain situations. =3D> The 'UND' subtag may be necessary when a protocol requires a value for t= he language tag, or when matching language tags in certain situations. The 'MUL' (Multiple) primary language subtag SHOULD NOT be used if the protocol allows you to use multiple languages, as is the case for the Content-Language header in HTTP. =3D> The 'MUL' (Multiple) primary language subtag SHOULD NOT be used whenever= a protocol allows the use of multiple languages, as is the case for the Content-Language header in HTTP. 6. This is a special case of the general problem that anything you send is visible to the receiving party. It is useful to be aware that such concer= ns can exist in some cases. =3D> This is a special case of the general problem that anything sent is visi= ble to the receiving party. It is useful to be aware that such concerns can exist in some cases. Mark =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "ltru Working Group" Sent: Wednesday, April 20, 2005 16:27 Subject: [Ltru] New version posted: ready for publication?? > All, > > I have just posted an updated version of draft-01 editor's copy. This includes all of the edits I'm currently aware, including the less subtle variant ABNF. It has been updated using the new xml2rfc and references th= e latest and greatest IETF process RFCs. > > I'm prepared to submit this, barring errors in the document. > > Question: what issues remain before this document can be considered in = its final form? > > Best Regards, > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > http://www.quest.com > > Chair, W3C Internationalization Core Working Group > http://www.w3.org/International > > Internationalization is not a feature. > It is an architecture. > > > -------------------------------------------------------------------------= --- ---- > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 22:48:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPXAQ-0005RP-RJ; Sat, 23 Apr 2005 22:48:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOfD2-0007Bn-Sb for ltru@megatron.ietf.org; Thu, 21 Apr 2005 13:11:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17987 for ; Thu, 21 Apr 2005 13:11:21 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOfOU-00052t-FO for ltru@ietf.org; Thu, 21 Apr 2005 13:23:15 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3LHBBAa835816 for ; Thu, 21 Apr 2005 13:11:11 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3LHBB7j289440 for ; Thu, 21 Apr 2005 11:11:11 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3LHBBdq001749 for ; Thu, 21 Apr 2005 11:11:11 -0600 Received: from markdavis (sig-9-48-120-132.mts.ibm.com [9.48.120.132]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3LHB9DW001625; Thu, 21 Apr 2005 11:11:10 -0600 Message-ID: <007a01c54695$1d140590$84783009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "Mark Davis" , "Addison Phillips" , "ltru Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B167BF7@irvmbxw01.quest.com> Subject: Re: [Ltru] New version posted: ready for publication?? Date: Thu, 21 Apr 2005 10:11:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id j3LHBBAa835816 X-Spam-Score: 0.0 (/) X-Scan-Signature: c2e58d9873012c90703822e287241385 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 23 Apr 2005 22:48:17 -0400 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org My comments below. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "Mark Davis" ; "Addison Phillips" ; "ltru Working Group" Sent: Thursday, April 21, 2005 09:52 Subject: RE: [Ltru] New version posted: ready for publication?? > That's the document! Sorry I didn't send a link previously. At that poi= nt I was rushing to get to the airport on time. > > Outlook ate the extra carriage returns in your message. Check to see if= I captured your comments correctly. > > Notes follow. > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > -----Original Message----- > > From: Mark Davis [mailto:mark.davis.mark.davis@jtcsv.com] > > Sent: Thursday, April 21, 2005 9:16 AM > > To: Addison Phillips; ltru Working Group > > Subject: Re: [Ltru] New version posted: ready for publication?? > > > > I didn't get an attachment and there wasn't a link I assume you mean = the > > document at > > > > http://inter-locale.com/ID/draft-ietf-ltru-registry-01.html > > > > It looks good. I only found some minor stuff. > > > > > > 2.1 > > [In the ABNF, variant has extra spaces in front.] > [Addison Phillips] > > Space removed. OK > > > > 2.1.1 > > [add] All subtags are from 1 to 8 characters in length. > [Addison Phillips] > > Not sure where you want me to put this. 2.1.1 is the length considerati= ons section and I don't see a particular spot to stick this text. We can put this below the ABNF itself in a note. In the Length considerations, perhaps the following " This limits most tags to a sequence of four subtags (excluding any extensions or private use sequences). " =3D> In practice, this limits most tags to a sequence of four subtags -- and thus a length of 35, because subtags are limited to a length of 8 each (excluding any extensions or private use sequences). > > > > > > 2.2.5 > > [remove] The maximum length of a variant subtag is eight characters long. > [Addison Phillips] > > Done. OK > > > > > > 3.1 > > field =3D field-name *SP ":" field-body CRLF=3D>field =3D field-name = *SP ":" *SP > > field-body CRLF[Leading spaces shouldn't be considered part of the > > field-body, for consistency.] > [Addison Phillips] > > Good catch. Done. OK > > Subsequent records represent subtags in the > > registry. Each record MUST contain the following fields: =3D> Subsequ= ent > > records represent subtags in the registry. Each of the fields in each > > record > > MUST occur no more than once, unless otherwise noted below. Each reco= rd > > MUST > > contain the following fields: > [Addison Phillips] > > Done. OK > > > 4.1 [some extra you's] > > Some protocols may force you to give a value for the language tag an= d the > > 'UND' subtag may be useful when matching language tags in certain > > situations. > > =3D> > > The 'UND' subtag may be necessary when a protocol requires a value f= or > > the > > language tag, or when matching language tags in certain situations. > [Addison Phillips] > > I did a slightly different rewrite: > > Some protocols may require a value for the language tag and the 'UND' subtag may be useful when matching language tags in certain situations. I did a bit more shuffling around, because the sentences was very clumsy. The two clauses are really disconnected, separate reasons for why someone might want to use UND, but the "and" makes them sound like they are suppo= sed to be connected. So I prefer my rewrite. > > > > The 'MUL' (Multiple) primary language subtag SHOULD NOT be used if t= he > > protocol allows you to use multiple languages, as is the case for the > > Content-Language header in HTTP. > > =3D> > > The 'MUL' (Multiple) primary language subtag SHOULD NOT be used whenever > > a > > protocol allows the use of multiple languages, as is the case for the > > Content-Language header in HTTP. > [Addison Phillips] > > Done. Should there be a general warning against using 'MUL'? Something like: OK > > -- > The 'MUL' subtag conveys little useful information: content in multiple languages should individually tag the languages where they appear or otherwise indicate the actual language in preference to the 'MUL' subtag. SURE > -- > > > > 6. > > This is a special case of the general problem that anything you send= is > > visible to the receiving party. It is useful to be aware that such > > concerns > > can exist in some cases. > > =3D> > > This is a special case of the general problem that anything sent is > > visible > > to the receiving party. It is useful to be aware that such concerns c= an > > exist in some cases. > [Addison Phillips] OK > > Done. Will post shortly. > > > > Mark > > > > =E2=80=8EMark > > > > ----- Original Message ----- > > From: "Addison Phillips" > > To: "ltru Working Group" > > Sent: Wednesday, April 20, 2005 16:27 > > Subject: [Ltru] New version posted: ready for publication?? > > > > > > > All, > > > > > > I have just posted an updated version of draft-01 editor's copy. Th= is > > includes all of the edits I'm currently aware, including the less sub= tle > > variant ABNF. It has been updated using the new xml2rfc and reference= s the > > latest and greatest IETF process RFCs. > > > > > > I'm prepared to submit this, barring errors in the document. > > > > > > Question: what issues remain before this document can be considered= in > > its > > final form? > > > > > > Best Regards, > > > > > > Addison > > > > > > Addison P. Phillips > > > Globalization Architect, Quest Software > > > http://www.quest.com > > > > > > Chair, W3C Internationalization Core Working Group > > > http://www.w3.org/International > > > > > > Internationalization is not a feature. > > > It is an architecture. > > > > > > > > > > > > > > > -----------------------------------------------------------------------= --- > > -- > > ---- > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > -------------------------------------------------------------------------= --- ---- > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 22:48:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPXAR-0005Rn-05; Sat, 23 Apr 2005 22:48:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOfgt-00032W-MT for ltru@megatron.ietf.org; Thu, 21 Apr 2005 13:42:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20853 for ; Thu, 21 Apr 2005 13:42:12 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOfsL-0005wm-Gt for ltru@ietf.org; Thu, 21 Apr 2005 13:54:06 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3LHg4Lg486082 for ; Thu, 21 Apr 2005 13:42:04 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3LHg3qa228926 for ; Thu, 21 Apr 2005 11:42:04 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3LHg3if023927 for ; Thu, 21 Apr 2005 11:42:03 -0600 Received: from markdavis (sig-9-48-120-132.mts.ibm.com [9.48.120.132]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3LHg2Z3023871; Thu, 21 Apr 2005 11:42:03 -0600 Message-ID: <00ad01c54699$6d64cb70$84783009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "Mark Davis" , "Addison Phillips" , "ltru Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B167BF7@irvmbxw01.quest.com> Subject: Re: [Ltru] New version posted: ready for publication?? Date: Thu, 21 Apr 2005 10:42:01 -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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 23 Apr 2005 22:48:17 -0400 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Oh, almost forgot. UND, MUL and FR should use recommended [ISO 639] casing (lowercase) in the following: > The 'UND' (Undetermined) primary language subtag SHOULD NOT be used to label content, even if the language is unknown. Omitting the tag is preferred. Some protocols may force you to give a value for the language tag and the 'UND' subtag may be useful when matching language tags in certain situations. >The 'MUL' (Multiple) primary language subtag SHOULD NOT be used if the protocol allows you to use multiple languages, as is the case for the Content-Language header in HTTP. > C'est la vie. in _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 22:48:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPXAR-0005SB-4q; Sat, 23 Apr 2005 22:48:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOg8i-0005yu-AW for ltru@megatron.ietf.org; Thu, 21 Apr 2005 14:11:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23264 for ; Thu, 21 Apr 2005 14:10:59 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOgKA-0006eq-BA for ltru@ietf.org; Thu, 21 Apr 2005 14:22:51 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3LIAmua421278 for ; Thu, 21 Apr 2005 14:10:48 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3LIAmqa208648 for ; Thu, 21 Apr 2005 12:10:48 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3LIAlg3006832 for ; Thu, 21 Apr 2005 12:10:47 -0600 Received: from markdavis (sig-9-48-120-132.mts.ibm.com [9.48.120.132]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3LIAkKL006740; Thu, 21 Apr 2005 12:10:47 -0600 Message-ID: <00ca01c5469d$71129460$84783009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "ltru Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B20967F@irvmbxw01.quest.com> Subject: Re: [Ltru] New version posted: ready for publication?? Date: Thu, 21 Apr 2005 11:10:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j3LIAmua421278 X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 23 Apr 2005 22:48:17 -0400 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "ltru Working Group" Sent: Thursday, April 21, 2005 10:59 Subject: RE: [Ltru] New version posted: ready for publication?? > See below. Excised excess text. > > Addison > > Addison P. Phillips > Globalization Architect, Quest Software > Chair, W3C Internationalization Core Working Group > > Internationalization is not a feature. > It is an architecture. > > > > > > > > > > > 2.1.1 > > > > [add] All subtags are from 1 to 8 characters in length. > > > [Addison Phillips] > > > > > > Not sure where you want me to put this. 2.1.1 is the length > > considerations > > section and I don't see a particular spot to stick this text. > > > > We can put this below the ABNF itself in a note. In the Length > > considerations, perhaps the following > > " This limits most tags to a sequence of four subtags (excluding any > > extensions or private use sequences). " > > =3D> > > In practice, this limits most tags to a sequence of four subtags -- = and > > thus a length of 35, because subtags are limited to a length of 8 eac= h > > (excluding any extensions or private use sequences). > [Addison Phillips] > > There were a couple of problems with that text (it seemed to suggest th= at extensions and private use were not limited to 8 character subtags), so I put: > > In particular, variant subtags SHOULD be used only with their recommended prefix. In practice, this limits most tags to a sequence of four subtags, and > thus a length of 35 (excluding any extensions or private use sequences)= , because subtags are limited to a length of eight characters. See for more information on selecting the most appropriate Language Tag. Good > > > > > > > > > 4.1 [some extra you's] > > > > Some protocols may force you to give a value for the language ta= g and > > the > > > > 'UND' subtag may be useful when matching language tags in certain > > > > situations. > > > > =3D> > > > > The 'UND' subtag may be necessary when a protocol requires a val= ue > > for > > > > the > > > > language tag, or when matching language tags in certain situation= s. > > > [Addison Phillips] > > > > > > I did a slightly different rewrite: > > > > > > Some protocols may require a value for the language tag and the 'UN= D' > > subtag may be useful when matching language tags in certain situation= s. > > > > I did a bit more shuffling around, because the sentences was very clumsy. > > The two clauses are really disconnected, separate reasons for why someone > > might want to use UND, but the "and" makes them sound like they are > > supposed > > to be connected. So I prefer my rewrite. > [Addison Phillips] > > I hear you. I changed it to: > > The 'UND' (Undetermined) primary language subtag SHOULD NOT be used = to label content, even if the language is unknown. Omitting the tag is preferred. Some protocols may require a value for the language tag. The 'UND' subtag may also be useful when matching language tags in certain situations. Good > > > > > > > > > > > > > > -- > > > The 'MUL' subtag conveys little useful information: content in multiple > > languages should individually tag the languages where they appear or > > otherwise indicate the actual language in preference to the 'MUL' subtag. > > SURE Good. > > > > > -- > [Addison Phillips] > > Inserted. > > > > > > -------------------------------------------------------------------------= --- ---- > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 22:48:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPXAR-0005SZ-AA; Sat, 23 Apr 2005 22:48:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOgtk-0002zr-Eu for ltru@megatron.ietf.org; Thu, 21 Apr 2005 14:59:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26602 for ; Thu, 21 Apr 2005 14:59:34 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOh5B-0007gz-PT for ltru@ietf.org; Thu, 21 Apr 2005 15:11:28 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j3LIxOua443428 for ; Thu, 21 Apr 2005 14:59:24 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3LIxO7j363596 for ; Thu, 21 Apr 2005 12:59:24 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j3LIxNxc007070 for ; Thu, 21 Apr 2005 12:59:23 -0600 Received: from markdavis ([9.48.113.255]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j3LIxL3C006980; Thu, 21 Apr 2005 12:59:23 -0600 Message-ID: <012401c546a4$3a644d80$84783009@sanjose.ibm.com> From: "Mark Davis" To: "Misha Wolf" , "ltru Working Group" References: <1987416CA83AC7499AC772F92E2DBF7803956C70@LONSMSXM02.emea.ime.reuters.com> Subject: Re: [Ltru] New version posted: ready for publication?? Date: Thu, 21 Apr 2005 11:59:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j3LIxOua443428 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 23 Apr 2005 22:48:17 -0400 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org My suggestion: The 'UND' (Undetermined) primary language subtag SHOULD NOT be used in language tags to label content, even if the language is unknown. Omitting the tag is preferred. The 'UND' subtag may be needed for protocols that require a language tag to be provided. The 'UND' subtag may also be useful when matching language tags in certain situations. =E2=80=8EMark ----- Original Message -----=20 From: "Misha Wolf" To: "ltru Working Group" Sent: Thursday, April 21, 2005 11:51 Subject: RE: [Ltru] New version posted: ready for publication?? We're getting there :-) I think I'm clear why 'UND' is referred to below sometimes as a tag and sometimes as a subtag. Will the reader be equally clear? Thanks, Misha The 'UND' (Undetermined) primary language subtag SHOULD NOT be used to label content, even if the language is unknown. Omitting the tag is preferred. The 'UND' tag may be useful for protocols that require a language tag to be provided. The 'UND' subtag may also be useful when matching language tags in certain situations. ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 23:06:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPXS2-0007LC-Ck; Sat, 23 Apr 2005 23:06:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPXRz-0007L7-Kp for ltru@megatron.ietf.org; Sat, 23 Apr 2005 23:06:28 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15940 for ; Sat, 23 Apr 2005 23:06:24 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DPXMp-0001sS-E8 for ltru@lists.ietf.org; Sun, 24 Apr 2005 05:01:07 +0200 Received: from du-001-092.access.de.clara.net ([212.82.227.92]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Apr 2005 05:01:07 +0200 Received: from nobody by du-001-092.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Apr 2005 05:01:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 24 Apr 2005 05:02:49 +0200 Organization: Lines: 65 Message-ID: <426B0C59.3E10@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.com> <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.c om> <6.2.1.2.2.20050423010354.02bc35a0@mail.jefsey.com> <42699FA6.CA7@xyzzy.claranet.de> <6.2.1.2.2.20050423135722.0379e590@mail.jefsey.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: du-001-092.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: BCP 47 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin wrote: > This should be accompanied by a letter to the IESG The only letter to the IESG I foresee at the moment is Randy's or Martin's letter asking for another last call. That's strictly their business. Of course you're free to write your own letter to the IESG. > IAB guidance/review The IAB and language tags ? I really don't think so. > Another advantage is that each yearly RFC is timestamped The draft registry has a timestamp near line two. as specified in chapter 3.1 of the registry draft. Each entry has its own timestamp Added (and Deprecated if applicable). BTW, the ABNF in 3.1 is a layout mess, the main ABNF is much nicer. > evaluate, from the RFC 3066 four years experience, what > belongs to the general needs of the Internet standard > process That's trivial, DO NOT ABUSE ISO 3166-1 ALPHA-2 CODES OR DIE. Bang, 3066 is dead after CS (for those who want stable tags). > to discuss in detail the filtering solution, starting from > the objective/target for each application Are you talking about matching ? Now where's the WG charter on Addison's page ? Trying , no, it's No "filter", on this page, only "match". > write the BPC 047 compliant RFC 3066 nth, for each > application. There's only one registry, how applications use it should be documented in the corresponding manuals. > Please remember RFC 1958 basic principle "Exponential growth", I refuse to read the rest of this FYI written 1996. I'm a big fan of texts like RfC 1591, but not every FYI. > everything in the Internet may change and solutions must keep > this as normal possibility. Yes, in the case of 3066 and 3066bis we've seen this for the problem of ISO 3166-1 alpha-2 codes. And after Unicode is now used everywhere we need scripts to structure this uniform mass. . > on demand additional RFCs by members of this group or others BTW, you announced a draft for about mid-April, are you still working on it, or have you dropped the idea ? So far Bruce's draft is the only alternative for those who need scripts. Not counting some unpublished 3066-registrations like the MO-stuff. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 23 23:18:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPXdC-00008T-3a; Sat, 23 Apr 2005 23:18:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPXd9-00008L-HY for ltru@megatron.ietf.org; Sat, 23 Apr 2005 23:17:59 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18504 for ; Sat, 23 Apr 2005 23:17:56 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DPXYO-0002Ts-Fb for ltru@lists.ietf.org; Sun, 24 Apr 2005 05:13:04 +0200 Received: from du-001-092.access.de.clara.net ([212.82.227.92]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Apr 2005 05:13:04 +0200 Received: from nobody by du-001-092.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Apr 2005 05:13:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 24 Apr 2005 05:17:39 +0200 Organization: Lines: 6 Message-ID: <426B0FD3.439C@xyzzy.claranet.de> References: <005901c54074$42479a60$7f1afea9@oemcomputer> <069001c54079$f4581180$4109fea9@sanjose.ibm.com> <4269BA21.7675@xyzzy.claranet.de> <20050423031010.GC4500@skunk.reutershealth.com> <4269CD91.50F4@xyzzy.claranet.de> <6.2.1.2.2.20050423131448.03690eb0@mail.jefsey.com> <426AFE0C.D5A@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-092.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > Show me one language where 003 is really useful, and I shut up. apa-003. Sigh. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 01:55:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPa5B-0007zM-S8; Sun, 24 Apr 2005 01:55:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPa5A-0007z8-9X for ltru@megatron.ietf.org; Sun, 24 Apr 2005 01:55:04 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25381 for ; Sun, 24 Apr 2005 01:55:02 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050424055432.TJPJ17140.mta10.adelphia.net@DEWELL> for ; Sun, 24 Apr 2005 01:54:32 -0400 Message-ID: <01d901c54892$06b864e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050420160557.UOZB4900.mta8.adelphia.net@megatron.ietf.org> Date: Sat, 23 Apr 2005 22:54:05 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: New registry with Suppress_Script X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > Thanks. How do you want to handle missing Suppress-Script > entries ? I risk to propose Latn for fy, li, and oc, but > discussing this here could be messy. A temporary list of > languages known to have no or more than one script could > help to fill the gaps. Well, sure, and I could add other Latin-only languages like Corsican and Hawaiian and Walloon. I could also point out that yi (Yiddish) has a Suppress-Script of Hebr, but its alias ji does not, even though other canonical/alias pairs like id/in and he/iw (Hebrew) do have the Suppress-Script for both subtags. But that's one of the major problems with Suppress-Script. The sets are open-ended and subject to controversy, and there is no widely accepted authority for this information. Erkki Kolehmainen has also pointed out that Moldavian (listed with a Suppress-Script of Latn) formerly used a Cyrillic orthography. Who is to say whether this usage is recent enough to change the "default"? What if the changeover had happened two years ago? To answer Frank's question, Suppress-Script entries are intended to be added and removed via the registration process (see Section 3.3 of draft-01). During this initial development stage, we need to have some type of reference work to point to, and a Real Process for additions and deletions. We can't just raise our hands and yell out "Add this! Remove that!" as though we were at some sort of rural auction. Notice I didn't "silently" add the entries I mentioned in the first paragraph above, even though I doubt anyone would argue with them. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 03:49:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPbsF-0004Pn-RS; Sun, 24 Apr 2005 03:49:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPbsE-0004Pf-JY for ltru@megatron.ietf.org; Sun, 24 Apr 2005 03:49:50 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21815 for ; Sun, 24 Apr 2005 03:49:48 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050424074918.MEDV4191.mta13.adelphia.net@DEWELL> for ; Sun, 24 Apr 2005 03:49:18 -0400 Message-ID: <01de01c548a1$efde8780$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: Subject: Re: [Ltru] Re: hyphen-minus (was: new version posted online) Date: Sun, 24 Apr 2005 00:47:58 -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 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org McDonald, Ira wrote: > I'm confused here. Are you really mixing Latin-1 in plaintext > with Unicode via NCRs in the Registry? John answered this pretty well, but no, I haven't mixed anything up. The registry is made up of Unicode characters; all except the Basic Latin (ASCII) characters are represented as NCRs; the current version is limited in repertoire to Latin-1 (U+0000 through U+00FF). > Latin-1 is only mentioned once in the current LTRU draft, > in the change log comment: > > "o Remove the Latin-1 restriction on the 'Description' field." Limiting the repertoire to Latin-1 is something I've done in the current draft registry, not necessarily a requirement of the draft. Frank has since asked for the ISO-based descriptions NOT to be arbitrarily restricted to Latin-1; anyone else? > Latin-1 (ISO 8859 Part 1) is NOT the same thing as "the > Latin script" as used in a number of places in the latest > LTRU draft (the Latin script includes a larger character > repertoire). I do understand this distinction. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ Individual member, Unicode Consortium _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 04:35:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPcaK-0002MN-Aj; Sun, 24 Apr 2005 04:35:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPcaD-0002LG-AZ for ltru@megatron.ietf.org; Sun, 24 Apr 2005 04:35:17 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27887 for ; Sun, 24 Apr 2005 04:35:14 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050424083445.UYBW17140.mta10.adelphia.net@DEWELL> for ; Sun, 24 Apr 2005 04:34:45 -0400 Message-ID: <025901c548a8$5868dca0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org> Date: Sun, 24 Apr 2005 01:33:50 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 (was: Moving Forward) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > BTW, what's the difference between the '003 North America' and > '021 Northern America' ? John Cowan replied: > Northern America is an economic grouping, and refers to Canada and > the U.S. North America is a geographical grouping, and includes > Northern America, Central America, and the Caribbean. I disagree that 021 Northern America is an "economic grouping." According to the UN page, it comprises Bermuda, Greenland, and St. Pierre and Miquelon as well as Canada and the U.S. It is listed with the geographical codes, not the economic codes. Frank responded: > I'm not sure, "economic groupings" shouldn't be registered: > > | B. UN numeric codes for 'economic groupings' or 'other > | groupings' are _not_ defined in the IANA registry and > | MUST NOT be used to form language tags. Again, the criterion was that the UN codes listed under the heading "Geographical region and composition" were in, on the basis that they are relevant to regional variations in language, while those listed under "Selected economic and other groupings" were out. > On the page http://unstats.un.org/unsd/methods/m49/m49regin.htm > 003 apparently only exists in footnote "b" for 021: > > | b/ The continent of North America (003) comprises Northern > | America (021), Caribbean (029), and Central America (013). > > Obscure region numbers existing only as footnotes should not > be registered, it's too confusing. I can understand the position that 003 doesn't belong since it is only listed in a footnote and not in the code list per se. Again, I request that we use objective criteria for allowing and forbidding codes, not subjective labels like "obscure" and "dubious." If we can come up with (a) a tagging need for 003 that isn't met by 021 and (2) a tagging need for 021 that isn't met by 003, we should admit both codes. They're not hurting anything, although the presence of both might cause some confusion. > Another dubious region number is 062 "South-central Asia" vs. > "Southern Asia". The UN page first introduces 034 "Southern > Asia" and later uses 062 with the same name "Southern Asia". I had never even noticed 034. The UN list was apparently updated on 2005-01-06, and I did not notice the change or have WatchThatPage set to watch it. Obviously only one of these codes, 034 and 062, can be correct, and whichever one is correct does now stand for "Southern Asia" and not "South-central Asia" as it previously did. Back in the original message, Frank wrote: > The 200 should be deleted IIRC. I don't remember any consensus for doing this, though I could be wrong. (Randy?) IIRC we did have consensus to delete 172. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 04:41:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPcgG-0002y9-32; Sun, 24 Apr 2005 04:41:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPcgE-0002y4-P2 for ltru@megatron.ietf.org; Sun, 24 Apr 2005 04:41:30 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28191 for ; Sun, 24 Apr 2005 04:41:28 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050424084058.MMKL4191.mta13.adelphia.net@DEWELL> for ; Sun, 24 Apr 2005 04:40:58 -0400 Message-ID: <026601c548a9$32052cc0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050424025309.ZNTK11382.mta7.adelphia.net@megatron.ietf.org> Date: Sun, 24 Apr 2005 01:39:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA28191 Cc: Subject: [Ltru] Re: hyphen-minus X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> As a reminder, I've restricted the existing entries in the >> draft registry to Latin-1 characters, and so far nobody has >> objected to this. > > Not sure about Addison, but I certainly did, IMHO you or IANA > or the future tag reviewer shouldn't be forced to second guess > the "official" ISO sources. > > [pseudo-QP by me] > > Hangul (Hang=3DC5=3DAD=C2=ADl, Hangeul) --> Hangul (Hangeul) > > please use ŭ LATIN SMALL LETTER U WITH BREVE > > > Ge=3DE2=3D80=3D98ez --> Ge'ez > > better use ‘ LEFT SINGLE QUOTATION MARK > > > N=3DE2=3D80=3D99ko --> N'ko > > better use ’ RIGHT SINGLE QUOTATION MARK > > > Gwich=3DC2=3DB4in --> Gwich'in > > better use ´ ACUTE ACCENT What does everyone think about this? If no real consensus on this emerges by next weekend, I'll put the non-Latin-1 characters back as indicated. Frank has a good point about second-guessing the standards, although the transformation is deterministic and not based on judgment. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 05:43:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPdeI-0000rl-35; Sun, 24 Apr 2005 05:43:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPdeE-0000rV-Rg for ltru@megatron.ietf.org; Sun, 24 Apr 2005 05:43:31 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02631 for ; Sun, 24 Apr 2005 05:43:27 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DPdZE-0000Ko-Rj for ltru@lists.ietf.org; Sun, 24 Apr 2005 11:38:20 +0200 Received: from du-001-092.access.de.clara.net ([212.82.227.92]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Apr 2005 11:38:20 +0200 Received: from nobody by du-001-092.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Apr 2005 11:38:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 24 Apr 2005 11:28:11 +0200 Organization: Lines: 38 Message-ID: <426B66AA.4580@xyzzy.claranet.de> References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org> <025901c548a8$5868dca0$030aa8c0@DEWELL> 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: du-001-092.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > I disagree that 021 Northern America is an "economic > grouping." ACK, 021 is okay. > I request that we use objective criteria for allowing and > forbidding codes, not subjective labels like "obscure" and > "dubious." So what are your objective criteria to include 003 ? There's a table starting in line 149 above "001 world" and ending in line 322 below "061 Polynesia". The next table "Selected economic and other groupings" isn't what we want. Another table starts in line 382, its first region is "002 Africa", near line 2534 within this table the "Developed and developing regions" begin. The last region above the h3-header is "876 Wallis and Futuna Islands". 003 is only mentioned in a footnote at the moment. Maybe they found that 419 makes more sense, it certainly does for me. Please don't argue with Navassa Island, it's uninhabited, and it belongs to UM. Guantanamo Bay, maybe apa-003, what else ? Oh no, is this about the Virgin Islands ? Major havoc for many confused users trying 003 instead of 021 or vice versa only for the Virgin Islands ? They could use en-029, en-VI, or en-VG :-( While we're at it, how do you exclude region numbers covered by ISO 3166-1 country codes ? Addison proposed to add the numbers to the codes somehow, so that a future tag reviewer can do his "same piece of land" magic when necessary. I somehow doubt that ISO and the UN are always in perfect synchronization, not only for the three wellknown exceptions TW, 830, and 833. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 07:03:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPetp-0007uV-VL; Sun, 24 Apr 2005 07:03:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPeto-0007uQ-Fi for ltru@megatron.ietf.org; Sun, 24 Apr 2005 07:03:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07413 for ; Sun, 24 Apr 2005 07:03:37 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPf5p-00041t-1Z for ltru@ietf.org; Sun, 24 Apr 2005 07:16:06 -0400 Received: from lns-p19-2-idf-82-251-121-211.adsl.proxad.net ([82.251.121.211] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DPetl-0001OE-DE; Sun, 24 Apr 2005 04:03:37 -0700 Message-Id: <6.2.1.2.2.20050424113019.035121f0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 24 Apr 2005 12:26:50 +0200 To: Frank Ellermann , ltru@ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: BCP 47 In-Reply-To: <426B0C59.3E10@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.com> <634978A7DF025A40BFEF33EB191E13BC0B209B3C@irvmbxw01.quest.c om> <6.2.1.2.2.20050423010354.02bc35a0@mail.jefsey.com> <42699FA6.CA7@xyzzy.claranet.de> <6.2.1.2.2.20050423135722.0379e590@mail.jefsey.com> <426B0C59.3E10@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 05:02 24/04/2005, Frank Ellermann wrote: >BTW, you announced a draft for about mid-April, are you still >working on it, or have you dropped the idea ? So far Bruce's >draft is the only alternative for those who need scripts. Not >counting some unpublished 3066-registrations like the MO-stuff. Dear Frank, the old internet leaks everywhere, suffering from scalability (this is a normal standard growth phase). Working on four matters (CRCs, IPv6 deployment/routing, Multilingual Internet and WSIS) and operating daily registry services shows me the much needed innovative consistency of the propositions to make today. This calls for a lot of parallel thinking, work and agreements ... and time (only 48 hours a day). The current Draft is an acceptable beginning for the second kind of documents planned by the Charter, addressing the specific needs of XML and possibly (undocumented) of CLDR by the people in charge of their specifications. I hoped they understood that from Randy's allusion to the Charters thorny points still to discuss, but I give up hoping: I sent a basic review Addison requested and joked at; I sent a complete review of Draft which was supposed to result in questions by Randy and which was just partly commented once. All this is obviously good material for an appeal, but it would be certainly better to discuss these issues within the WG. The problem is that IETF is not interested in multilingualism and that most of the members of this WG perceive it through the low layer internationalisation issues. The first priority would then be to attract in this WG all those who will block the Draft during the Last Call. I certainly prepare a Draft, but I have a practical work load problem as the program my working groups are engaged in is large. It plans several RFCs for information for Tunis. So, it can only be consistent with three other efforts with long texts for me to write in English. I hope I am finished with them by the end of the week. The detailed scope of the Draft is ready (documented in part in my mail) and some parts completed. But I continue to think that such a Draft would be unnecessary should Randy start a debate on the Charter thorny points, leading to a review of the whole language tags framework. But, IMHO, attracting before the future Last Call opponents would be advisable. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 12:48:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPkHD-0005AK-65; Sun, 24 Apr 2005 12:48:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPkHB-0005AF-TD for ltru@megatron.ietf.org; Sun, 24 Apr 2005 12:48:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02104 for ; Sun, 24 Apr 2005 12:48:06 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPkTF-0003Er-Ml for ltru@ietf.org; Sun, 24 Apr 2005 13:00:38 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3OGln84018116; Sun, 24 Apr 2005 12:47:49 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 24 Apr 2005 12:47:48 -0400 Date: Sun, 24 Apr 2005 12:47:47 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: 003 vs. 021 (was: Moving Forward) Message-ID: <20050424164747.GB26135@skunk.reutershealth.com> References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org> <025901c548a8$5868dca0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <025901c548a8$5868dca0$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell scripsit: > > Northern America is an economic grouping, and refers to Canada and > > the U.S. North America is a geographical grouping, and includes > > Northern America, Central America, and the Caribbean. > > I disagree that 021 Northern America is an "economic grouping." > According to the UN page, it comprises Bermuda, Greenland, and St. > Pierre and Miquelon as well as Canada and the U.S. It is listed with > the geographical codes, not the economic codes. Yeah, you're right. I was writing in haste. > I can understand the position that 003 doesn't belong since it is only > listed in a footnote and not in the code list per se. Again, I request > that we use objective criteria for allowing and forbidding codes, not > subjective labels like "obscure" and "dubious." I'm beginning to wonder just how authoritative that page really is. -- If you have ever wondered if you are in hell, John Cowan it has been said, then you are on a well-traveled http://www.ccil.org/~cowan road of spiritual inquiry. If you are absolutely http://www.reutershealth.com sure you are in hell, however, then you must be jcowan@reutershealth.com on the Cross Bronx Expressway. --Alan Feuer, NYTimes, 2002-09-20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 14:37:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPlyZ-0006GL-M8; Sun, 24 Apr 2005 14:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPlyY-0006GG-Nl for ltru@megatron.ietf.org; Sun, 24 Apr 2005 14:37:02 -0400 Received: from mta10.adelphia.net (mta10.adelphia.net [68.168.78.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10413 for ; Sun, 24 Apr 2005 14:37:00 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050424183630.LJQM17140.mta10.adelphia.net@DEWELL> for ; Sun, 24 Apr 2005 14:36:30 -0400 Message-ID: <001801c548fb$e025ec20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050424160329.SAMF17200.mta1.adelphia.net@megatron.ietf.org> Date: Sun, 24 Apr 2005 11:31:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA10413 Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> I request that we use objective criteria for allowing and >> forbidding codes, not subjective labels like "obscure" and >> "dubious." > > So what are your objective criteria to include 003 ? There's > a table starting in line 149 above "001 world" and ending in > line 322 below "061 Polynesia". > > The next table "Selected economic and other groupings" isn't > what we want. Another table starts in line 382, its first > region is "002 Africa", near line 2534 within this table the > "Developed and developing regions" begin. The last region > above the h3-header is "876 Wallis and Futuna Islands". > > 003 is only mentioned in a footnote at the moment. Maybe they > found that 419 makes more sense, it certainly does for me. I think you have an excellent point. What we really need is a single, normative text file that lists all the codes, without footnotes. Lacking that, I suppose I could write to statistics@un.org and see if they can tell me the "official" status of 003 and 021. > Please don't argue with Navassa Island, it's uninhabited, and > it belongs to UM. Guantanamo Bay, maybe apa-003, what else ? I don't have any desire to argue over Navassa Island. To me it is the same as anyplace else: there is either a code for it, and we use it, or there is none, and we use some other code that encompasses it. It doesn't take long, in discussions about the coverage of ISO 3166-1 and decisions made in its creation, for somebody to point scornfully at codes like BV and HM, which represent uninhabited areas. My opinion is that these ISO 3166-1 codes are just like any others: they exist, so we allow them in language tags. Guant=C3=A1namo Bay is physically part of Cuba and populated entirely by = U.S. military personnel. If there really is a language variation specific to this naval base, such that neither en-US nor es-CU nor any similar combination is accurate, then ietf-languages could discuss the best way to code it. > Oh no, is this about the Virgin Islands ? Major havoc for many > confused users trying 003 instead of 021 or vice versa only for > the Virgin Islands ? They could use en-029, en-VI, or en-VG :-( This is turning into quite a red herring. Allowing UN numeric codes for macrogeographic regions does introduce alternative ways to tag certain data. Here, look, I have some text in a sort of pan-Latin-American flavor of Spanish, probably from a border region of Honduras. Do I tag this as es-HN, es-013, es-419, es-019, or just plain es? The answer is, none of these is incorrect. That does not invalidate the premise of using macrogeographical codes, and IMHO it does not cause "major havoc.". > While we're at it, how do you exclude region numbers covered by > ISO 3166-1 country codes ? Addison proposed to add the numbers > to the codes somehow, so that a future tag reviewer can do his > "same piece of land" magic when necessary. I don't follow this. I would be surprised if Addison supported "adding the numbers to the codes" in the way you describe; perhaps a quote or reference to the archives would help me. > I somehow doubt that > ISO and the UN are always in perfect synchronization, not only > for the three wellknown exceptions TW, 830, and 833. I am sure you are right. I am not sure what the point is. We're using codes from internationally accepted authorities, to avoid placing ourselves or ietf-languages in the role of geopolitical expert. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 15:02:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPmNV-00013J-KZ; Sun, 24 Apr 2005 15:02:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPmNU-00013E-2a for ltru@megatron.ietf.org; Sun, 24 Apr 2005 15:02:48 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12978 for ; Sun, 24 Apr 2005 15:02:46 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050424190216.PYOQ8952.mta9.adelphia.net@DEWELL> for ; Sun, 24 Apr 2005 15:02:16 -0400 Message-ID: <002d01c548ff$538df600$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 24 Apr 2005 11:56:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA12978 Cc: Subject: [Ltru] Miscellaneous registry details X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I've been informed that the available reference materials on record-jar format consider the percent-percent line (%%) to be a record *separator*, not a delimiter or terminator. Therefore, the %% lines at the beginning and end of the registry should be deleted, making the File-Date record the first line of the file. Also, the latest draft replaces the underscore in record names with a hyphen (thus File-Date, Recommended-Prefix, and Suppress-Script). This will be reflected in the next registry. And in my earlier message, I agreed to follow Frank's idea of copying the descriptions verbatim from ISO standards, including the use of non-Latin-1 characters and including the mysterious acute accent in Gwich=C2=B4in. Should any of these items be made into tickets in RT? If not, then I propose making these changes in the draft registry next weekend (April 30-May 1), or sooner if there is rough consensus to do them, or not at all if there is consensus not to do them. "Consensus" in this case would apply to each item individually. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 15:08:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPmSX-0001X9-1e; Sun, 24 Apr 2005 15:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPmSV-0001W3-H8 for ltru@megatron.ietf.org; Sun, 24 Apr 2005 15:07:59 -0400 Received: from mta13.adelphia.net (mta13.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13710 for ; Sun, 24 Apr 2005 15:07:57 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050424190724.BUPE4191.mta13.adelphia.net@DEWELL> for ; Sun, 24 Apr 2005 15:07:24 -0400 Message-ID: <003301c54900$06bb6820$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 24 Apr 2005 12:01:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Open tickets on initial registry X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org According to RT, the following open tickets still exist for the initial-registry project: 875 should initial registry contents be made into an internet-draft? 878 should the initial registry contents i-d be published as an RFC? Did we ever reach a conclusion on these two related items? My opinion is NO on the second (878). 897 change canonical values to match ISO 3166:1998 for region subtags withdrawn from ISO 3166 after 1988 I think we already agreed to this. Can it be resolved? 900 remove region subtag 200 Judging from the recent exchange involving Frank, we still have not decided what to do about this. I'd prefer not to have this special-case exception to the rules. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 16:37:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPnrP-0001Ul-9F; Sun, 24 Apr 2005 16:37:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPnrO-0001Ug-43 for ltru@megatron.ietf.org; Sun, 24 Apr 2005 16:37:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20456 for ; Sun, 24 Apr 2005 16:37:43 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPo3U-0005t6-1V for ltru@ietf.org; Sun, 24 Apr 2005 16:50:17 -0400 Received: from lns-p19-2-idf-82-251-121-211.adsl.proxad.net ([82.251.121.211] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DPnrK-0002t1-43; Sun, 24 Apr 2005 13:37:42 -0700 Message-Id: <6.2.1.2.2.20050424194401.0379b720@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 24 Apr 2005 19:44:51 +0200 To: John Cowan , Doug Ewell From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: 003 vs. 021 (was: Moving Forward) In-Reply-To: <20050424164747.GB26135@skunk.reutershealth.com> References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org> <025901c548a8$5868dca0$030aa8c0@DEWELL> <20050424164747.GB26135@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 18:47 24/04/2005, John Cowan wrote: >I'm beginning to wonder just how authoritative that page really is. Please define "authoritative" if you wish to address this point. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 17:10:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPoNT-0004SG-Vi; Sun, 24 Apr 2005 17:10:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPoNS-0004SB-Gv for ltru@megatron.ietf.org; Sun, 24 Apr 2005 17:10:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22539 for ; Sun, 24 Apr 2005 17:10:52 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPoZY-0007Px-N1 for ltru@ietf.org; Sun, 24 Apr 2005 17:23:25 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3OLAh4E019126; Sun, 24 Apr 2005 17:10:43 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sun, 24 Apr 2005 17:10:52 -0400 Date: Sun, 24 Apr 2005 17:10:52 -0400 From: John Cowan To: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: 003 vs. 021 (was: Moving Forward) Message-ID: <20050424211052.GH26135@skunk.reutershealth.com> References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org> <025901c548a8$5868dca0$030aa8c0@DEWELL> <20050424164747.GB26135@skunk.reutershealth.com> <6.2.1.2.2.20050424194401.0379b720@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.2.20050424194401.0379b720@mail.jefsey.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC (Jefsey) Morfin scripsit: > >I'm beginning to wonder just how authoritative that page really is. > > Please define "authoritative" if you wish to address this point. IOW, does it actually represent the official M.49 list? -- One art / There is John Cowan No less / No more http://www.reutershealth.com All things / To do http://www.ccil.org/~cowan With sparks / Galore -- Douglas Hofstadter _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 17:42:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPosV-0007XE-L6; Sun, 24 Apr 2005 17:42:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPosU-0007X4-0o for ltru@megatron.ietf.org; Sun, 24 Apr 2005 17:42:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24968 for ; Sun, 24 Apr 2005 17:42:55 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPp4a-0000Yt-Ci for ltru@ietf.org; Sun, 24 Apr 2005 17:55:29 -0400 Received: from lns-p19-2-idf-82-251-121-211.adsl.proxad.net ([82.251.121.211] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DPosR-0004lo-E9; Sun, 24 Apr 2005 14:42:55 -0700 Message-Id: <6.2.1.2.2.20050424231512.04519dd0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 24 Apr 2005 23:42:52 +0200 To: John Cowan From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: 003 vs. 021 (was: Moving Forward) In-Reply-To: <20050424211052.GH26135@skunk.reutershealth.com> References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org> <025901c548a8$5868dca0$030aa8c0@DEWELL> <20050424164747.GB26135@skunk.reutershealth.com> <6.2.1.2.2.20050424194401.0379b720@mail.jefsey.com> <20050424211052.GH26135@skunk.reutershealth.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 23:10 24/04/2005, John Cowan wrote: >JFC (Jefsey) Morfin scripsit: > > > >I'm beginning to wonder just how authoritative that page really is. > > > > Please define "authoritative" if you wish to address this point. > >IOW, does it actually represent the official M.49 list? What I mean is more general. We are in real life. You can only include a name with a definition in a table. Full stop. This kind of discussion much repeated in here and ietf-languages@alverstrand.no is of no use. Because every user for the centuries to come can repeat it. With no other authoritative result than being understood by those who share her understanding - which can change. The job of a Registry designer and then of a Registry manager is not to discuss the meaning of existing names but to try to provide names that will satisfy the users enough for them not to introduce (or use if "barred" by the Registry Manager thinking he has a decision authority) confusing names. Keeping in mind that each time a name is denied by the Registry Manager, this is a loss of "authority" (knowledge/trust) for the Registry, because it will be used outside of it, creating confusion and possible conflicts. Intergovernance is not by rulings but by adherence to consensual propositions. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 18:34:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPpgl-0003U2-So; Sun, 24 Apr 2005 18:34:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPpgk-0003Tx-Kp for ltru@megatron.ietf.org; Sun, 24 Apr 2005 18:34:54 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29947 for ; Sun, 24 Apr 2005 18:34:50 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DPpbZ-0007N4-Bg for ltru@lists.ietf.org; Mon, 25 Apr 2005 00:29:33 +0200 Received: from du-001-047.access.de.clara.net ([212.82.227.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Apr 2005 00:29:33 +0200 Received: from nobody by du-001-047.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Apr 2005 00:29:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 25 Apr 2005 00:32:40 +0200 Organization: Lines: 14 Message-ID: <426C1E88.CF@xyzzy.claranet.de> References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org> <025901c548a8$5868dca0$030aa8c0@DEWELL> <20050424164747.GB26135@skunk.reutershealth.com> <6.2.1.2.2.20050424194401.0379b720@mail.jefsey.com> <20050424211052.GH26135@skunk.reutershealth.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: du-001-047.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org John Cowan wrote: >>> I'm beginning to wonder just how authoritative that page >>> really is. > IOW, does it actually represent the official M.49 list? Point. Maybe it's a Webmaster trying his best, but as always with a copy of a copy of an original text minor differences are possible. It would be easier for Doug to work with ths original text - instead of digging in strange HTML tables. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Apr 24 22:59:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPtp2-0006kt-Dk; Sun, 24 Apr 2005 22:59:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPtp0-0006kl-FS for ltru@megatron.ietf.org; Sun, 24 Apr 2005 22:59:42 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13833 for ; Sun, 24 Apr 2005 22:59:38 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DPtjv-0002nE-50 for ltru@lists.ietf.org; Mon, 25 Apr 2005 04:54:27 +0200 Received: from du-001-047.access.de.clara.net ([212.82.227.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Apr 2005 04:54:27 +0200 Received: from nobody by du-001-047.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Apr 2005 04:54:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 25 Apr 2005 04:54:44 +0200 Organization: Lines: 81 Message-ID: <426C5BF4.5EA8@xyzzy.claranet.de> References: <20050424160329.SAMF17200.mta1.adelphia.net@megatron.ietf.org> <001801c548fb$e025ec20$030aa8c0@DEWELL> 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: du-001-047.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell wrote: > I suppose I could write to statistics@un.org and see if they > can tell me the "official" status of 003 and 021. Good idea, or ask their Web master what (s)he used as source. If you get no reply drop 003 for the moment, adding it later is no problem, removing it later is more or less impossible. > It doesn't take long, in discussions about the coverage of > ISO 3166-1 and decisions made in its creation, for somebody > to point scornfully at codes like BV and HM Sure, using ISO 3166-1 alpha-2 codes to define regions is one of these simple but stupid ideas - sometimes my KISS-religion doesn't work as expected. > Do I tag this as es-HN, es-013, es-419, es-019, or just plain > es? The answer is, none of these is incorrect. That doesn't answer your question. It's an excellent question, it should be added to the registry draft. I note that you did not propose es-003. > IMHO it does not cause "major havoc.". I'd know how to implement HN < 013 < 419 < 019 < 001. It's a clear structure. But 003 breaks this simple structure, neither is 419 < 003 nor 003 < 419, and the intersection of 419 and 003 is not empty. So yes, it could cause havoc for smart geo-matching strategies. >> how do you exclude region numbers covered by ISO 3166-1 >> country codes ? Addison proposed to add the numbers to the >> codes somehow, so that a future tag reviewer can do his >> "same piece of land" magic when necessary. > I don't follow this. I would be surprised if Addison > supported "adding the numbers to the codes" in the way you > describe; perhaps a quote or reference to the archives would > help me. The "same piece of land" rule was something invented by you in our region-code-discussions on the languages list before LTRU. Addison's related articles here, just remove the angle brackets and add e.g. news://news.gmane.org/ or http://mid.gmane.org/ in front of the Message-ID to see the complete article: <634978A7DF025A40BFEF33EB191E13BC0A9F498B@irvmbxw01.quest.com> | perhaps the UN M.49 codes should be notes in the registry to | assist with clarity in the future <634978A7DF025A40BFEF33EB191E13BC0AC29C0A@irvmbxw01.quest.com> |> (a) by preserving all assigned ISO 3166 codes with their |> original meaning, except those that have already been |> reassigned, and using UN numeric codes in the case of future |> reassignments [...] | I support (a). Frank has convinced me that I would be in | favor of a fourth option (d): same as (a) but include the | M.49 codes in the description. >> I somehow doubt that ISO and the UN are always in perfect >> synchronization, not only for the three wellknown exceptions >> TW, 830, and 833. > I am sure you are right. I am not sure what the point is. The point is your undocumented "same piece of land" rule. One way to define & document it is to use UN region numbers as the authoritative source, because ISO 3166-1 codes obviously don't work this way (new DE is not old DE, dito CS, YE, YU, etc.) In one case we've seen that even the UN numbers don't always identify "the same piece of land", but that was the prehistoric GE before date-A, IIRC. After date-A region numbers were okay. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 25 01:06:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPvnt-0004s6-Aq; Mon, 25 Apr 2005 01:06:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPvnr-0004ry-Kv for ltru@megatron.ietf.org; Mon, 25 Apr 2005 01:06:39 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20522 for ; Mon, 25 Apr 2005 01:06:37 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050425050607.XEVO4191.mta13.adelphia.net@DEWELL> for ; Mon, 25 Apr 2005 01:06:07 -0400 Message-ID: <001101c54954$71d6a4e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050425030032.UTEK9622.mta3.adelphia.net@megatron.ietf.org> Date: Sun, 24 Apr 2005 22:05:47 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> I suppose I could write to statistics@un.org and see if they >> can tell me the "official" status of 003 and 021. > > Good idea, or ask their Web master what (s)he used as source. > If you get no reply drop 003 for the moment, adding it later > is no problem, removing it later is more or less impossible. We should be able to get the source. One possible problem that I'm wondering about is how much thought the UN Statistics Division has actually given to these codes. After all, UNSD publishes a quite a few databases of "real" statistics. If you need to know how many left-handed Protestant longshoremen were employed in each nation in 2000, and how much their mean salaries were, and how those figures compare to 1990 and 1980, chances are good UNSD can tell you. The list of region codes may be just an incidental mechanism to help them prepare these other statistical compendia, not a true database in its own right, which is how we are using it. >> It doesn't take long, in discussions about the coverage of >> ISO 3166-1 and decisions made in its creation, for somebody >> to point scornfully at codes like BV and HM > > Sure, using ISO 3166-1 alpha-2 codes to define regions is one > of these simple but stupid ideas - sometimes my KISS-religion > doesn't work as expected. People criticize the existence of BV and HM for reasons having nothing to do with language tags. >> Do I tag this as es-HN, es-013, es-419, es-019, or just plain >> es? The answer is, none of these is incorrect. > > That doesn't answer your question. It's an excellent question, > it should be added to the registry draft. The draft already says, "Use as precise a tag as possible, but no more specific than is justified. Avoid using subtags that are not important for distinguishing content in an application." I would interpret "as precise as possible" to mean that if I know the language variant is Honduran, then I should use -HN and not the others, whereas if all I know is that it's from somewhere in Latin America, I should use a more general numeric code. If I can't even tell anything except "it's Spanish," then I go with plain es. As the one tagging the data, I am responsible for making decisions like this. > I note that you did not propose es-003. > >> IMHO it does not cause "major havoc." > > I'd know how to implement HN < 013 < 419 < 019 < 001. It's a > clear structure. But 003 breaks this simple structure, neither > is 419 < 003 nor 003 < 419, and the intersection of 419 and 003 > is not empty. > > So yes, it could cause havoc for smart geo-matching strategies. I agree with your analysis of this situation. 003 is an odd bird that does not fit into the nice, neat "Geographical region and composition" hierarchy. Frankly, it reminds me of the economic codes. I'd like to see it disappear. But you need to understand that the registry is not just a reflection of what I'd like to see. Its contents need to be determined on the basis of stable, defensible rules, applied to references that people trust, devised by authorities that are in a position to devise them. So if the UN Statistics Division says that 003 is a quasi-economic code that really doesn't belong in its hierarchy, and that's why it only appears in a footnote, that would probably justify its removal. If Doug or Frank don't like it, that probably isn't good enough. If the Working Group came to a rough consensus that it should be removed from the registry, that would be fine, but we'd better have a good, solid justification for this "cherry-picking" (to use the term Bruce Lilly applied to a situation much like this one). BTW, I'd love to see matching algorithms implement a "smart geo-matching strategy" like the one you described. I hope that view is more prevalent in the future than the view that says "remove subtags blindly from right to left." > The "same piece of land" rule was something invented by you in > our region-code-discussions on the languages list before LTRU. The "same piece of land" rule was *only* intended to explain why certain withdrawn codes were or were not mapped to certain current codes -- for example, why BU was mapped to MM but DD was not mapped to DE. You'll notice I haven't mentioned the "same piece of land" rule since the LTRU WG came into existence. If you hadn't noticed, we abandoned it and adopted your rule, "either use ISO 3166-3 completely or not at all" -- and as you can see, DD is now mapped to DE as you wanted. As Randy says, we are starting fresh with this WG. > Addison's related articles here, just remove the angle brackets > and add e.g. news://news.gmane.org/ or http://mid.gmane.org/ in > front of the Message-ID to see the complete article: > > <634978A7DF025A40BFEF33EB191E13BC0A9F498B@irvmbxw01.quest.com> > | perhaps the UN M.49 codes should be notes in the registry to > | assist with clarity in the future > > <634978A7DF025A40BFEF33EB191E13BC0AC29C0A@irvmbxw01.quest.com> > |> (a) by preserving all assigned ISO 3166 codes with their > |> original meaning, except those that have already been > |> reassigned, and using UN numeric codes in the case of future > |> reassignments > [...] > | I support (a). Frank has convinced me that I would be in > | favor of a fourth option (d): same as (a) but include the > | M.49 codes in the description. OK, I see what you're talking about. He meant referencing the UN codes in comments, not making them part of the language tag itself (and I note that you never said otherwise). -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 25 01:31:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPwBf-0006dF-9G; Mon, 25 Apr 2005 01:31:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPwBd-0006cG-LY for ltru@megatron.ietf.org; Mon, 25 Apr 2005 01:31:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22151 for ; Mon, 25 Apr 2005 01:31:12 -0400 (EDT) Received: from ore.jhcloos.com ([64.240.156.239]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPwNo-0004XI-8l for ltru@ietf.org; Mon, 25 Apr 2005 01:43:49 -0400 Received: from lugabout.jhcloos.org (host-69-48-15-97.roc.choiceone.net [69.48.15.97]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "lugabout.jhcloos.org", Issuer "ca.jhcloos.com" (verified OK)) by ore.jhcloos.com (Postfix) with ESMTP id 32B9F1C90F for ; Mon, 25 Apr 2005 00:31:06 -0500 (CDT) Received: by lugabout.jhcloos.org (Postfix, from userid 500) id 3D06D4D42FB; Mon, 25 Apr 2005 05:31:00 +0000 (GMT) To: ltru@ietf.org From: James Cloos In-Reply-To: <426AF2EA.4BB2@xyzzy.claranet.de> (Frank Ellermann's message of "Sun, 24 Apr 2005 03:14:18 +0200") References: <20050420160557.UOZB4900.mta8.adelphia.net@megatron.ietf.org> <01a101c54848$ed01f1e0$030aa8c0@DEWELL> <426AF2EA.4BB2@xyzzy.claranet.de> X-Hashcash: 1:21:050425:ltru@ietf.org::88OxOQLnFzXa6adG:00004NjQ User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-Hashcash: 1:21:050425:ltru@ietf.org::xJrAIoecpL1ugcpN:00006xRw Date: Mon, 25 Apr 2005 01:30:59 -0400 Message-ID: Lines: 37 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Spam-Score: 2.9 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id BAA22151 Cc: Subject: [Ltru] Re: hyphen-minus X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org [SIGH, sent from wrong address; resending.... -JimC] >>>>> "Frank" =3D=3D Frank Ellermann writes: Commenting just on the 10646 choices here, not on the use of 8859-1 in lieu of 10646.... >> Ge=E2=80=98ez --> Ge'ez Frank> better use ‘ LEFT SINGLE QUOTATION MARK If that is a glottal stop, =C3=A0la Hawai=CA=BBian=E2=80=99s =CA=BBokina,= it should really be U+02BB MODIFIER LETTER TURNED COMMA rather than U+2018. Even if not, is it still the case that U+02BB is a letter whereas U+2018 is punctuation.... >> N=E2=80=99ko --> N'ko Frank> better use ’ RIGHT SINGLE QUOTATION MARK Same argument as above, but using U+02BC MODIFIER LETTER APOSTROPHE for N=CA=BCko. >> Gwich=C2=B4in --> Gwich'in Frank> better use ´ ACUTE ACCENT That one is confusing. If you are going to use 10646 there must be a better choice than a spacing acute accent.... 8859-1 is probably better right now for interoperability. If 10646 is used then every effort should be made to use the best characters even if homographs may be easier to enter on many (most?) keyboards. -JimC --=20 James H. Cloos, Jr. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 25 14:49:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ8eR-0005cp-QY; Mon, 25 Apr 2005 14:49:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ8eO-0005ck-Ng for ltru@megatron.ietf.org; Mon, 25 Apr 2005 14:49:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10589 for ; Mon, 25 Apr 2005 14:49:40 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ8qZ-0003vc-T6 for ltru@ietf.org; Mon, 25 Apr 2005 15:02:24 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Apr 2005 11:49:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C549C7.7E87DA77" Date: Mon, 25 Apr 2005 11:49:22 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B20A2D5@irvmbxw01.quest.com> X-MS-Has-Attach: yes Thread-Topic: (need approval) Working Group submission: LTRU registry draft-01 Thread-Index: AcVJx3px5STUY4E/Q3CHWiAguX0x1w== From: "Addison Phillips" To: "Randy Presuhn" , "Martin Duerst" X-OriginalArrivalTime: 25 Apr 2005 18:49:23.0412 (UTC) FILETIME=[7F5E1940:01C549C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e46af3b0bf8d830d1da230ab789487e Cc: ltru Working Group Subject: [Ltru] (need approval) Working Group submission: LTRU registry draft-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C549C7.7E87DA77 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmFuZHkgYW5kIE1hcnRpbiwNCg0KUGxlYXNlIGFwcHJvdmUgbXkgc3VibWl0dGluZyB0aGUgY3Vy cmVudCBlZGl0b3IncyBjb3B5IChhdHRhY2hlZCkgYXMgZHJhZnQtMDEgYnkgcmVzcG9uZGluZyB0 byB0aGlzIGVtYWlsLiBJIHdpbGwgc3VibWl0IHRoZSBuZXcgZHJhZnQgb3ZlciBhIGNvcHkgb2Yg dGhlIHJlc3BvbnNlLg0KDQpUaGVuIHdlIGNhbiBwcm9jZWVkIHRvIHdpcGUgdXAgYW55IHJlbWFp bmluZyBpc3N1ZXMsIGhvcGVmdWxseSBmb3IgYSB0aW1lbHkgbGFzdCBjYWxsLg0KDQpBZGRpc29u DQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBT b2Z0d2FyZQ0KaHR0cDovL3d3dy5xdWVzdC5jb20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFs aXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9u YWwNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFy Y2hpdGVjdHVyZS4gDQoNCg0K ------_=_NextPart_001_01C549C7.7E87DA77 Content-Type: text/plain; name="draft-ietf-ltru-registry-01.txt" Content-Description: draft-ietf-ltru-registry-01.txt Content-Disposition: attachment; filename="draft-ietf-ltru-registry-01.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUXVlc3QgU29mdHdhcmUNCkV4cGlyZXM6IE9jdG9iZXIg MjIsIDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gRGF2aXMsIEVkLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSUJNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQXByaWwgMjAsIDIwMDUNCg0KDQogICAgICAgICAgICAgICAgICAg ICBUYWdzIGZvciBJZGVudGlmeWluZyBMYW5ndWFnZXMNCiAgICAgICAgICAgICAgICAgICAgICBk cmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMDENCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBC eSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMg dGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hp Y2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQs IGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NCg0KICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBn cm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJy ZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQt RHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4 cGlyZSBvbiBPY3RvYmVyIDIyLCAyMDA1Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHly aWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLg0KDQpBYnN0cmFjdA0KDQogICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgc3RydWN0dXJlLCBjb250ZW50LCBjb25zdHJ1Y3Rp b24sIGFuZA0KICAgc2VtYW50aWNzIG9mIGxhbmd1YWdlIHRhZ3MgZm9yIHVzZSBpbiBjYXNlcyB3 aGVyZSBpdCBpcyBkZXNpcmFibGUgdG8NCiAgIGluZGljYXRlIHRoZSBsYW5ndWFnZSB1c2VkIGlu IGFuIGluZm9ybWF0aW9uIG9iamVjdC4gIEl0IGFsc28NCiAgIGRlc2NyaWJlcyBob3cgdG8gcmVn aXN0ZXIgdmFsdWVzIGZvciB1c2UgaW4gbGFuZ3VhZ2UgdGFncyBhbmQgdGhlDQogICBjcmVhdGlv biBvZiB1c2VyIGRlZmluZWQgZXh0ZW5zaW9ucyBmb3IgcHJpdmF0ZSBpbnRlcmNoYW5nZS4gIFRo aXMNCiAgIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgMzA2NiAod2hpY2ggcmVwbGFjZWQgUkZDIDE3 NjYpLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIs IDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNClRh YmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMi4gIFRoZSBMYW5ndWFnZSBU YWcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAg IDIuMSAgIFN5bnRheCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDQNCiAgICAgICAyLjEuMSAgIExlbmd0aCBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgICAyLjIgICBMYW5ndWFnZSBTdWJ0YWcg U291cmNlcyBhbmQgSW50ZXJwcmV0YXRpb24gLiAuIC4gLiAuIC4gLiAuICA3DQogICAgICAgMi4y LjEgICBQcmltYXJ5IExhbmd1YWdlIFN1YnRhZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDgNCiAgICAgICAyLjIuMiAgIEV4dGVuZGVkIExhbmd1YWdlIFN1YnRhZ3MgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgICAgIDIuMi4zICAgU2NyaXB0IFN1YnRhZyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDQogICAgICAgMi4yLjQgICBS ZWdpb24gU3VidGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEN CiAgICAgICAyLjIuNSAgIFZhcmlhbnQgU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxMg0KICAgICAgIDIuMi42ICAgRXh0ZW5zaW9uIFN1YnRhZ3MgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDQogICAgICAgMi4yLjcgICBQcml2YXRl IFVzZSBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQNCiAgICAg ICAyLjIuOCAgIFByZS1FeGlzdGluZyBSRkMgMzA2NiBSZWdpc3RyYXRpb25zICAuIC4gLiAuIC4g LiAuIC4gLiAxNA0KICAgICAgIDIuMi45ICAgQ2xhc3NlcyBvZiBDb25mb3JtYW5jZSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1DQogICAzLiAgUmVnaXN0cnkgRm9ybWF0IGFuZCBN YWludGVuYW5jZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNCiAgICAgMy4xICAg Rm9ybWF0IG9mIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAgLiAuIC4gLiAuIC4g LiAxNw0KICAgICAzLjIgICBNYWludGVuYW5jZSBvZiB0aGUgUmVnaXN0cnkgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDIxDQogICAgIDMuMyAgIFN0YWJpbGl0eSBvZiBJQU5BIFJlZ2lz dHJ5IEVudHJpZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjINCiAgICAgMy40ICAgUmVnaXN0 cmF0aW9uIFByb2NlZHVyZSBmb3IgU3VidGFncyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNQ0K ICAgICAzLjUgICBQb3NzaWJpbGl0aWVzIGZvciBSZWdpc3RyYXRpb24gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDI5DQogICAgIDMuNiAgIEV4dGVuc2lvbnMgYW5kIEV4dGVuc2lvbnMgTmFt ZXNwYWNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzANCiAgICAgMy43ICAgQ29udmVyc2lvbiBv ZiB0aGUgUkZDIDMwNjYgTGFuZ3VhZ2UgVGFnIFJlZ2lzdHJ5IC4gLiAuIC4gLiAzMw0KICAgNC4g IEZvcm1hdGlvbiBhbmQgUHJvY2Vzc2luZyBvZiBMYW5ndWFnZSBUYWdzICAuIC4gLiAuIC4gLiAu IC4gLiAuIDM2DQogICAgIDQuMSAgIENob2ljZSBvZiBMYW5ndWFnZSBUYWcgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzYNCiAgICAgNC4yICAgTWVhbmluZyBvZiB0aGUgTGFu Z3VhZ2UgVGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzOA0KICAgICA0LjMgICBD YW5vbmljYWxpemF0aW9uIG9mIExhbmd1YWdlIFRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDM5DQogICAgIDQuNCAgIENvbnNpZGVyYXRpb25zIGZvciBQcml2YXRlIFVzZSBTdWJ0YWdzIC4g LiAuIC4gLiAuIC4gLiAuIC4gNDANCiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Mg0KICAgNi4gIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQzDQog ICA3LiAgQ2hhcmFjdGVyIFNldCBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNDQNCiAgIDguICBDaGFuZ2VzIGZyb20gUkZDIDMwNjYgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NQ0KICAgOS4gIFJlZmVyZW5jZXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUwDQogICAgIDku MSAgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNTANCiAgICAgOS4yICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MQ0KICAgICAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUyDQogICBBLiAgQWNrbm93 bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NTMNCiAgIEIuICBFeGFtcGxlcyBvZiBMYW5ndWFnZSBUYWdzIChJbmZvcm1hdGl2ZSkgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA1NA0KICAgQy4gIEV4YW1wbGUgUmVnaXN0cnkgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU2DQogICAgICAgSW50ZWxsZWN0dWFs IFByb3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gNjANCg0K DQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVy IDIyLCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0K DQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIEh1bWFuIGJlaW5ncyBvbiBvdXIgcGxhbmV0IGhhdmUs IHBhc3QgYW5kIHByZXNlbnQsIHVzZWQgYSBudW1iZXIgb2YNCiAgIGxhbmd1YWdlcy4gIFRoZXJl IGFyZSBtYW55IHJlYXNvbnMgd2h5IG9uZSB3b3VsZCB3YW50IHRvIGlkZW50aWZ5IHRoZQ0KICAg bGFuZ3VhZ2UgdXNlZCB3aGVuIHByZXNlbnRpbmcgb3IgcmVxdWVzdGluZyBpbmZvcm1hdGlvbi4N Cg0KICAgSW5mb3JtYXRpb24gYWJvdXQgYSB1c2VyJ3MgbGFuZ3VhZ2UgcHJlZmVyZW5jZXMgY29t bW9ubHkgbmVlZHMgdG8gYmUNCiAgIGlkZW50aWZpZWQgc28gdGhhdCBhcHByb3ByaWF0ZSBwcm9j ZXNzaW5nIGNhbiBiZSBhcHBsaWVkLiAgRm9yDQogICBleGFtcGxlLCB0aGUgdXNlcidzIGxhbmd1 YWdlIHByZWZlcmVuY2VzIGluIGEgYnJvd3NlciBjYW4gYmUgdXNlZCB0bw0KICAgc2VsZWN0IHdl YiBwYWdlcyBhcHByb3ByaWF0ZWx5LiAgQSBjaG9pY2Ugb2YgbGFuZ3VhZ2UgcHJlZmVyZW5jZSBj YW4NCiAgIGFsc28gYmUgdXNlZCB0byBzZWxlY3QgYW1vbmcgdG9vbHMgKHN1Y2ggYXMgZGljdGlv bmFyaWVzKSB0byBhc3Npc3QNCiAgIGluIHRoZSBwcm9jZXNzaW5nIG9yIHVuZGVyc3RhbmRpbmcg b2YgY29udGVudCBpbiBkaWZmZXJlbnQgbGFuZ3VhZ2VzLg0KDQogICBJbiBhZGRpdGlvbiwga25v d2xlZGdlIGFib3V0IHRoZSBwYXJ0aWN1bGFyIGxhbmd1YWdlIHVzZWQgYnkgc29tZQ0KICAgcGll Y2Ugb2YgaW5mb3JtYXRpb24gY29udGVudCBtYXkgYmUgdXNlZnVsIG9yIGV2ZW4gcmVxdWlyZWQg Ynkgc29tZQ0KICAgdHlwZXMgb2YgaW5mb3JtYXRpb24gcHJvY2Vzc2luZzsgZm9yIGV4YW1wbGUg c3BlbGwtY2hlY2tpbmcsDQogICBjb21wdXRlci1zeW50aGVzaXplZCBzcGVlY2gsIEJyYWlsbGUg dHJhbnNjcmlwdGlvbiwgb3IgaGlnaC1xdWFsaXR5DQogICBwcmludCByZW5kZXJpbmdzLg0KDQog ICBPbmUgbWVhbnMgb2YgaW5kaWNhdGluZyB0aGUgbGFuZ3VhZ2UgdXNlZCBpcyBieSBsYWJlbGlu ZyB0aGUNCiAgIGluZm9ybWF0aW9uIGNvbnRlbnQgd2l0aCBhIGxhbmd1YWdlIGlkZW50aWZpZXIu ICBUaGVzZSBpZGVudGlmaWVycw0KICAgY2FuIGFsc28gYmUgdXNlZCB0byBzcGVjaWZ5IHVzZXIg cHJlZmVyZW5jZXMgd2hlbiBzZWxlY3RpbmcNCiAgIGluZm9ybWF0aW9uIGNvbnRlbnQsIG9yIGZv ciBsYWJlbGluZyBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMgb2YgY29udGVudA0KICAgYW5kIGFzc29j aWF0ZWQgcmVzb3VyY2VzLg0KDQogICBUaGVzZSBpZGVudGlmaWVycyBjYW4gYWxzbyBiZSB1c2Vk IHRvIGluZGljYXRlIGFkZGl0aW9uYWwgYXR0cmlidXRlcw0KICAgb2YgY29udGVudCB0aGF0IGFy ZSBjbG9zZWx5IHJlbGF0ZWQgdG8gdGhlIGxhbmd1YWdlLiAgSW4gcGFydGljdWxhciwNCiAgIGl0 IGlzIG9mdGVuIG5lY2Vzc2FyeSB0byBpbmRpY2F0ZSBzcGVjaWZpYyBpbmZvcm1hdGlvbiBhYm91 dCB0aGUNCiAgIGRpYWxlY3QsIHdyaXRpbmcgc3lzdGVtLCBvciBvcnRob2dyYXBoeSB1c2VkIGlu IGEgZG9jdW1lbnQgb3INCiAgIHJlc291cmNlLCBhcyB0aGVzZSBhdHRyaWJ1dGVzIG1heSBiZSBp bXBvcnRhbnQgZm9yIHRoZSB1c2VyIHRvIG9idGFpbg0KICAgaW5mb3JtYXRpb24gaW4gYSBmb3Jt IHRoYXQgdGhleSBjYW4gdW5kZXJzdGFuZCwgb3IgaW1wb3J0YW50IGluDQogICBzZWxlY3Rpbmcg YXBwcm9wcmlhdGUgcHJvY2Vzc2luZyByZXNvdXJjZXMgZm9yIHRoZSBnaXZlbiBjb250ZW50Lg0K DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhbiBpZGVudGlmaWVyIG1lY2hhbmlzbSBhbmQg YSByZWdpc3RyYXRpb24NCiAgIGZ1bmN0aW9uIGZvciB2YWx1ZXMgdG8gYmUgdXNlZCB3aXRoIHRo YXQgaWRlbnRpZmllciBtZWNoYW5pc20uICBJdA0KICAgYWxzbyBkZWZpbmVzIGEgbWVjaGFuaXNt IGZvciBwcml2YXRlIHVzZSB2YWx1ZXMgYW5kIGZ1dHVyZSBleHRlbnNpb24uDQoNCiAgIFRoaXMg ZG9jdW1lbnQgcmVwbGFjZXMgUkZDIDMwNjYsIHdoaWNoIHJlcGxhY2VkIFJGQyAxNzY2LiAgRm9y IGEgbGlzdA0KICAgb2YgY2hhbmdlcyBpbiB0aGlzIGRvY3VtZW50LCBzZWUgU2VjdGlvbiA4Lg0K DQogICBUaGUga2V5d29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwi LCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIs ICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50 ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMgMjExOV0gWzExXS4NCg0KDQoNCg0KDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAg ICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCjIuICBUaGUgTGFuZ3Vh Z2UgVGFnDQoNCjIuMSAgU3ludGF4DQoNCiAgIFRoZSBsYW5ndWFnZSB0YWcgaXMgY29tcG9zZWQg b2Ygb25lIG9yIG1vcmUgcGFydHM6IEEgcHJpbWFyeSBsYW5ndWFnZQ0KICAgc3VidGFnIGFuZCBh IChwb3NzaWJseSBlbXB0eSkgc2VyaWVzIG9mIHN1YnNlcXVlbnQgc3VidGFncy4gIFN1YnRhZ3MN CiAgIGFyZSBkaXN0aW5ndWlzaGVkIGJ5IHRoZWlyIGxlbmd0aCwgcG9zaXRpb24gaW4gdGhlIHN1 YnRhZyBzZXF1ZW5jZSwNCiAgIGFuZCBjb250ZW50LCBzbyB0aGF0IGVhY2ggdHlwZSBvZiBzdWJ0 YWcgY2FuIGJlIHJlY29nbml6ZWQgc29sZWx5IGJ5DQogICB0aGVzZSBmZWF0dXJlcy4gIFRoaXMg bWFrZXMgaXQgcG9zc2libGUgdG8gY29uc3RydWN0IGEgcGFyc2VyIHRoYXQNCiAgIGNhbiBleHRy YWN0IGFuZCBhc3NpZ24gc29tZSBzZW1hbnRpYyBpbmZvcm1hdGlvbiB0byB0aGUgc3VidGFncywg ZXZlbg0KICAgaWYgc3BlY2lmaWMgc3VidGFnIHZhbHVlcyBhcmUgbm90IHJlY29nbml6ZWQuICBU aHVzIGEgcGFyc2VyIG5lZWQgbm90DQogICBoYXZlIGFuIHVwLXRvLWRhdGUgY29weSBvZiB0aGUg cmVnaXN0ZXJlZCBzdWJ0YWcgdmFsdWVzIHRvIHBlcmZvcm0NCiAgIG1vc3Qgc2VhcmNoaW5nIGFu ZCBtYXRjaGluZyBvcGVyYXRpb25zLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSA0 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgVGhlIHN5bnRheCBvZiB0aGlzIHRhZyBpbiBB Qk5GIFs4XSBpczoNCg0KICAgTGFuZ3VhZ2UtVGFnID0gKGxhbmcNCiAgICAgICAgICAgICAgICAg ICAqKCItIiBleHRsYW5nKQ0KICAgICAgICAgICAgICAgICAgIFsiLSIgc2NyaXB0XQ0KICAgICAg ICAgICAgICAgICAgIFsiLSIgcmVnaW9uXQ0KICAgICAgICAgICAgICAgICAgICooIi0iIHZhcmlh bnQpDQogICAgICAgICAgICAgICAgICAgKigiLSIgZXh0ZW5zaW9uKQ0KICAgICAgICAgICAgICAg ICAgIFsiLSIgcHJpdmF0ZXVzZV0pDQogICAgICAgICAgICAgICAgICAgLyBwcml2YXRldXNlICAg ICAgICAgOyBwcml2YXRlLXVzZSB0YWcNCiAgICAgICAgICAgICAgICAgICAvIGdyYW5kZmF0aGVy ZWQgICAgICA7IGdyYW5kZmF0aGVyZWQgcmVnaXN0cmF0aW9ucw0KDQogICBsYW5nICAgICAgICAg ICAgPSAyKjNBTFBIQSAgICAgICAgICAgOyBzaG9ydGVzdCBJU08gNjM5IGNvZGUNCiAgICAgICAg ICAgICAgICAgICAvIHJlZ2lzdGVyZWQtbGFuZw0KICAgZXh0bGFuZyAgICAgICAgID0gM0FMUEhB ICAgICAgICAgICAgIDsgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UNCiAgIHNjcmlwdCAgICAgICAg ICA9IDRBTFBIQSAgICAgICAgICAgICA7IElTTyAxNTkyNCBjb2RlDQogICByZWdpb24gICAgICAg ICAgPSAyQUxQSEEgICAgICAgICAgICAgOyBJU08gMzE2NiBjb2RlDQogICAgICAgICAgICAgICAg ICAgLyAzRElHSVQgICAgICAgICAgICAgOyBVTiBjb3VudHJ5IG51bWJlcg0KICAgdmFyaWFudCAg ICAgICAgID0gIDUqOGFscGhhbnVtICAgICAgIDsgcmVnaXN0ZXJlZCB2YXJpYW50cw0KICAgICAg ICAgICAgICAgICAgIC8gKCBESUdJVCAzYWxwaGFudW0gKQ0KICAgZXh0ZW5zaW9uICAgICAgID0g c2luZ2xldG9uIDEqKCItIiAoMio4YWxwaGFudW0pKQ0KICAgcHJpdmF0ZXVzZSAgICAgID0gKCJ4 Ii8iWCIpIDEqKCItIiAoMSo4YWxwaGFudW0pKQ0KICAgc2luZ2xldG9uICAgICAgID0gJXg0MS01 NyAvICV4NTktNUEgLyAleDYxLTc3IC8gJXg3OS03QSAvIERJR0lUDQogICAgICAgICAgICAgICAg ICAgOyAiYSItInciIC8gInkiLSJ6IiAvICJBIi0iVyIgLyAiWSItIloiIC8gIjAiLSI5Ig0KICAg ICAgICAgICAgICAgICAgIDsgU2luZ2xlIGxldHRlcnM6IHgvWCBpcyByZXNlcnZlZCBmb3IgcHJp dmF0ZSB1c2UNCiAgIHJlZ2lzdGVyZWQtbGFuZyA9IDQqOEFMUEhBICAgICAgICAgIDsgcmVnaXN0 ZXJlZCBsYW5ndWFnZSBzdWJ0YWcNCiAgIGdyYW5kZmF0aGVyZWQgICA9IDEqM0FMUEhBIDEqMigi LSIgKDIqOGFscGhhbnVtKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDsgZ3JhbmRmYXRoZXJlZCByZWdpc3RyYXRpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDsgTm90ZTogaSBpcyB0aGUgb25seSBzaW5nbGV0b24NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgdGhhdCBzdGFydHMgYSBncmFuZGZhdGhlcmVk IHRhZw0KICAgYWxwaGFudW0gICAgICAgID0gKEFMUEhBIC8gRElHSVQpICAgOyBsZXR0ZXJzIGFu ZCBudW1iZXJzDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBMYW5ndWFnZSBU YWcgQUJORg0KDQogICBUaGUgY2hhcmFjdGVyICItIiBpcyBIWVBIRU4tTUlOVVMgKEFCTkY6ICV4 MkQpLiAgQWxsIHN1YnRhZ3MgaGF2ZSBhDQogICBtYXhpbXVtIGxlbmd0aCBvZiBlaWdodCBjaGFy YWN0ZXJzLiAgTm90ZSB0aGF0IHRoZXJlIGlzIGEgc3VidGxldHkgaW4NCiAgIHRoZSBBQk5GIGZv ciAndmFyaWFudCc6IHZhcmlhbnRzIHN0YXJ0aW5nIHdpdGggYSBkaWdpdCBtYXkgYmUgb25seQ0K ICAgZm91ciBjaGFyYWN0ZXJzIGxvbmcsIHdoaWxlIHRob3NlIHN0YXJ0aW5nIHdpdGggYSBsZXR0 ZXIgbXVzdCBiZSBhdA0KICAgbGVhc3QgZml2ZSBjaGFyYWN0ZXJzIGxvbmcuDQoNCiAgIFdoaXRl c3BhY2UgaXMgbm90IHBlcm1pdHRlZCBpbiBhIGxhbmd1YWdlIHRhZy4gIEZvciBleGFtcGxlcyBv Zg0KICAgbGFuZ3VhZ2UgdGFncywgc2VlIEFwcGVuZGl4IEIuDQoNCiAgIE5vdGUgdGhhdCBhbHRo b3VnaCBbOF0gcmVmZXJzIHRvIG9jdGV0cywgdGhlIGxhbmd1YWdlIHRhZ3MgZGVzY3JpYmVkDQog ICBpbiB0aGlzIGRvY3VtZW50IGFyZSBzZXF1ZW5jZXMgb2YgY2hhcmFjdGVycyBmcm9tIHRoZSBV Uy1BU0NJSQ0KICAgcmVwZXJ0b2lyZS4gIExhbmd1YWdlIHRhZ3MgbWF5IGJlIHVzZWQgaW4gZG9j dW1lbnRzIGFuZCBhcHBsaWNhdGlvbnMNCiAgIHRoYXQgdXNlIG90aGVyIGVuY29kaW5ncywgc28g bG9uZyBhcyB0aGVzZSBlbmNvbXBhc3MgdGhlIFVTLUFTQ0lJDQogICByZXBlcnRvaXJlLiAgQW4g ZXhhbXBsZSBvZiB0aGlzIHdvdWxkIGJlIGFuIFhNTCBkb2N1bWVudCB0aGF0IHVzZXMNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwNSAgICAgICAg ICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgdGhlIFVuaWNvZGUg VVRGLTE2TEUgZW5jb2RpbmcuDQoNCiAgIFRoZSB0YWdzIGFuZCB0aGVpciBzdWJ0YWdzLCBpbmNs dWRpbmcgcHJpdmF0ZS11c2UgYW5kIGV4dGVuc2lvbnMsIGFyZQ0KICAgdG8gYmUgdHJlYXRlZCBh cyBjYXNlIGluc2Vuc2l0aXZlOiB0aGVyZSBleGlzdCBjb252ZW50aW9ucyBmb3IgdGhlDQogICBj YXBpdGFsaXphdGlvbiBvZiBzb21lIG9mIHRoZSBzdWJ0YWdzLCBidXQgdGhlc2Ugc2hvdWxkIG5v dCBiZSB0YWtlbg0KICAgdG8gY2FycnkgbWVhbmluZy4NCg0KICAgRm9yIGV4YW1wbGU6DQoNCiAg IG8gIFtJU08gNjM5XSBbMV0gcmVjb21tZW5kcyB0aGF0IGxhbmd1YWdlIGNvZGVzIGJlIHdyaXR0 ZW4gaW4gbG93ZXINCiAgICAgIGNhc2UgKCdtbicgTW9uZ29saWFuKS4NCg0KICAgbyAgW0lTTyAz MTY2XSBbNF0gcmVjb21tZW5kcyB0aGF0IGNvdW50cnkgY29kZXMgYmUgY2FwaXRhbGl6ZWQgKCdN TicNCiAgICAgIE1vbmdvbGlhKS4NCg0KICAgbyAgW0lTTyAxNTkyNF0gWzNdIHJlY29tbWVuZHMg dGhhdCBzY3JpcHQgY29kZXMgdXNlIGxvd2VyIGNhc2Ugd2l0aA0KICAgICAgdGhlIGluaXRpYWwg bGV0dGVyIGNhcGl0YWxpemVkICgnQ3lybCcgQ3lyaWxsaWMpLg0KDQogICBIb3dldmVyLCBpbiB0 aGUgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQsIHRoZSB1cHBlcmNhc2UgVVMtQVNDSUkN CiAgIGxldHRlcnMgaW4gdGhlIHJhbmdlICdBJyB0aHJvdWdoICdaJyBhcmUgY29uc2lkZXJlZCBl cXVpdmFsZW50IGFuZA0KICAgbWFwcGVkIGRpcmVjdGx5IHRvIHRoZWlyIFVTLUFTQ0lJIGxvd2Vy Y2FzZSBlcXVpdmFsZW50cyBpbiB0aGUgcmFuZ2UNCiAgICdhJyB0aHJvdWdoICd6Jy4gIFRodXMg dGhlIHRhZyAibW4tQ3lybC1NTiIgaXMgbm90IGRpc3RpbmN0IGZyb20gIk1OLQ0KICAgY1lSTC1t biIgb3IgIm1OLWNZckwtTW4iIChvciBhbnkgb3RoZXIgY29tYmluYXRpb24pIGFuZCBlYWNoIG9m IHRoZXNlDQogICB2YXJpYXRpb25zIGNvbnZleXMgdGhlIHNhbWUgbWVhbmluZzogTW9uZ29saWFu IHdyaXR0ZW4gaW4gdGhlDQogICBDeXJpbGxpYyBzY3JpcHQgYXMgdXNlZCBpbiBNb25nb2xpYS4N Cg0KMi4xLjEgIExlbmd0aCBDb25zaWRlcmF0aW9ucw0KDQogICBBbHRob3VnaCBuZWl0aGVyIHRo ZSBBQk5GIG5vciBvdGhlciBndWlkZWxpbmVzIGluIHRoaXMgZG9jdW1lbnQNCiAgIHByb3ZpZGUg YSBmaXhlZCB1cHBlciBsaW1pdCBvbiB0aGUgbnVtYmVyIG9mIHN1YnRhZ3MgaW4gYSBMYW5ndWFn ZQ0KICAgVGFnIChhbmQgdGh1cyB0aGUgdXBwZXIgYm91bmQgb24gdGhlIHNpemUgb2YgYSB0YWcp IGFuZCBpdCBpcw0KICAgcG9zc2libGUgdG8gZW52aXNpb24gcXVpdGUgbG9uZyBhbmQgY29tcGxl eCBzdWJ0YWcgc2VxdWVuY2VzLCBpbg0KICAgcHJhY3RpY2UgdGhlc2UgYXJlIHJhcmUgYmVjYXVz ZSBhZGRpdGlvbmFsIGdyYW51bGFyaXR5IGluIHRhZ3Mgc2VsZG9tDQogICBhZGRzIHVzZWZ1bCBk aXN0aW5ndWlzaGluZyBpbmZvcm1hdGlvbiBhbmQgYmVjYXVzZSBsb25nZXIsIG1vcmUNCiAgIGdy YW51bGFyIHRhZ3MgaW50ZXJlZmVyZSB3aXRoIHRoZSBtZWFuaW5nLCB1bmRlcnN0YW5kaW5nLCBh bmQNCiAgIHByb2Nlc3Npbmcgb2YgbGFuZ3VhZ2UgdGFncy4NCg0KICAgSW4gcGFydGljdWxhciwg IHZhcmlhbnQgc3VidGFncyBTSE9VTEQgYmUgdXNlZCBvbmx5IHdpdGggdGhlaXINCiAgIHJlY29t bWVuZGVkIHByZWZpeC4gIEluIHByYWN0aWNlLCB0aGlzIGxpbWl0cyBtb3N0IHRhZ3MgdG8gYSBz ZXF1ZW5jZQ0KICAgb2YgZm91ciBzdWJ0YWdzLCBhbmQgdGh1cyBhIGxlbmd0aCBvZiAzNSAoZXhj bHVkaW5nIGFueSBleHRlbnNpb25zIG9yDQogICBwcml2YXRlIHVzZSBzZXF1ZW5jZXMpLCBiZWNh dXNlIHN1YnRhZ3MgYXJlIGxpbWl0ZWQgdG8gYSBsZW5ndGggb2YNCiAgIGVpZ2h0IGNoYXJhY3Rl cnMuICBTZWUgU2VjdGlvbiA0LjEgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gc2VsZWN0aW5nDQog ICB0aGUgbW9zdCBhcHByb3ByaWF0ZSBMYW5ndWFnZSBUYWcuDQoNCiAgIEEgY29uZm9ybWFudCBp bXBsZW1lbnRhdGlvbiBNQVkgcmVmdXNlIHRvIHN1cHBvcnQgdGhlIHN0b3JhZ2Ugb2YNCiAgIGxh bmd1YWdlIHRhZ3Mgd2hpY2ggZXhjZWVkIGEgc3BlY2lmaWVkIGxlbmd0aC4gIEZvciBhbiBleGFt cGxlLCBzZWUNCiAgIFtSRkMgMjIzMV0gWzIyXS4gIEFueSBzdWNoIGxpbWl0YXRpb24gTVVTVCBi ZSBjbGVhcmx5IGRvY3VtZW50ZWQsIGFuZA0KICAgc3VjaCBkb2N1bWVudGF0aW9uIFNIT1VMRCBp bmNsdWRlIHRoZSBkaXNwb3NpdGlvbiBvZiBhbnkgbG9uZ2VyIHRhZ3MNCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwNSAgICAgICAgICAgICAgICBb UGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgKGZvciBleGFtcGxlLCB3aGV0aGVy IGFuIGVycm9yIHZhbHVlIGlzIGdlbmVyYXRlZCBvciB0aGUgbGFuZ3VhZ2UgdGFnDQogICBpcyB0 cnVuY2F0ZWQpLiAgSWYgdHJ1bmNhdGlvbiBpcyBwZXJtaXR0ZWQgaXQgU0hPVUxEIE5PVCBwZXJt aXQgYQ0KICAgc3VidGFnIHRvIGJlIGRpdmlkZWQuDQoNCjIuMiAgTGFuZ3VhZ2UgU3VidGFnIFNv dXJjZXMgYW5kIEludGVycHJldGF0aW9uDQoNCiAgIFRoZSBuYW1lc3BhY2Ugb2YgbGFuZ3VhZ2Ug dGFncyBhbmQgdGhlaXIgc3VidGFncyBpcyBhZG1pbmlzdGVyZWQgYnkNCiAgIHRoZSBJbnRlcm5l dCBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0eSAoSUFOQSkgWzEzXSBhY2NvcmRpbmcgdG8gdGhl DQogICBydWxlcyBpbiBTZWN0aW9uIDUgb2YgdGhpcyBkb2N1bWVudC4gIFRoZSByZWdpc3RyeSBt YWludGFpbmVkIGJ5IElBTkENCiAgIGlzIHRoZSBzb3VyY2UgZm9yIHZhbGlkIHN1YnRhZ3M6IG90 aGVyIHN0YW5kYXJkcyByZWZlcmVuY2VkIGluIHRoaXMNCiAgIHNlY3Rpb24gcHJvdmlkZSB0aGUg c291cmNlIG1hdGVyaWFsIGZvciB0aGF0IHJlZ2lzdHJ5Lg0KDQogICBUZXJtaW5vbG9neSBpbiB0 aGlzIHNlY3Rpb246DQoNCiAgIG8gIFRhZyBvciB0YWdzIHJlZmVycyB0byBhIGNvbXBsZXRlIGxh bmd1YWdlIHRhZywgc3VjaCBhcw0KICAgICAgImZyLUxhdG4tQ0EiLiAgRXhhbXBsZXMgb2YgdGFn cyBpbiB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbg0KICAgICAgZG91YmxlLXF1b3RlcyAo ImVuLVVTIikuDQoNCiAgIG8gIFN1YnRhZyByZWZlcnMgdG8gYSBzcGVjaWZpYyBzZWN0aW9uIG9m IGEgdGFnLCBkZWxpbWl0ZWQgYnkgaHlwaGVuLA0KICAgICAgc3VjaCBhcyB0aGUgc3VidGFnICdM YXRuJyBpbiAiZnItTGF0bi1DQSIuICBFeGFtcGxlcyBvZiBzdWJ0YWdzIGluDQogICAgICB0aGlz IGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbiBzaW5nbGUgcXVvdGVzICgnTGF0bicpLg0KDQogICBv ICBDb2RlIG9yIGNvZGVzIHJlZmVycyB0byB2YWx1ZXMgZGVmaW5lZCBpbiBleHRlcm5hbCBzdGFu ZGFyZHMgKGFuZA0KICAgICAgd2hpY2ggYXJlIHVzZWQgYXMgc3VidGFncyBpbiB0aGlzIGRvY3Vt ZW50KS4gIEZvciBleGFtcGxlLCAnTGF0bicNCiAgICAgIGlzIGFuIFtJU08gMTU5MjRdIFszXSBz Y3JpcHQgY29kZSB3aGljaCB3YXMgdXNlZCB0byBkZWZpbmUgdGhlDQogICAgICAnTGF0bicgc2Ny aXB0IHN1YnRhZyBmb3IgdXNlIGluIGEgbGFuZ3VhZ2UgdGFnLiAgRXhhbXBsZXMgb2YgY29kZXMN CiAgICAgIGluIHRoaXMgZG9jdW1lbnQgYXJlIGVuY2xvc2VkIGluIHNpbmdsZSBxdW90ZXMgKCdl bicsICdMYXRuJykuDQoNCiAgIFRoZSBkZWZpbml0aW9ucyBpbiB0aGlzIHNlY3Rpb24gYXBwbHkg dG8gdGhlIHZhcmlvdXMgc3VidGFncyB3aXRoaW4NCiAgIHRoZSBsYW5ndWFnZSB0YWdzIGRlZmlu ZWQgYnkgdGhpcyBkb2N1bWVudCwgZXhjZXB0aW5nIHRob3NlDQogICAiZ3JhbmRmYXRoZXJlZCIg dGFncyBkZWZpbmVkIGluIFNlY3Rpb24gMi4yLjguDQoNCiAgIExhbmd1YWdlIHRhZ3MgYXJlIGRl c2lnbmVkIHNvIHRoYXQgZWFjaCBzdWJ0YWcgdHlwZSBoYXMgdW5pcXVlIGxlbmd0aA0KICAgYW5k IGNvbnRlbnQgcmVzdHJpY3Rpb25zLiAgVGhlc2UgbWFrZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUg c3VidGFnJ3MNCiAgIHR5cGUgcG9zc2libGUsIGV2ZW4gaWYgdGhlIGNvbnRlbnQgb2YgdGhlIHN1 YnRhZyBpdHNlbGYgaXMNCiAgIHVucmVjb2duaXplZC4gIFRoaXMgYWxsb3dzIHRhZ3MgdG8gYmUg cGFyc2VkIGFuZCBwcm9jZXNzZWQgd2l0aG91dA0KICAgcmVmZXJlbmNlIHRvIHRoZSBsYXRlc3Qg dmVyc2lvbiBvZiB0aGUgdW5kZXJseWluZyBzdGFuZGFyZHMgb3IgdGhlDQogICBJQU5BIHJlZ2lz dHJ5IGFuZCBtYWtlcyB0aGUgYXNzb2NpYXRlZCBleGNlcHRpb24gaGFuZGxpbmcgd2hlbg0KICAg cGFyc2luZyB0YWdzIHNpbXBsZXIuDQoNCiAgIFN1YnRhZ3MgaW4gdGhlIElBTkEgcmVnaXN0cnkg dGhhdCBkbyBub3QgY29tZSBmcm9tIGFuIHVuZGVybHlpbmcNCiAgIHN0YW5kYXJkIGNhbiBvbmx5 IGFwcGVhciBpbiBzcGVjaWZpYyBwb3NpdGlvbnMgaW4gYSB0YWcuDQogICBTcGVjaWZpY2FsbHks IHRoZXkgY2FuIG9ubHkgb2NjdXIgYXMgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIG9yIGFzDQog ICB2YXJpYW50IHN1YnRhZ3MuDQoNCiAgIE5vdGUgdGhhdCBzZXF1ZW5jZXMgb2YgcHJpdmF0ZS11 c2UgYW5kIGV4dGVuc2lvbiBzdWJ0YWdzIE1VU1Qgb2NjdXINCiAgIGF0IHRoZSBlbmQgb2YgdGhl IHNlcXVlbmNlIG9mIHN1YnRhZ3MgYW5kIE1VU1QgTk9UIGJlIGludGVyc3BlcnNlZA0KICAgd2l0 aCBzdWJ0YWdzIGRlZmluZWQgZWxzZXdoZXJlIGluIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQpQaGls bGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAg ICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdp c3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIFNpbmdsZSBsZXR0ZXIgYW5k IGRpZ2l0IHN1YnRhZ3MgYXJlIHJlc2VydmVkIGZvciBjdXJyZW50IG9yIGZ1dHVyZQ0KICAgdXNl LiAgVGhlc2UgaW5jbHVkZSB0aGUgZm9sbG93aW5nIGN1cnJlbnQgdXNlczoNCg0KICAgbyAgVGhl IHNpbmdsZSBsZXR0ZXIgc3VidGFnICd4JyBpcyByZXNlcnZlZCB0byBpbnRyb2R1Y2UgYSBzZXF1 ZW5jZQ0KICAgICAgb2YgcHJpdmF0ZS11c2Ugc3VidGFncy4gIFRoZSBpbnRlcnByZXRhdGlvbiBv ZiBhbnkgcHJpdmF0ZS11c2UNCiAgICAgIHN1YnRhZ3MgaXMgZGVmaW5lZCBzb2xlbHkgYnkgcHJp dmF0ZSBhZ3JlZW1lbnQgYW5kIGlzIG5vdCBkZWZpbmVkDQogICAgICBieSB0aGUgcnVsZXMgaW4g dGhpcyBzZWN0aW9uIG9yIGluIGFueSBzdGFuZGFyZCBvciByZWdpc3RyeQ0KICAgICAgZGVmaW5l ZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICBvICBBbGwgb3RoZXIgc2luZ2xlIGxldHRlciBzdWJ0 YWdzIGFyZSByZXNlcnZlZCB0byBpbnRyb2R1Y2UNCiAgICAgIHN0YW5kYXJkaXplZCBleHRlbnNp b24gc3VidGFnIHNlcXVlbmNlcyBhcyBkZXNjcmliZWQgaW4NCiAgICAgIFNlY3Rpb24gMy42Lg0K DQogICBUaGUgc2luZ2xlIGxldHRlciBzdWJ0YWcgJ2knIGlzIHVzZWQgYnkgc29tZSBncmFuZGZh dGhlcmVkIHRhZ3MsIHN1Y2gNCiAgIGFzICJpLWVub2NoaWFuIiwgd2hlcmUgaXQgYWx3YXlzIGFw cGVhcnMgaW4gdGhlIGZpcnN0IHBvc2l0aW9uIGFuZA0KICAgY2Fubm90IGJlIGNvbmZ1c2VkIHdp dGggYW4gZXh0ZW5zaW9uLg0KDQoyLjIuMSAgUHJpbWFyeSBMYW5ndWFnZSBTdWJ0YWcNCg0KICAg VGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGlzIHRoZSBmaXJzdCBzdWJ0YWcgaW4gYSBsYW5n dWFnZSB0YWcNCiAgICh3aXRoIHRoZSBleGNlcHRpb24gb2YgcHJpdmF0ZS11c2UgYW5kIGNlcnRh aW4gZ3JhbmRmYXRoZXJlZCB0YWdzKQ0KICAgYW5kIGNhbm5vdCBiZSBvbWl0dGVkLiAgVGhlIGZv bGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUgcHJpbWFyeQ0KICAgbGFuZ3VhZ2Ugc3VidGFnOg0K DQogICAxLiAgQWxsIDItY2hhcmFjdGVyIGxhbmd1YWdlIHN1YnRhZ3Mgd2VyZSBkZWZpbmVkIGlu IHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cyBm b3VuZCBpbiB0aGUgc3RhbmRhcmQgSVNPDQogICAgICAgNjM5IFBhcnQgMSwgIklTTyA2MzktMToy MDAyLCBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mDQogICAgICAgbmFtZXMgb2YgbGFu Z3VhZ2VzIC0tIFBhcnQgMTogQWxwaGEtMiBjb2RlIiBbSVNPIDYzOS0xXSBbMV0sIG9yDQogICAg ICAgdXNpbmcgYXNzaWdubWVudHMgc3Vic2VxdWVudGx5IG1hZGUgYnkgdGhlIElTTyA2MzkgUGFy dCAxDQogICAgICAgbWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRp b24gYm9kaWVzLg0KDQogICAyLiAgQWxsIDMtY2hhcmFjdGVyIGxhbmd1YWdlIHN1YnRhZ3Mgd2Vy ZSBkZWZpbmVkIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBh c3NpZ25tZW50cyBmb3VuZCBpbiBJU08gNjM5IFBhcnQgMiwNCiAgICAgICAiSVNPIDYzOS0yOjE5 OTggLSBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mDQogICAgICAgbGFu Z3VhZ2VzIC0tIFBhcnQgMjogQWxwaGEtMyBjb2RlIC0gZWRpdGlvbiAxIiBbSVNPIDYzOS0yXSBb Ml0sDQogICAgICAgb3IgYXNzaWdubWVudHMgc3Vic2VxdWVudGx5IG1hZGUgYnkgdGhlIElTTyA2 MzkgUGFydCAyDQogICAgICAgbWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVybmluZyBzdGFuZGFy ZGl6YXRpb24gYm9kaWVzLg0KDQogICAzLiAgVGhlIHN1YnRhZ3MgaW4gdGhlIHJhbmdlICdxYWEn IHRocm91Z2ggJ3F0eicgYXJlIHJlc2VydmVkIGZvcg0KICAgICAgIHByaXZhdGUgdXNlIGluIGxh bmd1YWdlIHRhZ3MuICBUaGVzZSBzdWJ0YWdzIGNvcnJlc3BvbmQgdG8gY29kZXMNCiAgICAgICBy ZXNlcnZlZCBieSBJU08gNjM5LTIgZm9yIHByaXZhdGUgdXNlLiAgVGhlc2UgY29kZXMgTUFZIGJl IHVzZWQNCiAgICAgICBmb3Igbm9uLXJlZ2lzdGVyZWQgcHJpbWFyeS1sYW5ndWFnZSBzdWJ0YWdz IChpbnN0ZWFkIG9mIHVzaW5nDQogICAgICAgcHJpdmF0ZS11c2Ugc3VidGFncyBmb2xsb3dpbmcg J3gtJykuICBQbGVhc2UgcmVmZXIgdG8gU2VjdGlvbiA0LjQNCiAgICAgICBmb3IgbW9yZSBpbmZv cm1hdGlvbiBvbiBwcml2YXRlIHVzZSBzdWJ0YWdzLg0KDQogICA0LiAgQWxsIDQtY2hhcmFjdGVy IGxhbmd1YWdlIHN1YnRhZ3MgYXJlIHJlc2VydmVkIGZvciBwb3NzaWJsZSBmdXR1cmUNCiAgICAg ICBzdGFuZGFyZGl6YXRpb24uDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGly ZXMgT2N0b2JlciAyMiwgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJp bCAyMDA1DQoNCg0KICAgNS4gIEFsbCBsYW5ndWFnZSBzdWJ0YWdzIG9mIDUgdG8gOCBjaGFyYWN0 ZXJzIGluIGxlbmd0aCBpbiB0aGUgSUFOQQ0KICAgICAgIHJlZ2lzdHJ5IHdlcmUgZGVmaW5lZCB2 aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGluIFNlY3Rpb24gMy40DQogICAgICAgYW5kIE1B WSBiZSB1c2VkIHRvIGZvcm0gdGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnLiAgQXQgdGhlIHRp bWUNCiAgICAgICB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkLCB0aGVyZSB3ZXJlIG5vIGV4YW1w bGVzIG9mIHRoaXMga2luZCBvZg0KICAgICAgIHN1YnRhZyBhbmQgZnV0dXJlIHJlZ2lzdHJhdGlv bnMgb2YgdGhpcyB0eXBlIHdpbGwgYmUgZGlzY291cmFnZWQ6DQogICAgICAgcHJpbWFyeSBsYW5n dWFnZXMgYXJlIFNUUk9OR0xZIFJFQ09NTUVOREVEIGZvciByZWdpc3RyYXRpb24gd2l0aA0KICAg ICAgIElTTyA2MzkgYW5kIHByb3Bvc2FscyByZWplY3RlZCBieSBJU08gNjM5L1JBIHdpbGwgYmUg Y2xvc2VseQ0KICAgICAgIHNjcnV0aW5pemVkIGJlZm9yZSB0aGV5IGFyZSByZWdpc3RlcmVkIHdp dGggSUFOQS4NCg0KICAgNi4gIFRoZSBzaW5nbGUgY2hhcmFjdGVyIHN1YnRhZyAneCcgYXMgdGhl IHByaW1hcnkgc3VidGFnIGluZGljYXRlcw0KICAgICAgIHRoYXQgdGhlIGxhbmd1YWdlIHRhZyBj b25zaXN0cyBzb2xlbHkgb2Ygc3VidGFncyB3aG9zZSBtZWFuaW5nIGlzDQogICAgICAgZGVmaW5l ZCBieSBwcml2YXRlIGFncmVlbWVudC4gIEZvciBleGFtcGxlLCBpbiB0aGUgdGFnICJ4LWZyLUNI IiwNCiAgICAgICB0aGUgc3VidGFncyAnZnInIGFuZCAnQ0gnIHNob3VsZCBub3QgYmUgdGFrZW4g dG8gcmVwcmVzZW50IHRoZQ0KICAgICAgIEZyZW5jaCBsYW5ndWFnZSBvciB0aGUgY291bnRyeSBv ZiBTd2l0emVybGFuZCAob3IgYW55IG90aGVyIHZhbHVlDQogICAgICAgaW4gdGhlIElBTkEgcmVn aXN0cnkpIHVubGVzcyB0aGVyZSBpcyBhIHByaXZhdGUgYWdyZWVtZW50IGluDQogICAgICAgcGxh Y2UgdG8gZG8gc28uICBTZWUgU2VjdGlvbiA0LjQuDQoNCiAgIDcuICBUaGUgc2luZ2xlIGNoYXJh Y3RlciBzdWJ0YWcgJ2knIGlzIHVzZWQgYnkgc29tZSBncmFuZGZhdGhlcmVkDQogICAgICAgdGFn cyAoc2VlIFNlY3Rpb24gMi4yLjgpIHN1Y2ggYXMgImkta2xpbmdvbiIgYW5kICJpLWJubiIuICAo T3RoZXINCiAgICAgICBncmFuZGZhdGhlcmVkIHRhZ3MgaGF2ZSBhIHByaW1hcnkgbGFuZ3VhZ2Ug c3VidGFnIGluIHRoZWlyIGZpcnN0DQogICAgICAgcG9zaXRpb24pDQoNCiAgIDguICBPdGhlciB2 YWx1ZXMgTVVTVCBOT1QgYmUgYXNzaWduZWQgdG8gdGhlIHByaW1hcnkgc3VidGFnIGV4Y2VwdCBi eQ0KICAgICAgIHJldmlzaW9uIG9yIHVwZGF0ZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBOb3Rl OiBGb3IgbGFuZ3VhZ2VzIHRoYXQgaGF2ZSBib3RoIGFuIElTTyA2MzktMSAyLWNoYXJhY3RlciBj b2RlIGFuZA0KICAgYW4gSVNPIDYzOS0yIDMtY2hhcmFjdGVyIGNvZGUsIG9ubHkgdGhlIElTTyA2 MzktMSAyLWNoYXJhY3RlciBjb2RlIGlzDQogICBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5 Lg0KDQogICBOb3RlOiBGb3IgbGFuZ3VhZ2VzIHRoYXQgaGF2ZSBubyBJU08gNjM5LTEgMi1jaGFy YWN0ZXIgY29kZSBhbmQgZm9yDQogICB3aGljaCB0aGUgSVNPIDYzOS0yL1QgKFRlcm1pbm9sb2d5 KSBjb2RlIGFuZCB0aGUgSVNPIDYzOS0yL0INCiAgIChCaWJsaW9ncmFwaGljKSBjb2RlcyBkaWZm ZXIsIG9ubHkgdGhlIFRlcm1pbm9sb2d5IGNvZGUgaXMgZGVmaW5lZCBpbg0KICAgdGhlIElBTkEg cmVnaXN0cnkuICBBdCB0aGUgdGltZSB0aGlzIGRvY3VtZW50IHdhcyBjcmVhdGVkLCBhbGwNCiAg IGxhbmd1YWdlcyB0aGF0IGhhZCBib3RoIGtpbmRzIG9mIDMtY2hhcmFjdGVyIGNvZGUgd2VyZSBh bHNvIGFzc2lnbmVkDQogICBhIDItY2hhcmFjdGVyIGNvZGU7IGl0IGlzIG5vdCBleHBlY3RlZCB0 aGF0IGZ1dHVyZSBhc3NpZ25tZW50cyBvZg0KICAgdGhpcyBuYXR1cmUgd2lsbCBvY2N1ci4NCg0K ICAgTm90ZTogVG8gYXZvaWQgcHJvYmxlbXMgd2l0aCB2ZXJzaW9uaW5nIGFuZCBzdWJ0YWcgY2hv aWNlIGFzDQogICBleHBlcmllbmNlZCBkdXJpbmcgdGhlIHRyYW5zaXRpb24gYmV0d2VlbiBSRkMg MTc2NiBhbmQgUkZDIDMwNjYsIGFzDQogICB3ZWxsIGFzIHRoZSBjYW5vbmljYWwgbmF0dXJlIG9m IHN1YnRhZ3MgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50LCB0aGUNCiAgIElTTyA2MzkgUmVnaXN0 cmF0aW9uIEF1dGhvcml0eSBKb2ludCBBZHZpc29yeSBDb21taXR0ZWUgKElTTyA2MzkvDQogICBS QS1KQUMpIGhhcyBpbmNsdWRlZCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBpbiBbMTddOg0KDQog ICAiQSBsYW5ndWFnZSBjb2RlIGFscmVhZHkgaW4gSVNPIDYzOS0yIGF0IHRoZSBwb2ludCBvZiBm cmVlemluZyBJU08NCiAgIDYzOS0xIHNoYWxsIG5vdCBsYXRlciBiZSBhZGRlZCB0byBJU08gNjM5 LTEuICBUaGlzIGlzIHRvIGVuc3VyZQ0KICAgY29uc2lzdGVuY3kgaW4gdXNhZ2Ugb3ZlciB0aW1l LCBzaW5jZSB1c2VycyBhcmUgZGlyZWN0ZWQgaW4gSW50ZXJuZXQNCiAgIGFwcGxpY2F0aW9ucyB0 byBlbXBsb3kgdGhlIGFscGhhLTMgY29kZSB3aGVuIGFuIGFscGhhLTIgY29kZSBmb3IgdGhhdA0K ICAgbGFuZ3VhZ2UgaXMgbm90IGF2YWlsYWJsZS4iDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIEluIG9yZGVyIHRvIGF2b2lkIGluc3RhYmlsaXR5IG9m IHRoZSBjYW5vbmljYWwgZm9ybSBvZiB0YWdzLCBpZiBhDQogICAyLWNoYXJhY3RlciBjb2RlIGlz IGFkZGVkIHRvIElTTyA2MzktMSBmb3IgYSBsYW5ndWFnZSBmb3Igd2hpY2ggYQ0KICAgMy1jaGFy YWN0ZXIgY29kZSB3YXMgYWxyZWFkeSBpbmNsdWRlZCBpbiBJU08gNjM5LTIsIHRoZSAyLWNoYXJh Y3Rlcg0KICAgY29kZSB3aWxsIG5vdCBiZSBhZGRlZCBhcyBhIHN1YnRhZyBpbiB0aGUgcmVnaXN0 cnkuICBTZWUgU2VjdGlvbiAzLjMuDQoNCiAgIEZvciBleGFtcGxlLCBpZiBzb21lIGNvbnRlbnQg d2VyZSB0YWdnZWQgd2l0aCAnaGF3JyAoSGF3YWlpYW4pLCB3aGljaA0KICAgY3VycmVudGx5IGhh cyBubyAyLWNoYXJhY3RlciBjb2RlLCB0aGUgdGFnIHdvdWxkIG5vdCBiZSBpbnZhbGlkYXRlZA0K ICAgaWYgSVNPIDYzOS0xIHdlcmUgdG8gYXNzaWduIGEgMi1jaGFyYWN0ZXIgY29kZSB0byB0aGUg SGF3YWlpYW4NCiAgIGxhbmd1YWdlIGF0IGEgbGF0ZXIgZGF0ZS4NCg0KICAgRm9yIGV4YW1wbGUs IG9uZSBvZiB0aGUgZ3JhbmRmYXRoZXJlZCBJQU5BIHJlZ2lzdHJhdGlvbnMgaXMNCiAgICJpLWVu b2NoaWFuIi4gIFRoZSBzdWJ0YWcgJ2Vub2NoaWFuJyBjb3VsZCBiZSByZWdpc3RlcmVkIGluIHRo ZSBJQU5BDQogICByZWdpc3RyeSBhcyBhIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIChhc3N1bWlu ZyB0aGF0IElTTyA2MzkgZG9lcyBub3QNCiAgIHJlZ2lzdGVyIHRoaXMgbGFuZ3VhZ2UgZmlyc3Qp LCBtYWtpbmcgdGFncyBzdWNoIGFzICJlbm9jaGlhbi1BUSIgYW5kDQogICAiZW5vY2hpYW4tTGF0 biIgdmFsaWQuDQoNCjIuMi4yICBFeHRlbmRlZCBMYW5ndWFnZSBTdWJ0YWdzDQoNCiAgIFRoZSBm b2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3M6DQoN CiAgIDEuICBUaHJlZSBsZXR0ZXIgc3VidGFncyBpbW1lZGlhdGVseSBmb2xsb3dpbmcgdGhlIHBy aW1hcnkgc3VidGFnIGFyZQ0KICAgICAgIHJlc2VydmVkIGZvciBmdXR1cmUgc3RhbmRhcmRpemF0 aW9uLCBhbnRpY2lwYXRpbmcgd29yayB0aGF0IGlzDQogICAgICAgY3VycmVudGx5IHVuZGVyIHdh eSBvbiBJU08gNjM5Lg0KDQogICAyLiAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBNVVNUIGZv bGxvdyB0aGUgcHJpbWFyeSBzdWJ0YWcgYW5kDQogICAgICAgcHJlY2VkZSBhbnkgb3RoZXIgc3Vi dGFncy4NCg0KICAgMy4gIFRoZXJlIE1BWSBiZSBhbnkgYWRkaXRpb25hbCBudW1iZXIgb2YgZXh0 ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncy4NCg0KICAgNC4gIEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRh Z3Mgd2lsbCBub3QgYmUgcmVnaXN0ZXJlZCBleGNlcHQgYnkNCiAgICAgICByZXZpc2lvbiBvZiB0 aGlzIGRvY3VtZW50Lg0KDQogICA1LiAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBNVVNUIE5P VCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncw0KICAgICAgIGV4Y2VwdCBieSByZXZpc2lv biBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBFeGFtcGxlOiBJbiBhIGZ1dHVyZSByZXZpc2lvbiBv ciB1cGRhdGUgb2YgdGhpcyBkb2N1bWVudCwgdGhlIHRhZw0KICAgInpoLWdhbiIgKHJlZ2lzdGVy ZWQgdW5kZXIgUkZDIDMwNjYpIG1pZ2h0IGJlY29tZSBhIHZhbGlkIG5vbi0NCiAgIGdyYW5kZmF0 aGVyZWQgKHRoYXQgaXMsIHJlZHVuZGFudCkgdGFnIGluIHdoaWNoIHRoZSBzdWJ0YWcgJ2dhbicN CiAgIG1pZ2h0IHJlcHJlc2VudCB0aGUgQ2hpbmVzZSBkaWFsZWN0ICdHYW4nLg0KDQoyLjIuMyAg U2NyaXB0IFN1YnRhZw0KDQogICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZSBzY3Jp cHQgc3VidGFnczoNCg0KICAgMS4gIEFsbCA0LWNoYXJhY3RlciBzdWJ0YWdzIHdlcmUgZGVmaW5l ZCBhY2NvcmRpbmcgdG8gSVNPIDE1OTI0DQogICAgICAgWzNdLS0iQ29kZXMgZm9yIHRoZSByZXBy ZXNlbnRhdGlvbiBvZiB0aGUgbmFtZXMgb2Ygc2NyaXB0cyI6DQogICAgICAgYWxwaGEtNCBzY3Jp cHQgY29kZXMsIG9yIHN1YnNlcXVlbnRseSBhc3NpZ25lZCBieSB0aGUgSVNPIDE1OTI0DQogICAg ICAgbWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVz LCBkZW5vdGluZw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVy IDIyLCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0K DQogICAgICAgdGhlIHNjcmlwdCBvciB3cml0aW5nIHN5c3RlbSB1c2VkIGluIGNvbmp1bmN0aW9u IHdpdGggdGhpcw0KICAgICAgIGxhbmd1YWdlLg0KDQogICAyLiAgU2NyaXB0IHN1YnRhZ3MgTVVT VCBpbW1lZGlhdGVseSBmb2xsb3cgdGhlIHByaW1hcnkgbGFuZ3VhZ2UNCiAgICAgICBzdWJ0YWcg YW5kIGFsbCBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIGFuZCBNVVNUIG9jY3VyIGJlZm9yZQ0K ICAgICAgIGFueSBvdGhlciB0eXBlIG9mIHN1YnRhZyBkZXNjcmliZWQgYmVsb3cuDQoNCiAgIDMu ICBUaGUgc2NyaXB0IHN1YnRhZ3MgJ1FhYWEnIHRocm91Z2ggJ1FhYngnIGFyZSByZXNlcnZlZCBm b3IgcHJpdmF0ZQ0KICAgICAgIHVzZSBpbiBsYW5ndWFnZSB0YWdzLiAgVGhlc2Ugc3VidGFncyBj b3JyZXNwb25kIHRvIGNvZGVzIHJlc2VydmVkDQogICAgICAgYnkgSVNPIDE1OTI0IGZvciBwcml2 YXRlIHVzZS4gIFRoZXNlIGNvZGVzIE1BWSBiZSB1c2VkIGZvciBub24tDQogICAgICAgcmVnaXN0 ZXJlZCBzY3JpcHQgdmFsdWVzLiAgUGxlYXNlIHJlZmVyIHRvIFNlY3Rpb24gNC40IGZvciBtb3Jl DQogICAgICAgaW5mb3JtYXRpb24gb24gcHJpdmF0ZS11c2Ugc3VidGFncy4NCg0KICAgNC4gIFNj cmlwdCBzdWJ0YWdzIGNhbm5vdCBiZSByZWdpc3RlcmVkIHVzaW5nIHRoZSBwcm9jZXNzIGluDQog ICAgICAgU2VjdGlvbiAzLjQgb2YgdGhpcyBkb2N1bWVudC4gIFZhcmlhbnQgc3VidGFncyBtYXkg YmUgY29uc2lkZXJlZA0KICAgICAgIGZvciByZWdpc3RyYXRpb24gZm9yIHRoYXQgcHVycG9zZS4N Cg0KICAgRXhhbXBsZTogImRlLUxhdG4iIHJlcHJlc2VudHMgR2VybWFuIHdyaXR0ZW4gdXNpbmcg dGhlIExhdGluIHNjcmlwdC4NCg0KMi4yLjQgIFJlZ2lvbiBTdWJ0YWcNCg0KICAgVGhlIGZvbGxv d2luZyBydWxlcyBhcHBseSB0byB0aGUgcmVnaW9uIHN1YnRhZ3M6DQoNCiAgIDEuICBUaGUgcmVn aW9uIHN1YnRhZyBkZWZpbmVzIGxhbmd1YWdlIHZhcmlhdGlvbnMgdXNlZCBpbiBhIHNwZWNpZmlj DQogICAgICAgcmVnaW9uLCBnZW9ncmFwaGljLCBvciBwb2xpdGljYWwgYXJlYS4gIFJlZ2lvbiBz dWJ0YWdzIE1VU1QNCiAgICAgICBmb2xsb3cgYW55IGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFn ZSwgb3Igc2NyaXB0IHN1YnRhZ3MgYW5kDQogICAgICAgTVVTVCBwcmVjZWRlIGFsbCBvdGhlciBz dWJ0YWdzLg0KDQogICAyLiAgQWxsIDItY2hhcmFjdGVyIHN1YnRhZ3MgZm9sbG93aW5nIHRoZSBw cmltYXJ5IHN1YnRhZyB3ZXJlIGRlZmluZWQNCiAgICAgICBpbiB0aGUgSUFOQSByZWdpc3RyeSBh Y2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1lbnRzIGZvdW5kIGluIElTTw0KICAgICAgIDMxNjYgWzRd LS0iQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBjb3VudHJpZXMgYW5k DQogICAgICAgdGhlaXIgc3ViZGl2aXNpb25zIC0gUGFydCAxOiBDb3VudHJ5IGNvZGVzIi0tYWxw aGEtMiBjb3VudHJ5DQogICAgICAgY29kZXMgb3IgYXNzaWdubWVudHMgc3Vic2VxdWVudGx5IG1h ZGUgYnkgdGhlIElTTyAzMTY2DQogICAgICAgbWFpbnRlbmFuY2UgYWdlbmN5IG9yIGdvdmVybmlu ZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLg0KDQogICAzLiAgQWxsIDMtY2hhcmFjdGVyIGNvZGVz IGNvbnNpc3Rpbmcgb2YgZGlnaXQgKG51bWVyaWMpIGNoYXJhY3RlcnMNCiAgICAgICB3ZXJlIGRl ZmluZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cw0K ICAgICAgIGZvdW5kIGluIFVOIFN0YW5kYXJkIENvdW50cnkgb3IgQXJlYSBDb2RlcyBmb3IgU3Rh dGlzdGljYWwgIFVzZQ0KICAgICAgIFs1XSBvciBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkgbWFk ZSBieSB0aGUgZ292ZXJuaW5nIHN0YW5kYXJkcw0KICAgICAgIGJvZHkuICBOb3RlIHRoYXQgbm90 IGFsbCBvZiB0aGUgVU4gTS40OSBjb2RlcyBhcmUgZGVmaW5lZCBpbiB0aGUNCiAgICAgICBJQU5B IHJlZ2lzdHJ5Og0KDQogICAgICAgQS4gIFVOIG51bWVyaWMgY29kZXMgYXNzaWduZWQgdG8gJ21h Y3JvLWdlb2dyYXBoaWNhbA0KICAgICAgICAgICAoY29udGluZW50YWwpJyBvciBzdWItcmVnaW9u cyBub3QgYXNzb2NpYXRlZCB3aXRoIGFuIGFzc2lnbmVkDQogICAgICAgICAgIElTTyAzMTY2IGFs cGhhLTIgY29kZSBfYXJlXyBkZWZpbmVkLg0KDQogICAgICAgQi4gIFVOIG51bWVyaWMgY29kZXMg Zm9yICdlY29ub21pYyBncm91cGluZ3MnIG9yICdvdGhlcg0KICAgICAgICAgICBncm91cGluZ3Mn IGFyZSBfbm90XyBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFuZCBNVVNUDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAg ICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgICAgICAgICAgTk9UIGJl IHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzLg0KDQogICAgICAgQy4gIFVOIG51bWVyaWMgY29k ZXMgZm9yIGNvdW50cmllcyB3aXRoIGFtYmlndW91cyBJU08gMzE2Ng0KICAgICAgICAgICBhbHBo YS0yIGNvZGVzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjMgYXJlIGRlZmluZWQgaW4gdGhlDQog ICAgICAgICAgIHJlZ2lzdHJ5IGFuZCBhcmUgY2Fub25pY2FsIGZvciB0aGUgZ2l2ZW4gY291bnRy eSBvciByZWdpb24NCiAgICAgICAgICAgZGVmaW5lZC4NCg0KICAgICAgIEQuICBUaGUgYWxwaGFu dW1lcmljIGNvZGVzIGluIEFwcGVuZGl4IFggb2YgdGhlIFVOIGRvY3VtZW50IGFyZQ0KICAgICAg ICAgICBfbm90XyBkZWZpbmVkIGFuZCBNVVNUIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2Ug dGFncy4NCiAgICAgICAgICAgKEF0IHRoZSB0aW1lIHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQg dGhlc2UgdmFsdWVzIG1hdGNoIHRoZQ0KICAgICAgICAgICBJU08gMzE2NiBhbHBoYS0yIGNvZGVz LikNCg0KICAgNC4gIFRoZXJlIG1heSBiZSBhdCBtb3N0IG9uZSByZWdpb24gc3VidGFnIGluIGEg bGFuZ3VhZ2UgdGFnLg0KDQogICA1LiAgVGhlIHJlZ2lvbiBzdWJ0YWdzICdBQScsICdRTSctJ1Fa JywgJ1hBJy0nWFonLCBhbmQgJ1paJyBhcmUNCiAgICAgICByZXNlcnZlZCBmb3IgcHJpdmF0ZSB1 c2UgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoZXNlIHN1YnRhZ3MNCiAgICAgICBjb3JyZXNwb25kIHRv IGNvZGVzIHJlc2VydmVkIGJ5IElTTyAzMTY2IGZvciBwcml2YXRlIHVzZS4gIFRoZXNlDQogICAg ICAgY29kZXMgTUFZIGJlIHVzZWQgZm9yIHByaXZhdGUgdXNlIHJlZ2lvbiBzdWJ0YWdzIChpbnN0 ZWFkIG9mDQogICAgICAgdXNpbmcgYSBwcml2YXRlLXVzZSBzdWJ0YWcgc2VxdWVuY2UpLiAgUGxl YXNlIHJlZmVyIHRvDQogICAgICAgU2VjdGlvbiA0LjQgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24g cHJpdmF0ZSB1c2Ugc3VidGFncy4NCg0KICAgImRlLUNIIiByZXByZXNlbnRzIEdlcm1hbiAoJ2Rl JykgYXMgdXNlZCBpbiBTd2l0emVybGFuZCAoJ0NIJykuDQoNCiAgICJzci1MYXRuLUNTIiByZXBy ZXNlbnRzIFNlcmJpYW4gKCdzcicpIHdyaXR0ZW4gdXNpbmcgTGF0aW4gc2NyaXB0DQogICAoJ0xh dG4nKSBhcyB1c2VkIGluIFNlcmJpYSBhbmQgTW9udGVuZWdybyAoJ0NTJykuDQoNCiAgICJlcy00 MTkiIHJlcHJlc2VudHMgU3BhbmlzaCAoJ2VzJykgYXMgdXNlZCBpbiB0aGUgVU4tZGVmaW5lZCBM YXRpbg0KICAgQW1lcmljYSBhbmQgQ2FyaWJiZWFuIHJlZ2lvbiAoJzQxOScpLg0KDQoyLjIuNSAg VmFyaWFudCBTdWJ0YWdzDQoNCiAgIFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIHZh cmlhbnQgc3VidGFnczoNCg0KICAgMS4gIFZhcmlhbnQgc3VidGFncyBhcmUgbm90IGFzc29jaWF0 ZWQgd2l0aCBhbnkgZXh0ZXJuYWwgc3RhbmRhcmQuDQogICAgICAgVmFyaWFudCBzdWJ0YWdzIGFu ZCB0aGVpciBtZWFuaW5ncyBhcmUgZGVmaW5lZCBieSB0aGUNCiAgICAgICByZWdpc3RyYXRpb24g cHJvY2VzcyBkZWZpbmVkIGluIFNlY3Rpb24gMy40Lg0KDQogICAyLiAgVmFyaWFudCBzdWJ0YWdz IE1VU1QgZm9sbG93IGFsbCBvZiB0aGUgb3RoZXIgZGVmaW5lZCBzdWJ0YWdzLCBidXQNCiAgICAg ICBwcmVjZWRlIGFueSBleHRlbnNpb24gb3IgcHJpdmF0ZS11c2Ugc3VidGFnIHNlcXVlbmNlcy4N Cg0KICAgMy4gIE1vcmUgdGhhbiBvbmUgdmFyaWFudCBNQVkgYmUgdXNlZCB0byBmb3JtIHRoZSBs YW5ndWFnZSB0YWcuDQoNCiAgIDQuICBWYXJpYW50IHN1YnRhZ3MgTVVTVCBiZSByZWdpc3RlcmVk IHdpdGggSUFOQSBhY2NvcmRpbmcgdG8gdGhlDQogICAgICAgcnVsZXMgaW4gU2VjdGlvbiAzLjQg b2YgdGhpcyBkb2N1bWVudCBiZWZvcmUgYmVpbmcgdXNlZCB0byBmb3JtDQogICAgICAgbGFuZ3Vh Z2UgdGFncy4gIEluIG9yZGVyIHRvIGRpc3Rpbmd1aXNoIHZhcmlhbnRzIGZyb20gb3RoZXIgdHlw ZXMNCiAgICAgICBvZiBzdWJ0YWdzLCByZWdpc3RyYXRpb25zIG11c3QgbWVldCB0aGUgZm9sbG93 aW5nIGxlbmd0aCBhbmQNCiAgICAgICBjb250ZW50IHJlc3RyaWN0aW9uczoNCg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1ICAgICAgICAgICAg ICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICAgICAgMS4gIFZhcmlhbnQg c3VidGFncyB0aGF0IGJlZ2luIHdpdGggYSBsZXR0ZXIgKGEteiwgQS1aKSBNVVNUIGJlDQogICAg ICAgICAgIGF0IGxlYXN0IGZpdmUgY2hhcmFjdGVycyBsb25nLg0KDQogICAgICAgMi4gIFZhcmlh bnQgc3VidGFncyB0aGF0IGJlZ2luIHdpdGggYSBkaWdpdCAoMC05KSBNVVNUIGJlIGF0DQogICAg ICAgICAgIGxlYXN0IGZvdXIgY2hhcmFjdGVycyBsb25nLg0KDQogICAiZW4tc2NvdXNlIiByZXBy ZXNlbnRzIHRoZSBTY291c2UgZGlhbGVjdCBvZiBFbmdsaXNoLg0KDQogICAiZGUtQ0gtMTk5NiIg cmVwcmVzZW50cyBHZXJtYW4gYXMgdXNlZCBpbiBTd2l0emVybGFuZCBhbmQgYXMgd3JpdHRlbg0K ICAgdXNpbmcgdGhlIHNwZWxsaW5nIHJlZm9ybSBiZWdpbm5pbmcgaW4gdGhlIHllYXIgMTk5NiBD LkUuDQoNCjIuMi42ICBFeHRlbnNpb24gU3VidGFncw0KDQogICBUaGUgZm9sbG93aW5nIHJ1bGVz IGFwcGx5IHRvIGV4dGVuc2lvbnM6DQoNCiAgIDEuICAgRXh0ZW5zaW9uIHN1YnRhZ3MgYXJlIHNl cGFyYXRlZCBmcm9tIHRoZSBvdGhlciBzdWJ0YWdzIGRlZmluZWQNCiAgICAgICAgaW4gdGhpcyBk b2N1bWVudCBieSBhIHNpbmdsZS1sZXR0ZXIgc3VidGFnICgic2luZ2xldG9uIikuICBUaGUNCiAg ICAgICAgc2luZ2xldG9uIE1VU1QgYmUgb25lIGFsbG9jYXRlZCB0byBhIHJlZ2lzdHJhdGlvbiBh dXRob3JpdHkgdmlhDQogICAgICAgIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFNlY3Rpb24g My42IGFuZCBjYW5ub3QgYmUgdGhlIGxldHRlcg0KICAgICAgICAneCcsIHdoaWNoIGlzIHJlc2Vy dmVkIGZvciBwcml2YXRlLXVzZSBzdWJ0YWcgc2VxdWVuY2VzLg0KDQogICAyLiAgIE5vdGU6IFBy aXZhdGUtdXNlIHN1YnRhZyBzZXF1ZW5jZXMgc3RhcnRpbmcgd2l0aCB0aGUgc2luZ2xldG9uDQog ICAgICAgIHN1YnRhZyAneCcgYXJlIGRlc2NyaWJlZCBiZWxvdy4NCg0KICAgMy4gICBBbiBleHRl bnNpb24gTVVTVCBmb2xsb3cgYXQgbGVhc3QgYSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZy4NCiAg ICAgICAgVGhhdCBpcywgYSBsYW5ndWFnZSB0YWcgY2Fubm90IGJlZ2luIHdpdGggYW4gZXh0ZW5z aW9uLg0KICAgICAgICBFeHRlbnNpb25zIGV4dGVuZCBsYW5ndWFnZSB0YWdzLCB0aGV5IGRvIG5v dCBvdmVycmlkZSBvciByZXBsYWNlDQogICAgICAgIHRoZW0uICBGb3IgZXhhbXBsZSwgImEtdmFs dWUiIGlzIG5vdCBhIHdlbGwtZm9ybWVkIGxhbmd1YWdlIHRhZywNCiAgICAgICAgd2hpbGUgImRl LWEtdmFsdWUiIGlzLg0KDQogICA0LiAgIEVhY2ggc2luZ2xldG9uIHN1YnRhZyBNVVNUIGFwcGVh ciBhdCBtb3N0IG9uZSB0aW1lIGluIGVhY2ggdGFnDQogICAgICAgIChvdGhlciB0aGFuIGFzIGEg cHJpdmF0ZS11c2Ugc3VidGFnKS4gIFRoYXQgaXMsIHNpbmdsZXRvbg0KICAgICAgICBzdWJ0YWdz IE1VU1QgTk9UIGJlIHJlcGVhdGVkLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgImVuLWEtYmJiLWEt DQogICAgICAgIGNjYyIgaXMgaW52YWxpZCBiZWNhdXNlIHRoZSBzdWJ0YWcgJ2EnIGFwcGVhcnMg dHdpY2UuICBOb3RlIHRoYXQNCiAgICAgICAgdGhlIHRhZyAiZW4tYS1iYmIteC1hLWNjYyIgaXMg dmFsaWQgYmVjYXVzZSB0aGUgc2Vjb25kDQogICAgICAgIGFwcGVhcmFuY2Ugb2YgdGhlIHNpbmds ZXRvbiAnYScgaXMgaW4gYSBwcml2YXRlIHVzZSBzZXF1ZW5jZS4NCg0KICAgNS4gICBFeHRlbnNp b24gc3VidGFncyBNVVNUIG1lZXQgYWxsIG9mIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZQ0KICAg ICAgICBjb250ZW50IGFuZCBmb3JtYXQgb2Ygc3VidGFncyBkZWZpbmVkIGluIHRoaXMgZG9jdW1l bnQuDQoNCiAgIDYuICAgRXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBtZWV0IHdoYXRldmVyIHJlcXVp cmVtZW50cyBhcmUgc2V0IGJ5IHRoZQ0KICAgICAgICBkb2N1bWVudCB0aGF0IGRlZmluZXMgdGhl aXIgc2luZ2xldG9uIHByZWZpeCBhbmQgd2hhdGV2ZXINCiAgICAgICAgcmVxdWlyZW1lbnRzIGFy ZSBwcm92aWRlZCBieSB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5Lg0KDQogICA3LiAgIEVhY2gg ZXh0ZW5zaW9uIHN1YnRhZyBNVVNUIGJlIGZyb20gdHdvIHRvIGVpZ2h0IGNoYXJhY3RlcnMgbG9u Zw0KICAgICAgICBhbmQgY29uc2lzdCBzb2xlbHkgb2YgbGV0dGVycyBvciBkaWdpdHMsIHdpdGgg ZWFjaCBzdWJ0YWcNCiAgICAgICAgc2VwYXJhdGVkIGJ5IGEgc2luZ2xlICctJy4NCg0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1ICAgICAgICAg ICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICA4LiAgIEVhY2ggc2lu Z2xldG9uIE1VU1QgYmUgZm9sbG93ZWQgYnkgYXQgbGVhc3Qgb25lIGV4dGVuc2lvbg0KICAgICAg ICBzdWJ0YWcuICBGb3IgZXhhbXBsZSwgdGhlIHRhZyAidGxoLWEtYi1mb28iIGlzIGludmFsaWQg YmVjYXVzZQ0KICAgICAgICB0aGUgZmlyc3Qgc2luZ2xldG9uICdhJyBpcyBmb2xsb3dlZCBpbW1l ZGlhdGVseSBieSBhbm90aGVyDQogICAgICAgIHNpbmdsZXRvbiAnYicuDQoNCiAgIDkuICAgRXh0 ZW5zaW9uIHN1YnRhZ3MgTVVTVCBmb2xsb3cgYWxsIGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFn ZSwNCiAgICAgICAgc2NyaXB0LCByZWdpb24gYW5kIHZhcmlhbnQgc3VidGFncyBpbiBhIHRhZy4N Cg0KICAgMTAuICBBbGwgc3VidGFncyBmb2xsb3dpbmcgdGhlIHNpbmdsZXRvbiBhbmQgYmVmb3Jl IGFub3RoZXIgc2luZ2xldG9uDQogICAgICAgIGFyZSBwYXJ0IG9mIHRoZSBleHRlbnNpb24uICBF eGFtcGxlOiBJbiB0aGUgdGFnICJmci1hLUxhdG4iLCB0aGUNCiAgICAgICAgc3VidGFnICdMYXRu JyBkb2VzIG5vdCByZXByZXNlbnQgdGhlIHNjcmlwdCBzdWJ0YWcgJ0xhdG4nDQogICAgICAgIGRl ZmluZWQgaW4gdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5LiAgSXRzIG1lYW5pbmcg aXMNCiAgICAgICAgZGVmaW5lZCBieSB0aGUgZXh0ZW5zaW9uICdhJy4NCg0KICAgMTEuICBJbiB0 aGUgZXZlbnQgdGhhdCBtb3JlIHRoYW4gb25lIGV4dGVuc2lvbiBhcHBlYXJzIGluIGEgc2luZ2xl DQogICAgICAgIHRhZywgdGhlIHRhZyBTSE9VTEQgYmUgY2Fub25pY2FsaXplZCBhcyBkZXNjcmli ZWQgaW4NCiAgICAgICAgU2VjdGlvbiA0LjMuDQoNCiAgIEZvciBleGFtcGxlLCBpZiB0aGUgcHJl Zml4IHNpbmdsZXRvbiAncicgYW5kIHRoZSBzaG93biBzdWJ0YWdzIHdlcmUNCiAgIGRlZmluZWQs IHRoZW4gdGhlIGZvbGxvd2luZyB0YWcgd291bGQgYmUgYSB2YWxpZCBleGFtcGxlOiAiZW4tTGF0 bi0NCiAgIEdCLWJvb250LXItZXh0ZW5kZWQtc2VxdWVuY2UteC1wcml2YXRlIg0KDQoyLjIuNyAg UHJpdmF0ZSBVc2UgU3VidGFncw0KDQogICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHBy aXZhdGUtdXNlIHN1YnRhZ3M6DQoNCiAgIDEuICBQcml2YXRlLXVzZSBzdWJ0YWdzIGFyZSBzZXBh cmF0ZWQgZnJvbSB0aGUgb3RoZXIgc3VidGFncyBkZWZpbmVkDQogICAgICAgaW4gdGhpcyBkb2N1 bWVudCBieSB0aGUgcmVzZXJ2ZWQgc2luZ2xlLWNoYXJhY3RlciBzdWJ0YWcgJ3gnLg0KDQogICAy LiAgUHJpdmF0ZS11c2Ugc3VidGFncyBNVVNUIGZvbGxvdyBhbGwgbGFuZ3VhZ2UsIGV4dGVuZGVk IGxhbmd1YWdlLA0KICAgICAgIHNjcmlwdCwgcmVnaW9uLCB2YXJpYW50LCBhbmQgZXh0ZW5zaW9u IHN1YnRhZ3MgaW4gdGhlIHRhZy4NCiAgICAgICBBbm90aGVyIHdheSBvZiBzYXlpbmcgdGhpcyBp cyB0aGF0IGFsbCBzdWJ0YWdzIGZvbGxvd2luZyB0aGUNCiAgICAgICBzaW5nbGV0b24gJ3gnIE1V U1QgYmUgY29uc2lkZXJlZCBwcml2YXRlIHVzZS4gIEV4YW1wbGU6IFRoZQ0KICAgICAgIHN1YnRh ZyAnVVMnIGluIHRoZSB0YWcgImVuLXgtVVMiIGlzIGEgcHJpdmF0ZSB1c2Ugc3VidGFnLg0KDQog ICAzLiAgQSB0YWcgTUFZIGNvbnNpc3QgZW50aXJlbHkgb2YgcHJpdmF0ZS11c2Ugc3VidGFncy4N Cg0KICAgNC4gIE5vIHNvdXJjZSBpcyBkZWZpbmVkIGZvciBwcml2YXRlIHVzZSBzdWJ0YWdzLiAg VXNlIG9mIHByaXZhdGUgdXNlDQogICAgICAgc3VidGFncyBpcyBieSBwcml2YXRlIGFncmVlbWVu dCBvbmx5Lg0KDQogICBGb3IgZXhhbXBsZTogVXNlcnMgd2hvIHdpc2hlZCB0byB1dGlsaXplIFNJ TCBFdGhub2xvZ3VlIGZvcg0KICAgaWRlbnRpZmljYXRpb24gbWlnaHQgYWdyZWUgdG8gZXhjaGFu Z2UgdGFncyBzdWNoIGFzICJhei1BcmFiLXgtQVpFLQ0KICAgZGVyYmVuZCIuICBUaGlzIGV4YW1w bGUgY29udGFpbnMgdHdvIHByaXZhdGUtdXNlIHN1YnRhZ3MuICBUaGUgZmlyc3QNCiAgIGlzICdB WkUnIGFuZCB0aGUgc2Vjb25kIGlzICdkZXJiZW5kJy4NCg0KMi4yLjggIFByZS1FeGlzdGluZyBS RkMgMzA2NiBSZWdpc3RyYXRpb25zDQoNCiAgIEV4aXN0aW5nIElBTkEtcmVnaXN0ZXJlZCBsYW5n dWFnZSB0YWdzIGZyb20gUkZDIDE3NjYgYW5kL29yIFJGQyAzMDY2DQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBbUGFn ZSAxNF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIG1haW50YWluIHRoZWlyIHZhbGlkaXR5 LiAgSUFOQSB3aWxsIG1haW50YWluIHRoZXNlIHRhZ3MgaW4gdGhlDQogICByZWdpc3RyeSB1bmRl ciBlaXRoZXIgdGhlICJncmFuZGZhdGhlcmVkIiBvciAicmVkdW5kYW50IiB0eXBlLiAgRm9yDQog ICBtb3JlIGluZm9ybWF0aW9uIHNlZSBTZWN0aW9uIDMuNy4NCg0KICAgSXQgaXMgaW1wb3J0YW50 IHRvIG5vdGUgdGhhdCBhbGwgbGFuZ3VhZ2UgdGFncyBmb3JtZWQgdW5kZXIgdGhlDQogICBndWlk ZWxpbmVzIGluIHRoaXMgZG9jdW1lbnQgd2VyZSBlaXRoZXIgbGVnYWwsIHdlbGwtZm9ybWVkIHRh Z3Mgb3INCiAgIGNvdWxkIGhhdmUgYmVlbiByZWdpc3RlcmVkIHVuZGVyIFJGQyAzMDY2Lg0KDQoy LjIuOSAgQ2xhc3NlcyBvZiBDb25mb3JtYW5jZQ0KDQogICBJbXBsZW1lbnRhdGlvbnMgbWF5IHdp c2ggdG8gZXhwcmVzcyB0aGVpciBsZXZlbCBvZiBjb25mb3JtYW5jZSB3aXRoDQogICB0aGUgcnVs ZXMgYW5kIHByYWN0aWNlcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4gIFRoZXJlIGFyZQ0K ICAgZ2VuZXJhbGx5IHR3byBjbGFzc2VzIG9mIGNvbmZvcm1pbmcgaW1wbGVtZW50YXRpb25zOiAi d2VsbC1mb3JtZWQiDQogICBwcm9jZXNzb3JzIGFuZCAidmFsaWRhdGluZyIgcHJvY2Vzc29ycy4g IENsYWltcyBvZiBjb25mb3JtYW5jZSBTSE9VTEQNCiAgIGV4cGxpY2l0bHkgcmVmZXJlbmNlIG9u ZSBvZiB0aGVzZSBkZWZpbml0aW9ucy4NCg0KICAgQW4gaW1wbGVtZW50YXRpb24gdGhhdCBjbGFp bXMgdG8gY2hlY2sgZm9yIHdlbGwtZm9ybWVkIGxhbmd1YWdlIHRhZ3MNCiAgIE1VU1Q6DQoNCiAg IG8gIENoZWNrIHRoYXQgdGhlIHRhZyBhbmQgYWxsIG9mIGl0cyBzdWJ0YWdzLCBpbmNsdWRpbmcg ZXh0ZW5zaW9uIGFuZA0KICAgICAgcHJpdmF0ZS11c2Ugc3VidGFncywgY29uZm9ybSB0byB0aGUg QUJORiBvciB0aGF0IHRoZSB0YWcgaXMgb24gdGhlDQogICAgICBsaXN0IG9mIGdyYW5kZmF0aGVy ZWQgdGFncy4NCg0KICAgbyAgQ2hlY2sgdGhhdCBzaW5nbGV0b24gc3VidGFncyB0aGF0IGlkZW50 aWZ5IGV4dGVuc2lvbnMgZG8gbm90DQogICAgICByZXBlYXQuICBGb3IgZXhhbXBsZSwgdGhlIHRh ZyAiZW4tYS14eC1iLXl5LWEtenoiIGlzIG5vdCB3ZWxsLQ0KICAgICAgZm9ybWVkLg0KDQogICBX ZWxsLWZvcm1lZCBwcm9jZXNzb3JzIGFyZSBzdHJvbmdseSBlbmNvdXJhZ2VkIHRvIGltcGxlbWVu dCB0aGUNCiAgIGNhbm9uaWNhbGl6YXRpb24gcnVsZXMgY29udGFpbmVkIGluIFNlY3Rpb24gNC4z Lg0KDQogICBBbiBpbXBsZW1lbnRhdGlvbiB0aGF0IGNsYWltcyB0byBiZSB2YWxpZGF0aW5nIE1V U1Q6DQoNCiAgIG8gIENoZWNrIHRoYXQgdGhlIHRhZyBpcyB3ZWxsLWZvcm1lZC4NCg0KICAgbyAg U3BlY2lmeSB0aGUgcGFydGljdWxhciByZWdpc3RyeSBkYXRlIGZvciB3aGljaCB0aGUgaW1wbGVt ZW50YXRpb24NCiAgICAgIHBlcmZvcm1zIHZhbGlkYXRpb24gb2Ygc3VidGFncy4NCg0KICAgbyAg Q2hlY2sgdGhhdCBlaXRoZXIgdGhlIHRhZyBpcyBhIGdyYW5kZmF0aGVyZWQgdGFnLCBvciB0aGF0 IGFsbA0KICAgICAgbGFuZ3VhZ2UsIHNjcmlwdCwgcmVnaW9uLCBhbmQgdmFyaWFudCBzdWJ0YWdz IGNvbnNpc3Qgb2YgdmFsaWQNCiAgICAgIGNvZGVzIGZvciB1c2UgaW4gbGFuZ3VhZ2UgdGFncyBh Y2NvcmRpbmcgdG8gdGhlIElBTkEgcmVnaXN0cnkgYXMNCiAgICAgIG9mIHRoZSBwYXJ0aWN1bGFy IGRhdGUgc3BlY2lmaWVkIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbi4NCg0KICAgbyAgU3BlY2lmeSB3 aGljaCwgaWYgYW55LCBleHRlbnNpb24gUkZDcyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy42DQog ICAgICBhcmUgc3VwcG9ydGVkLCBpbmNsdWRpbmcgdmVyc2lvbiwgcmV2aXNpb24sIGFuZCBkYXRl Lg0KDQogICBvICBGb3IgYW55IHN1Y2ggZXh0ZW5zaW9ucyBzdXBwb3J0ZWQsIGNoZWNrIHRoYXQg YWxsIHN1YnRhZ3MgdXNlZCBpbg0KICAgICAgdGhhdCBleHRlbnNpb24gYXJlIHZhbGlkLg0KDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAg ICAgICAgICAgICBbUGFnZSAxNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIG8gIElmIHRo ZSBwcm9jZXNzb3IgZ2VuZXJhdGVzIHRhZ3MsIGl0IE1VU1QgZG8gc28gaW4gY2Fub25pY2FsIGZv cm0sDQogICAgICBpbmNsdWRpbmcgYW55IHN1cHBvcnRlZCBleHRlbnNpb25zLCBhcyBkZWZpbmVk IGluIFNlY3Rpb24gNC4zLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAg ICAgICAgICBbUGFnZSAxNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCjMuICBSZWdpc3RyeSBG b3JtYXQgYW5kIE1haW50ZW5hbmNlDQoNCiAgIFRoaXMgc2VjdGlvbiBkZWZpbmVzIHRoZSBMYW5n dWFnZSBTdWJ0YWcgUmVnaXN0cnkgYW5kIHRoZSBtYWludGVuYW5jZQ0KICAgYW5kIHVwZGF0ZSBw cm9jZWR1cmVzIGFzc29jaWF0ZWQgd2l0aCBpdC4NCg0KICAgVGhlIGxhbmd1YWdlIHN1YnRhZyBy ZWdpc3RyeSB3aWxsIGJlIG1haW50YWluZWQgc28gdGhhdCwgZXhjZXB0IGZvcg0KICAgZXh0ZW5z aW9uIHN1YnRhZ3MsIGl0IGlzIHBvc3NpYmxlIHRvIHZhbGlkYXRlIGFsbCBvZiB0aGUgc3VidGFn cyB0aGF0DQogICBhcHBlYXIgaW4gYSBsYW5ndWFnZSB0YWcgdW5kZXIgdGhlIHByb3Zpc2lvbnMg b2YgdGhpcyBkb2N1bWVudCBvciBpdHMNCiAgIHJldmlzaW9ucyBvciBzdWNjZXNzb3JzLiAgSW4g YWRkaXRpb24sIHRoZSBtZWFuaW5nIG9mIHRoZSB2YXJpb3VzDQogICBzdWJ0YWdzIHdpbGwgYmUg dW5hbWJpZ3VvdXMgYW5kIHN0YWJsZSBvdmVyIHRpbWUuICAoVGhlIG1lYW5pbmcgb2YNCiAgIHBy aXZhdGUtdXNlIHN1YnRhZ3MsIG9mIGNvdXJzZSwgaXMgbm90IGRlZmluZWQgYnkgdGhlIElBTkEg cmVnaXN0cnkuKQ0KDQogICBUaGUgcmVnaXN0cnkgZGVmaW5lZCB1bmRlciB0aGlzIGRvY3VtZW50 IGNvbnRhaW5zIGEgY29tcHJlaGVuc2l2ZQ0KICAgbGlzdCBvZiBhbGwgb2YgdGhlIHN1YnRhZ3Mg dmFsaWQgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoaXMgYWxsb3dzDQogICBpbXBsZW1lbnRlcnMgYSBz dHJhaWdodGZvcndhcmQgYW5kIHJlbGlhYmxlIHdheSB0byB2YWxpZGF0ZSBsYW5ndWFnZQ0KICAg dGFncy4NCg0KMy4xICBGb3JtYXQgb2YgdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5 DQoNCiAgIFRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAoInRoZSByZWdpc3RyeSIp IHdpbGwgY29uc2lzdCBvZiBhDQogICB0ZXh0IGZpbGUgdGhhdCBpcyBtYWNoaW5lIHJlYWRhYmxl IGluIHRoZSBmb3JtYXQgZGVzY3JpYmVkIGluIHRoaXMNCiAgIHNlY3Rpb24sIHBsdXMgY29waWVz IG9mIHRoZSByZWdpc3RyYXRpb24gZm9ybXMgYXBwcm92ZWQgYnkgdGhlDQogICBMYW5ndWFnZSBT dWJ0YWcgUmV2aWV3ZXIgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBwcm9jZXNzIGRlc2NyaWJlZCBp bg0KICAgU2VjdGlvbiAzLjQuICBXaXRoIHRoZSBleGNlcHRpb24gb2YgdGhlIHJlZ2lzdHJhdGlv biBmb3JtcyBmb3INCiAgIGdyYW5kZmF0aGVyZWQgYW5kIHJlZHVuZGFudCB0YWdzLCBubyByZWdp c3RyYXRpb24gcmVjb3JkcyB3aWxsIGJlDQogICBtYWludGFpbmVkIGZvciB0aGUgaW5pdGlhbCBz ZXQgb2Ygc3VidGFncy4NCg0KICAgVGhlIHJlZ2lzdHJ5IHdpbGwgYmUgaW4gYSBtb2RpZmllZCBy ZWNvcmQtamFyIGZvcm1hdCB0ZXh0IGZpbGUgWzE4XS4NCiAgIExpbmVzIGFyZSBsaW1pdGVkIHRv IDcyIGNoYXJhY3RlcnMsIGluY2x1ZGluZyBhbGwgd2hpdGVzcGFjZS4NCg0KICAgUmVjb3JkcyBh cmUgc2VwYXJhdGVkIGJ5IGxpbmVzIGNvbnRhaW5pbmcgb25seSB0aGUgc2VxdWVuY2UgIiUlIg0K ICAgKCV4MjUuMjUpLg0KDQogICBFYWNoIGZpZWxkIGNhbiBiZSB2aWV3ZWQgYXMgYSBzaW5nbGUs IGxvZ2ljYWwgIGxpbmUgIG9mIEFTQ0lJDQogICBjaGFyYWN0ZXJzLCAgY29tcHJpc2luZyAgYSBm aWVsZC1uYW1lIGFuZCBhIGZpZWxkLWJvZHkgc2VwYXJhdGVkIGJ5IGENCiAgIENPTE9OIGNoYXJh Y3RlciAoJXgzQSkuICBGb3IgY29udmVuaWVuY2UsIHRoZSBmaWVsZC1ib2R5ICBwb3J0aW9uICBv Zg0KICAgdGhpcyAgY29uY2VwdHVhbCBlbnRpdHkgIGNhbiBiZSBzcGxpdCBpbnRvIGEgbXVsdGlw bGUtbGluZQ0KICAgcmVwcmVzZW50YXRpb247IHRoaXMgaXMgY2FsbGVkICJmb2xkaW5nIi4gIFRo ZSBmb3JtYXQgb2YgdGhlIHJlZ2lzdHJ5DQogICBpcyBkZXNjcmliZWQgYnkgdGhlIGZvbGxvd2lu ZyBBQk5GIChwZXIgWzhdKToNCiAgIHJlY29yZCA9IDEqZmllbGQgIiUlIiBDUkxGDQogICBmaWVs ZCA9IGZpZWxkLW5hbWUgKlNQICI6IiAqU1AgZmllbGQtYm9keSBDUkxGDQogICBmaWVsZC1uYW1l ID0gKihBTFBIQS9OVU0vJXgyRCkNCiAgIGZpZWxkLWJvZHkgPSAqKEFTQ0NIQVIvTFdTUCkNCiAg IEFTQ0NIQVIgPSAleDIxLTI1IC8gJXgyNy03RSAvIFVOSUNIQVINCiAgIDsgTm90ZTogQU1QRVJT QU5EIGlzICV4MjYNCiAgIFVOSUNIQVIgPSAiJiN4IiAyKjZIRVhESUcgIjsiDQoNCiAgIFRoZSBz ZXF1ZW5jZSAnLi4nICgleDJFLjJFKSBpbiBhIGZpZWxkLWJvZHkgZGVub3RlcyBhIHJhbmdlIG9m DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUg ICAgICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIHZhbHVl cy4gIFN1Y2ggYSByYW5nZSByZXByZXNlbnRzIGFsbCBzdWJ0YWdzIG9mIHRoZSBzYW1lIGxlbmd0 aCB0aGF0DQogICBhcmUgYWxwaGFiZXRpY2FsbHkgd2l0aGluIHRoYXQgcmFuZ2UsIGluY2x1ZGlu ZyB0aGUgdmFsdWVzIGV4cGxpY2l0bHkNCiAgIG1lbnRpb25lZC4gIEZvciBleGFtcGxlICdhLi5j JyBkZW5vdGVzIHRoZSB2YWx1ZXMgJ2EnLCAnYicsIGFuZCAnYycuDQoNCiAgIENoYXJhY3RlcnMg ZnJvbSBvdXRzaWRlIHRoZSBVUy1BU0NJSSByZXBlcnRvaXJlLCBhcyB3ZWxsIGFzIHRoZQ0KICAg QU1QRVJTQU5EIGNoYXJhY3RlciAoIiYiLCAleDI2KSB3aGVuIGl0IG9jY3VycyBpbiBhIGZpZWxk LWJvZHkgYXJlDQogICByZXByZXNlbnRlZCBieSBhICJOdW1lcmljIENoYXJhY3RlciBSZWZlcmVu Y2UiIHVzaW5nIGhleGFkZWNpbWFsDQogICBub3RhdGlvbiBpbiB0aGUgc3R5bGUgdXNlZCBieSBY TUwgMS4wIFsxOV0gKHNlZQ0KICAgPGh0dHA6Ly93d3cudzMub3JnL1RSLzIwMDQvUkVDLXhtbC0y MDA0MDIwNC8jZHQtY2hhcnJlZj4pLiAgVGhpcw0KICAgY29uc2lzdHMgb2YgdGhlIHNlcXVlbmNl ICImI3giICgleDI2LjIzLjc4KSBmb2xsb3dlZCBieSBhIGhleGFkZWNpbWFsDQogICByZXByZXNl bnRhdGlvbiBvZiB0aGUgY2hhcmFjdGVyJ3MgY29kZSBwb2ludCBpbiBJU08vSUVDIDEwNjQ2IFs2 XQ0KICAgZm9sbG93ZWQgYnkgYSBjbG9zaW5nIHNlbWljb2xvbiAoJXgzQikuICBGb3IgZXhhbXBs ZSwgdGhlIEVVUk8gU0lHTiwNCiAgIFUrMjBBQywgd291bGQgYmUgcmVwcmVzZW50ZWQgYnkgdGhl IHNlcXVlbmNlICImI3gyMEFDOyIuICBOb3RlIHRoYXQNCiAgIHRoZSBoZXhhZGVjaW1hbCBub3Rh dGlvbiBtYXkgaGF2ZSBiZXR3ZWVuIHR3byBhbmQgc2l4IGRpZ2l0cy4NCg0KICAgQWxsIGZpZWxk cyB3aG9zZSBmaWVsZC1ib2R5IGNvbnRhaW5zIGEgZGF0ZSB2YWx1ZSB1c2UgdGhlICJmdWxsLWRh dGUiDQogICBmb3JtYXQgc3BlY2lmaWVkIGluIFJGQyAzMzM5IFsxNF0uICBGb3IgZXhhbXBsZTog IjIwMDQtMDYtMjgiDQogICByZXByZXNlbnRzIEp1bmUgMjgsIDIwMDQgaW4gdGhlIEdyZWdvcmlh biBjYWxlbmRhci4NCg0KICAgVGhlIGZpcnN0IHJlY29yZCBpbiB0aGUgZmlsZSBjb250YWlucyB0 aGUgc2luZ2xlIGZpZWxkIHdob3NlIGZpZWxkLQ0KICAgbmFtZSBpcyAiRmlsZS1EYXRlIiBhbmQg d2hvc2UgZmllbGQtYm9keSBjb250YWlucyB0aGUgbGFzdA0KICAgbW9kaWZpY2F0aW9uIGRhdGUg b2YgdGhlIHJlZ2lzdHJ5Og0KICAgJSUNCiAgIEZpbGUtRGF0ZTogMjAwNC0wNi0yOA0KICAgJSUN Cg0KICAgU3Vic2VxdWVudCByZWNvcmRzIHJlcHJlc2VudCBzdWJ0YWdzIGluIHRoZSByZWdpc3Ry eS4gIEVhY2ggb2YgdGhlDQogICBmaWVsZHMgaW4gZWFjaCByZWNvcmQgTVVTVCBvY2N1ciBubyBt b3JlIHRoYW4gb25jZSwgdW5sZXNzIG90aGVyd2lzZQ0KICAgbm90ZWQgYmVsb3cuICBFYWNoIHJl Y29yZCBNVVNUIGNvbnRhaW4gdGhlIGZvbGxvd2luZyBmaWVsZHM6DQoNCiAgIG8gICdUeXBlJw0K DQogICAgICAqICBUeXBlJ3MgZmllbGQtdmFsdWUgTVVTVCBjb25zaXN0IG9mIG9uZSBvZiB0aGUg Zm9sbG93aW5nDQogICAgICAgICBzdHJpbmdzOiAibGFuZ3VhZ2UiLCAiZXh0bGFuZyIsICJzY3Jp cHQiLCAicmVnaW9uIiwgInZhcmlhbnQiLA0KICAgICAgICAgImdyYW5kZmF0aGVyZWQiLCBhbmQg InJlZHVuZGFudCIgYW5kIGRlbm90ZXMgdGhlIHR5cGUgb2YgdGFnIG9yDQogICAgICAgICBzdWJ0 YWcuDQoNCiAgIG8gIEVpdGhlciAnU3VidGFnJyBvciAnVGFnJw0KDQogICAgICAqICBTdWJ0YWcn cyBmaWVsZC12YWx1ZSBjb250YWlucyB0aGUgc3VidGFnIGJlaW5nIGRlZmluZWQuICBUaGlzDQog ICAgICAgICBmaWVsZCBNVVNUIG9ubHkgYXBwZWFyIGluIHJlY29yZHMgb2Ygd2hvc2UgVHlwZSBo YXMgb25lIG9mDQogICAgICAgICB0aGVzZSB2YWx1ZXM6ICJsYW5ndWFnZSIsICJleHRsYW5nIiwg InNjcmlwdCIsICJyZWdpb24iLCBvcg0KICAgICAgICAgInZhcmlhbnQiLg0KDQogICAgICAqICBU YWcncyBmaWVsZC12YWx1ZSBjb250YWlucyBhIGNvbXBsZXRlIGxhbmd1YWdlIHRhZy4gIFRoaXMg ZmllbGQNCiAgICAgICAgIE1VU1Qgb25seSBhcHBlYXIgaW4gcmVjb3JkcyB3aG9zZSBUeXBlIGhh cyBvbmUgb2YgdGhlc2UgdmFsdWVzOg0KICAgICAgICAgImdyYW5kZmF0aGVyZWQiIG9yICJyZWR1 bmRhbnQiLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIg MjIsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAxOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoN CiAgIG8gIERlc2NyaXB0aW9uDQoNCiAgICAgICogIERlc2NyaXB0aW9uJ3MgZmllbGQtdmFsdWUg Y29udGFpbnMgYSBub24tbm9ybWF0aXZlIGRlc2NyaXB0aW9uDQogICAgICAgICBvZiB0aGUgc3Vi dGFnIG9yIHRhZy4NCg0KICAgbyAgQWRkZWQNCg0KICAgICAgKiAgQWRkZWQncyBmaWVsZC12YWx1 ZSBjb250YWlucyB0aGUgZGF0ZSB0aGUgcmVjb3JkIHdhcyBhZGRlZCB0bw0KICAgICAgICAgdGhl IHJlZ2lzdHJ5Lg0KDQogICBUaGUgZmllbGQgJ0Rlc2NyaXB0aW9uJyBNQVkgYXBwZWFyIG1vcmUg dGhhbiBvbmUgdGltZS4gIFRoZQ0KICAgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBtdXN0IGNvbnRhaW4g YSBkZXNjcmlwdGlvbiBvZiB0aGUgdGFnIGJlaW5nDQogICByZWdpc3RlcmVkIHdyaXR0ZW4gb3Ig dHJhbnNjcmliZWQgaW50byB0aGUgTGF0aW4gc2NyaXB0OyBpdCBtYXkgYWxzbw0KICAgaW5jbHVk ZSBhIGRlc2NyaXB0aW9uIGluIGEgbm9uLUxhdGluIHNjcmlwdC4gIFRoZSAnRGVzY3JpcHRpb24n IGZpZWxkDQogICBpcyB1c2VkIGZvciBpZGVudGlmaWNhdGlvbiBwdXJwb3NlcyBhbmQgc2hvdWxk IG5vdCBiZSB0YWtlbiB0bw0KICAgcmVwcmVzZW50IHRoZSBhY3R1YWwgbmF0aXZlIG5hbWUgb2Yg dGhlIGxhbmd1YWdlIG9yIHZhcmlhdGlvbiBvciB0bw0KICAgYmUgaW4gYW55IHBhcnRpY3VsYXIg bGFuZ3VhZ2UuICBNb3N0IGRlc2NyaXB0aW9ucyBhcmUgdGFrZW4gZGlyZWN0bHkNCiAgIGZyb20g c291cmNlIHN0YW5kYXJkcyBzdWNoIGFzIElTTyA2Mzkgb3IgSVNPIDMxNjYuDQoNCiAgIE5vdGU6 IERlc2NyaXB0aW9ucyBpbiByZWdpc3RyeSBlbnRyaWVzIHRoYXQgY29ycmVzcG9uZCB0byBJU08g NjM5LA0KICAgSVNPIDE1OTI0LCAgSVNPIDMxNjYgb3IgVU4gTS40OSBjb2RlcyBhcmUgaW50ZW5k ZWQgb25seSB0byBpbmRpY2F0ZQ0KICAgdGhlIG1lYW5pbmcgb2YgdGhhdCBpZGVudGlmaWVyIGFz IGRlZmluZWQgaW4gdGhlIHNvdXJjZSBzdGFuZGFyZCBhdA0KICAgdGhlIHRpbWUgaXQgd2FzIGFk ZGVkIHRvIHRoZSByZWdpc3RyeS4gIFRoZSBkZXNjcmlwdGlvbiBkb2VzIG5vdA0KICAgcmVwbGFj ZSB0aGUgY29udGVudCBvZiB0aGUgc291cmNlIHN0YW5kYXJkIGl0c2VsZi4gIFRoZSBkZXNjcmlw dGlvbnMNCiAgIGFyZSBub3QgaW50ZW5kZWQgdG8gYmUgdGhlIEVuZ2xpc2ggbG9jYWxpemVkIG5h bWVzIGZvciB0aGUgc3VidGFncy4NCiAgIExvY2FsaXphdGlvbiBvciB0cmFuc2xhdGlvbiBvZiBs YW5ndWFnZSB0YWcgYW5kIHN1YnRhZyBkZXNjcmlwdGlvbnMNCiAgIGlzIG91dCBvZiBzY29wZSBv ZiB0aGlzIGRvY3VtZW50Lg0KDQogICBFYWNoIHJlY29yZCBNQVkgYWxzbyBjb250YWluIHRoZSBm b2xsb3dpbmcgZmllbGRzOg0KDQogICBvICBDYW5vbmljYWwNCg0KICAgICAgKiAgRm9yIGZpZWxk cyBvZiB0eXBlICdsYW5ndWFnZScsICdleHRsYW5nJywgJ3NjcmlwdCcsICdyZWdpb24nLA0KICAg ICAgICAgYW5kICd2YXJpYW50JywgYSBjYW5vbmljYWwgbWFwcGluZyBvZiB0aGlzIHJlY29yZCB0 byBhIHN1YnRhZw0KICAgICAgICAgcmVjb3JkIG9mIHRoZSBzYW1lICdUeXBlJy4NCg0KICAgICAg KiAgRm9yIGZpZWxkcyBvZiB0eXBlICdncmFuZGZhdGhlcmVkJyBhbmQgJ3JlZHVuZGFudCcsIGEg Y2Fub25pY2FsDQogICAgICAgICBtYXBwaW5nIHRvIGEgY29tcGxldGUgbGFuZ3VhZ2UgdGFnLg0K DQogICBvICBEZXByZWNhdGVkDQoNCiAgICAgICogIERlcHJlY2F0ZWQncyBmaWVsZC12YWx1ZSBj b250YWlucyB0aGUgZGF0ZSB0aGUgcmVjb3JkIHdhcw0KICAgICAgICAgZGVwcmVjYXRlZC4NCg0K ICAgbyAgUmVjb21tZW5kZWQtUHJlZml4DQoNCiAgICAgICogIFJlY29tbWVuZGVkLVByZWZpeCdz IGZpZWxkLXZhbHVlIGNvbnRhaW5zIGEgbGFuZ3VhZ2UgdGFnIHdpdGgNCiAgICAgICAgIHdoaWNo IHRoaXMgc3VidGFnIG1heSBiZSB1c2VkIHRvIGZvcm0gYSBuZXcgbGFuZ3VhZ2UgdGFnLA0KDQoN Cg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1ICAgICAg ICAgICAgICAgW1BhZ2UgMTldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICAgICAgICBwZXJo YXBzIHdpdGggb3RoZXIgc3VidGFncyBhcyB3ZWxsLiAgVGhpcyBmaWVsZCBNVVNUIG9ubHkNCiAg ICAgICAgIGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBlJyBmaWVsZC12YWx1ZSBpcyAndmFy aWFudCcgb3INCiAgICAgICAgICdleHRsYW5nJy4gIEZvciBleGFtcGxlLCB0aGUgJ1JlY29tbWVu ZGVkLVByZWZpeCcgZm9yIHRoZQ0KICAgICAgICAgdmFyaWFudCAnc2NvdXNlJyBpcyAnZW4nLCBt ZWFuaW5nIHRoYXQgdGhlIHRhZ3MgImVuLXNjb3VzZSIgYW5kDQogICAgICAgICAiZW4tR0Itc2Nv dXNlIiBtaWdodCBiZSBhcHByb3ByaWF0ZSB3aGlsZSB0aGUgdGFnICJpcy1zY291c2UiDQogICAg ICAgICBpcyBub3QuDQoNCiAgIG8gIENvbW1lbnRzDQoNCiAgICAgICogIENvbW1lbnRzIGNvbnRh aW5zIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHN1YnRhZywgYXMNCiAgICAgICAg IGRlZW1lZCBhcHByb3ByaWF0ZSBmb3IgdW5kZXJzdGFuZGluZyB0aGUgcmVnaXN0cnkgYW5kDQog ICAgICAgICBpbXBsZW1lbnRpbmcgbGFuZ3VhZ2UgdGFncyB1c2luZyB0aGUgc3VidGFnIG9yIHRh Zy4NCg0KICAgbyAgU3VwcHJlc3MtU2NyaXB0DQoNCiAgICAgICogIFN1cHByZXNzLVNjcmlwdCBj b250YWlucyBhIHNjcmlwdCBzdWJ0YWcgdGhhdCBTSE9VTEQgTk9UIGJlDQogICAgICAgICB1c2Vk IHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyB3aXRoIHRoZSBhc3NvY2lhdGVkIHByaW1hcnkgbGFuZ3Vh Z2UNCiAgICAgICAgIHN1YnRhZy4gIFRoaXMgZmllbGQgTVVTVCBvbmx5IGFwcGVhciBpbiByZWNv cmRzIHdob3NlICdUeXBlJw0KICAgICAgICAgZmllbGQtdmFsdWUgaXMgJ2xhbmd1YWdlJy4gIFNl ZSBTZWN0aW9uIDQuMS4NCg0KICAgVGhlIGZpZWxkICdDYW5vbmljYWwnIFNIQUxMIE5PVCBiZSBh ZGRlZCB0byBhbnkgcmVjb3JkIGFscmVhZHkgaW4gdGhlDQogICByZWdpc3RyeS4gIFRoZSBmaWVs ZCAnQ2Fub25pY2FsJyBTSEFMTCBOT1QgYmUgbW9kaWZpZWQgZXhjZXB0IGZvcg0KICAgcmVjb3Jk cyBvZiB0eXBlICJncmFuZGZhdGhlcmVkIjogdGhlcmVmb3JlIGEgc3VidGFnIHdob3NlIHJlY29y ZA0KICAgY29udGFpbnMgbm8gY2Fub25pY2FsIG1hcHBpbmcgd2hlbiB0aGUgcmVjb3JkIGlzIGNy ZWF0ZWQgaXMgYQ0KICAgY2Fub25pY2FsIGZvcm0gYW5kIHdpbGwgcmVtYWluIHNvLg0KDQogICBU aGUgJ0Nhbm9uaWNhbCcgZmllbGQgaW4gcmVjb3JkcyBvZiB0eXBlICJncmFuZGZhdGhlcmVkIiBh bmQNCiAgICJyZWR1bmRhbnQiIGNvbnRhaW5zIHdob2xlIGxhbmd1YWdlIHRhZ3MgdGhhdCBhcmUg U1RST05HTFkNCiAgIFJFQ09NTUVOREVEIGZvciB1c2UgaW4gcGxhY2Ugb2YgdGhlIHJlY29yZCdz IHZhbHVlLiAgSW4gbWFueSBjYXNlcw0KICAgdGhlIG1hcHBpbmdzIHdlcmUgY3JlYXRlZCBieSBk ZXByZWNhdGlvbiBvZiB0aGUgdGFncyBkdXJpbmcgdGhlDQogICBwZXJpb2QgYmVmb3JlIHRoaXMg ZG9jdW1lbnQgd2FzIGFkb3B0ZWQuICBGb3IgZXhhbXBsZSwgdGhlIHRhZyAibm8tDQogICBueW4i IHdhcyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBJU08gNjM5LTEgZGVmaW5lZCBsYW5ndWFn ZSBjb2RlDQogICAnbm4nLg0KDQogICBOb3RlIHRoYXQgYSByZWNvcmQgdGhhdCBoYXMgYSAnQ2Fu b25pY2FsJyBmaWVsZCBNVVNUIGhhdmUgYQ0KICAgJ0RlcHJlY2F0ZWQnIGZpZWxkIGFsc28gKGFs dGhvdWdoIHRoZSBjb252ZXJzZSBpcyBub3QgdHJ1ZSkuDQoNCiAgIFRoZSBmaWVsZCAnRGVwcmVj YXRlZCcgTUFZIGJlIGFkZGVkIHRvIGFueSByZWNvcmQgdmlhIHRoZSBtYWludGVuYW5jZQ0KICAg cHJvY2VzcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIgb3IgdmlhIHRoZSByZWdpc3RyYXRpb24g cHJvY2Vzcw0KICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40LiAgVXN1YWxseSB0aGUgYWRkaXRp b24gb2YgYSAnRGVwcmVjYXRlZCcNCiAgIGZpZWxkIGlzIGR1ZSB0byB0aGUgYWN0aW9uIG9mIG9u ZSBvZiB0aGUgc3RhbmRhcmRzIGJvZGllcywgc3VjaCBhcw0KICAgSVNPIDMxNjYsIHdpdGhkcmF3 aW5nIGEgY29kZS4gIEluIHNvbWUgaGlzdG9yaWNhbCBjYXNlcyBpdCBtYXkgbm90DQogICBoYXZl IGJlZW4gIHBvc3NpYmxlIHRvIHJlY29uc3RydWN0IHRoZSBvcmlnaW5hbCBkZXByZWNhdGlvbiBk YXRlLg0KICAgRm9yIHRoZXNlIGNhc2VzLCBhbiBhcHByb3hpbWF0ZSBkYXRlIGFwcGVhcnMgaW4g dGhlIHJlZ2lzdHJ5Lg0KICAgQWx0aG91Z2ggdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncywgc3VidGFn cyBhbmQgdGFncyB3aXRoIGEgJ0RlcHJlY2F0ZWQnDQogICBmaWVsZCBhcmUgZGVwcmVjYXRlZCBh bmQgdmFsaWRhdGluZyBwcm9jZXNzb3JzIFNIT1VMRCBOT1QgZ2VuZXJhdGUNCiAgIHRoZXNlIHN1 YnRhZ3MuICBOb3RlIHRoYXQgYSByZWNvcmQgdGhhdCBjb250YWlucyBhICdEZXByZWNhdGVkJyBm aWVsZA0KICAgYW5kIG5vIGNvcnJlc3BvbmRpbmcgJ0Nhbm9uaWNhbCcgZmllbGQgaGFzIG5vIHJl cGxhY2VtZW50IG1hcHBpbmcuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVz IE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAyMF0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwg MjAwNQ0KDQoNCiAgIFRoZSBmaWVsZCAnUmVjb21tZW5kZWQtUHJlZml4JyBNQVkgYXBwZWFyIG1v cmUgdGhhbiBvbmNlIHBlciByZWNvcmQuDQogICBBZGRpdGlvbmFsIGZpZWxkcyBvZiB0aGlzIHR5 cGUgTUFZIGJlIGFkZGVkIHRvIGEgcmVjb3JkIHZpYSB0aGUNCiAgIHJlZ2lzdHJhdGlvbiBwcm9j ZXNzLiAgVGhlIGZpZWxkLXZhbHVlIG9mIG9mIHRoaXMgZmllbGQgY29uc2lzdHMgb2YgYQ0KICAg bGFuZ3VhZ2UgdGFnIHRoYXQgaXMgUkVDT01NRU5ERUQgZm9yIHVzZSBhcyBhIHByZWZpeCBmb3Ig dGhpcyBzdWJ0YWcuDQogICBGb3IgZXhhbXBsZSwgdGhlIHZhcmlhbnQgc3VidGFnICdzY291c2Un IGhhcyBhIHJlY29tbWVuZGVkIHByZWZpeCBvZg0KICAgImVuIi4gIFRoaXMgbWVhbnMgdGhhdCB0 YWdzIHN0YXJ0aW5nIHdpdGggdGhlIHByZWZpeCAiZW4tIiBhcmUgbW9zdA0KICAgYXBwcm9wcmlh dGUgd2l0aCB0aGlzIHN1YnRhZywgc28gImVuLUxhdG4tc2NvdXNlIiBhbmQgImVuLUdCLXNjb3Vz ZSINCiAgIGFyZSBib3RoIGFjY2VwdGFibGUsIHdoaWxlIHRoZSB0YWcgImZyLXNjb3VzZSIgaXMg cHJvYmFibHkgYW4NCiAgIGluYXBwcm9wcmlhdGUgY2hvaWNlLg0KDQogICBUaGUgZmllbGQgb2Yg dHlwZSBSZWNvbW1lbmRlZC1QcmVmaXggTVVTVCBOT1QgYmUgcmVtb3ZlZCBmcm9tIGFueQ0KICAg cmVjb3JkLiAgVGhlIGZpZWxkLXZhbHVlIGZvciB0aGlzIHR5cGUgb2YgZmllbGQgTVVTVCBOT1Qg YmUgbW9kaWZpZWQuDQoNCiAgIFRoZSBmaWVsZCAnQ29tbWVudHMnIE1BWSBhcHBlYXIgbW9yZSB0 aGFuIG9uY2UgcGVyIHJlY29yZC4gIFRoaXMNCiAgIGZpZWxkIE1BWSBiZSBpbnNlcnRlZCBvciBj aGFuZ2VkIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgYW5kIG5vDQogICBndWFyYW50ZWUg b2Ygc3RhYmlsaXR5IGlzIHByb3ZpZGVkLiAgVGhlIGNvbnRlbnQgb2YgdGhpcyBmaWVsZCBpcyBu b3QNCiAgIHJlc3RyaWN0ZWQsIGV4Y2VwdCBieSB0aGUgbmVlZCB0byByZWdpc3RlciB0aGUgaW5m b3JtYXRpb24sIHRoZQ0KICAgc3VpdGFiaWxpdHkgb2YgdGhlIHJlcXVlc3QsIGFuZCBieSByZWFz b25hYmxlIHByYWN0aWNhbCBzaXplDQogICBsaW1pdGF0aW9ucy4gIExvbmcgc2NyZWVkcyBhYm91 dCBhIHBhcnRpY3VsYXIgc3VidGFnIGFyZSBmcm93bmVkDQogICB1cG9uLg0KDQogICBUaGUgZmll bGQgJ1N1cHByZXNzLVNjcmlwdCcgTVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdU eXBlJw0KICAgZmllbGQtdmFsdWUgaXMgJ2xhbmd1YWdlJy4gIFRoaXMgZmllbGQgbWF5IGFwcGVh ciBhdCBtb3N0IG9uZSB0aW1lIGluDQogICBhIHJlY29yZC4gIFRoaXMgZmllbGQgaW5kaWNhdGVz IGEgc2NyaXB0IHVzZWQgdG8gd3JpdGUgdGhlDQogICBvdmVyd2hlbG1pbmcgbWFqb3JpdHkgb2Yg ZG9jdW1lbnRzIGZvciB0aGUgZ2l2ZW4gbGFuZ3VhZ2UgYW5kIHdoaWNoDQogICB0aGVyZWZvcmUg YWRkcyBubyBkaXN0aW5ndWlzaGluZyBpbmZvcm1hdGlvbiB0byBhIGxhbmd1YWdlIHRhZy4gIEZv cg0KICAgZXhhbXBsZSwgdmlydHVhbGx5IGFsbCBJY2VsYW5kaWMgZG9jdW1lbnRzIGFyZSB3cml0 dGVuIGluIHRoZSBMYXRpbg0KICAgc2NyaXB0LCBtYWtpbmcgdGhlIHN1YnRhZyAnTGF0bicgcmVk dW5kYW50IGluIHRoZSB0YWcgImlzLUxhdG4iLg0KDQogICBGb3IgZXhhbXBsZXMgb2YgcmVnaXN0 cnkgZW50cmllcyBhbmQgdGhlaXIgZm9ybWF0LCBzZWUgQXBwZW5kaXggQy4NCg0KMy4yICBNYWlu dGVuYW5jZSBvZiB0aGUgUmVnaXN0cnkNCg0KICAgTWFpbnRlbmFuY2Ugb2YgdGhlIHJlZ2lzdHJ5 IHJlcXVpcmVzIHRoYXQgYXMgbmV3IGNvZGVzIGFyZSBhc3NpZ25lZA0KICAgYnkgSVNPIDYzOSwg SVNPIDE1OTI0LCBhbmQgSVNPIDMxNjYsIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXINCiAg IHdpbGwgZXZhbHVhdGUgZWFjaCBhc3NpZ25tZW50LCBkZXRlcm1pbmUgd2hldGhlciBpdCBjb25m bGljdHMgd2l0aA0KICAgZXhpc3RpbmcgcmVnaXN0cnkgZW50cmllcywgYW5kIHN1Ym1pdCB0aGUg aW5mb3JtYXRpb24gdG8gSUFOQSBmb3INCiAgIGluY2x1c2lvbiBpbiB0aGUgcmVnaXN0cnkuICBJ ZiBhbiBhc3NpZ25tZW50IHRha2VzIHBsYWNlIGFuZCB0aGUNCiAgIExhbmd1YWdlIFN1YnRhZyBS ZXZpZXdlciBkb2VzIG5vdCBkbyB0aGlzIGluIGEgdGltZWx5IG1hbm5lciwgdGhlbg0KICAgYW55 IGludGVyZXN0ZWQgcGFydHkgbWF5IHVzZSB0aGUgcHJvY2VkdXJlIGluIFNlY3Rpb24gMy40IHRv IHJlZ2lzdGVyDQogICB0aGUgYXBwcm9wcmlhdGUgdXBkYXRlLg0KDQogICBOb3RlOiBUaGUgcmVk dW5kYW50IGFuZCBncmFuZGZhdGhlcmVkIGVudHJpZXMgdG9nZXRoZXIgYXJlIHRoZQ0KICAgY29t cGxldGUgbGlzdCBvZiB0YWdzIHJlZ2lzdGVyZWQgdW5kZXIgUkZDIDMwNjYgWzIzXS4gIFRoZSBy ZWR1bmRhbnQNCiAgIHRhZ3MgYXJlIHRob3NlIHRoYXQgY2FuIG5vdyBiZSBmb3JtZWQgdXNpbmcg dGhlIHN1YnRhZ3MgZGVmaW5lZCBpbg0KICAgdGhlIHJlZ2lzdHJ5IHRvZ2V0aGVyIHdpdGggdGhl IHJ1bGVzIG9mICBTZWN0aW9uIDIuMi4gIFRoZQ0KICAgZ3JhbmRmYXRoZXJlZCBlbnRyaWVzIGFy ZSB0aG9zZSB0aGF0IGNhbiBuZXZlciBiZSBsZWdhbCB1bmRlciB0aG9zZQ0KICAgc2FtZSBwcm92 aXNpb25zLiAgVGhlIGl0ZW1zIGluIGJvdGggbGlzdHMgYXJlIHBlcm1hbmVudCBhbmQgc3RhYmxl LA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1 ICAgICAgICAgICAgICAgW1BhZ2UgMjFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg bGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICBhbHRo b3VnaCBncmFuZGZhdGhlcmVkIGl0ZW1zIG1heSBiZSBkZXByZWNhdGVkIG92ZXIgdGltZS4gIFJl ZmVyIHRvDQogICBTZWN0aW9uIDMuNyBmb3IgbW9yZSBpbmZvcm1hdGlvbi4NCg0KICAgUkZDIDMw NjYgdGFncyB0aGF0IHdlcmUgZGVwcmVjYXRlZCBwcmlvciB0byB0aGUgYWRvcHRpb24gb2YgdGhp cw0KICAgZG9jdW1lbnQgYXJlIHBhcnQgb2YgdGhlIGxpc3Qgb2YgZ3JhbmRmYXRoZXJlZCB0YWdz IGFuZCB0aGVpcg0KICAgY29tcG9uZW50IHN1YnRhZ3Mgd2VyZSBub3QgaW5jbHVkZWQgYXMgcmVn aXN0ZXJlZCB2YXJpYW50cyAoYWx0aG91Z2gNCiAgIHRoZXkgcmVtYWluIGVsaWdpYmxlIGZvciBy ZWdpc3RyYXRpb24pLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgImFydC0NCiAgIGxvamJhbiIgd2Fz IGRlcHJlY2F0ZWQgaW4gZmF2b3Igb2YgdGhlIGxhbmd1YWdlIHN1YnRhZyAnamJvJy4NCg0KICAg VGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBNVVNUIGVuc3VyZSB0aGF0IG5ldyBzdWJ0YWdz IG1lZXQgdGhlDQogICByZXF1aXJlbWVudHMgaW4gU2VjdGlvbiA0LjEgb3Igc3VibWl0IGFuIGFw cHJvcHJpYXRlIGFsdGVybmF0ZSBzdWJ0YWcNCiAgIGFzIGRlc2NyaWJlZCBpbiB0aGF0IHNlY3Rp b24uICBJZiBhIGNoYW5nZSBvciBhZGRpdGlvbiB0byB0aGUNCiAgIHJlZ2lzdHJ5IGlzIHJlcXVp cmVkLCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIHdpbGwgcHJlcGFyZSB0aGUNCiAgIGNv bXBsZXRlIHJlY29yZCwgaW5jbHVkaW5nIGFsbCBmaWVsZHMsIGFuZCBmb3J3YXJkIGl0IHRvIElB TkEgZm9yDQogICBpbnNlcnRpb24gaW50byB0aGUgcmVnaXN0cnkuICBJZiB0aGlzIHJlcHJlc2Vu dHMgYSBuZXcgc3VidGFnLCB0aGVuDQogICB0aGUgbWVzc2FnZSB3aWxsIGluZGljYXRlIHRoYXQg dGhpcyByZXByZXNlbnRzIGFuIElOU0VSVElPTiBvZiBhDQogICByZWNvcmQuICBJZiB0aGlzIHJl cHJlc2VudHMgYSBjaGFuZ2UgdG8gYW4gZXhpc3Rpbmcgc3VidGFnLCB0aGVuIHRoZQ0KICAgbWVz c2FnZSBtdXN0IGluZGljYXRlIHRoYXQgdGhpcyByZXByZXNlbnRzIGEgTU9ESUZJQ0FUSU9OLCBh cyBzaG93bg0KICAgaW4gdGhlIGZvbGxvd2luZyBleGFtcGxlOg0KDQogICBMQU5HVUFHRSBTVUJU QUcgTU9ESUZJQ0FUSU9ODQogICBGaWxlLURhdGU6IDIwMDUtMDEtMDINCiAgICUlDQogICBUeXBl OiB2YXJpYW50DQogICBTdWJ0YWc6IG5lZGlzDQogICBEZXNjcmlwdGlvbjogTmF0aXNvbmUgZGlh bGVjdA0KICAgRGVzY3JpcHRpb246IE5hZGl6YSBkaWFsZWN0DQogICBBZGRlZDogMjAwMy0xMC0w OQ0KICAgUmVjb21tZW5kZWQtUHJlZml4OiBzbA0KICAgQ29tbWVudHM6IFRoaXMgaXMgYSBjb21t ZW50IHNob3duDQogICAgIGFzIGFuIGV4YW1wbGUuDQogICAlJQ0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBGaWd1cmUgNA0KDQogICBXaGVuZXZlciBhbiBlbnRyeSBpcyBjcmVh dGVkIG9yIG1vZGlmaWVkIGluIHRoZSByZWdpc3RyeSwgdGhlICdGaWxlLQ0KICAgRGF0ZScgcmVj b3JkIGF0IHRoZSBzdGFydCBvZiB0aGUgcmVnaXN0cnkgaXMgdXBkYXRlZCB0byByZWZsZWN0IHRo ZQ0KICAgbW9zdCByZWNlbnQgbW9kaWZpY2F0aW9uIGRhdGUgaW4gdGhlIFJGQyAzMzM5IFsxNF0g ImZ1bGwtZGF0ZSINCiAgIGZvcm1hdC4NCg0KMy4zICBTdGFiaWxpdHkgb2YgSUFOQSBSZWdpc3Ry eSBFbnRyaWVzDQoNCiAgIFRoZSBzdGFiaWxpdHkgb2YgZW50cmllcyBhbmQgdGhlaXIgbWVhbmlu ZyBpbiB0aGUgcmVnaXN0cnkgaXMNCiAgIGNyaXRpY2FsIHRvIHRoZSBsb25nIHRlcm0gc3RhYmls aXR5IG9mIGxhbmd1YWdlIHRhZ3MuICBUaGUgcnVsZXMgaW4NCiAgIHRoaXMgc2VjdGlvbiBndWFy YW50ZWUgdGhhdCBhIHNwZWNpZmljIGxhbmd1YWdlIHRhZydzIG1lYW5pbmcgaXMNCiAgIHN0YWJs ZSBvdmVyIHRpbWUgYW5kIHdpbGwgbm90IGNoYW5nZSBhbmQgdGhhdCB0aGUgY2hvaWNlIG9mIGxh bmd1YWdlDQogICB0YWcgZm9yIHNwZWNpZmljIGNvbnRlbnQgaXMgYWxzbyBzdGFibGUgb3ZlciB0 aW1lLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIs IDIwMDUgICAgICAgICAgICAgICBbUGFnZSAyMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAg IFRoZXNlIHJ1bGVzIHNwZWNpZmljYWxseSBkZWFsIHdpdGggaG93IGNoYW5nZXMgdG8gY29kZXMg KGluY2x1ZGluZw0KICAgd2l0aGRyYXdhbCBhbmQgZGVwcmVjYXRpb24gb2YgY29kZXMpIG1haW50 YWluZWQgYnkgSVNPIDYzOSwgSVNPDQogICAxNTkyNCwgSVNPIDMxNjYsIGFuZCBVTiBNLjQ5IGFy ZSByZWZsZWN0ZWQgaW4gdGhlIElBTkEgTGFuZ3VhZ2UNCiAgIFN1YnRhZyBSZWdpc3RyeS4gIEFz c2lnbm1lbnRzIHRvIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeQ0KICAgTVVTVCBm b2xsb3cgdGhlIGZvbGxvd2luZyBzdGFiaWxpdHkgcnVsZXM6DQoNCiAgIG8gIFZhbHVlcyBpbiB0 aGUgZmllbGRzICdUeXBlJywgJ1N1YnRhZycsICdUYWcnLCAnQWRkZWQnIGFuZA0KICAgICAgJ0Nh bm9uaWNhbCcgTVVTVCBOT1QgYmUgY2hhbmdlZCBhbmQgYXJlIGd1YXJhbnRlZWQgdG8gYmUgc3Rh YmxlDQogICAgICBvdmVyIHRpbWUuDQoNCiAgIG8gIFZhbHVlcyBpbiB0aGUgJ0Rlc2NyaXB0aW9u JyBmaWVsZCBNVVNUIE5PVCBiZSBjaGFuZ2VkIGluIGEgd2F5DQogICAgICB0aGF0IHdvdWxkIGlu dmFsaWRhdGUgcHJldmlvdXNseS1leGlzdGluZyB0YWdzLiAgVGhleSBtYXkgYmUNCiAgICAgIGJy b2FkZW5lZCBzb21ld2hhdCBpbiBzY29wZSwgY2hhbmdlZCB0byBhZGQgaW5mb3JtYXRpb24sIG9y DQogICAgICBhZGFwdGVkIHRvIHRoZSBtb3N0IGNvbW1vbiBtb2Rlcm4gdXNhZ2UuICBGb3IgZXhh bXBsZSwgY291bnRyaWVzDQogICAgICBvY2Nhc2lvbmFsbHkgY2hhbmdlIHRoZWlyIG9mZmljaWFs IG5hbWVzOiBhbiBoaXN0b3JpY2FsIGV4YW1wbGUgb2YNCiAgICAgIHRoaXMgd291bGQgYmUgIlVw cGVyIFZvbHRhIiBjaGFuZ2luZyB0byAiQnVya2luYSBGYXNvIi4NCg0KICAgbyAgVmFsdWVzIGlu IHRoZSBmaWVsZCAnUmVjb21tZW5kZWQtUHJlZml4JyBNQVkgYmUgYWRkZWQgdmlhIHRoZQ0KICAg ICAgcmVnaXN0cmF0aW9uIHByb2Nlc3MuDQoNCiAgIG8gIFZhbHVlcyBpbiB0aGUgZmllbGQgJ1Jl Y29tbWVuZGVkLVByZWZpeCcgTUFZIGJlIG1vZGlmaWVkLCBzbyBsb25nDQogICAgICBhcyB0aGUg bW9kaWZpY2F0aW9ucyBicm9hZGVuIHRoZSBzZXQgb2YgcmVjb21tZW5kZWQgcHJlZml4ZXMuDQog ICAgICBUaGF0IGlzLCBhIHJlY29tbWVuZGVkIHByZWZpeCBNQVkgYmUgcmVwbGFjZWQgYnkgb25l IG9mIGl0cyBvd24NCiAgICAgIHByZWZpeGVzLiAgRm9yIGV4YW1wbGUsIHRoZSBwcmVmaXggImVu LVVTIiBjb3VsZCBiZSByZXBsYWNlZCBieQ0KICAgICAgImVuIiwgYnV0IG5vdCBieSB0aGUgcmFu Z2VzICJlbi1MYXRuIiwgImZyIiwgb3IgImVuLVVTLWJvb250Ii4NCg0KICAgbyAgVmFsdWVzIGlu IHRoZSBmaWVsZCAnUmVjb21tZW5kZWQtUHJlZml4JyBNVVNUIE5PVCBiZSByZW1vdmVkLg0KDQog ICBvICBUaGUgZmllbGQgJ0NvbW1lbnRzJyBNQVkgYmUgYWRkZWQsIGNoYW5nZWQsIG1vZGlmaWVk LCBvciByZW1vdmVkDQogICAgICB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIG9yIGFueSBv ZiB0aGUgcHJvY2Vzc2VzIG9yDQogICAgICBjb25zaWRlcmF0aW9ucyBkZXNjcmliZWQgaW4gdGhp cyBzZWN0aW9uLg0KDQogICBvICBUaGUgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgTUFZIGJlIGFk ZGVkIG9yIHJlbW92ZWQgdmlhIHRoZQ0KICAgICAgcmVnaXN0cmF0aW9uIHByb2Nlc3MuDQoNCiAg IG8gIENvZGVzIGFzc2lnbmVkIGJ5IElTTyA2MzksIElTTyAxNTkyNCwgYW5kIElTTyAzMTY2IHRo YXQgZG8gbm90DQogICAgICBjb25mbGljdCB3aXRoIGV4aXN0aW5nIHN1YnRhZ3Mgb2YgdGhlIGFz c29jaWF0ZWQgdHlwZSBhbmQgd2hvc2UNCiAgICAgIG1lYW5pbmcgaXMgbm90IHRoZSBzYW1lIGFz IGFuIGV4aXN0aW5nIHN1YnRhZyBvZiB0aGUgc2FtZSB0eXBlIGFyZQ0KICAgICAgZW50ZXJlZCBp bnRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIG5ldyByZWNvcmRzIGFuZCB0aGVpciB2YWx1ZSBpcw0K ICAgICAgY2Fub25pY2FsIGZvciB0aGUgbWVhbmluZyBhc3NpZ25lZCB0byB0aGVtLg0KDQogICBv ICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08gMTU5MjQsIG9yIElTTyAzMTY2IHRoYXQg YXJlDQogICAgICB3aXRoZHJhd24gYnkgdGhlaXIgcmVzcGVjdGl2ZSBtYWludGVuYW5jZSBvciBy ZWdpc3RyYXRpb24NCiAgICAgIGF1dGhvcml0eSByZW1haW4gdmFsaWQgaW4gbGFuZ3VhZ2UgdGFn cy4gIFRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcw0KICAgICAgTUFZIGJlIHVzZWQgdG8gYWRkIGEg bm90ZSBpbmRpY2F0aW5nIHRoZSB3aXRoZHJhd2FsIG9mIHRoZSBjb2RlIGJ5DQogICAgICB0aGUg cmVzcGVjdGl2ZSBzdGFuZGFyZC4NCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAyM10NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg QXByaWwgMjAwNQ0KDQoNCiAgIG8gIENvZGVzIGFzc2lnbmVkIGJ5IElTTyA2MzksIElTTyAxNTky NCwgb3IgSVNPIDMxNjYgdGhhdCBkbyBub3QNCiAgICAgIGNvbmZsaWN0IHdpdGggZXhpc3Rpbmcg c3VidGFncyBvZiB0aGUgYXNzb2NpYXRlZCB0eXBlIGJ1dCB3aGljaA0KICAgICAgcmVwcmVzZW50 IHRoZSBzYW1lIG1lYW5pbmcgYXMgYW4gZXhpc3Rpbmcgc3VidGFnIG9mIHRoYXQgdHlwZSBhcmUN CiAgICAgIGVudGVyZWQgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcyBuZXcgcmVjb3Jkcy4gIFRo ZSBmaWVsZA0KICAgICAgJ2Nhbm9uaWNhbCB2YWx1ZScgZm9yIHRoYXQgcmVjb3JkIE1VU1QgY29u dGFpbiB0aGUgZXhpc3Rpbmcgc3VidGFnDQogICAgICBvZiB0aGUgc2FtZSBtZWFuaW5nDQoNCiAg ICAgIEV4YW1wbGUgSWYgSVNPIDMxNjYgd2VyZSB0byBhc3NpZ24gdGhlIGNvZGUgJ0lNJyB0byBy ZXByZXNlbnQgdGhlDQogICAgICAgICB2YWx1ZSAiSXNsZSBvZiBNYW4iIChyZXByZXNlbnRlZCBp biB0aGUgSUFOQSByZWdpc3RyeSBieSB0aGUgVU4NCiAgICAgICAgIE0uNDkgY29kZSAnODMzJyks ICc4MzMnIHJlbWFpbnMgdGhlIGNhbm9uaWNhbCBzdWJ0YWcgYW5kICdJTScNCiAgICAgICAgIHdv dWxkIGJlIGFzc2lnbmVkICc4MzMnIGFzIGEgY2Fub25pY2FsIHZhbHVlLiAgVGhpcyBwcmV2ZW50 cw0KICAgICAgICAgdGFncyB0aGF0IGFyZSBpbiBjYW5vbmljYWwgZm9ybSBmcm9tIGJlY29taW5n IG5vbi1jYW5vbmljYWwuDQoNCiAgICAgIEV4YW1wbGUgSWYgdGhlIHRhZyAnZW5vY2hpYW4nIHdl cmUgcmVnaXN0ZXJlZCBhcyBhIHByaW1hcnkNCiAgICAgICAgIGxhbmd1YWdlIHN1YnRhZyBhbmQg SVNPIDYzOSBzdWJzZXF1ZW50bHkgYXNzaWduZWQgYW4gYWxwaGEtMw0KICAgICAgICAgY29kZSB0 byB0aGUgc2FtZSBsYW5ndWFnZSwgdGhlIG5ldyBJU08gNjM5IGNvZGUgd291bGQgYmUNCiAgICAg ICAgIGVudGVyZWQgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcyBhIHN1YnRhZyB3aXRoIGEgY2Fu b25pY2FsDQogICAgICAgICBtYXBwaW5nIHRvICdlbm9jaGlhbicuICBUaGUgbmV3IElTTyBjb2Rl IGNhbiBiZSB1c2VkLCBidXQgaXQgaXMNCiAgICAgICAgIG5vdCBjYW5vbmljYWwuDQoNCiAgIG8g IENvZGVzIGFzc2lnbmVkIGJ5IElTTyA2MzksIElTTyAxNTkyNCwgb3IgSVNPIDMxNjYgdGhhdCBj b25mbGljdA0KICAgICAgd2l0aCBleGlzdGluZyBzdWJ0YWdzIG9mIHRoZSBhc3NvY2lhdGVkIHR5 cGUgTVVTVCBOT1QgYmUgZW50ZXJlZA0KICAgICAgaW50byB0aGUgcmVnaXN0cnkuICBUaGUgZm9s bG93aW5nIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgYXBwbHk6DQoNCiAgICAgICogIEZvciBJ U08gNjM5IGNvZGVzLCBpZiB0aGUgbmV3bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcgaXMgbm90 DQogICAgICAgICByZXByZXNlbnRlZCBieSBhIHN1YnRhZyBpbiB0aGUgSUFOQSByZWdpc3RyeSwg dGhlIExhbmd1YWdlDQogICAgICAgICBTdWJ0YWcgUmV2aWV3ZXIsIGFzIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDMuNCwgc2hhbGwgcHJlcGFyZSBhDQogICAgICAgICBwcm9wb3NhbCBmb3IgZW50ZXJp bmcgaW4gdGhlIElBTkEgcmVnaXN0cnkgYXMgc29vbiBhcyBwcmFjdGljYWwNCiAgICAgICAgIGEg cmVnaXN0ZXJlZCBsYW5ndWFnZSBzdWJ0YWcgYXMgYW4gYWx0ZXJuYXRlIHZhbHVlIGZvciB0aGUg bmV3DQogICAgICAgICBjb2RlLiAgVGhlIGZvcm0gb2YgdGhlIHJlZ2lzdGVyZWQgbGFuZ3VhZ2Ug c3VidGFnIHdpbGwgYmUgYXQNCiAgICAgICAgIHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBMYW5ndWFn ZSBTdWJ0YWcgUmV2aWV3ZXIgYW5kIG11c3QgY29uZm9ybQ0KICAgICAgICAgdG8gb3RoZXIgcmVz dHJpY3Rpb25zIG9uIGxhbmd1YWdlIHN1YnRhZ3MgaW4gdGhpcyBkb2N1bWVudC4NCg0KICAgICAg KiAgRm9yIGFsbCBzdWJ0YWdzIHdob3NlIG1lYW5pbmcgaXMgZGVyaXZlZCBmcm9tIGFuIGV4dGVy bmFsDQogICAgICAgICBzdGFuZGFyZCAoaS5lLiAgSVNPIDYzOSwgSVNPIDE1OTI0LCBJU08gMzE2 Niwgb3IgVU4gTS40OSksIGlmIGENCiAgICAgICAgIG5ldyBtZWFuaW5nIGlzIGFzc2lnbmVkIHRv IGFuIGV4aXN0aW5nIGNvZGUgYW5kIHRoZSBuZXcgbWVhbmluZw0KICAgICAgICAgYnJvYWRlbnMg dGhlIG1lYW5pbmcgb2YgdGhhdCBjb2RlLCB0aGVuIHRoZSBtZWFuaW5nIGZvciB0aGUNCiAgICAg ICAgIGFzc29jaWF0ZWQgc3VidGFnIE1BWSBiZSBjaGFuZ2VkIHRvIG1hdGNoLiAgVGhlIG1lYW5p bmcgb2YgYQ0KICAgICAgICAgc3VidGFnIE1VU1QgTk9UIGJlIG5hcnJvd2VkLCBob3dldmVyLCBh cyB0aGlzIGNhbiByZXN1bHQgaW4gYW4NCiAgICAgICAgIHVua25vd24gcHJvcG9ydGlvbiBvZiB0 aGUgZXhpc3RpbmcgdXNlcyBvZiBhIHN1YnRhZyBiZWNvbWluZw0KICAgICAgICAgaW52YWxpZC4g IE5vdGU6IElTTyA2MzkgTUEvUkEgaGFzIGFkb3B0ZWQgYSBzaW1pbGFyIHN0YWJpbGl0eQ0KICAg ICAgICAgcG9saWN5Lg0KDQogICAgICAqICBGb3IgSVNPIDE1OTI0IGNvZGVzLCBpZiB0aGUgbmV3 bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcgaXMNCiAgICAgICAgIG5vdCByZXByZXNlbnRlZCBi eSBhIHN1YnRhZyBpbiB0aGUgSUFOQSByZWdpc3RyeSwgdGhlIExhbmd1YWdlDQogICAgICAgICBT dWJ0YWcgUmV2aWV3ZXIsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNCwgc2hhbGwgcHJlcGFy ZSBhDQogICAgICAgICBwcm9wb3NhbCBmb3IgZW50ZXJpbmcgaW4gdGhlIElBTkEgcmVnaXN0cnkg YXMgc29vbiBhcyBwcmFjdGljYWwNCiAgICAgICAgIGEgcmVnaXN0ZXJlZCB2YXJpYW50IHN1YnRh ZyBhcyBhbiBhbHRlcm5hdGUgdmFsdWUgZm9yIHRoZSBuZXcNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDI0 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgICAgICAgY29kZS4gIFRoZSBmb3JtIG9mIHRo ZSByZWdpc3RlcmVkIHZhcmlhbnQgc3VidGFnIHdpbGwgYmUgYXQgdGhlDQogICAgICAgICBkaXNj cmV0aW9uIG9mIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgYW5kIG11c3QgY29uZm9ybSB0 bw0KICAgICAgICAgb3RoZXIgcmVzdHJpY3Rpb25zIG9uIHZhcmlhbnQgc3VidGFncyBpbiB0aGlz IGRvY3VtZW50Lg0KDQogICAgICAqICBGb3IgSVNPIDMxNjYgY29kZXMsIGlmIHRoZSBuZXdseSBh c3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBpcw0KICAgICAgICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBz YW1lIFVOIE0uNDkgY29kZSBhcyBhbm90aGVyICdyZWdpb24nDQogICAgICAgICBzdWJ0YWcsIHRo ZW4gdGhlIGV4aXN0aW5nIHJlZ2lvbiBzdWJ0YWcgcmVtYWlucyBhcyB0aGUNCiAgICAgICAgIGNh bm9uaWNhbCBlbnRyeSBmb3IgdGhhdCByZWdpb24gYW5kIG5vIG5ldyBlbnRyeSBpcyBjcmVhdGVk LiAgQQ0KICAgICAgICAgY29tbWVudCBNQVkgYmUgYWRkZWQgdG8gdGhlIGV4aXN0aW5nIHJlZ2lv biBzdWJ0YWcgaW5kaWNhdGluZw0KICAgICAgICAgdGhlIHJlbGF0aW9uc2hpcCB0byB0aGUgbmV3 IElTTyAzMTY2IGNvZGUuDQoNCiAgICAgICogIEZvciBJU08gMzE2NiBjb2RlcywgaWYgdGhlIG5l d2x5IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlzDQogICAgICAgICBhc3NvY2lhdGVkIHdpdGgg YSBVTiBNLjQ5IGNvZGUgdGhhdCBpcyBub3QgcmVwcmVzZW50ZWQgYnkgYW4NCiAgICAgICAgIGV4 aXN0aW5nIHJlZ2lvbiBzdWJ0YWcsIHRoZW4gdGhlbiB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmll d2VyLA0KICAgICAgICAgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40LCBzaGFsbCBwcmVwYXJl IGEgcHJvcG9zYWwgZm9yDQogICAgICAgICBlbnRlcmluZyB0aGUgYXBwcm9wcmlhdGUgbnVtZXJp YyBVTiBjb3VudHJ5IGNvZGUgYXMgYW4gZW50cnkgaW4NCiAgICAgICAgIHRoZSBJQU5BIHJlZ2lz dHJ5Lg0KDQogICAgICAqICBGb3IgSVNPIDMxNjYgY29kZXMsIGlmIHRoZXJlIGlzIG5vIGFzc29j aWF0ZWQgVU4gbnVtZXJpYyBjb2RlLA0KICAgICAgICAgdGhlbiB0aGUgTGFuZ3VhZ2UgU3VidGFn IFJldmlld2VyIFNIQUxMIHBldGl0aW9uIHRoZSBVTiB0bw0KICAgICAgICAgY3JlYXRlIG9uZS4g IElmIHRoZXJlIGlzIG5vIHJlc3BvbnNlIGZyb20gdGhlIFVOIHdpdGhpbiBuaW5ldHkNCiAgICAg ICAgIGRheXMgb2YgdGhlIHJlcXVlc3QgYmVpbmcgc2VudCwgdGhlIExhbmd1YWdlIFN1YnRhZyBS ZXZpZXdlcg0KICAgICAgICAgc2hhbGwgcHJlcGFyZSBhIHByb3Bvc2FsIGZvciBlbnRlcmluZyBp biB0aGUgSUFOQSByZWdpc3RyeSBhcw0KICAgICAgICAgc29vbiBhcyBwcmFjdGljYWwgYSByZWdp c3RlcmVkIHZhcmlhbnQgc3VidGFnIGFzIGFuIGFsdGVybmF0ZQ0KICAgICAgICAgdmFsdWUgZm9y IHRoZSBuZXcgY29kZS4gIFRoZSBmb3JtIG9mIHRoZSByZWdpc3RlcmVkIHZhcmlhbnQNCiAgICAg ICAgIHN1YnRhZyB3aWxsIGJlIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBMYW5ndWFnZSBTdWJ0 YWcNCiAgICAgICAgIFJldmlld2VyIGFuZCBtdXN0IGNvbmZvcm0gdG8gb3RoZXIgcmVzdHJpY3Rp b25zIG9uIHZhcmlhbnQNCiAgICAgICAgIHN1YnRhZ3MgaW4gdGhpcyBkb2N1bWVudC4gIFRoaXMg c2l0dWF0aW9uIGlzIHZlcnkgdW5saWtlbHkgdG8NCiAgICAgICAgIGV2ZXIgb2NjdXIuDQoNCiAg IG8gIFN0YWJpbGl0eSBwcm92aXNpb25zIGFwcGx5IHRvIGdyYW5kZmF0aGVyZWQgdGFncyB3aXRo IHRoaXMNCiAgICAgIGV4Y2VwdGlvbjogc2hvdWxkIGFsbCBvZiB0aGUgc3VidGFncyBpbiBhIGdy YW5kZmF0aGVyZWQgdGFnIGJlY29tZQ0KICAgICAgdmFsaWQgc3VidGFncyBpbiB0aGUgSUFOQSBy ZWdpc3RyeSwgdGhlbiB0aGUgZ3JhbmRmYXRoZXJlZCB0YWcNCiAgICAgIE1VU1QgYmUgbWFya2Vk IGFzIHJlZHVuZGFudC4gIE5vdGUgdGhhdCB0aGlzIHdpbGwgbm90IGFmZmVjdA0KICAgICAgbGFu Z3VhZ2UgdGFncyB0aGF0IG1hdGNoIHRoZSBncmFuZGZhdGhlcmVkIHRhZywgc2luY2UgdGhlc2Ug dGFncw0KICAgICAgd2lsbCBub3cgbWF0Y2ggdmFsaWQgZ2VuZXJhdGl2ZSBzdWJ0YWcgc2VxdWVu Y2VzLiAgRm9yIGV4YW1wbGUsIGlmDQogICAgICB0aGUgc3VidGFnICdnYW4nIGluIHRoZSBsYW5n dWFnZSB0YWcgInpoLWdhbiIgd2VyZSB0byBiZQ0KICAgICAgcmVnaXN0ZXJlZCBhcyBhbiBleHRl bmRlZCBsYW5ndWFnZSBzdWJ0YWcsIHRoZW4gdGhlIGdyYW5kZmF0aGVyZWQNCiAgICAgIHRhZyAi emgtZ2FuIiB3b3VsZCBiZSBkZXByZWNhdGVkIChidXQgZXhpc3RpbmcgY29udGVudCBvcg0KICAg ICAgaW1wbGVtZW50YXRpb25zIHRoYXQgdXNlICJ6aC1nYW4iIHdvdWxkIHJlbWFpbiB2YWxpZCku DQoNCg0KMy40ICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlIGZvciBTdWJ0YWdzDQoNCiAgIFRoZSBw cm9jZWR1cmUgZ2l2ZW4gaGVyZSBNVVNUIGJlIHVzZWQgYnkgYW55b25lIHdobyB3YW50cyB0byB1 c2UgYQ0KICAgc3VidGFnIG5vdCBjdXJyZW50bHkgaW4gdGhlIElBTkEgTGFuZ3VhZ2UgU3VidGFn IFJlZ2lzdHJ5Lg0KDQogICBPbmx5IHN1YnRhZ3MgIG9mIHR5cGUgJ2xhbmd1YWdlJyBhbmQgJ3Zh cmlhbnQnIHdpbGwgYmUgY29uc2lkZXJlZCBmb3INCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDI1XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICAgICBBcHJpbCAyMDA1DQoNCg0KICAgaW5kZXBlbmRlbnQgcmVnaXN0cmF0aW9uIG9mIG5ldyBz dWJ0YWdzLiAgSGFuZGxpbmcgb2Ygc3VidGFncw0KICAgcmVxdWlyZWQgZm9yIHN0YWJpbGl0eSBh bmQgc3VidGFncyByZXF1aXJlZCB0byBrZWVwIHRoZSByZWdpc3RyeQ0KICAgc3luY2hyb25pemVk IHdpdGggSVNPIDYzOSwgSVNPIDE1OTI0LCBJU08gMzE2NiwgYW5kIFVOIE0uNDkgd2l0aGluDQog ICB0aGUgbGltaXRzIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCBhcmUgZGVzY3JpYmVkIGluIFNl Y3Rpb24gMy4yLg0KICAgU3RhYmlsaXR5IHByb3Zpc2lvbnMgYXJlIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDMuMy4NCg0KICAgVGhpcyBwcm9jZWR1cmUgTUFZIGFsc28gYmUgdXNlZCB0byByZWdpc3Rl ciBvciBhbHRlciB0aGUgaW5mb3JtYXRpb24NCiAgIGZvciB0aGUgIkRlc2NyaXB0aW9uIiwgIkNv bW1lbnRzIiwgIkRlcHJlY2F0ZWQiLCBvciAiUmVjb21tZW5kZWQtDQogICBQcmVmaXgiIGZpZWxk cyBpbiBhIHN1YnRhZydzIHJlY29yZCBhcyBkZXNjcmliZWQgaW4gRmlndXJlIDcuDQogICBDaGFu Z2VzIHRvIGFsbCBvdGhlciBmaWVsZHMgaW4gdGhlIElBTkEgcmVnaXN0cnkgYXJlIE5PVCBwZXJt aXR0ZWQuDQoNCiAgIFJlZ2lzdGVyaW5nIGEgbmV3IHN1YnRhZyBvciByZXF1ZXN0aW5nIG1vZGlm aWNhdGlvbnMgdG8gYW4gZXhpc3RpbmcNCiAgIHRhZyBvciBzdWJ0YWcgc3RhcnRzIHdpdGggdGhl IHJlcXVzdGVyIGZpbGxpbmcgb3V0IHRoZSByZWdpc3RyYXRpb24NCiAgIGZvcm0gcmVwcm9kdWNl ZCBiZWxvdy4gIE5vdGUgdGhhdCBlYWNoIHJlc3BvbnNlIGlzIG5vdCBsaW1pdGVkIGluDQogICBz aXplIGFuZCBzaG91bGQgdGFrZSB0aGUgcm9vbSBuZWNlc3NhcnkgdG8gYWRlcXVhdGVseSBkZXNj cmliZSB0aGUNCiAgIHJlZ2lzdHJhdGlvbi4gIFRoZSBmaWVsZHMgaW4gdGhlICJSZWNvcmQgUmVx dWVzdGVkIiBzZWN0aW9uIFNIT1VMRA0KICAgZm9sbG93IHRoZSByZXF1aXJlbWVudHMgaW4gU2Vj dGlvbiAzLjEuDQoNCiAgIExBTkdVQUdFIFNVQlRBRyBSRUdJU1RSQVRJT04gRk9STQ0KICAgMS4g TmFtZSBvZiByZXF1ZXN0ZXI6DQogICAyLiBFLW1haWwgYWRkcmVzcyBvZiByZXF1ZXN0ZXI6DQog ICAzLiBSZWNvcmQgUmVxdWVzdGVkOg0KDQogICBUeXBlOg0KICAgU3VidGFnOg0KICAgRGVzY3Jp cHRpb246DQogICBSZWNvbW1lbmRlZC1QcmVmaXg6DQogICBDYW5vbmljYWw6DQogICBEZXByZWNh dGVkOg0KICAgU3VwcHJlc3MtU2NyaXB0Og0KICAgQ29tbWVudHM6DQoNCiAgIDQuIEludGVuZGVk IG1lYW5pbmcgb2YgdGhlIHN1YnRhZzoNCiAgIDUuIFJlZmVyZW5jZSB0byBwdWJsaXNoZWQgZGVz Y3JpcHRpb24NCiAgIG9mIHRoZSBsYW5ndWFnZSAoYm9vayBvciBhcnRpY2xlKToNCiAgIDYuIEFu eSBvdGhlciByZWxldmFudCBpbmZvcm1hdGlvbjoNCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRmlndXJlIDUNCg0KICAgVGhlIHN1YnRhZyByZWdpc3RyYXRpb24gZm9ybSBNVVNU IGJlIHNlbnQgdG8NCiAgIDxpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZz4gZm9yIGEgdHdvIHdlZWsg cmV2aWV3IHBlcmlvZCBiZWZvcmUgaXQgY2FuDQogICBiZSBzdWJtaXR0ZWQgdG8gSUFOQS4gIChU aGlzIGlzIGFuIG9wZW4gbGlzdC4gIFJlcXVlc3RzIHRvIGJlIGFkZGVkDQogICBzaG91bGQgYmUg c2VudCB0byA8aWV0Zi1sYW5ndWFnZXMtcmVxdWVzdEBpYW5hLm9yZz4uKQ0KDQogICBWYXJpYW50 IHN1YnRhZ3MgYXJlIGdlbmVyYWxseSByZWdpc3RlcmVkIGZvciB1c2Ugd2l0aCBhIHBhcnRpY3Vs YXINCiAgIHJhbmdlIG9mIGxhbmd1YWdlIHRhZ3MuICBGb3IgZXhhbXBsZSwgdGhlIHN1YnRhZyAn c2NvdXNlJyBpcyBpbnRlbmRlZA0KICAgZm9yIHVzZSB3aXRoIGxhbmd1YWdlIHRhZ3MgdGhhdCBz dGFydCB3aXRoIHRoZSBwcmltYXJ5IGxhbmd1YWdlDQogICBzdWJ0YWcgImVuIiwgc2luY2UgU2Nv dXNlIGlzIGEgZGlhbGVjdCBvZiBFbmdsaXNoLiAgVGh1cyB0aGUgc3VidGFnDQoNCg0KDQpQaGls bGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAg ICBbUGFnZSAyNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdp c3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgICdzY291c2UnIGNvdWxkIGJl IGluY2x1ZGVkIGluIHRhZ3Mgc3VjaCBhcyAiZW4tTGF0bi1zY291c2UiIG9yICJlbi0NCiAgIEdC LXNjb3VzZSIuICBUaGlzIGluZm9ybWF0aW9uIGlzIHN0b3JlZCBpbiB0aGUgIlJlY29tbWVuZGVk LVByZWZpeCINCiAgIGZpZWxkIGluIHRoZSByZWdpc3RyeS4gIFZhcmlhbnQgcmVnaXN0cmF0aW9u IHJlcXVlc3RzIGFyZSBSRVFVSVJFRCB0bw0KICAgaW5jbHVkZSBhdCBsZWFzdCBvbmUgIlJlY29t bWVuZGVkLVByZWZpeCIgZmllbGQgaW4gdGhlIHJlZ2lzdHJhdGlvbg0KICAgZm9ybS4NCg0KICAg QW55IHN1YnRhZyBNQVkgYmUgaW5jb3Jwb3JhdGVkIGludG8gYSB2YXJpZXR5IG9mIGxhbmd1YWdl IHRhZ3MsDQogICBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIG9mIFNlY3Rpb24gMi4xLCBpbmNsdWRp bmcgdGFncyB0aGF0IGRvIG5vdA0KICAgbWF0Y2ggYW55IG9mIHRoZSByZWNvbW1lbmRlZCBwcmVm aXhlcyBvZiB0aGUgcmVnaXN0ZXJlZCBzdWJ0YWcuDQogICAoTm90ZSB0aGF0IHRoaXMgaXMgcHJv YmFibHkgYSBwb29yIGNob2ljZS4pICBUaGlzIG1ha2VzIHZhbGlkYXRpb24NCiAgIHNpbXBsZXIg YW5kIHRodXMgbW9yZSB1bmlmb3JtIGFjcm9zcyBpbXBsZW1lbnRhdGlvbnMsIGFuZCBkb2VzIG5v dA0KICAgcmVxdWlyZSB0aGUgcmVnaXN0cmF0aW9uIG9mIGEgc2VwYXJhdGUgc3VidGFnIGZvciB0 aGUgc2FtZSBwdXJwb3NlDQogICBhbmQgbWVhbmluZyBidXQgYSBkaWZmZXJlbnQgcmVjb21tZW5k ZWQgcHJlZml4Lg0KDQogICBUaGUgcmVjb21tZW5kZWQgcHJlZml4ZXMgZm9yIGEgZ2l2ZW4gcmVn aXN0ZXJlZCBzdWJ0YWcgd2lsbCBiZQ0KICAgbWFpbnRhaW5lZCBpbiB0aGUgSUFOQSByZWdpc3Ry eSBhcyBhIGd1aWRlIHRvIHVzYWdlLiAgSWYgaXQgaXMNCiAgIG5lY2Vzc2FyeSB0byBhZGQgYW4g YWRkaXRpb25hbCBwcmVmaXggdG8gdGhhdCBsaXN0IGZvciBhbiBleGlzdGluZw0KICAgbGFuZ3Vh Z2UgdGFnLCB0aGF0IGNhbiBiZSBkb25lIGJ5IGZpbGluZyBhbiBhZGRpdGlvbmFsIHJlZ2lzdHJh dGlvbg0KICAgZm9ybS4gIEluIHRoYXQgZm9ybSwgdGhlICJBbnkgb3RoZXIgcmVsZXZhbnQgaW5m b3JtYXRpb246IiBmaWVsZA0KICAgc2hvdWxkIGluZGljYXRlIHRoYXQgaXQgaXMgdGhlIGFkZGl0 aW9uIG9mIGFuIGFkZGl0aW9uYWwgcmVjb21tZW5kZWQNCiAgIHByZWZpeC4NCg0KICAgUmVxdWVz dHMgdG8gYWRkIGEgcmVjb21tZW5kZWQgcHJlZml4IHRvIGEgc3VidGFnIHRoYXQgaW1wbHkgYQ0K ICAgZGlmZmVyZW50IHNlbWFudGljIG1lYW5pbmcgd2lsbCBwcm9iYWJseSBiZSByZWplY3RlZC4g IEZvciBleGFtcGxlLCBhDQogICByZXF1ZXN0IHRvIGFkZCB0aGUgcHJlZml4ICJkZSIgdG8gdGhl IHN1YnRhZyAnbmVkaXMnIHNvIHRoYXQgdGhlIHRhZw0KICAgImRlLW5lZGlzIiByZXByZXNlbnRl ZCBzb21lIEdlcm1hbiBkaWFsZWN0IHdvdWxkIGJlIHJlamVjdGVkLiAgVGhlDQogICAnbmVkaXMn IHN1YnRhZyByZXByZXNlbnRzIGEgcGFydGljdWxhciBTbG92ZW5pYW4gZGlhbGVjdCBhbmQgdGhl DQogICBhZGRpdGlvbmFsIHJlZ2lzdHJhdGlvbiB3b3VsZCBjaGFuZ2UgdGhlIHNlbWFudGljIG1l YW5pbmcgYXNzaWduZWQgdG8NCiAgIHRoZSBzdWJ0YWcuICBBIHNlcGFyYXRlIHN1YnRhZyBzaG91 bGQgYmUgcHJvcG9zZWQgaW5zdGVhZC4NCg0KICAgVGhlICdEZXNjcmlwdGlvbicgZmllbGQgbXVz dCBjb250YWluIGEgZGVzY3JpcHRpb24gb2YgdGhlIHRhZyBiZWluZw0KICAgcmVnaXN0ZXJlZCB3 cml0dGVuIG9yIHRyYW5zY3JpYmVkIGludG8gdGhlIExhdGluIHNjcmlwdDsgaXQgbWF5IGFsc28N CiAgIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBpbiBhIG5vbi1MYXRpbiBzY3JpcHQuICBOb24tQVND SUkgY2hhcmFjdGVycw0KICAgbXVzdCBiZSBlc2NhcGVkIHVzaW5nIHRoZSBzeW50YXggZGVzY3Jp YmVkIGluIFNlY3Rpb24gMy4xLiAgVGhlDQogICAnRGVzY3JpcHRpb24nIGZpZWxkIGlzIHVzZWQg Zm9yIGlkZW50aWZpY2F0aW9uIHB1cnBvc2VzIGFuZCBzaG91bGQNCiAgIG5vdCBiZSB0YWtlbiB0 byByZXByZXNlbnQgdGhlIGFjdHVhbCBuYXRpdmUgbmFtZSBvZiB0aGUgbGFuZ3VhZ2Ugb3INCiAg IHZhcmlhdGlvbiBvciB0byBiZSBpbiBhbnkgcGFydGljdWxhciBsYW5ndWFnZS4NCg0KICAgV2hp bGUgdGhlICdEZXNjcmlwdGlvbicgZmllbGQgaXRzZWxmIGlzIG5vdCBndWFyYW50ZWVkIHRvIGJl IHN0YWJsZQ0KICAgYW5kIGVycmF0YSBjb3JyZWN0aW9ucyBtYXkgYmUgdW5kZXJ0YWtlbiBmcm9t IHRpbWUgdG8gdGltZSwgYXR0ZW1wdHMNCiAgIHRvIHByb3ZpZGUgdHJhbnNsYXRpb25zIG9yIHRy YW5zY3JpcHRpb25zIG9mIGVudHJpZXMgaW4gdGhlIHJlZ2lzdHJ5DQogICBpdHNlbGYgd2lsbCBw cm9iYWJseSBiZSBmcm93bmVkIHVwb24gYnkgdGhlIGNvbW11bml0eSBvciByZWplY3RlZA0KICAg b3V0cmlnaHQsIGFzIGNoYW5nZXMgb2YgdGhpcyBuYXR1cmUgbWF5IGltcGFjdCB0aGUgcHJvdmlz aW9ucyBpbg0KICAgU2VjdGlvbiAzLjMuDQoNCiAgIFRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3 ZXIgaXMgcmVzcG9uc2libGUgZm9yIHJlc3BvbmRpbmcgdG8NCiAgIHJlcXVlc3RzIGZvciB0aGUg cmVnaXN0cmF0aW9uIG9mIHN1YnRhZ3MgdGhyb3VnaCB0aGUgcmVnaXN0cmF0aW9uDQogICBwcm9j ZXNzICBhbmQgaXMgYXBwb2ludGVkIGJ5IHRoZSBJRVNHLg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgMjdd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICBXaGVuIHRoZSB0d28gd2VlayBwZXJpb2QgaGFz IHBhc3NlZCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyDQogICBlaXRoZXIgZm9yd2FyZHMg dGhlIHJlY29yZCB0byBiZSBpbnNlcnRlZCBvciBtb2RpZmllZCB0bw0KICAgaWFuYUBpYW5hLm9y ZyBhY2NvcmRpbmcgdG8gdGhlIHByb2NlZHVyZSBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIsIG9y DQogICByZWplY3RzIHRoZSByZXF1ZXN0IGJlY2F1c2Ugb2Ygc2lnbmlmaWNhbnQgb2JqZWN0aW9u cyByYWlzZWQgb24gdGhlDQogICBsaXN0IG9yIGR1ZSB0byBwcm9ibGVtcyB3aXRoIGNvbnN0cmFp bnRzIGluIHRoaXMgZG9jdW1lbnQgKHdoaWNoDQogICBzaG91bGQgYmUgZXhwbGljaXRseSBjaXRl ZCkuICBUaGUgcmV2aWV3ZXIgbWF5IGFsc28gZXh0ZW5kIHRoZSByZXZpZXcNCiAgIHBlcmlvZCBp biB0d28gd2VlayBpbmNyZW1lbnRzIHRvIHBlcm1pdCBmdXJ0aGVyIGRpc2N1c3Npb24uICBUaGUN CiAgIHJldmlld2VyIG11c3QgaW5kaWNhdGUgb24gdGhlIGxpc3Qgd2hldGhlciB0aGUgcmVnaXN0 cmF0aW9uIGhhcyBiZWVuDQogICBhY2NlcHRlZCwgcmVqZWN0ZWQsIG9yIGV4dGVuZGVkIGZvbGxv d2luZyBlYWNoIHR3byB3ZWVrIHBlcmlvZC4NCg0KICAgTm90ZSB0aGF0IHRoZSByZXZpZXdlciBj YW4gcmFpc2Ugb2JqZWN0aW9ucyBvbiB0aGUgbGlzdCBpZiBoZSBvciBzaGUNCiAgIHNvIGRlc2ly ZXMuICBUaGUgaW1wb3J0YW50IHRoaW5nIGlzIHRoYXQgdGhlIG9iamVjdGlvbiBtdXN0IGJlIG1h ZGUNCiAgIHB1YmxpY2x5Lg0KDQogICBUaGUgYXBwbGljYW50IGlzIGZyZWUgdG8gbW9kaWZ5IGEg cmVqZWN0ZWQgYXBwbGljYXRpb24gd2l0aA0KICAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhbmQg c3VibWl0IGl0IGFnYWluOyB0aGlzIHJlc3RhcnRzIHRoZSB0d28NCiAgIHdlZWsgY29tbWVudCBw ZXJpb2QuDQoNCiAgIERlY2lzaW9ucyBtYWRlIGJ5IHRoZSByZXZpZXdlciBtYXkgYmUgYXBwZWFs ZWQgdG8gdGhlIElFU0cgW1JGQyAyMDI4XQ0KICAgWzEwXSB1bmRlciB0aGUgc2FtZSBydWxlcyBh cyBvdGhlciBJRVRGIGRlY2lzaW9ucyBbUkZDIDIwMjZdIFs5XS4NCg0KICAgQWxsIGFwcHJvdmVk IHJlZ2lzdHJhdGlvbiBmb3JtcyBhcmUgYXZhaWxhYmxlIG9ubGluZSBpbiB0aGUgZGlyZWN0b3J5 DQogICBodHRwOi8vd3d3LmlhbmEub3JnL251bWJlcnMuaHRtbCB1bmRlciAibGFuZ3VhZ2VzIi4N Cg0KICAgVXBkYXRlcyBvciBjaGFuZ2VzIHRvIGV4aXN0aW5nIHJlY29yZHMsIGluY2x1ZGluZyBw cmV2aW91cw0KICAgcmVnaXN0cmF0aW9ucywgZm9sbG93IHRoZSBzYW1lIHByb2NlZHVyZSBhcyBu ZXcgcmVnaXN0cmF0aW9ucy4gIFRoZQ0KICAgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIGRlY2lk ZXMgd2hldGhlciB0aGVyZSBpcyBjb25zZW5zdXMgdG8gdXBkYXRlDQogICB0aGUgcmVnaXN0cmF0 aW9uIGZvbGxvd2luZyB0aGUgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZDsgbm9ybWFsbHkNCiAgIG9i amVjdGlvbnMgYnkgdGhlIG9yaWdpbmFsIHJlZ2lzdHJhbnQgd2lsbCBjYXJyeSBleHRyYSB3ZWln aHQgaW4NCiAgIGZvcm1pbmcgc3VjaCBhIGNvbnNlbnN1cy4NCg0KICAgUmVnaXN0cmF0aW9ucyBh cmUgcGVybWFuZW50IGFuZCBzdGFibGUuICBPbmNlIHJlZ2lzdGVyZWQsIHN1YnRhZ3MNCiAgIHdp bGwgbm90IGJlIHJlbW92ZWQgZnJvbSB0aGUgcmVnaXN0cnkgYW5kIHdpbGwgcmVtYWluIHRoZSBj YW5vbmljYWwNCiAgIG1ldGhvZCBvZiByZWZlcnJpbmcgdG8gYSBzcGVjaWZpYyBsYW5ndWFnZSBv ciB2YXJpYW50LiAgVGhpcw0KICAgcHJvdmlzaW9uIGRvZXMgbm90IGFwcGx5IHRvIGdyYW5kZmF0 aGVyZWQgdGFncywgd2hpY2ggbWF5IGJlY29tZQ0KICAgZGVwcmVjYXRlZCBkdWUgdG8gcmVnaXN0 cmF0aW9uIG9mIHN1YnRhZ3MuICBGb3IgZXhhbXBsZSwgdGhlIHRhZw0KICAgImktbmF2YWpvIiBp cyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBJU08gNjM5LTEgYmFzZWQgc3VidGFnICdudicu DQoNCiAgIE5vdGU6IFRoZSBwdXJwb3NlIG9mIHRoZSAicHVibGlzaGVkIGRlc2NyaXB0aW9uIiBp biB0aGUgcmVnaXN0cmF0aW9uDQogICBmb3JtIGlzIGludGVuZGVkIGFzIGFuIGFpZCB0byBwZW9w bGUgdHJ5aW5nIHRvIHZlcmlmeSB3aGV0aGVyIGENCiAgIGxhbmd1YWdlIGlzIHJlZ2lzdGVyZWQg b3Igd2hhdCBsYW5ndWFnZSBvciBsYW5ndWFnZSB2YXJpYXRpb24gYQ0KICAgcGFydGljdWxhciBz dWJ0YWcgcmVmZXJzIHRvLiAgSW4gbW9zdCBjYXNlcywgcmVmZXJlbmNlIHRvIGFuDQogICBhdXRo b3JpdGF0aXZlIGdyYW1tYXIgb3IgZGljdGlvbmFyeSBvZiB0aGF0IGxhbmd1YWdlIHdpbGwgYmUg dXNlZnVsOw0KICAgaW4gY2FzZXMgd2hlcmUgbm8gc3VjaCB3b3JrIGV4aXN0cywgb3RoZXIgd2Vs bCBrbm93biB3b3JrcyBkZXNjcmliaW5nDQogICB0aGF0IGxhbmd1YWdlIG9yIGluIHRoYXQgbGFu Z3VhZ2UgbWF5IGJlIGFwcHJvcHJpYXRlLiAgVGhlIHN1YnRhZw0KICAgcmV2aWV3ZXIgZGVjaWRl cyB3aGF0IGNvbnN0aXR1dGVzICJnb29kIGVub3VnaCIgcmVmZXJlbmNlIG1hdGVyaWFsLg0KICAg VGhpcyByZXF1aXJlbWVudCBpcyBub3QgaW50ZW5kZWQgdG8gZXhjbHVkZSBwYXJ0aWN1bGFyIGxh bmd1YWdlcyBvcg0KICAgZGlhbGVjdHMgZHVlIHRvIHRoZSBzaXplIG9mIHRoZSBzcGVha2VyIHBv cHVsYXRpb24gb3IgbGFjayBvZiBhDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBp cmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAyOF0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXBy aWwgMjAwNQ0KDQoNCiAgIHN0YW5kYXJkaXplZCBvcnRob2dyYXBoeS4gIE1pbm9yaXR5IGxhbmd1 YWdlcyB3aWxsIGJlIGNvbnNpZGVyZWQNCiAgIGVxdWFsbHkgb24gdGhlaXIgb3duIG1lcml0cy4N Cg0KMy41ICBQb3NzaWJpbGl0aWVzIGZvciBSZWdpc3RyYXRpb24NCg0KICAgUG9zc2liaWxpdGll cyBmb3IgcmVnaXN0cmF0aW9uIG9mIHN1YnRhZ3Mgb3IgaW5mb3JtYXRpb24gYWJvdXQNCiAgIHN1 YnRhZ3MgaW5jbHVkZToNCg0KICAgbyAgUHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIGZvciBsYW5n dWFnZXMgbm90IGxpc3RlZCBpbiBJU08gNjM5IHRoYXQNCiAgICAgIGFyZSBub3QgdmFyaWFudHMg b2YgYW55IGxpc3RlZCBvciByZWdpc3RlcmVkIGxhbmd1YWdlIGNhbiBiZQ0KICAgICAgcmVnaXN0 ZXJlZC4gIEF0IHRoZSB0aW1lIHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQgdGhlcmUgd2VyZSBu bw0KICAgICAgZXhhbXBsZXMgb2YgdGhpcyBmb3JtIG9mIHN1YnRhZy4gIEJlZm9yZSBhdHRlbXB0 aW5nIHRvIHJlZ2lzdGVyIGENCiAgICAgIGxhbmd1YWdlIHN1YnRhZywgdGhlcmUgTVVTVCBiZSBh biBhdHRlbXB0IHRvIHJlZ2lzdGVyIHRoZSBsYW5ndWFnZQ0KICAgICAgd2l0aCBJU08gNjM5LiAg Tm8gbGFuZ3VhZ2Ugc3VidGFncyB3aWxsIGJlIHJlZ2lzdGVyZWQgZm9yIGNvZGVzDQogICAgICB0 aGF0IGV4aXN0IGluIElTTyA2MzktMSBvciBJU08gNjM5LTIsIHdoaWNoIGFyZSB1bmRlcg0KICAg ICAgY29uc2lkZXJhdGlvbiBieSB0aGUgSVNPIDYzOSBtYWludGVuYW5jZSBvciByZWdpc3RyYXRp b24NCiAgICAgIGF1dGhvcml0aWVzLCBvciB3aGljaCBoYXZlIG5ldmVyIGJlZW4gYXR0ZW1wdGVk IGZvciByZWdpc3RyYXRpb24NCiAgICAgIHdpdGggdGhvc2UgYXV0aG9yaXRpZXMuICBJZiBJU08g NjM5IGhhcyBwcmV2aW91c2x5IHJlamVjdGVkIGENCiAgICAgIGxhbmd1YWdlIGZvciByZWdpc3Ry YXRpb24sIGl0IGlzIHJlYXNvbmFibGUgdG8gYXNzdW1lIHRoYXQgdGhlcmUNCiAgICAgIE1VU1Qg YmUgYWRkaXRpb25hbCB2ZXJ5IGNvbXBlbGxpbmcgZXZpZGVuY2Ugb2YgbmVlZCBiZWZvcmUgaXQg d2lsbA0KICAgICAgYmUgcmVnaXN0ZXJlZCBpbiB0aGUgSUFOQSByZWdpc3RyeSAodG8gdGhlIGV4 dGVudCB0aGF0IGl0IGlzIHZlcnkNCiAgICAgIHVubGlrZWx5IHRoYXQgYW55IHN1YnRhZ3Mgd2ls bCBiZSByZWdpc3RlcmVkIG9mIHRoaXMgdHlwZSkuDQoNCiAgIG8gIERpYWxlY3Qgb3Igb3RoZXIg ZGl2aXNpb25zIG9yIHZhcmlhdGlvbnMgd2l0aGluIGEgbGFuZ3VhZ2UsIGl0cw0KICAgICAgb3J0 aG9ncmFwaHksIHdyaXRpbmcgc3lzdGVtLCByZWdpb25hbCBvciBoaXN0b3JpY2FsIHVzYWdlLA0K ICAgICAgdHJhbnNsaXRlcmF0aW9uIG9yIG90aGVyIHRyYW5zZm9ybWF0aW9uLCBvciBkaXN0aW5n dWlzaGluZw0KICAgICAgdmFyaWF0aW9uIG1heSBiZSByZWdpc3RlcmVkIGFzIHZhcmlhbnQgc3Vi dGFncy4gIEFuIGV4YW1wbGUgaXMgdGhlDQogICAgICAnc2NvdXNlJyBzdWJ0YWcgKHRoZSBTY291 c2UgZGlhbGVjdCBvZiBFbmdsaXNoKS4NCg0KICAgbyAgVGhlIGFkZGl0aW9uIG9yIG1haW50ZW5h bmNlIG9mIGZpZWxkcyAoZ2VuZXJhbGx5IG9mIGFuDQogICAgICBpbmZvcm1hdGlvbmFsIG5hdHVy ZSkgaW4gVGFnIG9yIFN1YnRhZyByZWNvcmRzIGFzIGRlc2NyaWJlZCBpbg0KICAgICAgU2VjdGlv biAzLjEgYW5kIHN1YmplY3QgdG8gdGhlIHN0YWJpbGl0eSBwcm92aXNpb25zIGluDQogICAgICBT ZWN0aW9uIDMuMy4gIFRoaXMgaW5jbHVkZXMgZGVzY3JpcHRpb25zLCByZWNvbW1lbmRlZCBwcmVm aXhlcywNCiAgICAgIGNvbW1lbnRzLCBkZXByZWNhdGlvbiBvZiBvYnNvbGV0ZSBpdGVtcywgb3Ig dGhlIGFkZGl0aW9uIG9mIHNjcmlwdA0KICAgICAgb3IgZXh0bGFuZyBpbmZvcm1hdGlvbiB0byBw cmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3MuDQoNCiAgIFRoaXMgZG9jdW1lbnQgbGVhdmVzIHRoZSBk ZWNpc2lvbiBvbiB3aGF0IHN1YnRhZ3MgIG9yIGNoYW5nZXMgdG8NCiAgIHN1YnRhZ3MgYXJlIGFw cHJvcHJpYXRlIChvciBub3QpIHRvIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcw0KICAgZGVzY3Jp YmVkIGluIFNlY3Rpb24gMy40Lg0KDQogICBOb3RlOiA0LWNoYXJhY3RlciBwcmltYXJ5IGxhbmd1 YWdlIHN1YnRhZ3MgYXJlIHJlc2VydmVkIHRvIGFsbG93IGZvcg0KICAgdGhlIHBvc3NpYmlsaXR5 IG9mICBhbHBoYTQgY29kZXMgaW4gc29tZSBmdXR1cmUgYWRkaXRpb24gdG8gdGhlIElTTw0KICAg NjM5IGZhbWlseSBvZiBzdGFuZGFyZHMuDQoNCiAgIElTTyA2MzkgZGVmaW5lcyBhIG1haW50ZW5h bmNlIGFnZW5jeSBmb3IgYWRkaXRpb25zIHRvIGFuZCBjaGFuZ2VzIGluDQogICB0aGUgbGlzdCBv ZiBsYW5ndWFnZXMgaW4gSVNPIDYzOS4gIFRoaXMgYWdlbmN5IGlzOg0KDQogICBJbnRlcm5hdGlv bmFsIEluZm9ybWF0aW9uIENlbnRyZSBmb3IgVGVybWlub2xvZ3kgKEluZm90ZXJtKQ0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1ICAgICAgICAg ICAgICAgW1BhZ2UgMjldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICAgQWljaGhvbHpnYXNz ZSA2LzEyLCBBVC0xMTIwDQogICBXaWVuLCBBdXN0cmlhDQogICBQaG9uZTogKzQzIDEgMjYgNzUg MzUgRXh0LiAzMTIgRmF4OiArNDMgMSAyMTYgMzIgNzINCg0KICAgSVNPIDYzOS0yIGRlZmluZXMg YSBtYWludGVuYW5jZSBhZ2VuY3kgZm9yIGFkZGl0aW9ucyB0byBhbmQgY2hhbmdlcw0KICAgaW4g dGhlIGxpc3Qgb2YgbGFuZ3VhZ2VzIGluIElTTyA2MzktMi4gIFRoaXMgYWdlbmN5IGlzOg0KDQog ICBMaWJyYXJ5IG9mIENvbmdyZXNzDQogICBOZXR3b3JrIERldmVsb3BtZW50IGFuZCBNQVJDIFN0 YW5kYXJkcyBPZmZpY2UNCiAgIFdhc2hpbmd0b24sIEQuQy4gMjA1NDAgVVNBDQogICBQaG9uZTog KzEgMjAyIDcwNyA2MjM3ICBGYXg6ICsxIDIwMiA3MDcgMDExNQ0KICAgVVJMOiBodHRwOi8vd3d3 LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOQ0KDQogICBUaGUgbWFpbnRlbmFuY2UgYWdlbmN5IGZv ciBJU08gMzE2NiAoY291bnRyeSBjb2RlcykgaXM6DQoNCiAgIElTTyAzMTY2IE1haW50ZW5hbmNl IEFnZW5jeQ0KICAgYy9vIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6 YXRpb24NCiAgIENhc2UgcG9zdGFsZSA1Ng0KICAgQ0gtMTIxMSBHZW5ldmEgMjAgU3dpdHplcmxh bmQNCiAgIFBob25lOiArNDEgMjIgNzQ5IDcyIDMzICBGYXg6ICs0MSAyMiA3NDkgNzMgNDkNCiAg IFVSTDogaHR0cDovL3d3dy5pc28ub3JnL2lzby9lbi9wcm9kcy1zZXJ2aWNlcy9pc28zMTY2bWEv aW5kZXguaHRtbA0KDQogICBUaGUgcmVnaXN0cmF0aW9uIGF1dGhvcml0eSBmb3IgSVNPIDE1OTI0 IChzY3JpcHQgY29kZXMpIGlzOg0KDQogICBVbmljb2RlIENvbnNvcnRpdW0gQm94IDM5MTQ3Ng0K ICAgTW91bnRhaW4gVmlldywgQ0EgOTQwMzktMTQ3NiwgVVNBDQogICBVUkw6IGh0dHA6Ly93d3cu dW5pY29kZS5vcmcvaXNvMTU5MjQNCg0KICAgVGhlIFN0YXRpc3RpY3MgRGl2aXNpb24gb2YgdGhl IFVuaXRlZCBOYXRpb25zIFNlY3JldGFyaWF0IG1haW50YWlucw0KICAgdGhlIFN0YW5kYXJkIENv dW50cnkgb3IgQXJlYSBDb2RlcyBmb3IgU3RhdGlzdGljYWwgVXNlIGFuZCBjYW4gYmUNCiAgIHJl YWNoZWQgYXQ6DQoNCiAgIFN0YXRpc3RpY2FsIFNlcnZpY2VzIEJyYW5jaA0KICAgU3RhdGlzdGlj cyBEaXZpc2lvbg0KICAgVW5pdGVkIE5hdGlvbnMsIFJvb20gREMyLTE2MjANCiAgIE5ldyBZb3Jr LCBOWSAxMDAxNywgVVNBDQoNCiAgIEZheDogKzEtMjEyLTk2My0wNjIzDQogICBFLW1haWw6IHN0 YXRpc3RpY3NAdW4ub3JnDQogICBVUkw6IGh0dHA6Ly91bnN0YXRzLnVuLm9yZy91bnNkL21ldGhv ZHMvbTQ5L200OWFscGhhLmh0bQ0KDQozLjYgIEV4dGVuc2lvbnMgYW5kIEV4dGVuc2lvbnMgTmFt ZXNwYWNlDQoNCiAgIEV4dGVuc2lvbiBzdWJ0YWdzIGFyZSB0aG9zZSBpbnRyb2R1Y2VkIGJ5IHNp bmdsZS1sZXR0ZXIgc3VidGFncyBvdGhlcg0KICAgdGhhbiAneC0nLiAgVGhleSBhcmUgcmVzZXJ2 ZWQgZm9yIHRoZSBnZW5lcmF0aW9uIG9mIGlkZW50aWZpZXJzIHdoaWNoDQogICBjb250YWluIGEg bGFuZ3VhZ2UgY29tcG9uZW50LCBhbmQgYXJlIGNvbXBhdGlibGUgd2l0aCBhcHBsaWNhdGlvbnMN CiAgIHVuZGVyc3RhbmQgbGFuZ3VhZ2UgdGFncy4gIEZvciBleGFtcGxlLCB0aGV5IG1pZ2h0IGJl IHVzZWQgdG8gZGVmaW5lDQogICBsb2NhbGUgaWRlbnRpZmllcnMsIHdoaWNoIGFyZSBnZW5lcmFs bHkgYmFzZWQgb24gbGFuZ3VhZ2UuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBp cmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAzMF0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXBy aWwgMjAwNQ0KDQoNCiAgIFRoZSBzdHJ1Y3R1cmUgYW5kIGZvcm0gb2YgZXh0ZW5zaW9ucyBhcmUg ZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50IHNvDQogICB0aGF0IGltcGxlbWVudGF0aW9ucyBjYW4g YmUgY3JlYXRlZCB0aGF0IGFyZSBmb3J3YXJkIGNvbXBhdGlibGUgd2l0aA0KICAgYXBwbGljYXRp b25zIHRoYXQgbWF5IGJlIGNyZWF0ZWQgdXNpbmcgc2luZ2xlLWxldHRlciBzdWJ0YWdzIGluIHRo ZQ0KICAgZnV0dXJlLiAgSW4gYWRkaXRpb24sIGRlZmluaW5nIGEgbWVjaGFuaXNtIGZvciBtYWlu dGFpbmluZyBzaW5nbGUtDQogICBsZXR0ZXIgc3VidGFncyB3aWxsIGxlbmQgdG8gdGhlIHN0YWJp bGl0eSBvZiB0aGlzIGRvY3VtZW50IGJ5DQogICByZWR1Y2luZyB0aGUgbGlrZWx5IG5lZWQgZm9y IGZ1dHVyZSByZXZpc2lvbnMgb3IgdXBkYXRlcy4NCg0KICAgQWxsb2NhdGlvbiBvZiBhIHNpbmds ZS1sZXR0ZXIgc3VidGFnIHNoYWxsIHRha2UgdGhlIGZvcm0gb2YgYW4gUkZDDQogICBkZWZpbmlu ZyB0aGUgbmFtZSwgcHVycG9zZSwgcHJvY2Vzc2VzLCBhbmQgcHJvY2VkdXJlcyBmb3IgbWFpbnRh aW5pbmcNCiAgIHRoZSBzdWJ0YWdzLiAgVGhlIG1haW50YWluaW5nIG9yIHJlZ2lzdGVyaW5nIGF1 dGhvcml0eSwgaW5jbHVkaW5nDQogICBuYW1lLCBjb250YWN0IGVtYWlsLCBkaXNjdXNzaW9uIGxp c3QgZW1haWwsIGFuZCBVUkwgbG9jYXRpb24gb2YgdGhlDQogICByZWdpc3RyeSBtdXN0IGJlIGlu ZGljYXRlZCBjbGVhcmx5IGluIHRoZSBSRkMuICBUaGUgUkZDIE1VU1Qgc3BlY2lmeQ0KICAgb3Ig aW5jbHVkZSBlYWNoIG9mIHRoZSBmb2xsb3dpbmc6DQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9u IE1VU1QgcmVmZXJlbmNlIHRoZSBzcGVjaWZpYyB2ZXJzaW9uIG9yIHJldmlzaW9uDQogICAgICBv ZiB0aGlzIGRvY3VtZW50IHRoYXQgZ292ZXJucyBpdHMgY3JlYXRpb24gYW5kIE1VU1QgcmVmZXJl bmNlIHRoaXMNCiAgICAgIHNlY3Rpb24gb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgbyAgVGhlIHNw ZWNpZmljYXRpb24gYW5kIGFsbCBzdWJ0YWdzIGRlZmluZWQgYnkgdGhlIHNwZWNpZmljYXRpb24N CiAgICAgIE1VU1QgZm9sbG93IHRoZSBBQk5GIGFuZCBvdGhlciBydWxlcyBmb3IgdGhlIGZvcm1h dGlvbiBvZiB0YWdzIGFuZA0KICAgICAgc3VidGFncyBhcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1l bnQuICBJbiBwYXJ0aWN1bGFyIGl0IE1VU1QNCiAgICAgIHNwZWNpZnkgdGhhdCBjYXNlIGlzIG5v dCBzaWduaWZpY2FudCBhbmQgdGhhdCBzdWJ0YWdzIE1VU1QgTk9UDQogICAgICBleGNlZWQgZWln aHQgY2hhcmFjdGVycyBpbiBsZW5ndGguDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1Qg c3BlY2lmeSBhIGNhbm9uaWNhbCByZXByZXNlbnRhdGlvbi4NCg0KICAgbyAgVGhlIHNwZWNpZmlj YXRpb24gb2YgdmFsaWQgc3VidGFncyBNVVNUIGJlIGF2YWlsYWJsZSBvdmVyIHRoZQ0KICAgICAg SW50ZXJuZXQgYW5kIGF0IG5vIGNvc3QuDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1Qg YmUgaW4gdGhlIHB1YmxpYyBkb21haW4gb3IgYXZhaWxhYmxlIHZpYSBhDQogICAgICByb3lhbHR5 LWZyZWUgbGljZW5zZSBhY2NlcHRhYmxlIHRvIHRoZSBJRVRGIGFuZCBzcGVjaWZpZWQgaW4gdGhl DQogICAgICBSRkMuDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgdmVyc2lvbmVk IGFuZCBlYWNoIHZlcnNpb24gb2YgdGhlDQogICAgICBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgbnVt YmVyZWQsIGRhdGVkLCBhbmQgc3RhYmxlLg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNU IGJlIHN0YWJsZS4gIFRoYXQgaXMsIGV4dGVuc2lvbiBzdWJ0YWdzLA0KICAgICAgb25jZSBkZWZp bmVkIGJ5IGEgc3BlY2lmaWNhdGlvbiwgTVVTVCBOT1QgYmUgcmV0cmFjdGVkIG9yIGNoYW5nZQ0K ICAgICAgaW4gbWVhbmluZyBpbiBhbnkgc3Vic3RhbnRpYWwgd2F5Lg0KDQogICBvICBUaGUgc3Bl Y2lmaWNhdGlvbiBNVVNUIGluY2x1ZGUgaW4gYSBzZXBhcmF0ZSBzZWN0aW9uIHRoZQ0KICAgICAg cmVnaXN0cmF0aW9uIGZvcm0gcmVwcm9kdWNlZCBpbiB0aGlzIHNlY3Rpb24gKGJlbG93KSB0byBi ZSB1c2VkIGluDQogICAgICByZWdpc3RlcmluZyB0aGUgZXh0ZW5zaW9uIHVwb24gcHVibGljYXRp b24gYXMgYW4gUkZDLg0KDQogICBvICBJQU5BIE1VU1QgYmUgaW5mb3JtZWQgb2YgY2hhbmdlcyB0 byB0aGUgY29udGFjdCBpbmZvcm1hdGlvbiBhbmQNCiAgICAgIFVSTCBmb3IgdGhlIHNwZWNpZmlj YXRpb24uDQoNCiAgIElBTkEgd2lsbCBtYWludGFpbiBhIHJlZ2lzdHJ5IG9mIGFsbG9jYXRlZCBz aW5nbGUtbGV0dGVyIChzaW5nbGV0b24pDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAzMV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg QXByaWwgMjAwNQ0KDQoNCiAgIHN1YnRhZ3MuICBUaGlzIHJlZ2lzdHJ5IHdpbGwgdXNlIHRoZSBy ZWNvcmQtamFyIGZvcm1hdCBkZXNjcmliZWQgYnkNCiAgIHRoZSBBQk5GIGluIFNlY3Rpb24gMy4x LiAgVXBvbiBwdWJsaWNhdGlvbiBvZiBhbiBleHRlbnNpb24gYXMgYW4gUkZDLA0KICAgdGhlIG1h aW50YWluaW5nIGF1dGhvcml0eSBkZWZpbmVkIGluIHRoZSBSRkMgbXVzdCBmb3J3YXJkIHRoaXMN CiAgIHJlZ2lzdHJhdGlvbiBmb3JtIHRvIGllc2dAaWV0Zi5vcmcsIHdobyB3aWxsIGZvcndhcmQg dGhlIHJlcXVlc3QgdG8NCiAgIGlhbmFAaWFuYS5vcmcuICBUaGUgbWFpbnRhaW5pbmcgYXV0aG9y aXR5IG9mIHRoZSBleHRlbnNpb24gTVVTVA0KICAgbWFpbnRhaW4gdGhlIGFjY3VyYWN5IG9mIHRo ZSByZWNvcmQgYnkgc2VuZGluZyBhbiB1cGRhdGVkIGZ1bGwgY29weQ0KICAgb2YgdGhlIHJlY29y ZCB0byBpYW5hQGlhbmEub3JnIHdpdGggdGhlIHN1YmplY3QgbGluZSAiTEFOR1VBR0UgVEFHDQog ICBFWFRFTlNJT04gVVBEQVRFIiB3aGVuZXZlciBjb250ZW50IGNoYW5nZXMuICBPbmx5IHRoZSAn Q29tbWVudHMnLA0KICAgJ0NvbnRhY3RfRW1haWwnLCAnTWFpbGluZ19MaXN0JywgYW5kICdVUkwn IGZpZWxkcyBtYXkgYmUgbW9kaWZpZWQgaW4NCiAgIHRoZXNlIHVwZGF0ZXMuDQoNCiAgIEZhaWx1 cmUgdG8gbWFpbnRhaW4gdGhpcyByZWNvcmQsIHRoZSBjb3JyZXNwb25kaW5nIHJlZ2lzdHJ5LCBv ciBtZWV0DQogICBvdGhlciBjb25kaXRpb25zIGltcG9zZWQgYnkgdGhpcyBzZWN0aW9uIG9mIHRo aXMgZG9jdW1lbnQgbWF5IGJlDQogICBhcHBlYWxlZCB0byB0aGUgSUVTRyBbUkZDIDIwMjhdIFsx MF0gdW5kZXIgdGhlIHNhbWUgcnVsZXMgYXMgb3RoZXINCiAgIElFVEYgZGVjaXNpb25zIChzZWUg WzldKSBhbmQgbWF5IHJlc3VsdCBpbiB0aGUgYXV0aG9yaXR5IHRvIG1haW50YWluDQogICB0aGUg ZXh0ZW5zaW9uIGJlaW5nIHdpdGhkcmF3biBvciByZWFzc2lnbmVkIGJ5IHRoZSBJRVNHLg0KICAg JSUNCiAgIElkZW50aWZpZXI6DQogICBEZXNjcmlwdGlvbjoNCiAgIENvbW1lbnRzOg0KICAgQWRk ZWQ6DQogICBSRkM6DQogICBBdXRob3JpdHk6DQogICBDb250YWN0X0VtYWlsOg0KICAgTWFpbGlu Z19MaXN0Og0KICAgVVJMOg0KICAgJSUNCg0KICAgIEZpZ3VyZSA2OiBGb3JtYXQgb2YgUmVjb3Jk cyBpbiB0aGUgTGFuZ3VhZ2UgVGFnIEV4dGVuc2lvbnMgUmVnaXN0cnkNCg0KICAgJ0lkZW50aWZp ZXInIGNvbnRhaW5zIHRoZSBzaW5nbGUgbGV0dGVyIHN1YnRhZyAoc2luZ2xldG9uKSBhc3NpZ25l ZA0KICAgdG8gdGhlIGV4dGVuc2lvbi4gIFRoZSBJbnRlcm5ldC1EcmFmdCBzdWJtaXR0ZWQgdG8g ZGVmaW5lIHRoZQ0KICAgZXh0ZW5zaW9uIHNob3VsZCBzcGVjaWZpYyB3aGljaCBsZXR0ZXIgdG8g dXNlLCBhbHRob3VnaCB0aGUgSUVTRyBtYXkNCiAgIGNoYW5nZSB0aGUgYXNzaWdubWVudCB3aGVu IGFwcHJvdmluZyB0aGUgUkZDLg0KDQogICAnRGVzY3JpcHRpb24nIGNvbnRhaW5zIHRoZSBuYW1l IGFuZCBkZXNjcmlwdGlvbiBvZiB0aGUgZXh0ZW5zaW9uLg0KDQogICAnQ29tbWVudHMnIGlzIGFu IG9wdGlvbmFsIGZpZWxkIGFuZCBtYXkgY29udGFpbiBhIGJyb2FkZXIgZGVzY3JpcHRpb24NCiAg IG9mIHRoZSBleHRlbnNpb24uDQoNCiAgICdBZGRlZCcgY29udGFpbnMgdGhlIGRhdGUgdGhlIFJG QyB3YXMgcHVibGlzaGVkIGluIHRoZSAiZnVsbC1kYXRlIg0KICAgZm9ybWF0IHNwZWNpZmllZCBp biBSRkMgMzMzOSBbMTRdLiAgRm9yIGV4YW1wbGU6IDIwMDQtMDYtMjgNCiAgIHJlcHJlc2VudHMg SnVuZSAyOCwgMjAwNCwgaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRhci4NCg0KICAgJ1JGQycgY29u dGFpbnMgdGhlIFJGQyBudW1iZXIgYXNzaWduZWQgdG8gdGhlIGV4dGVuc2lvbi4NCg0KICAgJ0F1 dGhvcml0eScgY29udGFpbnMgdGhlIG5hbWUgb2YgdGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBm b3IgdGhlDQogICBleHRlbnNpb24uDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBp cmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAzMl0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXBy aWwgMjAwNQ0KDQoNCiAgICdDb250YWN0X0VtYWlsJyBjb250YWlucyB0aGUgZW1haWwgYWRkcmVz cyB1c2VkIHRvIGNvbnRhY3QgdGhlDQogICBtYWludGFpbmluZyBhdXRob3JpdHkuDQoNCiAgICdN YWlsaW5nX0xpc3QnIGNvbnRhaW5zIHRoZSBVUkwgb3Igc3Vic2NyaXB0aW9uIGVtYWlsIGFkZHJl c3Mgb2YgdGhlDQogICBtYWlsaW5nIGxpc3QgdXNlZCBieSB0aGUgbWFpbnRhaW5pbmcgYXV0aG9y aXR5Lg0KDQogICAnVVJMJyBjb250YWlucyB0aGUgVVJMIG9mIHRoZSByZWdpc3RyeSBmb3IgdGhp cyBleHRlbnNpb24uDQoNCiAgIFRoZSBkZXRlcm1pbmF0aW9uIG9mIHdoZXRoZXIgYW4gSW50ZXJu ZXQtRHJhZnQgbWVldHMgdGhlIGFib3ZlDQogICBjb25kaXRpb25zIGFuZCB0aGUgZGVjaXNpb24g dG8gZ3JhbnQgb3Igd2l0aGhvbGQgc3VjaCBhdXRob3JpdHkgcmVzdHMNCiAgIHNvbGVseSB3aXRo IHRoZSBJRVNHLCBhbmQgaXMgc3ViamVjdCB0byB0aGUgbm9ybWFsIHJldmlldyBhbmQgYXBwZWFs cw0KICAgcHJvY2VzcyBhc3NvY2lhdGVkIHdpdGggdGhlIFJGQyBwcm9jZXNzLg0KDQogICBFeHRl bnNpb24gYXV0aG9ycyBhcmUgc3Ryb25nbHkgY2F1dGlvbmVkIHRoYXQgbWFueSAoaW5jbHVkaW5n IG1vc3QNCiAgIHdlbGwtZm9ybWVkKSBwcm9jZXNzb3JzIHdpbGwgYmUgdW5hd2FyZSBvZiBhbnkg c3BlY2lhbCByZWxhdGlvbnNoaXBzDQogICBvciBtZWFuaW5nIGluaGVyZW50IGluIHRoZSBvcmRl ciBvZiBleHRlbnNpb24gc3VidGFncy4gIEV4dGVuc2lvbg0KICAgYXV0aG9ycyBTSE9VTEQgYXZv aWQgc3VidGFnIHJlbGF0aW9uc2hpcHMgb3IgY2Fub25pY2FsaXphdGlvbg0KICAgbWVjaGFuaXNt cyB0aGF0IGludGVyZmVyZSB3aXRoIG1hdGNoaW5nIG9yIHdpdGggbGVuZ3RoIHJlc3RyaWN0aW9u cw0KICAgdGhhdCBtYXkgZXhpc3QgaW4gY29tbW9uIHByb3RvY29scyB3aGVyZSB0aGUgZXh0ZW5z aW9uIGlzIHVzZWQuICBJbg0KICAgcGFydGljdWxhciwgYXBwbGljYXRpb25zIG1heSB0cnVuY2F0 ZSB0aGUgc3VidGFncyBpbiBkb2luZyBtYXRjaGluZw0KICAgb3IgaW4gZml0dGluZyBpbnRvIGxp bWl0ZWQgbGVuZ3Rocywgc28gaXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUNCiAgIG1vc3Qgc2ln bmlmaWNhbnQgaW5mb3JtYXRpb24gYmUgaW4gdGhlIG1vc3Qgc2lnbmlmaWNhbnQgKGxlZnQtbW9z dCkNCiAgIHN1YnRhZ3MsIGFuZCB0aGF0IHRoZSBzcGVjaWZpY2F0aW9uIGdyYWNlZnVsbHkgaGFu ZGxlIHRydW5jYXRlZA0KICAgc3VidGFncy4NCg0KICAgV2hlbiBhIGxhbmd1YWdlIHRhZyBpcyB0 byBiZSB1c2VkIGluIGEgc3BlY2lmaWMsIGtub3duLCBwcm90b2NvbCwgaXQNCiAgIGlzIFJFQ09N TUVOREVEIHRoYXQgdGhhdCB0aGUgbGFuZ3VhZ2UgdGFnIG5vdCBjb250YWluIGV4dGVuc2lvbnMg bm90DQogICBzdXBwb3J0ZWQgYnkgdGhhdCBwcm90b2NvbC4gIEluIGFkZGl0aW9uLCBpdCBzaG91 bGQgYmUgbm90ZWQgdGhhdA0KICAgc29tZSBwcm90b2NvbHMgbWF5IGltcG9zZSB1cHBlciBsaW1p dHMgb24gdGhlIGxlbmd0aCBvZiB0aGUgc3RyaW5ncw0KICAgdXNlZCB0byBzdG9yZSBvciB0cmFu c3BvcnQgdGhlIGxhbmd1YWdlIHRhZy4NCg0KMy43ICBDb252ZXJzaW9uIG9mIHRoZSBSRkMgMzA2 NiBMYW5ndWFnZSBUYWcgUmVnaXN0cnkNCg0KICAgVXBvbiBwdWJsaWNhdGlvbiBvZiB0aGlzIGRv Y3VtZW50IGFzIGEgQkNQLCB0aGUgZXhpc3RpbmcgSUFOQQ0KICAgbGFuZ3VhZ2UgdGFnIHJlZ2lz dHJ5IG11c3QgYmUgY29udmVydGVkIGludG8gdGhlIG5ldyBzdWJ0YWcgcmVnaXN0cnkuDQogICBU aGlzIHNlY3Rpb24gZGVmaW5lcyB0aGUgcHJvY2VzcyBmb3IgcGVyZm9ybWluZyB0aGlzIGNvbnZl cnNpb24uDQoNCiAgIFRoZSBpbXBhY3Qgb24gdGhlIElBTkEgbWFpbnRhaW5lcnMgb2YgdGhlIHJl Z2lzdHJ5IG9mIHRoaXMgY29udmVyc2lvbg0KICAgd2lsbCBiZSBhIHNtYWxsIGluY3JlYXNlIGlu IHRoZSBmcmVxdWVuY3kgb2YgbmV3IGVudHJpZXMuICBUaGUNCiAgIGluaXRpYWwgc2V0IG9mIHJl Y29yZHMgcmVwcmVzZW50cyBubyBpbXBhY3Qgb24gSUFOQSwgc2luY2UgdGhlIHdvcmsNCiAgIHRv IGNyZWF0ZSBpdCB3aWxsIGJlIHBlcmZvcm1lZCBleHRlcm5hbGx5IChhcyBkZWZpbmVkIGluIHRo aXMNCiAgIHNlY3Rpb24pLiAgRnV0dXJlIHdvcmsgd2lsbCBiZSBsaW1pdGVkIHRvIGluc2VydGlu ZyBvciByZXBsYWNpbmcNCiAgIHdob2xlIHJlY29yZHMgcHJlZm9ybWF0dGVkIGZvciBJQU5BIGJ5 IHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIuDQoNCiAgIFdoZW4gdGhpcyBkb2N1bWVudCBp cyBwdWJsaXNoZWQsIGFuIGVtYWlsIHdpbGwgYmUgc2VudCBieSB0aGUNCiAgIGNoYWlyKHMpIG9m IHRoZSBMVFJVIHdvcmtpbmcgZ3JvdXAgdG8gdGhlIExUUlUgYW5kIGlldGYtbGFuZ3VhZ2VzDQog ICBtYWlsIGxpc3RzIGFkdmlzaW5nIG9mIHRoZSBpbXBlbmRpbmcgY29udmVyc2lvbiBvZiB0aGUg cmVnaXN0cnkuICBJbg0KICAgdGhhdCBub3RpY2UsIHRoZSBjaGFpcihzKSB3aWxsIHByb3ZpZGUg YSBVUkwgd2hvc2UgcmVmZXJyZWQgY29udGVudA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgMzNdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg ICAgIEFwcmlsIDIwMDUNCg0KDQogICBpcyB0aGUgcHJvcG9zZWQgSUFOQSBMYW5ndWFnZSBTdWJ0 YWcgUmVnaXN0cnkgZm9sbG93aW5nIGNvbnZlcnNpb24uDQogICBUaGVyZSB3aWxsIGJlIGEgTGFz dCBDYWxsIHBlcmlvZCBvZiBub3QgbGVzcyB0aGFuIGZvdXIgd2Vla3MgZm9yDQogICBjb21tZW50 cyBhbmQgY29ycmVjdGlvbnMgdG8gYmUgZGlzY3Vzc2VkIG9uIHRoZQ0KICAgaWV0Zi1sYW5ndWFn ZXNAaWFuYS5vcmcgbWFpbCBsaXN0LiAgQ2hhbmdlcyBhcyBhIHJlc3VsdCBvZiBjb21tZW50cw0K ICAgd2lsbCBub3QgcmVzdGFydCB0aGUgTGFzdCBDYWxsIHBlcmlvZC4gIEF0IHRoZSBlbmQgb2Yg dGhlIHBlcmlvZCwgdGhlDQogICBjaGFpcihzKSB3aWxsIGZvcndhcmQgdGhlIFVSTCB0byBJQU5B LCB3aGljaCB3aWxsIHBvc3QgdGhlIG5ldw0KICAgcmVnaXN0cnkgb24tbGluZS4NCg0KICAgVGFn cyB0aGF0IGFyZSBjdXJyZW50bHkgZGVwcmVjYXRlZCB3aWxsIGJlIG1haW50YWluZWQgYXMNCiAg IGdyYW5kZmF0aGVyZWQgZW50cmllcy4gIFRoZSByZWNvcmQgZm9yIHRoZSBncmFuZGZhdGhlcmVk IGVudHJ5IHdpbGwNCiAgIGNvbnRhaW4gYSAnRGVwcmVjYXRlZCcgZmllbGQgd2l0aCB0aGUgbW9z dCBhcHByb3ByaWF0ZSBkYXRlIHRoYXQgY2FuDQogICBiZSBkZXRlcm1pbmVkIGZvciB3aGVuIHRo ZSByZWNvcmQgd2FzIGRlcHJlY2F0ZWQuICBUaGUgJ0NvbW1lbnRzJw0KICAgZmllbGQgd2lsbCBj b250YWluIHRoZSByZWFzb24gZm9yIHRoZSBkZXByZWNhdGlvbi4gIFRoZSAnQ2Fub25pY2FsJw0K ICAgZmllbGQgd2lsbCBjb250YWluIHRoZSB0YWcgdGhhdCByZXBsYWNlcyB0aGUgdmFsdWUuICBG b3IgZXhhbXBsZSwgdGhlDQogICB0YWcgImFydC1sb2piYW4iIGlzIGRlcHJlY2F0ZWQgYW5kIHdp bGwgYmUgcGxhY2VkIGluIHRoZQ0KICAgZ3JhbmRmYXRoZXJlZCBzZWN0aW9uLiAgSXQncyAnRGVw cmVjYXRlZCcgZmllbGQgd2lsbCBjb250YWluIHRoZQ0KICAgZGVwcmVjYXRpb24gZGF0ZSBhbmQg J0Nhbm9uaWNhbCcgZmllbGQgdGhlIHZhbHVlICJqYm8iLg0KDQogICBUYWdzIHRoYXQgYXJlIG5v dCBkZXByZWNhdGVkIHRoYXQgY29uc2lzdCBlbnRpcmVseSBvZiBzdWJ0YWdzIHRoYXQNCiAgIGFy ZSB2YWxpZCB1bmRlciB0aGlzIGRvY3VtZW50IGFuZCB3aGljaCBoYXZlIHRoZSBjb3JyZWN0IGZv cm0gYW5kDQogICBmb3JtYXQgZm9yIHRhZ3MgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50IGFyZSBz dXBlcnNlZGVkIGJ5IHRoaXMNCiAgIGRvY3VtZW50LiAgU3VjaCB0YWdzIGFyZSBwbGFjZWQgaW4g cmVjb3JkcyBvZiB0eXBlICdyZWR1bmRhbnQnIGluIHRoZQ0KICAgcmVnaXN0cnkuICBGb3IgZXhh bXBsZSwgInpoLUhhbnQiIGlzIG5vdyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQuDQoNCiAgIFRh Z3MgdGhhdCBhcmUgbm90IGRlcHJlY2F0ZWQgYW5kIHdoaWNoIGNvbnRhaW4gc3VidGFncyB3aGlj aCBhcmUNCiAgIGNvbnNpc3RlbnQgd2l0aCByZWdpc3RyYXRpb24gdW5kZXIgdGhlIGd1aWRlbGlu ZXMgaW4gdGhpcyBkb2N1bWVudA0KICAgd2lsbCBoYXZlIGEgbmV3IHN1YnRhZyByZWdpc3RyYXRp b24gY3JlYXRlZCBmb3IgZWFjaCBlbGlnaWJsZSBzdWJ0YWcuDQogICBJZiBhbGwgb2YgdGhlIHN1 YnRhZ3MgaW4gdGhlIG9yaWdpbmFsIHRhZyBhcmUgZnVsbHkgZGVmaW5lZCBieSB0aGUNCiAgIHJl c3VsdGluZyByZWdpc3RyYXRpb25zIG9yIGJ5IHRoaXMgZG9jdW1lbnQsIHRoZW4gdGhlIG9yaWdp bmFsIHRhZyBpcw0KICAgc3VwZXJzZWRlZCBieSB0aGlzIGRvY3VtZW50LiAgU3VjaCB0YWdzIGFy ZSBwbGFjZWQgaW4gdGhlICdyZWR1bmRhbnQnDQogICBzZWN0aW9uIG9mIHRoZSByZWdpc3RyeS4g IEZvciBleGFtcGxlLCAiZW4tYm9vbnQiIHdpbGwgcmVzdWx0IGluIGENCiAgIG5ldyBzdWJ0YWcg J2Jvb250JyBhbmQgdGhlIFJGQyAzMDY2IHJlZ2lzdGVyZWQgdGFnICJlbi1ib29udCIgcGxhY2Vk DQogICBpbiB0aGUgcmVkdW5kYW50IHNlY3Rpb24gb2YgdGhlIHJlZ2lzdHJ5Lg0KDQogICBUYWdz IHRoYXQgY29udGFpbiBvbmUgb3IgbW9yZSBzdWJ0YWdzIHRoYXQgZG8gbm90IG1hdGNoIHRoZSB2 YWxpZA0KICAgcmVnaXN0cmF0aW9uIHBhdHRlcm4gYW5kIHdoaWNoIGFyZSBub3Qgb3RoZXJ3aXNl IGRlZmluZWQgYnkgdGhpcw0KICAgZG9jdW1lbnQgd2lsbCBoYXZlIHJlY29yZHMgb2YgdHlwZSAg J2dyYW5kZmF0aGVyZWQnIGNyZWF0ZWQgaW4gdGhlDQogICByZWdpc3RyeS4NCg0KICAgVGhlcmUg d2lsbCBiZSBhIHJlYXNvbmFibGUgcGVyaW9kIGluIHdoaWNoIHRoZSBjb21tdW5pdHkgbWF5IGNv bW1lbnQNCiAgIG9uIHRoZSBwcm9wb3NlZCBsaXN0IGVudHJpZXMsIHdoaWNoIFNIQUxMIGJlIG5v IGxlc3MgdGhhbiBmb3VyIHdlZWtzDQogICBpbiBsZW5ndGguICBBdCB0aGUgY29tcGxldGlvbiBv ZiB0aGlzIHBlcmlvZCwgdGhlIGNoYWlyKHMpIHdpbGwNCiAgIG5vdGlmeSBpYW5hQGlhbmEub3Jn IGFuZCB0aGUgbHRydSBhbmQgaWV0Zi1sYW5ndWFnZXMgbWFpbCBsaXN0cyB0aGF0DQogICB0aGUg dGFzayBpcyBjb21wbGV0ZSBhbmQgZm9yd2FyZCB0aGUgbmVjZXNzYXJ5IG1hdGVyaWFscyB0byBJ QU5BIGZvcg0KICAgcHVibGljYXRpb24uDQoNCiAgIFJlZ2lzdHJhdGlvbnMgdGhhdCBhcmUgaW4g cHJvY2VzcyB1bmRlciB0aGUgcnVsZXMgZGVmaW5lZCBpbiBSRkMgMzA2Ng0KICAgTUFZIGJlIGNv bXBsZXRlZCB1bmRlciB0aGUgZm9ybWVyIHJ1bGVzLCBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUN Cg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwNSAg ICAgICAgICAgICAgIFtQYWdlIDM0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxh bmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgbGFuZ3Vh Z2UgdGFnIHJldmlld2VyLiAgQW55IG5ldyByZWdpc3RyYXRpb25zIHN1Ym1pdHRlZCBhZnRlciB0 aGUNCiAgIHJlcXVlc3QgZm9yIGNvbnZlcnNpb24gb2YgdGhlIHJlZ2lzdHJ5IE1VU1QgYmUgcmVq ZWN0ZWQuDQoNCiAgIEFsbCBleGlzdGluZyBSRkMgMzA2NiBsYW5ndWFnZSB0YWcgcmVnaXN0cmF0 aW9ucyB3aWxsIGJlIG1haW50YWluZWQNCiAgIGluIHBlcnBldHVpdHkuDQoNCiAgIFVzZXJzIG9m IHRhZ3MgdGhhdCBhcmUgZ3JhbmRmYXRoZXJlZCBzaG91bGQgY29uc2lkZXIgcmVnaXN0ZXJpbmcN CiAgIGFwcHJvcHJpYXRlIHN1YnRhZ3MgaW4gdGhlIElBTkEgc3VidGFnIHJlZ2lzdHJ5IChidXQg YXJlIG5vdCByZXF1aXJlZA0KICAgdG8pLg0KDQogICBXaGVyZSB0d28gc3VidGFncyBoYXZlIHRo ZSBzYW1lIG1lYW5pbmcsIHRoZSBwcmlvcml0eSBvZiB3aGljaCB0bw0KICAgbWFrZSBjYW5vbmlj YWwgU0hBTEwgYmUgdGhlIGZvbGxvd2luZzoNCg0KICAgbyAgQXMgb2YgdGhlIGRhdGUgb2YgYWNj ZXB0YW5jZSBvZiB0aGlzIGRvY3VtZW50IGFzIGEgQkNQLCBpZiBhIGNvZGUNCiAgICAgIGV4aXN0 cyBpbiB0aGUgYXNzb2NpYXRlZCBJU08gc3RhbmRhcmQgYW5kIGl0IGlzIG5vdCBkZXByZWNhdGVk IG9yDQogICAgICB3aXRoZHJhd24gYXMgb2YgdGhhdCBkYXRlLCB0aGVuIGl0IGhhcyBwcmlvcml0 eS4NCg0KICAgbyAgT3RoZXJ3aXNlLCB0aGUgZWFybGllci1yZWdpc3RlcmVkIHRhZyBpbiB0aGUg YXNzb2NpYXRlZCBJU08NCiAgICAgIHN0YW5kYXJkIGhhcyBwcmlvcml0eS4NCg0KICAgVU4gbnVt ZXJpYyBjb2RlcyBhc3NpZ25lZCB0byAnbWFjcm8tZ2VvZ3JhcGhpY2FsIChjb250aW5lbnRhbCkn IG9yDQogICBzdWItcmVnaW9ucyBub3QgYXNzb2NpYXRlZCB3aXRoIGFuIGFzc2lnbmVkIElTTyAz MTY2IGFscGhhLTIgY29kZSBhcmUNCiAgIGRlZmluZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkgYW5k IGFyZSB2YWxpZCBmb3IgdXNlIGluIGxhbmd1YWdlIHRhZ3MuDQogICBUaGVzZSBjb2RlcyBNVVNU IGJlIGFkZGVkIHRvIHRoZSBpbml0aWFsIHZlcnNpb24gb2YgdGhlIHJlZ2lzdHJ5Lg0KICAgVGhl IFVOIG51bWVyaWMgY29kZXMgZm9yICdlY29ub21pYyBncm91cGluZ3MnIG9yICdvdGhlciBncm91 cGluZ3MnLA0KICAgYW5kIHRoZSBhbHBoYW51bWVyaWMgY29kZXMgaW4gQXBwZW5kaXggWCBvZiB0 aGUgVU4gZG9jdW1lbnQgTVVTVCBOT1QNCiAgIGJlIGFkZGVkIHRvIHRoZSByZWdpc3RyeS4NCg0K ICAgV2hlbiBjcmVhdGluZyByZWNvcmRzIGZvciBJU08gNjM5LCBJU08gMTU5MjQsIElTTzMxNjYs IGFuZCBVTiBNLjQ5DQogICBjb2RlcywgdGhlIGZvbGxvd2luZyBjcml0ZXJpYSBTSEFMTCBiZSBh cHBsaWVkIHRvIHRoZSBpbmNsdXNpb24sDQogICBjYW5vbmljYWwgbWFwcGluZywgYW5kIGRlcHJl Y2F0aW9uIG9mIGNvZGVzOg0KDQogICBGb3IgZWFjaCBzdGFuZGFyZCwgdGhlIGRhdGUgb2YgdGhl IHN0YW5kYXJkIHJlZmVyZW5jZWQgaW4gUkZDIDE3NjYgaXMNCiAgIHNlbGVjdGVkIGFzIHRoZSBz dGFydGluZyBkYXRlLiAgQ29kZXMgdGhhdCB3ZXJlIHZhbGlkIG9uIHRoYXQgZGF0ZSBpbg0KICAg dGhlIHNlbGVjdGVkIHN0YW5kYXJkIGFyZSBhZGRlZCB0byB0aGUgcmVnaXN0cnkuICBDb2RlcyB0 aGF0IHdlcmUNCiAgIHByZXZpb3VzbHkgYXNzaWduZWQgYnkgd2VyZSB2YWNhdGVkIG9yIHdpdGhk cmF3biBiZWZvcmUgdGhhdCBkYXRlIGFyZQ0KICAgbm90IGFkZGVkIHRvIHRoZSByZWdpc3RyeS4g IEZvciBlYWNoIHN1Y2Nlc3NpdmUgY2hhbmdlIHRvIHRoZQ0KICAgc3RhbmRhcmQsIGFueSBhZGRp dGlvbmFsIGFzc2lnbm1lbnRzIGFyZSBhZGRlZCB0byB0aGUgcmVnaXN0cnkuDQogICBWYWx1ZXMg dGhhdCBhcmUgd2l0aGRyYXduIGFyZSBtYXJrZWQgYXMgZGVwcmVjYXRlZCwgYnV0IG5vdCByZW1v dmVkLg0KICAgQ2hhbmdlcyBpbiBtZWFuaW5nIG9yIGFzc2lnbm1lbnQgb2YgYSBzdWJ0YWcgYXJl IHBlcm1pdHRlZCBkdXJpbmcNCiAgIHRoaXMgcHJvY2VzcyAoY2YuICdDUycpLiAgVGhpcyBjb250 aW51ZXMgdXAgdG8gdGhlIGRhdGUgdGhhdCB0aGlzDQogICBkb2N1bWVudCB3YXMgYWRvcHRlZC4g IFRoZSByZXN1bHRpbmcgc2V0IG9mIHJlY29yZHMgaXMgYWRkZWQgdG8gdGhlDQogICByZWdpc3Ry eS4gIEZ1dHVyZSBjaGFuZ2VzIG9yIGFkZGl0aW9ucyB0byB0aGlzIHBvcnRpb24gb2YgdGhlDQog ICByZWdpc3RyeSBhcmUgZ292ZXJuZWQgYnkgdGhlIHByb3Zpc2lvbnMgb2YgdGhpcyBkb2N1bWVu dC4NCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVy IDIyLCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgMzVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0K DQo0LiAgRm9ybWF0aW9uIGFuZCBQcm9jZXNzaW5nIG9mIExhbmd1YWdlIFRhZ3MNCg0KICAgVGhp cyBzZWN0aW9uIGFkZHJlc3NlcyBob3cgdG8gdXNlIHRoZSByZWdpc3RyeSB3aXRoIHRoZSBsYW5n dWFnZSB0YWcNCiAgIGZvcm1hdCB0byBjaG9vc2UsIGZvcm0gYW5kIHByb2Nlc3MgbGFuZ3VhZ2Ug dGFncy4NCg0KNC4xICBDaG9pY2Ugb2YgTGFuZ3VhZ2UgVGFnDQoNCiAgIE9uZSBtYXkgb2NjYXNp b25hbGx5IGJlIGZhY2VkIHdpdGggc2V2ZXJhbCBwb3NzaWJsZSB0YWdzIGZvciB0aGUgc2FtZQ0K ICAgYm9keSBvZiB0ZXh0Lg0KDQogICBJbnRlcm9wZXJhYmlsaXR5IGlzIGJlc3Qgc2VydmVkIHdo ZW4gYWxsIHVzZXJzIHVzZSB0aGUgc2FtZSBsYW5ndWFnZQ0KICAgdGFnIGluIG9yZGVyIHRvIHJl cHJlc2VudCB0aGUgc2FtZSBsYW5ndWFnZS4gIElmIGFuIGFwcGxpY2F0aW9uIGhhcw0KICAgcmVx dWlyZW1lbnRzIHRoYXQgbWFrZSB0aGUgcnVsZXMgaGVyZSBpbmFwcGxpY2FibGUsIHRoZW4gdGhh dA0KICAgYXBwbGljYXRpb24gcmlza3MgZGFtYWdpbmcgaW50ZXJvcGVyYWJpbGl0eS4gIEl0IGlz IHN0cm9uZ2x5DQogICBSRUNPTU1FTkRFRCB0aGF0IHVzZXJzIG5vdCBkZWZpbmUgdGhlaXIgb3du IHJ1bGVzIGZvciBsYW5ndWFnZSB0YWcNCiAgIGNob2ljZS4NCg0KICAgT2YgcGFydGljdWxhciBu b3RlLCBtYW55IGFwcGxpY2F0aW9ucyBjYW4gYmVuZWZpdCBmcm9tIHRoZSB1c2Ugb2YNCiAgIHNj cmlwdCBzdWJ0YWdzIGluIGxhbmd1YWdlIHRhZ3MsIGFzIGxvbmcgYXMgdGhlIHVzZSBpcyBjb25z aXN0ZW50IGZvcg0KICAgYSBnaXZlbiBjb250ZXh0LiAgU2NyaXB0IHN1YnRhZ3Mgd2VyZSBub3Qg Zm9ybWFsbHkgZGVmaW5lZCBpbiBSRkMNCiAgIDMwNjYgYW5kIHRoZWlyIHVzZSBtYXkgYWZmZWN0 IG1hdGNoaW5nIGFuZCBzdWJ0YWcgaWRlbnRpZmljYXRpb24gYnkNCiAgIGltcGxlbWVudGF0aW9u cyBvZiBSRkMgMzA2NiwgYXMgdGhlc2Ugc3VidGFncyBhcHBlYXIgYmV0d2VlbiB0aGUNCiAgIHBy aW1hcnkgbGFuZ3VhZ2UgYW5kIHJlZ2lvbiBzdWJ0YWdzLiAgRm9yIGV4YW1wbGUsIGlmIGEgdXNl ciByZXF1ZXN0cw0KICAgY29udGVudCBpbiBhbiBpbXBsZW1lbnRhdGlvbiBvZiBTZWN0aW9uIDIu NSBvZiBSRkMgMzA2NiBbMjNdIHVzaW5nDQogICB0aGUgbGFuZ3VhZ2UgcmFuZ2UgImVuLVVTIiwg Y29udGVudCBsYWJlbGVkICJlbi1MYXRuLVVTIiB3aWxsIG5vdA0KICAgbWF0Y2ggdGhlIHJlcXVl c3QuICBUaGVyZWZvcmUgaXQgaXMgaW1wb3J0YW50IHRvIGtub3cgd2hlbiBzY3JpcHQNCiAgIHN1 YnRhZ3Mgd2lsbCBjdXN0b21hcmlseSBiZSB1c2VkIGFuZCB3aGVuIHRoZXkgc2hvdWxkIG5vdCBi ZSB1c2VkLg0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzICh0eXBlICdleHRsYW5nJyBp biB0aGUgcmVnaXN0cnksIHNlZQ0KICAgU2VjdGlvbiAzLjEpIGFsc28gYXBwZWFyIGJldHdlZW4g dGhlIHByaW1hcnkgbGFuZ3VhZ2UgYW5kIHJlZ2lvbg0KICAgc3VidGFncyBhbmQgYXJlIHJlc2Vy dmVkIGZvciBmdXR1cmUgc3RhbmRhcmRpemF0aW9uLiAgQXBwbGljYXRpb25zDQogICBtYXkgYmVu ZWZpdCBmcm9tIHRoZWlyIGp1ZGljaW91cyB1c2UgaW4gZm9ybWluZyBsYW5ndWFnZSB0YWdzIGlu IHRoZQ0KICAgZnV0dXJlIGFuZCBzaW1pbGFyIHJlY29tbWVuZGF0aW9ucyBhcmUgZXhwZWN0ZWQg dG8gYXBwbHkgdG8gdGhlaXIgdXNlDQogICBhcyBhcHBseSB0byBzY3JpcHQgc3VidGFncy4NCg0K ICAgU3RhbmRhcmRzLCBwcm90b2NvbHMgYW5kIGFwcGxpY2F0aW9ucyB0aGF0IHJlZmVyZW5jZSB0 aGlzIGRvY3VtZW50DQogICBub3JtYXRpdmVseSBidXQgYXBwbHkgZGlmZmVyZW50IHJ1bGVzIHRv IHRoZSBvbmVzIGdpdmVuIGluIHRoaXMNCiAgIHNlY3Rpb24gTVVTVCBzcGVjaWZ5IGhvdyB0aGUg cHJvY2VkdXJlIHZhcmllcyBmcm9tIHRoZSBvbmUgZ2l2ZW4NCiAgIGhlcmUuDQoNCiAgIFRoZSBj aG9pY2Ugb2Ygc3VidGFncyB1c2VkIHRvIGZvcm0gYSBsYW5ndWFnZSB0YWcgc2hvdWxkIGJlIGd1 aWRlZCBieQ0KICAgdGhlIGZvbGxvd2luZyBydWxlczoNCg0KICAgMS4gIFVzZSBhcyBwcmVjaXNl IGEgdGFnIGFzIHBvc3NpYmxlLCBidXQgbm8gbW9yZSBzcGVjaWZpYyB0aGFuIGlzDQogICAgICAg anVzdGlmaWVkLiAgQXZvaWQgdXNpbmcgc3VidGFncyB0aGF0IGFyZSBub3QgaW1wb3J0YW50IGZv cg0KICAgICAgIGRpc3Rpbmd1aXNoaW5nIGNvbnRlbnQgaW4gYW4gYXBwbGljYXRpb24uDQoNCg0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1ICAg ICAgICAgICAgICAgW1BhZ2UgMzZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFu Z3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICAgICAgKiAg Rm9yIGV4YW1wbGUsICdkZScgbWlnaHQgc3VmZmljZSBmb3IgdGFnZ2luZyBhbiBlbWFpbCB3cml0 dGVuDQogICAgICAgICAgaW4gR2VybWFuLCB3aGlsZSAiZGUtQ0gtMTk5NiIgaXMgcHJvYmFibHkg dW5uZWNlc3NhcmlseQ0KICAgICAgICAgIHByZWNpc2UgZm9yIHN1Y2ggYSB0YXNrLg0KDQogICAy LiAgVGhlIHNjcmlwdCBzdWJ0YWcgU0hPVUxEIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2Ug dGFncyB1bmxlc3MNCiAgICAgICB0aGUgc2NyaXB0IGFkZHMgc29tZSBkaXN0aW5ndWlzaGluZyBp bmZvcm1hdGlvbiB0byB0aGUgdGFnLiAgVGhlDQogICAgICAgZmllbGQgJ1N1cHByZXNzLVNjcmlw dCcgaW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2UgcmVjb3JkIGluIHRoZQ0KICAgICAgIHJlZ2lzdHJ5 IGluZGljYXRlcyB3aGljaCBzY3JpcHQgc3VidGFncyBkbyBub3QgYWRkIGRpc3Rpbmd1aXNoaW5n DQogICAgICAgaW5mb3JtYXRpb24gZm9yIG1vc3QgYXBwbGljYXRpb25zLg0KDQogICAgICAgKiAg Rm9yIGV4YW1wbGUsIHRoZSBzdWJ0YWcgJ0xhdG4nIHNob3VsZCBub3QgYmUgdXNlZCB3aXRoIHRo ZQ0KICAgICAgICAgIHByaW1hcnkgbGFuZ3VhZ2UgJ2VuJyBiZWNhdXNlIG5lYXJseSBhbGwgRW5n bGlzaCBkb2N1bWVudHMgYXJlDQogICAgICAgICAgd3JpdHRlbiBpbiB0aGUgTGF0aW4gc2NyaXB0 IGFuZCBpdCBhZGRzIG5vIGRpc3Rpbmd1aXNoaW5nDQogICAgICAgICAgaW5mb3JtYXRpb24uICBI b3dldmVyLCBpZiBhIGRvY3VtZW50IHdlcmUgd3JpdHRlbiBpbiBFbmdsaXNoDQogICAgICAgICAg bWl4aW5nIExhdGluIHNjcmlwdCB3aXRoIGFub3RoZXIgc2NyaXB0IHN1Y2ggYXMgQnJhaWxsZQ0K ICAgICAgICAgICgnQnJhaScpLCB0aGVuIGl0IG1heSBiZSBhcHByb3ByaWF0ZSB0byBjaG9vc2Ug dG8gaW5kaWNhdGUNCiAgICAgICAgICBib3RoIHNjcmlwdHMgdG8gYWlkIGluIGNvbnRlbnQgc2Vs ZWN0aW9uLCBzdWNoIGFzIHRoZQ0KICAgICAgICAgIGFwcGxpY2F0aW9uIG9mIGEgc3R5bGVzaGVl dC4NCg0KICAgMy4gIElmIGEgc3VidGFnIGhhcyBhICdDYW5vbmljYWwnIGZpZWxkIGluIGl0cyBy ZWdpc3RyeSBlbnRyeSwgdGhlDQogICAgICAgY2Fub25pY2FsIHN1YnRhZyBTSE9VTEQgYmUgdXNl ZCB0byBmb3JtIHRoZSBsYW5ndWFnZSB0YWcgaW4NCiAgICAgICBwcmVmZXJlbmNlIHRvIGFueSBv ZiBpdHMgYWxpYXNlcy4NCg0KICAgICAgICogIEZvciBleGFtcGxlLCB1c2UgJ2hlJyBmb3IgSGVi cmV3IGluIHByZWZlcmVuY2UgdG8gJ2l3Jy4NCg0KICAgNC4gIFRoZSAndW5kJyAoVW5kZXRlcm1p bmVkKSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBTSE9VTEQgTk9UIGJlDQogICAgICAgdXNlZCB0 byBsYWJlbCBjb250ZW50LCBldmVuIGlmIHRoZSBsYW5ndWFnZSBpcyB1bmtub3duLiAgT21pdHRp bmcNCiAgICAgICB0aGUgdGFnIGlzIHByZWZlcnJlZC4gIFRoZSAndW5kJyB0YWcgbWF5IGJlIHVz ZWZ1bCBmb3IgcHJvdG9jb2xzDQogICAgICAgdGhhdCByZXF1aXJlIGEgbGFuZ3VhZ2UgdGFnIHRv IGJlIHByb3ZpZGVkLiAgVGhlICd1bmQnIHN1YnRhZyBtYXkNCiAgICAgICBhbHNvIGJlIHVzZWZ1 bCB3aGVuIG1hdGNoaW5nIGxhbmd1YWdlIHRhZ3MgaW4gY2VydGFpbiBzaXR1YXRpb25zLg0KDQog ICA1LiAgVGhlICdtdWwnIChNdWx0aXBsZSkgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgU0hPVUxE IE5PVCBiZSB1c2VkDQogICAgICAgd2hlbmV2ZXIgdGhlIHByb3RvY29sIGFsbG93cyB0aGUgc2Vw YXJhdGUgdGFncyBmb3IgbXVsdGlwbGUNCiAgICAgICBsYW5ndWFnZXMsIGFzIGlzIHRoZSBjYXNl IGZvciB0aGUgQ29udGVudC1MYW5ndWFnZSBoZWFkZXIgaW4NCiAgICAgICBIVFRQLiAgVGhlICdt dWwnIHN1YnRhZyBjb252ZXlzIGxpdHRsZSB1c2VmdWwgaW5mb3JtYXRpb246DQogICAgICAgY29u dGVudCBpbiBtdWx0aXBsZSBsYW5ndWFnZXMgc2hvdWxkIGluZGl2aWR1YWxseSB0YWcgdGhlDQog ICAgICAgbGFuZ3VhZ2VzIHdoZXJlIHRoZXkgYXBwZWFyIG9yIG90aGVyd2lzZSBpbmRpY2F0ZSB0 aGUgYWN0dWFsDQogICAgICAgbGFuZ3VhZ2UgaW4gcHJlZmVyZW5jZSB0byB0aGUgJ211bCcgc3Vi dGFnLg0KDQogICA2LiAgVGhlIHNhbWUgdmFyaWFudCBzdWJ0YWcgU0hPVUxEIE5PVCBiZSB1c2Vk IG1vcmUgdGhhbiBvbmNlIHdpdGhpbg0KICAgICAgIGEgbGFuZ3VhZ2UgdGFnLg0KDQogICAgICAg KiAgRm9yIGV4YW1wbGUsIGRvIG5vdCB1c2UgImVuLUdCLXNjb3VzZS1zY291c2UiLg0KDQogICBU byBlbnN1cmUgY29uc2lzdGVudCBiYWNrd2FyZCBjb21wYXRpYmlsaXR5LCB0aGlzIGRvY3VtZW50 IGNvbnRhaW5zDQogICBzZXZlcmFsIHByb3Zpc2lvbnMgdG8gYWNjb3VudCBmb3IgcG90ZW50aWFs IGluc3RhYmlsaXR5IGluIHRoZQ0KICAgc3RhbmRhcmRzIHVzZWQgdG8gZGVmaW5lIHRoZSBzdWJ0 YWdzIHRoYXQgbWFrZSB1cCBsYW5ndWFnZSB0YWdzLg0KICAgVGhlc2UgcHJvdmlzaW9ucyBtZWFu IHRoYXQgbm8gbGFuZ3VhZ2UgdGFnIGNyZWF0ZWQgdW5kZXIgdGhlIHJ1bGVzIGluDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAg ICAgICBbUGFnZSAzN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIHRoaXMgZG9jdW1lbnQg d2lsbCBiZWNvbWUgb2Jzb2xldGUuICBJbiBhZGRpdGlvbiwgdGFncyB0aGF0IGFyZSBpbg0KICAg Y2Fub25pY2FsIGZvcm0gd2lsbCBhbHdheXMgYmUgaW4gY2Fub25pY2FsIGZvcm0uDQoNCjQuMiAg TWVhbmluZyBvZiB0aGUgTGFuZ3VhZ2UgVGFnDQoNCiAgIFRoZSBsYW5ndWFnZSB0YWcgYWx3YXlz IGRlZmluZXMgYSBsYW5ndWFnZSBhcyBzcG9rZW4gKG9yIHdyaXR0ZW4sDQogICBzaWduZWQgb3Ig b3RoZXJ3aXNlIHNpZ25hbGVkKSBieSBodW1hbiBiZWluZ3MgZm9yIGNvbW11bmljYXRpb24gb2YN CiAgIGluZm9ybWF0aW9uIHRvIG90aGVyIGh1bWFuIGJlaW5ncy4gIENvbXB1dGVyIGxhbmd1YWdl cyBzdWNoIGFzDQogICBwcm9ncmFtbWluZyBsYW5ndWFnZXMgYXJlIGV4cGxpY2l0bHkgZXhjbHVk ZWQuDQoNCiAgIElmIGEgbGFuZ3VhZ2UgdGFnIEIgY29udGFpbnMgbGFuZ3VhZ2UgdGFnIEEgYXMg YSBwcmVmaXgsIHRoZW4gQiBpcw0KICAgdHlwaWNhbGx5ICJuYXJyb3dlciIgb3IgIm1vcmUgc3Bl Y2lmaWMiIHRoYW4gQS4gRm9yIGV4YW1wbGUsICJ6aC0NCiAgIEhhbnQtVFciIGlzIG1vcmUgc3Bl Y2lmaWMgdGhhbiAiemgtSGFudCIuDQoNCiAgIFRoaXMgcmVsYXRpb25zaGlwIGlzIG5vdCBndWFy YW50ZWVkIGluIGFsbCBjYXNlczogc3BlY2lmaWNhbGx5LA0KICAgbGFuZ3VhZ2VzIHRoYXQgYmVn aW4gd2l0aCB0aGUgc2FtZSBzZXF1ZW5jZSBvZiBzdWJ0YWdzIGFyZSBOT1QNCiAgIGd1YXJhbnRl ZWQgdG8gYmUgbXV0dWFsbHkgaW50ZWxsaWdpYmxlLCBhbHRob3VnaCB0aGV5IG1heSBiZS4gIEZv cg0KICAgZXhhbXBsZSwgdGhlIHRhZyAiYXoiIHNoYXJlcyBhIHByZWZpeCB3aXRoIGJvdGggImF6 LUxhdG4iDQogICAoQXplcmJhaWphbmkgd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0KSBh bmQgImF6LUN5cmwiDQogICAoQXplcmJhaWphbmkgd3JpdHRlbiB1c2luZyB0aGUgQ3lyaWxsaWMg c2NyaXB0KS4gIEEgcGVyc29uIGZsdWVudCBpbg0KICAgb25lIHNjcmlwdCBtYXkgbm90IGJlIGFi bGUgdG8gcmVhZCB0aGUgb3RoZXIsIGV2ZW4gdGhvdWdoIHRoZSB0ZXh0DQogICBtaWdodCBiZSBp ZGVudGljYWwuICBDb250ZW50IHRhZ2dlZCBhcyAiYXoiIG1vc3QgcHJvYmFibHkgaXMgd3JpdHRl bg0KICAgaW4ganVzdCBvbmUgc2NyaXB0IGFuZCB0aHVzIG1pZ2h0IG5vdCBiZSBpbnRlbGxpZ2li bGUgdG8gYSByZWFkZXINCiAgIGZhbWlsaWFyIHdpdGggdGhlIG90aGVyIHNjcmlwdC4NCg0KICAg VGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSB0YWcgYW5kIHRoZSBpbmZvcm1hdGlvbiBpdCBy ZWxhdGVzIHRvIGlzDQogICBkZWZpbmVkIGJ5IHRoZSBzdGFuZGFyZCBkZXNjcmliaW5nIHRoZSBj b250ZXh0IGluIHdoaWNoIGl0IGFwcGVhcnMuDQogICBBY2NvcmRpbmdseSwgdGhpcyBzZWN0aW9u IGNhbiBvbmx5IGdpdmUgcG9zc2libGUgZXhhbXBsZXMgb2YgaXRzDQogICB1c2FnZS4NCg0KICAg byAgRm9yIGEgc2luZ2xlIGluZm9ybWF0aW9uIG9iamVjdCwgdGhlIGFzc29jaWF0ZWQgbGFuZ3Vh Z2UgdGFncw0KICAgICAgbWlnaHQgYmUgaW50ZXJwcmV0ZWQgYXMgdGhlIHNldCBvZiBsYW5ndWFn ZXMgdGhhdCBpcyByZXF1aXJlZCBmb3INCiAgICAgIGEgY29tcGxldGUgY29tcHJlaGVuc2lvbiBv ZiB0aGUgY29tcGxldGUgb2JqZWN0LiAgRXhhbXBsZTogUGxhaW4NCiAgICAgIHRleHQgZG9jdW1l bnRzLg0KDQogICBvICBGb3IgYW4gYWdncmVnYXRpb24gb2YgaW5mb3JtYXRpb24gb2JqZWN0cywg dGhlIGFzc29jaWF0ZWQgbGFuZ3VhZ2UNCiAgICAgIHRhZ3MgY291bGQgYmUgdGFrZW4gYXMgdGhl IHNldCBvZiBsYW5ndWFnZXMgdXNlZCBpbnNpZGUgY29tcG9uZW50cw0KICAgICAgb2YgdGhhdCBh Z2dyZWdhdGlvbi4gIEV4YW1wbGVzOiBEb2N1bWVudCBzdG9yZXMgYW5kIGxpYnJhcmllcy4NCg0K ICAgbyAgRm9yIGluZm9ybWF0aW9uIG9iamVjdHMgd2hvc2UgcHVycG9zZSBpcyB0byBwcm92aWRl IGFsdGVybmF0aXZlcywNCiAgICAgIHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdlIHRhZ3MgY291bGQg YmUgcmVnYXJkZWQgYXMgYSBoaW50IHRoYXQgdGhlDQogICAgICBjb250ZW50IGlzIHByb3ZpZGVk IGluIHNldmVyYWwgbGFuZ3VhZ2VzLCBhbmQgdGhhdCBvbmUgaGFzIHRvDQogICAgICBpbnNwZWN0 IGVhY2ggb2YgdGhlIGFsdGVybmF0aXZlcyBpbiBvcmRlciB0byBmaW5kIGl0cyBsYW5ndWFnZSBv cg0KICAgICAgbGFuZ3VhZ2VzLiAgSW4gdGhpcyBjYXNlLCB0aGUgcHJlc2VuY2Ugb2YgbXVsdGlw bGUgdGFncyBtaWdodCBub3QNCiAgICAgIG1lYW4gdGhhdCBvbmUgbmVlZHMgdG8gYmUgbXVsdGkt bGluZ3VhbCB0byBnZXQgY29tcGxldGUNCiAgICAgIHVuZGVyc3RhbmRpbmcgb2YgdGhlIGRvY3Vt ZW50LiAgRXhhbXBsZTogTUlNRSBtdWx0aXBhcnQvDQogICAgICBhbHRlcm5hdGl2ZS4NCg0KDQoN Cg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1ICAgICAg ICAgICAgICAgW1BhZ2UgMzhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICBvICBJbiBtYXJr dXAgbGFuZ3VhZ2VzLCBzdWNoIGFzIEhUTUwgYW5kIFhNTCwgbGFuZ3VhZ2UgaW5mb3JtYXRpb24N CiAgICAgIGNhbiBiZSBhZGRlZCB0byBlYWNoIHBhcnQgb2YgdGhlIGRvY3VtZW50IGlkZW50aWZp ZWQgYnkgdGhlIG1hcmt1cA0KICAgICAgc3RydWN0dXJlIChpbmNsdWRpbmcgdGhlIHdob2xlIGRv Y3VtZW50IGl0c2VsZikuICBGb3IgZXhhbXBsZSwgb25lDQogICAgICBjb3VsZCB3cml0ZSA8c3Bh biBsYW5nPSJmciI+Qydlc3QgbGEgdmllLjwvc3Bhbj4gaW5zaWRlIGENCiAgICAgIE5vcndlZ2lh biBkb2N1bWVudDsgdGhlIE5vcndlZ2lhbi1zcGVha2luZyB1c2VyIGNvdWxkIHRoZW4gYWNjZXNz DQogICAgICBhIEZyZW5jaC1Ob3J3ZWdpYW4gZGljdGlvbmFyeSB0byBmaW5kIG91dCB3aGF0IHRo ZSBtYXJrZWQgc2VjdGlvbg0KICAgICAgbWVhbnQuICBJZiB0aGUgdXNlciB3ZXJlIGxpc3Rlbmlu ZyB0byB0aGF0IGRvY3VtZW50IHRocm91Z2ggYQ0KICAgICAgc3BlZWNoIHN5bnRoZXNpcyBpbnRl cmZhY2UsIHRoaXMgZm9ybWF0aW9uIGNvdWxkIGJlIHVzZWQgdG8gc2lnbmFsDQogICAgICB0aGUg c3ludGhlc2l6ZXIgdG8gYXBwcm9wcmlhdGVseSBhcHBseSBGcmVuY2ggdGV4dC10by1zcGVlY2gN CiAgICAgIHByb251bmNpYXRpb24gcnVsZXMgdG8gdGhhdCBzcGFuIG9mIHRleHQsIGluc3RlYWQg b2YgYXBwbHlpbmcgdGhlDQogICAgICBpbmFwcHJvcHJpYXRlIE5vcndlZ2lhbiBydWxlcy4NCg0K DQo0LjMgIENhbm9uaWNhbGl6YXRpb24gb2YgTGFuZ3VhZ2UgVGFncw0KDQogICBTaW5jZSBhIHBh cnRpY3VsYXIgbGFuZ3VhZ2UgdGFnIG1heSBiZSB1c2VkIGluIG1hbnkgcHJvY2Vzc2VzLA0KICAg bGFuZ3VhZ2UgdGFncyBTSE9VTEQgYWx3YXlzIGJlIGNyZWF0ZWQgb3IgZ2VuZXJhdGVkIGluIGEg Y2Fub25pY2FsDQogICBmb3JtLg0KDQogICBBIGxhbmd1YWdlIHRhZyBpcyBpbiBjYW5vbmljYWwg Zm9ybSB3aGVuOg0KDQogICAxLiAgVGhlIHRhZyBpcyB3ZWxsLWZvcm1lZCBhY2NvcmRpbmcgdGhl IHJ1bGVzIGluIFNlY3Rpb24gMi4xIGFuZA0KICAgICAgIFNlY3Rpb24gMi4yLg0KDQogICAyLiAg Tm9uZSBvZiB0aGUgc3VidGFncyBpbiB0aGUgbGFuZ3VhZ2UgdGFnIGhhcyBhIGNhbm9uaWNhbF92 YWx1ZQ0KICAgICAgIG1hcHBpbmcgaW4gdGhlIElBTkEgcmVnaXN0cnkgKHNlZSBTZWN0aW9uIDMu MSkuICBTdWJ0YWdzIHdpdGggYQ0KICAgICAgIGNhbm9uaWNhbF92YWx1ZSBtYXBwaW5nIE1VU1Qg YmUgcmVwbGFjZWQgd2l0aCB0aGVpciBtYXBwaW5nIGluDQogICAgICAgb3JkZXIgdG8gY2Fub25p Y2FsaXplIHRoZSB0YWcuDQoNCiAgIDMuICBJZiBtb3JlIHRoYW4gb25lIGV4dGVuc2lvbiBzdWJ0 YWcgc2VxdWVuY2UgZXhpc3RzLCB0aGUgZXh0ZW5zaW9uDQogICAgICAgc2VxdWVuY2VzIGFyZSBv cmRlcmVkIGludG8gY2FzZS1pbnNlbnNpdGl2ZSBBU0NJSSBvcmRlciBieQ0KICAgICAgIHNpbmds ZXRvbiBzdWJ0YWcuDQoNCiAgIEV4YW1wbGU6IFRoZSBsYW5ndWFnZSB0YWcgImVuLUEtYWFhLUIt Y2NjLWJiYi14LXh5eiIgaXMgaW4gY2Fub25pY2FsDQogICBmb3JtLCB3aGlsZSAiZW4tQi1jY2Mt YmJiLUEtYWFhLVgteHl6IiBpcyB3ZWxsLWZvcm1lZCBidXQgbm90IGluDQogICBjYW5vbmljYWwg Zm9ybS4NCg0KICAgRXhhbXBsZTogVGhlIGxhbmd1YWdlIHRhZyAiZW4tTkgiIChFbmdsaXNoIGFz IHVzZWQgaW4gdGhlIE5ldw0KICAgSGVicmlkZXMpIGlzIG5vdCBjYW5vbmljYWwgYmVjYXVzZSB0 aGUgJ05IJyBzdWJ0YWcgaGFzIGEgY2Fub25pY2FsDQogICBtYXBwaW5nIHRvICdWVScgKFZhbnVh dHUpLg0KDQogICBOb3RlOiBDYW5vbmljYWxpemF0aW9uIG9mIGxhbmd1YWdlIHRhZ3MgZG9lcyBu b3QgaW1wbHkgYW55dGhpbmcgYWJvdXQNCiAgIHRoZSB1c2Ugb2YgdXBwZXIgb3IgbG93ZXJjYXNl IGxldHRlciBpbiBzdWJ0YWdzIGFzIGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAyLjEuICBBbGwg Y29tcGFyaXNvbnMgTVVTVCBiZSBwZXJmb3JtZWQgaW4gYSBjYXNlLWluc2Vuc2l0aXZlDQogICBt YW5uZXIuDQoNCiAgIE5vdGU6IGlmIHRoZSBmaWVsZCAnRGVwcmVjYXRlZCcgYXBwZWFycyBpbiBh IHJlZ2lzdHJ5IHJlY29yZCB3aXRob3V0DQogICBhbiBhY2NvbXBhbnlpbmcgJ0Nhbm9uaWNhbCcg ZmllbGQsIHRoZW4gdGhhdCB0YWcgb3Igc3VidGFnIGlzDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAzOV0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIGRlcHJlY2F0ZWQgd2l0aG91dCBhIHJlcGxhY2Vt ZW50LiAgVmFsaWRhdGluZyBwcm9jZXNzb3JzIFNIT1VMRCBOT1QNCiAgIGdlbmVyYXRlIHRhZ3Mg dGhhdCBpbmNsdWRlIHRoZXNlIHZhbHVlcywgYWx0aG91Z2ggdGhlIHZhbHVlcyBhcmUNCiAgIGNh bm9uaWNhbCB3aGVuIHRoZXkgYXBwZWFyIGluIGEgbGFuZ3VhZ2UgdGFnLg0KDQogICBBbiBleHRl bnNpb24gTVVTVCBkZWZpbmUgYW55IHJlbGF0aW9uc2hpcHMgdGhhdCBtYXkgZXhpc3QgYmV0d2Vl biB0aGUNCiAgIHZhcmlvdXMgc3VidGFncyBpbiB0aGUgZXh0ZW5zaW9uIGFuZCB0aHVzIE1BWSBk ZWZpbmUgYW4gYWx0ZXJuYXRlDQogICBjYW5vbmljYWxpemF0aW9uIHNjaGVtZSBmb3IgdGhlIGV4 dGVuc2lvbidzIHN1YnRhZ3MuICBFeHRlbnNpb25zIE1BWQ0KICAgZGVmaW5lIGhvdyB0aGUgb3Jk ZXIgb2YgdGhlIGV4dGVuc2lvbidzIHN1YnRhZ3MgYXJlIGludGVycHJldGVkLiAgRm9yDQogICBl eGFtcGxlLCBhbiBleHRlbnNpb24gY291bGQgZGVmaW5lIHRoYXQgaXRzIHN1YnRhZ3MgYXJlIGlu IGNhbm9uaWNhbA0KICAgb3JkZXIgd2hlbiB0aGUgc3VidGFncyBhcmUgcGxhY2VkIGludG8gQVND SUkgb3JkZXI6IHRoYXQgaXMsICJlbi1hLQ0KICAgYWFhLWJiYi1jY2MiIGluc3RlYWQgb2YgImVu LWEtY2NjLWJiYi1hYWEiLiAgQW5vdGhlciBleHRlbnNpb24gbWlnaHQNCiAgIGRlZmluZSB0aGF0 IHRoZSBvcmRlciBvZiB0aGUgc3VidGFncyBpbmZsdWVuY2VzIHRoZWlyIHNlbWFudGljDQogICBt ZWFuaW5nIChzbyB0aGF0ICJlbi1iLWNjYy1iYmItYWFhIiBoYXMgYSBkaWZmZXJlbnQgdmFsdWUg ZnJvbSAiZW4tYi0NCiAgIGFhYS1iYmItY2NjIikuICBIb3dldmVyLCBleHRlbnNpb24gc3BlY2lm aWNhdGlvbnMgU0hPVUxEIGJlIGRlc2lnbmVkDQogICBzbyB0aGF0IHRoZXkgYXJlIHRvbGVyYW50 IG9mIHRoZSB0eXBpY2FsIHByb2Nlc3NlcyBkZXNjcmliZWQgaW4NCiAgIFNlY3Rpb24gMy42Lg0K DQo0LjQgIENvbnNpZGVyYXRpb25zIGZvciBQcml2YXRlIFVzZSBTdWJ0YWdzDQoNCiAgIFByaXZh dGUtdXNlIHN1YnRhZ3MgcmVxdWlyZSBwcml2YXRlIGFncmVlbWVudCBiZXR3ZWVuIHRoZSBwYXJ0 aWVzDQogICB0aGF0IGludGVuZCB0byB1c2Ugb3IgZXhjaGFuZ2UgbGFuZ3VhZ2UgdGFncyB0aGF0 IHVzZSB0aGVtIGFuZCBncmVhdA0KICAgY2F1dGlvbiBzaG91bGQgYmUgdXNlZCBpbiBlbXBsb3lp bmcgdGhlbSBpbiBjb250ZW50IG9yIHByb3RvY29scw0KICAgaW50ZW5kZWQgZm9yIGdlbmVyYWwg dXNlLiAgUHJpdmF0ZS11c2Ugc3VidGFncyBhcmUgc2ltcGx5IHVzZWxlc3MgZm9yDQogICBpbmZv cm1hdGlvbiBleGNoYW5nZSB3aXRob3V0IHByaW9yIGFycmFuZ2VtZW50Lg0KDQogICBUaGUgdmFs dWUgYW5kIHNlbWFudGljIG1lYW5pbmcgb2YgcHJpdmF0ZS11c2UgdGFncyBhbmQgb2YgdGhlIHN1 YnRhZ3MNCiAgIHVzZWQgd2l0aGluIHN1Y2ggYSBsYW5ndWFnZSB0YWcgYXJlIG5vdCBkZWZpbmVk IGJ5IHRoaXMgZG9jdW1lbnQuDQoNCiAgIFRoZSB1c2Ugb2Ygc3VidGFncyBkZWZpbmVkIGluIHRo ZSBJQU5BIHJlZ2lzdHJ5IGFzIGhhdmluZyBhIHNwZWNpZmljDQogICBwcml2YXRlIHVzZSBtZWFu aW5nIGNvbnZleSBtb3JlIGluZm9ybWF0aW9uIHRoYXQgYSBwdXJlbHkgcHJpdmF0ZSB1c2UNCiAg IHRhZyBwcmVmaXhlZCBieSB0aGUgc2luZ2xldG9uIHN1YnRhZyAneCcuICBGb3IgYXBwbGljYXRp b25zIHRoaXMNCiAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gbWF5IGJlIHVzZWZ1bC4NCg0KICAg Rm9yIGV4YW1wbGUsIHRoZSByZWdpb24gc3VidGFncyAnQUEnLCAnWlonIGFuZCBpbiB0aGUgcmFu Z2VzDQogICAnUU0nLSdRWicgYW5kICdYQSctJ1haJyAoZGVyaXZlZCBmcm9tIElTTyAzMTY2IHBy aXZhdGUgdXNlIGNvZGVzKSBtYXkNCiAgIGJlIHVzZWQgdG8gZm9ybSBhIGxhbmd1YWdlIHRhZy4g IEEgdGFnIHN1Y2ggYXMgInpoLUhhbnMtWFEiIGNvbnZleXMgYQ0KICAgZ3JlYXQgZGVhbCBvZiBw dWJsaWMsIGludGVyY2hhbmdlYWJsZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbGFuZ3VhZ2UNCiAg IG1hdGVyaWFsICh0aGF0IGl0IGlzIENoaW5lc2UgaW4gdGhlIHNpbXBsaWZpZWQgQ2hpbmVzZSBz Y3JpcHQgYW5kIGlzDQogICBzdWl0YWJsZSBmb3Igc29tZSBnZW9ncmFwaGljIHJlZ2lvbiAnWFEn KS4gIFdoaWxlIHRoZSBwcmVjaXNlDQogICBnZW9ncmFwaGljIHJlZ2lvbiBpcyBub3Qga25vd24g b3V0c2lkZSBvZiBwcml2YXRlIGFncmVlbWVudCwgdGhlIHRhZw0KICAgY29udmV5cyBmYXIgbW9y ZSBpbmZvcm1hdGlvbiB0aGFuIGFuIG9wYXF1ZSB0YWcgc3VjaCBhcyAieC1zb21lTGFuZyIsDQog ICB3aGljaCBjb250YWlucyBubyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbGFuZ3VhZ2Ugc3VidGFn IG9yIHNjcmlwdA0KICAgc3VidGFnIG91dHNpZGUgb2YgdGhlIHByaXZhdGUgYWdyZWVtZW50Lg0K DQogICBIb3dldmVyLCBpbiBzb21lIGNhc2VzIGNvbnRlbnQgdGFnZ2VkIHdpdGggcHJpdmF0ZSB1 c2Ugc3VidGFncyBtYXkNCiAgIGludGVyYWN0IHdpdGggb3RoZXIgc3lzdGVtcyBpbiBhIGRpZmZl cmVudCBhbmQgcG9zc2libHkgdW5zdWl0YWJsZQ0KICAgbWFubmVyIGNvbXBhcmVkIHRvIHRhZ3Mg dGhhdCB1c2Ugb3BhcXVlLCBwcml2YXRlbHkgZGVmaW5lZCBzdWJ0YWdzLA0KICAgc28gdGhlIGNo b2ljZSBvZiB0aGUgYmVzdCBhcHByb2FjaCBtYXkgZGVwZW5kIG9uIHRoZSBwYXJ0aWN1bGFyDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAg ICAgICAgICAgICBbUGFnZSA0MF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIGRvbWFpbiBp biBxdWVzdGlvbi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAg ICAgICBbUGFnZSA0MV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCjUuICBJQU5BIENvbnNpZGVy YXRpb25zDQoNCiAgIFRoaXMgc2VjdGlvbiBkZWFscyB3aXRoIHRoZSBwcm9jZXNzZXMgYW5kIHJl cXVpcmVtZW50cyBuZWNlc3NhcnkgZm9yDQogICBJQU5BIHRvIHVuZGVydGFrZSB0byBtYWludGFp biB0aGUgcnN1YnRhZyBhbmQgZXh0ZW5zaW9uIHJlZ2lzdHJpZXMgYXMNCiAgIGRlZmluZWQgYnkg dGhpcyBkb2N1bWVudCBhbmQgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSByZXF1aXJlbWVudHMgb2YN CiAgIFJGQyAyNDM0IFsxMl0uDQoNCiAgIFRoZSBpbXBhY3Qgb24gdGhlIElBTkEgbWFpbnRhaW5l cnMgb2YgdGhlIHR3byByZWdpc3RyaWVzIGRlZmluZWQgYnkNCiAgIHRoaXMgZG9jdW1lbnQgd2ls bCBiZSBhIHNtYWxsIGluY3JlYXNlIGluIHRoZSBmcmVxdWVuY3kgb2YgbmV3DQogICBlbnRyaWVz IG9yIHVwZGF0ZXMuDQoNCiAgIFVwb24gYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCwgdGhlIHBy b2Nlc3MgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy43DQogICB3aWxsIGJlIHVzZWQgdG8gZ2VuZXJh dGUgdGhlIGluaXRpYWwgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5LiAgVGhlDQogICBpbml0aWFs IHNldCBvZiByZWNvcmRzIHJlcHJlc2VudHMgbm8gaW1wYWN0IG9uIElBTkEsIHNpbmNlIHRoZSB3 b3JrDQogICB0byBjcmVhdGUgaXQgd2lsbCBiZSBwZXJmb3JtZWQgZXh0ZXJuYWxseSAoYXMgZGVm aW5lZCBpbiB0aGF0DQogICBzZWN0aW9uKS4gIFRoZSBuZXcgcmVnaXN0cnkgd2lsbCBiZSBsaXN0 ZWQgdW5kZXIgIkxhbmd1YWdlIFRhZ3MiIGF0DQogICA8aHR0cDovL3d3dy5pYW5hLm9yZy9udW1i ZXJzLmh0bWw+LiAgVGhlIGV4aXN0aW5nIGRpcmVjdG9yeSBvZg0KICAgcmVnaXN0cmF0aW9uIGZv cm1zIGFuZCBSRkMgMzA2NiByZWdpc3RyYXRpb25zIHdpbGwgYmUgcmVsYWJlbGVkIGFzDQogICAi TGFuZ3VhZ2UgVGFncyAoT2Jzb2xldGUpIiBhbmQgbWFpbnRhaW5lZCAoYnV0IG5vdCBhZGRlZCB0 byBvcg0KICAgbW9kaWZpZWQpLg0KDQogICBGdXR1cmUgd29yayBvbiB0aGUgTGFuZ3VhZ2UgU3Vi dGFnIFJlZ2lzdHJ5IHdpbGwgYmUgbGltaXRlZCB0bw0KICAgaW5zZXJ0aW5nIG9yIHJlcGxhY2lu ZyB3aG9sZSByZWNvcmRzIHByZWZvcm1hdHRlZCBmb3IgSUFOQSBieSB0aGUNCiAgIExhbmd1YWdl IFN1YnRhZyBSZXZpZXdlciBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIgb2YgdGhpcw0KICAg ZG9jdW1lbnQuICBFYWNoIHJlY29yZCB3aWxsIGJlIHNlbnQgdG8gaWFuYUBpYW5hLm9yZyB3aXRo IGEgc3ViamVjdA0KICAgbGluZSBpbmRpY2F0aW5nIHdoZXRoZXIgdGhlIGVuY2xvc2VkIHJlY29y ZCBpcyBhbiBpbnNlcnRpb24gKG9mIGEgbmV3DQogICByZWNvcmQpIG9yIGEgcmVwbGFjbWVudCBv ZiBhbiBleGlzdGluZyByZWNvcmQgd2hpY2ggaGFzIGEgVHlwZSBhbmQNCiAgIFN1YnRhZyAob3Ig VGFnKSBmaWVsZCB0aGF0IGV4YWN0bHkgbWF0Y2hlcyB0aGUgcmVjb3JkIHNlbnQuICBSZWNvcmRz DQogICBjYW5ub3QgYmUgZGVsZXRlZCBmcm9tIHRoZSByZWdpc3RyeS4NCg0KICAgVGhlIExhbmd1 YWdlIFRhZyBFeHRlbnNpb25zIHJlZ2lzdHJ5IHdpbGwgYWxzbyBiZSBnZW5lcmF0ZWQgYW5kIHNl bnQNCiAgIHRvIElBTkEgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy42LiAgVGhpcyByZWdpc3Ry eSBtYXkgY29udGFpbiBhdA0KICAgbW9zdCAyNSByZWNvcmRzIGFuZCB0aHVzIGNoYW5nZXMgdG8g dGhpcyByZWdpc3RyeSBhcmUgZXhwZWN0ZWQgdG8gYmUNCiAgIHZlcnkgaW5mcmVxdWVudC4NCg0K ICAgRnV0dXJlIHdvcmsgYnkgSUFOQSBvbiB0aGUgTGFuZ3VhZ2UgVGFnIEV4dGVuc2lvbnMgUmVn aXN0cnkgaXMNCiAgIGxpbWl0ZWQgdG8gdHdvIGNhc2VzLiAgRmlyc3QsIHRoZSBJRVNHIG1heSBy ZXF1ZXN0IHRoYXQgbmV3IHJlY29yZHMNCiAgIGJlIGluc2VydGVkIGludG8gdGhpcyByZWdpc3Ry eSBmcm9tIHRpbWUgdG8gdGltZS4gIFRoZXNlIHJlcXVlc3RzDQogICB3aWxsIGluY2x1ZGUgdGhl IHJlY29yZCB0byBpbnNlcnQgaW4gdGhlIGV4YWN0IGZvcm1hdCBkZXNjcmliZWQgaW4NCiAgIFNl Y3Rpb24gMy42LiAgSW4gYWRkaXRpb24sIHRoZXJlIG1heSBiZSBvY2Nhc2lvbmFsIHJlcXVlc3Rz IGZyb20gdGhlDQogICBtYWludGFpbmluZyBhdXRob3JpdHkgZm9yIGEgc3BlY2lmaWMgZXh0ZW5z aW9uIHRvIHVwZGF0ZSB0aGUgY29udGFjdA0KICAgaW5mb3JtYXRpb24gb3IgVVJMcyBpbiB0aGUg cmVjb3JkLiAgVGhlc2UgcmVxdWVzdHMgTVVTVCBpbmNsdWRlIHRoZQ0KICAgY29tcGxldGUsIHVw ZGF0ZWQgcmVjb3JkLiAgSUFOQSBpcyBub3QgcmVzcG9uc2libGUgZm9yIHZhbGlkYXRpbmcgdGhl DQogICBpbmZvcm1hdGlvbiBwcm92aWRlZCwgb25seSB0aGF0IGl0IGlzIHByb3Blcmx5IGZvcm1h dHRlZC4gIEl0IHNob3VsZA0KICAgcmVhc29uYWJseSBiZSBzZWVuIHRvIGNvbWUgZnJvbSB0aGUg bWFpbnRhaW5pbmcgYXV0aG9yaXR5IG5hbWVkIGluDQogICB0aGUgcmVjb3JkIHByZXNlbnQgaW4g dGhlIHJlZ2lzdHJ5Lg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMg T2N0b2JlciAyMiwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDQyXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAy MDA1DQoNCg0KNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZSBvbmx5IHNlY3Vy aXR5IGlzc3VlIHRoYXQgaGFzIGJlZW4gcmFpc2VkIHdpdGggbGFuZ3VhZ2UgdGFncyBzaW5jZQ0K ICAgdGhlIHB1YmxpY2F0aW9uIG9mIFJGQyAxNzY2IFsyMV0sIHdoaWNoIHN0YXRlZCB0aGF0ICJT ZWN1cml0eSBpc3N1ZXMNCiAgIGFyZSBiZWxpZXZlZCB0byBiZSBpcnJlbGV2YW50IHRvIHRoaXMg bWVtbyIsIGlzIGEgY29uY2VybiB3aXRoDQogICBsYW5ndWFnZSBpZGVudGlmaWVycyB1c2VkIGlu IGNvbnRlbnQgbmVnb3RpYXRpb24gLSB0aGF0IHRoZXkgbWF5IGJlDQogICB1c2VkIHRvIGluZmVy IHRoZSBuYXRpb25hbGl0eSBvZiB0aGUgc2VuZGVyLCBhbmQgdGh1cyBpZGVudGlmeQ0KICAgcG90 ZW50aWFsIHRhcmdldHMgZm9yIHN1cnZlaWxsYW5jZS4NCg0KICAgVGhpcyBpcyBhIHNwZWNpYWwg Y2FzZSBvZiB0aGUgZ2VuZXJhbCBwcm9ibGVtIHRoYXQgYW55dGhpbmcgc2VudCBpcw0KICAgdmlz aWJsZSB0byB0aGUgcmVjZWl2aW5nIHBhcnR5IGFuZCBwb3NzaWJseSB0byB0aGlyZCBwYXJ0aWVz IGFzIHdlbGwuDQogICBJdCBpcyB1c2VmdWwgdG8gYmUgYXdhcmUgdGhhdCBzdWNoIGNvbmNlcm5z IGNhbiBleGlzdCBpbiBzb21lIGNhc2VzLg0KDQogICBUaGUgZXZhbHVhdGlvbiBvZiB0aGUgZXhh Y3QgbWFnbml0dWRlIG9mIHRoZSB0aHJlYXQsIGFuZCBhbnkgcG9zc2libGUNCiAgIGNvdW50ZXJt ZWFzdXJlcywgaXMgbGVmdCB0byBlYWNoIGFwcGxpY2F0aW9uIHByb3RvY29sIChzZWUgQkNQIDcy LA0KICAgUkZDICAzNTUyIFsxNV0gZm9yIGJlc3QgY3VycmVudCBwcmFjdGljZSBndWlkYW5jZSBv biBzZWN1cml0eSB0aHJlYXRzDQogICBhbmQgZGVmZW5zZXMpLg0KDQogICBBbHRob3VnaCB0aGUg c3BlY2lmaWNhdGlvbiBvZiB2YWxpZCBzdWJ0YWdzIGZvciBhbiBleHRlbnNpb24gTVVTVCBiZQ0K ICAgYXZhaWxhYmxlIG92ZXIgdGhlIEludGVybmV0LCBpbXBsZW1lbnRhdGlvbnMgU0hPVUxEIE5P VCBtZWNoYW5pY2FsbHkNCiAgIGRlcGVuZCBvbiBpdCBiZWluZyBhbHdheXMgYWNjZXNzaWJsZSwg dG8gcHJldmVudCBkZW5pYWwtb2Ytc2VydmljZQ0KICAgYXR0YWNrcy4NCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA0 M10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCjcuICBDaGFyYWN0ZXIgU2V0IENvbnNpZGVyYXRp b25zDQoNCiAgIFRoZSBzeW50YXggaW4gdGhpcyBkb2N1bWVudCByZXF1aXJlcyB0aGF0IGxhbmd1 YWdlIHRhZ3MgdXNlIG9ubHkgdGhlDQogICBjaGFyYWN0ZXJzIEEtWiwgYS16LCAwLTksIGFuZCBI WVBIRU4tTUlOVVMsIHdoaWNoIGFyZSBwcmVzZW50IGluIG1vc3QNCiAgIGNoYXJhY3RlciBzZXRz LCBzbyB0aGUgY29tcG9zaXRpb24gb2YgbGFuZ3VhZ2UgdGFncyBzaG91bGQgbm90IGhhdmUNCiAg IGFueSBjaGFyYWN0ZXIgc2V0IGlzc3Vlcy4NCg0KICAgUmVuZGVyaW5nIG9mIGNoYXJhY3RlcnMg YmFzZWQgb24gdGhlIGNvbnRlbnQgb2YgYSBsYW5ndWFnZSB0YWcgaXMgbm90DQogICBhZGRyZXNz ZWQgaW4gdGhpcyBtZW1vLiAgSGlzdG9yaWNhbGx5LCBzb21lIGxhbmd1YWdlcyBoYXZlIHJlbGll ZCBvbg0KICAgdGhlIHVzZSBvZiBzcGVjaWZpYyBjaGFyYWN0ZXIgc2V0cyBvciBvdGhlciBpbmZv cm1hdGlvbiBpbiBvcmRlciB0bw0KICAgaW5mZXIgaG93IGEgc3BlY2lmaWMgY2hhcmFjdGVyIHNo b3VsZCBiZSByZW5kZXJlZCAobm90YWJseSB0aGlzDQogICBhcHBsaWVzIHRvIGxhbmd1YWdlIGFu ZCBjdWx0dXJlIHNwZWNpZmljIHZhcmlhdGlvbnMgb2YgSGFuIGlkZW9ncmFwaHMNCiAgIGFzIHVz ZWQgaW4gSmFwYW5lc2UsIENoaW5lc2UsIGFuZCBLb3JlYW4pLiAgV2hlbiBsYW5ndWFnZSB0YWdz IGFyZQ0KICAgYXBwbGllZCB0byBzcGFucyBvZiB0ZXh0LCByZW5kZXJpbmcgZW5naW5lcyBtYXkg dXNlIHRoYXQgaW5mb3JtYXRpb24NCiAgIGluIGRlY2lkaW5nIHdoaWNoIGZvbnQgdG8gdXNlIGlu IHRoZSBhYnNlbmNlIG9mIG90aGVyIGluZm9ybWF0aW9uLA0KICAgcGFydGljdWxhcmx5IHdoZXJl IGxhbmd1YWdlcyB3aXRoIGRpc3RpbmN0IHdyaXRpbmcgdHJhZGl0aW9ucyB1c2UgdGhlDQogICBz YW1lIGNoYXJhY3RlcnMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGly ZXMgT2N0b2JlciAyMiwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDQ0XQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJp bCAyMDA1DQoNCg0KOC4gIENoYW5nZXMgZnJvbSBSRkMgMzA2Ng0KDQogICBUaGUgbWFpbiBnb2Fs cyBmb3IgdGhpcyByZXZpc2lvbiBvZiBsYW5ndWFnZSB0YWdzIHdlcmUgdGhlIGZvbGxvd2luZzoN Cg0KICAgKkNvbXBhdGliaWxpdHkuKiBBbGwgdmFsaWQgUkZDIDMwNjYgbGFuZ3VhZ2UgdGFncyAg KGluY2x1ZGluZyB0aG9zZQ0KICAgaW4gdGhlIElBTkEgcmVnaXN0cnkpICByZW1haW4gdmFsaWQg aW4gdGhpcyBzcGVjaWZpY2F0aW9uLiAgVGh1cw0KICAgdGhlcmUgaXMgY29tcGxldGUgYmFja3dh cmQgY29tcGF0aWJpbGl0eSBvZiB0aGlzIHNwZWNpZmljYXRpb24gd2l0aA0KICAgZXhpc3Rpbmcg Y29udGVudC4gIEluIGFkZGl0aW9uLCB0aGlzIGRvY3VtZW50IGRlZmluZXMgbGFuZ3VhZ2UgdGFn cw0KICAgaW4gc3VjaCBhcyB3YXkgYXMgdG8gZW5zdXJlIGZ1dHVyZSBjb21wYXRpYmlsaXR5LCBh bmQgcHJvY2Vzc29ycw0KICAgYmFzZWQgc29sZWx5IG9uIHRoZSBSRkMgMzA2NiBBQk5GIChzdWNo IGFzIHRob3NlIGRlc2NyaWJlZCBpbiBYTUwNCiAgIFNjaGVtYSB2ZXJzaW9uIDEuMCBbMjBdKSB3 aWxsIGJlIGFibGUgdG8gcHJvY2VzcyB0YWdzIGRlc2NyaWJlZCBieQ0KICAgdGhpcyBkb2N1bWVu dC4NCg0KICAgKlN0YWJpbGl0eS4qIEJlY2F1c2Ugb2YgdGhlIGNoYW5nZXMgaW4gdW5kZXJseWlu ZyBJU08gc3RhbmRhcmRzLCBhDQogICB2YWxpZCBSRkMgMzA2NiBsYW5ndWFnZSB0YWcgbWF5IGJl Y29tZSBpbnZhbGlkIChvciBoYXZlIGl0cyBtZWFuaW5nDQogICBjaGFuZ2UpIGF0IGEgbGF0ZXIg ZGF0ZS4gIFdpdGggc28gbXVjaCBvZiB0aGUgd29ybGQncyBjb21wdXRpbmcNCiAgIGluZnJhc3Ry dWN0dXJlIGRlcGVuZGVudCBvbiBsYW5ndWFnZSB0YWdzLCB0aGlzIGlzIHNpbXBseQ0KICAgdW5h Y2NlcHRhYmxlOiBpdCBpbnZhbGlkYXRlcyBjb250ZW50IHRoYXQgbWF5IGhhdmUgYW4gZXh0ZW5z aXZlDQogICBzaGVsZi1saWZlLiAgSW4gdGhpcyBzcGVjaWZpY2F0aW9uLCBvbmNlIGEgbGFuZ3Vh Z2UgdGFnIGlzIHZhbGlkLCBpdA0KICAgcmVtYWlucyB2YWxpZCBmb3JldmVyLiAgUHJldmlvdXNs eSwgdGhlcmUgd2FzIG5vIHdheSB0byBkZXRlcm1pbmUNCiAgIHdoZW4gdHdvIHRhZ3Mgd2VyZSBl cXVpdmFsZW50LiAgVGhpcyBzcGVjaWZpY2F0aW9uIHByb3ZpZGVzIGEgc3RhYmxlDQogICBtZWNo YW5pc20gZm9yIGRvaW5nIHNvLCB0aHJvdWdoIHRoZSB1c2Ugb2YgY2Fub25pY2FsIGZvcm1zLiAg VGhlc2UNCiAgIGFyZSBhbHNvIHN0YWJsZSwgc28gdGhhdCBpbXBsZW1lbnRhdGlvbnMgY2FuIGRl cGVuZCBvbiB0aGUgdXNlIG9mDQogICBjYW5vbmljYWwgZm9ybXMgdG8gYXNzZXNzIGVxdWl2YWxl bmN5Lg0KDQogICAqVmFsaWRpdHkuKiAgVGhlIHN0cnVjdHVyZSBvZiBsYW5ndWFnZSB0YWdzIGRl ZmluZWQgYnkgdGhpcyBkb2N1bWVudA0KICAgbWFrZXMgaXQgcG9zc2libGUgdG8gZGV0ZXJtaW5l IGlmIGEgcGFydGljdWxhciB0YWcgaXMgd2VsbC1mb3JtZWQNCiAgIHdpdGhvdXQgcmVnYXJkIGZv ciB0aGUgYWN0dWFsIGNvbnRlbnQgb3IgIm1lYW5pbmciIG9mIHRoZSB0YWcgYXMgYQ0KICAgd2hv bGUuICBUaGlzIGlzIGltcG9ydGFudCBiZWNhdXNlIHRoZSByZWdpc3RyeSBhbmQgdW5kZXJseWlu Zw0KICAgc3RhbmRhcmRzICBjaGFuZ2Ugb3ZlciB0aW1lLiAgSW4gYWRkaXRpb24sIGl0IG11c3Qg YmUgcG9zc2libGUgdG8NCiAgIGRldGVybWluZSBpZiBhIHRhZyBpcyB2YWxpZCAob3Igbm90KSBm b3IgYSBnaXZlbiBwb2ludCBpbiB0aW1lIGluDQogICBvcmRlciAgdG8gcHJvdmlkZSByZXByb2R1 Y2libGUsIHRlc3RhYmxlIHJlc3VsdHMuICBUaGlzIHByb2Nlc3MgbXVzdA0KICAgbm90IGJlIGVy cm9yLXByb25lOyBvdGhlcndpc2UgZXZlbiBpbnRlbGxpZ2VudCBwZW9wbGUgd2lsbCBnZW5lcmF0 ZQ0KICAgaW1wbGVtZW50YXRpb25zIHRoYXQgZ2l2ZSBkaWZmZXJlbnQgcmVzdWx0cy4gIFRoaXMg c3BlY2lmaWNhdGlvbg0KICAgcHJvdmlkZXMgZm9yIHRoYXQgYnkgaGF2aW5nIGEgc2luZ2xlIGRh dGEgZmlsZSwgd2l0aCBzcGVjaWZpYw0KICAgdmVyc2lvbmluZyBpbmZvcm1hdGlvbiwgc28gdGhh dCB0aGUgdmFsaWRpdHkgb2YgbGFuZ3VhZ2UgdGFncyBhdCBhbnkNCiAgIHBvaW50IGluIHRpbWUg Y2FuIGJlIHByZWNpc2VseSBkZXRlcm1pbmVkIChpbnN0ZWFkIG9mIGludGVycG9sYXRpbmcNCiAg IHZhbHVlcyBmcm9tIG1hbnkgc2VwYXJhdGUgc291cmNlcykuDQoNCiAgICpFeHRlbnNpYmlsaXR5 LiogSXQgaXMgaW1wb3J0YW50IHRvIGJlIGFibGUgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuDQog ICB3cml0dGVuIGZvcm1zIG9mIGxhbmd1YWdlIC0tIGZvciBtYW55IGltcGxlbWVudGF0aW9ucyB0 aGlzIGlzIG1vcmUNCiAgIGltcG9ydGFudCB0aGFuIGRpc3Rpbmd1aXNoaW5nIGJldHdlZW4gc3Bv a2VuIHZhcmlhbnRzIG9mIGEgbGFuZ3VhZ2UuDQogICBMYW5ndWFnZXMgYXJlIHdyaXR0ZW4gaW4g YSB3aWRlIHZhcmlldHkgb2YgZGlmZmVyZW50IHNjcmlwdHMsIHNvIHRoaXMNCiAgIGRvY3VtZW50 IHByb3ZpZGVzIGZvciB0aGUgZ2VuZXJhdGl2ZSB1c2Ugb2YgSVNPIDE1OTI0IHNjcmlwdCBjb2Rl cy4NCiAgIExpa2UgdGhlIGdlbmVyYXRpdmUgdXNlIG9mIElTTyBsYW5ndWFnZSBhbmQgY291bnRy eSBjb2RlcyBpbiBSRkMNCiAgIDMwNjYsIHRoaXMgYWxsb3dzIGNvbWJpbmF0aW9ucyB0byBiZSBw cm9kdWNlZCB3aXRob3V0IHJlc29ydGluZyB0bw0KICAgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNz LiAgVGhlIGFkZGl0aW9uIG9mIFVOIGNvZGVzIHByb3ZpZGVzIGZvciB0aGUNCiAgIGdlbmVyYXRp b24gb2YgbGFuZ3VhZ2UgdGFncyB3aXRoIHJlZ2lvbmFsIHNjb3BlLCB3aGljaCBpcyBhbHNvDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAg ICAgICAgICAgICBbUGFnZSA0NV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIHJlcXVpcmVk IGZvciBpbmZvcm1hdGlvbiB0ZWNobm9sb2d5Lg0KDQogICBUaGUgcmVjYXN0IG9mIHRoZSByZWdp c3RyeSBmcm9tIGNvbnRhaW5pbmcgd2hvbGUgbGFuZ3VhZ2UgdGFncyB0bw0KICAgc3VidGFncyBp cyBhIGtleSBwYXJ0IG9mIHRoaXMuICBBbiBpbXBvcnRhbnQgZmVhdHVyZSBvZiBSRkMgMzA2NiB3 YXMNCiAgIHRoYXQgaXQgYWxsb3dlZCBnZW5lcmF0aXZlIHVzZSBvZiBzdWJ0YWdzLiAgVGhpcyBh bGxvd3MgcGVvcGxlIHRvDQogICBtZWFuaW5nZnVsbHkgdXNlIGdlbmVyYXRlZCB0YWdzLCB3aXRo b3V0IHRoZSBkZWxheXMgaW4gcmVnaXN0ZXJpbmcNCiAgIHdob2xlIHRhZ3MsIGFuZCB0aGUgYnVy ZGVuIG9uIHRoZSByZWdpc3RyeSBvZiBoYXZpbmcgdG8gc3VwcGx5IGFsbCBvZg0KICAgdGhlIGNv bWJpbmF0aW9ucyB0aGF0IHBlb3BsZSBtYXkgZmluZCB1c2VmdWwuDQoNCiAgIEJlY2F1c2Ugb2Yg dGhlIHdpZGVzcHJlYWQgdXNlIG9mIGxhbmd1YWdlIHRhZ3MsIGl0IGlzIHBvdGVudGlhbGx5DQog ICBkaXNydXB0aXZlIHRvIGhhdmUgcGVyaW9kaWMgcmV2aXNpb25zIG9mIHRoZSBjb3JlIHNwZWNp ZmljYXRpb24sDQogICBkZXNwaXRlIGRlbW9uc3RyYXRlZCBuZWVkLiAgVGhlIGV4dGVuc2lvbiBt ZWNoYW5pc20gcHJvdmlkZXMgZm9yIGENCiAgIHdheSBmb3IgaW5kZXBlbmRlbnQgUkZDcyB0byBk ZWZpbmUgZXh0ZW5zaW9ucyB0byBsYW5ndWFnZSB0YWdzLg0KICAgVGhlc2UgZXh0ZW5zaW9ucyBo YXZlIGEgdmVyeSBjb25zdHJhaW5lZCwgd2VsbC1kZWZpbmVkIHN0cnVjdHVyZSB0bw0KICAgcHJl dmVudCBleHRlbnNpb25zIGZyb20gaW50ZXJmZXJpbmcgd2l0aCBpbXBsZW1lbnRhdGlvbnMgb2Yg bGFuZ3VhZ2UNCiAgIHRhZ3MgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LiAgVGhlIGRvY3VtZW50 IGFsc28gYW50aWNpcGF0ZXMNCiAgIGZlYXR1cmVzIG9mIElTTyA2MzktMyB3aXRoIHRoZSBhZGRp dGlvbiBvZiB0aGUgZXh0ZW5kZWQgbGFuZ3VhZ2UNCiAgIHN1YnRhZ3MsIGFzIHdlbGwgYXMgdGhl IHBvc3NpYmlsaXR5IG9mIG90aGVyIElTTyA2MzkgcGFydHMgYmVjb21pbmcNCiAgIHVzZWZ1bCBm b3IgdGhlIGZvcm1hdGlvbiBvZiBsYW5ndWFnZSB0YWdzIGluIHRoZSBmdXR1cmUuICBUaGUgdXNl IGFuZA0KICAgZGVmaW5pdGlvbiBvZiBwcml2YXRlIHVzZSB0YWdzIGhhcyBhbHNvIGJlZW4gbW9k aWZpZWQsIHRvIGFsbG93DQogICBwZW9wbGUgdG8gbW92ZSBhcyBtdWNoIGluZm9ybWF0aW9uIGFz IHBvc3NpYmxlIG91dCBvZiBwcml2YXRlIHVzZQ0KICAgdGFncywgYW5kIGludG8gdGhlIHJlZ3Vs YXIgc3RydWN0dXJlLiAgVGhlIGdvYWwgaXMgdG8gZHJhbWF0aWNhbGx5DQogICByZWR1Y2UgdGhl IG5lZWQgdG8gcHJvZHVjZSBhIHJldmlzaW9uIG9mIHRoaXMgZG9jdW1lbnQgaW4gdGhlIGZ1dHVy ZS4NCg0KICAgVGhlIHNwZWNpZmljIGNoYW5nZXMgaW4gdGhpcyBkb2N1bWVudCB0byBtZWV0IHRo ZXNlIGdvYWxzIGFyZToNCg0KICAgbyAgRGVmaW5lcyB0aGUgQUJORiBhbmQgcnVsZXMgZm9yIHN1 YnRhZ3Mgc28gdGhhdCB0aGUgY2F0ZWdvcnkgb2YgYWxsDQogICAgICBzdWJ0YWdzIGNhbiBiZSBk ZXRlcm1pbmVkIHdpdGhvdXQgcmVmZXJlbmNlIHRvIHRoZSByZWdpc3RyeS4NCg0KICAgbyAgQWRk cyB0aGUgY29uY2VwdCBvZiB3ZWxsLWZvcm1lZCB2cy4gdmFsaWRhdGluZyBwcm9jZXNzb3JzLA0K ICAgICAgZGVmaW5pbmcgdGhlIHJ1bGVzIGJ5IHdoaWNoIGFuIGltcGxlbWVudGF0aW9uIGNhbiBj bGFpbSB0byBiZSBvbmUNCiAgICAgIG9yIHRoZSBvdGhlci4NCg0KICAgbyAgUmVwbGFjZXMgdGhl IElBTkEgbGFuZ3VhZ2UgdGFnIHJlZ2lzdHJ5IHdpdGggYSBsYW5ndWFnZSBzdWJ0YWcNCiAgICAg IHJlZ2lzdHJ5IHRoYXQgcHJvdmlkZXMgYSBjb21wbGV0ZSBsaXN0IG9mIHZhbGlkIHN1YnRhZ3Mg aW4gdGhlDQogICAgICBJQU5BIHJlZ2lzdHJ5LiAgVGhpcyBhbGxvd3MgZm9yIHJvYnVzdCBpbXBs ZW1lbnRhdGlvbiBhbmQgZWFzZSBvZg0KICAgICAgbWFpbnRlbmFuY2UuICBUaGUgbGFuZ3VhZ2Ug c3VidGFnIHJlZ2lzdHJ5IGJlY29tZXMgdGhlIGNhbm9uaWNhbA0KICAgICAgc291cmNlIGZvciBm b3JtaW5nIGxhbmd1YWdlIHRhZ3MuDQoNCiAgIG8gIFByb3ZpZGVzIGEgcHJvY2VzcyB0aGF0IGd1 YXJhbnRlZXMgc3RhYmlsaXR5IG9mIGxhbmd1YWdlIHRhZ3MsIGJ5DQogICAgICBoYW5kbGluZyBy ZXVzZSBvZiB2YWx1ZXMgYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBhbmQgSVNPIDMxNjYgaW4NCiAg ICAgIHRoZSBldmVudCB0aGF0IHRoZXkgcmVnaXN0ZXIgYSBwcmV2aW91c2x5IHVzZWQgdmFsdWUg Zm9yIGEgbmV3DQogICAgICBwdXJwb3NlLg0KDQogICBvICBBbGxvd3MgSVNPIDE1OTI0IHNjcmlw dCBjb2RlIHN1YnRhZ3MgYW5kIGFsbG93cyB0aGVtIHRvIGJlIHVzZWQNCiAgICAgIGdlbmVyYXRp dmVseS4gIEFkZHMgdGhlIGNvbmNlcHQgb2YgYSB2YXJpYW50IHN1YnRhZyBhbmQgYWxsb3dzDQog ICAgICB2YXJpYW50cyB0byBiZSB1c2VkIGdlbmVyYXRpdmVseS4gIEFkZHMgdGhlIGFiaWxpdHkg dG8gdXNlIGEgY2xhc3MNCiAgICAgIG9mIFVOIHRhZ3MgYXMgcmVnaW9ucy4NCg0KDQoNClBoaWxs aXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwNSAgICAgICAgICAgICAg IFtQYWdlIDQ2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lz dHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgbyAgRGVmaW5lcyB0aGUgcHJp dmF0ZS11c2UgdGFncyBpbiBJU08gNjM5LCBJU08gMTU5MjQsIGFuZCBJU08gMzE2Ng0KICAgICAg YXMgdGhlIG1lY2hhbmlzbSBmb3IgY3JlYXRpbmcgcHJpdmF0ZS11c2UgbGFuZ3VhZ2UsIHNjcmlw dCwgYW5kDQogICAgICByZWdpb24gc3VidGFncyByZXNwZWN0aXZlbHkuDQoNCiAgIG8gIEFkZHMg YSB3ZWxsLWRlZmluZWQgZXh0ZW5zaW9uIG1lY2hhbmlzbS4NCg0KICAgbyAgRGVmaW5lcyBhbiBl eHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcsIHBvc3NpYmx5IGZvciB1c2Ugd2l0aCBjZXJ0YWluDQog ICAgICBhbnRpY2lwYXRlZCBmZWF0dXJlcyBvZiBJU08gNjM5LTMuDQoNCiAgIEVkIE5vdGU6IFRo ZSBmb2xsb3dpbmcgaXRlbXMgYXJlIHByb3ZpZGVkIGZvciB0aGUgY29udmVuaWVuY2Ugb2YNCiAg IHJldmlld2VycyBhbmQgd2lsbCBiZSByZW1vdmVkIGZyb20gdGhlIGZpbmFsIGRvY3VtZW50Lg0K DQogICBDaGFuZ2VzIGJldHdlZW4gZHJhZnQtaWV0Zi1sdHJ1LXJlZ2lzdHJ5LTAwIGFuZCB0aGlz IHZlcnNpb24gYXJlOg0KDQogICBvICBVcGRhdGVkIHRoZSBBQk5GIGZvciBzaW5nbGV0b24gdG8g bWFrZSBpdCBjb25mb3JtIHRvIFJGQyAyMjM0IGFuZA0KICAgICAgcGFzcyB0aGUgRmVubmVyIHBh cnNlciAoRi5FbGxlcm1hbm4pDQoNCiAgIG8gIFNwbGl0IHRoZSByZWZlcmVuY2VzIGludG8gaW5m b3JtYXRpdmUgYW5kIG5vcm1hdGl2ZSBsaXN0cy4NCiAgICAgIEVsaW1pbmF0ZWQgZGVhZCByZWZl cmVuY2VzIGNhcnJpZWQgZm9yd2FyZCBmcm9tIHByZXZpb3VzIHZlcnNpb25zDQogICAgICBvZiB0 aGlzIGRvY3VtZW50LiAgKEEuUGhpbGxpcHMpDQoNCiAgIG8gIEFkZGVkIGEgcmVmZXJlbmNlIHRv IFJGQyAzNTUyIChCQ1AgNzIpIHRvIHRoZSBTZWN1cml0eQ0KICAgICAgQ29uc2lkZXJhdGlvbnMg c2VjdGlvbiAoSS5NY0RvbmFsZCkNCg0KICAgbyAgTW9kaWZpZWQgdGhlIGZpcnN0IHNlbnRlbmNl IGluIFNlY3Rpb24gMi4xLjEgZnJvbSAib24gdGhlIG51bWJlcg0KICAgICAgb2Ygc2l6ZSBvZiBz dWJ0YWdzIGluIGEgTGFuZ3VhZ2UgVGFnIiB0byBiZSBwcm9wZXIgRW5nbGlzaCBhbmQNCiAgICAg IGNvbnZleSBtb3JlIG1lYW5pbmcuICAoQS5QaGlsbGlwcykNCg0KICAgbyAgVmFyaW91cyBleGFt cGxlcyB0aGF0IHVzZWQgdGhlIHZhcmlhbnQgJ2Jvb250JyB3ZXJlIGNoYW5nZXMgdG8gdXNlDQog ICAgICB0aGUgdmFyaWFudCAnc2NvdXNlJyBpbnN0ZWFkLiAgKEouQ293YW4pDQoNCiAgIG8gIEFk ZGVkIGFuIGFkZGl0aW9uYWwgZXhhbXBsZSAoImVuLWEtYmJiLXgtYS1jY2MiKSB0byB0aGUgZXh0 ZW5zaW9uLw0KICAgICAgc2luZ2xldG9uIHJ1bGVzIGluIFNlY3Rpb24gMi4yLjYgdG8gaWxsdXN0 cmF0ZSB0aGF0IHNpbmdsZXRvbnMgY2FuDQogICAgICByZWN1ciBpbiBwcml2YXRlIHVzZSBzZXF1 ZW5jZXMgKEEuUGhpbGxpcHMpDQoNCiAgIG8gIE1vZGlmaWVkIHRoZSBzZW50ZW5jZSBkZXNjcmli aW5nIHRoZSBwb3NzaWJpbGl0aWVzIGZvciB2YXJpYW50DQogICAgICByZWdpc3RyYXRpb24gKHNl ZSBTZWN0aW9uIDMuNSkgIHRvIGluY2x1ZGUgdHJhbnNsaXRlcmF0aW9ucyBhbmQNCiAgICAgIG90 aGVyIHRyYW5zZm9ybWF0aW9ucyBwZXIgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdC4gIChNLlQuIENh cnJhc2NvDQogICAgICBCZW5pdGV6KQ0KDQogICBvICBDb252ZXJ0ZWQgdGhlIGZvcm1hdCBvZiB0 aGUgcmVnaXN0cnkgdG8gcmVjb3JkLWphciBmb3JtYXQuICBUaGlzDQogICAgICBzdWJ0YW50aWFs bHkgcmVwbGFjZXMgc2VjdGlvbiAzLjEgKFIuUHJlc3VobikNCg0KICAgbyAgU3VidGFudGlhbGx5 IHJldmlzZWQgdGhlIHJ1bGVzIGZvciByZWdpc3RyeSBjcmVhdGlvbiB0byByZWZsZWN0DQogICAg ICB0aGUgRGF0ZSBBL0IgYm91bmRhcmllcyBvbiBhZG9wdGluZyBJU08gMzE2NiBjb2RlcyAoSi5D b3dhbikNCg0KICAgbyAgTW9kaWZpZWQgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIHNlY3Rpb24g YW5kIGZvcm0gdG8gZGVhbCB3aXRoDQogICAgICBib3RoIG5ldyBhZGRpdGlvbnMgYW5kIHJldmlz aW9ucyBvZiByZWNvcmRzLCBhcyB3ZWxsIGFzIG1ha2luZw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgNDdd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICAgICBsaWZlIGVhc2llciBvbiB0aGUgU3VidGFn IFJldmlld2VyIGJ5IG1hdGNoaW5nIHRoZSBmaWVsZHMgdG8gdGhlDQogICAgICByZWdpc3RyeSBm b3JtYXQuICAoQS5QaGlsbGlwcykNCg0KICAgbyAgQ2hhbmdlZCB0aGUgcmVmZXJlbmNlIHRvIFJG QyAyMjM0IHRvIFJGQyAyMjM0YmlzIChyZWNlbnRseQ0KICAgICAgYWRvcHRlZCkuICAoUy5Ib2xs ZW5iZWNrKQ0KDQogICBvICBNb2RpZmljYXRpb25zIHRvIG1ha2UgdGhpcyBkb2N1bWVudCBjb25m b3JtYW50IHdpdGggUkZDIDM5NzgNCiAgICAgIChyZWNlbnRseSBhZG9wdGVkKS4gIChSLlByZXN1 aG4pDQoNCiAgIG8gIEFkZGVkIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byBYTUwgU2NoZW1h IDEuMCBQYXJ0IDI6IFNlY29uZA0KICAgICAgRWRpdGlvbiBpbiB0aGlzIHNlY3Rpb24uICAoSi5N b3JmaW4pDQoNCiAgIG8gIEV4cGFuZGVkIHRoZSBqYXJnb24taXNoICdleHRsYW5nJyB0byAiZXh0 ZW5kZWQgbGFuZ3VhZ2UiIGluIHRoaXMNCiAgICAgIHNlY3Rpb24uICAoSi5Nb3JmaW4pDQoNCiAg IG8gIENvcnJlY3RlZCBhbiBlZ3JlZ2lvdXMgZXJyb3IgaW4gdGhlIEFCTkYgKCV4NkEgLT4gJXg1 QSBpbiBvbmUgb2YNCiAgICAgIHRoZSByYW5nZXMpIChBLlBoaWxsaXBzKQ0KDQogICBvICBTcGxp dCBNYWludGVuYW5jZSBvZiB0aGUgUmVnaXN0cnkgZnJvbSBGb3JtYXQgb2YgdGhlIFJlZ2lzdHJ5 DQogICAgICAoQS5QaGlsbGlwcykNCg0KICAgbyAgUmV2aXNpb24gb2Ygc2VjdGlvbiBTZWN0aW9u IDMuNCB0byBtYWtlIGl0IGNvbnNpc3RlbnQgd2l0aCB0aGUgbmV3DQogICAgICBzZWN0aW9uIFNl Y3Rpb24gMy4yLiAgKEEuUGhpbGxpcHMpDQoNCiAgIG8gIFNlcGFyYXRlZCBJQU5BIENvbnNpZGVy YXRpb25zIHNlY3Rpb24gZnJvbSB0aGUgcmVnaXN0cnkgZGVmaW5pdGlvbg0KICAgICAgYW5kIHJl Z2lzdHJhdGlvbiBwcm9jZWR1cmVzLiAoKQ0KDQogICBvICBBZGRlZCBhZGRpdGlvbmFsIGNob2lj ZSBpbmZvcm1hdGlvbiBkZWFsaW5nIHdpdGggc2NyaXB0cyBhbmQNCiAgICAgIGV4dGxhbmdzLiAg VGhlc2UgaXRlbXMgd2VyZSBhbHNvIG1vdmVkIHRvIGEgbmV3IHNlY3Rpb24gZm9sbG93aW5nDQog ICAgICB0aGUgcmVnaXN0cnkgZm9ybWF0IGJlY2F1c2Ugb2YgaW50ZXJkZXBlbmRlbmNlLg0KDQog ICBvICBVcGRhdGVkIHRoZSBJQU5BIENvbnNpZGVyYXRpb25zIHNlY3Rpb24uDQoNCiAgIG8gIEFk ZGVkIGFwcGVhbCBhbmQgbWFpbnRlbmFuY2UgcmVxdWlyZW1lbnRzIHRvIHRoZSBleHRlbnNpb25z DQogICAgICBTZWN0aW9uIDMuNiBzZWN0aW9uLiAgKEEuUGhpbGxpcHMpDQoNCiAgIG8gIEFkZGVk IGFuIGFkZGl0aW9uYWwgYnVsbGV0IHBvaW50IHRvIFNlY3Rpb24gMy41IGVudW1lcmF0aW5nIHRo ZQ0KICAgICAgY2hhbmdlcyB0aGF0IGNhbiBiZSByZWdpc3RlcmVkIHRvIGEgcmVjb3JkIChwcmV2 aW91c2x5IHdlIG9ubHkNCiAgICAgIGxpc3RlZCB0aGUgb3B0aW9ucyBmb3IgbmV3IHN1YnRhZ3Mp LiAgKEEuUGhpbGxpcHMpDQoNCiAgIG8gIEFkZGVkIHRoZSBwaHJhc2UgIiwgYXMgd2VsbCBhcyB0 aGUgcG9zc2liaWxpdHkgb2Ygb3RoZXIgSVNPIDYzOQ0KICAgICAgcGFydHMgYmVjb21pbmcgdXNl ZnVsIGZvciB0aGUgZm9ybWF0aW9uIG9mIGxhbmd1YWdlIHRhZ3MgaW4gdGhlDQogICAgICBmdXR1 cmUiIHRvIHRoaXMgc2VjdGlvbiBpbiBhbnRpY2lwYXRpb24gb2YgcmV2aXNpbmcgdGhlIEFCTkYg dG8NCiAgICAgIGFsbG93IGZvciB0aGUgcG9zc2liaWxpdHkgb2YgSVNPIDYzOS02IGJlaW5nIHVz ZWQgaW4gbGFuZ3VhZ2UgdGFncw0KICAgICAgaW4gYSBmdXR1cmUgcmV2aXNpb24gb2YgdGhpcyBk b2N1bWVudC4gIChELkdhcnNpZGUpDQoNCiAgIG8gIEFkZGVkIHRoZSBjb25jZXB0IG9mICdTdXBw cmVzcy1TY3JpcHQnIHRvIFNlY3Rpb24gNC4xLCBhcyB3ZWxsIGFzDQogICAgICB0byB0aGUgcmVn aXN0cnkgZm9ybWF0IGluIFNlY3Rpb24gMy4xLCBTZWN0aW9uIDMuMyBhbmQNCg0KDQoNClBoaWxs aXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwNSAgICAgICAgICAgICAg IFtQYWdlIDQ4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lz dHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgICAgU2VjdGlvbiAzLjIuICht YW55KQ0KDQogICBvICBBZGRlZCB0ZXh0IHJlcXVpcmluZyB0aGUgSS1EIHRoYXQgZGVmaW5lcyBh biBleHRlbnNpb24gdG8gY2hvb3NlIGENCiAgICAgIGxldHRlciAoYW5kIGFsbG93aW5nIHRoZSBJ RVNHIHRvIGNoYW5nZSBpdCBpZiBuZWNlc3NhcnkpLg0KICAgICAgKEQuRXdlbGw/KQ0KDQogICBv ICBSZW1vdmVkIHRoZSBBQk5GIG5vdGVzIGZyb20gdGhlIHRleHQgYWJvdXQgY2FzZSBpbnNlbnNp dGl2aXR5DQogICAgICAoRi5FbGxlcm1hbm4pDQoNCiAgIG8gIFJlbW92ZWQgdGhlIHNlY29uZCwg cmF0aGVyIHJlcGV0aXRpdmUgcmVmZXJlbmNlIHRvIEFwcGVuZGl4IEIgaW4NCiAgICAgIFNlY3Rp b24gMi4xIChBLlBoaWxsaXBzKQ0KDQogICBvICBGaXhlZCBtaXNzaW5nIHdoaXRlc2FwY2UgaW4g U2VjdGlvbiAyLjEgKEYuRWxsZXJtYW5uKQ0KDQogICBvICBDaGFuZ2VkICJlbXB0eSIgdG8gIm9t aXR0ZWQiIGluIFNlY3Rpb24gMi4yLjEgKEYuRWxsZXJtYW5uKQ0KDQogICBvICBDaGFuZ2VkIHRo ZSBpbnRybyB0byBTZWN0aW9uIDIuMi4xIGFuZCBvdGhlcndpc2UgdHVnZ2VkIGF0IHRoYXQNCiAg ICAgIHNlY3Rpb24gdG8gZGVhbCB3aXRoIGktKiBncmFuZGZhdGhlcmVkIGl0ZW1zLiAgKEYuRWxs ZXJtYW5uKQ0KDQogICBvICBSZXNlcnZlZCBhbHBoYTQgbGFuZ3VhZ2Ugc3VidGFncyBmb3IgZnV0 dXJlIHN0YW5kYXJkaXphdGlvbi4NCiAgICAgIChELkdhcnNpZGUpDQoNCiAgIG8gIEluY29ycG9y YXRlIGNoYW5nZXMgdG8gYmUgY29uc2lzdGVudCB3aXRoIFJGQyAzOTc4LCBpbmNsdWRpbmcgdGhl DQogICAgICBuZXcgeG1sMnJmYyBwcm9jZXNzb3IuICBOb3RlIHRoYXQgdGhpcyBoYXMgYW4gZWZm ZWN0IG9uIHRoZSBBQk5GLA0KICAgICAgc2luY2Ugc29tZSBvZiB0aGUgY29tbWVudHMgd2VyZSB0 b28gd2lkZSBwcmV2aW91c2x5IChjb21tZW50cyB3ZXJlDQogICAgICByZXZpc2VkIHRvIGZpdCB0 aGUgNzIgY2hhcmFjdGVyIG1heGltdW0pLiAgKFMuSG9sbGVuYmVjaykNCg0KICAgbyAgUmVtb3Zl IHRoZSBMYXRpbi0xIHJlc3RyaWN0aW9uIG9uIHRoZSAnRGVzY3JpcHRpb24nIGZpZWxkLg0KICAg ICAgUHJvdmlkZSBndWlkYW5jZSBmb3IgcmVnaXN0cmF0aW9uIG9mIGNvbnRlbnQsIGluY2x1ZGlu ZyBhDQogICAgICByZXF1aXJlbWVudCBmb3IgYXQgbGVhc3Qgb25lIHJlcHJlc2VudGF0aW9uIGlu IHRoZSBMYXRpbiBzY3JpcHQuDQogICAgICAoRi5FbGxlcm1hbm4sIEEuUGhpbGxpcHMpDQoNCiAg IG8gIE1ha2UgdGhlIHZhcmlhbnQgc3VidGxldHkgbGVzcyBzby4gIChGLkVsbGVybWFubikNCg0K ICAgbyAgVmFyaW91cyAneW91JyByZW1vdmFscyBhbmQgY2xlYW51cCAoTS5EYXZpcykNCg0KICAg byAgSW5zZXJ0ZWQgYWRkaXRpb25hbCBub24tbm9ybWF0aXZlIGNhdmVhdCBhYm91dCB0aGUgJ01V TCcgc3VidGFnDQogICAgICAoQS5QaGlsbGlwcykNCg0KICAgbyAgVmFyaW91cyBlZGl0b3JpYWwg ZWRpdHMgKEouQ293YW4pDQoNCiAgIG8gIFVzZSBub3JtYXRpdmUgbGFuZ3VhZ2Ugd2hlbiBnaXZp bmcgcGVybWlzc2lvbiB0byBub3Qgc3RvcmUgbG9uZw0KICAgICAgbGFuZ3VhZ2UgdGFncyBpbiBT ZWN0aW9uIDIuMS4xLiAgKEouQ293YW4pDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgNDld DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQo5LiAgUmVmZXJlbmNlcw0KDQo5LjEgIE5vcm1hdGl2 ZSBSZWZlcmVuY2VzDQoNCiAgIFsxXSAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBT dGFuZGFyZGl6YXRpb24sICJJU08gNjM5LQ0KICAgICAgICAgMToyMDAyLCBDb2RlcyBmb3IgdGhl IHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGxhbmd1YWdlcyAtLQ0KICAgICAgICAgUGFydCAx OiBBbHBoYS0yIGNvZGUiLCBJU08gU3RhbmRhcmQgNjM5LCAyMDAyLg0KDQogICBbMl0gICBJbnRl cm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPIDYzOS0yOjE5 OTgNCiAgICAgICAgIC0gQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZiBs YW5ndWFnZXMgLS0gUGFydCAyOg0KICAgICAgICAgQWxwaGEtMyBjb2RlIC0gZWRpdGlvbiAxIiwg QXVndXN0IDE5ODguDQoNCiAgIFszXSAgIElTTyBUQzQ2L1dHMywgIklTTyAxNTkyNDoyMDAzIChF L0YpIC0gQ29kZXMgZm9yIHRoZQ0KICAgICAgICAgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2Yg c2NyaXB0cyIsIEphbnVhcnkgMjAwNC4NCg0KICAgWzRdICAgSW50ZXJuYXRpb25hbCBPcmdhbml6 YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIkNvZGVzIGZvciB0aGUNCiAgICAgICAgIHJlcHJl c2VudGF0aW9uIG9mIG5hbWVzIG9mIGNvdW50cmllcywgM3JkIGVkaXRpb24iLA0KICAgICAgICAg SVNPIFN0YW5kYXJkIDMxNjYsIEF1Z3VzdCAxOTg4Lg0KDQogICBbNV0gICBTdGF0aXN0aWNhbCBE aXZpc2lvbiwgVW5pdGVkIE5hdGlvbnMsICJTdGFuZGFyZCBDb3VudHJ5IG9yIEFyZWENCiAgICAg ICAgIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2UiLCBVTiBTdGFuZGFyZCBDb3VudHJ5IG9yIEFy ZWEgQ29kZXMNCiAgICAgICAgIGZvciBTdGF0aXN0aWNhbCBVc2UsIFJldmlzaW9uIDQgKFVuaXRl ZCBOYXRpb25zIHB1YmxpY2F0aW9uLA0KICAgICAgICAgU2FsZXMgTm8uIDk4LlhWSUkuOSwgSnVu ZSAxOTk5Lg0KDQogICBbNl0gICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRh cmRpemF0aW9uLCAiSVNPL0lFQyAxMDY0Ni0NCiAgICAgICAgIDE6MjAwMC4gSW5mb3JtYXRpb24g dGVjaG5vbG9neSAtLSBVbml2ZXJzYWwgTXVsdGlwbGUtT2N0ZXQNCiAgICAgICAgIENvZGVkIENo YXJhY3RlciBTZXQgKFVDUykgLS0gUGFydCAxOiBBcmNoaXRlY3R1cmUgYW5kIEJhc2ljDQogICAg ICAgICBNdWx0aWxpbmd1YWwgUGxhbmUgYW5kIElTTy9JRUMgMTA2NDYtMjoyMDAxLiBJbmZvcm1h dGlvbg0KICAgICAgICAgdGVjaG5vbG9neSAtLSBVbml2ZXJzYWwgTXVsdGlwbGUtT2N0ZXQgQ29k ZWQgQ2hhcmFjdGVyIFNldA0KICAgICAgICAgKFVDUykgLS0gUGFydCAyOiBTdXBwbGVtZW50YXJ5 IFBsYW5lcywgYXMsIGZyb20gdGltZSB0byB0aW1lLA0KICAgICAgICAgYW1lbmRlZCwgcmVwbGFj ZWQgYnkgYSBuZXcgZWRpdGlvbiBvciBleHBhbmRlZCBieSB0aGUgYWRkaXRpb24NCiAgICAgICAg IG9mIG5ldyBwYXJ0cyIsIDIwMDAuDQoNCiAgIFs3XSAgIFVuaWNvZGUgQ29uc29ydGl1bSwgIlRo ZSBVbmljb2RlIENvbnNvcnRpdW0uIFRoZSBVbmljb2RlDQogICAgICAgICBTdGFuZGFyZCwgVmVy c2lvbiA0LjEuMCwgZGVmaW5lZCBieTogVGhlIFVuaWNvZGUgU3RhbmRhcmQsDQogICAgICAgICBW ZXJzaW9uIDQuMCAoQm9zdG9uLCBNQSwgQWRkaXNvbi1XZXNsZXksIDIwMDMuIElTQk4gMC0zMjEt DQogICAgICAgICAxODU3OC0xKSwgYXMgYW1lbmRlZCBieSBVbmljb2RlIDQuMC4xDQogICAgICAg ICAoaHR0cDovL3d3dy51bmljb2RlLm9yZy92ZXJzaW9ucy9Vbmljb2RlNC4wLjEpIGFuZCBieSBV bmljb2RlDQogICAgICAgICA0LjEuMCAoaHR0cDovL3d3dy51bmljb2RlLm9yZy92ZXJzaW9ucy9V bmljb2RlNC4xLjApLiIsDQogICAgICAgICBNYXJjaCAyMDA1Lg0KDQogICBbOF0gICBDcm9ja2Vy LCBELiBhbmQgUC4gT3ZlcmVsbCwgIkF1Z21lbnRlZCBCTkYgZm9yIFN5bnRheA0KICAgICAgICAg U3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBkcmFmdC1jcm9ja2VyLWFibmYtcmZjMjIzNGJpcy0wMCAo d29yaw0KICAgICAgICAgaW4gcHJvZ3Jlc3MpLCBNYXJjaCAyMDA1Lg0KDQogICBbOV0gICBCcmFk bmVyLCBTLiwgIlRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgUHJvY2VzcyAtLSBSZXZpc2lvbiAzIiwN CiAgICAgICAgIEJDUCA5LCBSRkMgMjAyNiwgT2N0b2JlciAxOTk2Lg0KDQoNCg0KDQpQaGlsbGlw cyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBb UGFnZSA1MF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3Ry eSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIFsxMF0gIEhvdmV5LCBSLiBhbmQg Uy4gQnJhZG5lciwgIlRoZSBPcmdhbml6YXRpb25zIEludm9sdmVkIGluIHRoZQ0KICAgICAgICAg SUVURiBTdGFuZGFyZHMgUHJvY2VzcyIsIEJDUCAxMSwgUkZDIDIwMjgsIE9jdG9iZXIgMTk5Ni4N Cg0KICAgWzExXSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIElu ZGljYXRlIFJlcXVpcmVtZW50DQogICAgICAgICBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBN YXJjaCAxOTk3Lg0KDQogICBbMTJdICBOYXJ0ZW4sIFQuIGFuZCBILiBBbHZlc3RyYW5kLCAiR3Vp ZGVsaW5lcyBmb3IgV3JpdGluZyBhbiBJQU5BDQogICAgICAgICBDb25zaWRlcmF0aW9ucyBTZWN0 aW9uIGluIFJGQ3MiLCBCQ1AgMjYsIFJGQyAyNDM0LA0KICAgICAgICAgT2N0b2JlciAxOTk4Lg0K DQogICBbMTNdICBDYXJwZW50ZXIsIEIuLCBCYWtlciwgRi4sIGFuZCBNLiBSb2JlcnRzLCAiTWVt b3JhbmR1bSBvZg0KICAgICAgICAgVW5kZXJzdGFuZGluZyBDb25jZXJuaW5nIHRoZSBUZWNobmlj YWwgV29yayBvZiB0aGUgSW50ZXJuZXQNCiAgICAgICAgIEFzc2lnbmVkIE51bWJlcnMgQXV0aG9y aXR5IiwgUkZDIDI4NjAsIEp1bmUgMjAwMC4NCg0KICAgWzE0XSAgS2x5bmUsIEcuIGFuZCBDLiBO ZXdtYW4sICJEYXRlIGFuZCBUaW1lIG9uIHRoZSBJbnRlcm5ldDoNCiAgICAgICAgIFRpbWVzdGFt cHMiLCBSRkMgMzMzOSwgSnVseSAyMDAyLg0KDQogICBbMTVdICBSZXNjb3JsYSwgRS4gYW5kIEIu IEtvcnZlciwgIkd1aWRlbGluZXMgZm9yIFdyaXRpbmcgUkZDIFRleHQgb24NCiAgICAgICAgIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIiwgQkNQIDcyLCBSRkMgMzU1MiwgSnVseSAyMDAzLg0KDQog ICBbMTZdICBCcmFkbmVyLCBTLiwgIklFVEYgUmlnaHRzIGluIENvbnRyaWJ1dGlvbnMiLCBCQ1Ag NzgsIFJGQyAzOTc4LA0KICAgICAgICAgTWFyY2ggMjAwNS4NCg0KOS4yICBJbmZvcm1hdGl2ZSBS ZWZlcmVuY2VzDQoNCiAgIFsxN10gIElTTyA2MzkgSm9pbnQgQWR2aXNvcnkgQ29tbWl0dGVlLCAi SVNPIDYzOSBKb2ludCBBZHZpc29yeQ0KICAgICAgICAgQ29tbWl0dGVlOiAgV29ya2luZyBwcmlu Y2lwbGVzIGZvciBJU08gNjM5IG1haW50ZW5hbmNlIiwNCiAgICAgICAgIE1hcmNoIDIwMDAsDQog ICAgICAgICA8aHR0cDovL3d3dy5sb2MuZ292L3N0YW5kYXJkcy9pc282MzktMi9pc282MzlqYWNf bjNyLmh0bWw+Lg0KDQogICBbMThdICBSYXltb25kLCBFLiwgIlRoZSBBcnQgb2YgVW5peCBQcm9n cmFtbWluZyIsIDIwMDMuDQoNCiAgIFsxOV0gIEJyYXkgKGV0IGFsKSwgVC4sICJFeHRlbnNpYmxl IE1hcmt1cCBMYW5ndWFnZSAoWE1MKSAxLjAgKFRoaXJkDQogICAgICAgICBFZGl0aW9uKSIsIDAy IDIwMDQuDQoNCiAgIFsyMF0gIEJpcm9uLCBQLiwgRWQuIGFuZCBBLiBNYWxob3RyYSwgRWQuLCAi WE1MIFNjaGVtYSBQYXJ0IDI6DQogICAgICAgICBEYXRhdHlwZXMgU2Vjb25kIEVkaXRpb24iLCAx MCAyMDA0LCA8DQogICAgICAgICBodHRwOi8vd3d3LnczLm9yZy9UUi94bWxzY2hlbWEtMi8+Lg0K DQogICBbMjFdICBBbHZlc3RyYW5kLCBILiwgIlRhZ3MgZm9yIHRoZSBJZGVudGlmaWNhdGlvbiBv ZiBMYW5ndWFnZXMiLA0KICAgICAgICAgUkZDIDE3NjYsIE1hcmNoIDE5OTUuDQoNCiAgIFsyMl0g IEZyZWVkLCBOLiBhbmQgSy4gTW9vcmUsICJNSU1FIFBhcmFtZXRlciBWYWx1ZSBhbmQgRW5jb2Rl ZCBXb3JkDQogICAgICAgICBFeHRlbnNpb25zOiBDaGFyYWN0ZXIgU2V0cywgTGFuZ3VhZ2VzLCBh bmQgQ29udGludWF0aW9ucyIsDQogICAgICAgICBSRkMgMjIzMSwgTm92ZW1iZXIgMTk5Ny4NCg0K ICAgWzIzXSAgQWx2ZXN0cmFuZCwgSC4sICJUYWdzIGZvciB0aGUgSWRlbnRpZmljYXRpb24gb2Yg TGFuZ3VhZ2VzIiwNCiAgICAgICAgIEJDUCA0NywgUkZDIDMwNjYsIEphbnVhcnkgMjAwMS4NCg0K DQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwNSAgICAg ICAgICAgICAgIFtQYWdlIDUxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0 YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KQXV0aG9ycycgQWRk cmVzc2VzDQoNCiAgIEFkZGlzb24gUGhpbGxpcHMgKGVkaXRvcikNCiAgIFF1ZXN0IFNvZnR3YXJl DQoNCiAgIEVtYWlsOiBhZGRpc29uLnBoaWxsaXBzQHF1ZXN0LmNvbQ0KDQoNCiAgIE1hcmsgRGF2 aXMgKGVkaXRvcikNCiAgIElCTQ0KDQogICBFbWFpbDogbWFyay5kYXZpc0B1cy5pYm0uY29tDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9i ZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA1Ml0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0K DQoNCkFwcGVuZGl4IEEuICBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIEFueSBsaXN0IG9mIGNvbnRy aWJ1dG9ycyBpcyBib3VuZCB0byBiZSBpbmNvbXBsZXRlOyBwbGVhc2UgcmVnYXJkIHRoZQ0KICAg Zm9sbG93aW5nIGFzIG9ubHkgYSBzZWxlY3Rpb24gZnJvbSB0aGUgZ3JvdXAgb2YgcGVvcGxlIHdo byBoYXZlDQogICBjb250cmlidXRlZCB0byBtYWtlIHRoaXMgZG9jdW1lbnQgd2hhdCBpdCBpcyB0 b2RheS4NCg0KICAgVGhlIGNvbnRyaWJ1dG9ycyB0byBSRkMgMzA2NiBhbmQgUkZDIDE3NjYsIHRo ZSBwcmVjdXJzb3JzIG9mIHRoaXMNCiAgIGRvY3VtZW50LCBtYWRlIGVub3Jtb3VzIGNvbnRyaWJ1 dGlvbnMgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSB0byB0aGlzDQogICBkb2N1bWVudCBhbmQgYXJl IGdlbmVyYWxseSByZXNwb25zaWJsZSBmb3IgdGhlIHN1Y2Nlc3Mgb2YgbGFuZ3VhZ2UNCiAgIHRh Z3MuDQoNCiAgIFRoZSBmb2xsb3dpbmcgcGVvcGxlIChpbiBhbHBoYWJldGljYWwgb3JkZXIpIGNv bnRyaWJ1dGVkIHRvIHRoaXMNCiAgIGRvY3VtZW50IG9yIHRvIFJGQ3MgMTc2NiBhbmQgMzA2NjoN Cg0KICAgR2xlbm4gQWRhbXMsIEhhcmFsZCBUdmVpdCBBbHZlc3RyYW5kLCBUaW0gQmVybmVycy1M ZWUsIE1hcmMgQmxhbmNoZXQsDQogICBOYXRoYW5pZWwgQm9yZW5zdGVpbiwgRXJpYyBCcnVubmVy LCBTZWFuIE0uIEJ1cmtlLCBNLlQuIENhcnJhc2NvDQogICBCZW5pdGV6LCBKZXJlbXkgQ2Fycm9s bCwgSm9obiBDbGV3cywgSmltIENvbmtsaW4sIFBldGVyIENvbnN0YWJsZSwNCiAgIEpvaG4gQ293 YW4sIE1hcmsgQ3Jpc3BpbiwgRGF2ZSBDcm9ja2VyLCBNYXJ0aW4gRHVlcnN0LCBGcmFuaw0KICAg RWxsZXJtYW4sIE1pY2hhZWwgRXZlcnNvbiwgRG91ZyBFd2VsbCwgTmVkIEZyZWVkLCBUaW0gR29v ZHdpbiwgRGlyay0NCiAgIFdpbGxlbSB2YW4gR3VsaWssIE1hcmlvbiBHdW5uLCBKb2VsIEhhbHBy ZW4sIEVsbGlvdHRlIFJ1c3R5IEhhcm9sZCwNCiAgIFBhdWwgSG9mZm1hbiwgU2NvdHQgSG9sbGVu YmVjaywgUmljaGFyZCBJc2hpZGEsIE9sbGUgSmFybmVmb3JzLCBLZW50DQogICBLYXJsc3Nvbiwg Sm9obiBLbGVuc2luLCBBbGFpbiBMYUJvbnRlLCBFcmljIE1hZGVyLCBJcmEgTWNEb25hbGQsDQog ICBLZWl0aCBNb29yZSwgQ2hyaXMgTmV3bWFuLCBNYXNhdGFrYSBPaHRhLCBSYW5keSBQcmVzdWhu LCBHZW9yZ2UNCiAgIFJob3RlbiwgTWFya3VzIFNjaGVyZXIsIEtlbGQgSm9ybiBTaW1vbnNlbiwg VGhpZXJyeSBTb3VyYmllciwgT3R0bw0KICAgU3RvbHosIFRleCBUZXhpbiwgQW5kcmVhIFZpbmUs IFJoeXMgV2VhdGhlcmxleSwgTWlzaGEgV29sZiwgRnJhbmNvaXMNCiAgIFllcmdlYXUgYW5kIG1h bnksIG1hbnkgb3RoZXJzLg0KDQogICBWZXJ5IHNwZWNpYWwgdGhhbmtzIG11c3QgZ28gdG8gSGFy YWxkIFR2ZWl0IEFsdmVzdHJhbmQsIHdobw0KICAgb3JpZ2luYXRlZCBSRkNzIDE3NjYgYW5kIDMw NjYsIGFuZCB3aXRob3V0IHdob20gdGhpcyBkb2N1bWVudCB3b3VsZA0KICAgbm90IGhhdmUgYmVl biBwb3NzaWJsZS4gIFNwZWNpYWwgdGhhbmtzIG11c3QgZ28gdG8gTWljaGFlbCBFdmVyc29uLA0K ICAgd2hvIGhhcyBzZXJ2ZWQgYXMgbGFuZ3VhZ2UgdGFnIHJldmlld2VyIGZvciBhbG1vc3QgdGhl IGNvbXBsZXRlDQogICBwZXJpb2Qgc2luY2UgdGhlIHB1YmxpY2F0aW9uIG9mIFJGQyAxNzY2LiAg U3BlY2lhbCB0aGFua3MgdG8gRG91Zw0KICAgRXdlbGwsIGZvciBoaXMgcHJvZHVjdGlvbiBvZiB0 aGUgZmlyc3QgY29tcGxldGUgc3VidGFnIHJlZ2lzdHJ5LCBhbmQNCiAgIGhpcyB3b3JrIGluIHBy b2R1Y2luZyBhIHRlc3QgcGFyc2VyIGZvciB2ZXJpZnlpbmcgbGFuZ3VhZ2UgdGFncy4NCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBp cmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA1M10NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXBy aWwgMjAwNQ0KDQoNCkFwcGVuZGl4IEIuICBFeGFtcGxlcyBvZiBMYW5ndWFnZSBUYWdzIChJbmZv cm1hdGl2ZSkNCg0KICAgU2ltcGxlIGxhbmd1YWdlIHN1YnRhZzoNCg0KICAgICAgZGUgKEdlcm1h bikNCg0KICAgICAgZnIgKEZyZW5jaCkNCg0KICAgICAgamEgKEphcGFuZXNlKQ0KDQogICAgICBp LWVub2NoaWFuIChleGFtcGxlIG9mIGEgZ3JhbmRmYXRoZXJlZCB0YWcpDQoNCiAgIExhbmd1YWdl IHN1YnRhZyBwbHVzIFNjcmlwdCBzdWJ0YWc6DQoNCiAgICAgIHpoLUhhbnQgKFRyYWRpdGlvbmFs IENoaW5lc2UpDQoNCiAgICAgIGVuLUxhdG4gKEVuZ2xpc2ggd3JpdHRlbiBpbiBMYXRpbiBzY3Jp cHQpDQoNCiAgICAgIHNyLUN5cmwgKFNlcmJpYW4gd3JpdHRlbiB3aXRoIEN5cmlsbGljIHNjcmlw dCkNCg0KICAgTGFuZ3VhZ2UtU2NyaXB0LVJlZ2lvbjoNCg0KICAgICAgemgtSGFucy1DTiAoU2lt cGxpZmllZCBDaGluZXNlIGZvciB0aGUgUFJDKQ0KDQogICAgICBzci1MYXRuLUNTIChTZXJiaWFu LCBMYXRpbiBzY3JpcHQsIFNlcmJpYSBhbmQgTW9udGVuZWdybykNCg0KICAgTGFuZ3VhZ2UtU2Ny aXB0LVJlZ2lvbi1WYXJpYW50Og0KDQogICAgICBlbi1MYXRuLVVTLWJvb250IChCb29udGxpbmcg ZGlhbGVjdCBvZiBFbmdsaXNoKQ0KDQogICAgICBkZS1MYXRuLUNILTE5OTYgKEdlcm1hbiB3cml0 dGVuIGluIExhdGluIHNjcmlwdCBmb3IgU3dpdHplcmxhbmQNCiAgICAgIHVzaW5nIHRoZSBvcnRo b2dyYXBoeSBvZiAxOTk2KQ0KDQogICBMYW5ndWFnZS1SZWdpb246DQoNCiAgICAgIGRlLURFIChH ZXJtYW4gZm9yIEdlcm1hbnkpDQoNCiAgICAgIHpoLVNHIChDaGluZXNlIGZvciBTaW5nYXBvcmUp DQoNCiAgICAgIGNzLTIwMCAoQ3plY2ggZm9yIEN6ZWNob3Nsb3Zha2lhKQ0KDQogICAgICBzci1D UyAoU2VyYmlhbiBmb3IgU2VyYmlhIGFuZCBNb250ZW5lZ3JvKQ0KDQogICAgICBlcy00MTkgKFNw YW5pc2ggZm9yIExhdGluIEFtZXJpY2EgYW5kIENhcmliYmVhbiByZWdpb24gdXNpbmcgdGhlDQog ICAgICBVTiByZWdpb24gY29kZSkNCg0KICAgT3RoZXIgTWl4dHVyZXM6DQoNCg0KDQoNClBoaWxs aXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwNSAgICAgICAgICAgICAg IFtQYWdlIDU0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lz dHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgICAgZW4tYm9vbnQgKEJvb250 bGluZyBkaWFsZWN0IG9mIEVuZ2xpc2gpDQoNCiAgIHByaXZhdGUtdXNlIG1lY2hhbmlzbToNCg0K ICAgICAgZGUtQ0gteC1waG9uZWJrDQoNCiAgICAgIGF6LUFyYWIteC1BWkUtZGVyYmVuZA0KDQog ICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIChleGFtcGxlcyBPTkxZOiBleHRlbmRlZCBsYW5n dWFnZXMgbXVzdCBiZQ0KICAgZGVmaW5lZCBieSByZXZpc2lvbiBvciB1cGRhdGUgdG8gdGhpcyBk b2N1bWVudCk6DQoNCiAgICAgIHpoLW1pbg0KDQogICAgICB6aC1taW4tbmFuLUhhbnQtQ04NCg0K ICAgUHJpdmF0ZS11c2Ugc3VidGFnczoNCg0KICAgICAgeC13aGF0ZXZlciAocHJpdmF0ZSB1c2Ug dXNpbmcgdGhlIHNpbmdsZXRvbiAneCcpDQoNCiAgICAgIHFhYS1RYWFhLVFNLXgtc291dGhlcm4g KGFsbCBwcml2YXRlIHRhZ3MpDQoNCiAgICAgIGRlLVFhYWEgKEdlcm1hbiwgd2l0aCBhIHByaXZh dGUgc2NyaXB0KQ0KDQogICAgICBkZS1MYXRuLVFNIChHZXJtYW4sIExhdGluLXNjcmlwdCwgcHJp dmF0ZSByZWdpb24pDQoNCiAgICAgIGRlLVFhYWEtREUgKEdlcm1hbiwgcHJpdmF0ZSBzY3JpcHQs IGZvciBHZXJtYW55KQ0KDQogICBUYWdzIHRoYXQgdXNlIGV4dGVuc2lvbnMgKGV4YW1wbGVzIE9O TFk6IGV4dGVuc2lvbnMgbXVzdCBiZSBkZWZpbmVkDQogICBieSByZXZpc2lvbiBvciB1cGRhdGUg dG8gdGhpcyBkb2N1bWVudCBvciBieSBSRkMpOg0KDQogICAgICBlbi1VUy11LWlzbGFtQ2FsDQoN CiAgICAgIHpoLUNOLWEtbXlFeHQteC1wcml2YXRlDQoNCiAgICAgIGVuLWEtbXlFeHQtYi1hbm90 aGVyDQoNCiAgIFNvbWUgSW52YWxpZCBUYWdzOg0KDQogICAgICBkZS00MTktREUgKHR3byByZWdp b24gdGFncykNCg0KICAgICAgYS1ERSAodXNlIG9mIGEgc2luZ2xlIGNoYXJhY3RlciBzdWJ0YWcg aW4gcHJpbWFyeSBwb3NpdGlvbjsgbm90ZQ0KICAgICAgdGhhdCB0aGVyZSBhcmUgYSBmZXcgZ3Jh bmRmYXRoZXJlZCB0YWdzIHRoYXQgc3RhcnQgd2l0aCAiaS0iIHRoYXQNCiAgICAgIGFyZSB2YWxp ZCkNCg0KICAgICAgYXItYS1hYWEtYi1iYmItYS1jY2MgKHR3byBleHRlbnNpb25zIHdpdGggc2Ft ZSBzaW5nbGUgbGV0dGVyDQogICAgICBwcmVmaXgpDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgNTVd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQpBcHBlbmRpeCBDLiAgRXhhbXBsZSBSZWdpc3RyeQ0K DQogICBFeGFtcGxlIFJlZ2lzdHJ5DQoNCiAgICUlDQogICBGaWxlLURhdGU6IDIwMDUtMDQtMTgN CiAgICUlDQogICBUeXBlOiBsYW5ndWFnZQ0KICAgU3VidGFnOiBhYQ0KICAgRGVzY3JpcHRpb246 IEFmYXINCiAgIEFkZGVkOiAyMDA0LTA3LTA2DQogICAlJQ0KICAgVHlwZTogbGFuZ3VhZ2UNCiAg IFN1YnRhZzogYWINCiAgIERlc2NyaXB0aW9uOiBBYmtoYXppYW4NCiAgIEFkZGVkOiAyMDA0LTA3 LTA2DQogICAlJQ0KICAgVHlwZTogbGFuZ3VhZ2UNCiAgIFN1YnRhZzogYWUNCiAgIERlc2NyaXB0 aW9uOiBBdmVzdGFuDQogICBBZGRlZDogMjAwNC0wNy0wNg0KICAgJSUNCiAgIFR5cGU6IGxhbmd1 YWdlDQogICBTdWJ0YWc6IGFyDQogICBEZXNjcmlwdGlvbjogQXJhYmljDQogICBBZGRlZDogMjAw NC0wNy0wNg0KICAgU3VwcHJlc3MtU2NyaXB0OiBBcmFiDQogICBDb21tZW50OiBBcmFiaWMgdGV4 dCBpcyB1c3VhbGx5IHdyaXR0ZW4gaW4gQXJhYmljIHNjcmlwdA0KICAgJSUNCiAgIFR5cGU6IGxh bmd1YWdlDQogICBTdWJ0YWc6IHFhYS4ucXR6DQogICBEZXNjcmlwdGlvbjogUFJJVkFURSBVU0UN CiAgIEFkZGVkOiAyMDA0LTA4LTAxDQogICBDb21tZW50OiBVc2UgcHJpdmF0ZSB1c2UgY29kZXMg aW4gcHJlZmVyZW5jZQ0KICAgICB0byB0aGUgeC0gc2luZ2xldG9uIGZvciBwcmltYXJ5IGxhbmd1 YWdlDQogICBDb21tZW50OiBUaGlzIGlzIGFuIGV4YW1wbGUgb2YgdHdvIGNvbW1lbnRzLg0KICAg JSUNCiAgIFR5cGU6IHNjcmlwdA0KICAgU3VidGFnOiBBcmFiDQogICBEZXNjcmlwdGlvbjogQXJh YmljDQogICBBZGRlZDogMjAwNC0wNy0wNg0KICAgJSUNCiAgIFR5cGU6IHNjcmlwdA0KICAgU3Vi dGFnOiBBcm1uDQogICBEZXNjcmlwdGlvbjogQXJtZW5pYW4NCiAgIEFkZGVkOiAyMDA0LTA3LTA2 DQogICAlJQ0KICAgVHlwZTogc2NyaXB0DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA1Nl0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg QXByaWwgMjAwNQ0KDQoNCiAgIFN1YnRhZzogQmFsaQ0KICAgRGVzY3JpcHRpb246IEJhbGluZXNl DQogICBBZGRlZDogMjAwNC0wNy0wNg0KICAgJSUNCiAgIFR5cGU6IHNjcmlwdA0KICAgU3VidGFn OiBCYXRrDQogICBEZXNjcmlwdGlvbjogQmF0YWsNCiAgIEFkZGVkOiAyMDA0LTA3LTA2DQogICAl JQ0KICAgVHlwZTogcmVnaW9uDQogICBTdWJ0YWc6IEFBDQogICBEZXNjcmlwdGlvbjogUFJJVkFU RSBVU0UNCiAgIEFkZGVkOiAyMDA0LTA4LTAxDQogICAlJQ0KICAgVHlwZTogcmVnaW9uDQogICBT dWJ0YWc6IEFEDQogICBEZXNjcmlwdGlvbjogQW5kb3JyYQ0KICAgQWRkZWQ6IDIwMDQtMDctMDYN CiAgICUlDQogICBUeXBlOiByZWdpb24NCiAgIFN1YnRhZzogQUUNCiAgIERlc2NyaXB0aW9uOiBV bml0ZWQgQXJhYiBFbWlyYXRlcw0KICAgQWRkZWQ6IDIwMDQtMDctMDYNCiAgICUlDQogICBUeXBl OiByZWdpb24NCiAgIFN1YnRhZzogQVgNCiAgIERlc2NyaXB0aW9uOiAmI3hDNTtsYW5kIElzbGFu ZHMNCiAgIEFkZGVkOiAyMDA0LTA3LTA2DQogICBDb21tZW50czogVGhlIGRlc2NyaXB0aW9uIHNo b3dzIGEgVW5pY29kZSBlc2NhcGUNCiAgICAgZm9yIHRoZSBsZXR0ZXIgQS1yaW5nLg0KICAgJSUN CiAgIFR5cGU6IHJlZ2lvbg0KICAgU3VidGFnOiAwMDENCiAgIERlc2NyaXB0aW9uOiBXb3JsZA0K ICAgQWRkZWQ6IDIwMDQtMDctMDYNCiAgICUlDQogICBUeXBlOiByZWdpb24NCiAgIFN1YnRhZzog MDAyDQogICBEZXNjcmlwdGlvbjogQWZyaWNhDQogICBBZGRlZDogMjAwNC0wNy0wNg0KICAgJSUN CiAgIFR5cGU6IHJlZ2lvbg0KICAgU3VidGFnOiAwMDMNCiAgIERlc2NyaXB0aW9uOiBOb3J0aCBB bWVyaWNhDQogICBBZGRlZDogMjAwNC0wNy0wNg0KICAgJSUNCiAgIFR5cGU6IHZhcmlhbnQNCiAg IFN1YnRhZzogMTkwMQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3Rv YmVyIDIyLCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgNTddDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUN Cg0KDQogICBEZXNjcmlwdGlvbjogVHJhZGl0aW9uYWwgR2VybWFuDQogICAgICBvcnRob2dyYXBo eQ0KICAgQWRkZWQ6IDIwMDQtMDktMDkNCiAgIFJlY29tbWVuZGVkLVByZWZpeDogZGUNCiAgIENv bW1lbnQ6IDxzaG93cyBjb250aW51YXRpb24+DQogICAlJQ0KICAgVHlwZTogdmFyaWFudA0KICAg U3VidGFnOiAxOTk2DQogICBEZXNjcmlwdGlvbjogR2VybWFuIG9ydGhvZ3JhcGh5IG9mIDE5OTYN CiAgIEFkZGVkOiAyMDA0LTA5LTA5DQogICBSZWNvbW1lbmRlZC1QcmVmaXg6IGRlDQogICAlJQ0K ICAgVHlwZTogdmFyaWFudA0KICAgU3VidGFnOiBib29udA0KICAgRGVzY3JpcHRpb246IEJvb250 bGluZw0KICAgQWRkZWQ6IDIwMDMtMDItMTQNCiAgIFJlY29tbWVuZGVkLVByZWZpeDogZW4NCiAg ICUlDQogICBUeXBlOiB2YXJpYW50DQogICBTdWJ0YWc6IGdhdWxpc2gNCiAgIERlc2NyaXB0aW9u OiBHYXVsaXNoDQogICBBZGRlZDogMjAwMS0wNS0yNQ0KICAgUmVjb21tZW5kZWQtUHJlZml4OiBj ZWwNCiAgICUlDQogICBUeXBlOiBncmFuZGZhdGhlcmVkDQogICBUYWc6IGFydC1sb2piYW4NCiAg IERlc2NyaXB0aW9uOiBMb2piYW4NCiAgIEFkZGVkOiAyMDAxLTExLTExDQogICBDYW5vbmljYWw6 IGpibw0KICAgRGVwcmVjYXRlZDogMjAwMy0wOS0wMg0KICAgJSUNCiAgIFR5cGU6IGdyYW5kZmF0 aGVyZWQNCiAgIFRhZzogZW4tR0Itb2VkDQogICBEZXNjcmlwdGlvbjogRW5nbGlzaCwgT3hmb3Jk IEVuZ2xpc2ggRGljdGlvbmFyeSBzcGVsbGluZw0KICAgQWRkZWQ6IDIwMDMtMDctMDkNCiAgICUl DQogICBUeXBlOiBncmFuZGZhdGhlcmVkDQogICBUYWc6IGktYW1pDQogICBEZXNjcmlwdGlvbjog J0FtaXMNCiAgIEFkZGVkOiAxOTk5LTA1LTI1DQogICAlJQ0KICAgVHlwZTogZ3JhbmRmYXRoZXJl ZA0KICAgVGFnOiBpLWJubg0KICAgRGVzY3JpcHRpb246IEJ1bnVuDQogICBBZGRlZDogMTk5OS0w NS0yNQ0KICAgJSUNCiAgIFR5cGU6IHJlZHVuZGFudA0KICAgVGFnOiBhei1BcmFiDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjIsIDIwMDUgICAgICAgICAg ICAgICBbUGFnZSA1OF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIERlc2NyaXB0aW9uOiBB emVyYmFpamFuaSBpbiBBcmFiaWMgc2NyaXB0DQogICBBZGRlZDogMjAwMy0wNS0zMA0KICAgQ29t bWVudDogdXNlIGxhbmd1YWdlIGF6ICsgc2NyaXB0IEFyYWINCiAgICUlDQogICBUeXBlOiByZWR1 bmRhbnQNCiAgIFRhZzogYXotQ3lybA0KICAgRGVzY3JpcHRpb246IEF6ZXJiYWlqYW5pIGluIEN5 cmlsbGljIHNjcmlwdA0KICAgQWRkZWQ6IDIwMDMtMDUtMzANCiAgIENvbW1lbnQ6IHVzZSBsYW5n dWFnZSBheiArIHNjcmlwdCBDeXJsDQogICAlJQ0KDQogICAgICAgICAgICAgICAgIEZpZ3VyZSA3 OiBFeGFtcGxlIG9mIHRoZSBSZWdpc3RyeSBGb3JtYXQNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBo aWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyMiwgMjAwNSAgICAgICAgICAg ICAgIFtQYWdlIDU5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJl Z2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KSW50ZWxsZWN0dWFsIFByb3Bl cnR5IFN0YXRlbWVudA0KDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcg dGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJp Z2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICBwZXJ0YWlu IHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVk IGluDQogICB0aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vuc2Ug dW5kZXIgc3VjaCByaWdodHMNCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5v ciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcw0KICAgbWFkZSBhbnkgaW5kZXBlbmRlbnQg ZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0cy4gIEluZm9ybWF0aW9uDQogICBvbiB0 aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2Fu IGJlDQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4NCg0KICAgQ29waWVzIG9mIElQUiBk aXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkNCiAgIGFzc3Vy YW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2Yg YW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlz c2lvbiBmb3IgdGhlIHVzZSBvZg0KICAgc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVt ZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVk IGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0KICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkg dG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMgb3Ig cGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkNCiAgIHJpZ2h0cyB0aGF0 IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudA0K ICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUg SUVURiBhdA0KICAgaWV0Zi1pcHJAaWV0Zi5vcmcuDQoNCg0KRGlzY2xhaW1lciBvZiBWYWxpZGl0 eQ0KDQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVp biBhcmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRP UiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0KICAgT1IgSVMgU1BPTlNPUkVE IEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUDQogICBF TkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9S IElNUExJRUQsDQogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBU SEFUIFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklO R0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFC SUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KQ29weXJpZ2h0 IFN0YXRlbWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA1 KS4gIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdA0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMg YW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQNCiAgIGV4Y2VwdCBhcyBz ZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDQoN Cg0KQWNrbm93bGVkZ21lbnQNCg0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rp b24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQ0KICAgSW50ZXJuZXQgU29jaWV0eS4NCg0K DQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDIyLCAyMDA1ICAg ICAgICAgICAgICAgW1BhZ2UgNjBdDQoMDQo= ------_=_NextPart_001_01C549C7.7E87DA77 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C549C7.7E87DA77-- From ltru-bounces@lists.ietf.org Mon Apr 25 19:58:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQDSm-0005GV-Kn; Mon, 25 Apr 2005 19:58:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPw8C-0006M7-3F for ltru@megatron.ietf.org; Mon, 25 Apr 2005 01:27:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21959 for ; Mon, 25 Apr 2005 01:27:38 -0400 (EDT) Received: from ore.jhcloos.com ([64.240.156.239]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPwKM-0004OB-DT for ltru@ietf.org; Mon, 25 Apr 2005 01:40:15 -0400 Received: from lugabout.jhcloos.org (host-69-48-15-97.roc.choiceone.net [69.48.15.97]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "lugabout.jhcloos.org", Issuer "ca.jhcloos.com" (verified OK)) by ore.jhcloos.com (Postfix) with ESMTP id 795731C90F for ; Mon, 25 Apr 2005 00:27:24 -0500 (CDT) Received: by lugabout.jhcloos.org (Postfix, from userid 500) id B59BD4D42FB; Mon, 25 Apr 2005 05:27:11 +0000 (GMT) To: ltru@ietf.org From: James Cloos In-Reply-To: <426AF2EA.4BB2@xyzzy.claranet.de> (Frank Ellermann's message of "Sun, 24 Apr 2005 03:14:18 +0200") References: <20050420160557.UOZB4900.mta8.adelphia.net@megatron.ietf.org> <01a101c54848$ed01f1e0$030aa8c0@DEWELL> <426AF2EA.4BB2@xyzzy.claranet.de> X-Hashcash: 1:21:050425:ltru@ietf.org::88OxOQLnFzXa6adG:00004NjQ Date: Mon, 25 Apr 2005 01:27:11 -0400 Message-ID: Lines: 35 User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Spam-Score: 2.9 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id BAA21959 X-Mailman-Approved-At: Mon, 25 Apr 2005 19:58:03 -0400 Cc: Subject: [Ltru] Re: hyphen-minus X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org >>>>> "Frank" =3D=3D Frank Ellermann writes: Commenting just on the 10646 choices here, not on the use of 8859-1 in lieu of 10646.... >> Ge=E2=80=98ez --> Ge'ez Frank> better use ‘ LEFT SINGLE QUOTATION MARK If that is a glottal stop, =C3=A0la Hawai=CA=BBian=E2=80=99s =CA=BBokina,= it should really be U+02BB MODIFIER LETTER TURNED COMMA rather than U+2018. Even if not, is it still the case that U+02BB is a letter whereas U+2018 is punctuation.... >> N=E2=80=99ko --> N'ko Frank> better use ’ RIGHT SINGLE QUOTATION MARK Same argument as above, but using U+02BC MODIFIER LETTER APOSTROPHE for N=CA=BCko. >> Gwich=C2=B4in --> Gwich'in Frank> better use ´ ACUTE ACCENT That one is confusing. If you are going to use 10646 there must be a better choice than a spacing acute accent.... 8859-1 is probably better right now for interoperability. If 10646 is used then every effort should be made to use the best characters even if homographs may be easier to enter on many (most?) keyboards. -JimC --=20 James H. Cloos, Jr. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 25 21:00:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQERM-0006Iv-M0; Mon, 25 Apr 2005 21:00:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQERK-0006IO-6Y for ltru@megatron.ietf.org; Mon, 25 Apr 2005 21:00:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16876 for ; Mon, 25 Apr 2005 21:00:34 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQEdb-0002ZZ-VY for ltru@ietf.org; Mon, 25 Apr 2005 21:13:22 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j3Q10J721920; Tue, 26 Apr 2005 10:00:19 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id c80c51b8_b5ef_11d9_982d_0030482532aa_21841; Tue, 26 Apr 2005 10:09:04 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO003F8D; 26 Apr 05 10:02:09 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 26 Apr 05 10:01:46 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.52) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG003F8B; 26 Apr 05 10:01:35 +0900 Message-Id: <6.0.0.20.2.20050426095506.07b430e0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 26 Apr 2005 09:57:59 +0900 To: "Addison Phillips" , "Randy Presuhn" From: Martin Duerst In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B20A2D5@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0B20A2D5@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ltru Working Group Subject: [Ltru] Re: (need approval) Working Group submission: LTRU registry draft-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hello Addison, At 03:49 05/04/26, Addison Phillips wrote: >Randy and Martin, > >Please approve my submitting the current editor's copy (attached) as >draft-01 by responding to this email. Please go ahead and submit the draft. There have been a lot of edits since -00, and it's always better to have a published draft at the official site to look at than a copy somewhere on the net. >I will submit the new draft over a copy of the response. I'm not sure I understand this sentence. Did you want to say that you will submit it as soon as you get a response? Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 25 21:24:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQEoq-0001PF-QV; Mon, 25 Apr 2005 21:24:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQEop-0001PA-Mj for ltru@megatron.ietf.org; Mon, 25 Apr 2005 21:24:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18504 for ; Mon, 25 Apr 2005 21:24:53 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQF1A-0003LE-PD for ltru@ietf.org; Mon, 25 Apr 2005 21:37:42 -0400 Received: from lns-p19-2-idf-82-251-127-245.adsl.proxad.net ([82.251.127.245] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DQEog-0007dP-Sv; Mon, 25 Apr 2005 18:24:47 -0700 Message-Id: <6.2.1.2.2.20050426005556.03530830@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 26 Apr 2005 01:34:04 +0200 To: "Randy Presuhn" , "Martin Duerst" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] (need approval) Working Group submission: LTRU registry draft-01 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0B20A2D5@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0B20A2D5@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear co-Chairs, I am interested to know if you plan to start a debate on the points of the Charter Randy described as thorny and to discuss the points in my Review of the Draft as announced also by Randy. I must wait for these debates to get the positions of this WG on all these points before: - either writing my own announced Draft to be as near as possible of a consensus, since I put myself in priority in the perspective of the WG Charter rather than in the continuity of a text which failed twice. This text could be an appropriate fix to the explained XML difficulty, but not a BCP 047 on Internet language tags framework. - or accept the changes resulting from this debate as consensual. I note that the points of disagreement are those who lead to the lack of consensus during the last Last Call. They are mainly the point above and the organisation of the ietf-languages list which is one of the key Charter point which has never been discussed yet. The organisation and the load for the IANA also never got any response. But all this is in my review. As explained to Frank we started to write a Draft earlier and waited for this debate. Now I am quite busy. - If you plan this debate I will still wait for it, I will make my delayed home work as I can, and I will call for an extra 15 days after I submitted my own Draft to have it reviewed. - If you do not plan to have these debates, I will be less dependent on the calendar of this WG to introduce a totally independent Draft. It will then get discussed on the general list during the last call, I presume? Please advise. jfc At 20:49 25/04/2005, Addison Phillips wrote: >Randy and Martin, > >Please approve my submitting the current editor's copy (attached) as >draft-01 by responding to this email. I will submit the new draft over a >copy of the response. > >Then we can proceed to wipe up any remaining issues, hopefully for a >timely last call. > >Addison > >Addison P. Phillips >Globalization Architect, Quest Software >http://www.quest.com > >Chair, W3C Internationalization Core Working Group >http://www.w3.org/International > >Internationalization is not a feature. >It is an architecture. > > > >_______________________________________________ >Ltru mailing list >Ltru@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 25 23:22:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQGeg-0008F3-GJ; Mon, 25 Apr 2005 23:22:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQGee-0008EH-Rw for ltru@megatron.ietf.org; Mon, 25 Apr 2005 23:22:33 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27828 for ; Mon, 25 Apr 2005 23:22:28 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DQGZA-0004ld-NZ for ltru@lists.ietf.org; Tue, 26 Apr 2005 05:16:52 +0200 Received: from 212.82.251.171 ([212.82.251.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Apr 2005 05:16:52 +0200 Received: from nobody by 212.82.251.171 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Apr 2005 05:16:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 26 Apr 2005 05:13:04 +0200 Organization: Lines: 111 Message-ID: <426DB1C0.3B55@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.171 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] -01 nits X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, some observations in draft -01 in no particular order: * [7] (Unicode 4) is not used. Please delete this normative reference, [6] is good enough. * In chapter 2.1 "UTF-16LE" is not explained. Please add [RfC 2781] as informative reference. * [13] (IETF-ICANN MoU about IANA) Please delete this "normative" reference to an MoU-FYI. Maybe use [RfC 2028] (BCP 11) as a reference to explain "IANA", you already have it as [10] elsewhere. * [16] (RfC 3978) is not used. Please delete this normative reference, the boilerplates work without it. * In chapter 3.1 replace the URL of XML 1.0 3rd ed. by the generic URL of the latest XML 1.0 edition. * Several "2-character code", "3-character code", "4-character subtags": Using "alpha-2 code" etc. would be clearer and shorter where the ABNF dictates 2ALPHA etc. * There's still a *("-" extlang) in the ABNF, it should be at most one ["-" extlang]. * In chapter 2.1.1: "In practice, this limits most tags to a sequence of four subtags, and thus a length of 35 (excluding any extensions": This limit is 8+(1+4)+(1+3)+(1+8)= 26 without extlang and 4 subtags. With extlang it's only 25 = 3+(1+3)+(1+4)+(2+3)+(1+8). * In chapter 2.1.1: "Any such limitation MUST be clearly documented, and such documentation SHOULD include the disposition of any longer tags (for example, whether an error value is generated or the language tag is truncated). If truncation is permitted it SHOULD NOT permit a subtag to be divided." Proposed new text: "Any limitation SHOULD be clearly documented. Tags SHOULD NOT be truncated, but removing complete subtags right to left MAY be permitted." * In chapter 2.2.1: 7. The single character subtag 'i' is used by some grandfathered tags (see Section 2.2.8) such as "i-klingon" and "i-bnn". Please replace the "almost" deprecated i-klingon by i-default. * In chapter 2.2.2: Please replace all "subtags" by "subtag". Please remove "3. There MAY be any additional number of extended language subtags." At most one extlang, otherwise it doesn't fly with RfC 2231 / 2047. * In chapter 2.2.7: "Users who wished to utilize SIL Ethnologue". Please delete this example, it muddies the water for ISO 639-3. * The ABNF layout in 3.1 is ugly, the main ABNF is better, please use the same xml2rfc trick (artwork ?) as in 2.1: registry = record *( "%%" CRLF record ) record = 1*( field-name *SP ":" *SP field-body CRLF ) field-name = 1*( ALPHA / DIGIT / "-" ) field-body = *( ASC-char / LWSP ) ASC-char = %x21-25 / %x27-7E / UNI-char ; AMPERSAND is %x26 UNI-char = "&#x" 2*6HEXDIG ";" This fixes the reported "no %% in the first / last line" problem. The minimal length of a field-name should be one, not zero. It also replaces the undefined NUM by DIGIT, and %x2D by "-". In theory a field-name starting or ending with a "-" would be a bad idea, and a DIGIT in a field-name is also strange, but OTOH we don't want to reinvent "ldh-string" for a known set of names. * Please delete the File-Date example or get rid of the first "%%": %% File-Date: 2004-06-28 %% * Another proposal for the registry ABNF: registry = record *( "%%" CRLF record ) record = 1*( field CRLF ) field = type / timestamp / reference / explanation type = ( subtagttype / tagtype ) 1*SP tagtext subtagtype = "Language:" / "Extlang:" / "Script:" / "Region:" / "Variant:" tagtype = "Grandfathered:" / "Redundant:" timestamp = ( "File-Date:" / "Added:" / "Deprecated:" ) 1*SP date reference = ( "Canonical:" / "Suppress-Script:" / "Recommended-Prefix:" ) 1*SP tagtext explanation = ( "Description:" / "Comment:" ) 1*SP text date = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; see RfC 3339 tagtext = 1*( ALPHA / DIGIT / "-" ) ; note no WSP text = *SP ":" *( ASC-char / LWSP ) ; note folding WSP ASC-char = %x21-25 / %x27-7E / UNI-char ; AMPERSAND is %x26 UNI-char = "&#x" 2*6HEXDIG ";" This is quite different from the old ABNF, no more SP before the COLON, at least one SP after the COLON, no "folding" for a date or tagtext, "folding" only for a (long) Description: or a Comment:, no UNI-char or special char in tagtext, a date syntax that needs no further explanation (one example will do). Based on this ABNF chapter 3.1 could be much shorter and clearer. It's not more necessary to dig through 3.1 to find all field names. IMHO you could submit snapshots of complete drafts more often, and you also don't need Randy or Martin for a future -02, etc. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 25 23:36:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQGsC-0001MM-SA; Mon, 25 Apr 2005 23:36:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQGsA-0001MH-PQ for ltru@megatron.ietf.org; Mon, 25 Apr 2005 23:36:30 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28897 for ; Mon, 25 Apr 2005 23:36:27 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DQGmi-0006HF-5Z for ltru@lists.ietf.org; Tue, 26 Apr 2005 05:30:52 +0200 Received: from 212.82.251.171 ([212.82.251.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Apr 2005 05:30:52 +0200 Received: from nobody by 212.82.251.171 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Apr 2005 05:30:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 26 Apr 2005 05:35:32 +0200 Organization: Lines: 14 Message-ID: <426DB704.3A96@xyzzy.claranet.de> References: <20050420160557.UOZB4900.mta8.adelphia.net@megatron.ietf.org> <01a101c54848$ed01f1e0$030aa8c0@DEWELL> <426AF2EA.4BB2@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.171 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: hyphen-minus X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org James Cloos wrote: > If 10646 is used then every effort should be made to use > the best characters The ISO sources use Unicode, they should fix what you noted. If Doug or the tag reviewer try to patch descriptions found in the official sources they'd be in a bad position. Okay, they wouldn't try decode invalid UTF-8 encodings, so there is some leeway, but IMHO replacing u+2018 / u+2019 by your proposals u+2BB / u+2BC is the job of ISO. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Apr 25 23:48:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQH3t-0003FW-Mv; Mon, 25 Apr 2005 23:48:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQH3s-0003F5-Bf for ltru@megatron.ietf.org; Mon, 25 Apr 2005 23:48:36 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29966 for ; Mon, 25 Apr 2005 23:48:32 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DQGyf-0000Uw-WB for ltru@lists.ietf.org; Tue, 26 Apr 2005 05:43:14 +0200 Received: from 212.82.251.171 ([212.82.251.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Apr 2005 05:43:13 +0200 Received: from nobody by 212.82.251.171 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Apr 2005 05:43:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 26 Apr 2005 05:47:58 +0200 Organization: Lines: 12 Message-ID: <426DB9EE.2DE6@xyzzy.claranet.de> References: <426DB1C0.3B55@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.171 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: -01 nits X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Sorry, an error in the proposed registry ABNF: > explanation = ( "Description:" / "Comment:" ) 1*SP text > date = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; see RfC 3339 > tagtext = 1*( ALPHA / DIGIT / "-" ) ; note no WSP > text = *SP ":" *( ASC-char / LWSP ) ; note folding WSP | text = *( ASC-char / LWSP ) I wasn't sure where to get rid of the *SP ":" *SP, and forgot to update the "text" of my first attempts. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 01:31:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQIfC-0007Y1-Hc; Tue, 26 Apr 2005 01:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQIfA-0007Xw-Rm for ltru@megatron.ietf.org; Tue, 26 Apr 2005 01:31:12 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09404 for ; Tue, 26 Apr 2005 01:31:11 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050426053041.EISI4191.mta13.adelphia.net@DEWELL> for ; Tue, 26 Apr 2005 01:30:41 -0400 Message-ID: <00b901c54a1f$13e2cf00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050425160433.TWNU28811.mta8.adelphia.net@megatron.ietf.org> Date: Mon, 25 Apr 2005 22:16:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id BAA09404 Cc: Subject: [Ltru] Re: hyphen-minus X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org James Cloos wrote: > If that is a glottal stop, =C3=A0la Hawai=CA=BBian=E2=80=99s =CA=BBokin= a, it should really > be U+02BB MODIFIER LETTER TURNED COMMA rather than U+2018. Even if > not, is it still the case that U+02BB is a letter whereas U+2018 is > punctuation.... > ... > Same argument as above, but using U+02BC MODIFIER LETTER APOSTROPHE > for N=CA=BCko. I completely agree with Frank that we are not in a position to correct the standards' use of Unicode, even if we know we are right. We only have two justifiable courses of action here: 1. accept what the underlying standard has, or 2. reduce it to ASCII or Latin-1. >>> Gwich=C2=B4in --> Gwich'in > > Frank> better use ´ ACUTE ACCENT > > That one is confusing. If you are going to use 10646 there must be > a better choice than a spacing acute accent.... There are tons of better choices. U+00B4 is not even an apostrophe, and if an acute accent is desired (over an h?) then it should be U+0301. I was willing to correct this to the vanilla apostrophe U+0027, but Frank's suggestion to leave all of these alone is probably more defensible. > 8859-1 is probably better right now for interoperability. If 10646 > is used then every effort should be made to use the best characters > even if homographs may be easier to enter on many (most?) keyboards. I appreciate your input, James. Anyone else? -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 03:34:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQKan-0007ME-47; Tue, 26 Apr 2005 03:34:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQKak-0007M9-Th for ltru@megatron.ietf.org; Tue, 26 Apr 2005 03:34:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09705 for ; Tue, 26 Apr 2005 03:34:43 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQKn4-000451-J6 for ltru@ietf.org; Tue, 26 Apr 2005 03:47:34 -0400 Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j3Q7YRm15961; Tue, 26 Apr 2005 16:34:27 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id a2771f6a_b625_11d9_96cc_0030482533a1_29342; Tue, 26 Apr 2005 16:34:33 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0040A4; 26 Apr 05 16:36:18 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 26 Apr 05 16:36:02 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.52) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG00409E; 26 Apr 05 16:35:58 +0900 Message-Id: <6.0.0.20.2.20050426161845.07b1f4b0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 26 Apr 2005 16:30:51 +0900 To: Frank Ellermann , ltru@ietf.org From: Martin Duerst In-Reply-To: <426DB1C0.3B55@xyzzy.claranet.de> References: <426DB1C0.3B55@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Submitting Drafts (was: Re: -01 nits) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 12:13 05/04/26, Frank Ellermann wrote: >Hi, some observations in draft -01 in no particular order: >IMHO you could submit snapshots of complete drafts more often, Very much so, please. The closer we get to final, the more drafts, at least in general. >and you also don't need Randy or Martin for a future -02, etc. Not unless it's supposed to be a last call draft, or there is otherwise some thorny issue (that absolutely needs to be solved for publishing the draft). Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 10:27:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQR1l-0004h1-Hf; Tue, 26 Apr 2005 10:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQR1j-0004fX-Ib for ltru@megatron.ietf.org; Tue, 26 Apr 2005 10:27:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12791 for ; Tue, 26 Apr 2005 10:26:59 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DQRE8-0005dp-6X for ltru@ietf.org; Tue, 26 Apr 2005 10:39:53 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 26 Apr 2005 15:06:26 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 15:06:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Apr 2005 15:06:25 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A5DF@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: Off Topic (was Re: [Ltru] Great Script Debate Part II: Formats...) Thread-Index: AcVBBxo/4xomo0PDR+usmvSs/1N0ggJYjokw From: "L.Gillam" To: ltru X-OriginalArrivalTime: 26 Apr 2005 14:06:25.0354 (UTC) FILETIME=[2211CAA0:01C54A69] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Ltru] ISO 3166-1 DIS ballot X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0198644422==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0198644422== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQpXaXRoIGRpc2N1c3Npb24gb2YgY291bnRyeSBjb2RlcywgSSBjYW4ndCByZW1lbWJlciBpZiBh bnlib2R5IGhhZCBicm91Z2h0IHRoZSBESVMgYmFsbG90IG9uIDMxNjYgdGhhdCBiZWdhbiAyMDA1 LTAyLTI0IGFuZCB3aWxsIHRlcm1pbmF0ZSAyMDA1LTA3LTI0IHRvIHRoZSBhdHRlbnRpb24gb2Yg dGhlIFdHLiBJIGFzayBvbmx5IGJlY2F1c2UgdGhlIGRvY3VtZW50IGhhcyBqdXN0IGNvbWUgdG8g bXkgYXR0ZW50aW9uIC8gaW50byBteSBwb3NzZXNzaW9uLiBJZiBJIHNpbXBseSBtaXNzZWQgaXQg aW4gdGhlIGhpYXR1cywgSSdsbCBxdWlldGx5IGNyYXdsIGJhY2sgdW5kZXIgbXkgcGFwZXJ3b3Jr Lg0K --===============0198644422== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --===============0198644422==-- From ltru-bounces@lists.ietf.org Tue Apr 26 10:30:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQR5P-00050M-CF; Tue, 26 Apr 2005 10:30:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQR5N-00050H-HT for ltru@megatron.ietf.org; Tue, 26 Apr 2005 10:30:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13004 for ; Tue, 26 Apr 2005 10:30:47 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQRHp-0005iW-Fe for ltru@ietf.org; Tue, 26 Apr 2005 10:43:42 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3QEUacV029960; Tue, 26 Apr 2005 10:30:38 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 26 Apr 2005 10:30:33 -0400 Date: Tue, 26 Apr 2005 10:30:33 -0400 From: John Cowan To: "L.Gillam" Subject: Re: [Ltru] ISO 3166-1 DIS ballot Message-ID: <20050426143033.GH15123@skunk.reutershealth.com> References: <4A7C6FA2AB31194E80E13FE585F6A21292A5DF@EVS-EC1-NODE1.surrey.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A7C6FA2AB31194E80E13FE585F6A21292A5DF@EVS-EC1-NODE1.surrey.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org L.Gillam scripsit: > > With discussion of country codes, I can't remember if anybody had > brought the DIS ballot on 3166 that began 2005-02-24 and will terminate > 2005-07-24 to the attention of the WG. I don't think so, no. This is the version that sets the 50-year lower limit for code reuse? -- John Cowan www.reutershealth.com www.ccil.org/~cowan jcowan@reutershealth.com The Penguin shall hunt and devour all that is crufty, gnarly and bogacious; all code which wriggles like spaghetti, or is infested with blighting creatures, or is bound by grave and perilous Licences shall it capture. And in capturing shall it replicate, and in replicating shall it document, and in documentation shall it bring freedom, serenity and most cool froodiness to the earth and all who code therein. --Gospel of Tux _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 11:07:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQReQ-0000rJ-DI; Tue, 26 Apr 2005 11:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQReO-0000qV-NH for ltru@megatron.ietf.org; Tue, 26 Apr 2005 11:07:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15928 for ; Tue, 26 Apr 2005 11:06:58 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DQRqq-0006lT-Nt for ltru@ietf.org; Tue, 26 Apr 2005 11:19:54 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Tue, 26 Apr 2005 15:53:01 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 15:53:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] ISO 3166-1 DIS ballot Date: Tue, 26 Apr 2005 15:53:00 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A21292A5EA@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] ISO 3166-1 DIS ballot Thread-Index: AcVKbnr2ewzxCc0jSOu3bLi3qg7C5QAASbZw From: "L.Gillam" To: ltru X-OriginalArrivalTime: 26 Apr 2005 14:53:00.0882 (UTC) FILETIME=[A4558320:01C54A6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Something like that........ 7.5.2 Reallocation period=20 Code elements that the ISO 3166/MA has altered or deleted should not be reallocated during a period of at least fifty years after the change. The exact period is determined in each case on the basis of the importance of the extent to which the former code element was used. 7.5.2 Codets r=E9serv=E9s pour une dur=E9e d=E9termin=E9e Les codets qui ont =E9t=E9 modifi=E9s ou supprim=E9s par l'ISO 3166/MA ne doivent pas =EAtre r=E9attribu=E9s pendant cinquante ans au moins =E0 partir du changement. La p=E9riode exacte est d=E9termin=E9e, dans chaque cas, selon l'importance de l'usage de l'ancien codet. 7.5.3 Period of non-use=20 Certain code elements existing at the time of the first publication of the ISO 3166 country codes and differing from those in this part of ISO 3166 should not be used for an indeterminate period to represent other country names. This provision applies to certain vehicle designations notified under the 1949 and 1968 Conventions on Road Traffic (see Bibliography). Code elements to which this provision applies should be included in the list of reserved code elements (see 7.5.6) and should not be reallocated during a period of at least fifty years after the date when the countries or organizations concerned have discontinued their use. 7.5.3 P=E9riode de non-usage Certains codets utilis=E9s au moment de la premi=E8re publication de l'ISO 3166, mais qui diff=E8rent de ceux figurant dans la pr=E9sente partie de l'ISO 3166, ne doivent pas =EAtre utilis=E9s pour repr=E9senter d'autres pays, et ce, pour une dur=E9e ind=E9termin=E9e. Ceci s'applique =E0 certaines d=E9signations de v=E9hicules notifi=E9s dans les Conventions sur la Circulation Routi=E8re (1949 et 1968; voir la Bibliographie). Les codets auxquels s'applique cette r=E9serve doivent =EAtre introduits dans la liste des codets r=E9serv=E9s (voir 7.5.6) et ne pas =EAtre r=E9allou=E9es pendant une p=E9riode d'au moibs cinquante ans apr=E8s la date =E0 laquelle les pays ou organisations ont cess=E9 de les utiliser > -----Original Message----- > From: John Cowan [mailto:jcowan@reutershealth.com] > Sent: 26 April 2005 15:31 > To: Gillam L Dr (Computing) > Cc: ltru@ietf.org > Subject: Re: [Ltru] ISO 3166-1 DIS ballot >=20 >=20 > L.Gillam scripsit: > >=20 > > With discussion of country codes, I can't remember if anybody had > > brought the DIS ballot on 3166 that began 2005-02-24 and=20 > will terminate > > 2005-07-24 to the attention of the WG.=20 >=20 > I don't think so, no. This is the version that sets the 50-year lower > limit for code reuse? >=20 > --=20 > John Cowan www.reutershealth.com www.ccil.org/~cowan =20 > jcowan@reutershealth.com > The Penguin shall hunt and devour all that is crufty, gnarly and > bogacious; all code which wriggles like spaghetti, or is infested with > blighting creatures, or is bound by grave and perilous=20 > Licences shall it > capture. And in capturing shall it replicate, and in=20 > replicating shall > it document, and in documentation shall it bring freedom, serenity and > most cool froodiness to the earth and all who code therein. =20 > --Gospel of Tux >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 11:12:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQRk1-0001Q9-Ea; Tue, 26 Apr 2005 11:12:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQRjz-0001Q1-Oq for ltru@megatron.ietf.org; Tue, 26 Apr 2005 11:12:47 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16682 for ; Tue, 26 Apr 2005 11:12:45 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050426151215.XEOD8952.mta9.adelphia.net@DEWELL> for ; Tue, 26 Apr 2005 11:12:15 -0400 Message-ID: <003e01c54a72$4aa9db20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050426142914.YBAL27459.mta2.adelphia.net@megatron.ietf.org> Date: Tue, 26 Apr 2005 08:11:57 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: -01 nits X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > * There's still a *("-" extlang) in the ABNF, it should be at most one > ["-" extlang]. This is a technical issue, not an editorial one. It has not yet been decided that there should be a limit of one extended language subtag. You and John Cowan argued in favor of this limit, and I would agree unless someone can present a reasonable use case for multiple extlangs (zh-min-nan does not count). But the group must agree to a change like this; it can't go in through the "back door" of editorial correction. > * In chapter 2.2.2: Please replace all "subtags" by "subtag". > Please remove "3. There MAY be any additional number of > extended language subtags." At most one extlang, otherwise > it doesn't fly with RfC 2231 / 2047. See above. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 11:51:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQSL6-0007Bp-P6; Tue, 26 Apr 2005 11:51:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQSL5-0007Bg-7g for ltru@megatron.ietf.org; Tue, 26 Apr 2005 11:51:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20602 for ; Tue, 26 Apr 2005 11:51:04 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQSXX-0008KS-RM for ltru@ietf.org; Tue, 26 Apr 2005 12:04:01 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Apr 2005 08:50:56 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Apr 2005 08:50:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: -01 nits Date: Tue, 26 Apr 2005 08:50:55 -0700 Message-ID: Thread-Topic: [Ltru] Re: -01 nits Thread-Index: AcVKcoLaaCbyQMnTSr+NQFMJfXdfFwAA+43g From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 26 Apr 2005 15:50:55.0918 (UTC) FILETIME=[BB9DECE0:01C54A77] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Doug Ewell > > * There's still a *("-" extlang) in the ABNF, it should be at most one > > ["-" extlang]. >=20 > This is a technical issue, not an editorial one. It has not yet been > decided that there should be a limit of one extended language subtag. I agree that this is a technical issue which has not been adequately discussed. =20 > You and John Cowan argued in favor of this limit, and I would agree > unless someone can present a reasonable use case for multiple extlangs > (zh-min-nan does not count). > > At most one extlang, otherwise it doesn't fly with RfC 2231 / 2047. This requires some explanation. Let me present a scenario: Suppose aaa is a macrolanguage category in ISO 639-3 and bbb is an individual language encompassed by it. So, in 3066ter, we could create a tag aaa-bbb. Now suppose ccc gets added to ISO 639-3 and is given a macrolanguage-membership relation to bbb. How would we want to tag content in ccc? ccc? aaa-ccc? bbb-ccc? aaa-bbb-ccc? I'm not saying I expect this to happen in ISO 639-3 in the future; I just don't know that I can rule it out. (The definitions I wrote for the DIS assume an entry has one particular scope; that would need a bit of adjustment if this were to happen. I suppose it would be possible to enforce in 639-3 that this kind of thing not be permitted, though that would require certain policies on maintenance.) Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 11:58:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQSS1-0007v1-Pu; Tue, 26 Apr 2005 11:58:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQSRz-0007us-Nk for ltru@megatron.ietf.org; Tue, 26 Apr 2005 11:58:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21151 for ; Tue, 26 Apr 2005 11:58:13 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQSeS-00005B-BF for ltru@ietf.org; Tue, 26 Apr 2005 12:11:09 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j3QFvvha000355; Tue, 26 Apr 2005 11:57:57 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 26 Apr 2005 11:57:58 -0400 Date: Tue, 26 Apr 2005 11:57:58 -0400 From: John Cowan To: Doug Ewell Subject: Re: [Ltru] Re: -01 nits Message-ID: <20050426155758.GA7776@skunk.reutershealth.com> References: <20050426142914.YBAL27459.mta2.adelphia.net@megatron.ietf.org> <003e01c54a72$4aa9db20$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003e01c54a72$4aa9db20$030aa8c0@DEWELL> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ltru@ietf.org X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Doug Ewell scripsit: > You and John Cowan argued in favor of this limit, and I would agree > unless someone can present a reasonable use case for multiple extlangs > (zh-min-nan does not count). /me argues out of both sides of his mouth with the greatest of ease. Here's a use case for multiple extlangs, partly factual, partly hypothetical. The 639-1 code 'ar' represents Arabic, which from a 639-3 standpoint is a macrolanguage covering Standard Arabic ('arb') and 29 Arabic colloquials. So in 3066ter, you would tag Standard Arabic specifically with "ar-arb", and (e.g.) Algerian Spoken Arabic with "ar-arq". It would still be valid to use the tag "ar", of course, which would leave the specific kind of Arabic vague. Since 'arb' and 'arq' would be in the registry as extlang subtags rather than language subtags (with a "Required-Prefix" of "ar"), this tagging scheme would be the only one possible under the rules. Now suppose further research shows that Algerian Spoken Arabic is not a single language, but a cover term for two distinct languages, say Eastern and Western Algerian S.A. The natural action of the 639-3/RA would be to register two new codes; let us suppose they are 'erq' and 'wrq' respectively (which are currently unused). These would be included in the macrolanguage table under 'ar', since they are still covered by the general name "Arabic". What should the RFC 3066ter registry maintainers do? Clearly "ar-arq" would still be valid, so 'arq' would remain in the registry as an extlang subtag. But what is the best tagging scheme for the newly recognized languages? Should we use "ar-erq" and "ar-wrq" and not worry about the overlap with "ar-arq", or should we go to a 2-level extlang scheme with "ar-arq-erq" and "ar-arq-wrq"? The former would promote simplicity, the latter would promote backward compatibility in the presence of prefix-matching schemes. (I apologize for the generally seal-barking nature of this message.) -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan The known is finite, the unknown infinite; intellectually we stand on an islet in the midst of an illimitable ocean of inexplicability. Our business in every generation is to reclaim a little more land, to add something to the extent and the solidity of our possessions. --Thomas Henry Huxley _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 12:05:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQSYw-00005e-71; Tue, 26 Apr 2005 12:05:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQSYv-00005X-2H for ltru@megatron.ietf.org; Tue, 26 Apr 2005 12:05:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21600 for ; Tue, 26 Apr 2005 12:05:20 -0400 (EDT) Received: from e2.ny.us.ibm.com ([32.97.182.142]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQSlK-0000DK-DT for ltru@ietf.org; Tue, 26 Apr 2005 12:18:16 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j3QG5A23016683 for ; Tue, 26 Apr 2005 12:05:10 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3QG59AT088052 for ; Tue, 26 Apr 2005 12:05:09 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j3QH3AaU005095 for ; Tue, 26 Apr 2005 12:03:10 -0500 Received: from markdavis (sig-9-48-117-151.mts.ibm.com [9.48.117.151]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with SMTP id j3QH39am005009; Tue, 26 Apr 2005 12:03:10 -0500 Message-ID: <00c101c54a79$b7569450$97753009@sanjose.ibm.com> From: "Mark Davis" To: , "Frank Ellermann" References: <426DB1C0.3B55@xyzzy.claranet.de> Subject: Re: [Ltru] -01 nits Date: Tue, 26 Apr 2005 09:05:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > * In chapter 2.1.1: "Any such limitation MUST be clearly documented, > and such documentation SHOULD include the disposition of any longer > tags (for example, whether an error value is generated or the > language tag is truncated). If truncation is permitted it SHOULD > NOT permit a subtag to be divided." > > Proposed new text: "Any limitation SHOULD be clearly documented. > Tags SHOULD NOT be truncated, but removing complete subtags right > to left MAY be permitted." I don't see why we should change this. I don't yet see any reason to allow protocols that claim conformance to this RFC to truncate without any documentation of that fact. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 14:23:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUiZ-0002r0-AB; Tue, 26 Apr 2005 14:23:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUiX-0002qv-Mw for ltru@megatron.ietf.org; Tue, 26 Apr 2005 14:23:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02875 for ; Tue, 26 Apr 2005 14:23:28 -0400 (EDT) Received: from pop-a065c28.pas.sa.earthlink.net ([207.217.121.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQUv2-0003jD-5z for ltru@ietf.org; Tue, 26 Apr 2005 14:36:24 -0400 Received: from h-64-105-136-240.snvacaid.dynamic.covad.net ([64.105.136.240] helo=oemcomputer) by pop-a065c28.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DQUiU-0001Nb-00 for ltru@ietf.org; Tue, 26 Apr 2005 11:23:26 -0700 Message-ID: <002b01c54a8d$50b96a60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "ltru Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0B20A2D5@irvmbxw01.quest.com> <6.2.1.2.2.20050426005556.03530830@mail.jefsey.com> Date: Tue, 26 Apr 2005 11:25:24 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: Subject: [Ltru] Charter Debates? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - (I've changed the subject line, since Jefsey's posting had nothing to do with the thread in which he had posted.) > From: "JFC (Jefsey) Morfin" > To: "Randy Presuhn" ; "Martin Duerst" > Cc: "ltru Working Group" > Sent: Monday, April 25, 2005 4:34 PM > Subject: Re: [Ltru] (need approval) Working Group submission: LTRU registry draft-01 > > Dear co-Chairs, > I am interested to know if you plan to start a debate on the points of the > Charter Randy described as thorny I do wish you would not twist my words. I don't know whether the problem is in your reading, your understanding, or your writing. I suggest you engage the services of someone fluent in technical French and English. I know that many such people exist. To be perfectly clear: - the charter is not up for debate until we complete our work - the charter imposes specific requirements on what we deliver - we need to ensure that what we produces addresses all the mandatory requirements imposed by our charter > and to discuss the points in my Review of > the Draft as announced also by Randy. I do need to assign issue tracker numbers to the technical points from that message. I'm sorry it has taken so long, but that in no way has prevented discussion of your messages, as any reader of this list will be aware. > I must wait for these debates to get > the positions of this WG on all these points before: > > - either writing my own announced Draft to be as near as possible of a > consensus, since I put myself in priority in the perspective of the WG > Charter rather than in the continuity of a text which failed twice. This > text could be an appropriate fix to the explained XML difficulty, but not a > BCP 047 on Internet language tags framework. You can write your i-d whever you like. No one is holding you back. > - or accept the changes resulting from this debate as consensual. I note > that the points of disagreement are those who lead to the lack of consensus > during the last Last Call. They are mainly the point above and the > organisation of the ietf-languages list which is one of the key Charter > point which has never been discussed yet. My recollection of the discussion on this list is that your problems with the ietf-languages list found no support in this WG. The one to which you have given the most emphasis, issue [psg.com #888], appears to be based on a fundamental misunderstanding of how IETF mailing lists work, as others have repeatedly explained here and elsewhere. > The organisation and the load for > the IANA also never got any response. Untrue. There has been discussion of both those points. In the case of the former, I don't think we've reached a conclusion, other than to say that we need to provide explicit instructions to IANA to tell them how we want things to work if we want anything fancy. In the case of the latter point, I believe the consensus was to provide a strong warning to developers to not do stupid things, as pointless as that may be, since the same theoretical problems could occur for many other registries, e.g., http://www.iana.org/assignments/enterprise-numbers > But all this is in my review. > > As explained to Frank we started to write a Draft earlier and waited for > this debate. Now I am quite busy. That is your choice. > - If you plan this debate I will still wait for it, I will make my delayed > home work as I can, and I will call for an extra 15 days after I submitted > my own Draft to have it reviewed. > - If you do not plan to have these debates, I will be less dependent on the > calendar of this WG to introduce a totally independent Draft. It will then > get discussed on the general list during the last call, I presume? ... This mailing list is for the discussion of WG documents. If you produce an independent submission, you are welcome to bring it to the WG's attention, and the WG may, if it choses, incorporate relevant ideas and text into its work. However, this WG's schedule will not be dictated by yours, and the last call period is for the discussion of the document under last call. As for the conduct of the last call, I refer you to RFC 2418 section 8 (for WG last call) and RFC 2026 section 6.1.2 (for IETF last call). Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 15:30:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQVkz-0002ef-SS; Tue, 26 Apr 2005 15:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQVkw-0002dt-9d for ltru@megatron.ietf.org; Tue, 26 Apr 2005 15:30:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09164 for ; Tue, 26 Apr 2005 15:30:00 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQVxR-00058m-1X for ltru@ietf.org; Tue, 26 Apr 2005 15:42:58 -0400 Received: from lns-p19-2-idf-82-251-127-245.adsl.proxad.net ([82.251.127.245] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DQVkl-0006cE-Ld; Tue, 26 Apr 2005 12:29:52 -0700 Message-Id: <6.2.1.2.2.20050426205354.03a7aeb0@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 26 Apr 2005 21:29:46 +0200 To: "Randy Presuhn" , "ltru Working Group" From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Charter Debates? In-Reply-To: <002b01c54a8d$50b96a60$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0B20A2D5@irvmbxw01.quest.com> <6.2.1.2.2.20050426005556.03530830@mail.jefsey.com> <002b01c54a8d$50b96a60$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 20:25 26/04/2005, Randy Presuhn wrote: >To be perfectly clear: the charter is not up for debate until we complete >our work. I just submit that commonly understanding the Charter might help before responding to it. Don't you agree? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 16:19:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWWn-0000st-KZ; Tue, 26 Apr 2005 16:19:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWWj-0000se-2D for ltru@megatron.ietf.org; Tue, 26 Apr 2005 16:19:28 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13793 for ; Tue, 26 Apr 2005 16:19:21 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DQWQY-00081y-FO for ltru@lists.ietf.org; Tue, 26 Apr 2005 22:13:04 +0200 Received: from 212.82.251.220 ([212.82.251.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Apr 2005 22:13:02 +0200 Received: from nobody by 212.82.251.220 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Apr 2005 22:13:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 26 Apr 2005 05:13:04 +0200 Organization: Lines: 112 Message-ID: <426DB1C0.3B55@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.220 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] -01 nits X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi, some observations in draft -01 in no particular order: * [7] (Unicode 4) is not used. Please delete this normative reference, [6] is good enough. * In chapter 2.1 "UTF-16LE" is not explained. Please add [RfC 2781] as informative reference. * [13] (IETF-ICANN MoU about IANA) Please delete this "normative" reference to an MoU-FYI. Maybe use [RfC 2028] (BCP 11) as a reference to explain "IANA", you already have it as [10] elsewhere. * [16] (RfC 3978) is not used. Please delete this normative reference, the boilerplates work without it. * In chapter 3.1 replace the URL of XML 1.0 3rd ed. by the generic URL of the latest XML 1.0 edition. * Several "2-character code", "3-character code", "4-character subtags": Using "alpha-2 code" etc. would be clearer and shorter where the ABNF dictates 2ALPHA etc. * There's still a *("-" extlang) in the ABNF, it should be at most one ["-" extlang]. * In chapter 2.1.1: "In practice, this limits most tags to a sequence of four subtags, and thus a length of 35 (excluding any extensions": This limit is 8+(1+4)+(1+3)+(1+8)= 26 without extlang and 4 subtags. With extlang it's only 25 = 3+(1+3)+(1+4)+(2+3)+(1+8). * In chapter 2.1.1: "Any such limitation MUST be clearly documented, and such documentation SHOULD include the disposition of any longer tags (for example, whether an error value is generated or the language tag is truncated). If truncation is permitted it SHOULD NOT permit a subtag to be divided." Proposed new text: "Any limitation SHOULD be clearly documented. Tags SHOULD NOT be truncated, but removing complete subtags right to left MAY be permitted." * In chapter 2.2.1: 7. The single character subtag 'i' is used by some grandfathered tags (see Section 2.2.8) such as "i-klingon" and "i-bnn". Please replace the "almost" deprecated i-klingon by i-default. * In chapter 2.2.2: Please replace all "subtags" by "subtag". Please remove "3. There MAY be any additional number of extended language subtags." At most one extlang, otherwise it doesn't fly with RfC 2231 / 2047. * In chapter 2.2.7: "Users who wished to utilize SIL Ethnologue". Please delete this example, it muddies the water for ISO 639-3. * The ABNF layout in 3.1 is ugly, the main ABNF is better, please use the same xml2rfc trick (artwork ?) as in 2.1: registry = record *( "%%" CRLF record ) record = 1*( field-name *SP ":" *SP field-body CRLF ) field-name = 1*( ALPHA / DIGIT / "-" ) field-body = *( ASC-char / LWSP ) ASC-char = %x21-25 / %x27-7E / UNI-char ; AMPERSAND is %x26 UNI-char = "&#x" 2*6HEXDIG ";" This fixes the reported "no %% in the first / last line" problem. The minimal length of a field-name should be one, not zero. It also replaces the undefined NUM by DIGIT, and %x2D by "-". In theory a field-name starting or ending with a "-" would be a bad idea, and a DIGIT in a field-name is also strange, but OTOH we don't want to reinvent "ldh-string" for a known set of names. * Please delete the File-Date example or get rid of the first "%%": %% File-Date: 2004-06-28 %% * Another proposal for the registry ABNF: registry = record *( "%%" CRLF record ) record = 1*( field CRLF ) field = type / timestamp / reference / explanation type = ( subtagttype / tagtype ) 1*SP tagtext subtagtype = "Language:" / "Extlang:" / "Script:" / "Region:" / "Variant:" tagtype = "Grandfathered:" / "Redundant:" timestamp = ( "File-Date:" / "Added:" / "Deprecated:" ) 1*SP date reference = ( "Canonical:" / "Suppress-Script:" / "Recommended-Prefix:" ) 1*SP tagtext explanation = ( "Description:" / "Comment:" ) 1*SP text date = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; see RfC 3339 tagtext = 1*( ALPHA / DIGIT / "-" ) ; note no WSP text = *( ASC-char / LWSP ) ; note folding WSP ASC-char = %x21-25 / %x27-7E / UNI-char ; AMPERSAND is %x26 UNI-char = "&#x" 2*6HEXDIG ";" This is quite different from the old ABNF, no more SP before the COLON, at least one SP after the COLON, no "folding" for a date or tagtext, "folding" only for a (long) Description: or a Comment:, no UNI-char or special char in tagtext, a date syntax that needs no further explanation (one example will do). Based on this ABNF chapter 3.1 could be much shorter and clearer. It's not more necessary to dig through 3.1 to find all field names. IMHO you could submit snapshots of complete drafts more often, and you also don't need Randy or Martin for a future -02, etc. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 16:19:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWX0-0000tp-SN; Tue, 26 Apr 2005 16:19:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWWz-0000tk-LU for ltru@megatron.ietf.org; Tue, 26 Apr 2005 16:19:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13808 for ; Tue, 26 Apr 2005 16:19:37 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70] helo=irvbhxw03.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQWjT-0006XH-Ai for ltru@ietf.org; Tue, 26 Apr 2005 16:32:35 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 13:19:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] -01 nits Date: Tue, 26 Apr 2005 13:19:26 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B2C4CB7@irvmbxw01.quest.com> Thread-Topic: [Ltru] -01 nits Thread-Index: AcVKDz+0g2a3/ol6TaGA1ZkzZp8/DAAXtz/g From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 26 Apr 2005 20:19:28.0119 (UTC) FILETIME=[3F3CB070:01C54A9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Comments inline. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?4?25? 20:13 > To: ltru@ietf.org > Subject: [Ltru] -01 nits >=20 > Hi, some observations in draft -01 in no particular order: >=20 > * [7] (Unicode 4) is not used. > Please delete this normative reference, [6] is good enough. [Addison Phillips]=20 Stale reference, but I recycled it as informative elsewhere. >=20 > * In chapter 2.1 "UTF-16LE" is not explained. > Please add [RfC 2781] as informative reference. [Addison Phillips]=20 Okay. Which is where I recycled Unicode and also refer to RFC2781. >=20 > * [13] (IETF-ICANN MoU about IANA) > Please delete this "normative" reference to an MoU-FYI. > Maybe use [RfC 2028] (BCP 11) as a reference to explain "IANA", > you already have it as [10] elsewhere. [Addison Phillips]=20 ~sigh~ I put this in at someone's urging and can replace it. >=20 > * [16] (RfC 3978) is not used. > Please delete this normative reference, the boilerplates > work without it. [Addison Phillips]=20 Agreed. >=20 > * In chapter 3.1 replace the URL of XML 1.0 3rd ed. by the > generic URL of the latest XML 1.0 edition. [Addison Phillips]=20 Agreed. Done. Also fixed the specific URL (in the eref) >=20 > * Several "2-character code", "3-character code", "4-character = subtags": > Using "alpha-2 code" etc. would be clearer and shorter where the = ABNF > dictates 2ALPHA etc. [Addison Phillips]=20 I replaced all of these with the number spelled out (e.g. "two = character" instead of "2-character"). Using plain English is preferable = (to me) to using more mechanical looking text. >=20 > * There's still a *("-" extlang) in the ABNF, it should be at most one > ["-" extlang]. [Addison Phillips]=20 No, since there is no restriction on how many extlangs there can be = currently and the grammar permits them. We don't know how they will = ultimately be used, so I am a bit loathe to remove the repeating aspect = (no matter that it greatly complicates processing).=20 If a consensus can be built to limit them then I will change the ABNF = and text in draft-02. (I would favor limiting them to one occurrence). >=20 > * In chapter 2.1.1: "In practice, this limits most tags to a sequence > of four subtags, and thus a length of 35 (excluding any extensions": > This limit is 8+(1+4)+(1+3)+(1+8)=3D 26 without extlang and 4 = subtags. > With extlang it's only 25 =3D 3+(1+3)+(1+4)+(2+3)+(1+8). [Addison Phillips]=20 Okay. I didn't include the math, I put instead: In particular, variant subtags SHOULD be used only with their = recommended prefix. In practice, this limits most tags to a sequence of = four subtags, and thus a maximum length of 26 characters (excluding any extensions or = private use sequences). This is because subtags are limited to a length = of eight characters and the extlang, script, and region subtags are = limited to even fewer characters. See = for more information on selecting the most appropriate Language Tag. >=20 > * In chapter 2.1.1: "Any such limitation MUST be clearly documented, > and such documentation SHOULD include the disposition of any longer > tags (for example, whether an error value is generated or the > language tag is truncated). If truncation is permitted it SHOULD > NOT permit a subtag to be divided." >=20 > Proposed new text: "Any limitation SHOULD be clearly documented. > Tags SHOULD NOT be truncated, but removing complete subtags right > to left MAY be permitted." [Addison Phillips]=20 I'd prefer to keep the MUSTard on the length limitation (it isn't that = onerous an item, if you think about it: anything that limits the length = will have to say what the limit is, no?).=20 >=20 > * In chapter 2.2.1: 7. The single character subtag 'i' is used by > some grandfathered tags (see Section 2.2.8) such as "i-klingon" > and "i-bnn". > Please replace the "almost" deprecated i-klingon by i-default. [Addison Phillips]=20 i-klingon was chosen in part because it is deprecated, not just because = it was grandfathered. >=20 > * In chapter 2.2.2: Please replace all "subtags" by "subtag". > Please remove "3. There MAY be any additional number of > extended language subtags." At most one extlang, otherwise > it doesn't fly with RfC 2231 / 2047. [Addison Phillips]=20 See above note about extlang. If there is consensus I will change it. >=20 > * In chapter 2.2.7: "Users who wished to utilize SIL Ethnologue". > Please delete this example, it muddies the water for ISO 639-3. [Addison Phillips]=20 Yes, but I need a replacement example. Want to suggest one? >=20 > * The ABNF layout in 3.1 is ugly, the main ABNF is better, please > use the same xml2rfc trick (artwork ?) as in 2.1: >=20 > registry =3D record *( "%%" CRLF record ) > record =3D 1*( field-name *SP ":" *SP field-body CRLF ) > field-name =3D 1*( ALPHA / DIGIT / "-" ) > field-body =3D *( ASC-char / LWSP ) > ASC-char =3D %x21-25 / %x27-7E / UNI-char ; AMPERSAND is %x26 > UNI-char =3D "&#x" 2*6HEXDIG ";" [Addison Phillips]=20 Okay. It is an artwork, I just haven't cleaned it up. Here is my cleanup: registry =3D record *("%%" CRLF record) record =3D 1*( field-name *SP ":" *SP field-body CRLF ) field-name =3D *(ALPHA / DIGIT / "-") field-body =3D *(ASCCHAR/LWSP) ASCCHAR =3D %x21-25 / %x27-7E / UNICHAR ; Note: AMPERSAND is %x26 UNICHAR =3D "&#x" 2*6HEXDIG ";" Validated the results cleanly. >=20 > This fixes the reported "no %% in the first / last line" problem. > The minimal length of a field-name should be one, not zero. > It also replaces the undefined NUM by DIGIT, and %x2D by "-". [Addison Phillips]=20 Okay. NUM is defined somewhere, but I replaced with DIGIT for = consistency's sake. >=20 > In theory a field-name starting or ending with a "-" would be a > bad idea, and a DIGIT in a field-name is also strange, but OTOH > we don't want to reinvent "ldh-string" for a known set of names. [Addison Phillips]=20 Exactly. >=20 > * Please delete the File-Date example or get rid of the first "%%": > %% > File-Date: 2004-06-28 > %% [Addison Phillips]=20 Already done. >=20 > * Another proposal for the registry ABNF: >=20 > registry =3D record *( "%%" CRLF record ) > record =3D 1*( field CRLF ) > field =3D type / timestamp / reference / explanation > type =3D ( subtagttype / tagtype ) 1*SP tagtext > subtagtype =3D "Language:" / "Extlang:" / "Script:" > / "Region:" / "Variant:" > tagtype =3D "Grandfathered:" / "Redundant:" > timestamp =3D ( "File-Date:" / "Added:" / "Deprecated:" ) 1*SP = date > reference =3D ( "Canonical:" / "Suppress-Script:" > / "Recommended-Prefix:" ) 1*SP tagtext > explanation =3D ( "Description:" / "Comment:" ) 1*SP text > date =3D 4DIGIT "-" 2DIGIT "-" 2DIGIT ; see RfC 3339 > tagtext =3D 1*( ALPHA / DIGIT / "-" ) ; note no WSP > text =3D *SP ":" *( ASC-char / LWSP ) ; note folding WSP > ASC-char =3D %x21-25 / %x27-7E / UNI-char ; AMPERSAND is %x26 > UNI-char =3D "&#x" 2*6HEXDIG ";" [Addison Phillips]=20 That's really different and probably quite correct. But I'm not going to = create a big ugly ABNF-and-full-text-edit before sending draft-01 off to = I-D land. Let's dicuss for draft-02. >=20 > This is quite different from the old ABNF, no more SP before the > COLON, at least one SP after the COLON, no "folding" for a date or > tagtext, "folding" only for a (long) Description: or a Comment:, > no UNI-char or special char in tagtext, a date syntax that needs > no further explanation (one example will do). >=20 > Based on this ABNF chapter 3.1 could be much shorter and clearer. > It's not more necessary to dig through 3.1 to find all field names. >=20 > IMHO you could submit snapshots of complete drafts more often, > and you also don't need Randy or Martin for a future -02, etc. [Addison Phillips]=20 I would like to submit them more often, but we needed to get through a = big edit first that solved most problems first. In addition: we are = behind schedule and I really REALLY want to finish this work. I am = hoping that draft-02 or draft-03 is a Last Call draft (which we can = approach by solving the remaining substantive issues). At present I recognize one substantive issue that we need to resolve, = namely the handling of country code changes. After that we are nearly = done but for nits, unless I am missing something. Thanks for your help. [Addison Phillips]=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 16:25:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWcW-0001ag-Cc; Tue, 26 Apr 2005 16:25:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWcT-0001VL-0N; Tue, 26 Apr 2005 16:25:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14209; Tue, 26 Apr 2005 16:24:53 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQWoW-0006eQ-G8; Tue, 26 Apr 2005 16:37:51 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 13:24:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C54A9D.F3732CE6" Date: Tue, 26 Apr 2005 13:24:30 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B2C4CC4@irvmbxw01.quest.com> X-MS-Has-Attach: yes Thread-Topic: [submission] draft-ietf-ltru-registry-01 Thread-Index: AcVKnfGCO5+L6R/KRa+chz671Z5CRA== From: "Addison Phillips" To: X-OriginalArrivalTime: 26 Apr 2005 20:24:33.0253 (UTC) FILETIME=[F51C7150:01C54A9D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 83a2c48a768a8faaaf93224d13118699 Cc: ltru@ietf.org Subject: [Ltru] [submission] draft-ietf-ltru-registry-01 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C54A9D.F3732CE6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBFZGl0b3IsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIGluIHRleHQgZm9ybWF0IHRoZSBk cmFmdCAiZHJhZnQtaWV0Zi1sdHJ1LXJlZ2lzdHJ5LTAxIg0KDQpUaGlzIGRvY3VtZW50IHdhcyBh cHByb3ZlZCBieSB0aGUgY2hhaXJzIG9mIHRoZSBMVFJVIFdvcmtpbmcgR3JvdXAgZm9yIHB1Ymxp Y2F0aW9uIGFuZCByZXByZXNlbnRzIGFuIGluY3JlbWVudGFsIGRyYWZ0Lg0KDQpCZXN0IFJlZ2Fy ZHMgKGZvciB0aGUgZWRpdG9ycyksDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0K R2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0 LmNvbQ0KDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91 cA0KaHR0cDovL3d3dy53My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlv biBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= ------_=_NextPart_001_01C54A9D.F3732CE6 Content-Type: text/plain; name="draft-ietf-ltru-registry-01.txt" Content-Description: draft-ietf-ltru-registry-01.txt Content-Disposition: attachment; filename="draft-ietf-ltru-registry-01.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUXVlc3QgU29mdHdhcmUNCkV4cGlyZXM6IE9jdG9iZXIg MjgsIDIwMDUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gRGF2aXMsIEVkLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSUJNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQXByaWwgMjYsIDIwMDUNCg0KDQogICAgICAgICAgICAgICAgICAg ICBUYWdzIGZvciBJZGVudGlmeWluZyBMYW5ndWFnZXMNCiAgICAgICAgICAgICAgICAgICAgICBk cmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMDENCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBC eSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMg dGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hp Y2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQs IGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NCg0KICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBn cm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJy ZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQt RHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4 cGlyZSBvbiBPY3RvYmVyIDI4LCAyMDA1Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHly aWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLg0KDQpBYnN0cmFjdA0KDQogICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgc3RydWN0dXJlLCBjb250ZW50LCBjb25zdHJ1Y3Rp b24sIGFuZA0KICAgc2VtYW50aWNzIG9mIGxhbmd1YWdlIHRhZ3MgZm9yIHVzZSBpbiBjYXNlcyB3 aGVyZSBpdCBpcyBkZXNpcmFibGUgdG8NCiAgIGluZGljYXRlIHRoZSBsYW5ndWFnZSB1c2VkIGlu IGFuIGluZm9ybWF0aW9uIG9iamVjdC4gIEl0IGFsc28NCiAgIGRlc2NyaWJlcyBob3cgdG8gcmVn aXN0ZXIgdmFsdWVzIGZvciB1c2UgaW4gbGFuZ3VhZ2UgdGFncyBhbmQgdGhlDQogICBjcmVhdGlv biBvZiB1c2VyIGRlZmluZWQgZXh0ZW5zaW9ucyBmb3IgcHJpdmF0ZSBpbnRlcmNoYW5nZS4gIFRo aXMNCiAgIGRvY3VtZW50IG9ic29sZXRlcyBSRkMgMzA2NiAod2hpY2ggcmVwbGFjZWQgUkZDIDE3 NjYpLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjgs IDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNClRh YmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMi4gIFRoZSBMYW5ndWFnZSBU YWcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAg IDIuMSAgIFN5bnRheCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDQNCiAgICAgICAyLjEuMSAgIExlbmd0aCBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgICAyLjIgICBMYW5ndWFnZSBTdWJ0YWcg U291cmNlcyBhbmQgSW50ZXJwcmV0YXRpb24gLiAuIC4gLiAuIC4gLiAuICA3DQogICAgICAgMi4y LjEgICBQcmltYXJ5IExhbmd1YWdlIFN1YnRhZyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDgNCiAgICAgICAyLjIuMiAgIEV4dGVuZGVkIExhbmd1YWdlIFN1YnRhZ3MgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgICAgIDIuMi4zICAgU2NyaXB0IFN1YnRhZyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDQogICAgICAgMi4yLjQgICBS ZWdpb24gU3VidGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTEN CiAgICAgICAyLjIuNSAgIFZhcmlhbnQgU3VidGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxMg0KICAgICAgIDIuMi42ICAgRXh0ZW5zaW9uIFN1YnRhZ3MgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDQogICAgICAgMi4yLjcgICBQcml2YXRl IFVzZSBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTQNCiAgICAg ICAyLjIuOCAgIFByZS1FeGlzdGluZyBSRkMgMzA2NiBSZWdpc3RyYXRpb25zICAuIC4gLiAuIC4g LiAuIC4gLiAxNQ0KICAgICAgIDIuMi45ICAgQ2xhc3NlcyBvZiBDb25mb3JtYW5jZSAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1DQogICAzLiAgUmVnaXN0cnkgRm9ybWF0IGFuZCBN YWludGVuYW5jZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNCiAgICAgMy4xICAg Rm9ybWF0IG9mIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeSAgLiAuIC4gLiAuIC4g LiAxNw0KICAgICAzLjIgICBNYWludGVuYW5jZSBvZiB0aGUgUmVnaXN0cnkgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDIxDQogICAgIDMuMyAgIFN0YWJpbGl0eSBvZiBJQU5BIFJlZ2lz dHJ5IEVudHJpZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjINCiAgICAgMy40ICAgUmVnaXN0 cmF0aW9uIFByb2NlZHVyZSBmb3IgU3VidGFncyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyNQ0K ICAgICAzLjUgICBQb3NzaWJpbGl0aWVzIGZvciBSZWdpc3RyYXRpb24gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDI5DQogICAgIDMuNiAgIEV4dGVuc2lvbnMgYW5kIEV4dGVuc2lvbnMgTmFt ZXNwYWNlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzANCiAgICAgMy43ICAgQ29udmVyc2lvbiBv ZiB0aGUgUkZDIDMwNjYgTGFuZ3VhZ2UgVGFnIFJlZ2lzdHJ5IC4gLiAuIC4gLiAzMw0KICAgNC4g IEZvcm1hdGlvbiBhbmQgUHJvY2Vzc2luZyBvZiBMYW5ndWFnZSBUYWdzICAuIC4gLiAuIC4gLiAu IC4gLiAuIDM2DQogICAgIDQuMSAgIENob2ljZSBvZiBMYW5ndWFnZSBUYWcgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzYNCiAgICAgNC4yICAgTWVhbmluZyBvZiB0aGUgTGFu Z3VhZ2UgVGFnICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzOA0KICAgICA0LjMgICBD YW5vbmljYWxpemF0aW9uIG9mIExhbmd1YWdlIFRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDM5DQogICAgIDQuNCAgIENvbnNpZGVyYXRpb25zIGZvciBQcml2YXRlIFVzZSBTdWJ0YWdzIC4g LiAuIC4gLiAuIC4gLiAuIC4gNDANCiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25zICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Mg0KICAgNi4gIFNlY3VyaXR5IENv bnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQzDQog ICA3LiAgQ2hhcmFjdGVyIFNldCBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNDQNCiAgIDguICBDaGFuZ2VzIGZyb20gUkZDIDMwNjYgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0NQ0KICAgOS4gIFJlZmVyZW5jZXMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUwDQogICAgIDku MSAgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNTANCiAgICAgOS4yICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA1MQ0KICAgICAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUyDQogICBBLiAgQWNrbm93 bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NTMNCiAgIEIuICBFeGFtcGxlcyBvZiBMYW5ndWFnZSBUYWdzIChJbmZvcm1hdGl2ZSkgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA1NA0KICAgQy4gIEV4YW1wbGUgUmVnaXN0cnkgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU3DQogICAgICAgSW50ZWxsZWN0dWFs IFByb3BlcnR5IGFuZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gNjENCg0K DQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVy IDI4LCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0K DQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIEh1bWFuIGJlaW5ncyBvbiBvdXIgcGxhbmV0IGhhdmUs IHBhc3QgYW5kIHByZXNlbnQsIHVzZWQgYSBudW1iZXIgb2YNCiAgIGxhbmd1YWdlcy4gIFRoZXJl IGFyZSBtYW55IHJlYXNvbnMgd2h5IG9uZSB3b3VsZCB3YW50IHRvIGlkZW50aWZ5IHRoZQ0KICAg bGFuZ3VhZ2UgdXNlZCB3aGVuIHByZXNlbnRpbmcgb3IgcmVxdWVzdGluZyBpbmZvcm1hdGlvbi4N Cg0KICAgSW5mb3JtYXRpb24gYWJvdXQgYSB1c2VyJ3MgbGFuZ3VhZ2UgcHJlZmVyZW5jZXMgY29t bW9ubHkgbmVlZHMgdG8gYmUNCiAgIGlkZW50aWZpZWQgc28gdGhhdCBhcHByb3ByaWF0ZSBwcm9j ZXNzaW5nIGNhbiBiZSBhcHBsaWVkLiAgRm9yDQogICBleGFtcGxlLCB0aGUgdXNlcidzIGxhbmd1 YWdlIHByZWZlcmVuY2VzIGluIGEgYnJvd3NlciBjYW4gYmUgdXNlZCB0bw0KICAgc2VsZWN0IHdl YiBwYWdlcyBhcHByb3ByaWF0ZWx5LiAgQSBjaG9pY2Ugb2YgbGFuZ3VhZ2UgcHJlZmVyZW5jZSBj YW4NCiAgIGFsc28gYmUgdXNlZCB0byBzZWxlY3QgYW1vbmcgdG9vbHMgKHN1Y2ggYXMgZGljdGlv bmFyaWVzKSB0byBhc3Npc3QNCiAgIGluIHRoZSBwcm9jZXNzaW5nIG9yIHVuZGVyc3RhbmRpbmcg b2YgY29udGVudCBpbiBkaWZmZXJlbnQgbGFuZ3VhZ2VzLg0KDQogICBJbiBhZGRpdGlvbiwga25v d2xlZGdlIGFib3V0IHRoZSBwYXJ0aWN1bGFyIGxhbmd1YWdlIHVzZWQgYnkgc29tZQ0KICAgcGll Y2Ugb2YgaW5mb3JtYXRpb24gY29udGVudCBtYXkgYmUgdXNlZnVsIG9yIGV2ZW4gcmVxdWlyZWQg Ynkgc29tZQ0KICAgdHlwZXMgb2YgaW5mb3JtYXRpb24gcHJvY2Vzc2luZzsgZm9yIGV4YW1wbGUg c3BlbGwtY2hlY2tpbmcsDQogICBjb21wdXRlci1zeW50aGVzaXplZCBzcGVlY2gsIEJyYWlsbGUg dHJhbnNjcmlwdGlvbiwgb3IgaGlnaC1xdWFsaXR5DQogICBwcmludCByZW5kZXJpbmdzLg0KDQog ICBPbmUgbWVhbnMgb2YgaW5kaWNhdGluZyB0aGUgbGFuZ3VhZ2UgdXNlZCBpcyBieSBsYWJlbGlu ZyB0aGUNCiAgIGluZm9ybWF0aW9uIGNvbnRlbnQgd2l0aCBhIGxhbmd1YWdlIGlkZW50aWZpZXIu ICBUaGVzZSBpZGVudGlmaWVycw0KICAgY2FuIGFsc28gYmUgdXNlZCB0byBzcGVjaWZ5IHVzZXIg cHJlZmVyZW5jZXMgd2hlbiBzZWxlY3RpbmcNCiAgIGluZm9ybWF0aW9uIGNvbnRlbnQsIG9yIGZv ciBsYWJlbGluZyBhZGRpdGlvbmFsIGF0dHJpYnV0ZXMgb2YgY29udGVudA0KICAgYW5kIGFzc29j aWF0ZWQgcmVzb3VyY2VzLg0KDQogICBUaGVzZSBpZGVudGlmaWVycyBjYW4gYWxzbyBiZSB1c2Vk IHRvIGluZGljYXRlIGFkZGl0aW9uYWwgYXR0cmlidXRlcw0KICAgb2YgY29udGVudCB0aGF0IGFy ZSBjbG9zZWx5IHJlbGF0ZWQgdG8gdGhlIGxhbmd1YWdlLiAgSW4gcGFydGljdWxhciwNCiAgIGl0 IGlzIG9mdGVuIG5lY2Vzc2FyeSB0byBpbmRpY2F0ZSBzcGVjaWZpYyBpbmZvcm1hdGlvbiBhYm91 dCB0aGUNCiAgIGRpYWxlY3QsIHdyaXRpbmcgc3lzdGVtLCBvciBvcnRob2dyYXBoeSB1c2VkIGlu IGEgZG9jdW1lbnQgb3INCiAgIHJlc291cmNlLCBhcyB0aGVzZSBhdHRyaWJ1dGVzIG1heSBiZSBp bXBvcnRhbnQgZm9yIHRoZSB1c2VyIHRvIG9idGFpbg0KICAgaW5mb3JtYXRpb24gaW4gYSBmb3Jt IHRoYXQgdGhleSBjYW4gdW5kZXJzdGFuZCwgb3IgaW1wb3J0YW50IGluDQogICBzZWxlY3Rpbmcg YXBwcm9wcmlhdGUgcHJvY2Vzc2luZyByZXNvdXJjZXMgZm9yIHRoZSBnaXZlbiBjb250ZW50Lg0K DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhbiBpZGVudGlmaWVyIG1lY2hhbmlzbSBhbmQg YSByZWdpc3RyYXRpb24NCiAgIGZ1bmN0aW9uIGZvciB2YWx1ZXMgdG8gYmUgdXNlZCB3aXRoIHRo YXQgaWRlbnRpZmllciBtZWNoYW5pc20uICBJdA0KICAgYWxzbyBkZWZpbmVzIGEgbWVjaGFuaXNt IGZvciBwcml2YXRlIHVzZSB2YWx1ZXMgYW5kIGZ1dHVyZSBleHRlbnNpb24uDQoNCiAgIFRoaXMg ZG9jdW1lbnQgcmVwbGFjZXMgUkZDIDMwNjYsIHdoaWNoIHJlcGxhY2VkIFJGQyAxNzY2LiAgRm9y IGEgbGlzdA0KICAgb2YgY2hhbmdlcyBpbiB0aGlzIGRvY3VtZW50LCBzZWUgU2VjdGlvbiA4Lg0K DQogICBUaGUga2V5d29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwi LCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIs ICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50 ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMgMjExOV0gWzEwXS4NCg0KDQoNCg0KDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAg ICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCjIuICBUaGUgTGFuZ3Vh Z2UgVGFnDQoNCjIuMSAgU3ludGF4DQoNCiAgIFRoZSBsYW5ndWFnZSB0YWcgaXMgY29tcG9zZWQg b2Ygb25lIG9yIG1vcmUgcGFydHM6IEEgcHJpbWFyeSBsYW5ndWFnZQ0KICAgc3VidGFnIGFuZCBh IChwb3NzaWJseSBlbXB0eSkgc2VyaWVzIG9mIHN1YnNlcXVlbnQgc3VidGFncy4gIFN1YnRhZ3MN CiAgIGFyZSBkaXN0aW5ndWlzaGVkIGJ5IHRoZWlyIGxlbmd0aCwgcG9zaXRpb24gaW4gdGhlIHN1 YnRhZyBzZXF1ZW5jZSwNCiAgIGFuZCBjb250ZW50LCBzbyB0aGF0IGVhY2ggdHlwZSBvZiBzdWJ0 YWcgY2FuIGJlIHJlY29nbml6ZWQgc29sZWx5IGJ5DQogICB0aGVzZSBmZWF0dXJlcy4gIFRoaXMg bWFrZXMgaXQgcG9zc2libGUgdG8gY29uc3RydWN0IGEgcGFyc2VyIHRoYXQNCiAgIGNhbiBleHRy YWN0IGFuZCBhc3NpZ24gc29tZSBzZW1hbnRpYyBpbmZvcm1hdGlvbiB0byB0aGUgc3VidGFncywg ZXZlbg0KICAgaWYgc3BlY2lmaWMgc3VidGFnIHZhbHVlcyBhcmUgbm90IHJlY29nbml6ZWQuICBU aHVzIGEgcGFyc2VyIG5lZWQgbm90DQogICBoYXZlIGFuIHVwLXRvLWRhdGUgY29weSBvZiB0aGUg cmVnaXN0ZXJlZCBzdWJ0YWcgdmFsdWVzIHRvIHBlcmZvcm0NCiAgIG1vc3Qgc2VhcmNoaW5nIGFu ZCBtYXRjaGluZyBvcGVyYXRpb25zLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSA0 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgVGhlIHN5bnRheCBvZiB0aGlzIHRhZyBpbiBB Qk5GIFs3XSBpczoNCg0KICAgTGFuZ3VhZ2UtVGFnID0gKGxhbmcNCiAgICAgICAgICAgICAgICAg ICAqKCItIiBleHRsYW5nKQ0KICAgICAgICAgICAgICAgICAgIFsiLSIgc2NyaXB0XQ0KICAgICAg ICAgICAgICAgICAgIFsiLSIgcmVnaW9uXQ0KICAgICAgICAgICAgICAgICAgICooIi0iIHZhcmlh bnQpDQogICAgICAgICAgICAgICAgICAgKigiLSIgZXh0ZW5zaW9uKQ0KICAgICAgICAgICAgICAg ICAgIFsiLSIgcHJpdmF0ZXVzZV0pDQogICAgICAgICAgICAgICAgICAgLyBwcml2YXRldXNlICAg ICAgICAgOyBwcml2YXRlLXVzZSB0YWcNCiAgICAgICAgICAgICAgICAgICAvIGdyYW5kZmF0aGVy ZWQgICAgICA7IGdyYW5kZmF0aGVyZWQgcmVnaXN0cmF0aW9ucw0KDQogICBsYW5nICAgICAgICAg ICAgPSAyKjNBTFBIQSAgICAgICAgICAgOyBzaG9ydGVzdCBJU08gNjM5IGNvZGUNCiAgICAgICAg ICAgICAgICAgICAvIHJlZ2lzdGVyZWQtbGFuZw0KICAgZXh0bGFuZyAgICAgICAgID0gM0FMUEhB ICAgICAgICAgICAgIDsgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UNCiAgIHNjcmlwdCAgICAgICAg ICA9IDRBTFBIQSAgICAgICAgICAgICA7IElTTyAxNTkyNCBjb2RlDQogICByZWdpb24gICAgICAg ICAgPSAyQUxQSEEgICAgICAgICAgICAgOyBJU08gMzE2NiBjb2RlDQogICAgICAgICAgICAgICAg ICAgLyAzRElHSVQgICAgICAgICAgICAgOyBVTiBjb3VudHJ5IG51bWJlcg0KICAgdmFyaWFudCAg ICAgICAgID0gIDUqOGFscGhhbnVtICAgICAgIDsgcmVnaXN0ZXJlZCB2YXJpYW50cw0KICAgICAg ICAgICAgICAgICAgIC8gKCBESUdJVCAzYWxwaGFudW0gKQ0KICAgZXh0ZW5zaW9uICAgICAgID0g c2luZ2xldG9uIDEqKCItIiAoMio4YWxwaGFudW0pKQ0KICAgcHJpdmF0ZXVzZSAgICAgID0gKCJ4 Ii8iWCIpIDEqKCItIiAoMSo4YWxwaGFudW0pKQ0KICAgc2luZ2xldG9uICAgICAgID0gJXg0MS01 NyAvICV4NTktNUEgLyAleDYxLTc3IC8gJXg3OS03QSAvIERJR0lUDQogICAgICAgICAgICAgICAg ICAgOyAiYSItInciIC8gInkiLSJ6IiAvICJBIi0iVyIgLyAiWSItIloiIC8gIjAiLSI5Ig0KICAg ICAgICAgICAgICAgICAgIDsgU2luZ2xlIGxldHRlcnM6IHgvWCBpcyByZXNlcnZlZCBmb3IgcHJp dmF0ZSB1c2UNCiAgIHJlZ2lzdGVyZWQtbGFuZyA9IDQqOEFMUEhBICAgICAgICAgIDsgcmVnaXN0 ZXJlZCBsYW5ndWFnZSBzdWJ0YWcNCiAgIGdyYW5kZmF0aGVyZWQgICA9IDEqM0FMUEhBIDEqMigi LSIgKDIqOGFscGhhbnVtKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDsgZ3JhbmRmYXRoZXJlZCByZWdpc3RyYXRpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDsgTm90ZTogaSBpcyB0aGUgb25seSBzaW5nbGV0b24NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgdGhhdCBzdGFydHMgYSBncmFuZGZhdGhlcmVk IHRhZw0KICAgYWxwaGFudW0gICAgICAgID0gKEFMUEhBIC8gRElHSVQpICAgOyBsZXR0ZXJzIGFu ZCBudW1iZXJzDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBMYW5ndWFnZSBU YWcgQUJORg0KDQogICBUaGUgY2hhcmFjdGVyICItIiBpcyBIWVBIRU4tTUlOVVMgKEFCTkY6ICV4 MkQpLiAgQWxsIHN1YnRhZ3MgaGF2ZSBhDQogICBtYXhpbXVtIGxlbmd0aCBvZiBlaWdodCBjaGFy YWN0ZXJzLiAgTm90ZSB0aGF0IHRoZXJlIGlzIGEgc3VidGxldHkgaW4NCiAgIHRoZSBBQk5GIGZv ciAndmFyaWFudCc6IHZhcmlhbnRzIHN0YXJ0aW5nIHdpdGggYSBkaWdpdCBtYXkgYmUgb25seQ0K ICAgZm91ciBjaGFyYWN0ZXJzIGxvbmcsIHdoaWxlIHRob3NlIHN0YXJ0aW5nIHdpdGggYSBsZXR0 ZXIgbXVzdCBiZSBhdA0KICAgbGVhc3QgZml2ZSBjaGFyYWN0ZXJzIGxvbmcuDQoNCiAgIFdoaXRl c3BhY2UgaXMgbm90IHBlcm1pdHRlZCBpbiBhIGxhbmd1YWdlIHRhZy4gIEZvciBleGFtcGxlcyBv Zg0KICAgbGFuZ3VhZ2UgdGFncywgc2VlIEFwcGVuZGl4IEIuDQoNCiAgIE5vdGUgdGhhdCBhbHRo b3VnaCBbN10gcmVmZXJzIHRvIG9jdGV0cywgdGhlIGxhbmd1YWdlIHRhZ3MgZGVzY3JpYmVkDQog ICBpbiB0aGlzIGRvY3VtZW50IGFyZSBzZXF1ZW5jZXMgb2YgY2hhcmFjdGVycyBmcm9tIHRoZSBV Uy1BU0NJSQ0KICAgcmVwZXJ0b2lyZS4gIExhbmd1YWdlIHRhZ3MgbWF5IGJlIHVzZWQgaW4gZG9j dW1lbnRzIGFuZCBhcHBsaWNhdGlvbnMNCiAgIHRoYXQgdXNlIG90aGVyIGVuY29kaW5ncywgc28g bG9uZyBhcyB0aGVzZSBlbmNvbXBhc3MgdGhlIFVTLUFTQ0lJDQogICByZXBlcnRvaXJlLiAgQW4g ZXhhbXBsZSBvZiB0aGlzIHdvdWxkIGJlIGFuIFhNTCBkb2N1bWVudCB0aGF0IHVzZXMNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAg ICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgdGhlIFVURi0xNkxF IFsxMl0gZW5jb2Rpbmcgb2YgVW5pY29kZSBbMjBdLg0KDQogICBUaGUgdGFncyBhbmQgdGhlaXIg c3VidGFncywgaW5jbHVkaW5nIHByaXZhdGUtdXNlIGFuZCBleHRlbnNpb25zLCBhcmUNCiAgIHRv IGJlIHRyZWF0ZWQgYXMgY2FzZSBpbnNlbnNpdGl2ZTogdGhlcmUgZXhpc3QgY29udmVudGlvbnMg Zm9yIHRoZQ0KICAgY2FwaXRhbGl6YXRpb24gb2Ygc29tZSBvZiB0aGUgc3VidGFncywgYnV0IHRo ZXNlIHNob3VsZCBub3QgYmUgdGFrZW4NCiAgIHRvIGNhcnJ5IG1lYW5pbmcuDQoNCiAgIEZvciBl eGFtcGxlOg0KDQogICBvICBbSVNPIDYzOV0gWzFdIHJlY29tbWVuZHMgdGhhdCBsYW5ndWFnZSBj b2RlcyBiZSB3cml0dGVuIGluIGxvd2VyDQogICAgICBjYXNlICgnbW4nIE1vbmdvbGlhbikuDQoN CiAgIG8gIFtJU08gMzE2Nl0gWzRdIHJlY29tbWVuZHMgdGhhdCBjb3VudHJ5IGNvZGVzIGJlIGNh cGl0YWxpemVkICgnTU4nDQogICAgICBNb25nb2xpYSkuDQoNCiAgIG8gIFtJU08gMTU5MjRdIFsz XSByZWNvbW1lbmRzIHRoYXQgc2NyaXB0IGNvZGVzIHVzZSBsb3dlciBjYXNlIHdpdGgNCiAgICAg IHRoZSBpbml0aWFsIGxldHRlciBjYXBpdGFsaXplZCAoJ0N5cmwnIEN5cmlsbGljKS4NCg0KICAg SG93ZXZlciwgaW4gdGhlIHRhZ3MgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50LCB0aGUgdXBwZXJj YXNlIFVTLUFTQ0lJDQogICBsZXR0ZXJzIGluIHRoZSByYW5nZSAnQScgdGhyb3VnaCAnWicgYXJl IGNvbnNpZGVyZWQgZXF1aXZhbGVudCBhbmQNCiAgIG1hcHBlZCBkaXJlY3RseSB0byB0aGVpciBV Uy1BU0NJSSBsb3dlcmNhc2UgZXF1aXZhbGVudHMgaW4gdGhlIHJhbmdlDQogICAnYScgdGhyb3Vn aCAneicuICBUaHVzIHRoZSB0YWcgIm1uLUN5cmwtTU4iIGlzIG5vdCBkaXN0aW5jdCBmcm9tICJN Ti0NCiAgIGNZUkwtbW4iIG9yICJtTi1jWXJMLU1uIiAob3IgYW55IG90aGVyIGNvbWJpbmF0aW9u KSBhbmQgZWFjaCBvZiB0aGVzZQ0KICAgdmFyaWF0aW9ucyBjb252ZXlzIHRoZSBzYW1lIG1lYW5p bmc6IE1vbmdvbGlhbiB3cml0dGVuIGluIHRoZQ0KICAgQ3lyaWxsaWMgc2NyaXB0IGFzIHVzZWQg aW4gTW9uZ29saWEuDQoNCjIuMS4xICBMZW5ndGggQ29uc2lkZXJhdGlvbnMNCg0KICAgQWx0aG91 Z2ggbmVpdGhlciB0aGUgQUJORiBub3Igb3RoZXIgZ3VpZGVsaW5lcyBpbiB0aGlzIGRvY3VtZW50 DQogICBwcm92aWRlIGEgZml4ZWQgdXBwZXIgbGltaXQgb24gdGhlIG51bWJlciBvZiBzdWJ0YWdz IGluIGEgTGFuZ3VhZ2UNCiAgIFRhZyAoYW5kIHRodXMgdGhlIHVwcGVyIGJvdW5kIG9uIHRoZSBz aXplIG9mIGEgdGFnKSBhbmQgaXQgaXMNCiAgIHBvc3NpYmxlIHRvIGVudmlzaW9uIHF1aXRlIGxv bmcgYW5kIGNvbXBsZXggc3VidGFnIHNlcXVlbmNlcywgaW4NCiAgIHByYWN0aWNlIHRoZXNlIGFy ZSByYXJlIGJlY2F1c2UgYWRkaXRpb25hbCBncmFudWxhcml0eSBpbiB0YWdzIHNlbGRvbQ0KICAg YWRkcyB1c2VmdWwgZGlzdGluZ3Vpc2hpbmcgaW5mb3JtYXRpb24gYW5kIGJlY2F1c2UgbG9uZ2Vy LCBtb3JlDQogICBncmFudWxhciB0YWdzIGludGVyZWZlcmUgd2l0aCB0aGUgbWVhbmluZywgdW5k ZXJzdGFuZGluZywgYW5kDQogICBwcm9jZXNzaW5nIG9mIGxhbmd1YWdlIHRhZ3MuDQoNCiAgIElu IHBhcnRpY3VsYXIsICB2YXJpYW50IHN1YnRhZ3MgU0hPVUxEIGJlIHVzZWQgb25seSB3aXRoIHRo ZWlyDQogICByZWNvbW1lbmRlZCBwcmVmaXguICBJbiBwcmFjdGljZSwgdGhpcyBsaW1pdHMgbW9z dCB0YWdzIHRvIGEgc2VxdWVuY2UNCiAgIG9mIGZvdXIgc3VidGFncywgYW5kIHRodXMgYSBtYXhp bXVtIGxlbmd0aCBvZiAyNiBjaGFyYWN0ZXJzDQogICAoZXhjbHVkaW5nIGFueSBleHRlbnNpb25z IG9yIHByaXZhdGUgdXNlIHNlcXVlbmNlcykuICBUaGlzIGlzIGJlY2F1c2UNCiAgIHN1YnRhZ3Mg YXJlIGxpbWl0ZWQgdG8gYSBsZW5ndGggb2YgZWlnaHQgY2hhcmFjdGVycyBhbmQgdGhlIGV4dGxh bmcsDQogICBzY3JpcHQsIGFuZCByZWdpb24gc3VidGFncyBhcmUgbGltaXRlZCB0byBldmVuIGZl d2VyIGNoYXJhY3RlcnMuICBTZWUNCiAgIFNlY3Rpb24gNC4xIGZvciBtb3JlIGluZm9ybWF0aW9u IG9uIHNlbGVjdGluZyB0aGUgbW9zdCBhcHByb3ByaWF0ZQ0KICAgTGFuZ3VhZ2UgVGFnLg0KDQog ICBBIGNvbmZvcm1hbnQgaW1wbGVtZW50YXRpb24gTUFZIHJlZnVzZSB0byBzdXBwb3J0IHRoZSBz dG9yYWdlIG9mDQogICBsYW5ndWFnZSB0YWdzIHdoaWNoIGV4Y2VlZCBhIHNwZWNpZmllZCBsZW5n dGguICBGb3IgYW4gZXhhbXBsZSwgc2VlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg QXByaWwgMjAwNQ0KDQoNCiAgIFtSRkMgMjIzMV0gWzIyXS4gIEFueSBzdWNoIGxpbWl0YXRpb24g TVVTVCBiZSBjbGVhcmx5IGRvY3VtZW50ZWQsIGFuZA0KICAgc3VjaCBkb2N1bWVudGF0aW9uIFNI T1VMRCBpbmNsdWRlIHRoZSBkaXNwb3NpdGlvbiBvZiBhbnkgbG9uZ2VyIHRhZ3MNCiAgIChmb3Ig ZXhhbXBsZSwgd2hldGhlciBhbiBlcnJvciB2YWx1ZSBpcyBnZW5lcmF0ZWQgb3IgdGhlIGxhbmd1 YWdlIHRhZw0KICAgaXMgdHJ1bmNhdGVkKS4gIElmIHRydW5jYXRpb24gaXMgcGVybWl0dGVkIGl0 IFNIT1VMRCBOT1QgcGVybWl0IGENCiAgIHN1YnRhZyB0byBiZSBkaXZpZGVkLg0KDQoyLjIgIExh bmd1YWdlIFN1YnRhZyBTb3VyY2VzIGFuZCBJbnRlcnByZXRhdGlvbg0KDQogICBUaGUgbmFtZXNw YWNlIG9mIGxhbmd1YWdlIHRhZ3MgYW5kIHRoZWlyIHN1YnRhZ3MgaXMgYWRtaW5pc3RlcmVkIGJ5 DQogICB0aGUgSW50ZXJuZXQgQXNzaWduZWQgTnVtYmVycyBBdXRob3JpdHkgKElBTkEpIFsxM10g YWNjb3JkaW5nIHRvIHRoZQ0KICAgcnVsZXMgaW4gU2VjdGlvbiA1IG9mIHRoaXMgZG9jdW1lbnQu ICBUaGUgcmVnaXN0cnkgbWFpbnRhaW5lZCBieSBJQU5BDQogICBpcyB0aGUgc291cmNlIGZvciB2 YWxpZCBzdWJ0YWdzOiBvdGhlciBzdGFuZGFyZHMgcmVmZXJlbmNlZCBpbiB0aGlzDQogICBzZWN0 aW9uIHByb3ZpZGUgdGhlIHNvdXJjZSBtYXRlcmlhbCBmb3IgdGhhdCByZWdpc3RyeS4NCg0KICAg VGVybWlub2xvZ3kgaW4gdGhpcyBzZWN0aW9uOg0KDQogICBvICBUYWcgb3IgdGFncyByZWZlcnMg dG8gYSBjb21wbGV0ZSBsYW5ndWFnZSB0YWcsIHN1Y2ggYXMNCiAgICAgICJmci1MYXRuLUNBIi4g IEV4YW1wbGVzIG9mIHRhZ3MgaW4gdGhpcyBkb2N1bWVudCBhcmUgZW5jbG9zZWQgaW4NCiAgICAg IGRvdWJsZS1xdW90ZXMgKCJlbi1VUyIpLg0KDQogICBvICBTdWJ0YWcgcmVmZXJzIHRvIGEgc3Bl Y2lmaWMgc2VjdGlvbiBvZiBhIHRhZywgZGVsaW1pdGVkIGJ5IGh5cGhlbiwNCiAgICAgIHN1Y2gg YXMgdGhlIHN1YnRhZyAnTGF0bicgaW4gImZyLUxhdG4tQ0EiLiAgRXhhbXBsZXMgb2Ygc3VidGFn cyBpbg0KICAgICAgdGhpcyBkb2N1bWVudCBhcmUgZW5jbG9zZWQgaW4gc2luZ2xlIHF1b3RlcyAo J0xhdG4nKS4NCg0KICAgbyAgQ29kZSBvciBjb2RlcyByZWZlcnMgdG8gdmFsdWVzIGRlZmluZWQg aW4gZXh0ZXJuYWwgc3RhbmRhcmRzIChhbmQNCiAgICAgIHdoaWNoIGFyZSB1c2VkIGFzIHN1YnRh Z3MgaW4gdGhpcyBkb2N1bWVudCkuICBGb3IgZXhhbXBsZSwgJ0xhdG4nDQogICAgICBpcyBhbiBb SVNPIDE1OTI0XSBbM10gc2NyaXB0IGNvZGUgd2hpY2ggd2FzIHVzZWQgdG8gZGVmaW5lIHRoZQ0K ICAgICAgJ0xhdG4nIHNjcmlwdCBzdWJ0YWcgZm9yIHVzZSBpbiBhIGxhbmd1YWdlIHRhZy4gIEV4 YW1wbGVzIG9mIGNvZGVzDQogICAgICBpbiB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbiBz aW5nbGUgcXVvdGVzICgnZW4nLCAnTGF0bicpLg0KDQogICBUaGUgZGVmaW5pdGlvbnMgaW4gdGhp cyBzZWN0aW9uIGFwcGx5IHRvIHRoZSB2YXJpb3VzIHN1YnRhZ3Mgd2l0aGluDQogICB0aGUgbGFu Z3VhZ2UgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQsIGV4Y2VwdGluZyB0aG9zZQ0KICAg ImdyYW5kZmF0aGVyZWQiIHRhZ3MgZGVmaW5lZCBpbiBTZWN0aW9uIDIuMi44Lg0KDQogICBMYW5n dWFnZSB0YWdzIGFyZSBkZXNpZ25lZCBzbyB0aGF0IGVhY2ggc3VidGFnIHR5cGUgaGFzIHVuaXF1 ZSBsZW5ndGgNCiAgIGFuZCBjb250ZW50IHJlc3RyaWN0aW9ucy4gIFRoZXNlIG1ha2UgaWRlbnRp ZmljYXRpb24gb2YgdGhlIHN1YnRhZydzDQogICB0eXBlIHBvc3NpYmxlLCBldmVuIGlmIHRoZSBj b250ZW50IG9mIHRoZSBzdWJ0YWcgaXRzZWxmIGlzDQogICB1bnJlY29nbml6ZWQuICBUaGlzIGFs bG93cyB0YWdzIHRvIGJlIHBhcnNlZCBhbmQgcHJvY2Vzc2VkIHdpdGhvdXQNCiAgIHJlZmVyZW5j ZSB0byB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIHVuZGVybHlpbmcgc3RhbmRhcmRzIG9yIHRo ZQ0KICAgSUFOQSByZWdpc3RyeSBhbmQgbWFrZXMgdGhlIGFzc29jaWF0ZWQgZXhjZXB0aW9uIGhh bmRsaW5nIHdoZW4NCiAgIHBhcnNpbmcgdGFncyBzaW1wbGVyLg0KDQogICBTdWJ0YWdzIGluIHRo ZSBJQU5BIHJlZ2lzdHJ5IHRoYXQgZG8gbm90IGNvbWUgZnJvbSBhbiB1bmRlcmx5aW5nDQogICBz dGFuZGFyZCBjYW4gb25seSBhcHBlYXIgaW4gc3BlY2lmaWMgcG9zaXRpb25zIGluIGEgdGFnLg0K ICAgU3BlY2lmaWNhbGx5LCB0aGV5IGNhbiBvbmx5IG9jY3VyIGFzIHByaW1hcnkgbGFuZ3VhZ2Ug c3VidGFncyBvciBhcw0KICAgdmFyaWFudCBzdWJ0YWdzLg0KDQogICBOb3RlIHRoYXQgc2VxdWVu Y2VzIG9mIHByaXZhdGUtdXNlIGFuZCBleHRlbnNpb24gc3VidGFncyBNVVNUIG9jY3VyDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAg ICAgICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIGF0IHRoZSBlbmQg b2YgdGhlIHNlcXVlbmNlIG9mIHN1YnRhZ3MgYW5kIE1VU1QgTk9UIGJlIGludGVyc3BlcnNlZA0K ICAgd2l0aCBzdWJ0YWdzIGRlZmluZWQgZWxzZXdoZXJlIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAg IFNpbmdsZSBsZXR0ZXIgYW5kIGRpZ2l0IHN1YnRhZ3MgYXJlIHJlc2VydmVkIGZvciBjdXJyZW50 IG9yIGZ1dHVyZQ0KICAgdXNlLiAgVGhlc2UgaW5jbHVkZSB0aGUgZm9sbG93aW5nIGN1cnJlbnQg dXNlczoNCg0KICAgbyAgVGhlIHNpbmdsZSBsZXR0ZXIgc3VidGFnICd4JyBpcyByZXNlcnZlZCB0 byBpbnRyb2R1Y2UgYSBzZXF1ZW5jZQ0KICAgICAgb2YgcHJpdmF0ZS11c2Ugc3VidGFncy4gIFRo ZSBpbnRlcnByZXRhdGlvbiBvZiBhbnkgcHJpdmF0ZS11c2UNCiAgICAgIHN1YnRhZ3MgaXMgZGVm aW5lZCBzb2xlbHkgYnkgcHJpdmF0ZSBhZ3JlZW1lbnQgYW5kIGlzIG5vdCBkZWZpbmVkDQogICAg ICBieSB0aGUgcnVsZXMgaW4gdGhpcyBzZWN0aW9uIG9yIGluIGFueSBzdGFuZGFyZCBvciByZWdp c3RyeQ0KICAgICAgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICBvICBBbGwgb3RoZXIg c2luZ2xlIGxldHRlciBzdWJ0YWdzIGFyZSByZXNlcnZlZCB0byBpbnRyb2R1Y2UNCiAgICAgIHN0 YW5kYXJkaXplZCBleHRlbnNpb24gc3VidGFnIHNlcXVlbmNlcyBhcyBkZXNjcmliZWQgaW4NCiAg ICAgIFNlY3Rpb24gMy42Lg0KDQogICBUaGUgc2luZ2xlIGxldHRlciBzdWJ0YWcgJ2knIGlzIHVz ZWQgYnkgc29tZSBncmFuZGZhdGhlcmVkIHRhZ3MsIHN1Y2gNCiAgIGFzICJpLWVub2NoaWFuIiwg d2hlcmUgaXQgYWx3YXlzIGFwcGVhcnMgaW4gdGhlIGZpcnN0IHBvc2l0aW9uIGFuZA0KICAgY2Fu bm90IGJlIGNvbmZ1c2VkIHdpdGggYW4gZXh0ZW5zaW9uLg0KDQoyLjIuMSAgUHJpbWFyeSBMYW5n dWFnZSBTdWJ0YWcNCg0KICAgVGhlIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGlzIHRoZSBmaXJz dCBzdWJ0YWcgaW4gYSBsYW5ndWFnZSB0YWcNCiAgICh3aXRoIHRoZSBleGNlcHRpb24gb2YgcHJp dmF0ZS11c2UgYW5kIGNlcnRhaW4gZ3JhbmRmYXRoZXJlZCB0YWdzKQ0KICAgYW5kIGNhbm5vdCBi ZSBvbWl0dGVkLiAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUgcHJpbWFyeQ0KICAg bGFuZ3VhZ2Ugc3VidGFnOg0KDQogICAxLiAgQWxsIHR3byBjaGFyYWN0ZXIgbGFuZ3VhZ2Ugc3Vi dGFncyB3ZXJlIGRlZmluZWQgaW4gdGhlIElBTkENCiAgICAgICByZWdpc3RyeSBhY2NvcmRpbmcg dG8gdGhlIGFzc2lnbm1lbnRzIGZvdW5kIGluIHRoZSBzdGFuZGFyZCBJU08NCiAgICAgICA2Mzkg UGFydCAxLCAiSVNPIDYzOS0xOjIwMDIsIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YN CiAgICAgICBuYW1lcyBvZiBsYW5ndWFnZXMgLS0gUGFydCAxOiBBbHBoYS0yIGNvZGUiIFtJU08g NjM5LTFdIFsxXSwgb3INCiAgICAgICB1c2luZyBhc3NpZ25tZW50cyBzdWJzZXF1ZW50bHkgbWFk ZSBieSB0aGUgSVNPIDYzOSBQYXJ0IDENCiAgICAgICBtYWludGVuYW5jZSBhZ2VuY3kgb3IgZ292 ZXJuaW5nIHN0YW5kYXJkaXphdGlvbiBib2RpZXMuDQoNCiAgIDIuICBBbGwgdGhyZWUgY2hhcmFj dGVyIGxhbmd1YWdlIHN1YnRhZ3Mgd2VyZSBkZWZpbmVkIGluIHRoZSBJQU5BDQogICAgICAgcmVn aXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3VuZCBpbiBJU08gNjM5IFBhcnQg MiwNCiAgICAgICAiSVNPIDYzOS0yOjE5OTggLSBDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9u IG9mIG5hbWVzIG9mDQogICAgICAgbGFuZ3VhZ2VzIC0tIFBhcnQgMjogQWxwaGEtMyBjb2RlIC0g ZWRpdGlvbiAxIiBbSVNPIDYzOS0yXSBbMl0sDQogICAgICAgb3IgYXNzaWdubWVudHMgc3Vic2Vx dWVudGx5IG1hZGUgYnkgdGhlIElTTyA2MzkgUGFydCAyDQogICAgICAgbWFpbnRlbmFuY2UgYWdl bmN5IG9yIGdvdmVybmluZyBzdGFuZGFyZGl6YXRpb24gYm9kaWVzLg0KDQogICAzLiAgVGhlIHN1 YnRhZ3MgaW4gdGhlIHJhbmdlICdxYWEnIHRocm91Z2ggJ3F0eicgYXJlIHJlc2VydmVkIGZvcg0K ICAgICAgIHByaXZhdGUgdXNlIGluIGxhbmd1YWdlIHRhZ3MuICBUaGVzZSBzdWJ0YWdzIGNvcnJl c3BvbmQgdG8gY29kZXMNCiAgICAgICByZXNlcnZlZCBieSBJU08gNjM5LTIgZm9yIHByaXZhdGUg dXNlLiAgVGhlc2UgY29kZXMgTUFZIGJlIHVzZWQNCiAgICAgICBmb3Igbm9uLXJlZ2lzdGVyZWQg cHJpbWFyeS1sYW5ndWFnZSBzdWJ0YWdzIChpbnN0ZWFkIG9mIHVzaW5nDQogICAgICAgcHJpdmF0 ZS11c2Ugc3VidGFncyBmb2xsb3dpbmcgJ3gtJykuICBQbGVhc2UgcmVmZXIgdG8gU2VjdGlvbiA0 LjQNCiAgICAgICBmb3IgbW9yZSBpbmZvcm1hdGlvbiBvbiBwcml2YXRlIHVzZSBzdWJ0YWdzLg0K DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUg ICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIDQuICBB bGwgZm91ciBjaGFyYWN0ZXIgbGFuZ3VhZ2Ugc3VidGFncyBhcmUgcmVzZXJ2ZWQgZm9yIHBvc3Np YmxlDQogICAgICAgZnV0dXJlIHN0YW5kYXJkaXphdGlvbi4NCg0KICAgNS4gIEFsbCBsYW5ndWFn ZSBzdWJ0YWdzIG9mIDUgdG8gOCBjaGFyYWN0ZXJzIGluIGxlbmd0aCBpbiB0aGUgSUFOQQ0KICAg ICAgIHJlZ2lzdHJ5IHdlcmUgZGVmaW5lZCB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzIGlu IFNlY3Rpb24gMy40DQogICAgICAgYW5kIE1BWSBiZSB1c2VkIHRvIGZvcm0gdGhlIHByaW1hcnkg bGFuZ3VhZ2Ugc3VidGFnLiAgQXQgdGhlIHRpbWUNCiAgICAgICB0aGlzIGRvY3VtZW50IHdhcyBj cmVhdGVkLCB0aGVyZSB3ZXJlIG5vIGV4YW1wbGVzIG9mIHRoaXMga2luZCBvZg0KICAgICAgIHN1 YnRhZyBhbmQgZnV0dXJlIHJlZ2lzdHJhdGlvbnMgb2YgdGhpcyB0eXBlIHdpbGwgYmUgZGlzY291 cmFnZWQ6DQogICAgICAgcHJpbWFyeSBsYW5ndWFnZXMgYXJlIFNUUk9OR0xZIFJFQ09NTUVOREVE IGZvciByZWdpc3RyYXRpb24gd2l0aA0KICAgICAgIElTTyA2MzkgYW5kIHByb3Bvc2FscyByZWpl Y3RlZCBieSBJU08gNjM5L1JBIHdpbGwgYmUgY2xvc2VseQ0KICAgICAgIHNjcnV0aW5pemVkIGJl Zm9yZSB0aGV5IGFyZSByZWdpc3RlcmVkIHdpdGggSUFOQS4NCg0KICAgNi4gIFRoZSBzaW5nbGUg Y2hhcmFjdGVyIHN1YnRhZyAneCcgYXMgdGhlIHByaW1hcnkgc3VidGFnIGluZGljYXRlcw0KICAg ICAgIHRoYXQgdGhlIGxhbmd1YWdlIHRhZyBjb25zaXN0cyBzb2xlbHkgb2Ygc3VidGFncyB3aG9z ZSBtZWFuaW5nIGlzDQogICAgICAgZGVmaW5lZCBieSBwcml2YXRlIGFncmVlbWVudC4gIEZvciBl eGFtcGxlLCBpbiB0aGUgdGFnICJ4LWZyLUNIIiwNCiAgICAgICB0aGUgc3VidGFncyAnZnInIGFu ZCAnQ0gnIHNob3VsZCBub3QgYmUgdGFrZW4gdG8gcmVwcmVzZW50IHRoZQ0KICAgICAgIEZyZW5j aCBsYW5ndWFnZSBvciB0aGUgY291bnRyeSBvZiBTd2l0emVybGFuZCAob3IgYW55IG90aGVyIHZh bHVlDQogICAgICAgaW4gdGhlIElBTkEgcmVnaXN0cnkpIHVubGVzcyB0aGVyZSBpcyBhIHByaXZh dGUgYWdyZWVtZW50IGluDQogICAgICAgcGxhY2UgdG8gZG8gc28uICBTZWUgU2VjdGlvbiA0LjQu DQoNCiAgIDcuICBUaGUgc2luZ2xlIGNoYXJhY3RlciBzdWJ0YWcgJ2knIGlzIHVzZWQgYnkgc29t ZSBncmFuZGZhdGhlcmVkDQogICAgICAgdGFncyAoc2VlIFNlY3Rpb24gMi4yLjgpIHN1Y2ggYXMg Imkta2xpbmdvbiIgYW5kICJpLWJubiIuICAoT3RoZXINCiAgICAgICBncmFuZGZhdGhlcmVkIHRh Z3MgaGF2ZSBhIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGluIHRoZWlyIGZpcnN0DQogICAgICAg cG9zaXRpb24pDQoNCiAgIDguICBPdGhlciB2YWx1ZXMgTVVTVCBOT1QgYmUgYXNzaWduZWQgdG8g dGhlIHByaW1hcnkgc3VidGFnIGV4Y2VwdCBieQ0KICAgICAgIHJldmlzaW9uIG9yIHVwZGF0ZSBv ZiB0aGlzIGRvY3VtZW50Lg0KDQogICBOb3RlOiBGb3IgbGFuZ3VhZ2VzIHRoYXQgaGF2ZSBib3Ro IGFuIElTTyA2MzktMSB0d28gY2hhcmFjdGVyIGNvZGUNCiAgIGFuZCBhbiBJU08gNjM5LTIgdGhy ZWUgY2hhcmFjdGVyIGNvZGUsIG9ubHkgdGhlIElTTyA2MzktMSB0d28NCiAgIGNoYXJhY3RlciBj b2RlIGlzIGRlZmluZWQgaW4gdGhlIElBTkEgcmVnaXN0cnkuDQoNCiAgIE5vdGU6IEZvciBsYW5n dWFnZXMgdGhhdCBoYXZlIG5vIElTTyA2MzktMSB0d28gY2hhcmFjdGVyIGNvZGUgYW5kIGZvcg0K ICAgd2hpY2ggdGhlIElTTyA2MzktMi9UIChUZXJtaW5vbG9neSkgY29kZSBhbmQgdGhlIElTTyA2 MzktMi9CDQogICAoQmlibGlvZ3JhcGhpYykgY29kZXMgZGlmZmVyLCBvbmx5IHRoZSBUZXJtaW5v bG9neSBjb2RlIGlzIGRlZmluZWQgaW4NCiAgIHRoZSBJQU5BIHJlZ2lzdHJ5LiAgQXQgdGhlIHRp bWUgdGhpcyBkb2N1bWVudCB3YXMgY3JlYXRlZCwgYWxsDQogICBsYW5ndWFnZXMgdGhhdCBoYWQg Ym90aCBraW5kcyBvZiB0aHJlZSBjaGFyYWN0ZXIgY29kZSB3ZXJlIGFsc28NCiAgIGFzc2lnbmVk IGEgdHdvIGNoYXJhY3RlciBjb2RlOyBpdCBpcyBub3QgZXhwZWN0ZWQgdGhhdCBmdXR1cmUNCiAg IGFzc2lnbm1lbnRzIG9mIHRoaXMgbmF0dXJlIHdpbGwgb2NjdXIuDQoNCiAgIE5vdGU6IFRvIGF2 b2lkIHByb2JsZW1zIHdpdGggdmVyc2lvbmluZyBhbmQgc3VidGFnIGNob2ljZSBhcw0KICAgZXhw ZXJpZW5jZWQgZHVyaW5nIHRoZSB0cmFuc2l0aW9uIGJldHdlZW4gUkZDIDE3NjYgYW5kIFJGQyAz MDY2LCBhcw0KICAgd2VsbCBhcyB0aGUgY2Fub25pY2FsIG5hdHVyZSBvZiBzdWJ0YWdzIGRlZmlu ZWQgYnkgdGhpcyBkb2N1bWVudCwgdGhlDQogICBJU08gNjM5IFJlZ2lzdHJhdGlvbiBBdXRob3Jp dHkgSm9pbnQgQWR2aXNvcnkgQ29tbWl0dGVlIChJU08gNjM5Lw0KICAgUkEtSkFDKSBoYXMgaW5j bHVkZWQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaW4gWzE2XToNCg0KICAgIkEgbGFuZ3VhZ2Ug Y29kZSBhbHJlYWR5IGluIElTTyA2MzktMiBhdCB0aGUgcG9pbnQgb2YgZnJlZXppbmcgSVNPDQog ICA2MzktMSBzaGFsbCBub3QgbGF0ZXIgYmUgYWRkZWQgdG8gSVNPIDYzOS0xLiAgVGhpcyBpcyB0 byBlbnN1cmUNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAy OCwgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0K ICAgY29uc2lzdGVuY3kgaW4gdXNhZ2Ugb3ZlciB0aW1lLCBzaW5jZSB1c2VycyBhcmUgZGlyZWN0 ZWQgaW4gSW50ZXJuZXQNCiAgIGFwcGxpY2F0aW9ucyB0byBlbXBsb3kgdGhlIGFscGhhLTMgY29k ZSB3aGVuIGFuIGFscGhhLTIgY29kZSBmb3IgdGhhdA0KICAgbGFuZ3VhZ2UgaXMgbm90IGF2YWls YWJsZS4iDQoNCiAgIEluIG9yZGVyIHRvIGF2b2lkIGluc3RhYmlsaXR5IG9mIHRoZSBjYW5vbmlj YWwgZm9ybSBvZiB0YWdzLCBpZiBhIHR3bw0KICAgY2hhcmFjdGVyIGNvZGUgaXMgYWRkZWQgdG8g SVNPIDYzOS0xIGZvciBhIGxhbmd1YWdlIGZvciB3aGljaCBhIHRocmVlDQogICBjaGFyYWN0ZXIg Y29kZSB3YXMgYWxyZWFkeSBpbmNsdWRlZCBpbiBJU08gNjM5LTIsIHRoZSB0d28gY2hhcmFjdGVy DQogICBjb2RlIHdpbGwgbm90IGJlIGFkZGVkIGFzIGEgc3VidGFnIGluIHRoZSByZWdpc3RyeS4g IFNlZSBTZWN0aW9uIDMuMy4NCg0KICAgRm9yIGV4YW1wbGUsIGlmIHNvbWUgY29udGVudCB3ZXJl IHRhZ2dlZCB3aXRoICdoYXcnIChIYXdhaWlhbiksIHdoaWNoDQogICBjdXJyZW50bHkgaGFzIG5v IHR3byBjaGFyYWN0ZXIgY29kZSwgdGhlIHRhZyB3b3VsZCBub3QgYmUgaW52YWxpZGF0ZWQNCiAg IGlmIElTTyA2MzktMSB3ZXJlIHRvIGFzc2lnbiBhIHR3byBjaGFyYWN0ZXIgY29kZSB0byB0aGUg SGF3YWlpYW4NCiAgIGxhbmd1YWdlIGF0IGEgbGF0ZXIgZGF0ZS4NCg0KICAgRm9yIGV4YW1wbGUs IG9uZSBvZiB0aGUgZ3JhbmRmYXRoZXJlZCBJQU5BIHJlZ2lzdHJhdGlvbnMgaXMNCiAgICJpLWVu b2NoaWFuIi4gIFRoZSBzdWJ0YWcgJ2Vub2NoaWFuJyBjb3VsZCBiZSByZWdpc3RlcmVkIGluIHRo ZSBJQU5BDQogICByZWdpc3RyeSBhcyBhIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIChhc3N1bWlu ZyB0aGF0IElTTyA2MzkgZG9lcyBub3QNCiAgIHJlZ2lzdGVyIHRoaXMgbGFuZ3VhZ2UgZmlyc3Qp LCBtYWtpbmcgdGFncyBzdWNoIGFzICJlbm9jaGlhbi1BUSIgYW5kDQogICAiZW5vY2hpYW4tTGF0 biIgdmFsaWQuDQoNCjIuMi4yICBFeHRlbmRlZCBMYW5ndWFnZSBTdWJ0YWdzDQoNCiAgIFRoZSBm b2xsb3dpbmcgcnVsZXMgYXBwbHkgdG8gdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3M6DQoN CiAgIDEuICBUaHJlZSBsZXR0ZXIgc3VidGFncyBpbW1lZGlhdGVseSBmb2xsb3dpbmcgdGhlIHBy aW1hcnkgc3VidGFnIGFyZQ0KICAgICAgIHJlc2VydmVkIGZvciBmdXR1cmUgc3RhbmRhcmRpemF0 aW9uLCBhbnRpY2lwYXRpbmcgd29yayB0aGF0IGlzDQogICAgICAgY3VycmVudGx5IHVuZGVyIHdh eSBvbiBJU08gNjM5Lg0KDQogICAyLiAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBNVVNUIGZv bGxvdyB0aGUgcHJpbWFyeSBzdWJ0YWcgYW5kDQogICAgICAgcHJlY2VkZSBhbnkgb3RoZXIgc3Vi dGFncy4NCg0KICAgMy4gIFRoZXJlIE1BWSBiZSBhbnkgYWRkaXRpb25hbCBudW1iZXIgb2YgZXh0 ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncy4NCg0KICAgNC4gIEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRh Z3Mgd2lsbCBub3QgYmUgcmVnaXN0ZXJlZCBleGNlcHQgYnkNCiAgICAgICByZXZpc2lvbiBvZiB0 aGlzIGRvY3VtZW50Lg0KDQogICA1LiAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyBNVVNUIE5P VCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncw0KICAgICAgIGV4Y2VwdCBieSByZXZpc2lv biBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBFeGFtcGxlOiBJbiBhIGZ1dHVyZSByZXZpc2lvbiBv ciB1cGRhdGUgb2YgdGhpcyBkb2N1bWVudCwgdGhlIHRhZw0KICAgInpoLWdhbiIgKHJlZ2lzdGVy ZWQgdW5kZXIgUkZDIDMwNjYpIG1pZ2h0IGJlY29tZSBhIHZhbGlkIG5vbi0NCiAgIGdyYW5kZmF0 aGVyZWQgKHRoYXQgaXMsIHJlZHVuZGFudCkgdGFnIGluIHdoaWNoIHRoZSBzdWJ0YWcgJ2dhbicN CiAgIG1pZ2h0IHJlcHJlc2VudCB0aGUgQ2hpbmVzZSBkaWFsZWN0ICdHYW4nLg0KDQoyLjIuMyAg U2NyaXB0IFN1YnRhZw0KDQogICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5IHRvIHRoZSBzY3Jp cHQgc3VidGFnczoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3Rv YmVyIDI4LCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUN Cg0KDQogICAxLiAgQWxsIGZvdXIgY2hhcmFjdGVyIHN1YnRhZ3Mgd2VyZSBkZWZpbmVkIGFjY29y ZGluZyB0byBJU08gMTU5MjQNCiAgICAgICBbM10tLSJDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0 aW9uIG9mIHRoZSBuYW1lcyBvZiBzY3JpcHRzIjoNCiAgICAgICBhbHBoYS00IHNjcmlwdCBjb2Rl cywgb3Igc3Vic2VxdWVudGx5IGFzc2lnbmVkIGJ5IHRoZSBJU08gMTU5MjQNCiAgICAgICBtYWlu dGVuYW5jZSBhZ2VuY3kgb3IgZ292ZXJuaW5nIHN0YW5kYXJkaXphdGlvbiBib2RpZXMsIGRlbm90 aW5nDQogICAgICAgdGhlIHNjcmlwdCBvciB3cml0aW5nIHN5c3RlbSB1c2VkIGluIGNvbmp1bmN0 aW9uIHdpdGggdGhpcw0KICAgICAgIGxhbmd1YWdlLg0KDQogICAyLiAgU2NyaXB0IHN1YnRhZ3Mg TVVTVCBpbW1lZGlhdGVseSBmb2xsb3cgdGhlIHByaW1hcnkgbGFuZ3VhZ2UNCiAgICAgICBzdWJ0 YWcgYW5kIGFsbCBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIGFuZCBNVVNUIG9jY3VyIGJlZm9y ZQ0KICAgICAgIGFueSBvdGhlciB0eXBlIG9mIHN1YnRhZyBkZXNjcmliZWQgYmVsb3cuDQoNCiAg IDMuICBUaGUgc2NyaXB0IHN1YnRhZ3MgJ1FhYWEnIHRocm91Z2ggJ1FhYngnIGFyZSByZXNlcnZl ZCBmb3IgcHJpdmF0ZQ0KICAgICAgIHVzZSBpbiBsYW5ndWFnZSB0YWdzLiAgVGhlc2Ugc3VidGFn cyBjb3JyZXNwb25kIHRvIGNvZGVzIHJlc2VydmVkDQogICAgICAgYnkgSVNPIDE1OTI0IGZvciBw cml2YXRlIHVzZS4gIFRoZXNlIGNvZGVzIE1BWSBiZSB1c2VkIGZvciBub24tDQogICAgICAgcmVn aXN0ZXJlZCBzY3JpcHQgdmFsdWVzLiAgUGxlYXNlIHJlZmVyIHRvIFNlY3Rpb24gNC40IGZvciBt b3JlDQogICAgICAgaW5mb3JtYXRpb24gb24gcHJpdmF0ZS11c2Ugc3VidGFncy4NCg0KICAgNC4g IFNjcmlwdCBzdWJ0YWdzIGNhbm5vdCBiZSByZWdpc3RlcmVkIHVzaW5nIHRoZSBwcm9jZXNzIGlu DQogICAgICAgU2VjdGlvbiAzLjQgb2YgdGhpcyBkb2N1bWVudC4gIFZhcmlhbnQgc3VidGFncyBt YXkgYmUgY29uc2lkZXJlZA0KICAgICAgIGZvciByZWdpc3RyYXRpb24gZm9yIHRoYXQgcHVycG9z ZS4NCg0KICAgRXhhbXBsZTogImRlLUxhdG4iIHJlcHJlc2VudHMgR2VybWFuIHdyaXR0ZW4gdXNp bmcgdGhlIExhdGluIHNjcmlwdC4NCg0KMi4yLjQgIFJlZ2lvbiBTdWJ0YWcNCg0KICAgVGhlIGZv bGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUgcmVnaW9uIHN1YnRhZ3M6DQoNCiAgIDEuICBUaGUg cmVnaW9uIHN1YnRhZyBkZWZpbmVzIGxhbmd1YWdlIHZhcmlhdGlvbnMgdXNlZCBpbiBhIHNwZWNp ZmljDQogICAgICAgcmVnaW9uLCBnZW9ncmFwaGljLCBvciBwb2xpdGljYWwgYXJlYS4gIFJlZ2lv biBzdWJ0YWdzIE1VU1QNCiAgICAgICBmb2xsb3cgYW55IGxhbmd1YWdlLCBleHRlbmRlZCBsYW5n dWFnZSwgb3Igc2NyaXB0IHN1YnRhZ3MgYW5kDQogICAgICAgTVVTVCBwcmVjZWRlIGFsbCBvdGhl ciBzdWJ0YWdzLg0KDQogICAyLiAgQWxsIHR3byBjaGFyYWN0ZXIgc3VidGFncyBmb2xsb3dpbmcg dGhlIHByaW1hcnkgc3VidGFnIHdlcmUNCiAgICAgICBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lz dHJ5IGFjY29yZGluZyB0byB0aGUgYXNzaWdubWVudHMgZm91bmQNCiAgICAgICBpbiBJU08gMzE2 NiBbNF0tLSJDb2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mDQogICAgICAg Y291bnRyaWVzIGFuZCB0aGVpciBzdWJkaXZpc2lvbnMgLSBQYXJ0IDE6IENvdW50cnkNCiAgICAg ICBjb2RlcyItLWFscGhhLTIgY291bnRyeSBjb2RlcyBvciBhc3NpZ25tZW50cyBzdWJzZXF1ZW50 bHkgbWFkZSBieQ0KICAgICAgIHRoZSBJU08gMzE2NiBtYWludGVuYW5jZSBhZ2VuY3kgb3IgZ292 ZXJuaW5nIHN0YW5kYXJkaXphdGlvbg0KICAgICAgIGJvZGllcy4NCg0KICAgMy4gIEFsbCB0aHJl ZSBjaGFyYWN0ZXIgY29kZXMgY29uc2lzdGluZyBvZiBkaWdpdCAobnVtZXJpYykNCiAgICAgICBj aGFyYWN0ZXJzIHdlcmUgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBhY2NvcmRpbmcgdG8g dGhlDQogICAgICAgYXNzaWdubWVudHMgZm91bmQgaW4gVU4gU3RhbmRhcmQgQ291bnRyeSBvciBB cmVhIENvZGVzIGZvcg0KICAgICAgIFN0YXRpc3RpY2FsICBVc2UgWzVdIG9yIGFzc2lnbm1lbnRz IHN1YnNlcXVlbnRseSBtYWRlIGJ5IHRoZQ0KICAgICAgIGdvdmVybmluZyBzdGFuZGFyZHMgYm9k eS4gIE5vdGUgdGhhdCBub3QgYWxsIG9mIHRoZSBVTiBNLjQ5IGNvZGVzDQogICAgICAgYXJlIGRl ZmluZWQgaW4gdGhlIElBTkEgcmVnaXN0cnk6DQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICAgICAgQS4gIFVOIG51bWVyaWMgY29kZXMgYXNzaWdu ZWQgdG8gJ21hY3JvLWdlb2dyYXBoaWNhbA0KICAgICAgICAgICAoY29udGluZW50YWwpJyBvciBz dWItcmVnaW9ucyBub3QgYXNzb2NpYXRlZCB3aXRoIGFuIGFzc2lnbmVkDQogICAgICAgICAgIElT TyAzMTY2IGFscGhhLTIgY29kZSBfYXJlXyBkZWZpbmVkLg0KDQogICAgICAgQi4gIFVOIG51bWVy aWMgY29kZXMgZm9yICdlY29ub21pYyBncm91cGluZ3MnIG9yICdvdGhlcg0KICAgICAgICAgICBn cm91cGluZ3MnIGFyZSBfbm90XyBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFuZCBNVVNU DQogICAgICAgICAgIE5PVCBiZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncy4NCg0KICAgICAg IEMuICBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgd2l0aCBhbWJpZ3VvdXMgSVNPIDMx NjYNCiAgICAgICAgICAgYWxwaGEtMiBjb2RlcyBhcyBkZWZpbmVkIGluIFNlY3Rpb24gMy4zIGFy ZSBkZWZpbmVkIGluIHRoZQ0KICAgICAgICAgICByZWdpc3RyeSBhbmQgYXJlIGNhbm9uaWNhbCBm b3IgdGhlIGdpdmVuIGNvdW50cnkgb3IgcmVnaW9uDQogICAgICAgICAgIGRlZmluZWQuDQoNCiAg ICAgICBELiAgVGhlIGFscGhhbnVtZXJpYyBjb2RlcyBpbiBBcHBlbmRpeCBYIG9mIHRoZSBVTiBk b2N1bWVudCBhcmUNCiAgICAgICAgICAgX25vdF8gZGVmaW5lZCBhbmQgTVVTVCBOT1QgYmUgdXNl ZCB0byBmb3JtIGxhbmd1YWdlIHRhZ3MuDQogICAgICAgICAgIChBdCB0aGUgdGltZSB0aGlzIGRv Y3VtZW50IHdhcyBjcmVhdGVkIHRoZXNlIHZhbHVlcyBtYXRjaCB0aGUNCiAgICAgICAgICAgSVNP IDMxNjYgYWxwaGEtMiBjb2Rlcy4pDQoNCiAgIDQuICBUaGVyZSBtYXkgYmUgYXQgbW9zdCBvbmUg cmVnaW9uIHN1YnRhZyBpbiBhIGxhbmd1YWdlIHRhZy4NCg0KICAgNS4gIFRoZSByZWdpb24gc3Vi dGFncyAnQUEnLCAnUU0nLSdRWicsICdYQSctJ1haJywgYW5kICdaWicgYXJlDQogICAgICAgcmVz ZXJ2ZWQgZm9yIHByaXZhdGUgdXNlIGluIGxhbmd1YWdlIHRhZ3MuICBUaGVzZSBzdWJ0YWdzDQog ICAgICAgY29ycmVzcG9uZCB0byBjb2RlcyByZXNlcnZlZCBieSBJU08gMzE2NiBmb3IgcHJpdmF0 ZSB1c2UuICBUaGVzZQ0KICAgICAgIGNvZGVzIE1BWSBiZSB1c2VkIGZvciBwcml2YXRlIHVzZSBy ZWdpb24gc3VidGFncyAoaW5zdGVhZCBvZg0KICAgICAgIHVzaW5nIGEgcHJpdmF0ZS11c2Ugc3Vi dGFnIHNlcXVlbmNlKS4gIFBsZWFzZSByZWZlciB0bw0KICAgICAgIFNlY3Rpb24gNC40IGZvciBt b3JlIGluZm9ybWF0aW9uIG9uIHByaXZhdGUgdXNlIHN1YnRhZ3MuDQoNCiAgICJkZS1DSCIgcmVw cmVzZW50cyBHZXJtYW4gKCdkZScpIGFzIHVzZWQgaW4gU3dpdHplcmxhbmQgKCdDSCcpLg0KDQog ICAic3ItTGF0bi1DUyIgcmVwcmVzZW50cyBTZXJiaWFuICgnc3InKSB3cml0dGVuIHVzaW5nIExh dGluIHNjcmlwdA0KICAgKCdMYXRuJykgYXMgdXNlZCBpbiBTZXJiaWEgYW5kIE1vbnRlbmVncm8g KCdDUycpLg0KDQogICAiZXMtNDE5IiByZXByZXNlbnRzIFNwYW5pc2ggKCdlcycpIGFzIHVzZWQg aW4gdGhlIFVOLWRlZmluZWQgTGF0aW4NCiAgIEFtZXJpY2EgYW5kIENhcmliYmVhbiByZWdpb24g KCc0MTknKS4NCg0KMi4yLjUgIFZhcmlhbnQgU3VidGFncw0KDQogICBUaGUgZm9sbG93aW5nIHJ1 bGVzIGFwcGx5IHRvIHRoZSB2YXJpYW50IHN1YnRhZ3M6DQoNCiAgIDEuICBWYXJpYW50IHN1YnRh Z3MgYXJlIG5vdCBhc3NvY2lhdGVkIHdpdGggYW55IGV4dGVybmFsIHN0YW5kYXJkLg0KICAgICAg IFZhcmlhbnQgc3VidGFncyBhbmQgdGhlaXIgbWVhbmluZ3MgYXJlIGRlZmluZWQgYnkgdGhlDQog ICAgICAgcmVnaXN0cmF0aW9uIHByb2Nlc3MgZGVmaW5lZCBpbiBTZWN0aW9uIDMuNC4NCg0KICAg Mi4gIFZhcmlhbnQgc3VidGFncyBNVVNUIGZvbGxvdyBhbGwgb2YgdGhlIG90aGVyIGRlZmluZWQg c3VidGFncywgYnV0DQogICAgICAgcHJlY2VkZSBhbnkgZXh0ZW5zaW9uIG9yIHByaXZhdGUtdXNl IHN1YnRhZyBzZXF1ZW5jZXMuDQoNCiAgIDMuICBNb3JlIHRoYW4gb25lIHZhcmlhbnQgTUFZIGJl IHVzZWQgdG8gZm9ybSB0aGUgbGFuZ3VhZ2UgdGFnLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAxMl0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIDQuICBWYXJpYW50IHN1YnRhZ3MgTVVTVCBiZSBy ZWdpc3RlcmVkIHdpdGggSUFOQSBhY2NvcmRpbmcgdG8gdGhlDQogICAgICAgcnVsZXMgaW4gU2Vj dGlvbiAzLjQgb2YgdGhpcyBkb2N1bWVudCBiZWZvcmUgYmVpbmcgdXNlZCB0byBmb3JtDQogICAg ICAgbGFuZ3VhZ2UgdGFncy4gIEluIG9yZGVyIHRvIGRpc3Rpbmd1aXNoIHZhcmlhbnRzIGZyb20g b3RoZXIgdHlwZXMNCiAgICAgICBvZiBzdWJ0YWdzLCByZWdpc3RyYXRpb25zIG11c3QgbWVldCB0 aGUgZm9sbG93aW5nIGxlbmd0aCBhbmQNCiAgICAgICBjb250ZW50IHJlc3RyaWN0aW9uczoNCg0K ICAgICAgIDEuICBWYXJpYW50IHN1YnRhZ3MgdGhhdCBiZWdpbiB3aXRoIGEgbGV0dGVyIChhLXos IEEtWikgTVVTVCBiZQ0KICAgICAgICAgICBhdCBsZWFzdCBmaXZlIGNoYXJhY3RlcnMgbG9uZy4N Cg0KICAgICAgIDIuICBWYXJpYW50IHN1YnRhZ3MgdGhhdCBiZWdpbiB3aXRoIGEgZGlnaXQgKDAt OSkgTVVTVCBiZSBhdA0KICAgICAgICAgICBsZWFzdCBmb3VyIGNoYXJhY3RlcnMgbG9uZy4NCg0K ICAgImVuLXNjb3VzZSIgcmVwcmVzZW50cyB0aGUgU2NvdXNlIGRpYWxlY3Qgb2YgRW5nbGlzaC4N Cg0KICAgImRlLUNILTE5OTYiIHJlcHJlc2VudHMgR2VybWFuIGFzIHVzZWQgaW4gU3dpdHplcmxh bmQgYW5kIGFzIHdyaXR0ZW4NCiAgIHVzaW5nIHRoZSBzcGVsbGluZyByZWZvcm0gYmVnaW5uaW5n IGluIHRoZSB5ZWFyIDE5OTYgQy5FLg0KDQoyLjIuNiAgRXh0ZW5zaW9uIFN1YnRhZ3MNCg0KICAg VGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byBleHRlbnNpb25zOg0KDQogICAxLiAgIEV4dGVu c2lvbiBzdWJ0YWdzIGFyZSBzZXBhcmF0ZWQgZnJvbSB0aGUgb3RoZXIgc3VidGFncyBkZWZpbmVk DQogICAgICAgIGluIHRoaXMgZG9jdW1lbnQgYnkgYSBzaW5nbGUtbGV0dGVyIHN1YnRhZyAoInNp bmdsZXRvbiIpLiAgVGhlDQogICAgICAgIHNpbmdsZXRvbiBNVVNUIGJlIG9uZSBhbGxvY2F0ZWQg dG8gYSByZWdpc3RyYXRpb24gYXV0aG9yaXR5IHZpYQ0KICAgICAgICB0aGUgbWVjaGFuaXNtIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDMuNiBhbmQgY2Fubm90IGJlIHRoZSBsZXR0ZXINCiAgICAgICAg J3gnLCB3aGljaCBpcyByZXNlcnZlZCBmb3IgcHJpdmF0ZS11c2Ugc3VidGFnIHNlcXVlbmNlcy4N Cg0KICAgMi4gICBOb3RlOiBQcml2YXRlLXVzZSBzdWJ0YWcgc2VxdWVuY2VzIHN0YXJ0aW5nIHdp dGggdGhlIHNpbmdsZXRvbg0KICAgICAgICBzdWJ0YWcgJ3gnIGFyZSBkZXNjcmliZWQgYmVsb3cu DQoNCiAgIDMuICAgQW4gZXh0ZW5zaW9uIE1VU1QgZm9sbG93IGF0IGxlYXN0IGEgcHJpbWFyeSBs YW5ndWFnZSBzdWJ0YWcuDQogICAgICAgIFRoYXQgaXMsIGEgbGFuZ3VhZ2UgdGFnIGNhbm5vdCBi ZWdpbiB3aXRoIGFuIGV4dGVuc2lvbi4NCiAgICAgICAgRXh0ZW5zaW9ucyBleHRlbmQgbGFuZ3Vh Z2UgdGFncywgdGhleSBkbyBub3Qgb3ZlcnJpZGUgb3IgcmVwbGFjZQ0KICAgICAgICB0aGVtLiAg Rm9yIGV4YW1wbGUsICJhLXZhbHVlIiBpcyBub3QgYSB3ZWxsLWZvcm1lZCBsYW5ndWFnZSB0YWcs DQogICAgICAgIHdoaWxlICJkZS1hLXZhbHVlIiBpcy4NCg0KICAgNC4gICBFYWNoIHNpbmdsZXRv biBzdWJ0YWcgTVVTVCBhcHBlYXIgYXQgbW9zdCBvbmUgdGltZSBpbiBlYWNoIHRhZw0KICAgICAg ICAob3RoZXIgdGhhbiBhcyBhIHByaXZhdGUtdXNlIHN1YnRhZykuICBUaGF0IGlzLCBzaW5nbGV0 b24NCiAgICAgICAgc3VidGFncyBNVVNUIE5PVCBiZSByZXBlYXRlZC4gIEZvciBleGFtcGxlLCB0 aGUgdGFnICJlbi1hLWJiYi1hLQ0KICAgICAgICBjY2MiIGlzIGludmFsaWQgYmVjYXVzZSB0aGUg c3VidGFnICdhJyBhcHBlYXJzIHR3aWNlLiAgTm90ZSB0aGF0DQogICAgICAgIHRoZSB0YWcgImVu LWEtYmJiLXgtYS1jY2MiIGlzIHZhbGlkIGJlY2F1c2UgdGhlIHNlY29uZA0KICAgICAgICBhcHBl YXJhbmNlIG9mIHRoZSBzaW5nbGV0b24gJ2EnIGlzIGluIGEgcHJpdmF0ZSB1c2Ugc2VxdWVuY2Uu DQoNCiAgIDUuICAgRXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBtZWV0IGFsbCBvZiB0aGUgcmVxdWly ZW1lbnRzIGZvciB0aGUNCiAgICAgICAgY29udGVudCBhbmQgZm9ybWF0IG9mIHN1YnRhZ3MgZGVm aW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICA2LiAgIEV4dGVuc2lvbiBzdWJ0YWdzIE1VU1Qg bWVldCB3aGF0ZXZlciByZXF1aXJlbWVudHMgYXJlIHNldCBieSB0aGUNCiAgICAgICAgZG9jdW1l bnQgdGhhdCBkZWZpbmVzIHRoZWlyIHNpbmdsZXRvbiBwcmVmaXggYW5kIHdoYXRldmVyDQoNCg0K DQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAg ICAgICAgICBbUGFnZSAxM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFn cy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgICAgICAgcmVxdWly ZW1lbnRzIGFyZSBwcm92aWRlZCBieSB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5Lg0KDQogICA3 LiAgIEVhY2ggZXh0ZW5zaW9uIHN1YnRhZyBNVVNUIGJlIGZyb20gdHdvIHRvIGVpZ2h0IGNoYXJh Y3RlcnMgbG9uZw0KICAgICAgICBhbmQgY29uc2lzdCBzb2xlbHkgb2YgbGV0dGVycyBvciBkaWdp dHMsIHdpdGggZWFjaCBzdWJ0YWcNCiAgICAgICAgc2VwYXJhdGVkIGJ5IGEgc2luZ2xlICctJy4N Cg0KICAgOC4gICBFYWNoIHNpbmdsZXRvbiBNVVNUIGJlIGZvbGxvd2VkIGJ5IGF0IGxlYXN0IG9u ZSBleHRlbnNpb24NCiAgICAgICAgc3VidGFnLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgInRsaC1h LWItZm9vIiBpcyBpbnZhbGlkIGJlY2F1c2UNCiAgICAgICAgdGhlIGZpcnN0IHNpbmdsZXRvbiAn YScgaXMgZm9sbG93ZWQgaW1tZWRpYXRlbHkgYnkgYW5vdGhlcg0KICAgICAgICBzaW5nbGV0b24g J2InLg0KDQogICA5LiAgIEV4dGVuc2lvbiBzdWJ0YWdzIE1VU1QgZm9sbG93IGFsbCBsYW5ndWFn ZSwgZXh0ZW5kZWQgbGFuZ3VhZ2UsDQogICAgICAgIHNjcmlwdCwgcmVnaW9uIGFuZCB2YXJpYW50 IHN1YnRhZ3MgaW4gYSB0YWcuDQoNCiAgIDEwLiAgQWxsIHN1YnRhZ3MgZm9sbG93aW5nIHRoZSBz aW5nbGV0b24gYW5kIGJlZm9yZSBhbm90aGVyIHNpbmdsZXRvbg0KICAgICAgICBhcmUgcGFydCBv ZiB0aGUgZXh0ZW5zaW9uLiAgRXhhbXBsZTogSW4gdGhlIHRhZyAiZnItYS1MYXRuIiwgdGhlDQog ICAgICAgIHN1YnRhZyAnTGF0bicgZG9lcyBub3QgcmVwcmVzZW50IHRoZSBzY3JpcHQgc3VidGFn ICdMYXRuJw0KICAgICAgICBkZWZpbmVkIGluIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdp c3RyeS4gIEl0cyBtZWFuaW5nIGlzDQogICAgICAgIGRlZmluZWQgYnkgdGhlIGV4dGVuc2lvbiAn YScuDQoNCiAgIDExLiAgSW4gdGhlIGV2ZW50IHRoYXQgbW9yZSB0aGFuIG9uZSBleHRlbnNpb24g YXBwZWFycyBpbiBhIHNpbmdsZQ0KICAgICAgICB0YWcsIHRoZSB0YWcgU0hPVUxEIGJlIGNhbm9u aWNhbGl6ZWQgYXMgZGVzY3JpYmVkIGluDQogICAgICAgIFNlY3Rpb24gNC4zLg0KDQogICBGb3Ig ZXhhbXBsZSwgaWYgdGhlIHByZWZpeCBzaW5nbGV0b24gJ3InIGFuZCB0aGUgc2hvd24gc3VidGFn cyB3ZXJlDQogICBkZWZpbmVkLCB0aGVuIHRoZSBmb2xsb3dpbmcgdGFnIHdvdWxkIGJlIGEgdmFs aWQgZXhhbXBsZTogImVuLUxhdG4tDQogICBHQi1ib29udC1yLWV4dGVuZGVkLXNlcXVlbmNlLXgt cHJpdmF0ZSINCg0KMi4yLjcgIFByaXZhdGUgVXNlIFN1YnRhZ3MNCg0KICAgVGhlIGZvbGxvd2lu ZyBydWxlcyBhcHBseSB0byBwcml2YXRlLXVzZSBzdWJ0YWdzOg0KDQogICAxLiAgUHJpdmF0ZS11 c2Ugc3VidGFncyBhcmUgc2VwYXJhdGVkIGZyb20gdGhlIG90aGVyIHN1YnRhZ3MgZGVmaW5lZA0K ICAgICAgIGluIHRoaXMgZG9jdW1lbnQgYnkgdGhlIHJlc2VydmVkIHNpbmdsZS1jaGFyYWN0ZXIg c3VidGFnICd4Jy4NCg0KICAgMi4gIFByaXZhdGUtdXNlIHN1YnRhZ3MgTVVTVCBmb2xsb3cgYWxs IGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwNCiAgICAgICBzY3JpcHQsIHJlZ2lvbiwgdmFy aWFudCwgYW5kIGV4dGVuc2lvbiBzdWJ0YWdzIGluIHRoZSB0YWcuDQogICAgICAgQW5vdGhlciB3 YXkgb2Ygc2F5aW5nIHRoaXMgaXMgdGhhdCBhbGwgc3VidGFncyBmb2xsb3dpbmcgdGhlDQogICAg ICAgc2luZ2xldG9uICd4JyBNVVNUIGJlIGNvbnNpZGVyZWQgcHJpdmF0ZSB1c2UuICBFeGFtcGxl OiBUaGUNCiAgICAgICBzdWJ0YWcgJ1VTJyBpbiB0aGUgdGFnICJlbi14LVVTIiBpcyBhIHByaXZh dGUgdXNlIHN1YnRhZy4NCg0KICAgMy4gIEEgdGFnIE1BWSBjb25zaXN0IGVudGlyZWx5IG9mIHBy aXZhdGUtdXNlIHN1YnRhZ3MuDQoNCiAgIDQuICBObyBzb3VyY2UgaXMgZGVmaW5lZCBmb3IgcHJp dmF0ZSB1c2Ugc3VidGFncy4gIFVzZSBvZiBwcml2YXRlIHVzZQ0KICAgICAgIHN1YnRhZ3MgaXMg YnkgcHJpdmF0ZSBhZ3JlZW1lbnQgb25seS4NCg0KICAgRm9yIGV4YW1wbGU6IFVzZXJzIHdobyB3 aXNoZWQgdG8gdXRpbGl6ZSBTSUwgRXRobm9sb2d1ZSBmb3INCiAgIGlkZW50aWZpY2F0aW9uIG1p Z2h0IGFncmVlIHRvIGV4Y2hhbmdlIHRhZ3Mgc3VjaCBhcyAiYXotQXJhYi14LUFaRS0NCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAg ICAgICAgIFtQYWdlIDE0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgZGVyYmVuZCIuICBU aGlzIGV4YW1wbGUgY29udGFpbnMgdHdvIHByaXZhdGUtdXNlIHN1YnRhZ3MuICBUaGUgZmlyc3QN CiAgIGlzICdBWkUnIGFuZCB0aGUgc2Vjb25kIGlzICdkZXJiZW5kJy4NCg0KMi4yLjggIFByZS1F eGlzdGluZyBSRkMgMzA2NiBSZWdpc3RyYXRpb25zDQoNCiAgIEV4aXN0aW5nIElBTkEtcmVnaXN0 ZXJlZCBsYW5ndWFnZSB0YWdzIGZyb20gUkZDIDE3NjYgYW5kL29yIFJGQyAzMDY2DQogICBtYWlu dGFpbiB0aGVpciB2YWxpZGl0eS4gIElBTkEgd2lsbCBtYWludGFpbiB0aGVzZSB0YWdzIGluIHRo ZQ0KICAgcmVnaXN0cnkgdW5kZXIgZWl0aGVyIHRoZSAiZ3JhbmRmYXRoZXJlZCIgb3IgInJlZHVu ZGFudCIgdHlwZS4gIEZvcg0KICAgbW9yZSBpbmZvcm1hdGlvbiBzZWUgU2VjdGlvbiAzLjcuDQoN CiAgIEl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgYWxsIGxhbmd1YWdlIHRhZ3MgZm9ybWVk IHVuZGVyIHRoZQ0KICAgZ3VpZGVsaW5lcyBpbiB0aGlzIGRvY3VtZW50IHdlcmUgZWl0aGVyIGxl Z2FsLCB3ZWxsLWZvcm1lZCB0YWdzIG9yDQogICBjb3VsZCBoYXZlIGJlZW4gcmVnaXN0ZXJlZCB1 bmRlciBSRkMgMzA2Ni4NCg0KMi4yLjkgIENsYXNzZXMgb2YgQ29uZm9ybWFuY2UNCg0KICAgSW1w bGVtZW50YXRpb25zIG1heSB3aXNoIHRvIGV4cHJlc3MgdGhlaXIgbGV2ZWwgb2YgY29uZm9ybWFu Y2Ugd2l0aA0KICAgdGhlIHJ1bGVzIGFuZCBwcmFjdGljZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9j dW1lbnQuICBUaGVyZSBhcmUNCiAgIGdlbmVyYWxseSB0d28gY2xhc3NlcyBvZiBjb25mb3JtaW5n IGltcGxlbWVudGF0aW9uczogIndlbGwtZm9ybWVkIg0KICAgcHJvY2Vzc29ycyBhbmQgInZhbGlk YXRpbmciIHByb2Nlc3NvcnMuICBDbGFpbXMgb2YgY29uZm9ybWFuY2UgU0hPVUxEDQogICBleHBs aWNpdGx5IHJlZmVyZW5jZSBvbmUgb2YgdGhlc2UgZGVmaW5pdGlvbnMuDQoNCiAgIEFuIGltcGxl bWVudGF0aW9uIHRoYXQgY2xhaW1zIHRvIGNoZWNrIGZvciB3ZWxsLWZvcm1lZCBsYW5ndWFnZSB0 YWdzDQogICBNVVNUOg0KDQogICBvICBDaGVjayB0aGF0IHRoZSB0YWcgYW5kIGFsbCBvZiBpdHMg c3VidGFncywgaW5jbHVkaW5nIGV4dGVuc2lvbiBhbmQNCiAgICAgIHByaXZhdGUtdXNlIHN1YnRh Z3MsIGNvbmZvcm0gdG8gdGhlIEFCTkYgb3IgdGhhdCB0aGUgdGFnIGlzIG9uIHRoZQ0KICAgICAg bGlzdCBvZiBncmFuZGZhdGhlcmVkIHRhZ3MuDQoNCiAgIG8gIENoZWNrIHRoYXQgc2luZ2xldG9u IHN1YnRhZ3MgdGhhdCBpZGVudGlmeSBleHRlbnNpb25zIGRvIG5vdA0KICAgICAgcmVwZWF0LiAg Rm9yIGV4YW1wbGUsIHRoZSB0YWcgImVuLWEteHgtYi15eS1hLXp6IiBpcyBub3Qgd2VsbC0NCiAg ICAgIGZvcm1lZC4NCg0KICAgV2VsbC1mb3JtZWQgcHJvY2Vzc29ycyBhcmUgc3Ryb25nbHkgZW5j b3VyYWdlZCB0byBpbXBsZW1lbnQgdGhlDQogICBjYW5vbmljYWxpemF0aW9uIHJ1bGVzIGNvbnRh aW5lZCBpbiBTZWN0aW9uIDQuMy4NCg0KICAgQW4gaW1wbGVtZW50YXRpb24gdGhhdCBjbGFpbXMg dG8gYmUgdmFsaWRhdGluZyBNVVNUOg0KDQogICBvICBDaGVjayB0aGF0IHRoZSB0YWcgaXMgd2Vs bC1mb3JtZWQuDQoNCiAgIG8gIFNwZWNpZnkgdGhlIHBhcnRpY3VsYXIgcmVnaXN0cnkgZGF0ZSBm b3Igd2hpY2ggdGhlIGltcGxlbWVudGF0aW9uDQogICAgICBwZXJmb3JtcyB2YWxpZGF0aW9uIG9m IHN1YnRhZ3MuDQoNCiAgIG8gIENoZWNrIHRoYXQgZWl0aGVyIHRoZSB0YWcgaXMgYSBncmFuZGZh dGhlcmVkIHRhZywgb3IgdGhhdCBhbGwNCiAgICAgIGxhbmd1YWdlLCBzY3JpcHQsIHJlZ2lvbiwg YW5kIHZhcmlhbnQgc3VidGFncyBjb25zaXN0IG9mIHZhbGlkDQogICAgICBjb2RlcyBmb3IgdXNl IGluIGxhbmd1YWdlIHRhZ3MgYWNjb3JkaW5nIHRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzDQogICAg ICBvZiB0aGUgcGFydGljdWxhciBkYXRlIHNwZWNpZmllZCBieSB0aGUgaW1wbGVtZW50YXRpb24u DQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAw NSAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgbyAg U3BlY2lmeSB3aGljaCwgaWYgYW55LCBleHRlbnNpb24gUkZDcyBhcyBkZWZpbmVkIGluIFNlY3Rp b24gMy42DQogICAgICBhcmUgc3VwcG9ydGVkLCBpbmNsdWRpbmcgdmVyc2lvbiwgcmV2aXNpb24s IGFuZCBkYXRlLg0KDQogICBvICBGb3IgYW55IHN1Y2ggZXh0ZW5zaW9ucyBzdXBwb3J0ZWQsIGNo ZWNrIHRoYXQgYWxsIHN1YnRhZ3MgdXNlZCBpbg0KICAgICAgdGhhdCBleHRlbnNpb24gYXJlIHZh bGlkLg0KDQogICBvICBJZiB0aGUgcHJvY2Vzc29yIGdlbmVyYXRlcyB0YWdzLCBpdCBNVVNUIGRv IHNvIGluIGNhbm9uaWNhbCBmb3JtLA0KICAgICAgaW5jbHVkaW5nIGFueSBzdXBwb3J0ZWQgZXh0 ZW5zaW9ucywgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAyMDA1 ICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg bGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQozLiAgUmVn aXN0cnkgRm9ybWF0IGFuZCBNYWludGVuYW5jZQ0KDQogICBUaGlzIHNlY3Rpb24gZGVmaW5lcyB0 aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IGFuZCB0aGUgbWFpbnRlbmFuY2UNCiAgIGFuZCB1 cGRhdGUgcHJvY2VkdXJlcyBhc3NvY2lhdGVkIHdpdGggaXQuDQoNCiAgIFRoZSBsYW5ndWFnZSBz dWJ0YWcgcmVnaXN0cnkgd2lsbCBiZSBtYWludGFpbmVkIHNvIHRoYXQsIGV4Y2VwdCBmb3INCiAg IGV4dGVuc2lvbiBzdWJ0YWdzLCBpdCBpcyBwb3NzaWJsZSB0byB2YWxpZGF0ZSBhbGwgb2YgdGhl IHN1YnRhZ3MgdGhhdA0KICAgYXBwZWFyIGluIGEgbGFuZ3VhZ2UgdGFnIHVuZGVyIHRoZSBwcm92 aXNpb25zIG9mIHRoaXMgZG9jdW1lbnQgb3IgaXRzDQogICByZXZpc2lvbnMgb3Igc3VjY2Vzc29y cy4gIEluIGFkZGl0aW9uLCB0aGUgbWVhbmluZyBvZiB0aGUgdmFyaW91cw0KICAgc3VidGFncyB3 aWxsIGJlIHVuYW1iaWd1b3VzIGFuZCBzdGFibGUgb3ZlciB0aW1lLiAgKFRoZSBtZWFuaW5nIG9m DQogICBwcml2YXRlLXVzZSBzdWJ0YWdzLCBvZiBjb3Vyc2UsIGlzIG5vdCBkZWZpbmVkIGJ5IHRo ZSBJQU5BIHJlZ2lzdHJ5LikNCg0KICAgVGhlIHJlZ2lzdHJ5IGRlZmluZWQgdW5kZXIgdGhpcyBk b2N1bWVudCBjb250YWlucyBhIGNvbXByZWhlbnNpdmUNCiAgIGxpc3Qgb2YgYWxsIG9mIHRoZSBz dWJ0YWdzIHZhbGlkIGluIGxhbmd1YWdlIHRhZ3MuICBUaGlzIGFsbG93cw0KICAgaW1wbGVtZW50 ZXJzIGEgc3RyYWlnaHRmb3J3YXJkIGFuZCByZWxpYWJsZSB3YXkgdG8gdmFsaWRhdGUgbGFuZ3Vh Z2UNCiAgIHRhZ3MuDQoNCjMuMSAgRm9ybWF0IG9mIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBS ZWdpc3RyeQ0KDQogICBUaGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgKCJ0aGUgcmVn aXN0cnkiKSB3aWxsIGNvbnNpc3Qgb2YgYQ0KICAgdGV4dCBmaWxlIHRoYXQgaXMgbWFjaGluZSBy ZWFkYWJsZSBpbiB0aGUgZm9ybWF0IGRlc2NyaWJlZCBpbiB0aGlzDQogICBzZWN0aW9uLCBwbHVz IGNvcGllcyBvZiB0aGUgcmVnaXN0cmF0aW9uIGZvcm1zIGFwcHJvdmVkIGJ5IHRoZQ0KICAgTGFu Z3VhZ2UgU3VidGFnIFJldmlld2VyIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgcHJvY2VzcyBkZXNj cmliZWQgaW4NCiAgIFNlY3Rpb24gMy40LiAgV2l0aCB0aGUgZXhjZXB0aW9uIG9mIHRoZSByZWdp c3RyYXRpb24gZm9ybXMgZm9yDQogICBncmFuZGZhdGhlcmVkIGFuZCByZWR1bmRhbnQgdGFncywg bm8gcmVnaXN0cmF0aW9uIHJlY29yZHMgd2lsbCBiZQ0KICAgbWFpbnRhaW5lZCBmb3IgdGhlIGlu aXRpYWwgc2V0IG9mIHN1YnRhZ3MuDQoNCiAgIFRoZSByZWdpc3RyeSB3aWxsIGJlIGluIGEgbW9k aWZpZWQgcmVjb3JkLWphciBmb3JtYXQgdGV4dCBmaWxlIFsxN10uDQogICBMaW5lcyBhcmUgbGlt aXRlZCB0byA3MiBjaGFyYWN0ZXJzLCBpbmNsdWRpbmcgYWxsIHdoaXRlc3BhY2UuDQoNCiAgIFJl Y29yZHMgYXJlIHNlcGFyYXRlZCBieSBsaW5lcyBjb250YWluaW5nIG9ubHkgdGhlIHNlcXVlbmNl ICIlJSINCiAgICgleDI1LjI1KS4NCg0KICAgRWFjaCBmaWVsZCBjYW4gYmUgdmlld2VkIGFzIGEg c2luZ2xlLCBsb2dpY2FsICBsaW5lICBvZiBBU0NJSQ0KICAgY2hhcmFjdGVycywgIGNvbXByaXNp bmcgIGEgZmllbGQtbmFtZSBhbmQgYSBmaWVsZC1ib2R5IHNlcGFyYXRlZCBieSBhDQogICBDT0xP TiBjaGFyYWN0ZXIgKCV4M0EpLiAgRm9yIGNvbnZlbmllbmNlLCB0aGUgZmllbGQtYm9keSAgcG9y dGlvbiAgb2YNCiAgIHRoaXMgIGNvbmNlcHR1YWwgZW50aXR5ICBjYW4gYmUgc3BsaXQgaW50byBh IG11bHRpcGxlLWxpbmUNCiAgIHJlcHJlc2VudGF0aW9uOyB0aGlzIGlzIGNhbGxlZCAiZm9sZGlu ZyIuICBUaGUgZm9ybWF0IG9mIHRoZSByZWdpc3RyeQ0KICAgaXMgZGVzY3JpYmVkIGJ5IHRoZSBm b2xsb3dpbmcgQUJORiAocGVyIFs3XSk6DQoNCiAgIHJlZ2lzdHJ5ICAgPSByZWNvcmQgKigiJSUi IENSTEYgcmVjb3JkKQ0KICAgcmVjb3JkICAgICA9IDEqKCBmaWVsZC1uYW1lICpTUCAiOiIgKlNQ IGZpZWxkLWJvZHkgQ1JMRiApDQogICBmaWVsZC1uYW1lID0gKihBTFBIQS9OVU0vIi0iKQ0KICAg ZmllbGQtYm9keSA9ICooQVNDQ0hBUi9MV1NQKQ0KICAgQVNDQ0hBUiAgICA9ICV4MjEtMjUgLyAl eDI3LTdFIC8gVU5JQ0hBUiA7IE5vdGU6IEFNUEVSU0FORCBpcyAleDI2DQogICBVTklDSEFSICAg ID0gIiYjeCIgMio2SEVYRElHICI7Ig0KDQogICBUaGUgc2VxdWVuY2UgJy4uJyAoJXgyRS4yRSkg aW4gYSBmaWVsZC1ib2R5IGRlbm90ZXMgYSByYW5nZSBvZg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZp cyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgMTdd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAg ICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICB2YWx1ZXMuICBTdWNoIGEgcmFuZ2UgcmVwcmVz ZW50cyBhbGwgc3VidGFncyBvZiB0aGUgc2FtZSBsZW5ndGggdGhhdA0KICAgYXJlIGFscGhhYmV0 aWNhbGx5IHdpdGhpbiB0aGF0IHJhbmdlLCBpbmNsdWRpbmcgdGhlIHZhbHVlcyBleHBsaWNpdGx5 DQogICBtZW50aW9uZWQuICBGb3IgZXhhbXBsZSAnYS4uYycgZGVub3RlcyB0aGUgdmFsdWVzICdh JywgJ2InLCBhbmQgJ2MnLg0KDQogICBDaGFyYWN0ZXJzIGZyb20gb3V0c2lkZSB0aGUgVVMtQVND SUkgcmVwZXJ0b2lyZSwgYXMgd2VsbCBhcyB0aGUNCiAgIEFNUEVSU0FORCBjaGFyYWN0ZXIgKCIm IiwgJXgyNikgd2hlbiBpdCBvY2N1cnMgaW4gYSBmaWVsZC1ib2R5IGFyZQ0KICAgcmVwcmVzZW50 ZWQgYnkgYSAiTnVtZXJpYyBDaGFyYWN0ZXIgUmVmZXJlbmNlIiB1c2luZyBoZXhhZGVjaW1hbA0K ICAgbm90YXRpb24gaW4gdGhlIHN0eWxlIHVzZWQgYnkgWE1MIDEuMCBbMThdIChzZWUNCiAgIDxo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMteG1sLyNkdC1jaGFycmVmPikuICBUaGlzIGNvbnNpc3Rz IG9mIHRoZQ0KICAgc2VxdWVuY2UgIiYjeCIgKCV4MjYuMjMuNzgpIGZvbGxvd2VkIGJ5IGEgaGV4 YWRlY2ltYWwgcmVwcmVzZW50YXRpb24NCiAgIG9mIHRoZSBjaGFyYWN0ZXIncyBjb2RlIHBvaW50 IGluIElTTy9JRUMgMTA2NDYgWzZdIGZvbGxvd2VkIGJ5IGENCiAgIGNsb3Npbmcgc2VtaWNvbG9u ICgleDNCKS4gIEZvciBleGFtcGxlLCB0aGUgRVVSTyBTSUdOLCBVKzIwQUMsIHdvdWxkDQogICBi ZSByZXByZXNlbnRlZCBieSB0aGUgc2VxdWVuY2UgIiYjeDIwQUM7Ii4gIE5vdGUgdGhhdCB0aGUg aGV4YWRlY2ltYWwNCiAgIG5vdGF0aW9uIG1heSBoYXZlIGJldHdlZW4gdHdvIGFuZCBzaXggZGln aXRzLg0KDQogICBBbGwgZmllbGRzIHdob3NlIGZpZWxkLWJvZHkgY29udGFpbnMgYSBkYXRlIHZh bHVlIHVzZSB0aGUgImZ1bGwtZGF0ZSINCiAgIGZvcm1hdCBzcGVjaWZpZWQgaW4gUkZDIDMzMzkg WzE0XS4gIEZvciBleGFtcGxlOiAiMjAwNC0wNi0yOCINCiAgIHJlcHJlc2VudHMgSnVuZSAyOCwg MjAwNCBpbiB0aGUgR3JlZ29yaWFuIGNhbGVuZGFyLg0KDQogICBUaGUgZmlyc3QgcmVjb3JkIGlu IHRoZSBmaWxlIGNvbnRhaW5zIHRoZSBzaW5nbGUgZmllbGQgd2hvc2UgZmllbGQtDQogICBuYW1l IGlzICJGaWxlLURhdGUiIGFuZCB3aG9zZSBmaWVsZC1ib2R5IGNvbnRhaW5zIHRoZSBsYXN0DQog ICBtb2RpZmljYXRpb24gZGF0ZSBvZiB0aGUgcmVnaXN0cnk6DQoNCiAgIEZpbGUtRGF0ZTogMjAw NC0wNi0yOA0KICAgJSUNCg0KICAgU3Vic2VxdWVudCByZWNvcmRzIHJlcHJlc2VudCBzdWJ0YWdz IGluIHRoZSByZWdpc3RyeS4gIEVhY2ggb2YgdGhlDQogICBmaWVsZHMgaW4gZWFjaCByZWNvcmQg TVVTVCBvY2N1ciBubyBtb3JlIHRoYW4gb25jZSwgdW5sZXNzIG90aGVyd2lzZQ0KICAgbm90ZWQg YmVsb3cuICBFYWNoIHJlY29yZCBNVVNUIGNvbnRhaW4gdGhlIGZvbGxvd2luZyBmaWVsZHM6DQoN CiAgIG8gICdUeXBlJw0KDQogICAgICAqICBUeXBlJ3MgZmllbGQtdmFsdWUgTVVTVCBjb25zaXN0 IG9mIG9uZSBvZiB0aGUgZm9sbG93aW5nDQogICAgICAgICBzdHJpbmdzOiAibGFuZ3VhZ2UiLCAi ZXh0bGFuZyIsICJzY3JpcHQiLCAicmVnaW9uIiwgInZhcmlhbnQiLA0KICAgICAgICAgImdyYW5k ZmF0aGVyZWQiLCBhbmQgInJlZHVuZGFudCIgYW5kIGRlbm90ZXMgdGhlIHR5cGUgb2YgdGFnIG9y DQogICAgICAgICBzdWJ0YWcuDQoNCiAgIG8gIEVpdGhlciAnU3VidGFnJyBvciAnVGFnJw0KDQog ICAgICAqICBTdWJ0YWcncyBmaWVsZC12YWx1ZSBjb250YWlucyB0aGUgc3VidGFnIGJlaW5nIGRl ZmluZWQuICBUaGlzDQogICAgICAgICBmaWVsZCBNVVNUIG9ubHkgYXBwZWFyIGluIHJlY29yZHMg b2Ygd2hvc2UgVHlwZSBoYXMgb25lIG9mDQogICAgICAgICB0aGVzZSB2YWx1ZXM6ICJsYW5ndWFn ZSIsICJleHRsYW5nIiwgInNjcmlwdCIsICJyZWdpb24iLCBvcg0KICAgICAgICAgInZhcmlhbnQi Lg0KDQogICAgICAqICBUYWcncyBmaWVsZC12YWx1ZSBjb250YWlucyBhIGNvbXBsZXRlIGxhbmd1 YWdlIHRhZy4gIFRoaXMgZmllbGQNCiAgICAgICAgIE1VU1Qgb25seSBhcHBlYXIgaW4gcmVjb3Jk cyB3aG9zZSBUeXBlIGhhcyBvbmUgb2YgdGhlc2UgdmFsdWVzOg0KICAgICAgICAgImdyYW5kZmF0 aGVyZWQiIG9yICJyZWR1bmRhbnQiLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAxOF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg QXByaWwgMjAwNQ0KDQoNCiAgIG8gIERlc2NyaXB0aW9uDQoNCiAgICAgICogIERlc2NyaXB0aW9u J3MgZmllbGQtdmFsdWUgY29udGFpbnMgYSBub24tbm9ybWF0aXZlIGRlc2NyaXB0aW9uDQogICAg ICAgICBvZiB0aGUgc3VidGFnIG9yIHRhZy4NCg0KICAgbyAgQWRkZWQNCg0KICAgICAgKiAgQWRk ZWQncyBmaWVsZC12YWx1ZSBjb250YWlucyB0aGUgZGF0ZSB0aGUgcmVjb3JkIHdhcyBhZGRlZCB0 bw0KICAgICAgICAgdGhlIHJlZ2lzdHJ5Lg0KDQogICBUaGUgZmllbGQgJ0Rlc2NyaXB0aW9uJyBN QVkgYXBwZWFyIG1vcmUgdGhhbiBvbmUgdGltZS4gIFRoZQ0KICAgJ0Rlc2NyaXB0aW9uJyBmaWVs ZCBtdXN0IGNvbnRhaW4gYSBkZXNjcmlwdGlvbiBvZiB0aGUgdGFnIGJlaW5nDQogICByZWdpc3Rl cmVkIHdyaXR0ZW4gb3IgdHJhbnNjcmliZWQgaW50byB0aGUgTGF0aW4gc2NyaXB0OyBpdCBtYXkg YWxzbw0KICAgaW5jbHVkZSBhIGRlc2NyaXB0aW9uIGluIGEgbm9uLUxhdGluIHNjcmlwdC4gIFRo ZSAnRGVzY3JpcHRpb24nIGZpZWxkDQogICBpcyB1c2VkIGZvciBpZGVudGlmaWNhdGlvbiBwdXJw b3NlcyBhbmQgc2hvdWxkIG5vdCBiZSB0YWtlbiB0bw0KICAgcmVwcmVzZW50IHRoZSBhY3R1YWwg bmF0aXZlIG5hbWUgb2YgdGhlIGxhbmd1YWdlIG9yIHZhcmlhdGlvbiBvciB0bw0KICAgYmUgaW4g YW55IHBhcnRpY3VsYXIgbGFuZ3VhZ2UuICBNb3N0IGRlc2NyaXB0aW9ucyBhcmUgdGFrZW4gZGly ZWN0bHkNCiAgIGZyb20gc291cmNlIHN0YW5kYXJkcyBzdWNoIGFzIElTTyA2Mzkgb3IgSVNPIDMx NjYuDQoNCiAgIE5vdGU6IERlc2NyaXB0aW9ucyBpbiByZWdpc3RyeSBlbnRyaWVzIHRoYXQgY29y cmVzcG9uZCB0byBJU08gNjM5LA0KICAgSVNPIDE1OTI0LCAgSVNPIDMxNjYgb3IgVU4gTS40OSBj b2RlcyBhcmUgaW50ZW5kZWQgb25seSB0byBpbmRpY2F0ZQ0KICAgdGhlIG1lYW5pbmcgb2YgdGhh dCBpZGVudGlmaWVyIGFzIGRlZmluZWQgaW4gdGhlIHNvdXJjZSBzdGFuZGFyZCBhdA0KICAgdGhl IHRpbWUgaXQgd2FzIGFkZGVkIHRvIHRoZSByZWdpc3RyeS4gIFRoZSBkZXNjcmlwdGlvbiBkb2Vz IG5vdA0KICAgcmVwbGFjZSB0aGUgY29udGVudCBvZiB0aGUgc291cmNlIHN0YW5kYXJkIGl0c2Vs Zi4gIFRoZSBkZXNjcmlwdGlvbnMNCiAgIGFyZSBub3QgaW50ZW5kZWQgdG8gYmUgdGhlIEVuZ2xp c2ggbG9jYWxpemVkIG5hbWVzIGZvciB0aGUgc3VidGFncy4NCiAgIExvY2FsaXphdGlvbiBvciB0 cmFuc2xhdGlvbiBvZiBsYW5ndWFnZSB0YWcgYW5kIHN1YnRhZyBkZXNjcmlwdGlvbnMNCiAgIGlz IG91dCBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KDQogICBFYWNoIHJlY29yZCBNQVkgYWxz byBjb250YWluIHRoZSBmb2xsb3dpbmcgZmllbGRzOg0KDQogICBvICBDYW5vbmljYWwNCg0KICAg ICAgKiAgRm9yIGZpZWxkcyBvZiB0eXBlICdsYW5ndWFnZScsICdleHRsYW5nJywgJ3NjcmlwdCcs ICdyZWdpb24nLA0KICAgICAgICAgYW5kICd2YXJpYW50JywgYSBjYW5vbmljYWwgbWFwcGluZyBv ZiB0aGlzIHJlY29yZCB0byBhIHN1YnRhZw0KICAgICAgICAgcmVjb3JkIG9mIHRoZSBzYW1lICdU eXBlJy4NCg0KICAgICAgKiAgRm9yIGZpZWxkcyBvZiB0eXBlICdncmFuZGZhdGhlcmVkJyBhbmQg J3JlZHVuZGFudCcsIGEgY2Fub25pY2FsDQogICAgICAgICBtYXBwaW5nIHRvIGEgY29tcGxldGUg bGFuZ3VhZ2UgdGFnLg0KDQogICBvICBEZXByZWNhdGVkDQoNCiAgICAgICogIERlcHJlY2F0ZWQn cyBmaWVsZC12YWx1ZSBjb250YWlucyB0aGUgZGF0ZSB0aGUgcmVjb3JkIHdhcw0KICAgICAgICAg ZGVwcmVjYXRlZC4NCg0KICAgbyAgUmVjb21tZW5kZWQtUHJlZml4DQoNCiAgICAgICogIFJlY29t bWVuZGVkLVByZWZpeCdzIGZpZWxkLXZhbHVlIGNvbnRhaW5zIGEgbGFuZ3VhZ2UgdGFnIHdpdGgN CiAgICAgICAgIHdoaWNoIHRoaXMgc3VidGFnIG1heSBiZSB1c2VkIHRvIGZvcm0gYSBuZXcgbGFu Z3VhZ2UgdGFnLA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVy IDI4LCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgMTldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0K DQogICAgICAgICBwZXJoYXBzIHdpdGggb3RoZXIgc3VidGFncyBhcyB3ZWxsLiAgVGhpcyBmaWVs ZCBNVVNUIG9ubHkNCiAgICAgICAgIGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBlJyBmaWVs ZC12YWx1ZSBpcyAndmFyaWFudCcgb3INCiAgICAgICAgICdleHRsYW5nJy4gIEZvciBleGFtcGxl LCB0aGUgJ1JlY29tbWVuZGVkLVByZWZpeCcgZm9yIHRoZQ0KICAgICAgICAgdmFyaWFudCAnc2Nv dXNlJyBpcyAnZW4nLCBtZWFuaW5nIHRoYXQgdGhlIHRhZ3MgImVuLXNjb3VzZSIgYW5kDQogICAg ICAgICAiZW4tR0Itc2NvdXNlIiBtaWdodCBiZSBhcHByb3ByaWF0ZSB3aGlsZSB0aGUgdGFnICJp cy1zY291c2UiDQogICAgICAgICBpcyBub3QuDQoNCiAgIG8gIENvbW1lbnRzDQoNCiAgICAgICog IENvbW1lbnRzIGNvbnRhaW5zIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHN1YnRh ZywgYXMNCiAgICAgICAgIGRlZW1lZCBhcHByb3ByaWF0ZSBmb3IgdW5kZXJzdGFuZGluZyB0aGUg cmVnaXN0cnkgYW5kDQogICAgICAgICBpbXBsZW1lbnRpbmcgbGFuZ3VhZ2UgdGFncyB1c2luZyB0 aGUgc3VidGFnIG9yIHRhZy4NCg0KICAgbyAgU3VwcHJlc3MtU2NyaXB0DQoNCiAgICAgICogIFN1 cHByZXNzLVNjcmlwdCBjb250YWlucyBhIHNjcmlwdCBzdWJ0YWcgdGhhdCBTSE9VTEQgTk9UIGJl DQogICAgICAgICB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyB3aXRoIHRoZSBhc3NvY2lhdGVk IHByaW1hcnkgbGFuZ3VhZ2UNCiAgICAgICAgIHN1YnRhZy4gIFRoaXMgZmllbGQgTVVTVCBvbmx5 IGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBlJw0KICAgICAgICAgZmllbGQtdmFsdWUgaXMg J2xhbmd1YWdlJy4gIFNlZSBTZWN0aW9uIDQuMS4NCg0KICAgVGhlIGZpZWxkICdDYW5vbmljYWwn IFNIQUxMIE5PVCBiZSBhZGRlZCB0byBhbnkgcmVjb3JkIGFscmVhZHkgaW4gdGhlDQogICByZWdp c3RyeS4gIFRoZSBmaWVsZCAnQ2Fub25pY2FsJyBTSEFMTCBOT1QgYmUgbW9kaWZpZWQgZXhjZXB0 IGZvcg0KICAgcmVjb3JkcyBvZiB0eXBlICJncmFuZGZhdGhlcmVkIjogdGhlcmVmb3JlIGEgc3Vi dGFnIHdob3NlIHJlY29yZA0KICAgY29udGFpbnMgbm8gY2Fub25pY2FsIG1hcHBpbmcgd2hlbiB0 aGUgcmVjb3JkIGlzIGNyZWF0ZWQgaXMgYQ0KICAgY2Fub25pY2FsIGZvcm0gYW5kIHdpbGwgcmVt YWluIHNvLg0KDQogICBUaGUgJ0Nhbm9uaWNhbCcgZmllbGQgaW4gcmVjb3JkcyBvZiB0eXBlICJn cmFuZGZhdGhlcmVkIiBhbmQNCiAgICJyZWR1bmRhbnQiIGNvbnRhaW5zIHdob2xlIGxhbmd1YWdl IHRhZ3MgdGhhdCBhcmUgU1RST05HTFkNCiAgIFJFQ09NTUVOREVEIGZvciB1c2UgaW4gcGxhY2Ug b2YgdGhlIHJlY29yZCdzIHZhbHVlLiAgSW4gbWFueSBjYXNlcw0KICAgdGhlIG1hcHBpbmdzIHdl cmUgY3JlYXRlZCBieSBkZXByZWNhdGlvbiBvZiB0aGUgdGFncyBkdXJpbmcgdGhlDQogICBwZXJp b2QgYmVmb3JlIHRoaXMgZG9jdW1lbnQgd2FzIGFkb3B0ZWQuICBGb3IgZXhhbXBsZSwgdGhlIHRh ZyAibm8tDQogICBueW4iIHdhcyBkZXByZWNhdGVkIGluIGZhdm9yIG9mIHRoZSBJU08gNjM5LTEg ZGVmaW5lZCBsYW5ndWFnZSBjb2RlDQogICAnbm4nLg0KDQogICBOb3RlIHRoYXQgYSByZWNvcmQg dGhhdCBoYXMgYSAnQ2Fub25pY2FsJyBmaWVsZCBNVVNUIGhhdmUgYQ0KICAgJ0RlcHJlY2F0ZWQn IGZpZWxkIGFsc28gKGFsdGhvdWdoIHRoZSBjb252ZXJzZSBpcyBub3QgdHJ1ZSkuDQoNCiAgIFRo ZSBmaWVsZCAnRGVwcmVjYXRlZCcgTUFZIGJlIGFkZGVkIHRvIGFueSByZWNvcmQgdmlhIHRoZSBt YWludGVuYW5jZQ0KICAgcHJvY2VzcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIgb3IgdmlhIHRo ZSByZWdpc3RyYXRpb24gcHJvY2Vzcw0KICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40LiAgVXN1 YWxseSB0aGUgYWRkaXRpb24gb2YgYSAnRGVwcmVjYXRlZCcNCiAgIGZpZWxkIGlzIGR1ZSB0byB0 aGUgYWN0aW9uIG9mIG9uZSBvZiB0aGUgc3RhbmRhcmRzIGJvZGllcywgc3VjaCBhcw0KICAgSVNP IDMxNjYsIHdpdGhkcmF3aW5nIGEgY29kZS4gIEluIHNvbWUgaGlzdG9yaWNhbCBjYXNlcyBpdCBt YXkgbm90DQogICBoYXZlIGJlZW4gIHBvc3NpYmxlIHRvIHJlY29uc3RydWN0IHRoZSBvcmlnaW5h bCBkZXByZWNhdGlvbiBkYXRlLg0KICAgRm9yIHRoZXNlIGNhc2VzLCBhbiBhcHByb3hpbWF0ZSBk YXRlIGFwcGVhcnMgaW4gdGhlIHJlZ2lzdHJ5Lg0KICAgQWx0aG91Z2ggdmFsaWQgaW4gbGFuZ3Vh Z2UgdGFncywgc3VidGFncyBhbmQgdGFncyB3aXRoIGEgJ0RlcHJlY2F0ZWQnDQogICBmaWVsZCBh cmUgZGVwcmVjYXRlZCBhbmQgdmFsaWRhdGluZyBwcm9jZXNzb3JzIFNIT1VMRCBOT1QgZ2VuZXJh dGUNCiAgIHRoZXNlIHN1YnRhZ3MuICBOb3RlIHRoYXQgYSByZWNvcmQgdGhhdCBjb250YWlucyBh ICdEZXByZWNhdGVkJyBmaWVsZA0KICAgYW5kIG5vIGNvcnJlc3BvbmRpbmcgJ0Nhbm9uaWNhbCcg ZmllbGQgaGFzIG5vIHJlcGxhY2VtZW50IG1hcHBpbmcuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlz ICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAyMF0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAg ICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIFRoZSBmaWVsZCAnUmVjb21tZW5kZWQtUHJlZml4 JyBNQVkgYXBwZWFyIG1vcmUgdGhhbiBvbmNlIHBlciByZWNvcmQuDQogICBBZGRpdGlvbmFsIGZp ZWxkcyBvZiB0aGlzIHR5cGUgTUFZIGJlIGFkZGVkIHRvIGEgcmVjb3JkIHZpYSB0aGUNCiAgIHJl Z2lzdHJhdGlvbiBwcm9jZXNzLiAgVGhlIGZpZWxkLXZhbHVlIG9mIG9mIHRoaXMgZmllbGQgY29u c2lzdHMgb2YgYQ0KICAgbGFuZ3VhZ2UgdGFnIHRoYXQgaXMgUkVDT01NRU5ERUQgZm9yIHVzZSBh cyBhIHByZWZpeCBmb3IgdGhpcyBzdWJ0YWcuDQogICBGb3IgZXhhbXBsZSwgdGhlIHZhcmlhbnQg c3VidGFnICdzY291c2UnIGhhcyBhIHJlY29tbWVuZGVkIHByZWZpeCBvZg0KICAgImVuIi4gIFRo aXMgbWVhbnMgdGhhdCB0YWdzIHN0YXJ0aW5nIHdpdGggdGhlIHByZWZpeCAiZW4tIiBhcmUgbW9z dA0KICAgYXBwcm9wcmlhdGUgd2l0aCB0aGlzIHN1YnRhZywgc28gImVuLUxhdG4tc2NvdXNlIiBh bmQgImVuLUdCLXNjb3VzZSINCiAgIGFyZSBib3RoIGFjY2VwdGFibGUsIHdoaWxlIHRoZSB0YWcg ImZyLXNjb3VzZSIgaXMgcHJvYmFibHkgYW4NCiAgIGluYXBwcm9wcmlhdGUgY2hvaWNlLg0KDQog ICBUaGUgZmllbGQgb2YgdHlwZSBSZWNvbW1lbmRlZC1QcmVmaXggTVVTVCBOT1QgYmUgcmVtb3Zl ZCBmcm9tIGFueQ0KICAgcmVjb3JkLiAgVGhlIGZpZWxkLXZhbHVlIGZvciB0aGlzIHR5cGUgb2Yg ZmllbGQgTVVTVCBOT1QgYmUgbW9kaWZpZWQuDQoNCiAgIFRoZSBmaWVsZCAnQ29tbWVudHMnIE1B WSBhcHBlYXIgbW9yZSB0aGFuIG9uY2UgcGVyIHJlY29yZC4gIFRoaXMNCiAgIGZpZWxkIE1BWSBi ZSBpbnNlcnRlZCBvciBjaGFuZ2VkIHZpYSB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgYW5kIG5v DQogICBndWFyYW50ZWUgb2Ygc3RhYmlsaXR5IGlzIHByb3ZpZGVkLiAgVGhlIGNvbnRlbnQgb2Yg dGhpcyBmaWVsZCBpcyBub3QNCiAgIHJlc3RyaWN0ZWQsIGV4Y2VwdCBieSB0aGUgbmVlZCB0byBy ZWdpc3RlciB0aGUgaW5mb3JtYXRpb24sIHRoZQ0KICAgc3VpdGFiaWxpdHkgb2YgdGhlIHJlcXVl c3QsIGFuZCBieSByZWFzb25hYmxlIHByYWN0aWNhbCBzaXplDQogICBsaW1pdGF0aW9ucy4gIExv bmcgc2NyZWVkcyBhYm91dCBhIHBhcnRpY3VsYXIgc3VidGFnIGFyZSBmcm93bmVkDQogICB1cG9u Lg0KDQogICBUaGUgZmllbGQgJ1N1cHByZXNzLVNjcmlwdCcgTVVTVCBvbmx5IGFwcGVhciBpbiBy ZWNvcmRzIHdob3NlICdUeXBlJw0KICAgZmllbGQtdmFsdWUgaXMgJ2xhbmd1YWdlJy4gIFRoaXMg ZmllbGQgbWF5IGFwcGVhciBhdCBtb3N0IG9uZSB0aW1lIGluDQogICBhIHJlY29yZC4gIFRoaXMg ZmllbGQgaW5kaWNhdGVzIGEgc2NyaXB0IHVzZWQgdG8gd3JpdGUgdGhlDQogICBvdmVyd2hlbG1p bmcgbWFqb3JpdHkgb2YgZG9jdW1lbnRzIGZvciB0aGUgZ2l2ZW4gbGFuZ3VhZ2UgYW5kIHdoaWNo DQogICB0aGVyZWZvcmUgYWRkcyBubyBkaXN0aW5ndWlzaGluZyBpbmZvcm1hdGlvbiB0byBhIGxh bmd1YWdlIHRhZy4gIEZvcg0KICAgZXhhbXBsZSwgdmlydHVhbGx5IGFsbCBJY2VsYW5kaWMgZG9j dW1lbnRzIGFyZSB3cml0dGVuIGluIHRoZSBMYXRpbg0KICAgc2NyaXB0LCBtYWtpbmcgdGhlIHN1 YnRhZyAnTGF0bicgcmVkdW5kYW50IGluIHRoZSB0YWcgImlzLUxhdG4iLg0KDQogICBGb3IgZXhh bXBsZXMgb2YgcmVnaXN0cnkgZW50cmllcyBhbmQgdGhlaXIgZm9ybWF0LCBzZWUgQXBwZW5kaXgg Qy4NCg0KMy4yICBNYWludGVuYW5jZSBvZiB0aGUgUmVnaXN0cnkNCg0KICAgTWFpbnRlbmFuY2Ug b2YgdGhlIHJlZ2lzdHJ5IHJlcXVpcmVzIHRoYXQgYXMgbmV3IGNvZGVzIGFyZSBhc3NpZ25lZA0K ICAgYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBhbmQgSVNPIDMxNjYsIHRoZSBMYW5ndWFnZSBTdWJ0 YWcgUmV2aWV3ZXINCiAgIHdpbGwgZXZhbHVhdGUgZWFjaCBhc3NpZ25tZW50LCBkZXRlcm1pbmUg d2hldGhlciBpdCBjb25mbGljdHMgd2l0aA0KICAgZXhpc3RpbmcgcmVnaXN0cnkgZW50cmllcywg YW5kIHN1Ym1pdCB0aGUgaW5mb3JtYXRpb24gdG8gSUFOQSBmb3INCiAgIGluY2x1c2lvbiBpbiB0 aGUgcmVnaXN0cnkuICBJZiBhbiBhc3NpZ25tZW50IHRha2VzIHBsYWNlIGFuZCB0aGUNCiAgIExh bmd1YWdlIFN1YnRhZyBSZXZpZXdlciBkb2VzIG5vdCBkbyB0aGlzIGluIGEgdGltZWx5IG1hbm5l ciwgdGhlbg0KICAgYW55IGludGVyZXN0ZWQgcGFydHkgbWF5IHVzZSB0aGUgcHJvY2VkdXJlIGlu IFNlY3Rpb24gMy40IHRvIHJlZ2lzdGVyDQogICB0aGUgYXBwcm9wcmlhdGUgdXBkYXRlLg0KDQog ICBOb3RlOiBUaGUgcmVkdW5kYW50IGFuZCBncmFuZGZhdGhlcmVkIGVudHJpZXMgdG9nZXRoZXIg YXJlIHRoZQ0KICAgY29tcGxldGUgbGlzdCBvZiB0YWdzIHJlZ2lzdGVyZWQgdW5kZXIgUkZDIDMw NjYgWzIzXS4gIFRoZSByZWR1bmRhbnQNCiAgIHRhZ3MgYXJlIHRob3NlIHRoYXQgY2FuIG5vdyBi ZSBmb3JtZWQgdXNpbmcgdGhlIHN1YnRhZ3MgZGVmaW5lZCBpbg0KICAgdGhlIHJlZ2lzdHJ5IHRv Z2V0aGVyIHdpdGggdGhlIHJ1bGVzIG9mICBTZWN0aW9uIDIuMi4gIFRoZQ0KICAgZ3JhbmRmYXRo ZXJlZCBlbnRyaWVzIGFyZSB0aG9zZSB0aGF0IGNhbiBuZXZlciBiZSBsZWdhbCB1bmRlciB0aG9z ZQ0KICAgc2FtZSBwcm92aXNpb25zLiAgVGhlIGl0ZW1zIGluIGJvdGggbGlzdHMgYXJlIHBlcm1h bmVudCBhbmQgc3RhYmxlLA0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBP Y3RvYmVyIDI4LCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgMjFdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIw MDUNCg0KDQogICBhbHRob3VnaCBncmFuZGZhdGhlcmVkIGl0ZW1zIG1heSBiZSBkZXByZWNhdGVk IG92ZXIgdGltZS4gIFJlZmVyIHRvDQogICBTZWN0aW9uIDMuNyBmb3IgbW9yZSBpbmZvcm1hdGlv bi4NCg0KICAgUkZDIDMwNjYgdGFncyB0aGF0IHdlcmUgZGVwcmVjYXRlZCBwcmlvciB0byB0aGUg YWRvcHRpb24gb2YgdGhpcw0KICAgZG9jdW1lbnQgYXJlIHBhcnQgb2YgdGhlIGxpc3Qgb2YgZ3Jh bmRmYXRoZXJlZCB0YWdzIGFuZCB0aGVpcg0KICAgY29tcG9uZW50IHN1YnRhZ3Mgd2VyZSBub3Qg aW5jbHVkZWQgYXMgcmVnaXN0ZXJlZCB2YXJpYW50cyAoYWx0aG91Z2gNCiAgIHRoZXkgcmVtYWlu IGVsaWdpYmxlIGZvciByZWdpc3RyYXRpb24pLiAgRm9yIGV4YW1wbGUsIHRoZSB0YWcgImFydC0N CiAgIGxvamJhbiIgd2FzIGRlcHJlY2F0ZWQgaW4gZmF2b3Igb2YgdGhlIGxhbmd1YWdlIHN1YnRh ZyAnamJvJy4NCg0KICAgVGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBNVVNUIGVuc3VyZSB0 aGF0IG5ldyBzdWJ0YWdzIG1lZXQgdGhlDQogICByZXF1aXJlbWVudHMgaW4gU2VjdGlvbiA0LjEg b3Igc3VibWl0IGFuIGFwcHJvcHJpYXRlIGFsdGVybmF0ZSBzdWJ0YWcNCiAgIGFzIGRlc2NyaWJl ZCBpbiB0aGF0IHNlY3Rpb24uICBJZiBhIGNoYW5nZSBvciBhZGRpdGlvbiB0byB0aGUNCiAgIHJl Z2lzdHJ5IGlzIHJlcXVpcmVkLCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIHdpbGwgcHJl cGFyZSB0aGUNCiAgIGNvbXBsZXRlIHJlY29yZCwgaW5jbHVkaW5nIGFsbCBmaWVsZHMsIGFuZCBm b3J3YXJkIGl0IHRvIElBTkEgZm9yDQogICBpbnNlcnRpb24gaW50byB0aGUgcmVnaXN0cnkuICBJ ZiB0aGlzIHJlcHJlc2VudHMgYSBuZXcgc3VidGFnLCB0aGVuDQogICB0aGUgbWVzc2FnZSB3aWxs IGluZGljYXRlIHRoYXQgdGhpcyByZXByZXNlbnRzIGFuIElOU0VSVElPTiBvZiBhDQogICByZWNv cmQuICBJZiB0aGlzIHJlcHJlc2VudHMgYSBjaGFuZ2UgdG8gYW4gZXhpc3Rpbmcgc3VidGFnLCB0 aGVuIHRoZQ0KICAgbWVzc2FnZSBtdXN0IGluZGljYXRlIHRoYXQgdGhpcyByZXByZXNlbnRzIGEg TU9ESUZJQ0FUSU9OLCBhcyBzaG93bg0KICAgaW4gdGhlIGZvbGxvd2luZyBleGFtcGxlOg0KDQog ICBMQU5HVUFHRSBTVUJUQUcgTU9ESUZJQ0FUSU9ODQogICBGaWxlLURhdGU6IDIwMDUtMDEtMDIN CiAgICUlDQogICBUeXBlOiB2YXJpYW50DQogICBTdWJ0YWc6IG5lZGlzDQogICBEZXNjcmlwdGlv bjogTmF0aXNvbmUgZGlhbGVjdA0KICAgRGVzY3JpcHRpb246IE5hZGl6YSBkaWFsZWN0DQogICBB ZGRlZDogMjAwMy0xMC0wOQ0KICAgUmVjb21tZW5kZWQtUHJlZml4OiBzbA0KICAgQ29tbWVudHM6 IFRoaXMgaXMgYSBjb21tZW50IHNob3duDQogICAgIGFzIGFuIGV4YW1wbGUuDQogICAlJQ0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNA0KDQogICBXaGVuZXZlciBh biBlbnRyeSBpcyBjcmVhdGVkIG9yIG1vZGlmaWVkIGluIHRoZSByZWdpc3RyeSwgdGhlICdGaWxl LQ0KICAgRGF0ZScgcmVjb3JkIGF0IHRoZSBzdGFydCBvZiB0aGUgcmVnaXN0cnkgaXMgdXBkYXRl ZCB0byByZWZsZWN0IHRoZQ0KICAgbW9zdCByZWNlbnQgbW9kaWZpY2F0aW9uIGRhdGUgaW4gdGhl IFJGQyAzMzM5IFsxNF0gImZ1bGwtZGF0ZSINCiAgIGZvcm1hdC4NCg0KMy4zICBTdGFiaWxpdHkg b2YgSUFOQSBSZWdpc3RyeSBFbnRyaWVzDQoNCiAgIFRoZSBzdGFiaWxpdHkgb2YgZW50cmllcyBh bmQgdGhlaXIgbWVhbmluZyBpbiB0aGUgcmVnaXN0cnkgaXMNCiAgIGNyaXRpY2FsIHRvIHRoZSBs b25nIHRlcm0gc3RhYmlsaXR5IG9mIGxhbmd1YWdlIHRhZ3MuICBUaGUgcnVsZXMgaW4NCiAgIHRo aXMgc2VjdGlvbiBndWFyYW50ZWUgdGhhdCBhIHNwZWNpZmljIGxhbmd1YWdlIHRhZydzIG1lYW5p bmcgaXMNCiAgIHN0YWJsZSBvdmVyIHRpbWUgYW5kIHdpbGwgbm90IGNoYW5nZSBhbmQgdGhhdCB0 aGUgY2hvaWNlIG9mIGxhbmd1YWdlDQogICB0YWcgZm9yIHNwZWNpZmljIGNvbnRlbnQgaXMgYWxz byBzdGFibGUgb3ZlciB0aW1lLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBp cmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAyMl0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXBy aWwgMjAwNQ0KDQoNCiAgIFRoZXNlIHJ1bGVzIHNwZWNpZmljYWxseSBkZWFsIHdpdGggaG93IGNo YW5nZXMgdG8gY29kZXMgKGluY2x1ZGluZw0KICAgd2l0aGRyYXdhbCBhbmQgZGVwcmVjYXRpb24g b2YgY29kZXMpIG1haW50YWluZWQgYnkgSVNPIDYzOSwgSVNPDQogICAxNTkyNCwgSVNPIDMxNjYs IGFuZCBVTiBNLjQ5IGFyZSByZWZsZWN0ZWQgaW4gdGhlIElBTkEgTGFuZ3VhZ2UNCiAgIFN1YnRh ZyBSZWdpc3RyeS4gIEFzc2lnbm1lbnRzIHRvIHRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBSZWdp c3RyeQ0KICAgTVVTVCBmb2xsb3cgdGhlIGZvbGxvd2luZyBzdGFiaWxpdHkgcnVsZXM6DQoNCiAg IG8gIFZhbHVlcyBpbiB0aGUgZmllbGRzICdUeXBlJywgJ1N1YnRhZycsICdUYWcnLCAnQWRkZWQn IGFuZA0KICAgICAgJ0Nhbm9uaWNhbCcgTVVTVCBOT1QgYmUgY2hhbmdlZCBhbmQgYXJlIGd1YXJh bnRlZWQgdG8gYmUgc3RhYmxlDQogICAgICBvdmVyIHRpbWUuDQoNCiAgIG8gIFZhbHVlcyBpbiB0 aGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBNVVNUIE5PVCBiZSBjaGFuZ2VkIGluIGEgd2F5DQogICAg ICB0aGF0IHdvdWxkIGludmFsaWRhdGUgcHJldmlvdXNseS1leGlzdGluZyB0YWdzLiAgVGhleSBt YXkgYmUNCiAgICAgIGJyb2FkZW5lZCBzb21ld2hhdCBpbiBzY29wZSwgY2hhbmdlZCB0byBhZGQg aW5mb3JtYXRpb24sIG9yDQogICAgICBhZGFwdGVkIHRvIHRoZSBtb3N0IGNvbW1vbiBtb2Rlcm4g dXNhZ2UuICBGb3IgZXhhbXBsZSwgY291bnRyaWVzDQogICAgICBvY2Nhc2lvbmFsbHkgY2hhbmdl IHRoZWlyIG9mZmljaWFsIG5hbWVzOiBhbiBoaXN0b3JpY2FsIGV4YW1wbGUgb2YNCiAgICAgIHRo aXMgd291bGQgYmUgIlVwcGVyIFZvbHRhIiBjaGFuZ2luZyB0byAiQnVya2luYSBGYXNvIi4NCg0K ICAgbyAgVmFsdWVzIGluIHRoZSBmaWVsZCAnUmVjb21tZW5kZWQtUHJlZml4JyBNQVkgYmUgYWRk ZWQgdmlhIHRoZQ0KICAgICAgcmVnaXN0cmF0aW9uIHByb2Nlc3MuDQoNCiAgIG8gIFZhbHVlcyBp biB0aGUgZmllbGQgJ1JlY29tbWVuZGVkLVByZWZpeCcgTUFZIGJlIG1vZGlmaWVkLCBzbyBsb25n DQogICAgICBhcyB0aGUgbW9kaWZpY2F0aW9ucyBicm9hZGVuIHRoZSBzZXQgb2YgcmVjb21tZW5k ZWQgcHJlZml4ZXMuDQogICAgICBUaGF0IGlzLCBhIHJlY29tbWVuZGVkIHByZWZpeCBNQVkgYmUg cmVwbGFjZWQgYnkgb25lIG9mIGl0cyBvd24NCiAgICAgIHByZWZpeGVzLiAgRm9yIGV4YW1wbGUs IHRoZSBwcmVmaXggImVuLVVTIiBjb3VsZCBiZSByZXBsYWNlZCBieQ0KICAgICAgImVuIiwgYnV0 IG5vdCBieSB0aGUgcmFuZ2VzICJlbi1MYXRuIiwgImZyIiwgb3IgImVuLVVTLWJvb250Ii4NCg0K ICAgbyAgVmFsdWVzIGluIHRoZSBmaWVsZCAnUmVjb21tZW5kZWQtUHJlZml4JyBNVVNUIE5PVCBi ZSByZW1vdmVkLg0KDQogICBvICBUaGUgZmllbGQgJ0NvbW1lbnRzJyBNQVkgYmUgYWRkZWQsIGNo YW5nZWQsIG1vZGlmaWVkLCBvciByZW1vdmVkDQogICAgICB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBw cm9jZXNzIG9yIGFueSBvZiB0aGUgcHJvY2Vzc2VzIG9yDQogICAgICBjb25zaWRlcmF0aW9ucyBk ZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uLg0KDQogICBvICBUaGUgZmllbGQgJ1N1cHByZXNzLVNj cmlwdCcgTUFZIGJlIGFkZGVkIG9yIHJlbW92ZWQgdmlhIHRoZQ0KICAgICAgcmVnaXN0cmF0aW9u IHByb2Nlc3MuDQoNCiAgIG8gIENvZGVzIGFzc2lnbmVkIGJ5IElTTyA2MzksIElTTyAxNTkyNCwg YW5kIElTTyAzMTY2IHRoYXQgZG8gbm90DQogICAgICBjb25mbGljdCB3aXRoIGV4aXN0aW5nIHN1 YnRhZ3Mgb2YgdGhlIGFzc29jaWF0ZWQgdHlwZSBhbmQgd2hvc2UNCiAgICAgIG1lYW5pbmcgaXMg bm90IHRoZSBzYW1lIGFzIGFuIGV4aXN0aW5nIHN1YnRhZyBvZiB0aGUgc2FtZSB0eXBlIGFyZQ0K ICAgICAgZW50ZXJlZCBpbnRvIHRoZSBJQU5BIHJlZ2lzdHJ5IGFzIG5ldyByZWNvcmRzIGFuZCB0 aGVpciB2YWx1ZSBpcw0KICAgICAgY2Fub25pY2FsIGZvciB0aGUgbWVhbmluZyBhc3NpZ25lZCB0 byB0aGVtLg0KDQogICBvICBDb2RlcyBhc3NpZ25lZCBieSBJU08gNjM5LCBJU08gMTU5MjQsIG9y IElTTyAzMTY2IHRoYXQgYXJlDQogICAgICB3aXRoZHJhd24gYnkgdGhlaXIgcmVzcGVjdGl2ZSBt YWludGVuYW5jZSBvciByZWdpc3RyYXRpb24NCiAgICAgIGF1dGhvcml0eSByZW1haW4gdmFsaWQg aW4gbGFuZ3VhZ2UgdGFncy4gIFRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcw0KICAgICAgTUFZIGJl IHVzZWQgdG8gYWRkIGEgbm90ZSBpbmRpY2F0aW5nIHRoZSB3aXRoZHJhd2FsIG9mIHRoZSBjb2Rl IGJ5DQogICAgICB0aGUgcmVzcGVjdGl2ZSBzdGFuZGFyZC4NCg0KDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAgICAgICAgICBbUGFn ZSAyM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIG8gIENvZGVzIGFzc2lnbmVkIGJ5IElT TyA2MzksIElTTyAxNTkyNCwgb3IgSVNPIDMxNjYgdGhhdCBkbyBub3QNCiAgICAgIGNvbmZsaWN0 IHdpdGggZXhpc3Rpbmcgc3VidGFncyBvZiB0aGUgYXNzb2NpYXRlZCB0eXBlIGJ1dCB3aGljaA0K ICAgICAgcmVwcmVzZW50IHRoZSBzYW1lIG1lYW5pbmcgYXMgYW4gZXhpc3Rpbmcgc3VidGFnIG9m IHRoYXQgdHlwZSBhcmUNCiAgICAgIGVudGVyZWQgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcyBu ZXcgcmVjb3Jkcy4gIFRoZSBmaWVsZA0KICAgICAgJ2Nhbm9uaWNhbCB2YWx1ZScgZm9yIHRoYXQg cmVjb3JkIE1VU1QgY29udGFpbiB0aGUgZXhpc3Rpbmcgc3VidGFnDQogICAgICBvZiB0aGUgc2Ft ZSBtZWFuaW5nDQoNCiAgICAgIEV4YW1wbGUgSWYgSVNPIDMxNjYgd2VyZSB0byBhc3NpZ24gdGhl IGNvZGUgJ0lNJyB0byByZXByZXNlbnQgdGhlDQogICAgICAgICB2YWx1ZSAiSXNsZSBvZiBNYW4i IChyZXByZXNlbnRlZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBieSB0aGUgVU4NCiAgICAgICAgIE0u NDkgY29kZSAnODMzJyksICc4MzMnIHJlbWFpbnMgdGhlIGNhbm9uaWNhbCBzdWJ0YWcgYW5kICdJ TScNCiAgICAgICAgIHdvdWxkIGJlIGFzc2lnbmVkICc4MzMnIGFzIGEgY2Fub25pY2FsIHZhbHVl LiAgVGhpcyBwcmV2ZW50cw0KICAgICAgICAgdGFncyB0aGF0IGFyZSBpbiBjYW5vbmljYWwgZm9y bSBmcm9tIGJlY29taW5nIG5vbi1jYW5vbmljYWwuDQoNCiAgICAgIEV4YW1wbGUgSWYgdGhlIHRh ZyAnZW5vY2hpYW4nIHdlcmUgcmVnaXN0ZXJlZCBhcyBhIHByaW1hcnkNCiAgICAgICAgIGxhbmd1 YWdlIHN1YnRhZyBhbmQgSVNPIDYzOSBzdWJzZXF1ZW50bHkgYXNzaWduZWQgYW4gYWxwaGEtMw0K ICAgICAgICAgY29kZSB0byB0aGUgc2FtZSBsYW5ndWFnZSwgdGhlIG5ldyBJU08gNjM5IGNvZGUg d291bGQgYmUNCiAgICAgICAgIGVudGVyZWQgaW50byB0aGUgSUFOQSByZWdpc3RyeSBhcyBhIHN1 YnRhZyB3aXRoIGEgY2Fub25pY2FsDQogICAgICAgICBtYXBwaW5nIHRvICdlbm9jaGlhbicuICBU aGUgbmV3IElTTyBjb2RlIGNhbiBiZSB1c2VkLCBidXQgaXQgaXMNCiAgICAgICAgIG5vdCBjYW5v bmljYWwuDQoNCiAgIG8gIENvZGVzIGFzc2lnbmVkIGJ5IElTTyA2MzksIElTTyAxNTkyNCwgb3Ig SVNPIDMxNjYgdGhhdCBjb25mbGljdA0KICAgICAgd2l0aCBleGlzdGluZyBzdWJ0YWdzIG9mIHRo ZSBhc3NvY2lhdGVkIHR5cGUgTVVTVCBOT1QgYmUgZW50ZXJlZA0KICAgICAgaW50byB0aGUgcmVn aXN0cnkuICBUaGUgZm9sbG93aW5nIGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgYXBwbHk6DQoN CiAgICAgICogIEZvciBJU08gNjM5IGNvZGVzLCBpZiB0aGUgbmV3bHkgYXNzaWduZWQgY29kZSdz IG1lYW5pbmcgaXMgbm90DQogICAgICAgICByZXByZXNlbnRlZCBieSBhIHN1YnRhZyBpbiB0aGUg SUFOQSByZWdpc3RyeSwgdGhlIExhbmd1YWdlDQogICAgICAgICBTdWJ0YWcgUmV2aWV3ZXIsIGFz IGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNCwgc2hhbGwgcHJlcGFyZSBhDQogICAgICAgICBwcm9w b3NhbCBmb3IgZW50ZXJpbmcgaW4gdGhlIElBTkEgcmVnaXN0cnkgYXMgc29vbiBhcyBwcmFjdGlj YWwNCiAgICAgICAgIGEgcmVnaXN0ZXJlZCBsYW5ndWFnZSBzdWJ0YWcgYXMgYW4gYWx0ZXJuYXRl IHZhbHVlIGZvciB0aGUgbmV3DQogICAgICAgICBjb2RlLiAgVGhlIGZvcm0gb2YgdGhlIHJlZ2lz dGVyZWQgbGFuZ3VhZ2Ugc3VidGFnIHdpbGwgYmUgYXQNCiAgICAgICAgIHRoZSBkaXNjcmV0aW9u IG9mIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgYW5kIG11c3QgY29uZm9ybQ0KICAgICAg ICAgdG8gb3RoZXIgcmVzdHJpY3Rpb25zIG9uIGxhbmd1YWdlIHN1YnRhZ3MgaW4gdGhpcyBkb2N1 bWVudC4NCg0KICAgICAgKiAgRm9yIGFsbCBzdWJ0YWdzIHdob3NlIG1lYW5pbmcgaXMgZGVyaXZl ZCBmcm9tIGFuIGV4dGVybmFsDQogICAgICAgICBzdGFuZGFyZCAoaS5lLiAgSVNPIDYzOSwgSVNP IDE1OTI0LCBJU08gMzE2Niwgb3IgVU4gTS40OSksIGlmIGENCiAgICAgICAgIG5ldyBtZWFuaW5n IGlzIGFzc2lnbmVkIHRvIGFuIGV4aXN0aW5nIGNvZGUgYW5kIHRoZSBuZXcgbWVhbmluZw0KICAg ICAgICAgYnJvYWRlbnMgdGhlIG1lYW5pbmcgb2YgdGhhdCBjb2RlLCB0aGVuIHRoZSBtZWFuaW5n IGZvciB0aGUNCiAgICAgICAgIGFzc29jaWF0ZWQgc3VidGFnIE1BWSBiZSBjaGFuZ2VkIHRvIG1h dGNoLiAgVGhlIG1lYW5pbmcgb2YgYQ0KICAgICAgICAgc3VidGFnIE1VU1QgTk9UIGJlIG5hcnJv d2VkLCBob3dldmVyLCBhcyB0aGlzIGNhbiByZXN1bHQgaW4gYW4NCiAgICAgICAgIHVua25vd24g cHJvcG9ydGlvbiBvZiB0aGUgZXhpc3RpbmcgdXNlcyBvZiBhIHN1YnRhZyBiZWNvbWluZw0KICAg ICAgICAgaW52YWxpZC4gIE5vdGU6IElTTyA2MzkgTUEvUkEgaGFzIGFkb3B0ZWQgYSBzaW1pbGFy IHN0YWJpbGl0eQ0KICAgICAgICAgcG9saWN5Lg0KDQogICAgICAqICBGb3IgSVNPIDE1OTI0IGNv ZGVzLCBpZiB0aGUgbmV3bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcgaXMNCiAgICAgICAgIG5v dCByZXByZXNlbnRlZCBieSBhIHN1YnRhZyBpbiB0aGUgSUFOQSByZWdpc3RyeSwgdGhlIExhbmd1 YWdlDQogICAgICAgICBTdWJ0YWcgUmV2aWV3ZXIsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMu NCwgc2hhbGwgcHJlcGFyZSBhDQogICAgICAgICBwcm9wb3NhbCBmb3IgZW50ZXJpbmcgaW4gdGhl IElBTkEgcmVnaXN0cnkgYXMgc29vbiBhcyBwcmFjdGljYWwNCiAgICAgICAgIGEgcmVnaXN0ZXJl ZCB2YXJpYW50IHN1YnRhZyBhcyBhbiBhbHRlcm5hdGUgdmFsdWUgZm9yIHRoZSBuZXcNCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAg ICAgICAgIFtQYWdlIDI0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgICAgICAgY29kZS4g IFRoZSBmb3JtIG9mIHRoZSByZWdpc3RlcmVkIHZhcmlhbnQgc3VidGFnIHdpbGwgYmUgYXQgdGhl DQogICAgICAgICBkaXNjcmV0aW9uIG9mIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgYW5k IG11c3QgY29uZm9ybSB0bw0KICAgICAgICAgb3RoZXIgcmVzdHJpY3Rpb25zIG9uIHZhcmlhbnQg c3VidGFncyBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICAgICAqICBGb3IgSVNPIDMxNjYgY29kZXMs IGlmIHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBpcw0KICAgICAgICAgYXNzb2Np YXRlZCB3aXRoIHRoZSBzYW1lIFVOIE0uNDkgY29kZSBhcyBhbm90aGVyICdyZWdpb24nDQogICAg ICAgICBzdWJ0YWcsIHRoZW4gdGhlIGV4aXN0aW5nIHJlZ2lvbiBzdWJ0YWcgcmVtYWlucyBhcyB0 aGUNCiAgICAgICAgIGNhbm9uaWNhbCBlbnRyeSBmb3IgdGhhdCByZWdpb24gYW5kIG5vIG5ldyBl bnRyeSBpcyBjcmVhdGVkLiAgQQ0KICAgICAgICAgY29tbWVudCBNQVkgYmUgYWRkZWQgdG8gdGhl IGV4aXN0aW5nIHJlZ2lvbiBzdWJ0YWcgaW5kaWNhdGluZw0KICAgICAgICAgdGhlIHJlbGF0aW9u c2hpcCB0byB0aGUgbmV3IElTTyAzMTY2IGNvZGUuDQoNCiAgICAgICogIEZvciBJU08gMzE2NiBj b2RlcywgaWYgdGhlIG5ld2x5IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlzDQogICAgICAgICBh c3NvY2lhdGVkIHdpdGggYSBVTiBNLjQ5IGNvZGUgdGhhdCBpcyBub3QgcmVwcmVzZW50ZWQgYnkg YW4NCiAgICAgICAgIGV4aXN0aW5nIHJlZ2lvbiBzdWJ0YWcsIHRoZW4gdGhlbiB0aGUgTGFuZ3Vh Z2UgU3VidGFnIFJldmlld2VyLA0KICAgICAgICAgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40 LCBzaGFsbCBwcmVwYXJlIGEgcHJvcG9zYWwgZm9yDQogICAgICAgICBlbnRlcmluZyB0aGUgYXBw cm9wcmlhdGUgbnVtZXJpYyBVTiBjb3VudHJ5IGNvZGUgYXMgYW4gZW50cnkgaW4NCiAgICAgICAg IHRoZSBJQU5BIHJlZ2lzdHJ5Lg0KDQogICAgICAqICBGb3IgSVNPIDMxNjYgY29kZXMsIGlmIHRo ZXJlIGlzIG5vIGFzc29jaWF0ZWQgVU4gbnVtZXJpYyBjb2RlLA0KICAgICAgICAgdGhlbiB0aGUg TGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIFNIQUxMIHBldGl0aW9uIHRoZSBVTiB0bw0KICAgICAg ICAgY3JlYXRlIG9uZS4gIElmIHRoZXJlIGlzIG5vIHJlc3BvbnNlIGZyb20gdGhlIFVOIHdpdGhp biBuaW5ldHkNCiAgICAgICAgIGRheXMgb2YgdGhlIHJlcXVlc3QgYmVpbmcgc2VudCwgdGhlIExh bmd1YWdlIFN1YnRhZyBSZXZpZXdlcg0KICAgICAgICAgc2hhbGwgcHJlcGFyZSBhIHByb3Bvc2Fs IGZvciBlbnRlcmluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcw0KICAgICAgICAgc29vbiBhcyBw cmFjdGljYWwgYSByZWdpc3RlcmVkIHZhcmlhbnQgc3VidGFnIGFzIGFuIGFsdGVybmF0ZQ0KICAg ICAgICAgdmFsdWUgZm9yIHRoZSBuZXcgY29kZS4gIFRoZSBmb3JtIG9mIHRoZSByZWdpc3RlcmVk IHZhcmlhbnQNCiAgICAgICAgIHN1YnRhZyB3aWxsIGJlIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRo ZSBMYW5ndWFnZSBTdWJ0YWcNCiAgICAgICAgIFJldmlld2VyIGFuZCBtdXN0IGNvbmZvcm0gdG8g b3RoZXIgcmVzdHJpY3Rpb25zIG9uIHZhcmlhbnQNCiAgICAgICAgIHN1YnRhZ3MgaW4gdGhpcyBk b2N1bWVudC4gIFRoaXMgc2l0dWF0aW9uIGlzIHZlcnkgdW5saWtlbHkgdG8NCiAgICAgICAgIGV2 ZXIgb2NjdXIuDQoNCiAgIG8gIFN0YWJpbGl0eSBwcm92aXNpb25zIGFwcGx5IHRvIGdyYW5kZmF0 aGVyZWQgdGFncyB3aXRoIHRoaXMNCiAgICAgIGV4Y2VwdGlvbjogc2hvdWxkIGFsbCBvZiB0aGUg c3VidGFncyBpbiBhIGdyYW5kZmF0aGVyZWQgdGFnIGJlY29tZQ0KICAgICAgdmFsaWQgc3VidGFn cyBpbiB0aGUgSUFOQSByZWdpc3RyeSwgdGhlbiB0aGUgZ3JhbmRmYXRoZXJlZCB0YWcNCiAgICAg IE1VU1QgYmUgbWFya2VkIGFzIHJlZHVuZGFudC4gIE5vdGUgdGhhdCB0aGlzIHdpbGwgbm90IGFm ZmVjdA0KICAgICAgbGFuZ3VhZ2UgdGFncyB0aGF0IG1hdGNoIHRoZSBncmFuZGZhdGhlcmVkIHRh Zywgc2luY2UgdGhlc2UgdGFncw0KICAgICAgd2lsbCBub3cgbWF0Y2ggdmFsaWQgZ2VuZXJhdGl2 ZSBzdWJ0YWcgc2VxdWVuY2VzLiAgRm9yIGV4YW1wbGUsIGlmDQogICAgICB0aGUgc3VidGFnICdn YW4nIGluIHRoZSBsYW5ndWFnZSB0YWcgInpoLWdhbiIgd2VyZSB0byBiZQ0KICAgICAgcmVnaXN0 ZXJlZCBhcyBhbiBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWcsIHRoZW4gdGhlIGdyYW5kZmF0aGVy ZWQNCiAgICAgIHRhZyAiemgtZ2FuIiB3b3VsZCBiZSBkZXByZWNhdGVkIChidXQgZXhpc3Rpbmcg Y29udGVudCBvcg0KICAgICAgaW1wbGVtZW50YXRpb25zIHRoYXQgdXNlICJ6aC1nYW4iIHdvdWxk IHJlbWFpbiB2YWxpZCkuDQoNCg0KMy40ICBSZWdpc3RyYXRpb24gUHJvY2VkdXJlIGZvciBTdWJ0 YWdzDQoNCiAgIFRoZSBwcm9jZWR1cmUgZ2l2ZW4gaGVyZSBNVVNUIGJlIHVzZWQgYnkgYW55b25l IHdobyB3YW50cyB0byB1c2UgYQ0KICAgc3VidGFnIG5vdCBjdXJyZW50bHkgaW4gdGhlIElBTkEg TGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5Lg0KDQogICBPbmx5IHN1YnRhZ3MgIG9mIHR5cGUgJ2xh bmd1YWdlJyBhbmQgJ3ZhcmlhbnQnIHdpbGwgYmUgY29uc2lkZXJlZCBmb3INCg0KDQoNClBoaWxs aXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAg IFtQYWdlIDI1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lz dHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgaW5kZXBlbmRlbnQgcmVnaXN0 cmF0aW9uIG9mIG5ldyBzdWJ0YWdzLiAgSGFuZGxpbmcgb2Ygc3VidGFncw0KICAgcmVxdWlyZWQg Zm9yIHN0YWJpbGl0eSBhbmQgc3VidGFncyByZXF1aXJlZCB0byBrZWVwIHRoZSByZWdpc3RyeQ0K ICAgc3luY2hyb25pemVkIHdpdGggSVNPIDYzOSwgSVNPIDE1OTI0LCBJU08gMzE2NiwgYW5kIFVO IE0uNDkgd2l0aGluDQogICB0aGUgbGltaXRzIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCBhcmUg ZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4yLg0KICAgU3RhYmlsaXR5IHByb3Zpc2lvbnMgYXJlIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDMuMy4NCg0KICAgVGhpcyBwcm9jZWR1cmUgTUFZIGFsc28gYmUg dXNlZCB0byByZWdpc3RlciBvciBhbHRlciB0aGUgaW5mb3JtYXRpb24NCiAgIGZvciB0aGUgIkRl c2NyaXB0aW9uIiwgIkNvbW1lbnRzIiwgIkRlcHJlY2F0ZWQiLCBvciAiUmVjb21tZW5kZWQtDQog ICBQcmVmaXgiIGZpZWxkcyBpbiBhIHN1YnRhZydzIHJlY29yZCBhcyBkZXNjcmliZWQgaW4gRmln dXJlIDcuDQogICBDaGFuZ2VzIHRvIGFsbCBvdGhlciBmaWVsZHMgaW4gdGhlIElBTkEgcmVnaXN0 cnkgYXJlIE5PVCBwZXJtaXR0ZWQuDQoNCiAgIFJlZ2lzdGVyaW5nIGEgbmV3IHN1YnRhZyBvciBy ZXF1ZXN0aW5nIG1vZGlmaWNhdGlvbnMgdG8gYW4gZXhpc3RpbmcNCiAgIHRhZyBvciBzdWJ0YWcg c3RhcnRzIHdpdGggdGhlIHJlcXVzdGVyIGZpbGxpbmcgb3V0IHRoZSByZWdpc3RyYXRpb24NCiAg IGZvcm0gcmVwcm9kdWNlZCBiZWxvdy4gIE5vdGUgdGhhdCBlYWNoIHJlc3BvbnNlIGlzIG5vdCBs aW1pdGVkIGluDQogICBzaXplIGFuZCBzaG91bGQgdGFrZSB0aGUgcm9vbSBuZWNlc3NhcnkgdG8g YWRlcXVhdGVseSBkZXNjcmliZSB0aGUNCiAgIHJlZ2lzdHJhdGlvbi4gIFRoZSBmaWVsZHMgaW4g dGhlICJSZWNvcmQgUmVxdWVzdGVkIiBzZWN0aW9uIFNIT1VMRA0KICAgZm9sbG93IHRoZSByZXF1 aXJlbWVudHMgaW4gU2VjdGlvbiAzLjEuDQoNCiAgIExBTkdVQUdFIFNVQlRBRyBSRUdJU1RSQVRJ T04gRk9STQ0KICAgMS4gTmFtZSBvZiByZXF1ZXN0ZXI6DQogICAyLiBFLW1haWwgYWRkcmVzcyBv ZiByZXF1ZXN0ZXI6DQogICAzLiBSZWNvcmQgUmVxdWVzdGVkOg0KDQogICBUeXBlOg0KICAgU3Vi dGFnOg0KICAgRGVzY3JpcHRpb246DQogICBSZWNvbW1lbmRlZC1QcmVmaXg6DQogICBDYW5vbmlj YWw6DQogICBEZXByZWNhdGVkOg0KICAgU3VwcHJlc3MtU2NyaXB0Og0KICAgQ29tbWVudHM6DQoN CiAgIDQuIEludGVuZGVkIG1lYW5pbmcgb2YgdGhlIHN1YnRhZzoNCiAgIDUuIFJlZmVyZW5jZSB0 byBwdWJsaXNoZWQgZGVzY3JpcHRpb24NCiAgIG9mIHRoZSBsYW5ndWFnZSAoYm9vayBvciBhcnRp Y2xlKToNCiAgIDYuIEFueSBvdGhlciByZWxldmFudCBpbmZvcm1hdGlvbjoNCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDUNCg0KICAgVGhlIHN1YnRhZyByZWdpc3Ry YXRpb24gZm9ybSBNVVNUIGJlIHNlbnQgdG8NCiAgIDxpZXRmLWxhbmd1YWdlc0BpYW5hLm9yZz4g Zm9yIGEgdHdvIHdlZWsgcmV2aWV3IHBlcmlvZCBiZWZvcmUgaXQgY2FuDQogICBiZSBzdWJtaXR0 ZWQgdG8gSUFOQS4gIChUaGlzIGlzIGFuIG9wZW4gbGlzdC4gIFJlcXVlc3RzIHRvIGJlIGFkZGVk DQogICBzaG91bGQgYmUgc2VudCB0byA8aWV0Zi1sYW5ndWFnZXMtcmVxdWVzdEBpYW5hLm9yZz4u KQ0KDQogICBWYXJpYW50IHN1YnRhZ3MgYXJlIGdlbmVyYWxseSByZWdpc3RlcmVkIGZvciB1c2Ug d2l0aCBhIHBhcnRpY3VsYXINCiAgIHJhbmdlIG9mIGxhbmd1YWdlIHRhZ3MuICBGb3IgZXhhbXBs ZSwgdGhlIHN1YnRhZyAnc2NvdXNlJyBpcyBpbnRlbmRlZA0KICAgZm9yIHVzZSB3aXRoIGxhbmd1 YWdlIHRhZ3MgdGhhdCBzdGFydCB3aXRoIHRoZSBwcmltYXJ5IGxhbmd1YWdlDQogICBzdWJ0YWcg ImVuIiwgc2luY2UgU2NvdXNlIGlzIGEgZGlhbGVjdCBvZiBFbmdsaXNoLiAgVGh1cyB0aGUgc3Vi dGFnDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjgsIDIw MDUgICAgICAgICAgICAgICBbUGFnZSAyNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgICdz Y291c2UnIGNvdWxkIGJlIGluY2x1ZGVkIGluIHRhZ3Mgc3VjaCBhcyAiZW4tTGF0bi1zY291c2Ui IG9yICJlbi0NCiAgIEdCLXNjb3VzZSIuICBUaGlzIGluZm9ybWF0aW9uIGlzIHN0b3JlZCBpbiB0 aGUgIlJlY29tbWVuZGVkLVByZWZpeCINCiAgIGZpZWxkIGluIHRoZSByZWdpc3RyeS4gIFZhcmlh bnQgcmVnaXN0cmF0aW9uIHJlcXVlc3RzIGFyZSBSRVFVSVJFRCB0bw0KICAgaW5jbHVkZSBhdCBs ZWFzdCBvbmUgIlJlY29tbWVuZGVkLVByZWZpeCIgZmllbGQgaW4gdGhlIHJlZ2lzdHJhdGlvbg0K ICAgZm9ybS4NCg0KICAgQW55IHN1YnRhZyBNQVkgYmUgaW5jb3Jwb3JhdGVkIGludG8gYSB2YXJp ZXR5IG9mIGxhbmd1YWdlIHRhZ3MsDQogICBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIG9mIFNlY3Rp b24gMi4xLCBpbmNsdWRpbmcgdGFncyB0aGF0IGRvIG5vdA0KICAgbWF0Y2ggYW55IG9mIHRoZSBy ZWNvbW1lbmRlZCBwcmVmaXhlcyBvZiB0aGUgcmVnaXN0ZXJlZCBzdWJ0YWcuDQogICAoTm90ZSB0 aGF0IHRoaXMgaXMgcHJvYmFibHkgYSBwb29yIGNob2ljZS4pICBUaGlzIG1ha2VzIHZhbGlkYXRp b24NCiAgIHNpbXBsZXIgYW5kIHRodXMgbW9yZSB1bmlmb3JtIGFjcm9zcyBpbXBsZW1lbnRhdGlv bnMsIGFuZCBkb2VzIG5vdA0KICAgcmVxdWlyZSB0aGUgcmVnaXN0cmF0aW9uIG9mIGEgc2VwYXJh dGUgc3VidGFnIGZvciB0aGUgc2FtZSBwdXJwb3NlDQogICBhbmQgbWVhbmluZyBidXQgYSBkaWZm ZXJlbnQgcmVjb21tZW5kZWQgcHJlZml4Lg0KDQogICBUaGUgcmVjb21tZW5kZWQgcHJlZml4ZXMg Zm9yIGEgZ2l2ZW4gcmVnaXN0ZXJlZCBzdWJ0YWcgd2lsbCBiZQ0KICAgbWFpbnRhaW5lZCBpbiB0 aGUgSUFOQSByZWdpc3RyeSBhcyBhIGd1aWRlIHRvIHVzYWdlLiAgSWYgaXQgaXMNCiAgIG5lY2Vz c2FyeSB0byBhZGQgYW4gYWRkaXRpb25hbCBwcmVmaXggdG8gdGhhdCBsaXN0IGZvciBhbiBleGlz dGluZw0KICAgbGFuZ3VhZ2UgdGFnLCB0aGF0IGNhbiBiZSBkb25lIGJ5IGZpbGluZyBhbiBhZGRp dGlvbmFsIHJlZ2lzdHJhdGlvbg0KICAgZm9ybS4gIEluIHRoYXQgZm9ybSwgdGhlICJBbnkgb3Ro ZXIgcmVsZXZhbnQgaW5mb3JtYXRpb246IiBmaWVsZA0KICAgc2hvdWxkIGluZGljYXRlIHRoYXQg aXQgaXMgdGhlIGFkZGl0aW9uIG9mIGFuIGFkZGl0aW9uYWwgcmVjb21tZW5kZWQNCiAgIHByZWZp eC4NCg0KICAgUmVxdWVzdHMgdG8gYWRkIGEgcmVjb21tZW5kZWQgcHJlZml4IHRvIGEgc3VidGFn IHRoYXQgaW1wbHkgYQ0KICAgZGlmZmVyZW50IHNlbWFudGljIG1lYW5pbmcgd2lsbCBwcm9iYWJs eSBiZSByZWplY3RlZC4gIEZvciBleGFtcGxlLCBhDQogICByZXF1ZXN0IHRvIGFkZCB0aGUgcHJl Zml4ICJkZSIgdG8gdGhlIHN1YnRhZyAnbmVkaXMnIHNvIHRoYXQgdGhlIHRhZw0KICAgImRlLW5l ZGlzIiByZXByZXNlbnRlZCBzb21lIEdlcm1hbiBkaWFsZWN0IHdvdWxkIGJlIHJlamVjdGVkLiAg VGhlDQogICAnbmVkaXMnIHN1YnRhZyByZXByZXNlbnRzIGEgcGFydGljdWxhciBTbG92ZW5pYW4g ZGlhbGVjdCBhbmQgdGhlDQogICBhZGRpdGlvbmFsIHJlZ2lzdHJhdGlvbiB3b3VsZCBjaGFuZ2Ug dGhlIHNlbWFudGljIG1lYW5pbmcgYXNzaWduZWQgdG8NCiAgIHRoZSBzdWJ0YWcuICBBIHNlcGFy YXRlIHN1YnRhZyBzaG91bGQgYmUgcHJvcG9zZWQgaW5zdGVhZC4NCg0KICAgVGhlICdEZXNjcmlw dGlvbicgZmllbGQgbXVzdCBjb250YWluIGEgZGVzY3JpcHRpb24gb2YgdGhlIHRhZyBiZWluZw0K ICAgcmVnaXN0ZXJlZCB3cml0dGVuIG9yIHRyYW5zY3JpYmVkIGludG8gdGhlIExhdGluIHNjcmlw dDsgaXQgbWF5IGFsc28NCiAgIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBpbiBhIG5vbi1MYXRpbiBz Y3JpcHQuICBOb24tQVNDSUkgY2hhcmFjdGVycw0KICAgbXVzdCBiZSBlc2NhcGVkIHVzaW5nIHRo ZSBzeW50YXggZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xLiAgVGhlDQogICAnRGVzY3JpcHRpb24n IGZpZWxkIGlzIHVzZWQgZm9yIGlkZW50aWZpY2F0aW9uIHB1cnBvc2VzIGFuZCBzaG91bGQNCiAg IG5vdCBiZSB0YWtlbiB0byByZXByZXNlbnQgdGhlIGFjdHVhbCBuYXRpdmUgbmFtZSBvZiB0aGUg bGFuZ3VhZ2Ugb3INCiAgIHZhcmlhdGlvbiBvciB0byBiZSBpbiBhbnkgcGFydGljdWxhciBsYW5n dWFnZS4NCg0KICAgV2hpbGUgdGhlICdEZXNjcmlwdGlvbicgZmllbGQgaXRzZWxmIGlzIG5vdCBn dWFyYW50ZWVkIHRvIGJlIHN0YWJsZQ0KICAgYW5kIGVycmF0YSBjb3JyZWN0aW9ucyBtYXkgYmUg dW5kZXJ0YWtlbiBmcm9tIHRpbWUgdG8gdGltZSwgYXR0ZW1wdHMNCiAgIHRvIHByb3ZpZGUgdHJh bnNsYXRpb25zIG9yIHRyYW5zY3JpcHRpb25zIG9mIGVudHJpZXMgaW4gdGhlIHJlZ2lzdHJ5DQog ICBpdHNlbGYgd2lsbCBwcm9iYWJseSBiZSBmcm93bmVkIHVwb24gYnkgdGhlIGNvbW11bml0eSBv ciByZWplY3RlZA0KICAgb3V0cmlnaHQsIGFzIGNoYW5nZXMgb2YgdGhpcyBuYXR1cmUgbWF5IGlt cGFjdCB0aGUgcHJvdmlzaW9ucyBpbg0KICAgU2VjdGlvbiAzLjMuDQoNCiAgIFRoZSBMYW5ndWFn ZSBTdWJ0YWcgUmV2aWV3ZXIgaXMgcmVzcG9uc2libGUgZm9yIHJlc3BvbmRpbmcgdG8NCiAgIHJl cXVlc3RzIGZvciB0aGUgcmVnaXN0cmF0aW9uIG9mIHN1YnRhZ3MgdGhyb3VnaCB0aGUgcmVnaXN0 cmF0aW9uDQogICBwcm9jZXNzICBhbmQgaXMgYXBwb2ludGVkIGJ5IHRoZSBJRVNHLg0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAyMDA1ICAgICAgICAg ICAgICAgW1BhZ2UgMjddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICBXaGVuIHRoZSB0d28g d2VlayBwZXJpb2QgaGFzIHBhc3NlZCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyDQogICBl aXRoZXIgZm9yd2FyZHMgdGhlIHJlY29yZCB0byBiZSBpbnNlcnRlZCBvciBtb2RpZmllZCB0bw0K ICAgaWFuYUBpYW5hLm9yZyBhY2NvcmRpbmcgdG8gdGhlIHByb2NlZHVyZSBkZXNjcmliZWQgaW4g U2VjdGlvbiAzLjIsIG9yDQogICByZWplY3RzIHRoZSByZXF1ZXN0IGJlY2F1c2Ugb2Ygc2lnbmlm aWNhbnQgb2JqZWN0aW9ucyByYWlzZWQgb24gdGhlDQogICBsaXN0IG9yIGR1ZSB0byBwcm9ibGVt cyB3aXRoIGNvbnN0cmFpbnRzIGluIHRoaXMgZG9jdW1lbnQgKHdoaWNoDQogICBzaG91bGQgYmUg ZXhwbGljaXRseSBjaXRlZCkuICBUaGUgcmV2aWV3ZXIgbWF5IGFsc28gZXh0ZW5kIHRoZSByZXZp ZXcNCiAgIHBlcmlvZCBpbiB0d28gd2VlayBpbmNyZW1lbnRzIHRvIHBlcm1pdCBmdXJ0aGVyIGRp c2N1c3Npb24uICBUaGUNCiAgIHJldmlld2VyIG11c3QgaW5kaWNhdGUgb24gdGhlIGxpc3Qgd2hl dGhlciB0aGUgcmVnaXN0cmF0aW9uIGhhcyBiZWVuDQogICBhY2NlcHRlZCwgcmVqZWN0ZWQsIG9y IGV4dGVuZGVkIGZvbGxvd2luZyBlYWNoIHR3byB3ZWVrIHBlcmlvZC4NCg0KICAgTm90ZSB0aGF0 IHRoZSByZXZpZXdlciBjYW4gcmFpc2Ugb2JqZWN0aW9ucyBvbiB0aGUgbGlzdCBpZiBoZSBvciBz aGUNCiAgIHNvIGRlc2lyZXMuICBUaGUgaW1wb3J0YW50IHRoaW5nIGlzIHRoYXQgdGhlIG9iamVj dGlvbiBtdXN0IGJlIG1hZGUNCiAgIHB1YmxpY2x5Lg0KDQogICBUaGUgYXBwbGljYW50IGlzIGZy ZWUgdG8gbW9kaWZ5IGEgcmVqZWN0ZWQgYXBwbGljYXRpb24gd2l0aA0KICAgYWRkaXRpb25hbCBp bmZvcm1hdGlvbiBhbmQgc3VibWl0IGl0IGFnYWluOyB0aGlzIHJlc3RhcnRzIHRoZSB0d28NCiAg IHdlZWsgY29tbWVudCBwZXJpb2QuDQoNCiAgIERlY2lzaW9ucyBtYWRlIGJ5IHRoZSByZXZpZXdl ciBtYXkgYmUgYXBwZWFsZWQgdG8gdGhlIElFU0cgW1JGQyAyMDI4XQ0KICAgWzldIHVuZGVyIHRo ZSBzYW1lIHJ1bGVzIGFzIG90aGVyIElFVEYgZGVjaXNpb25zIFtSRkMgMjAyNl0gWzhdLg0KDQog ICBBbGwgYXBwcm92ZWQgcmVnaXN0cmF0aW9uIGZvcm1zIGFyZSBhdmFpbGFibGUgb25saW5lIGlu IHRoZSBkaXJlY3RvcnkNCiAgIGh0dHA6Ly93d3cuaWFuYS5vcmcvbnVtYmVycy5odG1sIHVuZGVy ICJsYW5ndWFnZXMiLg0KDQogICBVcGRhdGVzIG9yIGNoYW5nZXMgdG8gZXhpc3RpbmcgcmVjb3Jk cywgaW5jbHVkaW5nIHByZXZpb3VzDQogICByZWdpc3RyYXRpb25zLCBmb2xsb3cgdGhlIHNhbWUg cHJvY2VkdXJlIGFzIG5ldyByZWdpc3RyYXRpb25zLiAgVGhlDQogICBMYW5ndWFnZSBTdWJ0YWcg UmV2aWV3ZXIgZGVjaWRlcyB3aGV0aGVyIHRoZXJlIGlzIGNvbnNlbnN1cyB0byB1cGRhdGUNCiAg IHRoZSByZWdpc3RyYXRpb24gZm9sbG93aW5nIHRoZSB0d28gd2VlayByZXZpZXcgcGVyaW9kOyBu b3JtYWxseQ0KICAgb2JqZWN0aW9ucyBieSB0aGUgb3JpZ2luYWwgcmVnaXN0cmFudCB3aWxsIGNh cnJ5IGV4dHJhIHdlaWdodCBpbg0KICAgZm9ybWluZyBzdWNoIGEgY29uc2Vuc3VzLg0KDQogICBS ZWdpc3RyYXRpb25zIGFyZSBwZXJtYW5lbnQgYW5kIHN0YWJsZS4gIE9uY2UgcmVnaXN0ZXJlZCwg c3VidGFncw0KICAgd2lsbCBub3QgYmUgcmVtb3ZlZCBmcm9tIHRoZSByZWdpc3RyeSBhbmQgd2ls bCByZW1haW4gdGhlIGNhbm9uaWNhbA0KICAgbWV0aG9kIG9mIHJlZmVycmluZyB0byBhIHNwZWNp ZmljIGxhbmd1YWdlIG9yIHZhcmlhbnQuICBUaGlzDQogICBwcm92aXNpb24gZG9lcyBub3QgYXBw bHkgdG8gZ3JhbmRmYXRoZXJlZCB0YWdzLCB3aGljaCBtYXkgYmVjb21lDQogICBkZXByZWNhdGVk IGR1ZSB0byByZWdpc3RyYXRpb24gb2Ygc3VidGFncy4gIEZvciBleGFtcGxlLCB0aGUgdGFnDQog ICAiaS1uYXZham8iIGlzIGRlcHJlY2F0ZWQgaW4gZmF2b3Igb2YgdGhlIElTTyA2MzktMSBiYXNl ZCBzdWJ0YWcgJ252Jy4NCg0KICAgTm90ZTogVGhlIHB1cnBvc2Ugb2YgdGhlICJwdWJsaXNoZWQg ZGVzY3JpcHRpb24iIGluIHRoZSByZWdpc3RyYXRpb24NCiAgIGZvcm0gaXMgaW50ZW5kZWQgYXMg YW4gYWlkIHRvIHBlb3BsZSB0cnlpbmcgdG8gdmVyaWZ5IHdoZXRoZXIgYQ0KICAgbGFuZ3VhZ2Ug aXMgcmVnaXN0ZXJlZCBvciB3aGF0IGxhbmd1YWdlIG9yIGxhbmd1YWdlIHZhcmlhdGlvbiBhDQog ICBwYXJ0aWN1bGFyIHN1YnRhZyByZWZlcnMgdG8uICBJbiBtb3N0IGNhc2VzLCByZWZlcmVuY2Ug dG8gYW4NCiAgIGF1dGhvcml0YXRpdmUgZ3JhbW1hciBvciBkaWN0aW9uYXJ5IG9mIHRoYXQgbGFu Z3VhZ2Ugd2lsbCBiZSB1c2VmdWw7DQogICBpbiBjYXNlcyB3aGVyZSBubyBzdWNoIHdvcmsgZXhp c3RzLCBvdGhlciB3ZWxsIGtub3duIHdvcmtzIGRlc2NyaWJpbmcNCiAgIHRoYXQgbGFuZ3VhZ2Ug b3IgaW4gdGhhdCBsYW5ndWFnZSBtYXkgYmUgYXBwcm9wcmlhdGUuICBUaGUgc3VidGFnDQogICBy ZXZpZXdlciBkZWNpZGVzIHdoYXQgY29uc3RpdHV0ZXMgImdvb2QgZW5vdWdoIiByZWZlcmVuY2Ug bWF0ZXJpYWwuDQogICBUaGlzIHJlcXVpcmVtZW50IGlzIG5vdCBpbnRlbmRlZCB0byBleGNsdWRl IHBhcnRpY3VsYXIgbGFuZ3VhZ2VzIG9yDQogICBkaWFsZWN0cyBkdWUgdG8gdGhlIHNpemUgb2Yg dGhlIHNwZWFrZXIgcG9wdWxhdGlvbiBvciBsYWNrIG9mIGENCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDI4 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgc3RhbmRhcmRpemVkIG9ydGhvZ3JhcGh5LiAg TWlub3JpdHkgbGFuZ3VhZ2VzIHdpbGwgYmUgY29uc2lkZXJlZA0KICAgZXF1YWxseSBvbiB0aGVp ciBvd24gbWVyaXRzLg0KDQozLjUgIFBvc3NpYmlsaXRpZXMgZm9yIFJlZ2lzdHJhdGlvbg0KDQog ICBQb3NzaWJpbGl0aWVzIGZvciByZWdpc3RyYXRpb24gb2Ygc3VidGFncyBvciBpbmZvcm1hdGlv biBhYm91dA0KICAgc3VidGFncyBpbmNsdWRlOg0KDQogICBvICBQcmltYXJ5IGxhbmd1YWdlIHN1 YnRhZ3MgZm9yIGxhbmd1YWdlcyBub3QgbGlzdGVkIGluIElTTyA2MzkgdGhhdA0KICAgICAgYXJl IG5vdCB2YXJpYW50cyBvZiBhbnkgbGlzdGVkIG9yIHJlZ2lzdGVyZWQgbGFuZ3VhZ2UgY2FuIGJl DQogICAgICByZWdpc3RlcmVkLiAgQXQgdGhlIHRpbWUgdGhpcyBkb2N1bWVudCB3YXMgY3JlYXRl ZCB0aGVyZSB3ZXJlIG5vDQogICAgICBleGFtcGxlcyBvZiB0aGlzIGZvcm0gb2Ygc3VidGFnLiAg QmVmb3JlIGF0dGVtcHRpbmcgdG8gcmVnaXN0ZXIgYQ0KICAgICAgbGFuZ3VhZ2Ugc3VidGFnLCB0 aGVyZSBNVVNUIGJlIGFuIGF0dGVtcHQgdG8gcmVnaXN0ZXIgdGhlIGxhbmd1YWdlDQogICAgICB3 aXRoIElTTyA2MzkuICBObyBsYW5ndWFnZSBzdWJ0YWdzIHdpbGwgYmUgcmVnaXN0ZXJlZCBmb3Ig Y29kZXMNCiAgICAgIHRoYXQgZXhpc3QgaW4gSVNPIDYzOS0xIG9yIElTTyA2MzktMiwgd2hpY2gg YXJlIHVuZGVyDQogICAgICBjb25zaWRlcmF0aW9uIGJ5IHRoZSBJU08gNjM5IG1haW50ZW5hbmNl IG9yIHJlZ2lzdHJhdGlvbg0KICAgICAgYXV0aG9yaXRpZXMsIG9yIHdoaWNoIGhhdmUgbmV2ZXIg YmVlbiBhdHRlbXB0ZWQgZm9yIHJlZ2lzdHJhdGlvbg0KICAgICAgd2l0aCB0aG9zZSBhdXRob3Jp dGllcy4gIElmIElTTyA2MzkgaGFzIHByZXZpb3VzbHkgcmVqZWN0ZWQgYQ0KICAgICAgbGFuZ3Vh Z2UgZm9yIHJlZ2lzdHJhdGlvbiwgaXQgaXMgcmVhc29uYWJsZSB0byBhc3N1bWUgdGhhdCB0aGVy ZQ0KICAgICAgTVVTVCBiZSBhZGRpdGlvbmFsIHZlcnkgY29tcGVsbGluZyBldmlkZW5jZSBvZiBu ZWVkIGJlZm9yZSBpdCB3aWxsDQogICAgICBiZSByZWdpc3RlcmVkIGluIHRoZSBJQU5BIHJlZ2lz dHJ5ICh0byB0aGUgZXh0ZW50IHRoYXQgaXQgaXMgdmVyeQ0KICAgICAgdW5saWtlbHkgdGhhdCBh bnkgc3VidGFncyB3aWxsIGJlIHJlZ2lzdGVyZWQgb2YgdGhpcyB0eXBlKS4NCg0KICAgbyAgRGlh bGVjdCBvciBvdGhlciBkaXZpc2lvbnMgb3IgdmFyaWF0aW9ucyB3aXRoaW4gYSBsYW5ndWFnZSwg aXRzDQogICAgICBvcnRob2dyYXBoeSwgd3JpdGluZyBzeXN0ZW0sIHJlZ2lvbmFsIG9yIGhpc3Rv cmljYWwgdXNhZ2UsDQogICAgICB0cmFuc2xpdGVyYXRpb24gb3Igb3RoZXIgdHJhbnNmb3JtYXRp b24sIG9yIGRpc3Rpbmd1aXNoaW5nDQogICAgICB2YXJpYXRpb24gbWF5IGJlIHJlZ2lzdGVyZWQg YXMgdmFyaWFudCBzdWJ0YWdzLiAgQW4gZXhhbXBsZSBpcyB0aGUNCiAgICAgICdzY291c2UnIHN1 YnRhZyAodGhlIFNjb3VzZSBkaWFsZWN0IG9mIEVuZ2xpc2gpLg0KDQogICBvICBUaGUgYWRkaXRp b24gb3IgbWFpbnRlbmFuY2Ugb2YgZmllbGRzIChnZW5lcmFsbHkgb2YgYW4NCiAgICAgIGluZm9y bWF0aW9uYWwgbmF0dXJlKSBpbiBUYWcgb3IgU3VidGFnIHJlY29yZHMgYXMgZGVzY3JpYmVkIGlu DQogICAgICBTZWN0aW9uIDMuMSBhbmQgc3ViamVjdCB0byB0aGUgc3RhYmlsaXR5IHByb3Zpc2lv bnMgaW4NCiAgICAgIFNlY3Rpb24gMy4zLiAgVGhpcyBpbmNsdWRlcyBkZXNjcmlwdGlvbnMsIHJl Y29tbWVuZGVkIHByZWZpeGVzLA0KICAgICAgY29tbWVudHMsIGRlcHJlY2F0aW9uIG9mIG9ic29s ZXRlIGl0ZW1zLCBvciB0aGUgYWRkaXRpb24gb2Ygc2NyaXB0DQogICAgICBvciBleHRsYW5nIGlu Zm9ybWF0aW9uIHRvIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncy4NCg0KICAgVGhpcyBkb2N1bWVu dCBsZWF2ZXMgdGhlIGRlY2lzaW9uIG9uIHdoYXQgc3VidGFncyAgb3IgY2hhbmdlcyB0bw0KICAg c3VidGFncyBhcmUgYXBwcm9wcmlhdGUgKG9yIG5vdCkgdG8gdGhlIHJlZ2lzdHJhdGlvbiBwcm9j ZXNzDQogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjQuDQoNCiAgIE5vdGU6IGZvdXIgY2hhcmFj dGVyIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBhcmUgcmVzZXJ2ZWQgdG8gYWxsb3cNCiAgIGZv ciB0aGUgcG9zc2liaWxpdHkgb2YgIGFscGhhNCBjb2RlcyBpbiBzb21lIGZ1dHVyZSBhZGRpdGlv biB0byB0aGUNCiAgIElTTyA2MzkgZmFtaWx5IG9mIHN0YW5kYXJkcy4NCg0KICAgSVNPIDYzOSBk ZWZpbmVzIGEgbWFpbnRlbmFuY2UgYWdlbmN5IGZvciBhZGRpdGlvbnMgdG8gYW5kIGNoYW5nZXMg aW4NCiAgIHRoZSBsaXN0IG9mIGxhbmd1YWdlcyBpbiBJU08gNjM5LiAgVGhpcyBhZ2VuY3kgaXM6 DQoNCiAgIEludGVybmF0aW9uYWwgSW5mb3JtYXRpb24gQ2VudHJlIGZvciBUZXJtaW5vbG9neSAo SW5mb3Rlcm0pDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIg MjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAyOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoN CiAgICBBaWNoaG9semdhc3NlIDYvMTIsIEFULTExMjANCiAgIFdpZW4sIEF1c3RyaWENCiAgIFBo b25lOiArNDMgMSAyNiA3NSAzNSBFeHQuIDMxMiBGYXg6ICs0MyAxIDIxNiAzMiA3Mg0KDQogICBJ U08gNjM5LTIgZGVmaW5lcyBhIG1haW50ZW5hbmNlIGFnZW5jeSBmb3IgYWRkaXRpb25zIHRvIGFu ZCBjaGFuZ2VzDQogICBpbiB0aGUgbGlzdCBvZiBsYW5ndWFnZXMgaW4gSVNPIDYzOS0yLiAgVGhp cyBhZ2VuY3kgaXM6DQoNCiAgIExpYnJhcnkgb2YgQ29uZ3Jlc3MNCiAgIE5ldHdvcmsgRGV2ZWxv cG1lbnQgYW5kIE1BUkMgU3RhbmRhcmRzIE9mZmljZQ0KICAgV2FzaGluZ3RvbiwgRC5DLiAyMDU0 MCBVU0ENCiAgIFBob25lOiArMSAyMDIgNzA3IDYyMzcgIEZheDogKzEgMjAyIDcwNyAwMTE1DQog ICBVUkw6IGh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMvaXNvNjM5DQoNCiAgIFRoZSBtYWlu dGVuYW5jZSBhZ2VuY3kgZm9yIElTTyAzMTY2IChjb3VudHJ5IGNvZGVzKSBpczoNCg0KICAgSVNP IDMxNjYgTWFpbnRlbmFuY2UgQWdlbmN5DQogICBjL28gSW50ZXJuYXRpb25hbCBPcmdhbml6YXRp b24gZm9yIFN0YW5kYXJkaXphdGlvbg0KICAgQ2FzZSBwb3N0YWxlIDU2DQogICBDSC0xMjExIEdl bmV2YSAyMCBTd2l0emVybGFuZA0KICAgUGhvbmU6ICs0MSAyMiA3NDkgNzIgMzMgIEZheDogKzQx IDIyIDc0OSA3MyA0OQ0KICAgVVJMOiBodHRwOi8vd3d3Lmlzby5vcmcvaXNvL2VuL3Byb2RzLXNl cnZpY2VzL2lzbzMxNjZtYS9pbmRleC5odG1sDQoNCiAgIFRoZSByZWdpc3RyYXRpb24gYXV0aG9y aXR5IGZvciBJU08gMTU5MjQgKHNjcmlwdCBjb2RlcykgaXM6DQoNCiAgIFVuaWNvZGUgQ29uc29y dGl1bSBCb3ggMzkxNDc2DQogICBNb3VudGFpbiBWaWV3LCBDQSA5NDAzOS0xNDc2LCBVU0ENCiAg IFVSTDogaHR0cDovL3d3dy51bmljb2RlLm9yZy9pc28xNTkyNA0KDQogICBUaGUgU3RhdGlzdGlj cyBEaXZpc2lvbiBvZiB0aGUgVW5pdGVkIE5hdGlvbnMgU2VjcmV0YXJpYXQgbWFpbnRhaW5zDQog ICB0aGUgU3RhbmRhcmQgQ291bnRyeSBvciBBcmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCBVc2Ug YW5kIGNhbiBiZQ0KICAgcmVhY2hlZCBhdDoNCg0KICAgU3RhdGlzdGljYWwgU2VydmljZXMgQnJh bmNoDQogICBTdGF0aXN0aWNzIERpdmlzaW9uDQogICBVbml0ZWQgTmF0aW9ucywgUm9vbSBEQzIt MTYyMA0KICAgTmV3IFlvcmssIE5ZIDEwMDE3LCBVU0ENCg0KICAgRmF4OiArMS0yMTItOTYzLTA2 MjMNCiAgIEUtbWFpbDogc3RhdGlzdGljc0B1bi5vcmcNCiAgIFVSTDogaHR0cDovL3Vuc3RhdHMu dW4ub3JnL3Vuc2QvbWV0aG9kcy9tNDkvbTQ5YWxwaGEuaHRtDQoNCjMuNiAgRXh0ZW5zaW9ucyBh bmQgRXh0ZW5zaW9ucyBOYW1lc3BhY2UNCg0KICAgRXh0ZW5zaW9uIHN1YnRhZ3MgYXJlIHRob3Nl IGludHJvZHVjZWQgYnkgc2luZ2xlLWxldHRlciBzdWJ0YWdzIG90aGVyDQogICB0aGFuICd4LScu ICBUaGV5IGFyZSByZXNlcnZlZCBmb3IgdGhlIGdlbmVyYXRpb24gb2YgaWRlbnRpZmllcnMgd2hp Y2gNCiAgIGNvbnRhaW4gYSBsYW5ndWFnZSBjb21wb25lbnQsIGFuZCBhcmUgY29tcGF0aWJsZSB3 aXRoIGFwcGxpY2F0aW9ucw0KICAgdW5kZXJzdGFuZCBsYW5ndWFnZSB0YWdzLiAgRm9yIGV4YW1w bGUsIHRoZXkgbWlnaHQgYmUgdXNlZCB0byBkZWZpbmUNCiAgIGxvY2FsZSBpZGVudGlmaWVycywg d2hpY2ggYXJlIGdlbmVyYWxseSBiYXNlZCBvbiBsYW5ndWFnZS4NCg0KDQoNClBoaWxsaXBzICYg RGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdl IDMwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAg ICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgVGhlIHN0cnVjdHVyZSBhbmQgZm9ybSBv ZiBleHRlbnNpb25zIGFyZSBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQgc28NCiAgIHRoYXQgaW1w bGVtZW50YXRpb25zIGNhbiBiZSBjcmVhdGVkIHRoYXQgYXJlIGZvcndhcmQgY29tcGF0aWJsZSB3 aXRoDQogICBhcHBsaWNhdGlvbnMgdGhhdCBtYXkgYmUgY3JlYXRlZCB1c2luZyBzaW5nbGUtbGV0 dGVyIHN1YnRhZ3MgaW4gdGhlDQogICBmdXR1cmUuICBJbiBhZGRpdGlvbiwgZGVmaW5pbmcgYSBt ZWNoYW5pc20gZm9yIG1haW50YWluaW5nIHNpbmdsZS0NCiAgIGxldHRlciBzdWJ0YWdzIHdpbGwg bGVuZCB0byB0aGUgc3RhYmlsaXR5IG9mIHRoaXMgZG9jdW1lbnQgYnkNCiAgIHJlZHVjaW5nIHRo ZSBsaWtlbHkgbmVlZCBmb3IgZnV0dXJlIHJldmlzaW9ucyBvciB1cGRhdGVzLg0KDQogICBBbGxv Y2F0aW9uIG9mIGEgc2luZ2xlLWxldHRlciBzdWJ0YWcgc2hhbGwgdGFrZSB0aGUgZm9ybSBvZiBh biBSRkMNCiAgIGRlZmluaW5nIHRoZSBuYW1lLCBwdXJwb3NlLCBwcm9jZXNzZXMsIGFuZCBwcm9j ZWR1cmVzIGZvciBtYWludGFpbmluZw0KICAgdGhlIHN1YnRhZ3MuICBUaGUgbWFpbnRhaW5pbmcg b3IgcmVnaXN0ZXJpbmcgYXV0aG9yaXR5LCBpbmNsdWRpbmcNCiAgIG5hbWUsIGNvbnRhY3QgZW1h aWwsIGRpc2N1c3Npb24gbGlzdCBlbWFpbCwgYW5kIFVSTCBsb2NhdGlvbiBvZiB0aGUNCiAgIHJl Z2lzdHJ5IG11c3QgYmUgaW5kaWNhdGVkIGNsZWFybHkgaW4gdGhlIFJGQy4gIFRoZSBSRkMgTVVT VCBzcGVjaWZ5DQogICBvciBpbmNsdWRlIGVhY2ggb2YgdGhlIGZvbGxvd2luZzoNCg0KICAgbyAg VGhlIHNwZWNpZmljYXRpb24gTVVTVCByZWZlcmVuY2UgdGhlIHNwZWNpZmljIHZlcnNpb24gb3Ig cmV2aXNpb24NCiAgICAgIG9mIHRoaXMgZG9jdW1lbnQgdGhhdCBnb3Zlcm5zIGl0cyBjcmVhdGlv biBhbmQgTVVTVCByZWZlcmVuY2UgdGhpcw0KICAgICAgc2VjdGlvbiBvZiB0aGlzIGRvY3VtZW50 Lg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBhbmQgYWxsIHN1YnRhZ3MgZGVmaW5lZCBieSB0 aGUgc3BlY2lmaWNhdGlvbg0KICAgICAgTVVTVCBmb2xsb3cgdGhlIEFCTkYgYW5kIG90aGVyIHJ1 bGVzIGZvciB0aGUgZm9ybWF0aW9uIG9mIHRhZ3MgYW5kDQogICAgICBzdWJ0YWdzIGFzIGRlZmlu ZWQgaW4gdGhpcyBkb2N1bWVudC4gIEluIHBhcnRpY3VsYXIgaXQgTVVTVA0KICAgICAgc3BlY2lm eSB0aGF0IGNhc2UgaXMgbm90IHNpZ25pZmljYW50IGFuZCB0aGF0IHN1YnRhZ3MgTVVTVCBOT1QN CiAgICAgIGV4Y2VlZCBlaWdodCBjaGFyYWN0ZXJzIGluIGxlbmd0aC4NCg0KICAgbyAgVGhlIHNw ZWNpZmljYXRpb24gTVVTVCBzcGVjaWZ5IGEgY2Fub25pY2FsIHJlcHJlc2VudGF0aW9uLg0KDQog ICBvICBUaGUgc3BlY2lmaWNhdGlvbiBvZiB2YWxpZCBzdWJ0YWdzIE1VU1QgYmUgYXZhaWxhYmxl IG92ZXIgdGhlDQogICAgICBJbnRlcm5ldCBhbmQgYXQgbm8gY29zdC4NCg0KICAgbyAgVGhlIHNw ZWNpZmljYXRpb24gTVVTVCBiZSBpbiB0aGUgcHVibGljIGRvbWFpbiBvciBhdmFpbGFibGUgdmlh IGENCiAgICAgIHJveWFsdHktZnJlZSBsaWNlbnNlIGFjY2VwdGFibGUgdG8gdGhlIElFVEYgYW5k IHNwZWNpZmllZCBpbiB0aGUNCiAgICAgIFJGQy4NCg0KICAgbyAgVGhlIHNwZWNpZmljYXRpb24g TVVTVCBiZSB2ZXJzaW9uZWQgYW5kIGVhY2ggdmVyc2lvbiBvZiB0aGUNCiAgICAgIHNwZWNpZmlj YXRpb24gTVVTVCBiZSBudW1iZXJlZCwgZGF0ZWQsIGFuZCBzdGFibGUuDQoNCiAgIG8gIFRoZSBz cGVjaWZpY2F0aW9uIE1VU1QgYmUgc3RhYmxlLiAgVGhhdCBpcywgZXh0ZW5zaW9uIHN1YnRhZ3Ms DQogICAgICBvbmNlIGRlZmluZWQgYnkgYSBzcGVjaWZpY2F0aW9uLCBNVVNUIE5PVCBiZSByZXRy YWN0ZWQgb3IgY2hhbmdlDQogICAgICBpbiBtZWFuaW5nIGluIGFueSBzdWJzdGFudGlhbCB3YXku DQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgaW5jbHVkZSBpbiBhIHNlcGFyYXRlIHNl Y3Rpb24gdGhlDQogICAgICByZWdpc3RyYXRpb24gZm9ybSByZXByb2R1Y2VkIGluIHRoaXMgc2Vj dGlvbiAoYmVsb3cpIHRvIGJlIHVzZWQgaW4NCiAgICAgIHJlZ2lzdGVyaW5nIHRoZSBleHRlbnNp b24gdXBvbiBwdWJsaWNhdGlvbiBhcyBhbiBSRkMuDQoNCiAgIG8gIElBTkEgTVVTVCBiZSBpbmZv cm1lZCBvZiBjaGFuZ2VzIHRvIHRoZSBjb250YWN0IGluZm9ybWF0aW9uIGFuZA0KICAgICAgVVJM IGZvciB0aGUgc3BlY2lmaWNhdGlvbi4NCg0KICAgSUFOQSB3aWxsIG1haW50YWluIGEgcmVnaXN0 cnkgb2YgYWxsb2NhdGVkIHNpbmdsZS1sZXR0ZXIgKHNpbmdsZXRvbikNCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQ YWdlIDMxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgc3VidGFncy4gIFRoaXMgcmVnaXN0 cnkgd2lsbCB1c2UgdGhlIHJlY29yZC1qYXIgZm9ybWF0IGRlc2NyaWJlZCBieQ0KICAgdGhlIEFC TkYgaW4gU2VjdGlvbiAzLjEuICBVcG9uIHB1YmxpY2F0aW9uIG9mIGFuIGV4dGVuc2lvbiBhcyBh biBSRkMsDQogICB0aGUgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IGRlZmluZWQgaW4gdGhlIFJGQyBt dXN0IGZvcndhcmQgdGhpcw0KICAgcmVnaXN0cmF0aW9uIGZvcm0gdG8gaWVzZ0BpZXRmLm9yZywg d2hvIHdpbGwgZm9yd2FyZCB0aGUgcmVxdWVzdCB0bw0KICAgaWFuYUBpYW5hLm9yZy4gIFRoZSBt YWludGFpbmluZyBhdXRob3JpdHkgb2YgdGhlIGV4dGVuc2lvbiBNVVNUDQogICBtYWludGFpbiB0 aGUgYWNjdXJhY3kgb2YgdGhlIHJlY29yZCBieSBzZW5kaW5nIGFuIHVwZGF0ZWQgZnVsbCBjb3B5 DQogICBvZiB0aGUgcmVjb3JkIHRvIGlhbmFAaWFuYS5vcmcgd2l0aCB0aGUgc3ViamVjdCBsaW5l ICJMQU5HVUFHRSBUQUcNCiAgIEVYVEVOU0lPTiBVUERBVEUiIHdoZW5ldmVyIGNvbnRlbnQgY2hh bmdlcy4gIE9ubHkgdGhlICdDb21tZW50cycsDQogICAnQ29udGFjdF9FbWFpbCcsICdNYWlsaW5n X0xpc3QnLCBhbmQgJ1VSTCcgZmllbGRzIG1heSBiZSBtb2RpZmllZCBpbg0KICAgdGhlc2UgdXBk YXRlcy4NCg0KICAgRmFpbHVyZSB0byBtYWludGFpbiB0aGlzIHJlY29yZCwgdGhlIGNvcnJlc3Bv bmRpbmcgcmVnaXN0cnksIG9yIG1lZXQNCiAgIG90aGVyIGNvbmRpdGlvbnMgaW1wb3NlZCBieSB0 aGlzIHNlY3Rpb24gb2YgdGhpcyBkb2N1bWVudCBtYXkgYmUNCiAgIGFwcGVhbGVkIHRvIHRoZSBJ RVNHIFtSRkMgMjAyOF0gWzldIHVuZGVyIHRoZSBzYW1lIHJ1bGVzIGFzIG90aGVyDQogICBJRVRG IGRlY2lzaW9ucyAoc2VlIFs4XSkgYW5kIG1heSByZXN1bHQgaW4gdGhlIGF1dGhvcml0eSB0byBt YWludGFpbg0KICAgdGhlIGV4dGVuc2lvbiBiZWluZyB3aXRoZHJhd24gb3IgcmVhc3NpZ25lZCBi eSB0aGUgSUVTRy4NCiAgICUlDQogICBJZGVudGlmaWVyOg0KICAgRGVzY3JpcHRpb246DQogICBD b21tZW50czoNCiAgIEFkZGVkOg0KICAgUkZDOg0KICAgQXV0aG9yaXR5Og0KICAgQ29udGFjdF9F bWFpbDoNCiAgIE1haWxpbmdfTGlzdDoNCiAgIFVSTDoNCiAgICUlDQoNCiAgICBGaWd1cmUgNjog Rm9ybWF0IG9mIFJlY29yZHMgaW4gdGhlIExhbmd1YWdlIFRhZyBFeHRlbnNpb25zIFJlZ2lzdHJ5 DQoNCiAgICdJZGVudGlmaWVyJyBjb250YWlucyB0aGUgc2luZ2xlIGxldHRlciBzdWJ0YWcgKHNp bmdsZXRvbikgYXNzaWduZWQNCiAgIHRvIHRoZSBleHRlbnNpb24uICBUaGUgSW50ZXJuZXQtRHJh ZnQgc3VibWl0dGVkIHRvIGRlZmluZSB0aGUNCiAgIGV4dGVuc2lvbiBzaG91bGQgc3BlY2lmaWMg d2hpY2ggbGV0dGVyIHRvIHVzZSwgYWx0aG91Z2ggdGhlIElFU0cgbWF5DQogICBjaGFuZ2UgdGhl IGFzc2lnbm1lbnQgd2hlbiBhcHByb3ZpbmcgdGhlIFJGQy4NCg0KICAgJ0Rlc2NyaXB0aW9uJyBj b250YWlucyB0aGUgbmFtZSBhbmQgZGVzY3JpcHRpb24gb2YgdGhlIGV4dGVuc2lvbi4NCg0KICAg J0NvbW1lbnRzJyBpcyBhbiBvcHRpb25hbCBmaWVsZCBhbmQgbWF5IGNvbnRhaW4gYSBicm9hZGVy IGRlc2NyaXB0aW9uDQogICBvZiB0aGUgZXh0ZW5zaW9uLg0KDQogICAnQWRkZWQnIGNvbnRhaW5z IHRoZSBkYXRlIHRoZSBSRkMgd2FzIHB1Ymxpc2hlZCBpbiB0aGUgImZ1bGwtZGF0ZSINCiAgIGZv cm1hdCBzcGVjaWZpZWQgaW4gUkZDIDMzMzkgWzE0XS4gIEZvciBleGFtcGxlOiAyMDA0LTA2LTI4 DQogICByZXByZXNlbnRzIEp1bmUgMjgsIDIwMDQsIGluIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIu DQoNCiAgICdSRkMnIGNvbnRhaW5zIHRoZSBSRkMgbnVtYmVyIGFzc2lnbmVkIHRvIHRoZSBleHRl bnNpb24uDQoNCiAgICdBdXRob3JpdHknIGNvbnRhaW5zIHRoZSBuYW1lIG9mIHRoZSBtYWludGFp bmluZyBhdXRob3JpdHkgZm9yIHRoZQ0KICAgZXh0ZW5zaW9uLg0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2Ug MzJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAg ICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICAnQ29udGFjdF9FbWFpbCcgY29udGFpbnMg dGhlIGVtYWlsIGFkZHJlc3MgdXNlZCB0byBjb250YWN0IHRoZQ0KICAgbWFpbnRhaW5pbmcgYXV0 aG9yaXR5Lg0KDQogICAnTWFpbGluZ19MaXN0JyBjb250YWlucyB0aGUgVVJMIG9yIHN1YnNjcmlw dGlvbiBlbWFpbCBhZGRyZXNzIG9mIHRoZQ0KICAgbWFpbGluZyBsaXN0IHVzZWQgYnkgdGhlIG1h aW50YWluaW5nIGF1dGhvcml0eS4NCg0KICAgJ1VSTCcgY29udGFpbnMgdGhlIFVSTCBvZiB0aGUg cmVnaXN0cnkgZm9yIHRoaXMgZXh0ZW5zaW9uLg0KDQogICBUaGUgZGV0ZXJtaW5hdGlvbiBvZiB3 aGV0aGVyIGFuIEludGVybmV0LURyYWZ0IG1lZXRzIHRoZSBhYm92ZQ0KICAgY29uZGl0aW9ucyBh bmQgdGhlIGRlY2lzaW9uIHRvIGdyYW50IG9yIHdpdGhob2xkIHN1Y2ggYXV0aG9yaXR5IHJlc3Rz DQogICBzb2xlbHkgd2l0aCB0aGUgSUVTRywgYW5kIGlzIHN1YmplY3QgdG8gdGhlIG5vcm1hbCBy ZXZpZXcgYW5kIGFwcGVhbHMNCiAgIHByb2Nlc3MgYXNzb2NpYXRlZCB3aXRoIHRoZSBSRkMgcHJv Y2Vzcy4NCg0KICAgRXh0ZW5zaW9uIGF1dGhvcnMgYXJlIHN0cm9uZ2x5IGNhdXRpb25lZCB0aGF0 IG1hbnkgKGluY2x1ZGluZyBtb3N0DQogICB3ZWxsLWZvcm1lZCkgcHJvY2Vzc29ycyB3aWxsIGJl IHVuYXdhcmUgb2YgYW55IHNwZWNpYWwgcmVsYXRpb25zaGlwcw0KICAgb3IgbWVhbmluZyBpbmhl cmVudCBpbiB0aGUgb3JkZXIgb2YgZXh0ZW5zaW9uIHN1YnRhZ3MuICBFeHRlbnNpb24NCiAgIGF1 dGhvcnMgU0hPVUxEIGF2b2lkIHN1YnRhZyByZWxhdGlvbnNoaXBzIG9yIGNhbm9uaWNhbGl6YXRp b24NCiAgIG1lY2hhbmlzbXMgdGhhdCBpbnRlcmZlcmUgd2l0aCBtYXRjaGluZyBvciB3aXRoIGxl bmd0aCByZXN0cmljdGlvbnMNCiAgIHRoYXQgbWF5IGV4aXN0IGluIGNvbW1vbiBwcm90b2NvbHMg d2hlcmUgdGhlIGV4dGVuc2lvbiBpcyB1c2VkLiAgSW4NCiAgIHBhcnRpY3VsYXIsIGFwcGxpY2F0 aW9ucyBtYXkgdHJ1bmNhdGUgdGhlIHN1YnRhZ3MgaW4gZG9pbmcgbWF0Y2hpbmcNCiAgIG9yIGlu IGZpdHRpbmcgaW50byBsaW1pdGVkIGxlbmd0aHMsIHNvIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQg dGhlDQogICBtb3N0IHNpZ25pZmljYW50IGluZm9ybWF0aW9uIGJlIGluIHRoZSBtb3N0IHNpZ25p ZmljYW50IChsZWZ0LW1vc3QpDQogICBzdWJ0YWdzLCBhbmQgdGhhdCB0aGUgc3BlY2lmaWNhdGlv biBncmFjZWZ1bGx5IGhhbmRsZSB0cnVuY2F0ZWQNCiAgIHN1YnRhZ3MuDQoNCiAgIFdoZW4gYSBs YW5ndWFnZSB0YWcgaXMgdG8gYmUgdXNlZCBpbiBhIHNwZWNpZmljLCBrbm93biwgcHJvdG9jb2ws IGl0DQogICBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoYXQgdGhlIGxhbmd1YWdlIHRhZyBub3QgY29u dGFpbiBleHRlbnNpb25zIG5vdA0KICAgc3VwcG9ydGVkIGJ5IHRoYXQgcHJvdG9jb2wuICBJbiBh ZGRpdGlvbiwgaXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQNCiAgIHNvbWUgcHJvdG9jb2xzIG1heSBp bXBvc2UgdXBwZXIgbGltaXRzIG9uIHRoZSBsZW5ndGggb2YgdGhlIHN0cmluZ3MNCiAgIHVzZWQg dG8gc3RvcmUgb3IgdHJhbnNwb3J0IHRoZSBsYW5ndWFnZSB0YWcuDQoNCjMuNyAgQ29udmVyc2lv biBvZiB0aGUgUkZDIDMwNjYgTGFuZ3VhZ2UgVGFnIFJlZ2lzdHJ5DQoNCiAgIFVwb24gcHVibGlj YXRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBhIEJDUCwgdGhlIGV4aXN0aW5nIElBTkENCiAgIGxh bmd1YWdlIHRhZyByZWdpc3RyeSBtdXN0IGJlIGNvbnZlcnRlZCBpbnRvIHRoZSBuZXcgc3VidGFn IHJlZ2lzdHJ5Lg0KICAgVGhpcyBzZWN0aW9uIGRlZmluZXMgdGhlIHByb2Nlc3MgZm9yIHBlcmZv cm1pbmcgdGhpcyBjb252ZXJzaW9uLg0KDQogICBUaGUgaW1wYWN0IG9uIHRoZSBJQU5BIG1haW50 YWluZXJzIG9mIHRoZSByZWdpc3RyeSBvZiB0aGlzIGNvbnZlcnNpb24NCiAgIHdpbGwgYmUgYSBz bWFsbCBpbmNyZWFzZSBpbiB0aGUgZnJlcXVlbmN5IG9mIG5ldyBlbnRyaWVzLiAgVGhlDQogICBp bml0aWFsIHNldCBvZiByZWNvcmRzIHJlcHJlc2VudHMgbm8gaW1wYWN0IG9uIElBTkEsIHNpbmNl IHRoZSB3b3JrDQogICB0byBjcmVhdGUgaXQgd2lsbCBiZSBwZXJmb3JtZWQgZXh0ZXJuYWxseSAo YXMgZGVmaW5lZCBpbiB0aGlzDQogICBzZWN0aW9uKS4gIEZ1dHVyZSB3b3JrIHdpbGwgYmUgbGlt aXRlZCB0byBpbnNlcnRpbmcgb3IgcmVwbGFjaW5nDQogICB3aG9sZSByZWNvcmRzIHByZWZvcm1h dHRlZCBmb3IgSUFOQSBieSB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyLg0KDQogICBXaGVu IHRoaXMgZG9jdW1lbnQgaXMgcHVibGlzaGVkLCBhbiBlbWFpbCB3aWxsIGJlIHNlbnQgYnkgdGhl DQogICBjaGFpcihzKSBvZiB0aGUgTFRSVSB3b3JraW5nIGdyb3VwIHRvIHRoZSBMVFJVIGFuZCBp ZXRmLWxhbmd1YWdlcw0KICAgbWFpbCBsaXN0cyBhZHZpc2luZyBvZiB0aGUgaW1wZW5kaW5nIGNv bnZlcnNpb24gb2YgdGhlIHJlZ2lzdHJ5LiAgSW4NCiAgIHRoYXQgbm90aWNlLCB0aGUgY2hhaXIo cykgd2lsbCBwcm92aWRlIGEgVVJMIHdob3NlIHJlZmVycmVkIGNvbnRlbnQNCg0KDQoNClBoaWxs aXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAg IFtQYWdlIDMzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lz dHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgaXMgdGhlIHByb3Bvc2VkIElB TkEgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IGZvbGxvd2luZyBjb252ZXJzaW9uLg0KICAgVGhl cmUgd2lsbCBiZSBhIExhc3QgQ2FsbCBwZXJpb2Qgb2Ygbm90IGxlc3MgdGhhbiBmb3VyIHdlZWtz IGZvcg0KICAgY29tbWVudHMgYW5kIGNvcnJlY3Rpb25zIHRvIGJlIGRpc2N1c3NlZCBvbiB0aGUN CiAgIGlldGYtbGFuZ3VhZ2VzQGlhbmEub3JnIG1haWwgbGlzdC4gIENoYW5nZXMgYXMgYSByZXN1 bHQgb2YgY29tbWVudHMNCiAgIHdpbGwgbm90IHJlc3RhcnQgdGhlIExhc3QgQ2FsbCBwZXJpb2Qu ICBBdCB0aGUgZW5kIG9mIHRoZSBwZXJpb2QsIHRoZQ0KICAgY2hhaXIocykgd2lsbCBmb3J3YXJk IHRoZSBVUkwgdG8gSUFOQSwgd2hpY2ggd2lsbCBwb3N0IHRoZSBuZXcNCiAgIHJlZ2lzdHJ5IG9u LWxpbmUuDQoNCiAgIFRhZ3MgdGhhdCBhcmUgY3VycmVudGx5IGRlcHJlY2F0ZWQgd2lsbCBiZSBt YWludGFpbmVkIGFzDQogICBncmFuZGZhdGhlcmVkIGVudHJpZXMuICBUaGUgcmVjb3JkIGZvciB0 aGUgZ3JhbmRmYXRoZXJlZCBlbnRyeSB3aWxsDQogICBjb250YWluIGEgJ0RlcHJlY2F0ZWQnIGZp ZWxkIHdpdGggdGhlIG1vc3QgYXBwcm9wcmlhdGUgZGF0ZSB0aGF0IGNhbg0KICAgYmUgZGV0ZXJt aW5lZCBmb3Igd2hlbiB0aGUgcmVjb3JkIHdhcyBkZXByZWNhdGVkLiAgVGhlICdDb21tZW50cycN CiAgIGZpZWxkIHdpbGwgY29udGFpbiB0aGUgcmVhc29uIGZvciB0aGUgZGVwcmVjYXRpb24uICBU aGUgJ0Nhbm9uaWNhbCcNCiAgIGZpZWxkIHdpbGwgY29udGFpbiB0aGUgdGFnIHRoYXQgcmVwbGFj ZXMgdGhlIHZhbHVlLiAgRm9yIGV4YW1wbGUsIHRoZQ0KICAgdGFnICJhcnQtbG9qYmFuIiBpcyBk ZXByZWNhdGVkIGFuZCB3aWxsIGJlIHBsYWNlZCBpbiB0aGUNCiAgIGdyYW5kZmF0aGVyZWQgc2Vj dGlvbi4gIEl0J3MgJ0RlcHJlY2F0ZWQnIGZpZWxkIHdpbGwgY29udGFpbiB0aGUNCiAgIGRlcHJl Y2F0aW9uIGRhdGUgYW5kICdDYW5vbmljYWwnIGZpZWxkIHRoZSB2YWx1ZSAiamJvIi4NCg0KICAg VGFncyB0aGF0IGFyZSBub3QgZGVwcmVjYXRlZCB0aGF0IGNvbnNpc3QgZW50aXJlbHkgb2Ygc3Vi dGFncyB0aGF0DQogICBhcmUgdmFsaWQgdW5kZXIgdGhpcyBkb2N1bWVudCBhbmQgd2hpY2ggaGF2 ZSB0aGUgY29ycmVjdCBmb3JtIGFuZA0KICAgZm9ybWF0IGZvciB0YWdzIGRlZmluZWQgYnkgdGhp cyBkb2N1bWVudCBhcmUgc3VwZXJzZWRlZCBieSB0aGlzDQogICBkb2N1bWVudC4gIFN1Y2ggdGFn cyBhcmUgcGxhY2VkIGluIHJlY29yZHMgb2YgdHlwZSAncmVkdW5kYW50JyBpbiB0aGUNCiAgIHJl Z2lzdHJ5LiAgRm9yIGV4YW1wbGUsICJ6aC1IYW50IiBpcyBub3cgZGVmaW5lZCBieSB0aGlzIGRv Y3VtZW50Lg0KDQogICBUYWdzIHRoYXQgYXJlIG5vdCBkZXByZWNhdGVkIGFuZCB3aGljaCBjb250 YWluIHN1YnRhZ3Mgd2hpY2ggYXJlDQogICBjb25zaXN0ZW50IHdpdGggcmVnaXN0cmF0aW9uIHVu ZGVyIHRoZSBndWlkZWxpbmVzIGluIHRoaXMgZG9jdW1lbnQNCiAgIHdpbGwgaGF2ZSBhIG5ldyBz dWJ0YWcgcmVnaXN0cmF0aW9uIGNyZWF0ZWQgZm9yIGVhY2ggZWxpZ2libGUgc3VidGFnLg0KICAg SWYgYWxsIG9mIHRoZSBzdWJ0YWdzIGluIHRoZSBvcmlnaW5hbCB0YWcgYXJlIGZ1bGx5IGRlZmlu ZWQgYnkgdGhlDQogICByZXN1bHRpbmcgcmVnaXN0cmF0aW9ucyBvciBieSB0aGlzIGRvY3VtZW50 LCB0aGVuIHRoZSBvcmlnaW5hbCB0YWcgaXMNCiAgIHN1cGVyc2VkZWQgYnkgdGhpcyBkb2N1bWVu dC4gIFN1Y2ggdGFncyBhcmUgcGxhY2VkIGluIHRoZSAncmVkdW5kYW50Jw0KICAgc2VjdGlvbiBv ZiB0aGUgcmVnaXN0cnkuICBGb3IgZXhhbXBsZSwgImVuLWJvb250IiB3aWxsIHJlc3VsdCBpbiBh DQogICBuZXcgc3VidGFnICdib29udCcgYW5kIHRoZSBSRkMgMzA2NiByZWdpc3RlcmVkIHRhZyAi ZW4tYm9vbnQiIHBsYWNlZA0KICAgaW4gdGhlIHJlZHVuZGFudCBzZWN0aW9uIG9mIHRoZSByZWdp c3RyeS4NCg0KICAgVGFncyB0aGF0IGNvbnRhaW4gb25lIG9yIG1vcmUgc3VidGFncyB0aGF0IGRv IG5vdCBtYXRjaCB0aGUgdmFsaWQNCiAgIHJlZ2lzdHJhdGlvbiBwYXR0ZXJuIGFuZCB3aGljaCBh cmUgbm90IG90aGVyd2lzZSBkZWZpbmVkIGJ5IHRoaXMNCiAgIGRvY3VtZW50IHdpbGwgaGF2ZSBy ZWNvcmRzIG9mIHR5cGUgICdncmFuZGZhdGhlcmVkJyBjcmVhdGVkIGluIHRoZQ0KICAgcmVnaXN0 cnkuDQoNCiAgIFRoZXJlIHdpbGwgYmUgYSByZWFzb25hYmxlIHBlcmlvZCBpbiB3aGljaCB0aGUg Y29tbXVuaXR5IG1heSBjb21tZW50DQogICBvbiB0aGUgcHJvcG9zZWQgbGlzdCBlbnRyaWVzLCB3 aGljaCBTSEFMTCBiZSBubyBsZXNzIHRoYW4gZm91ciB3ZWVrcw0KICAgaW4gbGVuZ3RoLiAgQXQg dGhlIGNvbXBsZXRpb24gb2YgdGhpcyBwZXJpb2QsIHRoZSBjaGFpcihzKSB3aWxsDQogICBub3Rp ZnkgaWFuYUBpYW5hLm9yZyBhbmQgdGhlIGx0cnUgYW5kIGlldGYtbGFuZ3VhZ2VzIG1haWwgbGlz dHMgdGhhdA0KICAgdGhlIHRhc2sgaXMgY29tcGxldGUgYW5kIGZvcndhcmQgdGhlIG5lY2Vzc2Fy eSBtYXRlcmlhbHMgdG8gSUFOQSBmb3INCiAgIHB1YmxpY2F0aW9uLg0KDQogICBSZWdpc3RyYXRp b25zIHRoYXQgYXJlIGluIHByb2Nlc3MgdW5kZXIgdGhlIHJ1bGVzIGRlZmluZWQgaW4gUkZDIDMw NjYNCiAgIE1BWSBiZSBjb21wbGV0ZWQgdW5kZXIgdGhlIGZvcm1lciBydWxlcywgYXQgdGhlIGRp c2NyZXRpb24gb2YgdGhlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9j dG9iZXIgMjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAzNF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAw NQ0KDQoNCiAgIGxhbmd1YWdlIHRhZyByZXZpZXdlci4gIEFueSBuZXcgcmVnaXN0cmF0aW9ucyBz dWJtaXR0ZWQgYWZ0ZXIgdGhlDQogICByZXF1ZXN0IGZvciBjb252ZXJzaW9uIG9mIHRoZSByZWdp c3RyeSBNVVNUIGJlIHJlamVjdGVkLg0KDQogICBBbGwgZXhpc3RpbmcgUkZDIDMwNjYgbGFuZ3Vh Z2UgdGFnIHJlZ2lzdHJhdGlvbnMgd2lsbCBiZSBtYWludGFpbmVkDQogICBpbiBwZXJwZXR1aXR5 Lg0KDQogICBVc2VycyBvZiB0YWdzIHRoYXQgYXJlIGdyYW5kZmF0aGVyZWQgc2hvdWxkIGNvbnNp ZGVyIHJlZ2lzdGVyaW5nDQogICBhcHByb3ByaWF0ZSBzdWJ0YWdzIGluIHRoZSBJQU5BIHN1YnRh ZyByZWdpc3RyeSAoYnV0IGFyZSBub3QgcmVxdWlyZWQNCiAgIHRvKS4NCg0KICAgV2hlcmUgdHdv IHN1YnRhZ3MgaGF2ZSB0aGUgc2FtZSBtZWFuaW5nLCB0aGUgcHJpb3JpdHkgb2Ygd2hpY2ggdG8N CiAgIG1ha2UgY2Fub25pY2FsIFNIQUxMIGJlIHRoZSBmb2xsb3dpbmc6DQoNCiAgIG8gIEFzIG9m IHRoZSBkYXRlIG9mIGFjY2VwdGFuY2Ugb2YgdGhpcyBkb2N1bWVudCBhcyBhIEJDUCwgaWYgYSBj b2RlDQogICAgICBleGlzdHMgaW4gdGhlIGFzc29jaWF0ZWQgSVNPIHN0YW5kYXJkIGFuZCBpdCBp cyBub3QgZGVwcmVjYXRlZCBvcg0KICAgICAgd2l0aGRyYXduIGFzIG9mIHRoYXQgZGF0ZSwgdGhl biBpdCBoYXMgcHJpb3JpdHkuDQoNCiAgIG8gIE90aGVyd2lzZSwgdGhlIGVhcmxpZXItcmVnaXN0 ZXJlZCB0YWcgaW4gdGhlIGFzc29jaWF0ZWQgSVNPDQogICAgICBzdGFuZGFyZCBoYXMgcHJpb3Jp dHkuDQoNCiAgIFVOIG51bWVyaWMgY29kZXMgYXNzaWduZWQgdG8gJ21hY3JvLWdlb2dyYXBoaWNh bCAoY29udGluZW50YWwpJyBvcg0KICAgc3ViLXJlZ2lvbnMgbm90IGFzc29jaWF0ZWQgd2l0aCBh biBhc3NpZ25lZCBJU08gMzE2NiBhbHBoYS0yIGNvZGUgYXJlDQogICBkZWZpbmVkIGluIHRoZSBJ QU5BIHJlZ2lzdHJ5IGFuZCBhcmUgdmFsaWQgZm9yIHVzZSBpbiBsYW5ndWFnZSB0YWdzLg0KICAg VGhlc2UgY29kZXMgTVVTVCBiZSBhZGRlZCB0byB0aGUgaW5pdGlhbCB2ZXJzaW9uIG9mIHRoZSBy ZWdpc3RyeS4NCiAgIFRoZSBVTiBudW1lcmljIGNvZGVzIGZvciAnZWNvbm9taWMgZ3JvdXBpbmdz JyBvciAnb3RoZXIgZ3JvdXBpbmdzJywNCiAgIGFuZCB0aGUgYWxwaGFudW1lcmljIGNvZGVzIGlu IEFwcGVuZGl4IFggb2YgdGhlIFVOIGRvY3VtZW50IE1VU1QgTk9UDQogICBiZSBhZGRlZCB0byB0 aGUgcmVnaXN0cnkuDQoNCiAgIFdoZW4gY3JlYXRpbmcgcmVjb3JkcyBmb3IgSVNPIDYzOSwgSVNP IDE1OTI0LCBJU08zMTY2LCBhbmQgVU4gTS40OQ0KICAgY29kZXMsIHRoZSBmb2xsb3dpbmcgY3Jp dGVyaWEgU0hBTEwgYmUgYXBwbGllZCB0byB0aGUgaW5jbHVzaW9uLA0KICAgY2Fub25pY2FsIG1h cHBpbmcsIGFuZCBkZXByZWNhdGlvbiBvZiBjb2RlczoNCg0KICAgRm9yIGVhY2ggc3RhbmRhcmQs IHRoZSBkYXRlIG9mIHRoZSBzdGFuZGFyZCByZWZlcmVuY2VkIGluIFJGQyAxNzY2IGlzDQogICBz ZWxlY3RlZCBhcyB0aGUgc3RhcnRpbmcgZGF0ZS4gIENvZGVzIHRoYXQgd2VyZSB2YWxpZCBvbiB0 aGF0IGRhdGUgaW4NCiAgIHRoZSBzZWxlY3RlZCBzdGFuZGFyZCBhcmUgYWRkZWQgdG8gdGhlIHJl Z2lzdHJ5LiAgQ29kZXMgdGhhdCB3ZXJlDQogICBwcmV2aW91c2x5IGFzc2lnbmVkIGJ5IHdlcmUg dmFjYXRlZCBvciB3aXRoZHJhd24gYmVmb3JlIHRoYXQgZGF0ZSBhcmUNCiAgIG5vdCBhZGRlZCB0 byB0aGUgcmVnaXN0cnkuICBGb3IgZWFjaCBzdWNjZXNzaXZlIGNoYW5nZSB0byB0aGUNCiAgIHN0 YW5kYXJkLCBhbnkgYWRkaXRpb25hbCBhc3NpZ25tZW50cyBhcmUgYWRkZWQgdG8gdGhlIHJlZ2lz dHJ5Lg0KICAgVmFsdWVzIHRoYXQgYXJlIHdpdGhkcmF3biBhcmUgbWFya2VkIGFzIGRlcHJlY2F0 ZWQsIGJ1dCBub3QgcmVtb3ZlZC4NCiAgIENoYW5nZXMgaW4gbWVhbmluZyBvciBhc3NpZ25tZW50 IG9mIGEgc3VidGFnIGFyZSBwZXJtaXR0ZWQgZHVyaW5nDQogICB0aGlzIHByb2Nlc3MgKGNmLiAn Q1MnKS4gIFRoaXMgY29udGludWVzIHVwIHRvIHRoZSBkYXRlIHRoYXQgdGhpcw0KICAgZG9jdW1l bnQgd2FzIGFkb3B0ZWQuICBUaGUgcmVzdWx0aW5nIHNldCBvZiByZWNvcmRzIGlzIGFkZGVkIHRv IHRoZQ0KICAgcmVnaXN0cnkuICBGdXR1cmUgY2hhbmdlcyBvciBhZGRpdGlvbnMgdG8gdGhpcyBw b3J0aW9uIG9mIHRoZQ0KICAgcmVnaXN0cnkgYXJlIGdvdmVybmVkIGJ5IHRoZSBwcm92aXNpb25z IG9mIHRoaXMgZG9jdW1lbnQuDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAg IEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDM1XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAg ICBBcHJpbCAyMDA1DQoNCg0KNC4gIEZvcm1hdGlvbiBhbmQgUHJvY2Vzc2luZyBvZiBMYW5ndWFn ZSBUYWdzDQoNCiAgIFRoaXMgc2VjdGlvbiBhZGRyZXNzZXMgaG93IHRvIHVzZSB0aGUgcmVnaXN0 cnkgd2l0aCB0aGUgbGFuZ3VhZ2UgdGFnDQogICBmb3JtYXQgdG8gY2hvb3NlLCBmb3JtIGFuZCBw cm9jZXNzIGxhbmd1YWdlIHRhZ3MuDQoNCjQuMSAgQ2hvaWNlIG9mIExhbmd1YWdlIFRhZw0KDQog ICBPbmUgbWF5IG9jY2FzaW9uYWxseSBiZSBmYWNlZCB3aXRoIHNldmVyYWwgcG9zc2libGUgdGFn cyBmb3IgdGhlIHNhbWUNCiAgIGJvZHkgb2YgdGV4dC4NCg0KICAgSW50ZXJvcGVyYWJpbGl0eSBp cyBiZXN0IHNlcnZlZCB3aGVuIGFsbCB1c2VycyB1c2UgdGhlIHNhbWUgbGFuZ3VhZ2UNCiAgIHRh ZyBpbiBvcmRlciB0byByZXByZXNlbnQgdGhlIHNhbWUgbGFuZ3VhZ2UuICBJZiBhbiBhcHBsaWNh dGlvbiBoYXMNCiAgIHJlcXVpcmVtZW50cyB0aGF0IG1ha2UgdGhlIHJ1bGVzIGhlcmUgaW5hcHBs aWNhYmxlLCB0aGVuIHRoYXQNCiAgIGFwcGxpY2F0aW9uIHJpc2tzIGRhbWFnaW5nIGludGVyb3Bl cmFiaWxpdHkuICBJdCBpcyBzdHJvbmdseQ0KICAgUkVDT01NRU5ERUQgdGhhdCB1c2VycyBub3Qg ZGVmaW5lIHRoZWlyIG93biBydWxlcyBmb3IgbGFuZ3VhZ2UgdGFnDQogICBjaG9pY2UuDQoNCiAg IE9mIHBhcnRpY3VsYXIgbm90ZSwgbWFueSBhcHBsaWNhdGlvbnMgY2FuIGJlbmVmaXQgZnJvbSB0 aGUgdXNlIG9mDQogICBzY3JpcHQgc3VidGFncyBpbiBsYW5ndWFnZSB0YWdzLCBhcyBsb25nIGFz IHRoZSB1c2UgaXMgY29uc2lzdGVudCBmb3INCiAgIGEgZ2l2ZW4gY29udGV4dC4gIFNjcmlwdCBz dWJ0YWdzIHdlcmUgbm90IGZvcm1hbGx5IGRlZmluZWQgaW4gUkZDDQogICAzMDY2IGFuZCB0aGVp ciB1c2UgbWF5IGFmZmVjdCBtYXRjaGluZyBhbmQgc3VidGFnIGlkZW50aWZpY2F0aW9uIGJ5DQog ICBpbXBsZW1lbnRhdGlvbnMgb2YgUkZDIDMwNjYsIGFzIHRoZXNlIHN1YnRhZ3MgYXBwZWFyIGJl dHdlZW4gdGhlDQogICBwcmltYXJ5IGxhbmd1YWdlIGFuZCByZWdpb24gc3VidGFncy4gIEZvciBl eGFtcGxlLCBpZiBhIHVzZXIgcmVxdWVzdHMNCiAgIGNvbnRlbnQgaW4gYW4gaW1wbGVtZW50YXRp b24gb2YgU2VjdGlvbiAyLjUgb2YgUkZDIDMwNjYgWzIzXSB1c2luZw0KICAgdGhlIGxhbmd1YWdl IHJhbmdlICJlbi1VUyIsIGNvbnRlbnQgbGFiZWxlZCAiZW4tTGF0bi1VUyIgd2lsbCBub3QNCiAg IG1hdGNoIHRoZSByZXF1ZXN0LiAgVGhlcmVmb3JlIGl0IGlzIGltcG9ydGFudCB0byBrbm93IHdo ZW4gc2NyaXB0DQogICBzdWJ0YWdzIHdpbGwgY3VzdG9tYXJpbHkgYmUgdXNlZCBhbmQgd2hlbiB0 aGV5IHNob3VsZCBub3QgYmUgdXNlZC4NCg0KICAgRXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFncyAo dHlwZSAnZXh0bGFuZycgaW4gdGhlIHJlZ2lzdHJ5LCBzZWUNCiAgIFNlY3Rpb24gMy4xKSBhbHNv IGFwcGVhciBiZXR3ZWVuIHRoZSBwcmltYXJ5IGxhbmd1YWdlIGFuZCByZWdpb24NCiAgIHN1YnRh Z3MgYW5kIGFyZSByZXNlcnZlZCBmb3IgZnV0dXJlIHN0YW5kYXJkaXphdGlvbi4gIEFwcGxpY2F0 aW9ucw0KICAgbWF5IGJlbmVmaXQgZnJvbSB0aGVpciBqdWRpY2lvdXMgdXNlIGluIGZvcm1pbmcg bGFuZ3VhZ2UgdGFncyBpbiB0aGUNCiAgIGZ1dHVyZSBhbmQgc2ltaWxhciByZWNvbW1lbmRhdGlv bnMgYXJlIGV4cGVjdGVkIHRvIGFwcGx5IHRvIHRoZWlyIHVzZQ0KICAgYXMgYXBwbHkgdG8gc2Ny aXB0IHN1YnRhZ3MuDQoNCiAgIFN0YW5kYXJkcywgcHJvdG9jb2xzIGFuZCBhcHBsaWNhdGlvbnMg dGhhdCByZWZlcmVuY2UgdGhpcyBkb2N1bWVudA0KICAgbm9ybWF0aXZlbHkgYnV0IGFwcGx5IGRp ZmZlcmVudCBydWxlcyB0byB0aGUgb25lcyBnaXZlbiBpbiB0aGlzDQogICBzZWN0aW9uIE1VU1Qg c3BlY2lmeSBob3cgdGhlIHByb2NlZHVyZSB2YXJpZXMgZnJvbSB0aGUgb25lIGdpdmVuDQogICBo ZXJlLg0KDQogICBUaGUgY2hvaWNlIG9mIHN1YnRhZ3MgdXNlZCB0byBmb3JtIGEgbGFuZ3VhZ2Ug dGFnIHNob3VsZCBiZSBndWlkZWQgYnkNCiAgIHRoZSBmb2xsb3dpbmcgcnVsZXM6DQoNCiAgIDEu ICBVc2UgYXMgcHJlY2lzZSBhIHRhZyBhcyBwb3NzaWJsZSwgYnV0IG5vIG1vcmUgc3BlY2lmaWMg dGhhbiBpcw0KICAgICAgIGp1c3RpZmllZC4gIEF2b2lkIHVzaW5nIHN1YnRhZ3MgdGhhdCBhcmUg bm90IGltcG9ydGFudCBmb3INCiAgICAgICBkaXN0aW5ndWlzaGluZyBjb250ZW50IGluIGFuIGFw cGxpY2F0aW9uLg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0 b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDM2XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1 DQoNCg0KICAgICAgICogIEZvciBleGFtcGxlLCAnZGUnIG1pZ2h0IHN1ZmZpY2UgZm9yIHRhZ2dp bmcgYW4gZW1haWwgd3JpdHRlbg0KICAgICAgICAgIGluIEdlcm1hbiwgd2hpbGUgImRlLUNILTE5 OTYiIGlzIHByb2JhYmx5IHVubmVjZXNzYXJpbHkNCiAgICAgICAgICBwcmVjaXNlIGZvciBzdWNo IGEgdGFzay4NCg0KICAgMi4gIFRoZSBzY3JpcHQgc3VidGFnIFNIT1VMRCBOT1QgYmUgdXNlZCB0 byBmb3JtIGxhbmd1YWdlIHRhZ3MgdW5sZXNzDQogICAgICAgdGhlIHNjcmlwdCBhZGRzIHNvbWUg ZGlzdGluZ3Vpc2hpbmcgaW5mb3JtYXRpb24gdG8gdGhlIHRhZy4gIFRoZQ0KICAgICAgIGZpZWxk ICdTdXBwcmVzcy1TY3JpcHQnIGluIHRoZSBwcmltYXJ5IGxhbmd1YWdlIHJlY29yZCBpbiB0aGUN CiAgICAgICByZWdpc3RyeSBpbmRpY2F0ZXMgd2hpY2ggc2NyaXB0IHN1YnRhZ3MgZG8gbm90IGFk ZCBkaXN0aW5ndWlzaGluZw0KICAgICAgIGluZm9ybWF0aW9uIGZvciBtb3N0IGFwcGxpY2F0aW9u cy4NCg0KICAgICAgICogIEZvciBleGFtcGxlLCB0aGUgc3VidGFnICdMYXRuJyBzaG91bGQgbm90 IGJlIHVzZWQgd2l0aCB0aGUNCiAgICAgICAgICBwcmltYXJ5IGxhbmd1YWdlICdlbicgYmVjYXVz ZSBuZWFybHkgYWxsIEVuZ2xpc2ggZG9jdW1lbnRzIGFyZQ0KICAgICAgICAgIHdyaXR0ZW4gaW4g dGhlIExhdGluIHNjcmlwdCBhbmQgaXQgYWRkcyBubyBkaXN0aW5ndWlzaGluZw0KICAgICAgICAg IGluZm9ybWF0aW9uLiAgSG93ZXZlciwgaWYgYSBkb2N1bWVudCB3ZXJlIHdyaXR0ZW4gaW4gRW5n bGlzaA0KICAgICAgICAgIG1peGluZyBMYXRpbiBzY3JpcHQgd2l0aCBhbm90aGVyIHNjcmlwdCBz dWNoIGFzIEJyYWlsbGUNCiAgICAgICAgICAoJ0JyYWknKSwgdGhlbiBpdCBtYXkgYmUgYXBwcm9w cmlhdGUgdG8gY2hvb3NlIHRvIGluZGljYXRlDQogICAgICAgICAgYm90aCBzY3JpcHRzIHRvIGFp ZCBpbiBjb250ZW50IHNlbGVjdGlvbiwgc3VjaCBhcyB0aGUNCiAgICAgICAgICBhcHBsaWNhdGlv biBvZiBhIHN0eWxlc2hlZXQuDQoNCiAgIDMuICBJZiBhIHN1YnRhZyBoYXMgYSAnQ2Fub25pY2Fs JyBmaWVsZCBpbiBpdHMgcmVnaXN0cnkgZW50cnksIHRoZQ0KICAgICAgIGNhbm9uaWNhbCBzdWJ0 YWcgU0hPVUxEIGJlIHVzZWQgdG8gZm9ybSB0aGUgbGFuZ3VhZ2UgdGFnIGluDQogICAgICAgcHJl ZmVyZW5jZSB0byBhbnkgb2YgaXRzIGFsaWFzZXMuDQoNCiAgICAgICAqICBGb3IgZXhhbXBsZSwg dXNlICdoZScgZm9yIEhlYnJldyBpbiBwcmVmZXJlbmNlIHRvICdpdycuDQoNCiAgIDQuICBUaGUg J3VuZCcgKFVuZGV0ZXJtaW5lZCkgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgU0hPVUxEIE5PVCBi ZQ0KICAgICAgIHVzZWQgdG8gbGFiZWwgY29udGVudCwgZXZlbiBpZiB0aGUgbGFuZ3VhZ2UgaXMg dW5rbm93bi4gIE9taXR0aW5nDQogICAgICAgdGhlIGxhbmd1YWdlIHRhZyBhbHRvZ2V0aGVyIGlz IHByZWZlcnJlZCB0byB1c2luZyBhIHRhZyB3aXRoIGENCiAgICAgICBwcmltYXJ5IGxhbmd1YWdl IHN1YnRhZyBvZiAndW5kJy4gIFRoZSAndW5kJyBzdWJ0YWcgbWF5IGJlIHVzZWZ1bA0KICAgICAg IGZvciBwcm90b2NvbHMgdGhhdCByZXF1aXJlIGEgbGFuZ3VhZ2UgdGFnIHRvIGJlIHByb3ZpZGVk LiAgVGhlDQogICAgICAgJ3VuZCcgc3VidGFnIG1heSBhbHNvIGJlIHVzZWZ1bCB3aGVuIG1hdGNo aW5nIGxhbmd1YWdlIHRhZ3MgaW4NCiAgICAgICBjZXJ0YWluIHNpdHVhdGlvbnMuDQoNCiAgIDUu ICBUaGUgJ211bCcgKE11bHRpcGxlKSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBTSE9VTEQgTk9U IGJlIHVzZWQNCiAgICAgICB3aGVuZXZlciB0aGUgcHJvdG9jb2wgYWxsb3dzIHRoZSBzZXBhcmF0 ZSB0YWdzIGZvciBtdWx0aXBsZQ0KICAgICAgIGxhbmd1YWdlcywgYXMgaXMgdGhlIGNhc2UgZm9y IHRoZSBDb250ZW50LUxhbmd1YWdlIGhlYWRlciBpbg0KICAgICAgIEhUVFAuICBUaGUgJ211bCcg c3VidGFnIGNvbnZleXMgbGl0dGxlIHVzZWZ1bCBpbmZvcm1hdGlvbjoNCiAgICAgICBjb250ZW50 IGluIG11bHRpcGxlIGxhbmd1YWdlcyBzaG91bGQgaW5kaXZpZHVhbGx5IHRhZyB0aGUNCiAgICAg ICBsYW5ndWFnZXMgd2hlcmUgdGhleSBhcHBlYXIgb3Igb3RoZXJ3aXNlIGluZGljYXRlIHRoZSBh Y3R1YWwNCiAgICAgICBsYW5ndWFnZSBpbiBwcmVmZXJlbmNlIHRvIHRoZSAnbXVsJyBzdWJ0YWcu DQoNCiAgIDYuICBUaGUgc2FtZSB2YXJpYW50IHN1YnRhZyBTSE9VTEQgTk9UIGJlIHVzZWQgbW9y ZSB0aGFuIG9uY2Ugd2l0aGluDQogICAgICAgYSBsYW5ndWFnZSB0YWcuDQoNCiAgICAgICAqICBG b3IgZXhhbXBsZSwgZG8gbm90IHVzZSAiZW4tR0Itc2NvdXNlLXNjb3VzZSIuDQoNCiAgIFRvIGVu c3VyZSBjb25zaXN0ZW50IGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIHRoaXMgZG9jdW1lbnQgY29u dGFpbnMNCiAgIHNldmVyYWwgcHJvdmlzaW9ucyB0byBhY2NvdW50IGZvciBwb3RlbnRpYWwgaW5z dGFiaWxpdHkgaW4gdGhlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9j dG9iZXIgMjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAzN10NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAw NQ0KDQoNCiAgIHN0YW5kYXJkcyB1c2VkIHRvIGRlZmluZSB0aGUgc3VidGFncyB0aGF0IG1ha2Ug dXAgbGFuZ3VhZ2UgdGFncy4NCiAgIFRoZXNlIHByb3Zpc2lvbnMgbWVhbiB0aGF0IG5vIGxhbmd1 YWdlIHRhZyBjcmVhdGVkIHVuZGVyIHRoZSBydWxlcyBpbg0KICAgdGhpcyBkb2N1bWVudCB3aWxs IGJlY29tZSBvYnNvbGV0ZS4gIEluIGFkZGl0aW9uLCB0YWdzIHRoYXQgYXJlIGluDQogICBjYW5v bmljYWwgZm9ybSB3aWxsIGFsd2F5cyBiZSBpbiBjYW5vbmljYWwgZm9ybS4NCg0KNC4yICBNZWFu aW5nIG9mIHRoZSBMYW5ndWFnZSBUYWcNCg0KICAgVGhlIGxhbmd1YWdlIHRhZyBhbHdheXMgZGVm aW5lcyBhIGxhbmd1YWdlIGFzIHNwb2tlbiAob3Igd3JpdHRlbiwNCiAgIHNpZ25lZCBvciBvdGhl cndpc2Ugc2lnbmFsZWQpIGJ5IGh1bWFuIGJlaW5ncyBmb3IgY29tbXVuaWNhdGlvbiBvZg0KICAg aW5mb3JtYXRpb24gdG8gb3RoZXIgaHVtYW4gYmVpbmdzLiAgQ29tcHV0ZXIgbGFuZ3VhZ2VzIHN1 Y2ggYXMNCiAgIHByb2dyYW1taW5nIGxhbmd1YWdlcyBhcmUgZXhwbGljaXRseSBleGNsdWRlZC4N Cg0KICAgSWYgYSBsYW5ndWFnZSB0YWcgQiBjb250YWlucyBsYW5ndWFnZSB0YWcgQSBhcyBhIHBy ZWZpeCwgdGhlbiBCIGlzDQogICB0eXBpY2FsbHkgIm5hcnJvd2VyIiBvciAibW9yZSBzcGVjaWZp YyIgdGhhbiBBLiBGb3IgZXhhbXBsZSwgInpoLQ0KICAgSGFudC1UVyIgaXMgbW9yZSBzcGVjaWZp YyB0aGFuICJ6aC1IYW50Ii4NCg0KICAgVGhpcyByZWxhdGlvbnNoaXAgaXMgbm90IGd1YXJhbnRl ZWQgaW4gYWxsIGNhc2VzOiBzcGVjaWZpY2FsbHksDQogICBsYW5ndWFnZXMgdGhhdCBiZWdpbiB3 aXRoIHRoZSBzYW1lIHNlcXVlbmNlIG9mIHN1YnRhZ3MgYXJlIE5PVA0KICAgZ3VhcmFudGVlZCB0 byBiZSBtdXR1YWxseSBpbnRlbGxpZ2libGUsIGFsdGhvdWdoIHRoZXkgbWF5IGJlLiAgRm9yDQog ICBleGFtcGxlLCB0aGUgdGFnICJheiIgc2hhcmVzIGEgcHJlZml4IHdpdGggYm90aCAiYXotTGF0 biINCiAgIChBemVyYmFpamFuaSB3cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBzY3JpcHQpIGFuZCAi YXotQ3lybCINCiAgIChBemVyYmFpamFuaSB3cml0dGVuIHVzaW5nIHRoZSBDeXJpbGxpYyBzY3Jp cHQpLiAgQSBwZXJzb24gZmx1ZW50IGluDQogICBvbmUgc2NyaXB0IG1heSBub3QgYmUgYWJsZSB0 byByZWFkIHRoZSBvdGhlciwgZXZlbiB0aG91Z2ggdGhlIHRleHQNCiAgIG1pZ2h0IGJlIGlkZW50 aWNhbC4gIENvbnRlbnQgdGFnZ2VkIGFzICJheiIgbW9zdCBwcm9iYWJseSBpcyB3cml0dGVuDQog ICBpbiBqdXN0IG9uZSBzY3JpcHQgYW5kIHRodXMgbWlnaHQgbm90IGJlIGludGVsbGlnaWJsZSB0 byBhIHJlYWRlcg0KICAgZmFtaWxpYXIgd2l0aCB0aGUgb3RoZXIgc2NyaXB0Lg0KDQogICBUaGUg cmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHRhZyBhbmQgdGhlIGluZm9ybWF0aW9uIGl0IHJlbGF0 ZXMgdG8gaXMNCiAgIGRlZmluZWQgYnkgdGhlIHN0YW5kYXJkIGRlc2NyaWJpbmcgdGhlIGNvbnRl eHQgaW4gd2hpY2ggaXQgYXBwZWFycy4NCiAgIEFjY29yZGluZ2x5LCB0aGlzIHNlY3Rpb24gY2Fu IG9ubHkgZ2l2ZSBwb3NzaWJsZSBleGFtcGxlcyBvZiBpdHMNCiAgIHVzYWdlLg0KDQogICBvICBG b3IgYSBzaW5nbGUgaW5mb3JtYXRpb24gb2JqZWN0LCB0aGUgYXNzb2NpYXRlZCBsYW5ndWFnZSB0 YWdzDQogICAgICBtaWdodCBiZSBpbnRlcnByZXRlZCBhcyB0aGUgc2V0IG9mIGxhbmd1YWdlcyB0 aGF0IGlzIHJlcXVpcmVkIGZvcg0KICAgICAgYSBjb21wbGV0ZSBjb21wcmVoZW5zaW9uIG9mIHRo ZSBjb21wbGV0ZSBvYmplY3QuICBFeGFtcGxlOiBQbGFpbg0KICAgICAgdGV4dCBkb2N1bWVudHMu DQoNCiAgIG8gIEZvciBhbiBhZ2dyZWdhdGlvbiBvZiBpbmZvcm1hdGlvbiBvYmplY3RzLCB0aGUg YXNzb2NpYXRlZCBsYW5ndWFnZQ0KICAgICAgdGFncyBjb3VsZCBiZSB0YWtlbiBhcyB0aGUgc2V0 IG9mIGxhbmd1YWdlcyB1c2VkIGluc2lkZSBjb21wb25lbnRzDQogICAgICBvZiB0aGF0IGFnZ3Jl Z2F0aW9uLiAgRXhhbXBsZXM6IERvY3VtZW50IHN0b3JlcyBhbmQgbGlicmFyaWVzLg0KDQogICBv ICBGb3IgaW5mb3JtYXRpb24gb2JqZWN0cyB3aG9zZSBwdXJwb3NlIGlzIHRvIHByb3ZpZGUgYWx0 ZXJuYXRpdmVzLA0KICAgICAgdGhlIGFzc29jaWF0ZWQgbGFuZ3VhZ2UgdGFncyBjb3VsZCBiZSBy ZWdhcmRlZCBhcyBhIGhpbnQgdGhhdCB0aGUNCiAgICAgIGNvbnRlbnQgaXMgcHJvdmlkZWQgaW4g c2V2ZXJhbCBsYW5ndWFnZXMsIGFuZCB0aGF0IG9uZSBoYXMgdG8NCiAgICAgIGluc3BlY3QgZWFj aCBvZiB0aGUgYWx0ZXJuYXRpdmVzIGluIG9yZGVyIHRvIGZpbmQgaXRzIGxhbmd1YWdlIG9yDQog ICAgICBsYW5ndWFnZXMuICBJbiB0aGlzIGNhc2UsIHRoZSBwcmVzZW5jZSBvZiBtdWx0aXBsZSB0 YWdzIG1pZ2h0IG5vdA0KICAgICAgbWVhbiB0aGF0IG9uZSBuZWVkcyB0byBiZSBtdWx0aS1saW5n dWFsIHRvIGdldCBjb21wbGV0ZQ0KICAgICAgdW5kZXJzdGFuZGluZyBvZiB0aGUgZG9jdW1lbnQu ICBFeGFtcGxlOiBNSU1FIG11bHRpcGFydC8NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAg IEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDM4XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAg ICBBcHJpbCAyMDA1DQoNCg0KICAgICAgYWx0ZXJuYXRpdmUuDQoNCiAgIG8gIEluIG1hcmt1cCBs YW5ndWFnZXMsIHN1Y2ggYXMgSFRNTCBhbmQgWE1MLCBsYW5ndWFnZSBpbmZvcm1hdGlvbg0KICAg ICAgY2FuIGJlIGFkZGVkIHRvIGVhY2ggcGFydCBvZiB0aGUgZG9jdW1lbnQgaWRlbnRpZmllZCBi eSB0aGUgbWFya3VwDQogICAgICBzdHJ1Y3R1cmUgKGluY2x1ZGluZyB0aGUgd2hvbGUgZG9jdW1l bnQgaXRzZWxmKS4gIEZvciBleGFtcGxlLCBvbmUNCiAgICAgIGNvdWxkIHdyaXRlIDxzcGFuIGxh bmc9ImZyIj5DJ2VzdCBsYSB2aWUuPC9zcGFuPiBpbnNpZGUgYQ0KICAgICAgTm9yd2VnaWFuIGRv Y3VtZW50OyB0aGUgTm9yd2VnaWFuLXNwZWFraW5nIHVzZXIgY291bGQgdGhlbiBhY2Nlc3MNCiAg ICAgIGEgRnJlbmNoLU5vcndlZ2lhbiBkaWN0aW9uYXJ5IHRvIGZpbmQgb3V0IHdoYXQgdGhlIG1h cmtlZCBzZWN0aW9uDQogICAgICBtZWFudC4gIElmIHRoZSB1c2VyIHdlcmUgbGlzdGVuaW5nIHRv IHRoYXQgZG9jdW1lbnQgdGhyb3VnaCBhDQogICAgICBzcGVlY2ggc3ludGhlc2lzIGludGVyZmFj ZSwgdGhpcyBmb3JtYXRpb24gY291bGQgYmUgdXNlZCB0byBzaWduYWwNCiAgICAgIHRoZSBzeW50 aGVzaXplciB0byBhcHByb3ByaWF0ZWx5IGFwcGx5IEZyZW5jaCB0ZXh0LXRvLXNwZWVjaA0KICAg ICAgcHJvbnVuY2lhdGlvbiBydWxlcyB0byB0aGF0IHNwYW4gb2YgdGV4dCwgaW5zdGVhZCBvZiBh cHBseWluZyB0aGUNCiAgICAgIGluYXBwcm9wcmlhdGUgTm9yd2VnaWFuIHJ1bGVzLg0KDQoNCjQu MyAgQ2Fub25pY2FsaXphdGlvbiBvZiBMYW5ndWFnZSBUYWdzDQoNCiAgIFNpbmNlIGEgcGFydGlj dWxhciBsYW5ndWFnZSB0YWcgbWF5IGJlIHVzZWQgaW4gbWFueSBwcm9jZXNzZXMsDQogICBsYW5n dWFnZSB0YWdzIFNIT1VMRCBhbHdheXMgYmUgY3JlYXRlZCBvciBnZW5lcmF0ZWQgaW4gYSBjYW5v bmljYWwNCiAgIGZvcm0uDQoNCiAgIEEgbGFuZ3VhZ2UgdGFnIGlzIGluIGNhbm9uaWNhbCBmb3Jt IHdoZW46DQoNCiAgIDEuICBUaGUgdGFnIGlzIHdlbGwtZm9ybWVkIGFjY29yZGluZyB0aGUgcnVs ZXMgaW4gU2VjdGlvbiAyLjEgYW5kDQogICAgICAgU2VjdGlvbiAyLjIuDQoNCiAgIDIuICBOb25l IG9mIHRoZSBzdWJ0YWdzIGluIHRoZSBsYW5ndWFnZSB0YWcgaGFzIGEgY2Fub25pY2FsX3ZhbHVl DQogICAgICAgbWFwcGluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSAoc2VlIFNlY3Rpb24gMy4xKS4g IFN1YnRhZ3Mgd2l0aCBhDQogICAgICAgY2Fub25pY2FsX3ZhbHVlIG1hcHBpbmcgTVVTVCBiZSBy ZXBsYWNlZCB3aXRoIHRoZWlyIG1hcHBpbmcgaW4NCiAgICAgICBvcmRlciB0byBjYW5vbmljYWxp emUgdGhlIHRhZy4NCg0KICAgMy4gIElmIG1vcmUgdGhhbiBvbmUgZXh0ZW5zaW9uIHN1YnRhZyBz ZXF1ZW5jZSBleGlzdHMsIHRoZSBleHRlbnNpb24NCiAgICAgICBzZXF1ZW5jZXMgYXJlIG9yZGVy ZWQgaW50byBjYXNlLWluc2Vuc2l0aXZlIEFTQ0lJIG9yZGVyIGJ5DQogICAgICAgc2luZ2xldG9u IHN1YnRhZy4NCg0KICAgRXhhbXBsZTogVGhlIGxhbmd1YWdlIHRhZyAiZW4tQS1hYWEtQi1jY2Mt YmJiLXgteHl6IiBpcyBpbiBjYW5vbmljYWwNCiAgIGZvcm0sIHdoaWxlICJlbi1CLWNjYy1iYmIt QS1hYWEtWC14eXoiIGlzIHdlbGwtZm9ybWVkIGJ1dCBub3QgaW4NCiAgIGNhbm9uaWNhbCBmb3Jt Lg0KDQogICBFeGFtcGxlOiBUaGUgbGFuZ3VhZ2UgdGFnICJlbi1OSCIgKEVuZ2xpc2ggYXMgdXNl ZCBpbiB0aGUgTmV3DQogICBIZWJyaWRlcykgaXMgbm90IGNhbm9uaWNhbCBiZWNhdXNlIHRoZSAn TkgnIHN1YnRhZyBoYXMgYSBjYW5vbmljYWwNCiAgIG1hcHBpbmcgdG8gJ1ZVJyAoVmFudWF0dSku DQoNCiAgIE5vdGU6IENhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFncyBkb2VzIG5vdCBp bXBseSBhbnl0aGluZyBhYm91dA0KICAgdGhlIHVzZSBvZiB1cHBlciBvciBsb3dlcmNhc2UgbGV0 dGVyIGluIHN1YnRhZ3MgYXMgZGVzY3JpYmVkIGluDQogICBTZWN0aW9uIDIuMS4gIEFsbCBjb21w YXJpc29ucyBNVVNUIGJlIHBlcmZvcm1lZCBpbiBhIGNhc2UtaW5zZW5zaXRpdmUNCiAgIG1hbm5l ci4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAy MDA1ICAgICAgICAgICAgICAgW1BhZ2UgMzldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICBO b3RlOiBpZiB0aGUgZmllbGQgJ0RlcHJlY2F0ZWQnIGFwcGVhcnMgaW4gYSByZWdpc3RyeSByZWNv cmQgd2l0aG91dA0KICAgYW4gYWNjb21wYW55aW5nICdDYW5vbmljYWwnIGZpZWxkLCB0aGVuIHRo YXQgdGFnIG9yIHN1YnRhZyBpcw0KICAgZGVwcmVjYXRlZCB3aXRob3V0IGEgcmVwbGFjZW1lbnQu ICBWYWxpZGF0aW5nIHByb2Nlc3NvcnMgU0hPVUxEIE5PVA0KICAgZ2VuZXJhdGUgdGFncyB0aGF0 IGluY2x1ZGUgdGhlc2UgdmFsdWVzLCBhbHRob3VnaCB0aGUgdmFsdWVzIGFyZQ0KICAgY2Fub25p Y2FsIHdoZW4gdGhleSBhcHBlYXIgaW4gYSBsYW5ndWFnZSB0YWcuDQoNCiAgIEFuIGV4dGVuc2lv biBNVVNUIGRlZmluZSBhbnkgcmVsYXRpb25zaGlwcyB0aGF0IG1heSBleGlzdCBiZXR3ZWVuIHRo ZQ0KICAgdmFyaW91cyBzdWJ0YWdzIGluIHRoZSBleHRlbnNpb24gYW5kIHRodXMgTUFZIGRlZmlu ZSBhbiBhbHRlcm5hdGUNCiAgIGNhbm9uaWNhbGl6YXRpb24gc2NoZW1lIGZvciB0aGUgZXh0ZW5z aW9uJ3Mgc3VidGFncy4gIEV4dGVuc2lvbnMgTUFZDQogICBkZWZpbmUgaG93IHRoZSBvcmRlciBv ZiB0aGUgZXh0ZW5zaW9uJ3Mgc3VidGFncyBhcmUgaW50ZXJwcmV0ZWQuICBGb3INCiAgIGV4YW1w bGUsIGFuIGV4dGVuc2lvbiBjb3VsZCBkZWZpbmUgdGhhdCBpdHMgc3VidGFncyBhcmUgaW4gY2Fu b25pY2FsDQogICBvcmRlciB3aGVuIHRoZSBzdWJ0YWdzIGFyZSBwbGFjZWQgaW50byBBU0NJSSBv cmRlcjogdGhhdCBpcywgImVuLWEtDQogICBhYWEtYmJiLWNjYyIgaW5zdGVhZCBvZiAiZW4tYS1j Y2MtYmJiLWFhYSIuICBBbm90aGVyIGV4dGVuc2lvbiBtaWdodA0KICAgZGVmaW5lIHRoYXQgdGhl IG9yZGVyIG9mIHRoZSBzdWJ0YWdzIGluZmx1ZW5jZXMgdGhlaXIgc2VtYW50aWMNCiAgIG1lYW5p bmcgKHNvIHRoYXQgImVuLWItY2NjLWJiYi1hYWEiIGhhcyBhIGRpZmZlcmVudCB2YWx1ZSBmcm9t ICJlbi1iLQ0KICAgYWFhLWJiYi1jY2MiKS4gIEhvd2V2ZXIsIGV4dGVuc2lvbiBzcGVjaWZpY2F0 aW9ucyBTSE9VTEQgYmUgZGVzaWduZWQNCiAgIHNvIHRoYXQgdGhleSBhcmUgdG9sZXJhbnQgb2Yg dGhlIHR5cGljYWwgcHJvY2Vzc2VzIGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjYuDQoNCjQu NCAgQ29uc2lkZXJhdGlvbnMgZm9yIFByaXZhdGUgVXNlIFN1YnRhZ3MNCg0KICAgUHJpdmF0ZS11 c2Ugc3VidGFncyByZXF1aXJlIHByaXZhdGUgYWdyZWVtZW50IGJldHdlZW4gdGhlIHBhcnRpZXMN CiAgIHRoYXQgaW50ZW5kIHRvIHVzZSBvciBleGNoYW5nZSBsYW5ndWFnZSB0YWdzIHRoYXQgdXNl IHRoZW0gYW5kIGdyZWF0DQogICBjYXV0aW9uIHNob3VsZCBiZSB1c2VkIGluIGVtcGxveWluZyB0 aGVtIGluIGNvbnRlbnQgb3IgcHJvdG9jb2xzDQogICBpbnRlbmRlZCBmb3IgZ2VuZXJhbCB1c2Uu ICBQcml2YXRlLXVzZSBzdWJ0YWdzIGFyZSBzaW1wbHkgdXNlbGVzcyBmb3INCiAgIGluZm9ybWF0 aW9uIGV4Y2hhbmdlIHdpdGhvdXQgcHJpb3IgYXJyYW5nZW1lbnQuDQoNCiAgIFRoZSB2YWx1ZSBh bmQgc2VtYW50aWMgbWVhbmluZyBvZiBwcml2YXRlLXVzZSB0YWdzIGFuZCBvZiB0aGUgc3VidGFn cw0KICAgdXNlZCB3aXRoaW4gc3VjaCBhIGxhbmd1YWdlIHRhZyBhcmUgbm90IGRlZmluZWQgYnkg dGhpcyBkb2N1bWVudC4NCg0KICAgVGhlIHVzZSBvZiBzdWJ0YWdzIGRlZmluZWQgaW4gdGhlIElB TkEgcmVnaXN0cnkgYXMgaGF2aW5nIGEgc3BlY2lmaWMNCiAgIHByaXZhdGUgdXNlIG1lYW5pbmcg Y29udmV5IG1vcmUgaW5mb3JtYXRpb24gdGhhdCBhIHB1cmVseSBwcml2YXRlIHVzZQ0KICAgdGFn IHByZWZpeGVkIGJ5IHRoZSBzaW5nbGV0b24gc3VidGFnICd4Jy4gIEZvciBhcHBsaWNhdGlvbnMg dGhpcw0KICAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBtYXkgYmUgdXNlZnVsLg0KDQogICBGb3Ig ZXhhbXBsZSwgdGhlIHJlZ2lvbiBzdWJ0YWdzICdBQScsICdaWicgYW5kIGluIHRoZSByYW5nZXMN CiAgICdRTSctJ1FaJyBhbmQgJ1hBJy0nWFonIChkZXJpdmVkIGZyb20gSVNPIDMxNjYgcHJpdmF0 ZSB1c2UgY29kZXMpIG1heQ0KICAgYmUgdXNlZCB0byBmb3JtIGEgbGFuZ3VhZ2UgdGFnLiAgQSB0 YWcgc3VjaCBhcyAiemgtSGFucy1YUSIgY29udmV5cyBhDQogICBncmVhdCBkZWFsIG9mIHB1Ymxp YywgaW50ZXJjaGFuZ2VhYmxlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBsYW5ndWFnZQ0KICAgbWF0 ZXJpYWwgKHRoYXQgaXQgaXMgQ2hpbmVzZSBpbiB0aGUgc2ltcGxpZmllZCBDaGluZXNlIHNjcmlw dCBhbmQgaXMNCiAgIHN1aXRhYmxlIGZvciBzb21lIGdlb2dyYXBoaWMgcmVnaW9uICdYUScpLiAg V2hpbGUgdGhlIHByZWNpc2UNCiAgIGdlb2dyYXBoaWMgcmVnaW9uIGlzIG5vdCBrbm93biBvdXRz aWRlIG9mIHByaXZhdGUgYWdyZWVtZW50LCB0aGUgdGFnDQogICBjb252ZXlzIGZhciBtb3JlIGlu Zm9ybWF0aW9uIHRoYW4gYW4gb3BhcXVlIHRhZyBzdWNoIGFzICJ4LXNvbWVMYW5nIiwNCiAgIHdo aWNoIGNvbnRhaW5zIG5vIGluZm9ybWF0aW9uIGFib3V0IHRoZSBsYW5ndWFnZSBzdWJ0YWcgb3Ig c2NyaXB0DQogICBzdWJ0YWcgb3V0c2lkZSBvZiB0aGUgcHJpdmF0ZSBhZ3JlZW1lbnQuDQoNCiAg IEhvd2V2ZXIsIGluIHNvbWUgY2FzZXMgY29udGVudCB0YWdnZWQgd2l0aCBwcml2YXRlIHVzZSBz dWJ0YWdzIG1heQ0KICAgaW50ZXJhY3Qgd2l0aCBvdGhlciBzeXN0ZW1zIGluIGEgZGlmZmVyZW50 IGFuZCBwb3NzaWJseSB1bnN1aXRhYmxlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA0MF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg QXByaWwgMjAwNQ0KDQoNCiAgIG1hbm5lciBjb21wYXJlZCB0byB0YWdzIHRoYXQgdXNlIG9wYXF1 ZSwgcHJpdmF0ZWx5IGRlZmluZWQgc3VidGFncywNCiAgIHNvIHRoZSBjaG9pY2Ugb2YgdGhlIGJl c3QgYXBwcm9hY2ggbWF5IGRlcGVuZCBvbiB0aGUgcGFydGljdWxhcg0KICAgZG9tYWluIGluIHF1 ZXN0aW9uLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAyMDA1ICAgICAgICAgICAgICAgW1Bh Z2UgNDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQo1LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0K DQogICBUaGlzIHNlY3Rpb24gZGVhbHMgd2l0aCB0aGUgcHJvY2Vzc2VzIGFuZCByZXF1aXJlbWVu dHMgbmVjZXNzYXJ5IGZvcg0KICAgSUFOQSB0byB1bmRlcnRha2UgdG8gbWFpbnRhaW4gdGhlIHJz dWJ0YWcgYW5kIGV4dGVuc2lvbiByZWdpc3RyaWVzIGFzDQogICBkZWZpbmVkIGJ5IHRoaXMgZG9j dW1lbnQgYW5kIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgcmVxdWlyZW1lbnRzIG9mDQogICBSRkMg MjQzNCBbMTFdLg0KDQogICBUaGUgaW1wYWN0IG9uIHRoZSBJQU5BIG1haW50YWluZXJzIG9mIHRo ZSB0d28gcmVnaXN0cmllcyBkZWZpbmVkIGJ5DQogICB0aGlzIGRvY3VtZW50IHdpbGwgYmUgYSBz bWFsbCBpbmNyZWFzZSBpbiB0aGUgZnJlcXVlbmN5IG9mIG5ldw0KICAgZW50cmllcyBvciB1cGRh dGVzLg0KDQogICBVcG9uIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQsIHRoZSBwcm9jZXNzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDMuNw0KICAgd2lsbCBiZSB1c2VkIHRvIGdlbmVyYXRlIHRoZSBp bml0aWFsIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeS4gIFRoZQ0KICAgaW5pdGlhbCBzZXQgb2Yg cmVjb3JkcyByZXByZXNlbnRzIG5vIGltcGFjdCBvbiBJQU5BLCBzaW5jZSB0aGUgd29yaw0KICAg dG8gY3JlYXRlIGl0IHdpbGwgYmUgcGVyZm9ybWVkIGV4dGVybmFsbHkgKGFzIGRlZmluZWQgaW4g dGhhdA0KICAgc2VjdGlvbikuICBUaGUgbmV3IHJlZ2lzdHJ5IHdpbGwgYmUgbGlzdGVkIHVuZGVy ICJMYW5ndWFnZSBUYWdzIiBhdA0KICAgPGh0dHA6Ly93d3cuaWFuYS5vcmcvbnVtYmVycy5odG1s Pi4gIFRoZSBleGlzdGluZyBkaXJlY3Rvcnkgb2YNCiAgIHJlZ2lzdHJhdGlvbiBmb3JtcyBhbmQg UkZDIDMwNjYgcmVnaXN0cmF0aW9ucyB3aWxsIGJlIHJlbGFiZWxlZCBhcw0KICAgIkxhbmd1YWdl IFRhZ3MgKE9ic29sZXRlKSIgYW5kIG1haW50YWluZWQgKGJ1dCBub3QgYWRkZWQgdG8gb3INCiAg IG1vZGlmaWVkKS4NCg0KICAgRnV0dXJlIHdvcmsgb24gdGhlIExhbmd1YWdlIFN1YnRhZyBSZWdp c3RyeSB3aWxsIGJlIGxpbWl0ZWQgdG8NCiAgIGluc2VydGluZyBvciByZXBsYWNpbmcgd2hvbGUg cmVjb3JkcyBwcmVmb3JtYXR0ZWQgZm9yIElBTkEgYnkgdGhlDQogICBMYW5ndWFnZSBTdWJ0YWcg UmV2aWV3ZXIgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4yIG9mIHRoaXMNCiAgIGRvY3VtZW50 LiAgRWFjaCByZWNvcmQgd2lsbCBiZSBzZW50IHRvIGlhbmFAaWFuYS5vcmcgd2l0aCBhIHN1Ympl Y3QNCiAgIGxpbmUgaW5kaWNhdGluZyB3aGV0aGVyIHRoZSBlbmNsb3NlZCByZWNvcmQgaXMgYW4g aW5zZXJ0aW9uIChvZiBhIG5ldw0KICAgcmVjb3JkKSBvciBhIHJlcGxhY21lbnQgb2YgYW4gZXhp c3RpbmcgcmVjb3JkIHdoaWNoIGhhcyBhIFR5cGUgYW5kDQogICBTdWJ0YWcgKG9yIFRhZykgZmll bGQgdGhhdCBleGFjdGx5IG1hdGNoZXMgdGhlIHJlY29yZCBzZW50LiAgUmVjb3Jkcw0KICAgY2Fu bm90IGJlIGRlbGV0ZWQgZnJvbSB0aGUgcmVnaXN0cnkuDQoNCiAgIFRoZSBMYW5ndWFnZSBUYWcg RXh0ZW5zaW9ucyByZWdpc3RyeSB3aWxsIGFsc28gYmUgZ2VuZXJhdGVkIGFuZCBzZW50DQogICB0 byBJQU5BIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNi4gIFRoaXMgcmVnaXN0cnkgbWF5IGNv bnRhaW4gYXQNCiAgIG1vc3QgMjUgcmVjb3JkcyBhbmQgdGh1cyBjaGFuZ2VzIHRvIHRoaXMgcmVn aXN0cnkgYXJlIGV4cGVjdGVkIHRvIGJlDQogICB2ZXJ5IGluZnJlcXVlbnQuDQoNCiAgIEZ1dHVy ZSB3b3JrIGJ5IElBTkEgb24gdGhlIExhbmd1YWdlIFRhZyBFeHRlbnNpb25zIFJlZ2lzdHJ5IGlz DQogICBsaW1pdGVkIHRvIHR3byBjYXNlcy4gIEZpcnN0LCB0aGUgSUVTRyBtYXkgcmVxdWVzdCB0 aGF0IG5ldyByZWNvcmRzDQogICBiZSBpbnNlcnRlZCBpbnRvIHRoaXMgcmVnaXN0cnkgZnJvbSB0 aW1lIHRvIHRpbWUuICBUaGVzZSByZXF1ZXN0cw0KICAgd2lsbCBpbmNsdWRlIHRoZSByZWNvcmQg dG8gaW5zZXJ0IGluIHRoZSBleGFjdCBmb3JtYXQgZGVzY3JpYmVkIGluDQogICBTZWN0aW9uIDMu Ni4gIEluIGFkZGl0aW9uLCB0aGVyZSBtYXkgYmUgb2NjYXNpb25hbCByZXF1ZXN0cyBmcm9tIHRo ZQ0KICAgbWFpbnRhaW5pbmcgYXV0aG9yaXR5IGZvciBhIHNwZWNpZmljIGV4dGVuc2lvbiB0byB1 cGRhdGUgdGhlIGNvbnRhY3QNCiAgIGluZm9ybWF0aW9uIG9yIFVSTHMgaW4gdGhlIHJlY29yZC4g IFRoZXNlIHJlcXVlc3RzIE1VU1QgaW5jbHVkZSB0aGUNCiAgIGNvbXBsZXRlLCB1cGRhdGVkIHJl Y29yZC4gIElBTkEgaXMgbm90IHJlc3BvbnNpYmxlIGZvciB2YWxpZGF0aW5nIHRoZQ0KICAgaW5m b3JtYXRpb24gcHJvdmlkZWQsIG9ubHkgdGhhdCBpdCBpcyBwcm9wZXJseSBmb3JtYXR0ZWQuICBJ dCBzaG91bGQNCiAgIHJlYXNvbmFibHkgYmUgc2VlbiB0byBjb21lIGZyb20gdGhlIG1haW50YWlu aW5nIGF1dGhvcml0eSBuYW1lZCBpbg0KICAgdGhlIHJlY29yZCBwcmVzZW50IGluIHRoZSByZWdp c3RyeS4NCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIg MjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA0Ml0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoN CjYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGUgb25seSBzZWN1cml0eSBpc3N1 ZSB0aGF0IGhhcyBiZWVuIHJhaXNlZCB3aXRoIGxhbmd1YWdlIHRhZ3Mgc2luY2UNCiAgIHRoZSBw dWJsaWNhdGlvbiBvZiBSRkMgMTc2NiBbMjFdLCB3aGljaCBzdGF0ZWQgdGhhdCAiU2VjdXJpdHkg aXNzdWVzDQogICBhcmUgYmVsaWV2ZWQgdG8gYmUgaXJyZWxldmFudCB0byB0aGlzIG1lbW8iLCBp cyBhIGNvbmNlcm4gd2l0aA0KICAgbGFuZ3VhZ2UgaWRlbnRpZmllcnMgdXNlZCBpbiBjb250ZW50 IG5lZ290aWF0aW9uIC0gdGhhdCB0aGV5IG1heSBiZQ0KICAgdXNlZCB0byBpbmZlciB0aGUgbmF0 aW9uYWxpdHkgb2YgdGhlIHNlbmRlciwgYW5kIHRodXMgaWRlbnRpZnkNCiAgIHBvdGVudGlhbCB0 YXJnZXRzIGZvciBzdXJ2ZWlsbGFuY2UuDQoNCiAgIFRoaXMgaXMgYSBzcGVjaWFsIGNhc2Ugb2Yg dGhlIGdlbmVyYWwgcHJvYmxlbSB0aGF0IGFueXRoaW5nIHNlbnQgaXMNCiAgIHZpc2libGUgdG8g dGhlIHJlY2VpdmluZyBwYXJ0eSBhbmQgcG9zc2libHkgdG8gdGhpcmQgcGFydGllcyBhcyB3ZWxs Lg0KICAgSXQgaXMgdXNlZnVsIHRvIGJlIGF3YXJlIHRoYXQgc3VjaCBjb25jZXJucyBjYW4gZXhp c3QgaW4gc29tZSBjYXNlcy4NCg0KICAgVGhlIGV2YWx1YXRpb24gb2YgdGhlIGV4YWN0IG1hZ25p dHVkZSBvZiB0aGUgdGhyZWF0LCBhbmQgYW55IHBvc3NpYmxlDQogICBjb3VudGVybWVhc3VyZXMs IGlzIGxlZnQgdG8gZWFjaCBhcHBsaWNhdGlvbiBwcm90b2NvbCAoc2VlIEJDUCA3MiwNCiAgIFJG QyAgMzU1MiBbMTVdIGZvciBiZXN0IGN1cnJlbnQgcHJhY3RpY2UgZ3VpZGFuY2Ugb24gc2VjdXJp dHkgdGhyZWF0cw0KICAgYW5kIGRlZmVuc2VzKS4NCg0KICAgQWx0aG91Z2ggdGhlIHNwZWNpZmlj YXRpb24gb2YgdmFsaWQgc3VidGFncyBmb3IgYW4gZXh0ZW5zaW9uIE1VU1QgYmUNCiAgIGF2YWls YWJsZSBvdmVyIHRoZSBJbnRlcm5ldCwgaW1wbGVtZW50YXRpb25zIFNIT1VMRCBOT1QgbWVjaGFu aWNhbGx5DQogICBkZXBlbmQgb24gaXQgYmVpbmcgYWx3YXlzIGFjY2Vzc2libGUsIHRvIHByZXZl bnQgZGVuaWFsLW9mLXNlcnZpY2UNCiAgIGF0dGFja3MuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAg ICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2UgNDNdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAg ICAgIEFwcmlsIDIwMDUNCg0KDQo3LiAgQ2hhcmFjdGVyIFNldCBDb25zaWRlcmF0aW9ucw0KDQog ICBUaGUgc3ludGF4IGluIHRoaXMgZG9jdW1lbnQgcmVxdWlyZXMgdGhhdCBsYW5ndWFnZSB0YWdz IHVzZSBvbmx5IHRoZQ0KICAgY2hhcmFjdGVycyBBLVosIGEteiwgMC05LCBhbmQgSFlQSEVOLU1J TlVTLCB3aGljaCBhcmUgcHJlc2VudCBpbiBtb3N0DQogICBjaGFyYWN0ZXIgc2V0cywgc28gdGhl IGNvbXBvc2l0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mgc2hvdWxkIG5vdCBoYXZlDQogICBhbnkgY2hh cmFjdGVyIHNldCBpc3N1ZXMuDQoNCiAgIFJlbmRlcmluZyBvZiBjaGFyYWN0ZXJzIGJhc2VkIG9u IHRoZSBjb250ZW50IG9mIGEgbGFuZ3VhZ2UgdGFnIGlzIG5vdA0KICAgYWRkcmVzc2VkIGluIHRo aXMgbWVtby4gIEhpc3RvcmljYWxseSwgc29tZSBsYW5ndWFnZXMgaGF2ZSByZWxpZWQgb24NCiAg IHRoZSB1c2Ugb2Ygc3BlY2lmaWMgY2hhcmFjdGVyIHNldHMgb3Igb3RoZXIgaW5mb3JtYXRpb24g aW4gb3JkZXIgdG8NCiAgIGluZmVyIGhvdyBhIHNwZWNpZmljIGNoYXJhY3RlciBzaG91bGQgYmUg cmVuZGVyZWQgKG5vdGFibHkgdGhpcw0KICAgYXBwbGllcyB0byBsYW5ndWFnZSBhbmQgY3VsdHVy ZSBzcGVjaWZpYyB2YXJpYXRpb25zIG9mIEhhbiBpZGVvZ3JhcGhzDQogICBhcyB1c2VkIGluIEph cGFuZXNlLCBDaGluZXNlLCBhbmQgS29yZWFuKS4gIFdoZW4gbGFuZ3VhZ2UgdGFncyBhcmUNCiAg IGFwcGxpZWQgdG8gc3BhbnMgb2YgdGV4dCwgcmVuZGVyaW5nIGVuZ2luZXMgbWF5IHVzZSB0aGF0 IGluZm9ybWF0aW9uDQogICBpbiBkZWNpZGluZyB3aGljaCBmb250IHRvIHVzZSBpbiB0aGUgYWJz ZW5jZSBvZiBvdGhlciBpbmZvcm1hdGlvbiwNCiAgIHBhcnRpY3VsYXJseSB3aGVyZSBsYW5ndWFn ZXMgd2l0aCBkaXN0aW5jdCB3cml0aW5nIHRyYWRpdGlvbnMgdXNlIHRoZQ0KICAgc2FtZSBjaGFy YWN0ZXJzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIE9jdG9i ZXIgMjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA0NF0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgQXByaWwgMjAwNQ0K DQoNCjguICBDaGFuZ2VzIGZyb20gUkZDIDMwNjYNCg0KICAgVGhlIG1haW4gZ29hbHMgZm9yIHRo aXMgcmV2aXNpb24gb2YgbGFuZ3VhZ2UgdGFncyB3ZXJlIHRoZSBmb2xsb3dpbmc6DQoNCiAgICpD b21wYXRpYmlsaXR5LiogQWxsIHZhbGlkIFJGQyAzMDY2IGxhbmd1YWdlIHRhZ3MgIChpbmNsdWRp bmcgdGhvc2UNCiAgIGluIHRoZSBJQU5BIHJlZ2lzdHJ5KSAgcmVtYWluIHZhbGlkIGluIHRoaXMg c3BlY2lmaWNhdGlvbi4gIFRodXMNCiAgIHRoZXJlIGlzIGNvbXBsZXRlIGJhY2t3YXJkIGNvbXBh dGliaWxpdHkgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIHdpdGgNCiAgIGV4aXN0aW5nIGNvbnRlbnQu ICBJbiBhZGRpdGlvbiwgdGhpcyBkb2N1bWVudCBkZWZpbmVzIGxhbmd1YWdlIHRhZ3MNCiAgIGlu IHN1Y2ggYXMgd2F5IGFzIHRvIGVuc3VyZSBmdXR1cmUgY29tcGF0aWJpbGl0eSwgYW5kIHByb2Nl c3NvcnMNCiAgIGJhc2VkIHNvbGVseSBvbiB0aGUgUkZDIDMwNjYgQUJORiAoc3VjaCBhcyB0aG9z ZSBkZXNjcmliZWQgaW4gWE1MDQogICBTY2hlbWEgdmVyc2lvbiAxLjAgWzE5XSkgd2lsbCBiZSBh YmxlIHRvIHByb2Nlc3MgdGFncyBkZXNjcmliZWQgYnkNCiAgIHRoaXMgZG9jdW1lbnQuDQoNCiAg ICpTdGFiaWxpdHkuKiBCZWNhdXNlIG9mIHRoZSBjaGFuZ2VzIGluIHVuZGVybHlpbmcgSVNPIHN0 YW5kYXJkcywgYQ0KICAgdmFsaWQgUkZDIDMwNjYgbGFuZ3VhZ2UgdGFnIG1heSBiZWNvbWUgaW52 YWxpZCAob3IgaGF2ZSBpdHMgbWVhbmluZw0KICAgY2hhbmdlKSBhdCBhIGxhdGVyIGRhdGUuICBX aXRoIHNvIG11Y2ggb2YgdGhlIHdvcmxkJ3MgY29tcHV0aW5nDQogICBpbmZyYXN0cnVjdHVyZSBk ZXBlbmRlbnQgb24gbGFuZ3VhZ2UgdGFncywgdGhpcyBpcyBzaW1wbHkNCiAgIHVuYWNjZXB0YWJs ZTogaXQgaW52YWxpZGF0ZXMgY29udGVudCB0aGF0IG1heSBoYXZlIGFuIGV4dGVuc2l2ZQ0KICAg c2hlbGYtbGlmZS4gIEluIHRoaXMgc3BlY2lmaWNhdGlvbiwgb25jZSBhIGxhbmd1YWdlIHRhZyBp cyB2YWxpZCwgaXQNCiAgIHJlbWFpbnMgdmFsaWQgZm9yZXZlci4gIFByZXZpb3VzbHksIHRoZXJl IHdhcyBubyB3YXkgdG8gZGV0ZXJtaW5lDQogICB3aGVuIHR3byB0YWdzIHdlcmUgZXF1aXZhbGVu dC4gIFRoaXMgc3BlY2lmaWNhdGlvbiBwcm92aWRlcyBhIHN0YWJsZQ0KICAgbWVjaGFuaXNtIGZv ciBkb2luZyBzbywgdGhyb3VnaCB0aGUgdXNlIG9mIGNhbm9uaWNhbCBmb3Jtcy4gIFRoZXNlDQog ICBhcmUgYWxzbyBzdGFibGUsIHNvIHRoYXQgaW1wbGVtZW50YXRpb25zIGNhbiBkZXBlbmQgb24g dGhlIHVzZSBvZg0KICAgY2Fub25pY2FsIGZvcm1zIHRvIGFzc2VzcyBlcXVpdmFsZW5jeS4NCg0K ICAgKlZhbGlkaXR5LiogIFRoZSBzdHJ1Y3R1cmUgb2YgbGFuZ3VhZ2UgdGFncyBkZWZpbmVkIGJ5 IHRoaXMgZG9jdW1lbnQNCiAgIG1ha2VzIGl0IHBvc3NpYmxlIHRvIGRldGVybWluZSBpZiBhIHBh cnRpY3VsYXIgdGFnIGlzIHdlbGwtZm9ybWVkDQogICB3aXRob3V0IHJlZ2FyZCBmb3IgdGhlIGFj dHVhbCBjb250ZW50IG9yICJtZWFuaW5nIiBvZiB0aGUgdGFnIGFzIGENCiAgIHdob2xlLiAgVGhp cyBpcyBpbXBvcnRhbnQgYmVjYXVzZSB0aGUgcmVnaXN0cnkgYW5kIHVuZGVybHlpbmcNCiAgIHN0 YW5kYXJkcyAgY2hhbmdlIG92ZXIgdGltZS4gIEluIGFkZGl0aW9uLCBpdCBtdXN0IGJlIHBvc3Np YmxlIHRvDQogICBkZXRlcm1pbmUgaWYgYSB0YWcgaXMgdmFsaWQgKG9yIG5vdCkgZm9yIGEgZ2l2 ZW4gcG9pbnQgaW4gdGltZSBpbg0KICAgb3JkZXIgIHRvIHByb3ZpZGUgcmVwcm9kdWNpYmxlLCB0 ZXN0YWJsZSByZXN1bHRzLiAgVGhpcyBwcm9jZXNzIG11c3QNCiAgIG5vdCBiZSBlcnJvci1wcm9u ZTsgb3RoZXJ3aXNlIGV2ZW4gaW50ZWxsaWdlbnQgcGVvcGxlIHdpbGwgZ2VuZXJhdGUNCiAgIGlt cGxlbWVudGF0aW9ucyB0aGF0IGdpdmUgZGlmZmVyZW50IHJlc3VsdHMuICBUaGlzIHNwZWNpZmlj YXRpb24NCiAgIHByb3ZpZGVzIGZvciB0aGF0IGJ5IGhhdmluZyBhIHNpbmdsZSBkYXRhIGZpbGUs IHdpdGggc3BlY2lmaWMNCiAgIHZlcnNpb25pbmcgaW5mb3JtYXRpb24sIHNvIHRoYXQgdGhlIHZh bGlkaXR5IG9mIGxhbmd1YWdlIHRhZ3MgYXQgYW55DQogICBwb2ludCBpbiB0aW1lIGNhbiBiZSBw cmVjaXNlbHkgZGV0ZXJtaW5lZCAoaW5zdGVhZCBvZiBpbnRlcnBvbGF0aW5nDQogICB2YWx1ZXMg ZnJvbSBtYW55IHNlcGFyYXRlIHNvdXJjZXMpLg0KDQogICAqRXh0ZW5zaWJpbGl0eS4qIEl0IGlz IGltcG9ydGFudCB0byBiZSBhYmxlIHRvIGRpZmZlcmVudGlhdGUgYmV0d2Vlbg0KICAgd3JpdHRl biBmb3JtcyBvZiBsYW5ndWFnZSAtLSBmb3IgbWFueSBpbXBsZW1lbnRhdGlvbnMgdGhpcyBpcyBt b3JlDQogICBpbXBvcnRhbnQgdGhhbiBkaXN0aW5ndWlzaGluZyBiZXR3ZWVuIHNwb2tlbiB2YXJp YW50cyBvZiBhIGxhbmd1YWdlLg0KICAgTGFuZ3VhZ2VzIGFyZSB3cml0dGVuIGluIGEgd2lkZSB2 YXJpZXR5IG9mIGRpZmZlcmVudCBzY3JpcHRzLCBzbyB0aGlzDQogICBkb2N1bWVudCBwcm92aWRl cyBmb3IgdGhlIGdlbmVyYXRpdmUgdXNlIG9mIElTTyAxNTkyNCBzY3JpcHQgY29kZXMuDQogICBM aWtlIHRoZSBnZW5lcmF0aXZlIHVzZSBvZiBJU08gbGFuZ3VhZ2UgYW5kIGNvdW50cnkgY29kZXMg aW4gUkZDDQogICAzMDY2LCB0aGlzIGFsbG93cyBjb21iaW5hdGlvbnMgdG8gYmUgcHJvZHVjZWQg d2l0aG91dCByZXNvcnRpbmcgdG8NCiAgIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcy4gIFRoZSBh ZGRpdGlvbiBvZiBVTiBjb2RlcyBwcm92aWRlcyBmb3IgdGhlDQogICBnZW5lcmF0aW9uIG9mIGxh bmd1YWdlIHRhZ3Mgd2l0aCByZWdpb25hbCBzY29wZSwgd2hpY2ggaXMgYWxzbw0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAyMDA1ICAgICAgICAgICAg ICAgW1BhZ2UgNDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICByZXF1aXJlZCBmb3IgaW5m b3JtYXRpb24gdGVjaG5vbG9neS4NCg0KICAgVGhlIHJlY2FzdCBvZiB0aGUgcmVnaXN0cnkgZnJv bSBjb250YWluaW5nIHdob2xlIGxhbmd1YWdlIHRhZ3MgdG8NCiAgIHN1YnRhZ3MgaXMgYSBrZXkg cGFydCBvZiB0aGlzLiAgQW4gaW1wb3J0YW50IGZlYXR1cmUgb2YgUkZDIDMwNjYgd2FzDQogICB0 aGF0IGl0IGFsbG93ZWQgZ2VuZXJhdGl2ZSB1c2Ugb2Ygc3VidGFncy4gIFRoaXMgYWxsb3dzIHBl b3BsZSB0bw0KICAgbWVhbmluZ2Z1bGx5IHVzZSBnZW5lcmF0ZWQgdGFncywgd2l0aG91dCB0aGUg ZGVsYXlzIGluIHJlZ2lzdGVyaW5nDQogICB3aG9sZSB0YWdzLCBhbmQgdGhlIGJ1cmRlbiBvbiB0 aGUgcmVnaXN0cnkgb2YgaGF2aW5nIHRvIHN1cHBseSBhbGwgb2YNCiAgIHRoZSBjb21iaW5hdGlv bnMgdGhhdCBwZW9wbGUgbWF5IGZpbmQgdXNlZnVsLg0KDQogICBCZWNhdXNlIG9mIHRoZSB3aWRl c3ByZWFkIHVzZSBvZiBsYW5ndWFnZSB0YWdzLCBpdCBpcyBwb3RlbnRpYWxseQ0KICAgZGlzcnVw dGl2ZSB0byBoYXZlIHBlcmlvZGljIHJldmlzaW9ucyBvZiB0aGUgY29yZSBzcGVjaWZpY2F0aW9u LA0KICAgZGVzcGl0ZSBkZW1vbnN0cmF0ZWQgbmVlZC4gIFRoZSBleHRlbnNpb24gbWVjaGFuaXNt IHByb3ZpZGVzIGZvciBhDQogICB3YXkgZm9yIGluZGVwZW5kZW50IFJGQ3MgdG8gZGVmaW5lIGV4 dGVuc2lvbnMgdG8gbGFuZ3VhZ2UgdGFncy4NCiAgIFRoZXNlIGV4dGVuc2lvbnMgaGF2ZSBhIHZl cnkgY29uc3RyYWluZWQsIHdlbGwtZGVmaW5lZCBzdHJ1Y3R1cmUgdG8NCiAgIHByZXZlbnQgZXh0 ZW5zaW9ucyBmcm9tIGludGVyZmVyaW5nIHdpdGggaW1wbGVtZW50YXRpb25zIG9mIGxhbmd1YWdl DQogICB0YWdzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4gIFRoZSBkb2N1bWVudCBhbHNvIGFu dGljaXBhdGVzDQogICBmZWF0dXJlcyBvZiBJU08gNjM5LTMgd2l0aCB0aGUgYWRkaXRpb24gb2Yg dGhlIGV4dGVuZGVkIGxhbmd1YWdlDQogICBzdWJ0YWdzLCBhcyB3ZWxsIGFzIHRoZSBwb3NzaWJp bGl0eSBvZiBvdGhlciBJU08gNjM5IHBhcnRzIGJlY29taW5nDQogICB1c2VmdWwgZm9yIHRoZSBm b3JtYXRpb24gb2YgbGFuZ3VhZ2UgdGFncyBpbiB0aGUgZnV0dXJlLiAgVGhlIHVzZSBhbmQNCiAg IGRlZmluaXRpb24gb2YgcHJpdmF0ZSB1c2UgdGFncyBoYXMgYWxzbyBiZWVuIG1vZGlmaWVkLCB0 byBhbGxvdw0KICAgcGVvcGxlIHRvIG1vdmUgYXMgbXVjaCBpbmZvcm1hdGlvbiBhcyBwb3NzaWJs ZSBvdXQgb2YgcHJpdmF0ZSB1c2UNCiAgIHRhZ3MsIGFuZCBpbnRvIHRoZSByZWd1bGFyIHN0cnVj dHVyZS4gIFRoZSBnb2FsIGlzIHRvIGRyYW1hdGljYWxseQ0KICAgcmVkdWNlIHRoZSBuZWVkIHRv IHByb2R1Y2UgYSByZXZpc2lvbiBvZiB0aGlzIGRvY3VtZW50IGluIHRoZSBmdXR1cmUuDQoNCiAg IFRoZSBzcGVjaWZpYyBjaGFuZ2VzIGluIHRoaXMgZG9jdW1lbnQgdG8gbWVldCB0aGVzZSBnb2Fs cyBhcmU6DQoNCiAgIG8gIERlZmluZXMgdGhlIEFCTkYgYW5kIHJ1bGVzIGZvciBzdWJ0YWdzIHNv IHRoYXQgdGhlIGNhdGVnb3J5IG9mIGFsbA0KICAgICAgc3VidGFncyBjYW4gYmUgZGV0ZXJtaW5l ZCB3aXRob3V0IHJlZmVyZW5jZSB0byB0aGUgcmVnaXN0cnkuDQoNCiAgIG8gIEFkZHMgdGhlIGNv bmNlcHQgb2Ygd2VsbC1mb3JtZWQgdnMuIHZhbGlkYXRpbmcgcHJvY2Vzc29ycywNCiAgICAgIGRl ZmluaW5nIHRoZSBydWxlcyBieSB3aGljaCBhbiBpbXBsZW1lbnRhdGlvbiBjYW4gY2xhaW0gdG8g YmUgb25lDQogICAgICBvciB0aGUgb3RoZXIuDQoNCiAgIG8gIFJlcGxhY2VzIHRoZSBJQU5BIGxh bmd1YWdlIHRhZyByZWdpc3RyeSB3aXRoIGEgbGFuZ3VhZ2Ugc3VidGFnDQogICAgICByZWdpc3Ry eSB0aGF0IHByb3ZpZGVzIGEgY29tcGxldGUgbGlzdCBvZiB2YWxpZCBzdWJ0YWdzIGluIHRoZQ0K ICAgICAgSUFOQSByZWdpc3RyeS4gIFRoaXMgYWxsb3dzIGZvciByb2J1c3QgaW1wbGVtZW50YXRp b24gYW5kIGVhc2Ugb2YNCiAgICAgIG1haW50ZW5hbmNlLiAgVGhlIGxhbmd1YWdlIHN1YnRhZyBy ZWdpc3RyeSBiZWNvbWVzIHRoZSBjYW5vbmljYWwNCiAgICAgIHNvdXJjZSBmb3IgZm9ybWluZyBs YW5ndWFnZSB0YWdzLg0KDQogICBvICBQcm92aWRlcyBhIHByb2Nlc3MgdGhhdCBndWFyYW50ZWVz IHN0YWJpbGl0eSBvZiBsYW5ndWFnZSB0YWdzLCBieQ0KICAgICAgaGFuZGxpbmcgcmV1c2Ugb2Yg dmFsdWVzIGJ5IElTTyA2MzksIElTTyAxNTkyNCwgYW5kIElTTyAzMTY2IGluDQogICAgICB0aGUg ZXZlbnQgdGhhdCB0aGV5IHJlZ2lzdGVyIGEgcHJldmlvdXNseSB1c2VkIHZhbHVlIGZvciBhIG5l dw0KICAgICAgcHVycG9zZS4NCg0KICAgbyAgQWxsb3dzIElTTyAxNTkyNCBzY3JpcHQgY29kZSBz dWJ0YWdzIGFuZCBhbGxvd3MgdGhlbSB0byBiZSB1c2VkDQogICAgICBnZW5lcmF0aXZlbHkuICBB ZGRzIHRoZSBjb25jZXB0IG9mIGEgdmFyaWFudCBzdWJ0YWcgYW5kIGFsbG93cw0KICAgICAgdmFy aWFudHMgdG8gYmUgdXNlZCBnZW5lcmF0aXZlbHkuICBBZGRzIHRoZSBhYmlsaXR5IHRvIHVzZSBh IGNsYXNzDQogICAgICBvZiBVTiB0YWdzIGFzIHJlZ2lvbnMuDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA0 Nl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgIG8gIERlZmluZXMgdGhlIHByaXZhdGUtdXNl IHRhZ3MgaW4gSVNPIDYzOSwgSVNPIDE1OTI0LCBhbmQgSVNPIDMxNjYNCiAgICAgIGFzIHRoZSBt ZWNoYW5pc20gZm9yIGNyZWF0aW5nIHByaXZhdGUtdXNlIGxhbmd1YWdlLCBzY3JpcHQsIGFuZA0K ICAgICAgcmVnaW9uIHN1YnRhZ3MgcmVzcGVjdGl2ZWx5Lg0KDQogICBvICBBZGRzIGEgd2VsbC1k ZWZpbmVkIGV4dGVuc2lvbiBtZWNoYW5pc20uDQoNCiAgIG8gIERlZmluZXMgYW4gZXh0ZW5kZWQg bGFuZ3VhZ2Ugc3VidGFnLCBwb3NzaWJseSBmb3IgdXNlIHdpdGggY2VydGFpbg0KICAgICAgYW50 aWNpcGF0ZWQgZmVhdHVyZXMgb2YgSVNPIDYzOS0zLg0KDQogICBFZCBOb3RlOiBUaGUgZm9sbG93 aW5nIGl0ZW1zIGFyZSBwcm92aWRlZCBmb3IgdGhlIGNvbnZlbmllbmNlIG9mDQogICByZXZpZXdl cnMgYW5kIHdpbGwgYmUgcmVtb3ZlZCBmcm9tIHRoZSBmaW5hbCBkb2N1bWVudC4NCg0KICAgQ2hh bmdlcyBiZXR3ZWVuIGRyYWZ0LWlldGYtbHRydS1yZWdpc3RyeS0wMCBhbmQgdGhpcyB2ZXJzaW9u IGFyZToNCg0KICAgbyAgVXBkYXRlZCB0aGUgQUJORiBmb3Igc2luZ2xldG9uIHRvIG1ha2UgaXQg Y29uZm9ybSB0byBSRkMgMjIzNCBhbmQNCiAgICAgIHBhc3MgdGhlIEZlbm5lciBwYXJzZXIgKEYu RWxsZXJtYW5uKQ0KDQogICBvICBTcGxpdCB0aGUgcmVmZXJlbmNlcyBpbnRvIGluZm9ybWF0aXZl IGFuZCBub3JtYXRpdmUgbGlzdHMuDQogICAgICBFbGltaW5hdGVkIGRlYWQgcmVmZXJlbmNlcyBj YXJyaWVkIGZvcndhcmQgZnJvbSBwcmV2aW91cyB2ZXJzaW9ucw0KICAgICAgb2YgdGhpcyBkb2N1 bWVudC4gIChBLlBoaWxsaXBzKQ0KDQogICBvICBBZGRlZCBhIHJlZmVyZW5jZSB0byBSRkMgMzU1 MiAoQkNQIDcyKSB0byB0aGUgU2VjdXJpdHkNCiAgICAgIENvbnNpZGVyYXRpb25zIHNlY3Rpb24g KEkuTWNEb25hbGQpDQoNCiAgIG8gIE1vZGlmaWVkIHRoZSBmaXJzdCBzZW50ZW5jZSBpbiBTZWN0 aW9uIDIuMS4xIGZyb20gIm9uIHRoZSBudW1iZXINCiAgICAgIG9mIHNpemUgb2Ygc3VidGFncyBp biBhIExhbmd1YWdlIFRhZyIgdG8gYmUgcHJvcGVyIEVuZ2xpc2ggYW5kDQogICAgICBjb252ZXkg bW9yZSBtZWFuaW5nLiAgKEEuUGhpbGxpcHMpDQoNCiAgIG8gIFZhcmlvdXMgZXhhbXBsZXMgdGhh dCB1c2VkIHRoZSB2YXJpYW50ICdib29udCcgd2VyZSBjaGFuZ2VzIHRvIHVzZQ0KICAgICAgdGhl IHZhcmlhbnQgJ3Njb3VzZScgaW5zdGVhZC4gIChKLkNvd2FuKQ0KDQogICBvICBBZGRlZCBhbiBh ZGRpdGlvbmFsIGV4YW1wbGUgKCJlbi1hLWJiYi14LWEtY2NjIikgdG8gdGhlIGV4dGVuc2lvbi8N CiAgICAgIHNpbmdsZXRvbiBydWxlcyBpbiBTZWN0aW9uIDIuMi42IHRvIGlsbHVzdHJhdGUgdGhh dCBzaW5nbGV0b25zIGNhbg0KICAgICAgcmVjdXIgaW4gcHJpdmF0ZSB1c2Ugc2VxdWVuY2VzIChB LlBoaWxsaXBzKQ0KDQogICBvICBNb2RpZmllZCB0aGUgc2VudGVuY2UgZGVzY3JpYmluZyB0aGUg cG9zc2liaWxpdGllcyBmb3IgdmFyaWFudA0KICAgICAgcmVnaXN0cmF0aW9uIChzZWUgU2VjdGlv biAzLjUpICB0byBpbmNsdWRlIHRyYW5zbGl0ZXJhdGlvbnMgYW5kDQogICAgICBvdGhlciB0cmFu c2Zvcm1hdGlvbnMgcGVyIGRpc2N1c3Npb24gb24gdGhlIGxpc3QuICAoTS5ULiBDYXJyYXNjbw0K ICAgICAgQmVuaXRleikNCg0KICAgbyAgQ29udmVydGVkIHRoZSBmb3JtYXQgb2YgdGhlIHJlZ2lz dHJ5IHRvIHJlY29yZC1qYXIgZm9ybWF0LiAgVGhpcw0KICAgICAgc3VidGFudGlhbGx5IHJlcGxh Y2VzIHNlY3Rpb24gMy4xIChSLlByZXN1aG4pDQoNCiAgIG8gIFN1YnRhbnRpYWxseSByZXZpc2Vk IHRoZSBydWxlcyBmb3IgcmVnaXN0cnkgY3JlYXRpb24gdG8gcmVmbGVjdA0KICAgICAgdGhlIERh dGUgQS9CIGJvdW5kYXJpZXMgb24gYWRvcHRpbmcgSVNPIDMxNjYgY29kZXMgKEouQ293YW4pDQoN CiAgIG8gIE1vZGlmaWVkIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBzZWN0aW9uIGFuZCBmb3Jt IHRvIGRlYWwgd2l0aA0KICAgICAgYm90aCBuZXcgYWRkaXRpb25zIGFuZCByZXZpc2lvbnMgb2Yg cmVjb3JkcywgYXMgd2VsbCBhcyBtYWtpbmcNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAg IEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDQ3XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAg ICBBcHJpbCAyMDA1DQoNCg0KICAgICAgbGlmZSBlYXNpZXIgb24gdGhlIFN1YnRhZyBSZXZpZXdl ciBieSBtYXRjaGluZyB0aGUgZmllbGRzIHRvIHRoZQ0KICAgICAgcmVnaXN0cnkgZm9ybWF0LiAg KEEuUGhpbGxpcHMpDQoNCiAgIG8gIENoYW5nZWQgdGhlIHJlZmVyZW5jZSB0byBSRkMgMjIzNCB0 byBSRkMgMjIzNGJpcyAocmVjZW50bHkNCiAgICAgIGFkb3B0ZWQpLiAgKFMuSG9sbGVuYmVjaykN Cg0KICAgbyAgTW9kaWZpY2F0aW9ucyB0byBtYWtlIHRoaXMgZG9jdW1lbnQgY29uZm9ybWFudCB3 aXRoIFJGQyAzOTc4DQogICAgICAocmVjZW50bHkgYWRvcHRlZCkuICAoUi5QcmVzdWhuKQ0KDQog ICBvICBBZGRlZCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gWE1MIFNjaGVtYSAxLjAgUGFy dCAyOiBTZWNvbmQNCiAgICAgIEVkaXRpb24gaW4gdGhpcyBzZWN0aW9uLiAgKEouTW9yZmluKQ0K DQogICBvICBFeHBhbmRlZCB0aGUgamFyZ29uLWlzaCAnZXh0bGFuZycgdG8gImV4dGVuZGVkIGxh bmd1YWdlIiBpbiB0aGlzDQogICAgICBzZWN0aW9uLiAgKEouTW9yZmluKQ0KDQogICBvICBDb3Jy ZWN0ZWQgYW4gZWdyZWdpb3VzIGVycm9yIGluIHRoZSBBQk5GICgleDZBIC0+ICV4NUEgaW4gb25l IG9mDQogICAgICB0aGUgcmFuZ2VzKSAoQS5QaGlsbGlwcykNCg0KICAgbyAgU3BsaXQgTWFpbnRl bmFuY2Ugb2YgdGhlIFJlZ2lzdHJ5IGZyb20gRm9ybWF0IG9mIHRoZSBSZWdpc3RyeQ0KICAgICAg KEEuUGhpbGxpcHMpDQoNCiAgIG8gIFJldmlzaW9uIG9mIHNlY3Rpb24gU2VjdGlvbiAzLjQgdG8g bWFrZSBpdCBjb25zaXN0ZW50IHdpdGggdGhlIG5ldw0KICAgICAgc2VjdGlvbiBTZWN0aW9uIDMu Mi4gIChBLlBoaWxsaXBzKQ0KDQogICBvICBTZXBhcmF0ZWQgSUFOQSBDb25zaWRlcmF0aW9ucyBz ZWN0aW9uIGZyb20gdGhlIHJlZ2lzdHJ5IGRlZmluaXRpb24NCiAgICAgIGFuZCByZWdpc3RyYXRp b24gcHJvY2VkdXJlcy4gKCkNCg0KICAgbyAgQWRkZWQgYWRkaXRpb25hbCBjaG9pY2UgaW5mb3Jt YXRpb24gZGVhbGluZyB3aXRoIHNjcmlwdHMgYW5kDQogICAgICBleHRsYW5ncy4gIFRoZXNlIGl0 ZW1zIHdlcmUgYWxzbyBtb3ZlZCB0byBhIG5ldyBzZWN0aW9uIGZvbGxvd2luZw0KICAgICAgdGhl IHJlZ2lzdHJ5IGZvcm1hdCBiZWNhdXNlIG9mIGludGVyZGVwZW5kZW5jZS4NCg0KICAgbyAgVXBk YXRlZCB0aGUgSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KDQogICBvICBBZGRlZCBhcHBl YWwgYW5kIG1haW50ZW5hbmNlIHJlcXVpcmVtZW50cyB0byB0aGUgZXh0ZW5zaW9ucw0KICAgICAg U2VjdGlvbiAzLjYgc2VjdGlvbi4gIChBLlBoaWxsaXBzKQ0KDQogICBvICBBZGRlZCBhbiBhZGRp dGlvbmFsIGJ1bGxldCBwb2ludCB0byBTZWN0aW9uIDMuNSBlbnVtZXJhdGluZyB0aGUNCiAgICAg IGNoYW5nZXMgdGhhdCBjYW4gYmUgcmVnaXN0ZXJlZCB0byBhIHJlY29yZCAocHJldmlvdXNseSB3 ZSBvbmx5DQogICAgICBsaXN0ZWQgdGhlIG9wdGlvbnMgZm9yIG5ldyBzdWJ0YWdzKS4gIChBLlBo aWxsaXBzKQ0KDQogICBvICBBZGRlZCB0aGUgcGhyYXNlICIsIGFzIHdlbGwgYXMgdGhlIHBvc3Np YmlsaXR5IG9mIG90aGVyIElTTyA2MzkNCiAgICAgIHBhcnRzIGJlY29taW5nIHVzZWZ1bCBmb3Ig dGhlIGZvcm1hdGlvbiBvZiBsYW5ndWFnZSB0YWdzIGluIHRoZQ0KICAgICAgZnV0dXJlIiB0byB0 aGlzIHNlY3Rpb24gaW4gYW50aWNpcGF0aW9uIG9mIHJldmlzaW5nIHRoZSBBQk5GIHRvDQogICAg ICBhbGxvdyBmb3IgdGhlIHBvc3NpYmlsaXR5IG9mIElTTyA2MzktNiBiZWluZyB1c2VkIGluIGxh bmd1YWdlIHRhZ3MNCiAgICAgIGluIGEgZnV0dXJlIHJldmlzaW9uIG9mIHRoaXMgZG9jdW1lbnQu ICAoRC5HYXJzaWRlKQ0KDQogICBvICBBZGRlZCB0aGUgY29uY2VwdCBvZiAnU3VwcHJlc3MtU2Ny aXB0JyB0byBTZWN0aW9uIDQuMSwgYXMgd2VsbCBhcw0KICAgICAgdG8gdGhlIHJlZ2lzdHJ5IGZv cm1hdCBpbiBTZWN0aW9uIDMuMSwgU2VjdGlvbiAzLjMgYW5kDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA0 OF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICAgQXByaWwgMjAwNQ0KDQoNCiAgICAgIFNlY3Rpb24gMy4yLiAobWFueSkNCg0K ICAgbyAgQWRkZWQgdGV4dCByZXF1aXJpbmcgdGhlIEktRCB0aGF0IGRlZmluZXMgYW4gZXh0ZW5z aW9uIHRvIGNob29zZSBhDQogICAgICBsZXR0ZXIgKGFuZCBhbGxvd2luZyB0aGUgSUVTRyB0byBj aGFuZ2UgaXQgaWYgbmVjZXNzYXJ5KS4NCiAgICAgIChELkV3ZWxsPykNCg0KICAgbyAgUmVtb3Zl ZCB0aGUgQUJORiBub3RlcyBmcm9tIHRoZSB0ZXh0IGFib3V0IGNhc2UgaW5zZW5zaXRpdml0eQ0K ICAgICAgKEYuRWxsZXJtYW5uKQ0KDQogICBvICBSZW1vdmVkIHRoZSBzZWNvbmQsIHJhdGhlciBy ZXBldGl0aXZlIHJlZmVyZW5jZSB0byBBcHBlbmRpeCBCIGluDQogICAgICBTZWN0aW9uIDIuMSAo QS5QaGlsbGlwcykNCg0KICAgbyAgRml4ZWQgbWlzc2luZyB3aGl0ZXNhcGNlIGluIFNlY3Rpb24g Mi4xIChGLkVsbGVybWFubikNCg0KICAgbyAgQ2hhbmdlZCAiZW1wdHkiIHRvICJvbWl0dGVkIiBp biBTZWN0aW9uIDIuMi4xIChGLkVsbGVybWFubikNCg0KICAgbyAgQ2hhbmdlZCB0aGUgaW50cm8g dG8gU2VjdGlvbiAyLjIuMSBhbmQgb3RoZXJ3aXNlIHR1Z2dlZCBhdCB0aGF0DQogICAgICBzZWN0 aW9uIHRvIGRlYWwgd2l0aCBpLSogZ3JhbmRmYXRoZXJlZCBpdGVtcy4gIChGLkVsbGVybWFubikN Cg0KICAgbyAgUmVzZXJ2ZWQgYWxwaGE0IGxhbmd1YWdlIHN1YnRhZ3MgZm9yIGZ1dHVyZSBzdGFu ZGFyZGl6YXRpb24uDQogICAgICAoRC5HYXJzaWRlKQ0KDQogICBvICBJbmNvcnBvcmF0ZSBjaGFu Z2VzIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCBSRkMgMzk3OCwgaW5jbHVkaW5nIHRoZQ0KICAgICAg bmV3IHhtbDJyZmMgcHJvY2Vzc29yLiAgTm90ZSB0aGF0IHRoaXMgaGFzIGFuIGVmZmVjdCBvbiB0 aGUgQUJORiwNCiAgICAgIHNpbmNlIHNvbWUgb2YgdGhlIGNvbW1lbnRzIHdlcmUgdG9vIHdpZGUg cHJldmlvdXNseSAoY29tbWVudHMgd2VyZQ0KICAgICAgcmV2aXNlZCB0byBmaXQgdGhlIDcyIGNo YXJhY3RlciBtYXhpbXVtKS4gIChTLkhvbGxlbmJlY2spDQoNCiAgIG8gIFJlbW92ZSB0aGUgTGF0 aW4tMSByZXN0cmljdGlvbiBvbiB0aGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZC4NCiAgICAgIFByb3Zp ZGUgZ3VpZGFuY2UgZm9yIHJlZ2lzdHJhdGlvbiBvZiBjb250ZW50LCBpbmNsdWRpbmcgYQ0KICAg ICAgcmVxdWlyZW1lbnQgZm9yIGF0IGxlYXN0IG9uZSByZXByZXNlbnRhdGlvbiBpbiB0aGUgTGF0 aW4gc2NyaXB0Lg0KICAgICAgKEYuRWxsZXJtYW5uLCBBLlBoaWxsaXBzKQ0KDQogICBvICBNYWtl IHRoZSB2YXJpYW50IHN1YnRsZXR5IGxlc3Mgc28uICAoRi5FbGxlcm1hbm4pDQoNCiAgIG8gIFZh cmlvdXMgJ3lvdScgcmVtb3ZhbHMgYW5kIGNsZWFudXAgKE0uRGF2aXMpDQoNCiAgIG8gIEluc2Vy dGVkIGFkZGl0aW9uYWwgbm9uLW5vcm1hdGl2ZSBjYXZlYXQgYWJvdXQgdGhlICdNVUwnIHN1YnRh Zw0KICAgICAgKEEuUGhpbGxpcHMpDQoNCiAgIG8gIFZhcmlvdXMgZWRpdG9yaWFsIGVkaXRzIChK LkNvd2FuKQ0KDQogICBvICBVc2Ugbm9ybWF0aXZlIGxhbmd1YWdlIHdoZW4gZ2l2aW5nIHBlcm1p c3Npb24gdG8gbm90IHN0b3JlIGxvbmcNCiAgICAgIGxhbmd1YWdlIHRhZ3MgaW4gU2VjdGlvbiAy LjEuMS4gIChKLkNvd2FuKQ0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAg IEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDQ5XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAg ICBBcHJpbCAyMDA1DQoNCg0KOS4gIFJlZmVyZW5jZXMNCg0KOS4xICBOb3JtYXRpdmUgUmVmZXJl bmNlcw0KDQogICBbMV0gICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBmb3IgU3RhbmRhcmRp emF0aW9uLCAiSVNPIDYzOS0NCiAgICAgICAgIDE6MjAwMiwgQ29kZXMgZm9yIHRoZSByZXByZXNl bnRhdGlvbiBvZiBuYW1lcyBvZiBsYW5ndWFnZXMgLS0NCiAgICAgICAgIFBhcnQgMTogQWxwaGEt MiBjb2RlIiwgSVNPIFN0YW5kYXJkIDYzOSwgMjAwMi4NCg0KICAgWzJdICAgSW50ZXJuYXRpb25h bCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTyA2MzktMjoxOTk4DQogICAg ICAgICAtIENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YgbGFuZ3VhZ2Vz IC0tIFBhcnQgMjoNCiAgICAgICAgIEFscGhhLTMgY29kZSAtIGVkaXRpb24gMSIsIEF1Z3VzdCAx OTg4Lg0KDQogICBbM10gICBJU08gVEM0Ni9XRzMsICJJU08gMTU5MjQ6MjAwMyAoRS9GKSAtIENv ZGVzIGZvciB0aGUNCiAgICAgICAgIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIHNjcmlwdHMi LCBKYW51YXJ5IDIwMDQuDQoNCiAgIFs0XSAgIEludGVybmF0aW9uYWwgT3JnYW5pemF0aW9uIGZv ciBTdGFuZGFyZGl6YXRpb24sICJDb2RlcyBmb3IgdGhlDQogICAgICAgICByZXByZXNlbnRhdGlv biBvZiBuYW1lcyBvZiBjb3VudHJpZXMsIDNyZCBlZGl0aW9uIiwNCiAgICAgICAgIElTTyBTdGFu ZGFyZCAzMTY2LCBBdWd1c3QgMTk4OC4NCg0KICAgWzVdICAgU3RhdGlzdGljYWwgRGl2aXNpb24s IFVuaXRlZCBOYXRpb25zLCAiU3RhbmRhcmQgQ291bnRyeSBvciBBcmVhDQogICAgICAgICBDb2Rl cyBmb3IgU3RhdGlzdGljYWwgVXNlIiwgVU4gU3RhbmRhcmQgQ291bnRyeSBvciBBcmVhIENvZGVz DQogICAgICAgICBmb3IgU3RhdGlzdGljYWwgVXNlLCBSZXZpc2lvbiA0IChVbml0ZWQgTmF0aW9u cyBwdWJsaWNhdGlvbiwNCiAgICAgICAgIFNhbGVzIE5vLiA5OC5YVklJLjksIEp1bmUgMTk5OS4N Cg0KICAgWzZdICAgSW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlv biwgIklTTy9JRUMgMTA2NDYtDQogICAgICAgICAxOjIwMDAuIEluZm9ybWF0aW9uIHRlY2hub2xv Z3kgLS0gVW5pdmVyc2FsIE11bHRpcGxlLU9jdGV0DQogICAgICAgICBDb2RlZCBDaGFyYWN0ZXIg U2V0IChVQ1MpIC0tIFBhcnQgMTogQXJjaGl0ZWN0dXJlIGFuZCBCYXNpYw0KICAgICAgICAgTXVs dGlsaW5ndWFsIFBsYW5lIGFuZCBJU08vSUVDIDEwNjQ2LTI6MjAwMS4gSW5mb3JtYXRpb24NCiAg ICAgICAgIHRlY2hub2xvZ3kgLS0gVW5pdmVyc2FsIE11bHRpcGxlLU9jdGV0IENvZGVkIENoYXJh Y3RlciBTZXQNCiAgICAgICAgIChVQ1MpIC0tIFBhcnQgMjogU3VwcGxlbWVudGFyeSBQbGFuZXMs IGFzLCBmcm9tIHRpbWUgdG8gdGltZSwNCiAgICAgICAgIGFtZW5kZWQsIHJlcGxhY2VkIGJ5IGEg bmV3IGVkaXRpb24gb3IgZXhwYW5kZWQgYnkgdGhlIGFkZGl0aW9uDQogICAgICAgICBvZiBuZXcg cGFydHMiLCAyMDAwLg0KDQogICBbN10gICBDcm9ja2VyLCBELiBhbmQgUC4gT3ZlcmVsbCwgIkF1 Z21lbnRlZCBCTkYgZm9yIFN5bnRheA0KICAgICAgICAgU3BlY2lmaWNhdGlvbnM6IEFCTkYiLCBk cmFmdC1jcm9ja2VyLWFibmYtcmZjMjIzNGJpcy0wMCAod29yaw0KICAgICAgICAgaW4gcHJvZ3Jl c3MpLCBNYXJjaCAyMDA1Lg0KDQogICBbOF0gICBCcmFkbmVyLCBTLiwgIlRoZSBJbnRlcm5ldCBT dGFuZGFyZHMgUHJvY2VzcyAtLSBSZXZpc2lvbiAzIiwNCiAgICAgICAgIEJDUCA5LCBSRkMgMjAy NiwgT2N0b2JlciAxOTk2Lg0KDQogICBbOV0gICBIb3ZleSwgUi4gYW5kIFMuIEJyYWRuZXIsICJU aGUgT3JnYW5pemF0aW9ucyBJbnZvbHZlZCBpbiB0aGUNCiAgICAgICAgIElFVEYgU3RhbmRhcmRz IFByb2Nlc3MiLCBCQ1AgMTEsIFJGQyAyMDI4LCBPY3RvYmVyIDE5OTYuDQoNCiAgIFsxMF0gIEJy YWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1aXJl bWVudA0KICAgICAgICAgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0K ICAgWzExXSAgTmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9yIFdy aXRpbmcgYW4gSUFOQQ0KICAgICAgICAgQ29uc2lkZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzIiwg QkNQIDI2LCBSRkMgMjQzNCwNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMg T2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDUwXQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAy MDA1DQoNCg0KICAgICAgICAgT2N0b2JlciAxOTk4Lg0KDQogICBbMTJdICBIb2ZmbWFuLCBQLiBh bmQgRi4gWWVyZ2VhdSwgIlVURi0xNiwgYW4gZW5jb2Rpbmcgb2YgSVNPIDEwNjQ2IiwNCiAgICAg ICAgIFJGQyAyNzgxLCBGZWJydWFyeSAyMDAwLg0KDQogICBbMTNdICBDYXJwZW50ZXIsIEIuLCBC YWtlciwgRi4sIGFuZCBNLiBSb2JlcnRzLCAiTWVtb3JhbmR1bSBvZg0KICAgICAgICAgVW5kZXJz dGFuZGluZyBDb25jZXJuaW5nIHRoZSBUZWNobmljYWwgV29yayBvZiB0aGUgSW50ZXJuZXQNCiAg ICAgICAgIEFzc2lnbmVkIE51bWJlcnMgQXV0aG9yaXR5IiwgUkZDIDI4NjAsIEp1bmUgMjAwMC4N Cg0KICAgWzE0XSAgS2x5bmUsIEcuIGFuZCBDLiBOZXdtYW4sICJEYXRlIGFuZCBUaW1lIG9uIHRo ZSBJbnRlcm5ldDoNCiAgICAgICAgIFRpbWVzdGFtcHMiLCBSRkMgMzMzOSwgSnVseSAyMDAyLg0K DQogICBbMTVdICBSZXNjb3JsYSwgRS4gYW5kIEIuIEtvcnZlciwgIkd1aWRlbGluZXMgZm9yIFdy aXRpbmcgUkZDIFRleHQgb24NCiAgICAgICAgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIiwgQkNQ IDcyLCBSRkMgMzU1MiwgSnVseSAyMDAzLg0KDQo5LjIgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMN Cg0KICAgWzE2XSAgSVNPIDYzOSBKb2ludCBBZHZpc29yeSBDb21taXR0ZWUsICJJU08gNjM5IEpv aW50IEFkdmlzb3J5DQogICAgICAgICBDb21taXR0ZWU6ICBXb3JraW5nIHByaW5jaXBsZXMgZm9y IElTTyA2MzkgbWFpbnRlbmFuY2UiLA0KICAgICAgICAgTWFyY2ggMjAwMCwNCiAgICAgICAgIDxo dHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOS0yL2lzbzYzOWphY19uM3IuaHRtbD4u DQoNCiAgIFsxN10gIFJheW1vbmQsIEUuLCAiVGhlIEFydCBvZiBVbml4IFByb2dyYW1taW5nIiwg MjAwMy4NCg0KICAgWzE4XSAgQnJheSAoZXQgYWwpLCBULiwgIkV4dGVuc2libGUgTWFya3VwIExh bmd1YWdlIChYTUwpIDEuMCIsDQogICAgICAgICAwMiAyMDA0Lg0KDQogICBbMTldICBCaXJvbiwg UC4sIEVkLiBhbmQgQS4gTWFsaG90cmEsIEVkLiwgIlhNTCBTY2hlbWEgUGFydCAyOg0KICAgICAg ICAgRGF0YXR5cGVzIFNlY29uZCBFZGl0aW9uIiwgMTAgMjAwNCwgPA0KICAgICAgICAgaHR0cDov L3d3dy53My5vcmcvVFIveG1sc2NoZW1hLTIvPi4NCg0KICAgWzIwXSAgVW5pY29kZSBDb25zb3J0 aXVtLCAiVGhlIFVuaWNvZGUgQ29uc29ydGl1bS4gVGhlIFVuaWNvZGUNCiAgICAgICAgIFN0YW5k YXJkLCBWZXJzaW9uIDQuMS4wLCBkZWZpbmVkIGJ5OiBUaGUgVW5pY29kZSBTdGFuZGFyZCwNCiAg ICAgICAgIFZlcnNpb24gNC4wIChCb3N0b24sIE1BLCBBZGRpc29uLVdlc2xleSwgMjAwMy4gSVNC TiAwLTMyMS0NCiAgICAgICAgIDE4NTc4LTEpLCBhcyBhbWVuZGVkIGJ5IFVuaWNvZGUgNC4wLjEN CiAgICAgICAgIChodHRwOi8vd3d3LnVuaWNvZGUub3JnL3ZlcnNpb25zL1VuaWNvZGU0LjAuMSkg YW5kIGJ5IFVuaWNvZGUNCiAgICAgICAgIDQuMS4wIChodHRwOi8vd3d3LnVuaWNvZGUub3JnL3Zl cnNpb25zL1VuaWNvZGU0LjEuMCkuIiwNCiAgICAgICAgIE1hcmNoIDIwMDUuDQoNCiAgIFsyMV0g IEFsdmVzdHJhbmQsIEguLCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9mIExhbmd1YWdl cyIsDQogICAgICAgICBSRkMgMTc2NiwgTWFyY2ggMTk5NS4NCg0KICAgWzIyXSAgRnJlZWQsIE4u IGFuZCBLLiBNb29yZSwgIk1JTUUgUGFyYW1ldGVyIFZhbHVlIGFuZCBFbmNvZGVkIFdvcmQNCiAg ICAgICAgIEV4dGVuc2lvbnM6IENoYXJhY3RlciBTZXRzLCBMYW5ndWFnZXMsIGFuZCBDb250aW51 YXRpb25zIiwNCiAgICAgICAgIFJGQyAyMjMxLCBOb3ZlbWJlciAxOTk3Lg0KDQogICBbMjNdICBB bHZlc3RyYW5kLCBILiwgIlRhZ3MgZm9yIHRoZSBJZGVudGlmaWNhdGlvbiBvZiBMYW5ndWFnZXMi LA0KICAgICAgICAgQkNQIDQ3LCBSRkMgMzA2NiwgSmFudWFyeSAyMDAxLg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAyMDA1ICAgICAgICAgICAgICAg W1BhZ2UgNTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMNCg0K ICAgQWRkaXNvbiBQaGlsbGlwcyAoZWRpdG9yKQ0KICAgUXVlc3QgU29mdHdhcmUNCg0KICAgRW1h aWw6IGFkZGlzb24ucGhpbGxpcHNAcXVlc3QuY29tDQoNCg0KICAgTWFyayBEYXZpcyAoZWRpdG9y KQ0KICAgSUJNDQoNCiAgIEVtYWlsOiBtYXJrLmRhdmlzQHVzLmlibS5jb20NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAw NSAgICAgICAgICAgICAgIFtQYWdlIDUyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KQXBwZW5k aXggQS4gIEFja25vd2xlZGdlbWVudHMNCg0KICAgQW55IGxpc3Qgb2YgY29udHJpYnV0b3JzIGlz IGJvdW5kIHRvIGJlIGluY29tcGxldGU7IHBsZWFzZSByZWdhcmQgdGhlDQogICBmb2xsb3dpbmcg YXMgb25seSBhIHNlbGVjdGlvbiBmcm9tIHRoZSBncm91cCBvZiBwZW9wbGUgd2hvIGhhdmUNCiAg IGNvbnRyaWJ1dGVkIHRvIG1ha2UgdGhpcyBkb2N1bWVudCB3aGF0IGl0IGlzIHRvZGF5Lg0KDQog ICBUaGUgY29udHJpYnV0b3JzIHRvIFJGQyAzMDY2IGFuZCBSRkMgMTc2NiwgdGhlIHByZWN1cnNv cnMgb2YgdGhpcw0KICAgZG9jdW1lbnQsIG1hZGUgZW5vcm1vdXMgY29udHJpYnV0aW9ucyBkaXJl Y3RseSBvciBpbmRpcmVjdGx5IHRvIHRoaXMNCiAgIGRvY3VtZW50IGFuZCBhcmUgZ2VuZXJhbGx5 IHJlc3BvbnNpYmxlIGZvciB0aGUgc3VjY2VzcyBvZiBsYW5ndWFnZQ0KICAgdGFncy4NCg0KICAg VGhlIGZvbGxvd2luZyBwZW9wbGUgKGluIGFscGhhYmV0aWNhbCBvcmRlcikgY29udHJpYnV0ZWQg dG8gdGhpcw0KICAgZG9jdW1lbnQgb3IgdG8gUkZDcyAxNzY2IGFuZCAzMDY2Og0KDQogICBHbGVu biBBZGFtcywgSGFyYWxkIFR2ZWl0IEFsdmVzdHJhbmQsIFRpbSBCZXJuZXJzLUxlZSwgTWFyYyBC bGFuY2hldCwNCiAgIE5hdGhhbmllbCBCb3JlbnN0ZWluLCBFcmljIEJydW5uZXIsIFNlYW4gTS4g QnVya2UsIE0uVC4gQ2FycmFzY28NCiAgIEJlbml0ZXosIEplcmVteSBDYXJyb2xsLCBKb2huIENs ZXdzLCBKaW0gQ29ua2xpbiwgUGV0ZXIgQ29uc3RhYmxlLA0KICAgSm9obiBDb3dhbiwgTWFyayBD cmlzcGluLCBEYXZlIENyb2NrZXIsIE1hcnRpbiBEdWVyc3QsIEZyYW5rDQogICBFbGxlcm1hbiwg TWljaGFlbCBFdmVyc29uLCBEb3VnIEV3ZWxsLCBOZWQgRnJlZWQsIFRpbSBHb29kd2luLCBEaXJr LQ0KICAgV2lsbGVtIHZhbiBHdWxpaywgTWFyaW9uIEd1bm4sIEpvZWwgSGFscHJlbiwgRWxsaW90 dGUgUnVzdHkgSGFyb2xkLA0KICAgUGF1bCBIb2ZmbWFuLCBTY290dCBIb2xsZW5iZWNrLCBSaWNo YXJkIElzaGlkYSwgT2xsZSBKYXJuZWZvcnMsIEtlbnQNCiAgIEthcmxzc29uLCBKb2huIEtsZW5z aW4sIEFsYWluIExhQm9udGUsIEVyaWMgTWFkZXIsIElyYSBNY0RvbmFsZCwNCiAgIEtlaXRoIE1v b3JlLCBDaHJpcyBOZXdtYW4sIE1hc2F0YWthIE9odGEsIFJhbmR5IFByZXN1aG4sIEdlb3JnZQ0K ICAgUmhvdGVuLCBNYXJrdXMgU2NoZXJlciwgS2VsZCBKb3JuIFNpbW9uc2VuLCBUaGllcnJ5IFNv dXJiaWVyLCBPdHRvDQogICBTdG9seiwgVGV4IFRleGluLCBBbmRyZWEgVmluZSwgUmh5cyBXZWF0 aGVybGV5LCBNaXNoYSBXb2xmLCBGcmFuY29pcw0KICAgWWVyZ2VhdSBhbmQgbWFueSwgbWFueSBv dGhlcnMuDQoNCiAgIFZlcnkgc3BlY2lhbCB0aGFua3MgbXVzdCBnbyB0byBIYXJhbGQgVHZlaXQg QWx2ZXN0cmFuZCwgd2hvDQogICBvcmlnaW5hdGVkIFJGQ3MgMTc2NiBhbmQgMzA2NiwgYW5kIHdp dGhvdXQgd2hvbSB0aGlzIGRvY3VtZW50IHdvdWxkDQogICBub3QgaGF2ZSBiZWVuIHBvc3NpYmxl LiAgU3BlY2lhbCB0aGFua3MgbXVzdCBnbyB0byBNaWNoYWVsIEV2ZXJzb24sDQogICB3aG8gaGFz IHNlcnZlZCBhcyBsYW5ndWFnZSB0YWcgcmV2aWV3ZXIgZm9yIGFsbW9zdCB0aGUgY29tcGxldGUN CiAgIHBlcmlvZCBzaW5jZSB0aGUgcHVibGljYXRpb24gb2YgUkZDIDE3NjYuICBTcGVjaWFsIHRo YW5rcyB0byBEb3VnDQogICBFd2VsbCwgZm9yIGhpcyBwcm9kdWN0aW9uIG9mIHRoZSBmaXJzdCBj b21wbGV0ZSBzdWJ0YWcgcmVnaXN0cnksIGFuZA0KICAgaGlzIHdvcmsgaW4gcHJvZHVjaW5nIGEg dGVzdCBwYXJzZXIgZm9yIHZlcmlmeWluZyBsYW5ndWFnZSB0YWdzLg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2Jl ciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDUzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoN Cg0KQXBwZW5kaXggQi4gIEV4YW1wbGVzIG9mIExhbmd1YWdlIFRhZ3MgKEluZm9ybWF0aXZlKQ0K DQogICBTaW1wbGUgbGFuZ3VhZ2Ugc3VidGFnOg0KDQogICAgICBkZSAoR2VybWFuKQ0KDQogICAg ICBmciAoRnJlbmNoKQ0KDQogICAgICBqYSAoSmFwYW5lc2UpDQoNCiAgICAgIGktZW5vY2hpYW4g KGV4YW1wbGUgb2YgYSBncmFuZGZhdGhlcmVkIHRhZykNCg0KICAgTGFuZ3VhZ2Ugc3VidGFnIHBs dXMgU2NyaXB0IHN1YnRhZzoNCg0KICAgICAgemgtSGFudCAoQ2hpbmVzZSB3cml0dGVuIHVzaW5n IHRoZSBUcmFkaXRpb25hbCBDaGluZXNlIHNjcmlwdCkNCg0KICAgICAgemgtSGFucyAoQ2hpbmVz ZSB3cml0dGVuIHVzaW5nIHRoZSBTaW1wbGlmaWVkIENoaW5lc2Ugc2NyaXB0KQ0KDQogICAgICBz ci1DeXJsIChTZXJiaWFuIHdyaXR0ZW4gdXNpbmcgdGhlICBDeXJpbGxpYyBzY3JpcHQpDQoNCiAg ICAgIHNyLUxhdG4gKFNlcmJpYW4gd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0KQ0KDQog ICBMYW5ndWFnZS1TY3JpcHQtUmVnaW9uOg0KDQogICAgICB6aC1IYW5zLUNOIChDaGluZXNlIHdy aXR0ZW4gdXNpbmcgdGhlIFNpbWxpZmllZCBzY3JpcHQgYXMgdXNlZCBpbg0KICAgICAgbWFpbmxh bmQgQ2hpbmEpDQoNCiAgICAgIHNyLUxhdG4tQ1MgKFNlcmJpYW4gd3JpdHRlbiB1c2luZyB0aGUg TGF0aW4gc2NyaXB0IGFzIHVzZWQgaW4NCiAgICAgIFNlcmJpYSBhbmQgTW9udGVuZWdybykNCg0K ICAgTGFuZ3VhZ2UtVmFyaWFudDoNCg0KICAgICAgZW4tYm9vbnQgKEJvb250bGluZyBkaWFsZWN0 IG9mIEVuZ2xpc2gpDQoNCiAgICAgIGVuLXNjb3VzZSAoU2NvdXNlIGRpYWxlY3Qgb2YgRW5nbGlz aCkNCg0KICAgTGFuZ3VhZ2UtUmVnaW9uLVZhcmlhbnQ6DQoNCiAgICAgIGVuLUdCLXNjb3VzZSAo U2NvdXNlIGRpYWxlY3Qgb2YgRW5nbGlzaCBhcyB1c2VkIGluIHRoZSBVSykNCg0KICAgTGFuZ3Vh Z2UtU2NyaXB0LVJlZ2lvbi1WYXJpYW50Og0KDQogICAgICBzbC1MYXRuLUlULW5lZGlzIChOYWRp emEgZGlhbGVjdCBvZiBTbG92ZW5pYW4gd3JpdHRlbiB1c2luZyB0aGUNCiAgICAgIExhdGluIHNj cmlwdCBhcyB1c2VkIGluIEl0YWx5LiAgTm90ZSB0aGF0IHRoaXMgdGFnIGlzIG5vdA0KICAgICAg cmVjb21tZW5kZWQgYmVjYXVzZSBzdWJ0YWcgJ3NsJyBoYXMgYSBTdXBwcmVzcy1TY3JpcHQgdmFs dWUgb2YNCiAgICAgICdMYXRuJykNCg0KICAgTGFuZ3VhZ2UtUmVnaW9uOg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAyMDA1ICAgICAgICAgICAgICAg W1BhZ2UgNTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICAgICBkZS1ERSAoR2VybWFuIGZv ciBHZXJtYW55KQ0KDQogICAgICBlbi1VUyAoRW5nbGlzaCBhcyB1c2VkIGluIHRoZSBVbml0ZWQg U3RhdGVzKQ0KDQogICAgICBlcy00MTkgKFNwYW5pc2ggZm9yIExhdGluIEFtZXJpY2EgYW5kIENh cmliYmVhbiByZWdpb24gdXNpbmcgdGhlDQogICAgICBVTiByZWdpb24gY29kZSkNCg0KICAgUHJp dmF0ZS11c2Ugc3VidGFnczoNCg0KICAgICAgZGUtQ0gteC1waG9uZWJrDQoNCiAgICAgIGF6LUFy YWIteC1BWkUtZGVyYmVuZA0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIChleGFtcGxl cyBPTkxZOiBleHRlbmRlZCBsYW5ndWFnZXMgbXVzdCBiZQ0KICAgZGVmaW5lZCBieSByZXZpc2lv biBvciB1cGRhdGUgdG8gdGhpcyBkb2N1bWVudCk6DQoNCiAgICAgIHpoLW1pbg0KDQogICAgICB6 aC1taW4tbmFuLUhhbnQtQ04NCg0KICAgUHJpdmF0ZS11c2UgcmVnaXN0cnkgdmFsdWVzOg0KDQog ICAgICB4LXdoYXRldmVyIChwcml2YXRlIHVzZSB1c2luZyB0aGUgc2luZ2xldG9uICd4JykNCg0K ICAgICAgcWFhLVFhYWEtUU0teC1zb3V0aGVybiAoYWxsIHByaXZhdGUgdGFncykNCg0KICAgICAg ZGUtUWFhYSAoR2VybWFuLCB3aXRoIGEgcHJpdmF0ZSBzY3JpcHQpDQoNCiAgICAgIHNyLUxhdG4t UU0gKFNlcmJpYW4sIExhdGluLXNjcmlwdCwgcHJpdmF0ZSByZWdpb24pDQoNCiAgICAgIHNyLVFh YWEtQ1MgKFNlcmJpYW4sIHByaXZhdGUgc2NyaXB0LCBmb3IgU2VyYmlhIGFuZCBNb250ZW5lZ3Jv KQ0KDQogICBUYWdzIHRoYXQgdXNlIGV4dGVuc2lvbnMgKGV4YW1wbGVzIE9OTFk6IGV4dGVuc2lv bnMgbXVzdCBiZSBkZWZpbmVkDQogICBieSByZXZpc2lvbiBvciB1cGRhdGUgdG8gdGhpcyBkb2N1 bWVudCBvciBieSBSRkMpOg0KDQogICAgICBlbi1VUy11LWlzbGFtQ2FsDQoNCiAgICAgIHpoLUNO LWEtbXlFeHQteC1wcml2YXRlDQoNCiAgICAgIGVuLWEtbXlFeHQtYi1hbm90aGVyDQoNCiAgIFNv bWUgSW52YWxpZCBUYWdzOg0KDQogICAgICBkZS00MTktREUgKHR3byByZWdpb24gdGFncykNCg0K DQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAy MDA1ICAgICAgICAgICAgICAgW1BhZ2UgNTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICAg ICBhLURFICh1c2Ugb2YgYSBzaW5nbGUgY2hhcmFjdGVyIHN1YnRhZyBpbiBwcmltYXJ5IHBvc2l0 aW9uOyBub3RlDQogICAgICB0aGF0IHRoZXJlIGFyZSBhIGZldyBncmFuZGZhdGhlcmVkIHRhZ3Mg dGhhdCBzdGFydCB3aXRoICJpLSIgdGhhdA0KICAgICAgYXJlIHZhbGlkKQ0KDQogICAgICBhci1h LWFhYS1iLWJiYi1hLWNjYyAodHdvIGV4dGVuc2lvbnMgd2l0aCBzYW1lIHNpbmdsZSBsZXR0ZXIN CiAgICAgIHByZWZpeCkNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQ YWdlIDU2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KQXBwZW5kaXggQy4gIEV4YW1wbGUgUmVn aXN0cnkNCg0KICAgRXhhbXBsZSBSZWdpc3RyeQ0KDQogICBGaWxlLURhdGU6IDIwMDUtMDQtMTgN CiAgICUlDQogICBUeXBlOiBsYW5ndWFnZQ0KICAgU3VidGFnOiBhYQ0KICAgRGVzY3JpcHRpb246 IEFmYXINCiAgIEFkZGVkOiAyMDA0LTA3LTA2DQogICAlJQ0KICAgVHlwZTogbGFuZ3VhZ2UNCiAg IFN1YnRhZzogYWINCiAgIERlc2NyaXB0aW9uOiBBYmtoYXppYW4NCiAgIEFkZGVkOiAyMDA0LTA3 LTA2DQogICAlJQ0KICAgVHlwZTogbGFuZ3VhZ2UNCiAgIFN1YnRhZzogYWUNCiAgIERlc2NyaXB0 aW9uOiBBdmVzdGFuDQogICBBZGRlZDogMjAwNC0wNy0wNg0KICAgJSUNCiAgIFR5cGU6IGxhbmd1 YWdlDQogICBTdWJ0YWc6IGFyDQogICBEZXNjcmlwdGlvbjogQXJhYmljDQogICBBZGRlZDogMjAw NC0wNy0wNg0KICAgU3VwcHJlc3MtU2NyaXB0OiBBcmFiDQogICBDb21tZW50OiBBcmFiaWMgdGV4 dCBpcyB1c3VhbGx5IHdyaXR0ZW4gaW4gQXJhYmljIHNjcmlwdA0KICAgJSUNCiAgIFR5cGU6IGxh bmd1YWdlDQogICBTdWJ0YWc6IHFhYS4ucXR6DQogICBEZXNjcmlwdGlvbjogUFJJVkFURSBVU0UN CiAgIEFkZGVkOiAyMDA0LTA4LTAxDQogICBDb21tZW50OiBVc2UgcHJpdmF0ZSB1c2UgY29kZXMg aW4gcHJlZmVyZW5jZQ0KICAgICB0byB0aGUgeC0gc2luZ2xldG9uIGZvciBwcmltYXJ5IGxhbmd1 YWdlDQogICBDb21tZW50OiBUaGlzIGlzIGFuIGV4YW1wbGUgb2YgdHdvIGNvbW1lbnRzLg0KICAg JSUNCiAgIFR5cGU6IHNjcmlwdA0KICAgU3VidGFnOiBBcmFiDQogICBEZXNjcmlwdGlvbjogQXJh YmljDQogICBBZGRlZDogMjAwNC0wNy0wNg0KICAgJSUNCiAgIFR5cGU6IHNjcmlwdA0KICAgU3Vi dGFnOiBBcm1uDQogICBEZXNjcmlwdGlvbjogQXJtZW5pYW4NCiAgIEFkZGVkOiAyMDA0LTA3LTA2 DQogICAlJQ0KICAgVHlwZTogc2NyaXB0DQogICBTdWJ0YWc6IEJhbGkNCg0KDQoNClBoaWxsaXBz ICYgRGF2aXMgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQ YWdlIDU3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5 ICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAgRGVzY3JpcHRpb246IEJhbGluZXNl DQogICBBZGRlZDogMjAwNC0wNy0wNg0KICAgJSUNCiAgIFR5cGU6IHNjcmlwdA0KICAgU3VidGFn OiBCYXRrDQogICBEZXNjcmlwdGlvbjogQmF0YWsNCiAgIEFkZGVkOiAyMDA0LTA3LTA2DQogICAl JQ0KICAgVHlwZTogcmVnaW9uDQogICBTdWJ0YWc6IEFBDQogICBEZXNjcmlwdGlvbjogUFJJVkFU RSBVU0UNCiAgIEFkZGVkOiAyMDA0LTA4LTAxDQogICAlJQ0KICAgVHlwZTogcmVnaW9uDQogICBT dWJ0YWc6IEFEDQogICBEZXNjcmlwdGlvbjogQW5kb3JyYQ0KICAgQWRkZWQ6IDIwMDQtMDctMDYN CiAgICUlDQogICBUeXBlOiByZWdpb24NCiAgIFN1YnRhZzogQUUNCiAgIERlc2NyaXB0aW9uOiBV bml0ZWQgQXJhYiBFbWlyYXRlcw0KICAgQWRkZWQ6IDIwMDQtMDctMDYNCiAgICUlDQogICBUeXBl OiByZWdpb24NCiAgIFN1YnRhZzogQVgNCiAgIERlc2NyaXB0aW9uOiAmI3hDNTtsYW5kIElzbGFu ZHMNCiAgIEFkZGVkOiAyMDA0LTA3LTA2DQogICBDb21tZW50czogVGhlIGRlc2NyaXB0aW9uIHNo b3dzIGEgVW5pY29kZSBlc2NhcGUNCiAgICAgZm9yIHRoZSBsZXR0ZXIgQS1yaW5nLg0KICAgJSUN CiAgIFR5cGU6IHJlZ2lvbg0KICAgU3VidGFnOiAwMDENCiAgIERlc2NyaXB0aW9uOiBXb3JsZA0K ICAgQWRkZWQ6IDIwMDQtMDctMDYNCiAgICUlDQogICBUeXBlOiByZWdpb24NCiAgIFN1YnRhZzog MDAyDQogICBEZXNjcmlwdGlvbjogQWZyaWNhDQogICBBZGRlZDogMjAwNC0wNy0wNg0KICAgJSUN CiAgIFR5cGU6IHJlZ2lvbg0KICAgU3VidGFnOiAwMDMNCiAgIERlc2NyaXB0aW9uOiBOb3J0aCBB bWVyaWNhDQogICBBZGRlZDogMjAwNC0wNy0wNg0KICAgJSUNCiAgIFR5cGU6IHZhcmlhbnQNCiAg IFN1YnRhZzogMTkwMQ0KICAgRGVzY3JpcHRpb246IFRyYWRpdGlvbmFsIEdlcm1hbg0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAyMDA1ICAgICAgICAg ICAgICAgW1BhZ2UgNThdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICAgICBvcnRob2dyYXBo eQ0KICAgQWRkZWQ6IDIwMDQtMDktMDkNCiAgIFJlY29tbWVuZGVkLVByZWZpeDogZGUNCiAgIENv bW1lbnQ6IDxzaG93cyBjb250aW51YXRpb24+DQogICAlJQ0KICAgVHlwZTogdmFyaWFudA0KICAg U3VidGFnOiAxOTk2DQogICBEZXNjcmlwdGlvbjogR2VybWFuIG9ydGhvZ3JhcGh5IG9mIDE5OTYN CiAgIEFkZGVkOiAyMDA0LTA5LTA5DQogICBSZWNvbW1lbmRlZC1QcmVmaXg6IGRlDQogICAlJQ0K ICAgVHlwZTogdmFyaWFudA0KICAgU3VidGFnOiBib29udA0KICAgRGVzY3JpcHRpb246IEJvb250 bGluZw0KICAgQWRkZWQ6IDIwMDMtMDItMTQNCiAgIFJlY29tbWVuZGVkLVByZWZpeDogZW4NCiAg ICUlDQogICBUeXBlOiB2YXJpYW50DQogICBTdWJ0YWc6IGdhdWxpc2gNCiAgIERlc2NyaXB0aW9u OiBHYXVsaXNoDQogICBBZGRlZDogMjAwMS0wNS0yNQ0KICAgUmVjb21tZW5kZWQtUHJlZml4OiBj ZWwNCiAgICUlDQogICBUeXBlOiBncmFuZGZhdGhlcmVkDQogICBUYWc6IGFydC1sb2piYW4NCiAg IERlc2NyaXB0aW9uOiBMb2piYW4NCiAgIEFkZGVkOiAyMDAxLTExLTExDQogICBDYW5vbmljYWw6 IGpibw0KICAgRGVwcmVjYXRlZDogMjAwMy0wOS0wMg0KICAgJSUNCiAgIFR5cGU6IGdyYW5kZmF0 aGVyZWQNCiAgIFRhZzogZW4tR0Itb2VkDQogICBEZXNjcmlwdGlvbjogRW5nbGlzaCwgT3hmb3Jk IEVuZ2xpc2ggRGljdGlvbmFyeSBzcGVsbGluZw0KICAgQWRkZWQ6IDIwMDMtMDctMDkNCiAgICUl DQogICBUeXBlOiBncmFuZGZhdGhlcmVkDQogICBUYWc6IGktYW1pDQogICBEZXNjcmlwdGlvbjog J0FtaXMNCiAgIEFkZGVkOiAxOTk5LTA1LTI1DQogICAlJQ0KICAgVHlwZTogZ3JhbmRmYXRoZXJl ZA0KICAgVGFnOiBpLWJubg0KICAgRGVzY3JpcHRpb246IEJ1bnVuDQogICBBZGRlZDogMTk5OS0w NS0yNQ0KICAgJSUNCiAgIFR5cGU6IHJlZHVuZGFudA0KICAgVGFnOiBhei1BcmFiDQogICBEZXNj cmlwdGlvbjogQXplcmJhaWphbmkgaW4gQXJhYmljIHNjcmlwdA0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI4LCAyMDA1ICAgICAgICAgICAgICAgW1BhZ2Ug NTldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAg ICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICBBZGRlZDogMjAwMy0wNS0zMA0KICAgJSUN CiAgIFR5cGU6IHJlZHVuZGFudA0KICAgVGFnOiBhei1DeXJsDQogICBEZXNjcmlwdGlvbjogQXpl cmJhaWphbmkgaW4gQ3lyaWxsaWMgc2NyaXB0DQogICBBZGRlZDogMjAwMy0wNS0zMA0KICAgJSUN Cg0KICAgICAgICAgICAgICAgICBGaWd1cmUgNzogRXhhbXBsZSBvZiB0aGUgUmVnaXN0cnkgRm9y bWF0DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIE9jdG9iZXIgMjgsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSA2MF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg QXByaWwgMjAwNQ0KDQoNCkludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQNCg0KICAgVGhl IElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBv ZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRo YXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24g b3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBv ciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBt aWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhh dCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkg c3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNw ZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4 IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUg SUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJl IG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8g b2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAg IHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlz DQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUg SVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0KDQogICBUaGUg SUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRp b24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9y IG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0 aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVh c2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGll dGYub3JnLg0KDQoNCkRpc2NsYWltZXIgb2YgVmFsaWRpdHkNCg0KICAgVGhpcyBkb2N1bWVudCBh bmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQog ICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUv U0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVS TkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVA0KICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBE SVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELA0KICAgSU5DTFVESU5H IEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQ0KICAg SU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElN UExJRUQNCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEg UEFSVElDVUxBUiBQVVJQT1NFLg0KDQoNCkNvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJp Z2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuICBUaGlzIGRvY3VtZW50IGlzIHN1 YmplY3QNCiAgIHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFp bmVkIGluIEJDUCA3OCwgYW5kDQogICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBh dXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQoNCkFja25vd2xlZGdtZW50DQoNCiAg IEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRl ZCBieSB0aGUNCiAgIEludGVybmV0IFNvY2lldHkuDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgIEV4cGlyZXMgT2N0b2JlciAyOCwgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDYxXQ0K DA0K ------_=_NextPart_001_01C54A9D.F3732CE6 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C54A9D.F3732CE6-- From ltru-bounces@lists.ietf.org Tue Apr 26 16:32:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWje-0002wT-LF; Tue, 26 Apr 2005 16:32:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWjd-0002wO-Of for ltru@megatron.ietf.org; Tue, 26 Apr 2005 16:32:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14706 for ; Tue, 26 Apr 2005 16:32:43 -0400 (EDT) Received: from irvbhxw01.quest.com ([12.106.87.68] helo=irvbhxw02.prod.quest.corp) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQWw8-0006ow-JB for ltru@ietf.org; Tue, 26 Apr 2005 16:45:42 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 13:32:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] -01 nits Date: Tue, 26 Apr 2005 13:32:34 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0B2C4CD8@irvmbxw01.quest.com> Thread-Topic: [Ltru] -01 nits Thread-Index: AcVKnhLvPLS6EX4EQr+klz3ycuBQoQAAOIjw From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 26 Apr 2005 20:32:34.0819 (UTC) FILETIME=[14259530:01C54A9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hm... I'm getting dupes of various messages on this list. This just arrived = *after* I sent a response to it, a remarkable occurrence normally. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Frank Ellermann > Sent: 2005?4?25? 20:13 > To: ltru@ietf.org > Subject: [Ltru] -01 nits >=20 > Hi, some observations in draft -01 in no particular order: >=20 > * [7] (Unicode 4) is not used. > Please delete this normative reference, [6] is good enough. >=20 > * In chapter 2.1 "UTF-16LE" is not explained. > Please add [RfC 2781] as informative reference. >=20 > * [13] (IETF-ICANN MoU about IANA) > Please delete this "normative" reference to an MoU-FYI. > Maybe use [RfC 2028] (BCP 11) as a reference to explain "IANA", > you already have it as [10] elsewhere. >=20 > * [16] (RfC 3978) is not used. > Please delete this normative reference, the boilerplates > work without it. >=20 > * In chapter 3.1 replace the URL of XML 1.0 3rd ed. by the > generic URL of the latest XML 1.0 edition. >=20 > * Several "2-character code", "3-character code", "4-character = subtags": > Using "alpha-2 code" etc. would be clearer and shorter where the = ABNF > dictates 2ALPHA etc. >=20 > * There's still a *("-" extlang) in the ABNF, it should be at most one > ["-" extlang]. >=20 > * In chapter 2.1.1: "In practice, this limits most tags to a sequence > of four subtags, and thus a length of 35 (excluding any extensions": > This limit is 8+(1+4)+(1+3)+(1+8)=3D 26 without extlang and 4 = subtags. > With extlang it's only 25 =3D 3+(1+3)+(1+4)+(2+3)+(1+8). >=20 > * In chapter 2.1.1: "Any such limitation MUST be clearly documented, > and such documentation SHOULD include the disposition of any longer > tags (for example, whether an error value is generated or the > language tag is truncated). If truncation is permitted it SHOULD > NOT permit a subtag to be divided." >=20 > Proposed new text: "Any limitation SHOULD be clearly documented. > Tags SHOULD NOT be truncated, but removing complete subtags right > to left MAY be permitted." >=20 > * In chapter 2.2.1: 7. The single character subtag 'i' is used by > some grandfathered tags (see Section 2.2.8) such as "i-klingon" > and "i-bnn". > Please replace the "almost" deprecated i-klingon by i-default. >=20 > * In chapter 2.2.2: Please replace all "subtags" by "subtag". > Please remove "3. There MAY be any additional number of > extended language subtags." At most one extlang, otherwise > it doesn't fly with RfC 2231 / 2047. >=20 > * In chapter 2.2.7: "Users who wished to utilize SIL Ethnologue". > Please delete this example, it muddies the water for ISO 639-3. >=20 > * The ABNF layout in 3.1 is ugly, the main ABNF is better, please > use the same xml2rfc trick (artwork ?) as in 2.1: >=20 > registry =3D record *( "%%" CRLF record ) > record =3D 1*( field-name *SP ":" *SP field-body CRLF ) > field-name =3D 1*( ALPHA / DIGIT / "-" ) > field-body =3D *( ASC-char / LWSP ) > ASC-char =3D %x21-25 / %x27-7E / UNI-char ; AMPERSAND is %x26 > UNI-char =3D "&#x" 2*6HEXDIG ";" >=20 > This fixes the reported "no %% in the first / last line" problem. > The minimal length of a field-name should be one, not zero. > It also replaces the undefined NUM by DIGIT, and %x2D by "-". >=20 > In theory a field-name starting or ending with a "-" would be a > bad idea, and a DIGIT in a field-name is also strange, but OTOH > we don't want to reinvent "ldh-string" for a known set of names. >=20 > * Please delete the File-Date example or get rid of the first "%%": > %% > File-Date: 2004-06-28 > %% >=20 > * Another proposal for the registry ABNF: >=20 > registry =3D record *( "%%" CRLF record ) > record =3D 1*( field CRLF ) > field =3D type / timestamp / reference / explanation > type =3D ( subtagttype / tagtype ) 1*SP tagtext > subtagtype =3D "Language:" / "Extlang:" / "Script:" > / "Region:" / "Variant:" > tagtype =3D "Grandfathered:" / "Redundant:" > timestamp =3D ( "File-Date:" / "Added:" / "Deprecated:" ) 1*SP = date > reference =3D ( "Canonical:" / "Suppress-Script:" > / "Recommended-Prefix:" ) 1*SP tagtext > explanation =3D ( "Description:" / "Comment:" ) 1*SP text > date =3D 4DIGIT "-" 2DIGIT "-" 2DIGIT ; see RfC 3339 > tagtext =3D 1*( ALPHA / DIGIT / "-" ) ; note no WSP > text =3D *( ASC-char / LWSP ) ; note folding WSP > ASC-char =3D %x21-25 / %x27-7E / UNI-char ; AMPERSAND is %x26 > UNI-char =3D "&#x" 2*6HEXDIG ";" >=20 > This is quite different from the old ABNF, no more SP before the > COLON, at least one SP after the COLON, no "folding" for a date or > tagtext, "folding" only for a (long) Description: or a Comment:, > no UNI-char or special char in tagtext, a date syntax that needs > no further explanation (one example will do). >=20 > Based on this ABNF chapter 3.1 could be much shorter and clearer. > It's not more necessary to dig through 3.1 to find all field names. >=20 > IMHO you could submit snapshots of complete drafts more often, > and you also don't need Randy or Martin for a future -02, etc. >=20 > Bye, Frank >=20 >=20 >=20 >=20 > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 17:42:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQXpV-0004y1-2f; Tue, 26 Apr 2005 17:42:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWiq-0002u4-7m for ltru@megatron.ietf.org; Tue, 26 Apr 2005 16:31:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14640 for ; Tue, 26 Apr 2005 16:31:53 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DQWvK-0006nQ-Ht for ltru@ietf.org; Tue, 26 Apr 2005 16:44:52 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Tue, 26 Apr 2005 13:28:26 -0700 Message-ID: <006d01c54a9e$f8a10ec0$107e3009@sanjose.ibm.com> From: "Mark Davis" To: "Mark Davis" , , "Frank Ellermann" Subject: Re: [Ltru] -01 nits Date: Tue, 26 Apr 2005 13:31:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA14640 X-Mailman-Approved-At: Tue, 26 Apr 2005 17:42:51 -0400 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org My mail is having trouble getting through. =E2=80=8EMark ----- Original Message -----=20 From: "Mark Davis" To: ; "Frank Ellermann" Sent: Tuesday, April 26, 2005 09:05 Subject: Re: [Ltru] -01 nits > > > * In chapter 2.1.1: "Any such limitation MUST be clearly documented, > > and such documentation SHOULD include the disposition of any longer > > tags (for example, whether an error value is generated or the > > language tag is truncated). If truncation is permitted it SHOULD > > NOT permit a subtag to be divided." > > > > Proposed new text: "Any limitation SHOULD be clearly documented. > > Tags SHOULD NOT be truncated, but removing complete subtags right > > to left MAY be permitted." > > I don't see why we should change this. I don't yet see any reason to al= low > protocols that claim conformance to this RFC to truncate without any > documentation of that fact. > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 17:42:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQXpV-0004yO-8G; Tue, 26 Apr 2005 17:42:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQXml-0004Bg-8U for ltru@megatron.ietf.org; Tue, 26 Apr 2005 17:40:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20216 for ; Tue, 26 Apr 2005 17:40:00 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DQXzF-0008EE-JH for ltru@ietf.org; Tue, 26 Apr 2005 17:53:00 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Tue, 26 Apr 2005 14:36:28 -0700 Message-ID: <013b01c54aa8$7b259970$107e3009@sanjose.ibm.com> From: "Mark Davis" To: , "Frank Ellermann" References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org><025901c548a8$5868dca0$030aa8c0@DEWELL> <426B66AA.4580@xyzzy.claranet.de> Subject: Re: [Ltru] Re: 003 vs. 021 Date: Tue, 26 Apr 2005 14:39:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA20216 X-Mailman-Approved-At: Tue, 26 Apr 2005 17:42:51 -0400 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I agree, 021 is ok. By the way, in CLDR we don't bother with 003, since it doesn't fit with t= he other containment relations. See: http://www.unicode.org/cldr//data/diff/supplemental/supplemental.html#ter= ritory_containment__un_m____ We also supplement the UN M.49 codes with ZZ (a private use region code),= so that we get 3 containment levels there. We've requested a regular numeric code for that, but at this point a private use code is as good as we can = do. =E2=80=8EMark ----- Original Message -----=20 From: "Frank Ellermann" To: Sent: Sunday, April 24, 2005 02:28 Subject: [Ltru] Re: 003 vs. 021 > Doug Ewell wrote: > > > I disagree that 021 Northern America is an "economic > > grouping." > > ACK, 021 is okay. > > > I request that we use objective criteria for allowing and > > forbidding codes, not subjective labels like "obscure" and > > "dubious." > > So what are your objective criteria to include 003 ? There's > a table starting in line 149 above "001 world" and ending in > line 322 below "061 Polynesia". > > The next table "Selected economic and other groupings" isn't > what we want. Another table starts in line 382, its first > region is "002 Africa", near line 2534 within this table the > "Developed and developing regions" begin. The last region > above the h3-header is "876 Wallis and Futuna Islands". > > 003 is only mentioned in a footnote at the moment. Maybe they > found that 419 makes more sense, it certainly does for me. > > Please don't argue with Navassa Island, it's uninhabited, and > it belongs to UM. Guantanamo Bay, maybe apa-003, what else ? > > Oh no, is this about the Virgin Islands ? Major havoc for many > confused users trying 003 instead of 021 or vice versa only for > the Virgin Islands ? They could use en-029, en-VI, or en-VG :-( > > While we're at it, how do you exclude region numbers covered by > ISO 3166-1 country codes ? Addison proposed to add the numbers > to the codes somehow, so that a future tag reviewer can do his > "same piece of land" magic when necessary. I somehow doubt that > ISO and the UN are always in perfect synchronization, not only > for the three wellknown exceptions TW, 830, and 833. Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 20:29:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQaQV-0000xL-Mt; Tue, 26 Apr 2005 20:29:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQaQU-0000we-7P for ltru@megatron.ietf.org; Tue, 26 Apr 2005 20:29:14 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07271 for ; Tue, 26 Apr 2005 20:29:11 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DQaL3-0006ee-L8 for ltru@lists.ietf.org; Wed, 27 Apr 2005 02:23:37 +0200 Received: from 212.82.251.220 ([212.82.251.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Apr 2005 02:23:37 +0200 Received: from nobody by 212.82.251.220 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Apr 2005 02:23:37 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 27 Apr 2005 02:22:49 +0200 Organization: Lines: 134 Message-ID: <426EDB58.6084@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0B2C4CB7@irvmbxw01.quest.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.220 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: -01 nits X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: [IETF-ICANN MoU about IANA] > ~sigh~ I put this in at someone's urging and can replace it. If you like [RfC 2860] you could also move it to "informative". BTW, have you ever tested with xml2rfc ? ["2-character code" vs. "alpha-2 code"] > I replaced all of these with the number spelled out (e.g. > "two character" instead of "2-character"). Using plain > English is preferable (to me) to using more mechanical > looking text. Plain English is fine, I also say byte when I mean octet, etc. But you said that you're an "Unicadet", so I'm a bit surprised that you prefer "character" when it's only A..Za..z, also known as ALPHA. >> it should be at most one ["-" extlang]. > No, since there is no restriction on how many extlangs there > can be currently and the grammar permits them That's not possible for the Internet. Maybe delete ISO 639-3 and eliminate extlang completely if this scheme doesn't work for language tags, or if it's unclear at the moment. OTOH Peter's example indicates that they might get away with at most two extlang as in aaa-bbb-ccc, and that's of course okay, the worst "normal" case would then be length 29 instead of 26. > I am a bit loathe to remove the repeating aspect (no matter > that it greatly complicates processing). I can understand that you don't like to limit it, and besides RfC 2231 is a PITA. If you'd get an ACK from Bruce or Ned for the "unlimited extlang" it's okay. > (I would favor limiting them to one occurrence). That's apparently a hot issue for draft -02 > thus a maximum length of 26 characters (excluding any > extensions or private use sequences). This is because > subtags are limited to a length of eight characters and the > extlang, script, and region subtags are limited to even > fewer characters. Yes, that's clear. 29 for two extlangs won't be a showstopper. [MUST be clearly documented] > I'd prefer to keep the MUSTard on the length limitation (it > isn't that onerous an item, if you think about it: anything > that limits the length will have to say what the limit is, > no?). No, RfC 2231 is unfortunately not that clear, you have to read it in conjunction with RfC 2047 to find the hard limit 76, then you need the worst case of a charset name in the IANA registry, plus 8 =?*?Q??=, some calculations for the =?*?B??= case, and a worst case of a header field in Usenet (maybe), and finally the result is _not_ clear, it depends on too many variables. You cannot say "MUST be clearly documented" if you know a case where that's not true. 3066bis wants to be compatible with RfC 2231 / 2047. But that nit was more about "it SHOULD NOT permit a subtag to be divided": I wanted to propose a clearer "if you truncate tags remove complete subtags right to left". Apparently my proposal wasn't clear, Mark thought that I plan to maim poor tags, actually I wanted to protect them as far as possible ;-) [replace the "almost" deprecated i-klingon by i-default] > i-klingon was chosen in part because it is deprecated, not > just because it was grandfathered. It's a bad example because it's "almost" deprecated. I didn't know that it should be replaced by "tlh" because the IANA page doesn't say so, and the last time I've seen it as an example on a new W3C page was this year. and it was in an argument with Bruce and Ned about RfC 2231, the status of "i-klingon" cost me a point in this debate. [Ethnologue] > I need a replacement example. Want to suggest one? No idea. Maybe fr-US-x-cajun if it has no proper code. > Here is my cleanup: [...] > Validated the results cleanly. Better. I'd avoid "shouting" (upper case) where possible, but that's only a matter of taste. [ABNF variant eumerating field types ; date / tagtext / text] > That's really different and probably quite correct. But I'm > not going to create a big ugly ABNF-and-full-text-edit before > sending draft-01 off to I-D land. Let's dicuss for draft-02. Sure, I thought that's what I do. But if you have fixed some minor points before submitting -01 it's also fine, I only have to replace pre-01 by the real -01 in my public I-D collection. > In addition: we are behind schedule and I really REALLY want > to finish this work. Of course we are, it's the purpose of this WG to solve a few real problems, and Doug can't invent "Suppress-Scripts" with a random generator. BTW, there's a problem in pre-01 about "Supress-Script" (4.2): First you had "MUST NOT ... unless ...". Then I wanted a short "SHOULD NOT ..." without "unless". Then Randy decided that the consensus is something with "MUST NOT". But now you have a "SHOULD NOT ... unless ...", that's exactly the opposite of what Randy said, it's also not my "SHOULD NOT". You also didn't add the rationale for this "MUSTard" (I like this pun :-) i.e. existing RfC 3066 content and tools. > I recognize one substantive issue that we need to resolve, > namely the handling of country code changes. That's also about "canonical" and "deprecated". As it is we'd get a more or less nice registry at date B (ignoring four lost regions after date-A), but it would soon deteriorate again for some future 3166-1 codes. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 20:57:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQarm-0004u3-UO; Tue, 26 Apr 2005 20:57:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQark-0004tv-PX for ltru@megatron.ietf.org; Tue, 26 Apr 2005 20:57:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09080 for ; Tue, 26 Apr 2005 20:57:23 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQb4H-0004mU-7c for ltru@ietf.org; Tue, 26 Apr 2005 21:10:23 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 17:57:12 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Apr 2005 17:57:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] Re: -01 nits Date: Tue, 26 Apr 2005 17:57:12 -0700 Message-ID: Thread-Topic: [Ltru] Re: -01 nits Thread-Index: AcVKwDNCbLCpPaYSTfCCifga5FsinwAAflGQ From: "Peter Constable" To: X-OriginalArrivalTime: 27 Apr 2005 00:57:12.0807 (UTC) FILETIME=[0C2A4770:01C54AC4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Frank Ellermann > > No, since there is no restriction on how many extlangs there > > can be currently and the grammar permits them >=20 > That's not possible for the Internet. RFC 3066 gave no upper bound on the number of subtags that might occur in a tag, though in practice we knew it was constrained. Clearly RFC 3066 permitted extremely long (even infinite) tags, and equally clearly that's not possible for the Internet, but also equally clearly such tags were not going to occur (unless generated by a rogue process, which by definition flaunts both assumed and explicit conventions). It's not clear to me why there's a problem if our ABNF doesn't impose an upper bound on the number of extlang subtags at this point. We know that we have in mind constraints that will limit how many can be used in practice (it would be constrained by macrolanguage mappings in 639-3), and we will have an opportunity while developing 3066ter to define whatever further constraints we might wish. > OTOH Peter's example indicates that they might get away with at > most two extlang as in aaa-bbb-ccc, and that's of course okay, > the worst "normal" case would then be length 29 instead of 26. My point was that I cannot guarantee at this time that 639-3 might not have two or three or n levels of macrolanguage mappings, though I think it's extremely unlikely there would be more than a few levels, and I don't have any specific reason to believe that there would ever be more than one level. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 21:30:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQbO4-0001eo-EX; Tue, 26 Apr 2005 21:30:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQbO2-0001dt-Og for ltru@megatron.ietf.org; Tue, 26 Apr 2005 21:30:47 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12185 for ; Tue, 26 Apr 2005 21:30:42 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DQbIe-0003Wh-RH for ltru@lists.ietf.org; Wed, 27 Apr 2005 03:25:12 +0200 Received: from 212.82.251.220 ([212.82.251.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Apr 2005 03:25:12 +0200 Received: from nobody by 212.82.251.220 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Apr 2005 03:25:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 27 Apr 2005 03:28:57 +0200 Organization: Lines: 19 Message-ID: <426EEAD9.60C8@xyzzy.claranet.de> References: <4A7C6FA2AB31194E80E13FE585F6A21292A5EA@EVS-EC1-NODE1.surrey.ac.uk> 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.220 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: ISO 3166-1 DIS ballot X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org L.Gillam wrote: > Code elements that the ISO 3166/MA has altered or deleted > should not be reallocated during a period of at least fifty > years after the change. The exact period is determined in > each case on the basis of the importance of the extent to > which the former code element was used. In other words 3066bis draft -01 should work without problems at least until date A plus 50 years (2038). And maybe we can improve this situation in draft -02 with a new "canonical" rule following 3166-1 as long as possible - until the registry is finally forced to take the emergency exit "UN number". Not bad. If the future Internet users really hate it they are free to invent a new 3066ter where all old 3166-1 codes are frozen and deprecated and replaced by UN numbers. And in that case I'd want an "I told you so" on my grave. ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 22:16:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQc6h-0000Au-RJ; Tue, 26 Apr 2005 22:16:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQc6g-0000Ap-M6 for ltru@megatron.ietf.org; Tue, 26 Apr 2005 22:16:54 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14892 for ; Tue, 26 Apr 2005 22:16:52 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DQc1P-0007gm-WD for ltru@lists.ietf.org; Wed, 27 Apr 2005 04:11:28 +0200 Received: from 212.82.251.220 ([212.82.251.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Apr 2005 04:11:27 +0200 Received: from nobody by 212.82.251.220 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Apr 2005 04:11:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 27 Apr 2005 04:13:12 +0200 Organization: Lines: 45 Message-ID: <426EF538.C32@xyzzy.claranet.de> References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org><025901c548a8$5868dca0$030aa8c0@DEWELL> <426B66AA.4580@xyzzy.claranet.de> <013b01c54aa8$7b259970$107e3009@sanjose.ibm.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.220 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis wrote: > in CLDR we don't bother with 003, since it doesn't fit with > the other containment relations. See: > http://www.unicode.org/cldr//data/diff/supplemental/supplemental.html#territory_containment__un_m____ Apparently you have neither 419 nor 003. But the LTRU draft mentions 419. Actually both 419 and 003 are somewhat dubious, at most one of them could be okay, but none of them is better. Where's the difference between es-019 and es-419 ? If it's about immigrants from Cuba to Florida, Mexico to California, etc., then it's es-CU, es-MX, es-019, or es-US, and es-419 (or es-003) are not strictly necessary. Now I don't doubt that Doug must register 419 under the rules, and maybe even 003. But it's apparently no good idea to use these numbers in an example, if they are not supported by CLDR. > We also supplement the UN M.49 codes with ZZ (a private use > region code), so that we get 3 containment levels there. That's a strange idea, The UM territories have nothing to do with AQ, and Navassa is a Carribean island, not Oceania. And IO is also unrelated to Oceania, that's Diego Garcia etc. in the Indian Ocean. I'd add IO near the Seychelles. You have SC as Eastern Africa, I'd probably say Western Asia. You also have Cyprus as Western Asia, but from my POV (I'm not burdened by any "Middle East" concept) it's Europe. It's even a member of the EU, at least the southern part. For Turkey you could toss a coin, the main part is Asia. OTOH Georgia is Europe, not Asia. Actually Eurasia is one continent, and arguments where it's not require a separate continent for India. > We've requested a regular numeric code for that, but at this > point a private use code is as good as we can do. You've requested a number from the UN for AQ ? This will cause mass suicides. IIRC CC or CX or both also have nothing to do with Oceania, one of them is near to IN or MM (?) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Apr 26 23:36:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQdLt-0002mX-5t; Tue, 26 Apr 2005 23:36:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQdLr-0002mS-WC for ltru@megatron.ietf.org; Tue, 26 Apr 2005 23:36:40 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20333 for ; Tue, 26 Apr 2005 23:36:36 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DQdG6-00057w-8p for ltru@lists.ietf.org; Wed, 27 Apr 2005 05:30:42 +0200 Received: from 212.82.251.220 ([212.82.251.220]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Apr 2005 05:30:42 +0200 Received: from nobody by 212.82.251.220 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Apr 2005 05:30:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 27 Apr 2005 05:32:37 +0200 Organization: Lines: 52 Message-ID: <426F07D5.13E1@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.220 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] aaa-bbb-ccc-ddd-eee-fff-ggg-hhh-Latn-US-boont (was: -01 nits) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable wrote: > RFC 3066 gave no upper bound on the number of subtags that > might occur in a tag And it was written after RfC 2231. Now RfC 3066 is broken, we try to fix it. With an ugly kludges like "Suppress-Script" this could apparently work, but *("-" extlang) is impossible. > RFC 3066 permitted extremely long (even infinite) tags And RfC 2231 cum 2047 doesn't allow this => RfC 3066 is FUBAR for more than one reason. BTW, the same is true for RfC 2231. > It's not clear to me why there's a problem if our ABNF > doesn't impose an upper bound on the number of extlang > subtags at this point. Implementors use the ABNF to write code. They want limits and worst cases for their buffers and tables, otherwise they make them up on the fly, "anything longer than xxx-Ssss-nnn must be nonsense, let's say 16 to be sure and ignore all longer tags". That's exactly how I'd implement it, if it's something that generates 2231 / 2047 encoded words in header fields. Or if it's a mail2news gateway desperately trying to get it right for both sides - okay, maybe I'd add a dummy =?us-ascii?Q??= to avoid dubious cases of "refolding" for news header fields (if that's allowed, I haven't checked 2047). > we have in mind constraints that will limit how many can be > used in practice (it would be constrained by macrolanguage > mappings in 639-3), and we will have an opportunity while > developing 3066ter to define whatever further constraints we > might wish. Then we could reserve a *2("-" extlang) now, and let 3066ter reduce it to ["-" extlang] if possible, or remove the complete idea if ISO 639-3 wants more. Maybe Debbie's alpha-4 codes are better for the Internet. IMHO anything is better than *("-" extlang). Even registering all 7000+ Ethnologue codes manually is better than *("-" extlang). > I cannot guarantee at this time that 639-3 might not have > two or three or n levels of macrolanguage mappings But "we" (TINW) can guarantee that something with more than say two levels is dead on arrival, maybe that helps somehow in your ISO 639-3 debates (?) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Apr 27 01:36:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQfEA-0002h6-IC; Wed, 27 Apr 2005 01:36:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQfE8-0002gq-Cd for ltru@megatron.ietf.org; Wed, 27 Apr 2005 01:36:48 -0400 Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27595 for ; Wed, 27 Apr 2005 01:36:41 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050427053610.SJZW13270.mta11.adelphia.net@DEWELL> for ; Wed, 27 Apr 2005 01:36:10 -0400 Message-ID: <008401c54aea$b91fd140$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050426202910.XBHN28811.mta8.adelphia.net@megatron.ietf.org> Date: Tue, 26 Apr 2005 22:34:02 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: -01 nits X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > * Several "2-character code", "3-character code", "4-character subtags": > Using "alpha-2 code" etc. would be clearer and shorter where the ABNF > dictates 2ALPHA etc. Whereupon Addison proceeded to replace all instances of "2-character code" with "two character code," and similarly for 3 and 4. I don't like this change. I find the numbers in "2-character" or "2-letter" or "alpha-2" much easier to pick out of a sea of text than the English word "two." My college journalism professors are tsk-tsking at me for saying this ("always spell out numbers ten and under"), but this is a technical document, not the Times. I also miss the hyphen between "two" (or "2") and "character." Furthermore, I don't think it's what Frank had in mind. I think he just meant to have the varying uses of "alpha-2," "2-character," etc. normalized to a single compact term, not to have the word "two" spelled out. This isn't a showstopper for me, but the technical writer in me doesn't like it. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Apr 27 02:25:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQfyo-0001wc-Tu; Wed, 27 Apr 2005 02:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQfyn-0001wD-VT for ltru@megatron.ietf.org; Wed, 27 Apr 2005 02:25:02 -0400 Received: from mta13.adelphia.net (mta13.mail.adelphia.net [68.168.78.44]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26935 for ; Wed, 27 Apr 2005 02:25:00 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050427062430.LSNU4191.mta13.adelphia.net@DEWELL> for ; Wed, 27 Apr 2005 02:24:30 -0400 Message-ID: <008d01c54af1$aa48d200$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050427021727.UOGN27459.mta2.adelphia.net@megatron.ietf.org> Date: Tue, 26 Apr 2005 23:23:44 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I'm not really picking Frank as the target for all my posts, it just seems that way. :-) Frank Ellermann wrote: > Apparently you have neither 419 nor 003. But the LTRU draft > mentions 419. Actually both 419 and 003 are somewhat dubious, > at most one of them could be okay, but none of them is better. 419 fits cleanly into the hierarchy: 019 (Americas) comprises 021 (everything north of the U.S.-Mexico border and the Gulf of Mexico) and 419 (everything south). I don't see anything "dubious" about that. 003 is the one that doesn't fit, and I would be happy to remove it if there is a consensus that to do so would not be arbitrary. I've already mentioned that UNSD appears to have revised their list of macrogeographical codes in January, while I wasn't looking :-(. I need to go through the list again, so the registry that comes out this weekend will reflect the latest version. In the meantime, can we get a show of hands with regard to keeping 003 vs. throwing it out? Without mixing in any other issues, please? > Where's the difference between es-019 and es-419 ? If it's > about immigrants from Cuba to Florida, Mexico to California, > etc., then it's es-CU, es-MX, es-019, or es-US, and es-419 (or > es-003) are not strictly necessary. There's a lot of Spanish spoken here in Southern California, and it's not quite the same as es-MX, even though the speakers are primarily Mexican or of Mexican descent. And it's definitely not the same as Florida Spanish (which isn't quite es-CU) or New York Spanish (which isn't quite es-PR). -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Apr 27 09:57:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQn2a-00032j-Cx; Wed, 27 Apr 2005 09:57:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQn2Z-00032W-JL for ltru@megatron.ietf.org; Wed, 27 Apr 2005 09:57:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12618 for ; Wed, 27 Apr 2005 09:57:21 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DQnFA-0003yi-RK for ltru@ietf.org; Wed, 27 Apr 2005 10:10:28 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Wed, 27 Apr 2005 06:49:43 -0700 Message-ID: <029c01c54b31$02f357b0$107e3009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <20050427021727.UOGN27459.mta2.adelphia.net@megatron.ietf.org> <008d01c54af1$aa48d200$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: 003 vs. 021 Date: Wed, 27 Apr 2005 06:57:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA12618 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > In the meantime, can we get a show of hands with regard to keeping 003 > vs. throwing it out? Don't remove it. =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Tuesday, April 26, 2005 23:23 Subject: [Ltru] Re: 003 vs. 021 > I'm not really picking Frank as the target for all my posts, it just > seems that way. :-) > > Frank Ellermann wrote: > > > Apparently you have neither 419 nor 003. But the LTRU draft > > mentions 419. Actually both 419 and 003 are somewhat dubious, > > at most one of them could be okay, but none of them is better. > > 419 fits cleanly into the hierarchy: 019 (Americas) comprises 021 > (everything north of the U.S.-Mexico border and the Gulf of Mexico) and > 419 (everything south). I don't see anything "dubious" about that. > > 003 is the one that doesn't fit, and I would be happy to remove it if > there is a consensus that to do so would not be arbitrary. > > I've already mentioned that UNSD appears to have revised their list of > macrogeographical codes in January, while I wasn't looking :-(. I need > to go through the list again, so the registry that comes out this > weekend will reflect the latest version. > > In the meantime, can we get a show of hands with regard to keeping 003 > vs. throwing it out? Without mixing in any other issues, please? > > > Where's the difference between es-019 and es-419 ? If it's > > about immigrants from Cuba to Florida, Mexico to California, > > etc., then it's es-CU, es-MX, es-019, or es-US, and es-419 (or > > es-003) are not strictly necessary. > > There's a lot of Spanish spoken here in Southern California, and it's > not quite the same as es-MX, even though the speakers are primarily > Mexican or of Mexican descent. And it's definitely not the same as > Florida Spanish (which isn't quite es-CU) or New York Spanish (which > isn't quite es-PR). > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Apr 27 10:54:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQnw5-0004PO-6T; Wed, 27 Apr 2005 10:54:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQnw3-0004PG-Uh for ltru@megatron.ietf.org; Wed, 27 Apr 2005 10:54:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21907 for ; Wed, 27 Apr 2005 10:54:41 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQo8g-0006UB-Ta for ltru@ietf.org; Wed, 27 Apr 2005 11:07:50 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Apr 2005 07:54:30 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Apr 2005 07:54:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 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] aaa-bbb-ccc-ddd-eee-fff-ggg-hhh-Latn-US-boont (was: -01 nits) Date: Wed, 27 Apr 2005 07:54:29 -0700 Message-ID: Thread-Topic: [Ltru] aaa-bbb-ccc-ddd-eee-fff-ggg-hhh-Latn-US-boont (was: -01 nits) Thread-Index: AcVK2rH/DBng0q+UR2mSH7aG9tbbawAXZANg From: "Peter Constable" To: X-OriginalArrivalTime: 27 Apr 2005 14:54:30.0797 (UTC) FILETIME=[045733D0:01C54B39] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > Then we could reserve a *2("-" extlang) now, and let 3066ter > reduce it to ["-" extlang] if possible, or remove the complete > idea if ISO 639-3 wants more. I think *n("-" extlang) where 2 <=3D n <=3D 4 would be find for now. I = don't think we should remove this. =20 > > I cannot guarantee at this time that 639-3 might not have > > two or three or n levels of macrolanguage mappings >=20 > But "we" (TINW) can guarantee that something with more than say > two levels is dead on arrival... Sure "we" can do that; I'm not opposed to it.=20 > maybe that helps somehow in your > ISO 639-3 debates (?) So far, this hasn't come up for debate, actually. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Apr 27 11:00:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQo1a-0005cV-JB; Wed, 27 Apr 2005 11:00:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQo1Z-0005cQ-Ge for ltru@megatron.ietf.org; Wed, 27 Apr 2005 11:00:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22437 for ; Wed, 27 Apr 2005 11:00:22 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DQoEB-0006f5-Q1 for ltru@ietf.org; Wed, 27 Apr 2005 11:13:31 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Wed, 27 Apr 2005 07:52:48 -0700 Message-ID: <02de01c54b39$d38c8d30$107e3009@sanjose.ibm.com> From: "Mark Davis" To: , "Frank Ellermann" References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org><025901c548a8$5868dca0$030aa8c0@DEWELL><426B66AA.4580@xyzzy.claranet.de><013b01c54aa8$7b259970$107e3009@sanjose.ibm.com> <426EF538.C32@xyzzy.claranet.de> Subject: Re: [Ltru] Re: 003 vs. 021 Date: Wed, 27 Apr 2005 08:00:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA22437 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org First, I must apologize; we actually do 'bother with 003'. I misspoke. We don't concentrate on it, because we focus on translating the items that d= o follow a smooth 3-level breakdown. But we do support it. >Where's the difference between es-019 and es-419? It is whatever the difference is between "Spanish as used in the Americas= " and "Spanish as used in Latin America and the Caribbean" -- thus the lat= ter would exclude any variants that are only found in Northern America. > You also have Cyprus as Western Asia We didn't originate the groupings; we take them from http://unstats.un.org/unsd/methods/m49/m49regin.htm. So if you have any complaints about Cyprus, etc. address them to the UN, not us. >You've requested a number from the UN for AQ? No. We added a ZZ to include region codes that were not otherwise include= d in the UN grouping. =E2=80=8EMark ----- Original Message -----=20 From: "Frank Ellermann" To: Sent: Tuesday, April 26, 2005 19:13 Subject: [Ltru] Re: 003 vs. 021 > Mark Davis wrote: > > > in CLDR we don't bother with 003, since it doesn't fit with > > the other containment relations. See: > > > http://www.unicode.org/cldr//data/diff/supplemental/supplemental.html#ter= ritory_containment__un_m____ > > Apparently you have neither 419 nor 003. But the LTRU draft > mentions 419. Actually both 419 and 003 are somewhat dubious, > at most one of them could be okay, but none of them is better. > > Where's the difference between es-019 and es-419 ? If it's > about immigrants from Cuba to Florida, Mexico to California, > etc., then it's es-CU, es-MX, es-019, or es-US, and es-419 (or > es-003) are not strictly necessary. > > Now I don't doubt that Doug must register 419 under the rules, > and maybe even 003. But it's apparently no good idea to use > these numbers in an example, if they are not supported by CLDR. > > > We also supplement the UN M.49 codes with ZZ (a private use > > region code), so that we get 3 containment levels there. > > That's a strange idea, The UM territories have nothing to do > with AQ, and Navassa is a Carribean island, not Oceania. And > IO is also unrelated to Oceania, that's Diego Garcia etc. in > the Indian Ocean. I'd add IO near the Seychelles. You have > SC as Eastern Africa, I'd probably say Western Asia. > > You also have Cyprus as Western Asia, but from my POV (I'm not > burdened by any "Middle East" concept) it's Europe. It's even > a member of the EU, at least the southern part. For Turkey > you could toss a coin, the main part is Asia. OTOH Georgia is > Europe, not Asia. > > Actually Eurasia is one continent, and arguments where it's not > require a separate continent for India. > > > We've requested a regular numeric code for that, but at this > > point a private use code is as good as we can do. > > You've requested a number from the UN for AQ ? This will cause > mass suicides. IIRC CC or CX or both also have nothing to do > with Oceania, one of them is near to IN or MM (?) Bye, Frank > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Apr 27 14:00:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQqpi-0007de-JH; Wed, 27 Apr 2005 14:00:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQqpi-0007dZ-1F for ltru@megatron.ietf.org; Wed, 27 Apr 2005 14:00:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07123 for ; Wed, 27 Apr 2005 14:00:20 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQr2L-000270-Ma for ltru@ietf.org; Wed, 27 Apr 2005 14:13:29 -0400 Received: from if12m5-235.d4.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DQqpV-00045V-8j; Wed, 27 Apr 2005 11:00:09 -0700 Message-Id: <6.2.1.2.2.20050427113815.04054020@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 27 Apr 2005 11:48:34 +0200 To: Frank Ellermann From: "JFC (Jefsey) Morfin" Subject: Re: [Ltru] Re: ISO 3166-1 DIS ballot In-Reply-To: <426EEAD9.60C8@xyzzy.claranet.de> References: <4A7C6FA2AB31194E80E13FE585F6A21292A5EA@EVS-EC1-NODE1.surrey.ac.uk> <426EEAD9.60C8@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Score: 0.7 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ltru Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 03:28 27/04/2005, Frank Ellermann said: >In other words 3066bis draft -01 should work without problems >at least until date A plus 50 years (2038). And maybe we can >improve this situation in draft -02 with a new "canonical" rule >following 3166-1 as long as possible - until the registry is >finally forced to take the emergency exit "UN number". > >Not bad. If the future Internet users really hate it they are >free to invent a new 3066ter where all old 3166-1 codes are >frozen and deprecated and replaced by UN numbers. And in that >case I'd want an "I told you so" on my grave. Bye, Frank I do not think this is an acceptable statement both in regard to the non-yet debatted charter and of industry needs and market criteria. It is not either an acceptabe proposition. A position statement should be included in the IANA part, since IANA - through ICANN - is a member of the ISO 3166 committee, how dormant it is. The use of 3166-1 alpha2 codes is a choice of this Draft to match some existing Internet standard formats. It is up to BCP 047 to document the possible use of other formats. No need to wait your decease (unless you want the Draft to be your grave). jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Apr 27 15:52:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQsaB-0001Xp-8G; Wed, 27 Apr 2005 15:52:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQsa5-0001XC-SP; Wed, 27 Apr 2005 15:52:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18894; Wed, 27 Apr 2005 15:52:19 -0400 (EDT) Message-Id: <200504271952.PAA18894@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 27 Apr 2005 15:52:19 -0400 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-registry-01.txt X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Language Tag Registry Update Working Group of the IETF. Title : Tags for Identifying Languages Author(s) : A. Phillips, M. Davis Filename : draft-ietf-ltru-registry-01.txt Pages : 61 Date : 2005-4-27 This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user defined extensions for private interchange. This document obsoletes RFC 3066 (which replaced RFC 1766). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ltru-registry-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ltru-registry-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-27160550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-registry-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-registry-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-27160550.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru --NextPart-- From ltru-bounces@lists.ietf.org Thu Apr 28 06:37:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR6Oj-0001pV-3Z; Thu, 28 Apr 2005 06:37:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR6Ob-0001pP-8J for ltru@megatron.ietf.org; Thu, 28 Apr 2005 06:37:32 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01154 for ; Thu, 28 Apr 2005 06:37:22 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DR6IW-0007pg-JC for ltru@lists.ietf.org; Thu, 28 Apr 2005 12:31:08 +0200 Received: from c-134-88-108.hh.dial.de.ignite.net ([62.134.88.108]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Apr 2005 12:31:08 +0200 Received: from nobody by c-134-88-108.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Apr 2005 12:31:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 28 Apr 2005 12:35:12 +0200 Organization: Lines: 33 Message-ID: <4270BC60.59EB@xyzzy.claranet.de> References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org><025901c548a8$5868dca0$030aa8c0@DEWELL><426B66AA.4580@xyzzy.claranet.de><013b01c54aa8$7b259970$107e3009@sanjose.ibm.com> <426EF538.C32@xyzzy.claranet.de> <02de01c54b39$d38c8d30$107e3009@sanjose.ibm.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: c-134-88-108.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis wrote: > if you have any complaints about Cyprus, etc. address > them to the UN, not us. I take the easy way out, I second Doug's impression that this source isn't above doubt. For the future registry it might be better to get rid of all these "groupings". > We added a ZZ to include region codes that were not > otherwise included in the UN grouping. Yes, but you added ZZ below Oceania, and IO below ZZ, not next to SC where I'd expect it, see also: And you have CC and CX below ZZ instead of Southeast Asia: I'd also expect GS near FK, but not somewhere below Oceania: Maybe you could clean-up the whole ZZ grouping, e.g. for HM I find "Indian Ocean", "two thirds of the way from Madagascar to Antarctica". Or you could rename ZZ to "Antarctica" if you add CC, CX, IO, and UM elsewhere. UM with its Navassa is a headache whatever you do. Bye, Fran _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 28 06:41:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR6SF-0002Y6-TJ; Thu, 28 Apr 2005 06:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR6SD-0002Xn-Kn for ltru@megatron.ietf.org; Thu, 28 Apr 2005 06:41:09 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28636 for ; Thu, 28 Apr 2005 05:54:56 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DR5dD-00035s-KM for ltru@lists.ietf.org; Thu, 28 Apr 2005 11:48:28 +0200 Received: from c-134-88-108.hh.dial.de.ignite.net ([62.134.88.108]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Apr 2005 11:48:27 +0200 Received: from nobody by c-134-88-108.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Apr 2005 11:48:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 28 Apr 2005 11:51:39 +0200 Organization: Lines: 14 Message-ID: <4270B22B.2A02@xyzzy.claranet.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-88-108.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: aaa-bbb-ccc-ddd-eee-fff-ggg-hhh-Latn-US-boont X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable wrote: > I think *n("-" extlang) where 2 <= n <= 4 would be > fine for now. I don't think we should remove this. Fine, that should help with one of Bruce's objections in the -08 last call. A future 30066ter could reduce the "n" in this extlang-limit if possible. It could also help against recent claims on the general IETF list that WGs don't care about the side-effects of what they do. :-( Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 28 11:10:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRAeQ-0000P9-3i; Thu, 28 Apr 2005 11:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRAeO-0000Op-IZ for ltru@megatron.ietf.org; Thu, 28 Apr 2005 11:10:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24743 for ; Thu, 28 Apr 2005 11:09:57 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DRArF-0006h5-Ed for ltru@ietf.org; Thu, 28 Apr 2005 11:23:18 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Thu, 28 Apr 2005 08:01:39 -0700 Message-ID: <016b01c54c04$53a4da20$6401a8c0@sanjose.ibm.com> From: "Mark Davis" To: , "Frank Ellermann" References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org><025901c548a8$5868dca0$030aa8c0@DEWELL><426B66AA.4580@xyzzy.claranet.de><013b01c54aa8$7b259970$107e3009@sanjose.ibm.com><426EF538.C32@xyzzy.claranet.de><02de01c54b39$d38c8d30$107e3009@sanjose.ibm.com> <4270BC60.59EB@xyzzy.claranet.de> Subject: Re: [Ltru] Re: 003 vs. 021 Date: Thu, 28 Apr 2005 08:09:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA24743 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org 1. There is no reason why the groupings should not stay; they are well-defined entities, and serve a useful purpose in identifying regional use of language. 2. ZZ is really irrelevant to ltru, since it is CLDR's use of a private u= se code. However, just for your information, we will not change any of the contents of groupings that the UN had already put into place. So ZZ is simply a collection of everything that they didn't put into a 3rd level group. While it may be possible to improve the name, or some other change= , this mail list is not the place for that discussion. =E2=80=8EMark ----- Original Message -----=20 From: "Frank Ellermann" To: Sent: Thursday, April 28, 2005 03:35 Subject: [Ltru] Re: 003 vs. 021 > Mark Davis wrote: > > > if you have any complaints about Cyprus, etc. address > > them to the UN, not us. > > I take the easy way out, I second Doug's impression that > this source isn't above doubt. For the future registry > it might be better to get rid of all these "groupings". > > > We added a ZZ to include region codes that were not > > otherwise included in the UN grouping. > > Yes, but you added ZZ below Oceania, and IO below ZZ, not > next to SC where I'd expect it, see also: > > > > And you have CC and CX below ZZ instead of Southeast Asia: > > > > > I'd also expect GS near FK, but not somewhere below Oceania: > > > > Maybe you could clean-up the whole ZZ grouping, e.g. for HM > I find "Indian Ocean", "two thirds of the way from Madagascar > to Antarctica". Or you could rename ZZ to "Antarctica" if > you add CC, CX, IO, and UM elsewhere. UM with its Navassa > is a headache whatever you do. > Bye, Fran > > > > _______________________________________________ > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Apr 28 15:12:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRER5-0000th-Iz; Thu, 28 Apr 2005 15:12:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRER3-0000tc-Ts for ltru@megatron.ietf.org; Thu, 28 Apr 2005 15:12:30 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15429 for ; Thu, 28 Apr 2005 15:12:27 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DREKx-000320-EN for ltru@lists.ietf.org; Thu, 28 Apr 2005 21:06:11 +0200 Received: from 62.80.58.28 ([62.80.58.28]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Apr 2005 21:06:11 +0200 Received: from nobody by 62.80.58.28 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Apr 2005 21:06:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 28 Apr 2005 21:10:00 +0200 Organization: Lines: 12 Message-ID: <42713508.27B9@xyzzy.claranet.de> References: <20050423125148.JSJB28887.mta4.adelphia.net@megatron.ietf.org><025901c548a8$5868dca0$030aa8c0@DEWELL><426B66AA.4580@xyzzy.claranet.de><013b01c54aa8$7b259970$107e3009@sanjose.ibm.com><426EF538.C32@xyzzy.claranet.de><02de01c54b39$d38c8d30$107e3009@sanjose.ibm.com> <4270BC60.59EB@xyzzy.claranet.de> <016b01c54c04$53a4da20$6401a8c0@sanjose.ibm.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: 62.80.58.28 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Mark Davis wrote: > ZZ is simply a collection of everything that they didn't > put into a 3rd level group. If I got it right that should match all alpha-2 codes in the registry which are not deprecated and don't have a UN number: AQ, BV, CC, CX, GS, HM, IO, TF, UM. And TW is an exception. Maybe Doug can use ZZ as an additional plausibilty test. Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Apr 29 14:18:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRa4N-0000dY-FD; Fri, 29 Apr 2005 14:18:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRa4M-0000dS-JU for ltru@megatron.ietf.org; Fri, 29 Apr 2005 14:18:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25419 for ; Fri, 29 Apr 2005 14:18:29 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRaHR-0001mO-NV for ltru@ietf.org; Fri, 29 Apr 2005 14:32:04 -0400 Received: from h-68-166-37-61.snvacaid.dynamic.covad.net ([68.166.37.61] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DRa4I-0004PN-00 for ltru@ietf.org; Fri, 29 Apr 2005 11:18:26 -0700 Message-ID: <007001c54ce8$1f470980$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 29 Apr 2005 11:20:28 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] Fw: Area Advisor Changes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Forwarded for your information. This should have no impact on our day-to-day operation, particularly since Scott had been our acting AD while Ted was out on paternity leave. Randy, ltru co-chair > From: "Scott Hollenbeck" > To: ; ; ; alexey.melnikov@isode.com> > Cc: "'Ted Hardie'" > Sent: Friday, April 29, 2005 2:11 AM > Subject: Area Advisor Changes > > Ted and I have decided to re-balance management of a few applications area > working groups. I will become the area advisor for the LTRU and SIEVE > working groups. Strangely, we both thought I already was the area advisor > for sieve, but the charter web page says otherwise. > > I've asked the Secretariat to update your charter pages. > > -Scott- > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 30 11:52:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRuGE-0004In-FT; Sat, 30 Apr 2005 11:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRuGD-0004Ih-3m for ltru@megatron.ietf.org; Sat, 30 Apr 2005 11:52:05 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14403 for ; Sat, 30 Apr 2005 11:52:02 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050430155133.SYQQ8952.mta9.adelphia.net@DEWELL> for ; Sat, 30 Apr 2005 11:51:33 -0400 Message-ID: <004a01c54d9c$530683e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050428160446.HYMY27459.mta2.adelphia.net@megatron.ietf.org> Date: Sat, 30 Apr 2005 08:50:24 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: 003 vs. 021 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: >> if you have any complaints about Cyprus, etc. address >> them to the UN, not us. > > I take the easy way out, I second Doug's impression that > this source isn't above doubt. For the future registry > it might be better to get rid of all these "groupings". Please don't associate my concern about UNSD changing the numeric codes with a call to "get rid of" the codes. I agree with Mark that they may serve a useful tagging purpose. If there is disagreement about the edge cases, like whether Cyprus is part of Asia or Europe, that does not justify throwing away the entire mechanism. Geographers have disagreed over such things for centuries. > Maybe you could clean-up the whole ZZ grouping, e.g. for HM > I find "Indian Ocean", "two thirds of the way from Madagascar > to Antarctica". Or you could rename ZZ to "Antarctica" if > you add CC, CX, IO, and UM elsewhere. UM with its Navassa > is a headache whatever you do. But none of this, as Mark said, has anything to do with language tags. Later: > Maybe Doug can use ZZ as an additional plausibilty test. Plausibility of what? -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 30 14:50:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRx33-0006Iq-DO; Sat, 30 Apr 2005 14:50:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DRx32-0006Il-47 for ltru@megatron.ietf.org; Sat, 30 Apr 2005 14:50:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23897 for ; Sat, 30 Apr 2005 14:50:38 -0400 (EDT) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DRxGL-0003hd-9S for ltru@ietf.org; Sat, 30 Apr 2005 15:04:26 -0400 Received: from h-68-165-3-95.snvacaid.dynamic.covad.net ([68.165.3.95] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DRx2v-0001gy-00 for ltru@ietf.org; Sat, 30 Apr 2005 11:50:33 -0700 Message-ID: <009f01c54db5$c79e8040$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <4A7C6FA2AB31194E80E13FE585F6A21292A5EA@EVS-EC1-NODE1.surrey.ac.uk> <426EEAD9.60C8@xyzzy.claranet.de> Subject: Re: [Ltru] Re: ISO 3166-1 DIS ballot Date: Sat, 30 Apr 2005 11:52:37 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Frank Ellermann" > To: > Sent: Tuesday, April 26, 2005 6:28 PM > Subject: [Ltru] Re: ISO 3166-1 DIS ballot > > L.Gillam wrote: > > > Code elements that the ISO 3166/MA has altered or deleted > > should not be reallocated during a period of at least fifty > > years after the change. The exact period is determined in > > each case on the basis of the importance of the extent to > > which the former code element was used. > > In other words 3066bis draft -01 should work without problems > at least until date A plus 50 years (2038). And maybe we can > improve this situation in draft -02 with a new "canonical" rule > following 3166-1 as long as possible - until the registry is > finally forced to take the emergency exit "UN number". ... Do you have specific text you'd like to propose? Keep in mind that we don't want to make a normative reference to work-in-progress. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Apr 30 21:55:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS3gQ-00032y-6C; Sat, 30 Apr 2005 21:55:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS3gP-00032t-Kj for ltru@megatron.ietf.org; Sat, 30 Apr 2005 21:55:45 -0400 Received: from mta9.adelphia.net (mta9.adelphia.net [68.168.78.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16690 for ; Sat, 30 Apr 2005 21:55:43 -0400 (EDT) Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050501015514.OYRX8952.mta9.adelphia.net@DEWELL> for ; Sat, 30 Apr 2005 21:55:14 -0400 Message-ID: <001301c54df0$c53371e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 30 Apr 2005 18:54:53 -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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: ISO 3166-1 DIS ballot X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Language Tag Registry Update working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann wrote: > In other words 3066bis draft -01 should work without problems > at least until date A plus 50 years (2038). And maybe we can > improve this situation in draft -02 with a new "canonical" rule > following 3166-1 as long as possible - until the registry is > finally forced to take the emergency exit "UN number". and Randy responded: > Do you have specific text you'd like to propose? > Keep in mind that we don't want to make a normative reference > to work-in-progress. There's more to it than that. The draft contains SPECIFIC, EXPLICIT steps for what to do if and when ISO 3166/MA ever reuses a code element. This is one of the basic rationales for the whole LTRU project. To state that the draft will "work without problems" only until ISO 3166/MA reuses a code element, and that at that point the registry will be "forced to take an emergency exit," demonstrates complete misunderstanding of the mechanism described in the draft. Please read Section 3.3 again, in particular the next-to-last bullet point (the one with six sub-bullet points): http://www.inter-locale.com/ID/draft-ietf-ltru-registry-01.html#ianastability -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru