From ltru-bounces@lists.ietf.org Fri Jul 01 02:53:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoFOV-0001ho-Uh; Fri, 01 Jul 2005 02:52:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoFOP-0001fX-4G for ltru@megatron.ietf.org; Fri, 01 Jul 2005 02:52:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18078 for ; Fri, 1 Jul 2005 02:52:50 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoFhZ-0000Fo-LE for ltru@ietf.org; Fri, 01 Jul 2005 03:12:44 -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 j616jlZm013401; Fri, 1 Jul 2005 09:45:48 +0300 (EEST) Message-ID: <42C4E69A.2070602@kotus.fi> Date: Fri, 01 Jul 2005 09:45:46 +0300 From: Erkki Kolehmainen User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fi, en-us, sv MIME-Version: 1.0 To: Martin Duerst Subject: Re: [Ltru] Submission: draft-ietf-ltru-registry-07 References: <634978A7DF025A40BFEF33EB191E13BC0BF74E8A@irvmbxw01.quest.com> <6.0.0.20.2.20050701124803.0420d790@localhost> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Excellent, indeed! Erkki I. Kolehmainen Martin Duerst wrote: > At 01:54 05/07/01, Addison Phillips wrote: > >content-class: urn:content-classes:message > >Content-Type: text/plain;charset="utf-8" > > > >Martin, > > > >Instead of proposing work to do, propose text. > > Sorry, yes, I should have done that. > > >I'm tired of this process, so I've made an edit of Section 8 ("Changes > from > >RFC 3066"), modifying the text to make it more Anglo-Saxon (i.e. > easier to > >read for non-Anglo-Saxons). I have also put in a specific paragraph to > deal > >with the placement of the script subtag: > > > >The choice of placing the extended language and script subtags between > >the primary language and region subtags was widely debated. This > design was > >chosen because the prevalent matching and content negotiation schemes > rely > >on the subtags being arranged in order of increasing specificity. That > is, > >the subtags that mark a greater barrier to mutual intelligibility appear > >left-most in a tag. For example, when selecting content written in > >Azerbaijani, the script (Arabic, Cyrillic, or Latin) represents a greater > >barrier to understanding than any regional variations (those associated > >with Azerbaijan or Iran, for example). Individuals who prefer > documents in > >a particular script, but can deal with the minor regional differences, > can > >therefore select appropriate content. Applications that do not deal with > >written content will continue to omit these subtags. > > This looks great! Thanks a lot. Martin. > > > >The results are posted as draft-08 on my personal website as usual: > > > >http://www.inter-locale.com/ID/draft-ietf-ltru-registry-08.html > >http://www.inter-locale.com/ID/draft-ietf-ltru-registry-08.txt > > > >Are we done now? > > > >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: Mark Davis [mailto:mark.davis@jtcsv.com] > >> Sent: 2005$Bj;%((B6$Bk|(B?0$Bkw!&(B 7:26 > >> To: Addison Phillips; Martin Duerst > >> Cc: Karen_Broome@spe.sony.com; LTRU Working Group > >> Subject: Re: [Ltru] Submission: draft-ietf-ltru-registry-07 > >> > >> I realize that your intentions were good, but we are way behind > schedule. > >> > >> $Bc`;.(Bark > >> > >> ----- Original Message ----- > >> From: "Martin Duerst" > >> To: "Mark Davis" ; "Addison Phillips" > >> > >> Cc: ; "LTRU Working Group" > >> Sent: Thursday, June 30, 2005 01:13 > >> Subject: Re: [Ltru] Submission: draft-ietf-ltru-registry-07 > >> > >> > >> > Just to make things clear, I was not asking for a lengthy explanation > >> > of every issue that ever came up on the mailing list, or in some > other > >> > discusson. I was also not proposing to delay the schedule. I was just > >> > proposing that documenting the arguably most disussed point in the > >> > whole proposal, namely the position of the script tag. > >> > But I'll leave it to the editors to do the right thing. > >> > > >> > Regards, Martin. > >> > > >> > At 00:28 05/06/30, Mark Davis wrote: > >> > >With any document, it is always possible to have incremental > >> improvements. > >> > >But we will never finish at that rate. It is now the 60th of > May, so > >> if > >> we > >> > >are going to finish by the end of May as planned, we have to wrap > >> things > >> up, > >> > >instead of having continual tweaks. > >> > > > >> > >$Bn,%+mz%=(Bark > >> > > > >> > >----- Original Message ----- > >> > >From: "Martin Duerst" > >> > >To: "Addison Phillips" > >> > >Cc: ; "LTRU Working Group" > > >> > >Sent: Tuesday, June 28, 2005 17:08 > >> > >Subject: Re: [Ltru] Submission: draft-ietf-ltru-registry-07 > >> > > > >> > > > >> > >> Addison, others, > >> > >> > >> > >> This question is probably the most frequent question that comes > >> > >> up from newcommers. Is there any chance that the reason for this > >> > >> decision is documented in the draft, e.g. in an Appendix? > >> > >> > >> > >> There are some examples of how to do this, see e.g. > >> > >> RFC 3987, Appendix A, or RFC 3023, also Appendix A. > >> > >> > >> > >> Are there any other difficult-to-understand things that might > >> > >> benefit from such documentation? We already have some > documentation > >> > >> about how we got to the various length restrictions; maybe that > >> > >> could be moved to the appendix, too. > >> > >> > >> > >> Regards, Martin. > >> > >> > >> > >> At 04:16 05/06/29, Karen_Broome@spe.sony.com wrote: > >> > >> >I'm a newcomer to the list, so forgive me if I have a > historical > >> > >question: > >> > >> >Why was the decision made to put the script variant before the > >> regional > >> > >> >variant? I likely would have structured it with the regional > >> variant > >> > >> >before the script variant because for me, the script variant > only > >> > >applies > >> > >> >if the content is written while the regional variant would > apply > >> in > >> both > >> > >> >the written and spoken contexts. If you can point me in the > >> direction of > >> > >> >an archive on the topic, that would help. > >> > >> > > >> > >> >Thank you, > >> > >> > > >> > >> >Karen Broome > >> > >> >Metadata Systems Designer > >> > >> >Sony Pictures Entertainment > >> > >> >310.244.4384 > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> >"Addison Phillips" > >> > >> >Sent by: ltru-bounces@lists.ietf.org > >> > >> >06/27/2005 10:22 AM > >> > >> > > >> > >> > > >> > >> > To: > >> > >> > cc: LTRU Working Group > >> > >> > Subject: [Ltru] Submission: > >> draft-ietf-ltru-registry-07 > >> > >> > > >> > >> > > >> > >> >Dear Editor, > >> > >> > > >> > >> >Please find draft-ietf-ltru-registry-07 attached. > >> > >> > > >> > >> >Best Regards, > >> > >> > > >> > >> >Addison (for the editors) > >> > >> > > >> > >> >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 > >> > >> > >> > >> > >> > > >> > > >> > > >> > > > > > >_______________________________________________ > >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 Fri Jul 01 05:42:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoI27-0003rS-IU; Fri, 01 Jul 2005 05:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoI25-0003pv-6h for ltru@megatron.ietf.org; Fri, 01 Jul 2005 05:42:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15452 for ; Fri, 1 Jul 2005 05:41:54 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DoIRx-0000Ye-4n for ltru@ietf.org; Fri, 01 Jul 2005 06:08:45 -0400 Received: from ads33.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Fri, 1 Jul 2005 10:41:12 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads33.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jul 2005 10:41:09 +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] (no subject) Date: Fri, 1 Jul 2005 10:41:09 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A212BC8B6F@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] (no subject) Thread-Index: AcV90aGx5xypNK08TqOyqt13XkbrvgAReLyA From: "L.Gillam" To: info , petercon X-OriginalArrivalTime: 01 Jul 2005 09:41:09.0131 (UTC) FILETIME=[028665B0:01C57E21] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Am I missing the point, or is there a lot of argument about private use = extensions wanting to use a "." where, as I perceive it, the same job = can be accomplished with what is already available. Without going into limitations, extend the syntax that's already there. = You don't *need* to use a "." since you can have multiple differently = lengthed alphanums (each upto 8 in length). Your first item could be = alphanum*5. If you have a second that is alphanum*3, this can "stand = for" your requirement. You can then have a following alphanum*5. = Programmatically quite straightforward I think you'll agree, = back-compatible with RFC 3066, and since in the PUE section you can = declare your own conformant ABNF for this that others can reference = also. The only question is: what is the length limitation imposed on = longest conformant ("registry") tag + longest conformant PUE. But, if = you're not bothered about back-compat then do what you wish. That is, = unless I missed some *major* fundamental interpretative issue whereby a = "." is the ONLY possible solution. I didn't realise that Peter Constable had suddenly taken complete = ownership of RFC 3066 - I'd be surprised it the editors hadn't noticed - = and yet this mail quoted is addressed to Mr Constable and uses a = succession of "you" and "your" that by implication are in the singular. = RFC 3066 is not Peter's personal limitation or imposition, and as such = what is contained below does not make for pleasant reading. If you wish = to attack a system and its definition, fine - but provide good and well = explained examples of why it does not or can not work. For example, can = you explain WHY an ASCII tag for identifying languages prevents culture, = or what aspects of culture (art? history?) are prevented by its use. = Personal attacks, on the other hand, are not welcome. > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of info@dot-root.com > Sent: 01 July 2005 01:12 > To: petercon@microsoft.com > Cc: ltru@ietf.org > Subject: [Ltru] (no subject) >=20 >=20 > Dear Mr. Constable, > I apologise for being late in responding. But I have to get=20 > some help to > send a mail in English. >=20 > I feel you do not realise how we perceive what you are doing. In the > Internet world there is ISO 3166 which has a clear=20 > recognition. RFC 3066 > introduced ISO 639 and it provided a way to define, when=20 > people need it, > other "binomes" when the ISO tables are not enough. This is a=20 > lose, light > and versatile system. This is what is important. I can use=20 > it. Even if the > IANA registry is not well managed. >=20 > You transform the system. You make it formal. You make it heavy and > complex. I understand nothing in this text. But I am to obey=20 > it. This is > why I dislike your ideas. All the more than you make it=20 > systematic with > locales de facto imposed to Linux, and no commitment from=20 > CLDR to never do > as ISO planned to do: to register it and to force people pay for it. >=20 > You harm us, Mr. Constable. We did nothing to you. >=20 >=20 >=20 > The "." changes nothing. It is a separator. We are no fool,=20 > and we use it. > The token can be any length, the subtag remains 8alphanum -=20 > however we do > not mind. You say we break retrocompatibility: with what? >=20 > We talk necessarily of usage which were never even=20 > considered. If an old > system fails recognising our tag, what then???? Since we do=20 > not want them > to be compatible (this could be confusing). We do not want a single > ASCIInternational global space. Do you understand that? We=20 > want a space > per community: technical end to end interoperability must=20 > work everywhere, > but cultural person to person interintelligibility must be=20 > protected. Your > system forbids its most elementary protection, which is the=20 > support of its > diversity and its self-denomination/definition by the people. >=20 > Anyway, we will do it. >=20 > And we expect it to be quite used because it addresses a=20 > need. I am sorry > to have to tell you that: with all my respect, the world is=20 > not a zoo for > ASCII visitors. We are not much interested in the IETF=20 > paperwork. We are > not even interested in academic running code: we are=20 > interested in used > code and real practices. This is the best RFC. This is why you should > carefully read the mail of M. JFC Morfin. I think his=20 > position is good and > permits you to also develop your ideas. No one wants the=20 > fight you want: > but no one wants to be under pressure to speak American or to=20 > buy products > from a specific group of manufacturers. We want competition.=20 > You try to > reduce competition. >=20 > We want to empower cultures and therefore their languages. Not to put > their dominant editor in a can with a gummed ASCII langtag,=20 > on the shelves > on the e-commerce software shop. We just succeeded to get=20 > culture out of > WTO's reach: it is not to get them back through their=20 > languages. Languages > are not for sales, just language oriented tools are, but on an equal > opportunity basis for the sellers and the users. Including=20 > the right to > use open source without a commercial locale. >=20 > Mr. Constable, I am sorry. Please also get real. Not only technical, > commercial and political. > F. Charles. >=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 Fri Jul 01 15:50:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRXG-0007v2-UT; Fri, 01 Jul 2005 15:50:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoRWY-0004RT-0v; Fri, 01 Jul 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05306; Fri, 1 Jul 2005 15:50:02 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoRwX-0001SE-8g; Fri, 01 Jul 2005 16:16:58 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DoRWU-0001dU-Fm; Fri, 01 Jul 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 01 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-registry-08.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-08.txt Pages : 60 Date : 2005-7-1 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-08.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-08.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-08.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-7-1134859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-registry-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-registry-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-1134859.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 Fri Jul 01 18:35:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoU6l-0003nC-QS; Fri, 01 Jul 2005 18:35:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoU6k-0003kS-Mi for ltru@megatron.ietf.org; Fri, 01 Jul 2005 18:35:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02108 for ; Fri, 1 Jul 2005 18:35:35 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoUWm-0006fK-WF for ltru@ietf.org; Fri, 01 Jul 2005 19:02:34 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DoU6T-0000Vp-J5; Fri, 01 Jul 2005 15:35:21 -0700 Message-Id: <6.2.1.2.2.20050701222739.03a9f790@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 02 Jul 2005 00:34:57 +0200 To: "Peter Constable" , From: r&d afrac Subject: RE: [Ltru] ISO 11179 and other issues 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 - afrac.org X-Spam-Score: 0.0 (/) 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 Sorry: troll. Comments out of my mail's scope. I am not sure who do you think you are to venture the first one? The second is irrelevant. jfc At 03:08 01/07/2005, Peter Constable wrote: > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] >On Behalf Of r&d > > afrac _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 02 19:27:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DorOr-0008QM-EE; Sat, 02 Jul 2005 19:27:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DorOp-0008PK-NV for ltru@megatron.ietf.org; Sat, 02 Jul 2005 19:27:51 -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 TAA10082 for ; Sat, 2 Jul 2005 19:27:47 -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 <20050702232719.QXFO29002.mta9.adelphia.net@DEWELL> for ; Sat, 2 Jul 2005 19:27:19 -0400 Message-ID: <001901c57f5d$8893c980$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 2 Jul 2005 16:26: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: This time for sure: draft-ietf-ltru-initial-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 I mentioned that in draft-initial-01, there are some passages marked with [ [ double brackets ] ] that I believe are outside the scope of the initial registry, and need to be either moved back into the main registry draft or deleted altogether. There are also some UN numeric codes in the list in Section 4 that are marked [ [ the same way ] ], which probably don't belong on that list, but which I would rather debate on the list than remove unilaterally. So far there has been no response on the list to any of this. Now maybe all the Americans in the WG are just out of town for the long weekend, but I know there had been a desire to move this thing along, and make progress toward a simultaneous Last Call for both drafts (with the matching draft to follow in a month or so). Would it help stimulate discussion if I turned these questions into RT tickets? -- 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 Jul 02 23:17:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Douz5-0007Y3-U0; Sat, 02 Jul 2005 23:17:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dotp0-0004NE-EC for ltru@megatron.ietf.org; Sat, 02 Jul 2005 22:03:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20911 for ; Sat, 2 Jul 2005 22:02:59 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DouFH-0006Ip-PI for ltru@ietf.org; Sat, 02 Jul 2005 22:30:12 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dotos-0007JW-TG for ltru@ietf.org; Sat, 02 Jul 2005 19:02:55 -0700 Message-Id: <6.2.1.2.2.20050703025830.04a12060@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 03 Jul 2005 04:02:50 +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.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Sat, 02 Jul 2005 23:17:30 -0400 Cc: Subject: [Ltru] IANA ISO 3166 related Registries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 fundamental reason I opposed and will continue to oppose the current Draft is that it uses the IANA Registry to attach and disseminate worldwide a new language attribute concerning national and linguistic communities without involving them. This langtag also confuses these communities and cultures since it can only discriminate through the generic language code, its generic script code, and the code of a country. What can be conceived for a solitary linguist classifying its library or sorting his notes, does not make sense when considering a network, all the more when the words being used are not defined, neither as concepts nor as the way their are instantiated: what is a language, what is the nature descriptive or normative of the langtag, if its for the reader, for the author, for the relational exchange? This is not acceptable when these langtags will be de facto imposed to languages independently of the laws and policies which may identify, define, support them. The position adopted by the USA concerning the control of the root file results in the continuation of the IANA contract and therefore the dependance of the considered Registry from the US Government. Under the circumstance, AFRAC (whose purpose in life is to provide a proper reference system to French people) has concerted with similar projects under consideration in Europe, Africa, Asia, South America and Canada. The consensus is that every IANA Registry using ISO 3166 codes will be from now on deemed representing an US position, unless it is transferred to the ICANN IANA zone, on such case the authority should be the GAC. The consensus is that generally the US point of view on local culture does bear enough weight to be worth the continuation of the effort engaged since December. Also it is that priority will be given to the root files and that any organisation proposing a distributed IANA copy will support the langtag Registry decided by its own Culture Ministry. It is also agreed that the US position should be read as a support of the International Standards simplification (in this case as ISO 11179, ISO 639-3, ISO 639-4, ISO 639-6, ISO 3166). The consensus is therefore to use the ISO tags or built from ISO tables, and to use x-tags. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 00:13:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DovrH-0002i7-Ke; Sun, 03 Jul 2005 00: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 1DovrF-0002fz-Ug for ltru@megatron.ietf.org; Sun, 03 Jul 2005 00:13:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01565 for ; Sun, 3 Jul 2005 00:13:26 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DowHY-0006sf-P4 for ltru@ietf.org; Sun, 03 Jul 2005 00:40:41 -0400 Received: from h-64-105-136-238.snvacaid.dynamic.covad.net ([64.105.136.238] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DovrC-00050L-00 for ltru@ietf.org; Sun, 03 Jul 2005 00:13:26 -0400 Message-ID: <000601c57f86$1e9edc80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.2.1.2.2.20050703025830.04a12060@pop.online.fr> Subject: Re: [Ltru] IANA ISO 3166 related Registries Date: Sat, 2 Jul 2005 21:17:25 -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: 00e94c813bef7832af255170dca19e36 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 - Trying to understand whether any new issues are being raised... > From: "Jefsey Morfin" > To: > Sent: Saturday, July 02, 2005 7:02 PM > Subject: [Ltru] IANA ISO 3166 related Registries > > The fundamental reason I opposed and will continue to oppose the current > Draft is that it uses the IANA Registry to attach and disseminate worldwide > a new language attribute concerning national and linguistic communities > without involving them. This langtag also confuses these communities and > cultures since it can only discriminate through the generic language code, > its generic script code, and the code of a country. > > What can be conceived for a solitary linguist classifying its library or > sorting his notes, does not make sense when considering a network, all the > more when the words being used are not defined, neither as concepts nor as > the way their are instantiated: what is a language, what is the nature > descriptive or normative of the langtag, if its for the reader, for the > author, for the relational exchange? This is not acceptable when these > langtags will be de facto imposed to languages independently of the laws > and policies which may identify, define, support them. > > The position adopted by the USA concerning the control of the root file What position in what forum are you talking about? > results in the continuation of the IANA contract and therefore the > dependance of the considered Registry from the US Government. Under the > circumstance, AFRAC (whose purpose in life is to provide a proper reference > system to French people) has concerted with similar projects under > consideration in Europe, Africa, Asia, South America and Canada. The Is this in conjunction with your http://intlnet.org/eadmin.htm project? Who would be the liaison contact for the IETF? > consensus is that every IANA Registry using ISO 3166 codes will be from now The consensus of whom? > on deemed representing an US position, unless it is transferred to the > ICANN IANA zone, on such case the authority should be the GAC. The The logic of how the use of an ISO international standard could be construed as representing a US position completely eludes me. > consensus is that generally the US point of view on local culture does bear I'm curious to learn what this "US point of view on local culture" is, and where (and by whom) this weighty pronouncement was made. > enough weight to be worth the continuation of the effort engaged since > December. Also it is that priority will be given to the root files and that > any organisation proposing a distributed IANA copy will support the langtag > Registry decided by its own Culture Ministry. I don't think the US even has a Culture Ministry. If there is one, it goes by some other name and keeps a *very* low profile. > It is also agreed that the US position should be read as a support of the Agreed by whom? The US position where? > International Standards simplification (in this case as ISO 11179, ISO > 639-3, ISO 639-4, ISO 639-6, ISO 3166). The consensus is therefore to use > the ISO tags or built from ISO tables, and to use x-tags. The consensus of whom? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 04:50:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp0BE-0001rL-Jq; Sun, 03 Jul 2005 04:50:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp0BC-0001r8-Ln for ltru@megatron.ietf.org; Sun, 03 Jul 2005 04:50:22 -0400 Received: from rly-ip03.mx.aol.com (rly-ip03.mx.aol.com [64.12.138.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22433 for ; Sun, 3 Jul 2005 04:50:20 -0400 (EDT) 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 RELAYIN1-242c7a6aee3; Sun, 03 Jul 2005 04:49:50 -0500 Received: from DEBHOME (ACC99C4A.ipt.aol.com [172.201.156.74]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j638ni3C030546 for ; Sun, 3 Jul 2005 04:49:44 -0400 Message-Id: <200507030849.j638ni3C030546@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'LTRU Working Group'" Date: Sun, 3 Jul 2005 09:49:55 +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: AcV/rC0vo43AfJ0bRaScXklXoaZW+w== X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Referencing the Scheme within the 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org An issue that I still feel quite strongly about is the referencing of the encoding scheme within the language tag itself; I believe it is essential for long term archival processes. I would like to propose the addition of the following: "Implementers MAY reference this scheme within the language tag itself using the following syntax: Language-Tag (Scheme_RFC_3066_bis) = ..." or some such... This would be particularly useful when tagging cultural information for archival purposes e.g. digitalised manuscripts. It would give archivists the ability to maintain, reference and update their systems. Debbie Garside www.linguasphere.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 05:59:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp1G2-0007Ql-Ez; Sun, 03 Jul 2005 05:59:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp1G0-0007Qc-Ui for ltru@megatron.ietf.org; Sun, 03 Jul 2005 05:59:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03192 for ; Sun, 3 Jul 2005 05:59: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 1Dp1gH-000123-KY for ltru@ietf.org; Sun, 03 Jul 2005 06:26:38 -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 RELAYIN6-742c7b6e5321; Sun, 03 Jul 2005 05:59:02 -0500 Received: from DEBHOME (ACC99C4A.ipt.aol.com [172.201.156.74]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j639wx5a030103 for ; Sun, 3 Jul 2005 05:58:59 -0400 Message-Id: <200507030958.j639wx5a030103@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: Date: Sun, 3 Jul 2005 10:59:11 +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: AcV/rC0vo43AfJ0bRaScXklXoaZW+wACZQDQ X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.7 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Referencing the Scheme within the 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org An issue that I still feel quite strongly about is the referencing of the encoding scheme within the language tag itself; I believe it is essential for long term archival processes. I would like to propose the addition of the following: "Implementers MAY reference this scheme within the language tag itself using the following syntax: Language-Tag (Scheme_RFC_3066_bis) = ..." or some such... This would be particularly useful when tagging cultural information for archival purposes e.g. digitalised manuscripts. It would give archivists the ability to maintain, reference and update their systems. Debbie Garside www.linguasphere.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 06:47:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp20Z-0005Of-Ng; Sun, 03 Jul 2005 06:47:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp20X-0005OI-Os for ltru@megatron.ietf.org; Sun, 03 Jul 2005 06:47:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08408 for ; Sun, 3 Jul 2005 06:47:27 -0400 (EDT) Received: from mail12.svc.cra.dublin.eircom.net ([159.134.118.28]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dp2Qs-00058z-Qo for ltru@ietf.org; Sun, 03 Jul 2005 07:14:44 -0400 Received: (qmail 10016 messnum 5765208 invoked from network[159.134.168.177/159-134-168-177.as1.prp.dublin.eircom.net]); 3 Jul 2005 10:47:13 -0000 Received: from 159-134-168-177.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.168.177) by mail12.svc.cra.dublin.eircom.net (qp 10016) with SMTP; 3 Jul 2005 10:47:13 -0000 Message-ID: <42C7C180.F4F78074@egt.ie> Date: Sun, 03 Jul 2005 11:44:16 +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] Referencing the Scheme within the Tag References: <200507030958.j639wx5a030103@smtp-los03.proxy.aol.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA08408 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 Makes sense. mg Scr=EDobh Debbie Garside: > ... >=20 > "Implementers MAY reference this scheme within the language tag itself = using > the following syntax: >=20 > Language-Tag (Scheme_RFC_3066_bis) =3D ..." or some such... >=20 > This would be particularly useful when tagging cultural information for > archival purposes e.g. digitalised manuscripts. It would give archivis= ts > the ability to maintain, reference and update their systems. >=20 > Debbie Garside > www.linguasphere.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 Sun Jul 03 11:15:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp6C5-0001jQ-9w; Sun, 03 Jul 2005 11:15:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp6C4-0001jC-5w for ltru@megatron.ietf.org; Sun, 03 Jul 2005 11:15:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07974 for ; Sun, 3 Jul 2005 11:15:38 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp6cS-0006WU-Ml for ltru@ietf.org; Sun, 03 Jul 2005 11:42:57 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dp6C2-0002TB-3D; Sun, 03 Jul 2005 08:15:38 -0700 Message-Id: <6.2.1.2.2.20050703145300.0523cd70@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 03 Jul 2005 17:15:32 +0200 To: "Randy Presuhn" , From: r&d afrac Subject: Re: [Ltru] IANA ISO 3166 related Registries In-Reply-To: <000601c57f86$1e9edc80$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050703025830.04a12060@pop.online.fr> <000601c57f86$1e9edc80$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 06:17 03/07/2005, Randy Presuhn wrote: > > The position adopted by the USA concerning the control of the root file > >What position in what forum are you talking about? Sorry, due to its importance I expected this information was known to everyone. I sent the URL in another mail. >Is this in conjunction with your http://intlnet.org/eadmin.htm project? >Who would be the liaison contact for the IETF? as previously explained ICANN published the ICP-3 document. IETF disregarded the call. Intlnet carried this experimentation along with the ICANN guidlines (named dot-root). This permitted to identify both the needs (as the USA do today) and ways to address them. We incorporated AFRAC to explore the solutions we identified. The architectural stability of the world digital ecosystem and the end to end principle call for (at least) the national distribution of the reference sources (IANA): Common Refeference Centers. The NICSO has the mission to advise Govs, ccTLDs and National Internet Communities over the transition. > > consensus is that every IANA Registry using ISO 3166 codes will be from now > >The consensus of whom? The people I polled who are involved in the study/project of a CRC projects interested in the AFRAC work. > > on deemed representing an US position, unless it is transferred to the > > ICANN IANA zone, on such case the authority should be the GAC. The > >The logic of how the use of an ISO international standard could be construed >as representing a US position completely eludes me. Read the US Statement of Principles. > > consensus is that generally the US point of view on local culture does bear > >I'm curious to learn what this "US point of view on local culture" is >and where (and by whom) this weighty pronouncement was made. the many who would like to know it! > > enough weight to be worth the continuation of the effort engaged since > > December. Also it is that priority will be given to the root files and that > > any organisation proposing a distributed IANA copy will support the langtag > > Registry decided by its own Culture Ministry. > >I don't think the US even has a Culture Ministry. This is precisely the problem :-) >If there is one, it goes by some other name and keeps a *very* low profile. You may know that in many countries of the world, this Ministry is a key one. What is really a problem is that ietf-languages may consider deciding anything about languages and countries without involving these Ministries. And that this Draft does not consider them. > > It is also agreed that the US position should be read as a support of the > >Agreed by whom? By some who have the capacity to do it and that the US position acknowledges as in charge, as far as it has been quickly discussed evaluated. There is no reason to think ohers would see it differently: they share the same interests as the US Governments, within the frame of their own culture and policies. Obviously now the international community is to organise its intergovernance. With the hope that this WG will cease to be one of its problem. The USA considered their critical infrastructure but also the American way of life (http://whitehouse.gov/pcipb) . Other countries consider also the same their language and culture. This WG will obviously not be an international problem, but certainly its Registry will be a reason for national alternative-IANA, based on the international community solutions (ISO). jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 11:15:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp6C7-0001kU-Em; Sun, 03 Jul 2005 11:15:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp6C6-0001jr-L4 for ltru@megatron.ietf.org; Sun, 03 Jul 2005 11:15:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07977 for ; Sun, 3 Jul 2005 11:15:40 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dp6cU-0006Wf-9s for ltru@ietf.org; Sun, 03 Jul 2005 11:42:59 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dp6C3-0002TB-0I for ltru@ietf.org; Sun, 03 Jul 2005 08:15:40 -0700 Message-Id: <6.2.1.2.2.20050703164412.041fcb00@mail.jefsey.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 03 Jul 2005 16:46:30 +0200 To: ltru@ietf.org From: r&d afrac Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ltru] NTIA Statement of Principles X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 apologise: I expected so much the return of the US policy to a common sense logic of national interests at the world digital ecosystem level that I did not realised, with the W.E., some has not been informed yet. Here is the link to the statement of Mr. Gallagher: http://www.ntia.doc.gov/ntiahome/domainname/USDNSprinciples_06302005.htm From two mails I received, I realise that this may be a shock to some, discovering there an opposition with the "IETF core values", by the main expected funder of Internet R&D (cf. RFC 3869). It is only a direct consequence of the "end to end" principle: States have responsibilities to their own ends, and to exercise them, in such an architecture, they must also control or really trust the other end. The USA only take into consideration the current IETF architecture. They have identified this a while ago (gateway protocols): http://whitehouse.gov/pcipb. Up to us to provide a solution and to reduce the risks of technical balkanisation. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 13:23:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp8C9-0008U8-QX; Sun, 03 Jul 2005 13:23:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp8C8-0008U3-9e for ltru@megatron.ietf.org; Sun, 03 Jul 2005 13:23:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18672 for ; Sun, 3 Jul 2005 13:23: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 1Dp8cX-0007q1-RH for ltru@ietf.org; Sun, 03 Jul 2005 13:51:10 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 3 Jul 2005 10:25: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] Referencing the Scheme within the Tag Date: Sun, 3 Jul 2005 10:25:24 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C014530@irvmbxw01.quest.com> Thread-Topic: [Ltru] Referencing the Scheme within the Tag Thread-Index: AcV/rC0vo43AfJ0bRaScXklXoaZW+wACZQDQAA8iDdA= From: "Addison Phillips" To: "Debbie Garside" , X-OriginalArrivalTime: 03 Jul 2005 17:25:25.0007 (UTC) FILETIME=[32BF41F0:01C57FF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Huh? You mean putting a subtag into the language tag to indicate what = kind (generation) of tag it is? The 3066bis scheme represents a narrowing of the 3066 grammar for = language tags. Unlike 3066, it represents a full description of every = subtag, including those unassigned by 3066bis. It will not be possible = to create a new, different, grammar for language tags without breaking = compatibility with 3066bis. Any "3066ter" or later will essentially = provide additional rules for putting things into the registry, not = modify the grammar of a tag. What will be more important to archivists will be the registry date. = This will define what subtags were valid at the time. (Once we switch to = a registry, the scheme itself is less important than the registry) Putting a subtag into the tag to indicate the scheme is a colossal waste = as it conveys no useful information. But I may be misunderstanding your = comment, since you put the (Scheme_RFC_3066_bis) on the left side of the = ABNF statement. 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 Debbie Garside > Sent: den 3 juli 2005 02:59 > To: ltru@ietf.org > Subject: [Ltru] Referencing the Scheme within the Tag >=20 > An issue that I still feel quite strongly about is the referencing of = the > encoding scheme within the language tag itself; I believe it is = essential > for long term archival processes. I would like to propose the = addition of > the following: >=20 > "Implementers MAY reference this scheme within the language tag itself > using > the following syntax: >=20 > Language-Tag (Scheme_RFC_3066_bis) =3D ..." or some such... >=20 > This would be particularly useful when tagging cultural information = for > archival purposes e.g. digitalised manuscripts. It would give = archivists > the ability to maintain, reference and update their systems. >=20 >=20 > Debbie Garside > www.linguasphere.com >=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 Jul 03 13:27:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp8Fy-0001DS-MS; Sun, 03 Jul 2005 13:27:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp8Fw-0001DN-U3 for ltru@megatron.ietf.org; Sun, 03 Jul 2005 13:27:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19059 for ; Sun, 3 Jul 2005 13: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 1Dp8gM-000860-L2 for ltru@ietf.org; Sun, 03 Jul 2005 13:55:07 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 3 Jul 2005 10:29: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] IANA ISO 3166 related Registries Date: Sun, 3 Jul 2005 10:29:23 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C014531@irvmbxw01.quest.com> Thread-Topic: [Ltru] IANA ISO 3166 related Registries Thread-Index: AcV/4mCEktCB+tQJQXKvLgHqlMPbGQAEcDsw From: "Addison Phillips" To: "r&d afrac" , "Randy Presuhn" , X-OriginalArrivalTime: 03 Jul 2005 17:29:24.0041 (UTC) FILETIME=[C138F390:01C57FF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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 What, pray tell, has this got to do with language tags? 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 r&d afrac > Sent: den 3 juli 2005 08:16 > To: Randy Presuhn; ltru@ietf.org > Subject: Re: [Ltru] IANA ISO 3166 related Registries >=20 > At 06:17 03/07/2005, Randy Presuhn wrote: > > > The position adopted by the USA concerning the control of the root > file > > > >What position in what forum are you talking about? >=20 > Sorry, due to its importance I expected this information was known to > everyone. I sent the URL in another mail. >=20 > >Is this in conjunction with your http://intlnet.org/eadmin.htm = project? > >Who would be the liaison contact for the IETF? >=20 > as previously explained ICANN published the ICP-3 document. IETF > disregarded the call. Intlnet carried this experimentation along with = the > ICANN guidlines (named dot-root). This permitted to identify both the > needs > (as the USA do today) and ways to address them. We incorporated AFRAC = to > explore the solutions we identified. The architectural stability of = the > world digital ecosystem and the end to end principle call for (at = least) > the national distribution of the reference sources (IANA): Common > Refeference Centers. The NICSO has the mission to advise Govs, ccTLDs = and > National Internet Communities over the transition. >=20 > > > consensus is that every IANA Registry using ISO 3166 codes will be > from now > > > >The consensus of whom? >=20 > The people I polled who are involved in the study/project of a CRC > projects > interested in the AFRAC work. >=20 > > > on deemed representing an US position, unless it is transferred to = the > > > ICANN IANA zone, on such case the authority should be the GAC. The > > > >The logic of how the use of an ISO international standard could be > construed > >as representing a US position completely eludes me. >=20 > Read the US Statement of Principles. >=20 > > > consensus is that generally the US point of view on local culture = does > bear > > > >I'm curious to learn what this "US point of view on local culture" is > >and where (and by whom) this weighty pronouncement was made. >=20 > the many who would like to know it! >=20 >=20 > > > enough weight to be worth the continuation of the effort engaged = since > > > December. Also it is that priority will be given to the root files = and > that > > > any organisation proposing a distributed IANA copy will support = the > langtag > > > Registry decided by its own Culture Ministry. > > > >I don't think the US even has a Culture Ministry. >=20 > This is precisely the problem :-) >=20 > >If there is one, it goes by some other name and keeps a *very* low > profile. >=20 > You may know that in many countries of the world, this Ministry is a = key > one. What is really a problem is that ietf-languages may consider = deciding > anything about languages and countries without involving these = Ministries. > And that this Draft does not consider them. >=20 > > > It is also agreed that the US position should be read as a support = of > the > > > >Agreed by whom? >=20 > By some who have the capacity to do it and that the US position > acknowledges as in charge, as far as it has been quickly discussed > evaluated. There is no reason to think ohers would see it differently: > they > share the same interests as the US Governments, within the frame of = their > own culture and policies. Obviously now the international community is = to > organise its intergovernance. >=20 > With the hope that this WG will cease to be one of its problem. The = USA > considered their critical infrastructure but also the American way of = life > (http://whitehouse.gov/pcipb) . Other countries consider also the same > their language and culture. This WG will obviously not be an = international > problem, but certainly its Registry will be a reason for national > alternative-IANA, based on the international community solutions = (ISO). >=20 > 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 Sun Jul 03 14:02:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp8nc-0001tY-D2; Sun, 03 Jul 2005 14:02:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp8nb-0001tQ-AN for ltru@megatron.ietf.org; Sun, 03 Jul 2005 14:02:35 -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 OAA22800 for ; Sun, 3 Jul 2005 14:02:34 -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 <20050703180203.PQFZ14360.mta13.adelphia.net@DEWELL>; Sun, 3 Jul 2005 14:02:03 -0400 Message-ID: <000901c57ff9$289d2a20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" , Date: Sun, 3 Jul 2005 11:00:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: iso639-2@loc.gov Subject: [Ltru] Correct dates for Middle French? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 just found an inconsistency in the tables listed on the ISO 639-2/RA site for the code element "frm". These tables are linked from the page located at http://www.loc.gov/standards/iso639-2/langhome.html. In the tables sorted by English name of language and French name of language (both HTML and plain text), the associated language name is: French, Middle (ca.1400-1600) In the tables sorted by ISO 639-2 alpha-3 code (both HTML and two plain-text versions), the language name is: French, Middle (ca.1400-1800) In other words, the difference is between 1600 and 1800 as the ending date for "Middle French." Intuitively, 1600 seems more correct, and this is the version that has been used in the ISO/DIS 639-3 draft tables. However, the Initial Language Subtag Registry at http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-00.txt currently lists 1800, since it was generated from the ISO 639-2 table sorted by alpha-3 code. >From the LTRU and ietf-languages people, I would like confirmation that 1600 is the correct ending date, not 1800 as currently shown, and that this should be corrected in the registry. >From the ISO 639-2 people, I would like to request that the official tables be made consistent with each other, displaying the same association between codes and language names regardless of how the list is sorted. -- 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 Jul 03 14:36:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp9Jy-000265-QW; Sun, 03 Jul 2005 14: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 1Dp9Jw-00025z-N2 for ltru@megatron.ietf.org; Sun, 03 Jul 2005 14:36: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 OAA25554 for ; Sun, 3 Jul 2005 14:35:58 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dp9Je-000848-I0 for ltru@lists.ietf.org; Sun, 03 Jul 2005 20:35:42 +0200 Received: from 62.80.58.76 ([62.80.58.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Jul 2005 20:35:42 +0200 Received: from nobody by 62.80.58.76 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Jul 2005 20:35:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 03 Jul 2005 20:35:13 +0200 Organization: Lines: 12 Message-ID: <42C82FE1.758A@xyzzy.claranet.de> References: <200507030849.j638ni3C030546@smtp-los02.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: 62.80.58.76 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Referencing the Scheme within the 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Debbie Garside wrote: > "Implementers MAY reference this scheme within the language > tag itself using the following syntax: > Language-Tag (Scheme_RFC_3066_bis) = ..." or some such... Referencing meta data schemes is a different beast. What you want could be addressed by something like DC - *maybe* - as always when I try to understand a simple concept like dc:lang using Google I give up after wasting an hour of my time. Bye _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 14:50:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp9YN-0005u2-RF; Sun, 03 Jul 2005 14:50:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp9YM-0005tx-1A for ltru@megatron.ietf.org; Sun, 03 Jul 2005 14:50: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 OAA27253 for ; Sun, 3 Jul 2005 14:50:52 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dp9YA-0000oT-He for ltru@lists.ietf.org; Sun, 03 Jul 2005 20:50:47 +0200 Received: from 62.80.58.76 ([62.80.58.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Jul 2005 20:50:42 +0200 Received: from nobody by 62.80.58.76 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 03 Jul 2005 20:50:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 03 Jul 2005 20:48:27 +0200 Organization: Lines: 17 Message-ID: <42C832FB.4E58@xyzzy.claranet.de> References: <6.2.1.2.2.20050703164412.041fcb00@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: 62.80.58.76 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: NTIA Statement of Principles X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 r&d afrac wrote: > Here is the link to the statement of Mr. Gallagher: Somebody else could serve as IANA, we already discussed this. IIRC it was you who wanted the RfC 2860 MoU as "normative" for some finer points of the appeal procedures. > From two mails I received, I realise that this may be a > shock to some Their own format ".net" suicide shocked me more. But that's strictly off topic, unless you have new ideas about RfC 2860. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 15:00:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp9hM-0007zF-DH; Sun, 03 Jul 2005 15:00:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp9hL-0007zA-5O for ltru@megatron.ietf.org; Sun, 03 Jul 2005 15:00:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28073 for ; Sun, 3 Jul 2005 15:00:09 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpA7f-0006S8-AO for ltru@ietf.org; Sun, 03 Jul 2005 15:27:29 -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-242c8359718d; Sun, 03 Jul 2005 14:59:35 -0500 Received: from DEBHOME (ACC99C4A.ipt.aol.com [172.201.156.74]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j63IxR0v002882; Sun, 3 Jul 2005 14:59:28 -0400 Message-Id: <200507031859.j63IxR0v002882@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Addison Phillips'" , Subject: RE: [Ltru] Referencing the Scheme within the Tag Date: Sun, 3 Jul 2005 19:59:41 +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 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C014530@irvmbxw01.quest.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcV/rC0vo43AfJ0bRaScXklXoaZW+wACZQDQAA8iDdAAAvNEIA== X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.7 (++) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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 See in-line comments... > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: 03 July 2005 18:25 > To: Debbie Garside; ltru@ietf.org > Subject: RE: [Ltru] Referencing the Scheme within the Tag > > Huh? You mean putting a subtag into the language tag to indicate what kind > (generation) of tag it is? No, I do not mean putting a subtag into the language tag. I mean inserting a piece of text (as proposed) that will create a mechanism for archivists to be able to record and return "records" that match "RFC 3066 bis" in the language tag in some far off future maintenance/update scheme. There is also the issue of cross-over implementation dates, from one scheme to another (bis to ter perhaps); as we all know that implementers do not necessarily change their systems to match new standards immediately upon release so document date doesn't necessarily help. But I could be waffling a little here :-) > The 3066bis scheme represents a narrowing of the 3066 grammar for language > tags. Unlike 3066, it represents a full description of every subtag, > including those unassigned by 3066bis. It will not be possible to create a > new, different, grammar for language tags without breaking compatibility > with 3066bis. I am not talking backward compatibility, I'm talking forward extensibility, and retrieval for future maintenance and update procedures in a particular industry. > Any "3066ter" or later will essentially provide additional > rules for putting things into the registry, not modify the grammar of a > tag. Exactly. I am assuming that language tags in the future may incorporate more information e.g. written/spoken (something that will definitely rear its ugly head again in the future ter methinks). If an archivist cannot reference the scheme that has been used within the document they may have to look at each and every tag to see which scheme has been used. This would involve evaluating the document again to see whether the information is absent from the tag because it is not relevant to the document or because the scheme used at the time of encoding did not facilitate the incorporation of said information. > What will be more important to archivists will be the registry date. This > will define what subtags were valid at the time. (Once we switch to a > registry, the scheme itself is less important than the registry) Not true (possibly :-)). Given that the registry will, I assume (please correct me if I am wrong) never delete a tag (deprecate etc. but not delete), this is of no consequence. If a subtag is within a document using RFC 3066 bis or its successors, in theory, it SHOULD be within the registry. (Actually, looking at it from another point of view I can see your point! But I am assuming the registry is going to be forever changing as people register subtags, so what date would be used? But, that is another problem. The subtag registration date might help when analysing tags!) > Putting a subtag into the tag to indicate the scheme is a colossal waste > as it conveys no useful information. But I may be misunderstanding your > comment, since you put the (Scheme_RFC_3066_bis) on the left side of the > ABNF statement. My proposal will allow archivists to reference the scheme used and does not form an additional subtag. My intention was to put it on the left of the ABNF in order that it MAY be incorporated as a reference only if end users needs require but does not form part of the actual language subtag. I cannot see the harm in facilitating this; my proposal opens the door to another industry gaining good use from this standard (can never be a bad thing when thinking about knowledge grids). Personally, I think it would be SMART for the MAY to be SHOULD but then I like to have as much information available as possible; my philosophy only. By suggesting MAY I was trying not to tie other people into using this; I understand some users have space concerns. Kind regards Debbie Garside www.linguasphere.com > 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 Debbie Garside > > Sent: den 3 juli 2005 02:59 > > To: ltru@ietf.org > > Subject: [Ltru] Referencing the Scheme within the Tag > > > > An issue that I still feel quite strongly about is the referencing of > the > > encoding scheme within the language tag itself; I believe it is > essential > > for long term archival processes. I would like to propose the addition > of > > the following: > > > > "Implementers MAY reference this scheme within the language tag itself > > using > > the following syntax: > > > > Language-Tag (Scheme_RFC_3066_bis) = ..." or some such... > > > > This would be particularly useful when tagging cultural information for > > archival purposes e.g. digitalised manuscripts. It would give > archivists > > the ability to maintain, reference and update their systems. > > > > > > Debbie Garside > > www.linguasphere.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@lists.ietf.org Sun Jul 03 16:07:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpAkA-0008Av-CA; Sun, 03 Jul 2005 16: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 1DpAk9-0008Aq-Ix for ltru@megatron.ietf.org; Sun, 03 Jul 2005 16:07:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06075 for ; Sun, 3 Jul 2005 16:07:07 -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 1DpBAa-0002cM-BP for ltru@ietf.org; Sun, 03 Jul 2005 16:34:28 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 3 Jul 2005 13:08: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] Referencing the Scheme within the Tag Date: Sun, 3 Jul 2005 13:08:41 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C014532@irvmbxw01.quest.com> Thread-Topic: [Ltru] Referencing the Scheme within the Tag Thread-Index: AcV/rC0vo43AfJ0bRaScXklXoaZW+wACZQDQAA8iDdAAAvNEIAACqTGA From: "Addison Phillips" To: "Debbie Garside" , X-OriginalArrivalTime: 03 Jul 2005 20:08:41.0980 (UTC) FILETIME=[0232B3C0:01C5800B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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 below, excess text deleted. 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: den 3 juli 2005 12:00 > To: Addison Phillips; ltru@ietf.org > Subject: RE: [Ltru] Referencing the Scheme within the Tag > > > > Huh? You mean putting a subtag into the language tag to indicate = what > kind > > (generation) of tag it is? >=20 > No, I do not mean putting a subtag into the language tag. I mean > inserting > a piece of text (as proposed) that will create a mechanism for = archivists > to > be able to record and return "records" that match "RFC 3066 bis" in = the > language tag in some far off future maintenance/update scheme. [Addison Phillips]=20 The text you propose would be in the ABNF definition of the term = "Language Tag". It is unlikely to be referenced anywhere except in the = 3066bis document. Instead, references will be to the RFC or BCP number = of the document. >=20 > There is also the issue of cross-over implementation dates, from one > scheme > to another (bis to ter perhaps);=20 [Addison Phillips]=20 Which don't matter: all RFC 3066 tags are also RFC 3066bis tags. The = same will be true of the bis->ter transition. What will change are the = entries in the registry (there will presumably be more of them). >=20 > > The 3066bis scheme represents a narrowing of the 3066 grammar for > language > > tags. Unlike 3066, it represents a full description of every subtag, > > including those unassigned by 3066bis. It will not be possible to = create > a > > new, different, grammar for language tags without breaking = compatibility > > with 3066bis. >=20 > I am not talking backward compatibility, I'm talking forward = extensibility, > and retrieval for future maintenance and update procedures in a = particular > industry. [Addison Phillips]=20 The registry provides dates that can be referenced and the rules in bis = do not allow subtags to become extinct or be reused. If a future version = were to provide for such instability, then *it* should define ways for = implementations to identify themselves. What's important is: "I have a language tag" and then divining what the = subtags are.=20 >=20 > > Any "3066ter" or later will essentially provide additional > > rules for putting things into the registry, not modify the grammar = of a > > tag. >=20 > Exactly. I am assuming that language tags in the future may = incorporate > more > information e.g. written/spoken (something that will definitely rear = its > ugly head again in the future ter methinks). If an archivist cannot > reference the scheme that has been used within the document they may = have > to > look at each and every tag to see which scheme has been used.=20 [Addison Phillips]=20 No, they will have to look at the subtags and refer to the registry to = determine the meaning of each. Additional subtag types might come into = existence, but these will be defined in some future version of the 3066 = series. 3066bis implementations will only know that "I have a variant = subtag" or "I have an extension subtag" or even "I have an extended = language subtag", but not the given additional meaning. This is NOT bad. = It is good: it means that 3066bis implementations are somewhat future = proof! The stability rules allow archivists to be confident that we won't go = changing the meaning of their tags: it is a key element of the new = document. This would > involve evaluating the document again to see whether the information = is > absent from the tag because it is not relevant to the document or = because > the scheme used at the time of encoding did not facilitate the > incorporation > of said information. [Addison Phillips]=20 Okay, I see what you're saying: someone might want to retag to use new, = more granular semantics (hmm... like ISO 639-6, eh?). If any = equivalencies have been established, then the current 3066bis++ registry = will contain the mappings that allow one to track forward. If no = equivalencies have been established, then content owners will have to = decide (but their tags will still convey the original meaning). >=20 > > What will be more important to archivists will be the registry date. > This > > will define what subtags were valid at the time. (Once we switch to = a > > registry, the scheme itself is less important than the registry) >=20 > Not true (possibly :-)). Given that the registry will, I assume = (please > correct me if I am wrong) never delete a tag (deprecate etc. but not > delete), this is of no consequence. If a subtag is within a document > using > RFC 3066 bis or its successors, in theory, it SHOULD be within the > registry. > (Actually, looking at it from another point of view I can see your = point! > But I am assuming the registry is going to be forever changing as = people > register subtags, so what date would be used? But, that is another = problem. > The subtag registration date might help when analysing tags!) [Addison Phillips]=20 Which is why it exists. >=20 > > Putting a subtag into the tag to indicate the scheme is a colossal = waste > > as it conveys no useful information. But I may be misunderstanding = your > > comment, since you put the (Scheme_RFC_3066_bis) on the left side of = the > > ABNF statement. >=20 > My proposal will allow archivists to reference the scheme used and = does > not > form an additional subtag. My intention was to put it on the left of = the > ABNF in order that it MAY be incorporated as a reference only if end = users > needs require but does not form part of the actual language subtag. I > cannot > see the harm in facilitating this; my proposal opens the door to = another > industry gaining good use from this standard (can never be a bad thing > when > thinking about knowledge grids). [Addison Phillips]=20 They should reference the parent document and not the scheme in the = ABNF. That is a more reliable and complete reference anyway. >=20 > Personally, I think it would be SMART for the MAY to be SHOULD but = then I > like to have as much information available as possible; my philosophy = only. > By suggesting MAY I was trying not to tie other people into using = this; I > understand some users have space concerns. >=20 Referencing the document does this. There are references to RFC 1766 = that exist in the world and they communicate specific restrictions on = language tags and the subtags used to form them, for example. Best Regards, Addison _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 16:44:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpBKA-0000AP-FA; Sun, 03 Jul 2005 16:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpBK7-00009g-3j for ltru@megatron.ietf.org; Sun, 03 Jul 2005 16:44:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08755 for ; Sun, 3 Jul 2005 16:44:17 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpBkT-0005Og-71 for ltru@ietf.org; Sun, 03 Jul 2005 17:11:38 -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 RELAYIN6-742c84e0a166; Sun, 03 Jul 2005 16:43:54 -0500 Received: from DEBHOME (ACC99C4A.ipt.aol.com [172.201.156.74]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j63Khg23004324; Sun, 3 Jul 2005 16:43:43 -0400 Message-Id: <200507032043.j63Khg23004324@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Addison Phillips'" , Subject: RE: [Ltru] Referencing the Scheme within the Tag Date: Sun, 3 Jul 2005 21:43:57 +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 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C014532@irvmbxw01.quest.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcV/rC0vo43AfJ0bRaScXklXoaZW+wACZQDQAA8iDdAAAvNEIAACqTGAAADaW6A= X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.7 (++) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 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 > No, they will have to look at the subtags and refer to the registry to > determine the meaning of each. Additional subtag types might come into > existence, but these will be defined in some future version of the 3066 > series. 3066bis implementations will only know that "I have a variant > subtag" or "I have an extension subtag" or even "I have an extended > language subtag", but not the given additional meaning. This is NOT bad. > It is good: it means that 3066bis implementations are somewhat future > proof! I agree! But matching a tag or determining what a tag means is not my point. > The stability rules allow archivists to be confident that we won't go > changing the meaning of their tags: it is a key element of the new > document. And fabulous it is I'm sure! But this was not my point either! > Okay, I see what you're saying: someone might want to retag to use new, > more granular semantics Yes! Now we are getting there! > (hmm... like ISO 639-6, eh?). Well yes, if you want to look at it that way... but not just 639-6 ANY other additions/extensions that may occur in future updates... What harm is there in my proposal? Kind regards Debbie > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: 03 July 2005 21:09 > To: Debbie Garside; ltru@ietf.org > Subject: RE: [Ltru] Referencing the Scheme within the Tag > > Comments below, excess text deleted. > > 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: den 3 juli 2005 12:00 > > To: Addison Phillips; ltru@ietf.org > > Subject: RE: [Ltru] Referencing the Scheme within the Tag > > > > > > Huh? You mean putting a subtag into the language tag to indicate what > > kind > > > (generation) of tag it is? > > > > No, I do not mean putting a subtag into the language tag. I mean > > inserting > > a piece of text (as proposed) that will create a mechanism for > archivists > > to > > be able to record and return "records" that match "RFC 3066 bis" in the > > language tag in some far off future maintenance/update scheme. > [Addison Phillips] > > The text you propose would be in the ABNF definition of the term "Language > Tag". It is unlikely to be referenced anywhere except in the 3066bis > document. Instead, references will be to the RFC or BCP number of the > document. > > > > > There is also the issue of cross-over implementation dates, from one > > scheme > > to another (bis to ter perhaps); > [Addison Phillips] > > Which don't matter: all RFC 3066 tags are also RFC 3066bis tags. The same > will be true of the bis->ter transition. What will change are the entries > in the registry (there will presumably be more of them). > > > > > > The 3066bis scheme represents a narrowing of the 3066 grammar for > > language > > > tags. Unlike 3066, it represents a full description of every subtag, > > > including those unassigned by 3066bis. It will not be possible to > create > > a > > > new, different, grammar for language tags without breaking > compatibility > > > with 3066bis. > > > > I am not talking backward compatibility, I'm talking forward > extensibility, > > and retrieval for future maintenance and update procedures in a > particular > > industry. > [Addison Phillips] > > The registry provides dates that can be referenced and the rules in bis do > not allow subtags to become extinct or be reused. If a future version were > to provide for such instability, then *it* should define ways for > implementations to identify themselves. > > > What's important is: "I have a language tag" and then divining what the > subtags are. > > > > > Any "3066ter" or later will essentially provide additional > > > rules for putting things into the registry, not modify the grammar of > a > > > tag. > > > > Exactly. I am assuming that language tags in the future may incorporate > > more > > information e.g. written/spoken (something that will definitely rear its > > ugly head again in the future ter methinks). If an archivist cannot > > reference the scheme that has been used within the document they may > have > > to > > look at each and every tag to see which scheme has been used. > [Addison Phillips] > > No, they will have to look at the subtags and refer to the registry to > determine the meaning of each. Additional subtag types might come into > existence, but these will be defined in some future version of the 3066 > series. 3066bis implementations will only know that "I have a variant > subtag" or "I have an extension subtag" or even "I have an extended > language subtag", but not the given additional meaning. This is NOT bad. > It is good: it means that 3066bis implementations are somewhat future > proof! > > The stability rules allow archivists to be confident that we won't go > changing the meaning of their tags: it is a key element of the new > document. > > > This would > > involve evaluating the document again to see whether the information is > > absent from the tag because it is not relevant to the document or > because > > the scheme used at the time of encoding did not facilitate the > > incorporation > > of said information. > [Addison Phillips] > > Okay, I see what you're saying: someone might want to retag to use new, > more granular semantics (hmm... like ISO 639-6, eh?). If any equivalencies > have been established, then the current 3066bis++ registry will contain > the mappings that allow one to track forward. If no equivalencies have > been established, then content owners will have to decide (but their tags > will still convey the original meaning). > > > > > What will be more important to archivists will be the registry date. > > This > > > will define what subtags were valid at the time. (Once we switch to a > > > registry, the scheme itself is less important than the registry) > > > > Not true (possibly :-)). Given that the registry will, I assume (please > > correct me if I am wrong) never delete a tag (deprecate etc. but not > > delete), this is of no consequence. If a subtag is within a document > > using > > RFC 3066 bis or its successors, in theory, it SHOULD be within the > > registry. > > (Actually, looking at it from another point of view I can see your > point! > > But I am assuming the registry is going to be forever changing as people > > register subtags, so what date would be used? But, that is another > problem. > > The subtag registration date might help when analysing tags!) > [Addison Phillips] > > Which is why it exists. > > > > > Putting a subtag into the tag to indicate the scheme is a colossal > waste > > > as it conveys no useful information. But I may be misunderstanding > your > > > comment, since you put the (Scheme_RFC_3066_bis) on the left side of > the > > > ABNF statement. > > > > My proposal will allow archivists to reference the scheme used and does > > not > > form an additional subtag. My intention was to put it on the left of > the > > ABNF in order that it MAY be incorporated as a reference only if end > users > > needs require but does not form part of the actual language subtag. I > > cannot > > see the harm in facilitating this; my proposal opens the door to another > > industry gaining good use from this standard (can never be a bad thing > > when > > thinking about knowledge grids). > [Addison Phillips] > > They should reference the parent document and not the scheme in the ABNF. > That is a more reliable and complete reference anyway. > > > > Personally, I think it would be SMART for the MAY to be SHOULD but then > I > > like to have as much information available as possible; my philosophy > only. > > By suggesting MAY I was trying not to tie other people into using this; > I > > understand some users have space concerns. > > > Referencing the document does this. There are references to RFC 1766 that > exist in the world and they communicate specific restrictions on language > tags and the subtags used to form them, for example. > > Best Regards, > > Addison _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 21:13:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpFWo-0007On-Cq; Sun, 03 Jul 2005 21:13:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpFWm-0007OT-Vv for ltru@megatron.ietf.org; Sun, 03 Jul 2005 21:13:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02647 for ; Sun, 3 Jul 2005 21:13:39 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpFxG-00083Q-Fl for ltru@ietf.org; Sun, 03 Jul 2005 21:41:02 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DpFWZ-0007eV-VK; Sun, 03 Jul 2005 18:13:28 -0700 Message-Id: <6.2.1.2.2.20050704013531.04772090@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 04 Jul 2005 02:01:08 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: NTIA Statement of Principles In-Reply-To: <42C832FB.4E58@xyzzy.claranet.de> References: <6.2.1.2.2.20050703164412.041fcb00@mail.jefsey.com> <42C832FB.4E58@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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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:48 03/07/2005, Frank Ellermann wrote: >r&d afrac wrote: > > > Here is the link to the statement of Mr. Gallagher: >Somebody else could serve as IANA, we already discussed this. >IIRC it was you who wanted the RfC 2860 MoU as "normative" >for some finer points of the appeal procedures. > > > From two mails I received, I realise that this may be a > > shock to some > >Their own format ".net" suicide shocked me more. But that's >strictly off topic, unless you have new ideas about RfC 2860. Hi! Frank, RFC 2860 bis is under general discussion with Brian Carpenter discussing it and a Draft from John Klensin. The real issue is now to know if we are going to have at IANA level a contention similar to the "alt-roots" with USA, China, Europe, etc. playing alt-IANA. Obviously not as simple as that. But this is roughly what we all want to avoid. Already complex enough with 192 States, 260 TLDs, no need at this stage to add confusion with 7500 languages. The problem is that everyone including WGIG, USA, IEFT think in terms of an old "mono" architecture asking features that only a non tested or even investigated "multi" architecture could deliver. WGIG has not identified the problem and forced the USA to move, before they announce their conclusions. USA have identified the problem and do not know who is going to technically address it (IETF, ITU, DoD, Open Sources?) from what they officialy say. In this perspective, RFC 2860 de facto does not exist anymore. Its legitimacy is based upon the White Book and the IANA contract. RFC 2860 could be replaced by an ISOC (IASA) co-operative agreement with the USG or any other agreement. There is an audit of the ICANN contract by the General Accounting Office which question many things in case of change. The USA have clarified the back-ground and underlined the problem they see. This is great. But this does not mean that their choices are the good one (I tend to think some are imposed by the lacks of the technology, and others by protectionism). Our job is to see how we can best support people. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 21:13:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpFWo-0007PE-P7; Sun, 03 Jul 2005 21:13:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpFWn-0007OU-1w for ltru@megatron.ietf.org; Sun, 03 Jul 2005 21:13:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02651 for ; Sun, 3 Jul 2005 21:13:39 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpFxG-00083L-Fp for ltru@ietf.org; Sun, 03 Jul 2005 21:41:02 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DpFWY-0007eV-QJ; Sun, 03 Jul 2005 18:13:27 -0700 Message-Id: <6.2.1.2.2.20050703204019.0477c180@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 04 Jul 2005 03:13:19 +0200 To: "Addison Phillips" From: r&d afrac Subject: RE: [Ltru] IANA ISO 3166 related Registries In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C014531@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C014531@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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 On 19:29 03/07/2005, Addison Phillips said: >What, pray tell, has this got to do with language tags? This is clear enough. The US Statement changes the nature of the IANA from a global reference center into a national reference center, like AFRAC will be one and most probably each country will soon experiment one. This is not because an RFC says this or that, or because ietf-languages will adopt a langtag or not, that it will translate into these Registries. This will be because the reference centers intergovernance will adhere to your proposition or to a registration. 1. obviously there is work ahead to get this reference centers operational. My fear was that you would create additional confusion before the ISO Varsaw meeting and the USA would announce their new strategy. And this way you would delay our effort. 2. now if you want langtags to be supported by the Internet Registry System, you will have to convince us, not only the IESG. To convince us (whatever the way this intergovernance will formed in coming months) you will have IMHO to demonstrate: 1. your project is not contentious. This means that its Registry is controled in a way acceptable to all. The rule which will prevail is subsidiarity: the one who is concerned is the one who decides: experts advise, locals decide. A good transition rule is that Registries using ISO 3166 or/and ISO 639 codes (a) becomes part of the name and numbers ICANN reserved area (RFC 2860) and be under GAC final control (b) to impose them to harmonize with ISO 11179 and with the results on distributed CRCs experimentation. 2. your project is to be a network project. This means that it should be consistent in every relational layers and core services - including DNS, OPES, etc. I explained what it means as far as AFRAC is concerned. 1. the langtag identifies a relational channel protocol. This means that it defines a protocol permitting person to person interintelligibility. 2. this means that a dysimetrical receiving (concepts)/sending(values) ends negotiation using language, mode and cultural environment (what documents the protocol), referent (what refers to the channel) and context (what refers to the relations) elements. 3. anyone can register any non conflicting form of langtag in any format. The need is for end to end/person to person relation establishment/authentication. Formats, like yours, can stabilise or even aquire a defacto leadership or monopoly if they are adequate to usage. Is that clear? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 21:13:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpFWo-0007Pc-Tw; Sun, 03 Jul 2005 21:13:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpFWn-0007OV-3w for ltru@megatron.ietf.org; Sun, 03 Jul 2005 21:13:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02646 for ; Sun, 3 Jul 2005 21:13:39 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpFxG-00083Z-Fh for ltru@ietf.org; Sun, 03 Jul 2005 21:41:02 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DpFWc-0007eV-0Q; Sun, 03 Jul 2005 18:13:30 -0700 Message-Id: <6.2.1.2.2.20050704022458.05a300e0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 04 Jul 2005 02:42:25 +0200 To: "Debbie Garside" From: r&d afrac Subject: RE: [Ltru] Referencing the Scheme within the Tag In-Reply-To: <200507031859.j63IxR0v002882@smtp-los03.proxy.aol.com> References: <634978A7DF025A40BFEF33EB191E13BC0C014530@irvmbxw01.quest.com> <200507031859.j63IxR0v002882@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 - afrac.org 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 20:59 03/07/2005, Debbie Garside said: > > The 3066bis scheme represents a narrowing of the 3066 grammar for language > > tags. Unlike 3066, it represents a full description of every subtag, > > including those unassigned by 3066bis. It will not be possible to create a > > new, different, grammar for language tags without breaking compatibility > > with 3066bis. > >I am not talking backward compatibility, I'm talking forward extensibility, >and retrieval for future maintenance and update procedures in a particular >industry. Debbie, Addison describes his intent to rule the future. No objection to that, except he also wants to rule the net.(BCP 47) This not possible, the net is not to be narrowed but scaled. I have a question: Addison puts already too many information in his tag (too many, because they can have unexpected conflicts). Why do you want to add more? You do not have conflict in adding specialised metatags. What is actually the odd idea is an ABNF langtag when an XML or other open format could have solved all these problems much more simply? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 22:00:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpGGH-0006gr-0v; Sun, 03 Jul 2005 22:00:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpGGG-0006gm-8m for ltru@megatron.ietf.org; Sun, 03 Jul 2005 22:00: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 WAA06397 for ; Sun, 3 Jul 2005 22:00:37 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DpGFz-0005FA-SQ for ltru@lists.ietf.org; Mon, 04 Jul 2005 04:00:23 +0200 Received: from 62.80.58.76 ([62.80.58.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Jul 2005 04:00:23 +0200 Received: from nobody by 62.80.58.76 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Jul 2005 04:00:23 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 04 Jul 2005 03:57:40 +0200 Organization: Lines: 41 Message-ID: <42C89794.3EF1@xyzzy.claranet.de> References: <6.2.1.2.2.20050703164412.041fcb00@mail.jefsey.com> <42C832FB.4E58@xyzzy.claranet.de> <6.2.1.2.2.20050704013531.04772090@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.76 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: NTIA Statement of Principles X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 r&d afrac wrote: > RFC 2860 bis is under general discussion with Brian Carpenter > discussing it and a Draft from John Klensin. Yes, I read the IETF general list, and I've John's draft in my "collection" It's not about finding a new hoster for the IANA, it's about the definition of "IESG approval". Perfectly irrelevant for LTRU, it was always clear that there's no way to bypass the "language tag review" step in our procedure. You can't send a registration request directly to the IESG - that's the problem they had with this obscure IPv6 hop-by-hop option, if I understood this correctly. > The real issue is now to know if we are going to have at IANA > level a contention similar to the "alt-roots" with USA, > China, Europe, etc. playing alt-IANA. For the moment IANA is what the IETF says it is. And for the moment ns1.de.eu.orsn.net mirrors ICANN's servers, or at least that's what I think it does. > no need at this stage to add confusion with 7500 languages. I like the idea. But it will be 3066ter, Peter can't register them manually one after the other. 3066ter will simply offer a bulk registry update, add ISO 639-3 to the registry maybe after filtering any dupes. No confusion. > RFC 2860 de facto does not exist anymore. Fine, then let's delete it from the references. The last time I proposed this you didn't like it. Only an "informative" MoU, good riddance from our "normative" references. > Our job is to see how we can best support people. Reinventing ICANN isn't covered by our WG Charter, we're here to define a registry format, not the hoster of this registry. And as far as I'm concerned that job is finished. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 03 22:30:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpGil-0002nJ-QQ; Sun, 03 Jul 2005 22:30:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpGik-0002nD-IL for ltru@megatron.ietf.org; Sun, 03 Jul 2005 22:30:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08449 for ; Sun, 3 Jul 2005 22:30:04 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpH9E-00046B-37 for ltru@ietf.org; Sun, 03 Jul 2005 22:57:29 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DpGig-0001eB-FJ; Sun, 03 Jul 2005 19:30:02 -0700 Message-Id: <6.2.1.2.2.20050704042050.041381c0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 04 Jul 2005 04:28:43 +0200 To: Frank Ellermann From: r&d afrac Subject: Re: [Ltru] Re: NTIA Statement of Principles In-Reply-To: <42C89794.3EF1@xyzzy.claranet.de> References: <6.2.1.2.2.20050703164412.041fcb00@mail.jefsey.com> <42C832FB.4E58@xyzzy.claranet.de> <6.2.1.2.2.20050704013531.04772090@mail.afrac.org> <42C89794.3EF1@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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 I am afraid you miss the point. There is _no_more_ IANA. The IANA you consider was a registry/document repository for the whole network. Due to the growth of the network the USA contracted to give it to the Global Intenet Community: RFC 2860 and the work of this WG (which is to define a IANA Registry) are based on that. This contract will not be continued. RFC 2860 and this Draft must now consider what is their purpose: to support the Global community or to serve the USA through its national reference center and to deal with the constraints/advantages this may represent. jfc On 03:57 04/07/2005, Frank Ellermann said: >r&d afrac wrote: > > > RFC 2860 bis is under general discussion with Brian Carpenter > > discussing it and a Draft from John Klensin. > >Yes, I read the IETF general list, and I've John's draft in my >"collection" It's not about >finding a new hoster for the IANA, it's about the definition of >"IESG approval". Perfectly irrelevant for LTRU, it was always >clear that there's no way to bypass the "language tag review" >step in our procedure. You can't send a registration request >directly to the IESG - that's the problem they had with this >obscure IPv6 hop-by-hop option, if I understood this correctly. > > > The real issue is now to know if we are going to have at IANA > > level a contention similar to the "alt-roots" with USA, > > China, Europe, etc. playing alt-IANA. > >For the moment IANA is what the IETF says it is. And for the >moment ns1.de.eu.orsn.net mirrors ICANN's servers, or at least >that's what I think it does. > > > no need at this stage to add confusion with 7500 languages. > >I like the idea. But it will be 3066ter, Peter can't register >them manually one after the other. 3066ter will simply offer a >bulk registry update, add ISO 639-3 to the registry maybe after >filtering any dupes. No confusion. > > > RFC 2860 de facto does not exist anymore. > >Fine, then let's delete it from the references. The last time >I proposed this you didn't like it. Only an "informative" MoU, >good riddance from our "normative" references. > > > Our job is to see how we can best support people. > >Reinventing ICANN isn't covered by our WG Charter, we're here >to define a registry format, not the hoster of this registry. >And as far as I'm concerned that job is finished. 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 Sun Jul 03 22:50:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpH2b-0005jK-CS; Sun, 03 Jul 2005 22:50:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpH2Z-0005jF-Mu for ltru@megatron.ietf.org; Sun, 03 Jul 2005 22:50:35 -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 WAA09813 for ; Sun, 3 Jul 2005 22:50:33 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DpH25-0000FJ-LP for ltru@lists.ietf.org; Mon, 04 Jul 2005 04:50:05 +0200 Received: from 62.80.58.76 ([62.80.58.76]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Jul 2005 04:50:05 +0200 Received: from nobody by 62.80.58.76 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Jul 2005 04:50:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 04 Jul 2005 04:47:56 +0200 Organization: Lines: 7 Message-ID: <42C8A35C.1EFA@xyzzy.claranet.de> References: <6.2.1.2.2.20050703164412.041fcb00@mail.jefsey.com> <42C832FB.4E58@xyzzy.claranet.de> <6.2.1.2.2.20050704013531.04772090@mail.afrac.org> <42C89794.3EF1@xyzzy.claranet.de> <6.2.1.2.2.20050704042050.041381c0@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 62.80.58.76 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: NTIA Statement of Principles X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 r&d afrac wrote: > I am afraid you miss the point. There is _no_more_ IANA. I've no problem with - alive and kicking. It's also still the same link from . Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 04 01:12:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpJG1-0001cE-9Y; Mon, 04 Jul 2005 01:12:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpJFw-0001c8-Br for ltru@megatron.ietf.org; Mon, 04 Jul 2005 01:12:34 -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 BAA20121 for ; Mon, 4 Jul 2005 01:12:31 -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 <20050704051200.EZQI14360.mta13.adelphia.net@DEWELL>; Mon, 4 Jul 2005 01:12:00 -0400 Message-ID: <003c01c58056$dae65c80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050704023055.JYPG21785.mta5.adelphia.net@megatron.ietf.org> Date: Sun, 3 Jul 2005 22:11: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 Cc: Subject: [Ltru] Re: IANA ISO 3166 related Registries X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 r&d afrac wrote: > Addison describes his intent to rule the future. No objection to that, > except he also wants to rule the net.(BCP 47) I am amazed and bewildered that this sort of personal abuse is allowed to continue, month after month. It makes me not want to participate any 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@lists.ietf.org Mon Jul 04 02:47:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpKkE-0007nx-H7; Mon, 04 Jul 2005 02:47:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpKkC-0007nf-Mh for ltru@megatron.ietf.org; Mon, 04 Jul 2005 02:47:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23011 for ; Mon, 4 Jul 2005 02:47:51 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpLAZ-0003vN-Ma for ltru@ietf.org; Mon, 04 Jul 2005 03:15:17 -0400 Received: from smtp-los01.proxy.aol.com (smtp-los01.proxy.aol.com [195.93.24.40]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN2-342c8db7135b; Mon, 04 Jul 2005 02:47:13 -0500 Received: from DEBHOME (ACC99C4A.ipt.aol.com [172.201.156.74]) by smtp-los01.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j646l9iT015837; Mon, 4 Jul 2005 02:47:09 -0400 Message-Id: <200507040647.j646l9iT015837@smtp-los01.proxy.aol.com> From: "Debbie Garside" To: "'r&d afrac'" Subject: RE: [Ltru] Referencing the Scheme within the Tag Date: Mon, 4 Jul 2005 07:47: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 In-Reply-To: <6.2.1.2.2.20050704022458.05a300e0@mail.afrac.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWANZTrh0kN3N2/Skymm6/jzLWvPAALZgrw X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.40 X-Spam-Score: 2.7 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi Jefsey I do not wish to add more information into the tag. I just want to reference the scheme. The fact that the scheme MAY be updated in the future to include additional information is part of the reason for requiring the reference. Kind regards Debbie > -----Original Message----- > From: r&d afrac [mailto:rd@afrac.org] > Sent: 04 July 2005 01:42 > To: Debbie Garside > Cc: ltru@ietf.org > Subject: RE: [Ltru] Referencing the Scheme within the Tag > > On 20:59 03/07/2005, Debbie Garside said: > > > The 3066bis scheme represents a narrowing of the 3066 grammar for > language > > > tags. Unlike 3066, it represents a full description of every subtag, > > > including those unassigned by 3066bis. It will not be possible to > create a > > > new, different, grammar for language tags without breaking > compatibility > > > with 3066bis. > > > >I am not talking backward compatibility, I'm talking forward > extensibility, > >and retrieval for future maintenance and update procedures in a > particular > >industry. > > Debbie, > Addison describes his intent to rule the future. No objection to that, > except he also wants to rule the net.(BCP 47) This not possible, the net > is > not to be narrowed but scaled. > > I have a question: Addison puts already too many information in his tag > (too many, because they can have unexpected conflicts). Why do you want to > add more? You do not have conflict in adding specialised metatags. What is > actually the odd idea is an ABNF langtag when an XML or other open format > could have solved all these problems much more simply? > > jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 04 04:22:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpMDd-00082F-PW; Mon, 04 Jul 2005 04:22:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpMDb-00082A-6j for ltru@megatron.ietf.org; Mon, 04 Jul 2005 04:22:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04831 for ; Mon, 4 Jul 2005 04:22:17 -0400 (EDT) Received: from mail12.svc.cra.dublin.eircom.net ([159.134.118.28]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DpMe7-0002ax-Ln for ltru@ietf.org; Mon, 04 Jul 2005 04:49:44 -0400 Received: (qmail 67608 messnum 5762159 invoked from network[159.134.168.179/159-134-168-179.as1.prp.dublin.eircom.net]); 4 Jul 2005 08:22:03 -0000 Received: from 159-134-168-179.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.168.179) by mail12.svc.cra.dublin.eircom.net (qp 67608) with SMTP; 4 Jul 2005 08:22:03 -0000 Message-ID: <42C8F0F7.B0FFF67@egt.ie> Date: Mon, 04 Jul 2005 09:19: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 Subject: Re: [Ltru] Referencing the Scheme within the Tag References: <200507032043.j63Khg23004324@smtp-los03.proxy.aol.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 2.9 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA04831 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 Echoing DG's question (below). I see only advantage in her proposal. mg Scr=EDobh Debbie Garside: > ... > > Okay, I see what you're saying: someone might want to retag to use ne= w, > > more granular semantics >=20 > Yes! Now we are getting there! >=20 > > (hmm... like ISO 639-6, eh?). >=20 > Well yes, if you want to look at it that way... but not just 639-6 ANY = other > additions/extensions that may occur in future updates... >=20 > What harm is there in my proposal? >=20 > Kind regards >=20 > Debbie --=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 Jul 04 10:57:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSOT-0001ld-8t; Mon, 04 Jul 2005 10:57:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSOS-0001lX-9m for ltru@megatron.ietf.org; Mon, 04 Jul 2005 10:57:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26949 for ; Mon, 4 Jul 2005 10:57:54 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpSp2-00019P-Uy for ltru@ietf.org; Mon, 04 Jul 2005 11:25:25 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DpSOM-0005yJ-88; Mon, 04 Jul 2005 07:57:50 -0700 Message-Id: <6.2.1.2.2.20050704094915.04952d80@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 04 Jul 2005 10:15:15 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: IANA ISO 3166 related Registries In-Reply-To: <003c01c58056$dae65c80$030aa8c0@DEWELL> References: <20050704023055.JYPG21785.mta5.adelphia.net@megatron.ietf.org> <003c01c58056$dae65c80$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 - afrac.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 07:11 04/07/2005, Doug Ewell wrote: >r&d afrac wrote: > > > Addison describes his intent to rule the future. No objection to that, > > except he also wants to rule the net.(BCP 47) > >I am amazed and bewildered that this sort of personal abuse is allowed >to continue, month after month. It makes me not want to participate any >more. Which abuse ???? Your mail is either hurting without reason or a troll? Or it may also be that you are not familiar with the Internet architecture and with the Internet standard process? In that case: - Addison describes his plan which is to make what he calls RFC 3066 bis/ter to more and more define a grammar, semantic, etc. So every version stays compatible with the previous one (but not the previous one with the new one). This has the advantage to get at the end of the day a very strict, may be clear (if there are not too many complexity to address the legacy of the previous RFCs), an probably stable system. I have no problem with this, except that I do not understand its use. But Addison says he needs it. - the problem is that he also wants to make his draft to replace RFC 3066, what will make it ipso-facto the new BCP 47. BCP 47 is the current rule of the net in matter of languages. I do not see what can be abusive and personal in this??? This problem is the _only_ real problem of this Draft. It was documented at length by John Klensin, Dave Crocker and others during the last Last Call and will make the next Last Call fail. This lack of understanding of the Internet standard process by W3C people can be easily shown. You go on Google and look for "W3C RFC 3066" (and RFC3066): there are 14,950 responses. If you enter the same "W3C BCP 47", you get 675 responses (0.5%). This means that people refer to the non-canonical version of what they want to say, and that they will have to update all of them if the Draft is approved. Would they have understood the Internet standard process document management system, they would have most probably used BCP as a BCP can be updated, not an RFC, and is therefore canonical. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 04 10:58:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSOY-0001m8-G9; Mon, 04 Jul 2005 10: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 1DpSOS-0001lc-R0 for ltru@megatron.ietf.org; Mon, 04 Jul 2005 10:58:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26952 for ; Mon, 4 Jul 2005 10:57:55 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpSp2-00019Q-Uu for ltru@ietf.org; Mon, 04 Jul 2005 11:25:26 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DpSON-0005yJ-Aj; Mon, 04 Jul 2005 07:57:51 -0700 Message-Id: <6.2.1.2.2.20050704101614.04a3e0c0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 04 Jul 2005 10:29:22 +0200 To: "Debbie Garside" From: r&d afrac Subject: RE: [Ltru] Referencing the Scheme within the Tag In-Reply-To: <200507040647.j646l9iT015837@smtp-los01.proxy.aol.com> References: <6.2.1.2.2.20050704022458.05a300e0@mail.afrac.org> <200507040647.j646l9iT015837@smtp-los01.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 - afrac.org X-Spam-Score: 0.6 (/) 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 08:47 04/07/2005, Debbie Garside wrote: >Hi Jefsey >I do not wish to add more information into the tag. I just want to >reference the scheme. The fact that the scheme MAY be updated in the future >to include additional information is part of the reason for requiring the >reference. Debbie, RFC 3066 is used in a lot of places and the Draft "narrowing" changes its nature. It is likely that this new nature will not always be accepted, all the more in the new IANA context. This means that we will have several coexisting schemes as both the narrowing and the needs will increase. The result will probably be complex semantic (look at the added complexity by this fist narrowing level, after 18 versions: even the target is to make RFC 3066 ter as simple as they wanted RFC 3066 bis to be). There will be at least three coexisting schemes. This is why it seems much more promising to work on a private generalised x-tags open space along with an ISO 11179 approach, where all this issues will have to be addressed in the context of the present state of the art, without having to rebuild the wheel. The only fear I have is that ISO 11179 is complex and may very well be another X.500 story. This is why I wish to keep the multilingualism and the networking aspects under other fora (including IETF) control. So if an Internet vision had to emerge (like for LDAP) we could make it more easily. Designing it in the context of this WG could be possible (it was my request to ADs when I called for a WG-TAGS) but would call for far more people to assemble. I called for that on the IETF main list, but the chair opposed we had some of them on the list (but never heard about). jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 04 11:18:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSih-0006v7-JL; Mon, 04 Jul 2005 11:18:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSig-0006uB-JY for ltru@megatron.ietf.org; Mon, 04 Jul 2005 11:18:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00337 for ; Mon, 4 Jul 2005 11:18:48 -0400 (EDT) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpT9B-0003Hz-QG for ltru@ietf.org; Mon, 04 Jul 2005 11:46:20 -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 RELAYIN8-942c9533c297; Mon, 04 Jul 2005 11:18:20 -0500 Received: from DEBHOME (ACC99C4A.ipt.aol.com [172.201.156.74]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j64FI5xL004769; Mon, 4 Jul 2005 11:18:05 -0400 Message-Id: <200507041518.j64FI5xL004769@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'r&d afrac'" Subject: RE: [Ltru] Referencing the Scheme within the Tag Date: Mon, 4 Jul 2005 16:18:25 +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 In-Reply-To: <6.2.1.2.2.20050704101614.04a3e0c0@mail.afrac.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWAqMBbleIXfFAcQyGHl/qVwPSk7QAAKMyg X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.7 (++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org JFC wrote: > This means that we will have several > coexisting schemes as both the narrowing and the needs will increase. All the more reason to reference the scheme within the tag. > > The only fear I have is that ISO 11179 is complex. This is my view also. I have further investigations to do on this and would not at this stage (or possibly even at any stage) be suggesting to this WG to adopt ISO 11179. Initial discussions with industry suggest there MAY be a split view on its use; I don't know. I understand that this WG has already discussed 11179 and made the decision not to apply the standard at this stage. For my purposes so far, within the draft for 639-6 (and please remember this is not yet ratified by ISO), it works quite nicely. > Designing it in the context of this WG could be possible (it was my > request > to ADs when I called for a WG-TAGS) but would call for far more people to > assemble. I understand that this is an anonymous list; however, it would be interesting to know how many people are subscribed. Randy? Kind regards Debbie > -----Original Message----- > From: r&d afrac [mailto:rd@afrac.org] > Sent: 04 July 2005 09:29 > To: Debbie Garside > Cc: ltru@ietf.org > Subject: RE: [Ltru] Referencing the Scheme within the Tag > > At 08:47 04/07/2005, Debbie Garside wrote: > >Hi Jefsey > >I do not wish to add more information into the tag. I just want to > >reference the scheme. The fact that the scheme MAY be updated in the > future > >to include additional information is part of the reason for requiring the > >reference. > > Debbie, > RFC 3066 is used in a lot of places and the Draft "narrowing" changes its > nature. It is likely that this new nature will not always be accepted, all > the more in the new IANA context. This means that we will have several > coexisting schemes as both the narrowing and the needs will increase. The > result will probably be complex semantic (look at the added complexity by > this fist narrowing level, after 18 versions: even the target is to make > RFC 3066 ter as simple as they wanted RFC 3066 bis to be). There will be > at > least three coexisting schemes. This is why it seems much more promising > to > work on a private generalised x-tags open space along with an ISO 11179 > approach, where all this issues will have to be addressed in the context > of > the present state of the art, without having to rebuild the wheel. > > The only fear I have is that ISO 11179 is complex and may very well be > another X.500 story. This is why I wish to keep the multilingualism and > the > networking aspects under other fora (including IETF) control. So if an > Internet vision had to emerge (like for LDAP) we could make it more > easily. > Designing it in the context of this WG could be possible (it was my > request > to ADs when I called for a WG-TAGS) but would call for far more people to > assemble. I called for that on the IETF main list, but the chair opposed > we > had some of them on the list (but never heard about). > > jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 04 12:09:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpTVh-0000wy-4D; Mon, 04 Jul 2005 12:09:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpTVg-0000ws-2u for ltru@megatron.ietf.org; Mon, 04 Jul 2005 12:09:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06351 for ; Mon, 4 Jul 2005 12:09: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 1DpTwF-0007ZX-M4 for ltru@ietf.org; Mon, 04 Jul 2005 12:36:58 -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 Jul 2005 09:10: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] Referencing the Scheme within the Tag Date: Mon, 4 Jul 2005 09:10:59 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C014577@irvmbxw01.quest.com> Thread-Topic: [Ltru] Referencing the Scheme within the Tag Thread-Index: AcWAcfyY6kAelGG8QdW43IDEXGq18gAP+VAA From: "Addison Phillips" To: "Marion Gunn" X-OriginalArrivalTime: 04 Jul 2005 16:10:59.0974 (UTC) FILETIME=[F7CB0A60:01C580B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Okay, here's the main problem: we can't put a notation where you want it = and have valid ABNF. "Language-Tag" is not just some string. It is an = identifier. Secondly, the whole document should be referenced, not just the ABNF = (which will rarely be referenced). RFC numbers are not reused: it is = their sole advantage. Referencing RFC3066bis is a permanent way to say = which scheme you are using and will remain a useful reference even when = there is a "3066ter". Finally, there is a section in the document (2.2.9) that defines = conformance. This proposal belongs in that section. I'm not opposed to this minor adjustment, but I don't think it is = practical. 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: den 4 juli 2005 01:19 > Cc: ltru@ietf.org > Subject: Re: [Ltru] Referencing the Scheme within the Tag >=20 > Echoing DG's question (below). I see only advantage in her proposal. > mg >=20 > Scr=EDobh Debbie Garside: > > ... > > > Okay, I see what you're saying: someone might want to retag to use = new, > > > more granular semantics > > > > Yes! Now we are getting there! > > > > > (hmm... like ISO 639-6, eh?). > > > > Well yes, if you want to look at it that way... but not just 639-6 = ANY > other > > additions/extensions that may occur in future updates... > > > > What harm is there in my proposal? > > > > Kind regards > > > > Debbie > -- >=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 Jul 04 12:48:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpU7g-0001DY-5k; Mon, 04 Jul 2005 12: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 1DpU7e-0001D8-Hg for ltru@megatron.ietf.org; Mon, 04 Jul 2005 12:48:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11220 for ; Mon, 4 Jul 2005 12:48:39 -0400 (EDT) Received: from mta13.adelphia.net ([68.168.78.44]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpUYE-0002V3-6H for ltru@ietf.org; Mon, 04 Jul 2005 13:16:12 -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 <20050704164825.RQQW14360.mta13.adelphia.net@DEWELL> for ; Mon, 4 Jul 2005 12:48:25 -0400 Message-ID: <001d01c580b8$1d4f4800$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050704023055.JYPG21785.mta5.adelphia.net@megatron.ietf.org> <003c01c58056$dae65c80$030aa8c0@DEWELL> <6.2.1.2.2.20050704094915.04952d80@mail.afrac.org> Subject: Re: [Ltru] Re: IANA ISO 3166 related Registries Date: Mon, 4 Jul 2005 09:47: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: 057ebe9b96adec30a7efb2aeda4c26a4 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 r&d afrac wrote: >>> Addison describes his intent to rule the future. No objection to >>> that, except he also wants to rule the net.(BCP 47) >> >> I am amazed and bewildered that this sort of personal abuse is >> allowed to continue, month after month. It makes me not want to >> participate any more. > > Which abuse ???? Your mail is either hurting without reason or a > troll? This is not the first time you have claimed that either this WG or its members are trying to "rule the future" or "take over the world." This WG is trying to expand the existing mechanism for specifying the language of content on the Internet and elsewhere. You greatly overestimate the global importance of this project, and badly misunderstand the intentions of its participants. Making demonstrably false accusations that WG participants are trying to hijack the Internet, trample on the national rights of governments, take over control of ISO standards, and manipulate cultures is what is hurtful. Why don't you quote the e-mail in which Addison "describes his intent to rule the future"? Go ahead, I'll wait. > - Addison describes his plan Not just his. > which is to make what he calls RFC 3066 bis/ter to more and more > define a grammar, semantic, etc. So every version stays compatible > with the previous one (but not the previous one with the new one). > This has the advantage to get at the end of the day a very strict, may > be clear (if there are not too many complexity to address the legacy > of the previous RFCs), an probably stable system. I have no problem > with this, except that I do not understand its use. But Addison says > he needs it. RFC 1766 and 3066 already defined a grammar and semantic. The current draft expands on this. Lots of people need this, not just Addison personally, and not just the W3C. People have been saying this for over a year; you have chosen not to listen or believe. > - the problem is that he also wants to make his draft to replace RFC > 3066, what will make it ipso-facto the new BCP 47. BCP 47 is the > current rule of the net in matter of languages. In the matter of assigning short text strings to *represent* languages. This is an important distinction. None of this "tagging" activity has anything to do with defining, authorizing, sanctioning, supporting, or suppressing the languages themselves. They are just symbols. Why don't you go pick on Harald Alvestrand for trying to "rule the future" back in 2001, when RFC 3066 was published and made a BCP? > I do not see what can be abusive and personal in this??? Accusing Addison of trying to "rule the future" is abusive and personal. He is doing his job as WG participant and co-editor of a WG document. > This problem is the _only_ real problem of this Draft. It was > documented at length by John Klensin, Dave Crocker and others during > the last Last Call and will make the next Last Call fail. We are supposed to be moving forward, not obsessing on last December. But since you mention it, most of the criticism of the previous Last Call that I heard, as a member of ietf-languages (where most of those concerns were being aired), had to do with the fact that the document wasn't created by a WG, and as such had no charter or chair or AD, and thus no accountability and format review process. Now we have all of those things. > This lack of understanding of the Internet standard process by W3C > people can be easily shown. You go on Google and look for "W3C RFC > 3066" (and RFC3066): there are 14,950 responses. If you enter the same > "W3C BCP 47", you get 675 responses (0.5%). This means that people > refer to the non-canonical version of what they want to say, and that > they will have to update all of them if the Draft is approved. Would > they have understood the Internet standard process document management > system, they would have most probably used BCP as a BCP can be > updated, not an RFC, and is therefore canonical. It means that many more people on the Internet refer to RFC numbers than to BCP numbers. Criticizing and opposing our project is perfectly fine, and a normal part of the process. Accusing individuals of trying to take over the world is absolutely uncalled for. I am sure that there is some perfectly good reason why the co-chairs are allowing this personal sniping and misrepresentation to continue unchecked, but for the life of me I don't understand it. It will certainly make me think twice about volunteering to participate in another IETF WG, and it may cause me to leave this one. -- 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 Jul 04 15:29:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpWdj-0000s6-6m; Mon, 04 Jul 2005 15:29:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpWdi-0000s1-PY for ltru@megatron.ietf.org; Mon, 04 Jul 2005 15:29:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00798 for ; Mon, 4 Jul 2005 15:29:57 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpX4K-0005cR-Tb for ltru@ietf.org; Mon, 04 Jul 2005 15:57:30 -0400 Received: from h-68-165-6-198.snvacaid.dynamic.covad.net ([68.165.6.198] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DpWdf-0007F8-00 for ltru@ietf.org; Mon, 04 Jul 2005 15:29:55 -0400 Message-ID: <008701c580cf$5464b980$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200507041518.j64FI5xL004769@smtp-los03.proxy.aol.com> Subject: Re: [Ltru] Referencing the Scheme within the Tag Date: Mon, 4 Jul 2005 12:33:41 -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: 93238566e09e6e262849b4f805833007 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: "Debbie Garside" > To: "'r&d afrac'" > Cc: > Sent: Monday, July 04, 2005 8:18 AM > Subject: RE: [Ltru] Referencing the Scheme within the Tag ... > I understand that this is an anonymous list; however, it would be > interesting to know how many people are subscribed. Randy? ... It's not anonymous, in that postings are not anonymized. To keep spam down, the address listing isn't made available. There are currently 57 addresses subscribed. It's hard to know how many different people this comes to be, since we have a few people with multiple addresses subscribed, and I know that some of the subscribed addresses lead to distribution lists or news groups. 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 Jul 04 15:52:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpWzH-0004x1-4Z; Mon, 04 Jul 2005 15: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 1DpWzF-0004ww-D7 for ltru@megatron.ietf.org; Mon, 04 Jul 2005 15:52:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03713 for ; Mon, 4 Jul 2005 15:52:11 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpXPr-0006Yg-AY for ltru@ietf.org; Mon, 04 Jul 2005 16:19:44 -0400 Received: from h-68-165-6-198.snvacaid.dynamic.covad.net ([68.165.6.198] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DpWzC-0004gS-00; Mon, 04 Jul 2005 15:52:10 -0400 Message-ID: <008e01c580d2$6da451a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050704023055.JYPG21785.mta5.adelphia.net@megatron.ietf.org><003c01c58056$dae65c80$030aa8c0@DEWELL> <6.2.1.2.2.20050704094915.04952d80@mail.afrac.org> Date: Mon, 4 Jul 2005 12:56:11 -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: 0fa76816851382eb71b0a882ccdc29ac Cc: Subject: [Ltru] Suspending J.F.C. Morfin X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - Jefsey has once again become too disruptive, engaging in personal attacks, misrepresenting the positions of others, revisiting long-resolved issues, and generally impeding timely completion of our assigned task by causing other WG members to waste time. Pursuant to RFC 3934, I am suspending the posting privileges of his subscribed addresses to the ltru WG mailing list, for a period of up to 30 days. His posting privileges will be restored no later than August third, 2005. Randy, ltru co-chair ----- Original Message ----- > From: "r&d afrac" > To: "Doug Ewell" ; "LTRU Working Group" > Sent: Monday, July 04, 2005 1:15 AM > Subject: Re: [Ltru] Re: IANA ISO 3166 related Registries > > At 07:11 04/07/2005, Doug Ewell wrote: > >r&d afrac wrote: > > > > > Addison describes his intent to rule the future. No objection to that, > > > except he also wants to rule the net.(BCP 47) > > > >I am amazed and bewildered that this sort of personal abuse is allowed > >to continue, month after month. It makes me not want to participate any > >more. > > Which abuse ???? Your mail is either hurting without reason or a troll? Or > it may also be that you are not familiar with the Internet architecture and > with the Internet standard process? In that case: > > - Addison describes his plan which is to make what he calls RFC 3066 > bis/ter to more and more define a grammar, semantic, etc. So every version > stays compatible with the previous one (but not the previous one with the > new one). This has the advantage to get at the end of the day a very > strict, may be clear (if there are not too many complexity to address the > legacy of the previous RFCs), an probably stable system. I have no problem > with this, except that I do not understand its use. But Addison says he > needs it. > > - the problem is that he also wants to make his draft to replace RFC 3066, > what will make it ipso-facto the new BCP 47. BCP 47 is the current rule of > the net in matter of languages. > > I do not see what can be abusive and personal in this??? This problem is > the _only_ real problem of this Draft. It was documented at length by John > Klensin, Dave Crocker and others during the last Last Call and will make > the next Last Call fail. > > This lack of understanding of the Internet standard process by W3C people > can be easily shown. You go on Google and look for "W3C RFC 3066" (and > RFC3066): there are 14,950 responses. If you enter the same "W3C BCP 47", > you get 675 responses (0.5%). This means that people refer to the > non-canonical version of what they want to say, and that they will have to > update all of them if the Draft is approved. Would they have understood the > Internet standard process document management system, they would have most > probably used BCP as a BCP can be updated, not an RFC, and is therefore > canonical. > > 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 Jul 04 16:34:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpXe4-0005eD-A5; Mon, 04 Jul 2005 16:34:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpXe3-0005e8-6w for ltru@megatron.ietf.org; Mon, 04 Jul 2005 16:34:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09871 for ; Mon, 4 Jul 2005 16:34:21 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpY4a-00014c-Us for ltru@ietf.org; Mon, 04 Jul 2005 17:01:55 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN6-742c99d38310; Mon, 04 Jul 2005 16:34:00 -0500 Received: from DEBHOME (ACC99C4A.ipt.aol.com [172.201.156.74]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j64KXoTq004286; Mon, 4 Jul 2005 16:33:50 -0400 Message-Id: <200507042033.j64KXoTq004286@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Addison Phillips'" , "'Marion Gunn'" Subject: RE: [Ltru] Referencing the Scheme within the Tag Date: Mon, 4 Jul 2005 21:33:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C014577@irvmbxw01.quest.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWAcfyY6kAelGG8QdW43IDEXGq18gAP+VAAAAljbIA= X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 X-Spam-Score: 2.7 (++) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 Having looked at ABNF I revise the proposal as follows: Language-Tag[RFC3066bis]=3D.... Regards Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Addison Phillips > Sent: 04 July 2005 17:11 > To: Marion Gunn > Cc: ltru@ietf.org > Subject: RE: [Ltru] Referencing the Scheme within the Tag >=20 > Okay, here's the main problem: we can't put a notation where you want = it > and have valid ABNF. "Language-Tag" is not just some string. It is an > identifier. >=20 > Secondly, the whole document should be referenced, not just the ABNF > (which will rarely be referenced). RFC numbers are not reused: it is = their > sole advantage. Referencing RFC3066bis is a permanent way to say which > scheme you are using and will remain a useful reference even when = there is > a "3066ter". >=20 > Finally, there is a section in the document (2.2.9) that defines > conformance. This proposal belongs in that section. >=20 > I'm not opposed to this minor adjustment, but I don't think it is > practical. >=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 Marion Gunn > > Sent: den 4 juli 2005 01:19 > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Referencing the Scheme within the Tag > > > > Echoing DG's question (below). I see only advantage in her proposal. > > mg > > > > Scr=EDobh Debbie Garside: > > > ... > > > > Okay, I see what you're saying: someone might want to retag to = use > new, > > > > more granular semantics > > > > > > Yes! Now we are getting there! > > > > > > > (hmm... like ISO 639-6, eh?). > > > > > > Well yes, if you want to look at it that way... but not just 639-6 = ANY > > other > > > additions/extensions that may occur in future updates... > > > > > > What harm is there in my proposal? > > > > > > Kind regards > > > > > > Debbie > > -- > > > > 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 >=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 Jul 04 17:22:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpYP2-0007Ls-91; Mon, 04 Jul 2005 17:22:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpYP1-0007Jd-35 for ltru@megatron.ietf.org; Mon, 04 Jul 2005 17:22:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16572 for ; Mon, 4 Jul 2005 17:22:52 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpYpe-0004tC-5m for ltru@ietf.org; Mon, 04 Jul 2005 17:50:27 -0400 Received: from h-68-165-6-198.snvacaid.dynamic.covad.net ([68.165.6.198] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DpYOm-0001nT-00 for ltru@ietf.org; Mon, 04 Jul 2005 17:22:40 -0400 Message-ID: <000601c580df$12543ce0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200507042033.j64KXoTq004286@smtp-los02.proxy.aol.com> Subject: Re: [Ltru] Referencing the Scheme within the Tag Date: Mon, 4 Jul 2005 14:26: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: 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: "Debbie Garside" > To: "'Addison Phillips'" ; "'Marion Gunn'" > Cc: > Sent: Monday, July 04, 2005 1:33 PM > Subject: RE: [Ltru] Referencing the Scheme within the Tag > > Having looked at ABNF I revise the proposal as follows: > > Language-Tag[RFC3066bis]=.... ... Do you intend literally "RFC3066bis", or do you intend that the "3066bis" portion would be replaced by whatever RFC number is assigned to the registry draft during the publication process? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 04 17:42:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpYi7-0002mI-Cr; Mon, 04 Jul 2005 17: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 1DpYi6-0002mA-Bm for ltru@megatron.ietf.org; Mon, 04 Jul 2005 17:42:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18983 for ; Mon, 4 Jul 2005 17:42: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 1DpZ8f-0006Lf-M4 for ltru@ietf.org; Mon, 04 Jul 2005 18:10:10 -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-342c9ad35bd; Mon, 04 Jul 2005 17:42:14 -0500 Received: from DEBHOME (ACC99C4A.ipt.aol.com [172.201.156.74]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j64Lg8UY016654; Mon, 4 Jul 2005 17:42:08 -0400 Message-Id: <200507042142.j64Lg8UY016654@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'Randy Presuhn'" , Subject: RE: [Ltru] Referencing the Scheme within the Tag Date: Mon, 4 Jul 2005 22:42:09 +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 In-Reply-To: <000601c580df$12543ce0$7f1afea9@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWA3sU67hqTiGcUQkagoEVzI/AOKwAAMJ9w X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.101 X-Spam-Score: 2.7 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Randy wrote: >> or do you intend that the "3066bis" portion would be replaced by whatever >> RFC number is assigned to the registry draft during the publication >> process? Yes! So perhaps my proposal should state: Language-tag[RFC****]=... Regards Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > Sent: 04 July 2005 22:27 > To: ltru@ietf.org > Subject: Re: [Ltru] Referencing the Scheme within the Tag > > Hi - > > > From: "Debbie Garside" > > To: "'Addison Phillips'" ; "'Marion Gunn'" > > > Cc: > > Sent: Monday, July 04, 2005 1:33 PM > > Subject: RE: [Ltru] Referencing the Scheme within the Tag > > > > Having looked at ABNF I revise the proposal as follows: > > > > Language-Tag[RFC3066bis]=.... > ... > > Do you intend literally "RFC3066bis", or do you intend that the > "3066bis" portion would be replaced by whatever RFC number > is assigned to the registry draft during the publication process? > > 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 Jul 04 20:39:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpbT9-0007FZ-4f; Mon, 04 Jul 2005 20:39:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpbT7-0007DH-38 for ltru@megatron.ietf.org; Mon, 04 Jul 2005 20:39:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14715 for ; Mon, 4 Jul 2005 20:39:19 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpbtm-0003MX-1m for ltru@ietf.org; Mon, 04 Jul 2005 21:06:55 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jul 2005 17:39: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.1830); Mon, 4 Jul 2005 17:39:05 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Referencing the Scheme within the Tag Date: Mon, 4 Jul 2005 17:39:16 -0700 Message-ID: Thread-Topic: [Ltru] Referencing the Scheme within the Tag Thread-Index: AcV/rC0vo43AfJ0bRaScXklXoaZW+wACZQDQAA8iDdAAAvNEIAACqTGAAADaW6AAOoyzUA== From: "Peter Constable" To: X-OriginalArrivalTime: 05 Jul 2005 00:39:05.0669 (UTC) FILETIME=[F2AEEF50:01C580F9] X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Debbie Garside > What harm is there in my proposal? There's no harm in proposing something; there's only a risk of rabbit trails if a proposal isn't explained clearly. Now, is there harm in *adopting* your proposal? I'm not certain what you're proposing, so I can't say. If you're suggesting that the ABNF specify Language-Tag[RFC3066bis]=3D (lang *3("-" extlang) ["-" script] ["-" region] ... rather than=20 Language-Tag =3D (lang *3("-" extlang) ["-" script] ["-" region] ... then I think there's no harm, but I also think there's nothing accomplished. The RFC would still provide a single syntax; it just happens to name the start rule slightly differently. I think what you really want is the *consuming* protocols that use these metadata elements should add some kind of qualifier in their protocols to indicate what specification for the particular metadata category is in use. Something along the lines of=20 In general, I think this kind of meta-metadata can be useful, particularly if there's likelihood of re-architecting something. And while I don't foresee particular reasons for rearchitecting this category of metadata elements, it would be foolish to assume a need wouldn't arise in ten or twenty or fifty or more years. But, this is something that belongs in *consuming* protocols, not in this document. At most, this document can suggest that applications incorporate support for such meta-metadata. Given that there are lots of existing applications / consuming protocols of RFC 3066 that do *not* do this, and given that adding text of this sort isn't likely going to change them, I wouldn't make it a priority. Given that we are overdue and trying to drive toward completion, I'm reluctant to consider another addition at this time -- feature creep *can* harm us. If it's to be entertained at all, I'd suggest that this not be adopted unless some proposed text is provided promptly and there's a quick consensus that the proposed text is a useful addition. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 04 22:33:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpdFY-0006Z3-47; Mon, 04 Jul 2005 22: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 1DpdFV-0006Ym-4V for ltru@megatron.ietf.org; Mon, 04 Jul 2005 22:33: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 WAA27885 for ; Mon, 4 Jul 2005 22:33:22 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DpdFN-0001bB-GI for ltru@lists.ietf.org; Tue, 05 Jul 2005 04:33:17 +0200 Received: from 212.82.251.219 ([212.82.251.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Jul 2005 04:33:17 +0200 Received: from nobody by 212.82.251.219 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 05 Jul 2005 04:33:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 05 Jul 2005 04:32:39 +0200 Organization: Lines: 21 Message-ID: <42C9F147.698D@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.219 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Referencing the Scheme within the 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Peter Constable wrote: > If you're suggesting that the ABNF specify > Language-Tag[RFC3066bis]= (lang [...] > rather than > Language-Tag = (lang [...] > then I think there's no harm, but I also think there's > nothing accomplished. | The name of a rule is simply the name itself; that is, a | sequence of characters, beginning with an alphabetic | character, and followed by a combination of alphabetics, | digits and hyphens (dashes). No square brackets. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 04 23:06:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpdl5-0004k5-9R; Mon, 04 Jul 2005 23: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 1Dpdl3-0004ik-Hq for ltru@megatron.ietf.org; Mon, 04 Jul 2005 23:06:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01848 for ; Mon, 4 Jul 2005 23:05:59 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpeBi-0005kz-92 for ltru@ietf.org; Mon, 04 Jul 2005 23:33:36 -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 j6535eMp461520 for ; Mon, 4 Jul 2005 23:05:40 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6535eBV329776 for ; Mon, 4 Jul 2005 21:05:40 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j6535emj029287 for ; Mon, 4 Jul 2005 21:05:40 -0600 Received: from markdavis (sig-9-48-110-138.mts.ibm.com [9.48.110.138]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j6535co3029259; Mon, 4 Jul 2005 21:05:39 -0600 Message-ID: <092f01c5810e$6bb4e670$47763009@sanjose.ibm.com> From: "Mark Davis" To: "Peter Constable" , References: Subject: Re: [Ltru] Referencing the Scheme within the Tag Date: Mon, 4 Jul 2005 19:54: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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id j6535eMp461520 X-Spam-Score: 0.3 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 absolutely in accord with Peter. =E2=80=8EMark ----- Original Message -----=20 From: "Peter Constable" To: Sent: Monday, July 04, 2005 17:39 Subject: RE: [Ltru] Referencing the Scheme within the Tag > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Debbie Garside > What harm is there in my proposal? There's no harm in proposing something; there's only a risk of rabbit trails if a proposal isn't explained clearly. Now, is there harm in *adopting* your proposal? I'm not certain what you're proposing, so I can't say. If you're suggesting that the ABNF specify Language-Tag[RFC3066bis]=3D (lang *3("-" extlang) ["-" script] ["-" region] ... rather than Language-Tag =3D (lang *3("-" extlang) ["-" script] ["-" region] ... then I think there's no harm, but I also think there's nothing accomplished. The RFC would still provide a single syntax; it just happens to name the start rule slightly differently. I think what you really want is the *consuming* protocols that use these metadata elements should add some kind of qualifier in their protocols to indicate what specification for the particular metadata category is in use. Something along the lines of In general, I think this kind of meta-metadata can be useful, particularly if there's likelihood of re-architecting something. And while I don't foresee particular reasons for rearchitecting this category of metadata elements, it would be foolish to assume a need wouldn't arise in ten or twenty or fifty or more years. But, this is something that belongs in *consuming* protocols, not in this document. At most, this document can suggest that applications incorporate support for such meta-metadata. Given that there are lots of existing applications / consuming protocols of RFC 3066 that do *not* do this, and given that adding text of this sort isn't likely going to change them, I wouldn't make it a priority. Given that we are overdue and trying to drive toward completion, I'm reluctant to consider another addition at this time -- feature creep *can* harm us. If it's to be entertained at all, I'd suggest that this not be adopted unless some proposed text is provided promptly and there's a quick consensus that the proposed text is a useful addition. 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 Jul 05 00:57:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpfUy-0002PT-1x; Tue, 05 Jul 2005 00:57:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpfUx-0002PJ-Gp for ltru@megatron.ietf.org; Tue, 05 Jul 2005 00:57:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17577 for ; Tue, 5 Jul 2005 00:57:23 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpfvZ-0005zD-TM for ltru@ietf.org; Tue, 05 Jul 2005 01:25:02 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j654v0I12202; Tue, 5 Jul 2005 13:57:01 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id d406b4fe_ed12_11d9_80f1_0030482532aa_26471; Tue, 05 Jul 2005 14:08:30 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO006F62; 5 Jul 05 14:02:13 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 5 Jul 05 14:01:51 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG006F5E; 5 Jul 05 14:01:47 +0900 Message-Id: <6.0.0.20.2.20050705103622.0874cc40@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 05 Jul 2005 10:40:15 +0900 To: "Peter Constable" , From: Martin Duerst Subject: RE: [Ltru] Referencing the Scheme within the Tag In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.9 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 Personally, and technically, I have to agree with Peter. I'm also not sure ABNF allows '[' and ']' on the left side of productions (which could be fixed easily by changing the proposal to something like Languag-Tag-RFC-****, however). Please note that in general standards practice, it's the using standard that defines what spec to use, so e.g. a protocol or format spec using RFC3066bis will say something like "protocol element foo is a Language-Tag according to RFC 3066bis". Regards, Martin. At 09:39 05/07/05, Peter Constable wrote: >> From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] >On >> Behalf Of Debbie Garside > > >> What harm is there in my proposal? > >There's no harm in proposing something; there's only a risk of rabbit >trails if a proposal isn't explained clearly. Now, is there harm in >*adopting* your proposal? I'm not certain what you're proposing, so I >can't say. > >If you're suggesting that the ABNF specify > >Language-Tag[RFC3066bis]= (lang > *3("-" extlang) > ["-" script] > ["-" region] > ... > >rather than > >Language-Tag = (lang > *3("-" extlang) > ["-" script] > ["-" region] > ... > >then I think there's no harm, but I also think there's nothing >accomplished. The RFC would still provide a single syntax; it just >happens to name the start rule slightly differently. > >I think what you really want is the *consuming* protocols that use these >metadata elements should add some kind of qualifier in their protocols >to indicate what specification for the particular metadata category is >in use. Something along the lines of > > > >In general, I think this kind of meta-metadata can be useful, >particularly if there's likelihood of re-architecting something. And >while I don't foresee particular reasons for rearchitecting this >category of metadata elements, it would be foolish to assume a need >wouldn't arise in ten or twenty or fifty or more years. > >But, this is something that belongs in *consuming* protocols, not in >this document. At most, this document can suggest that applications >incorporate support for such meta-metadata. > >Given that there are lots of existing applications / consuming protocols >of RFC 3066 that do *not* do this, and given that adding text of this >sort isn't likely going to change them, I wouldn't make it a priority. >Given that we are overdue and trying to drive toward completion, I'm >reluctant to consider another addition at this time -- feature creep >*can* harm us. If it's to be entertained at all, I'd suggest that this >not be adopted unless some proposed text is provided promptly and >there's a quick consensus that the proposed text is a useful addition. > > > >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 Jul 05 13:36:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprLv-0001Gb-45; Tue, 05 Jul 2005 13:36:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprLt-0001Dq-FP for ltru@megatron.ietf.org; Tue, 05 Jul 2005 13:36:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28246 for ; Tue, 5 Jul 2005 13:36: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 1Dprdh-0002qX-P8 for ltru@ietf.org; Tue, 05 Jul 2005 13:55:24 -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 Jul 2005 10:29:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Jul 2005 10:29:11 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C014743@irvmbxw01.quest.com> Thread-Topic: last call scheduled? Thread-Index: AcWBhowtBKvUjnrvT+uZmDRYyuhdoA== From: "Addison Phillips" To: X-OriginalArrivalTime: 05 Jul 2005 17:29:11.0451 (UTC) FILETIME=[0E8B5EB0:01C58187] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] last call scheduled? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1572221621==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1572221621== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgUmFuZHkgYW5kIE1hcnRpbiwNCg0KSSBub3RlIHRoYXQgYSB3ZWVrIGhhcyBwYXNzZWQgc2lu Y2UgeW91IGRlY2xhcmVkIGFuIGludGVudGlvbiB0byBydW4gYSBXRyBMYXN0IENhbGwuIFBsZWFz ZSBhZHZpc2UgYWJvdXQgdGhlIHNjaGVkdWxlIGZvciBhIGxhc3QgY2FsbC4NCg0KVGhlIG9ubHkg bmV3IGlzc3VlIG9uIHRoZSByZWdpc3RyeSBkcmFmdCBpcyBEZWJiaWUgR2Fyc2lkZSdzIHJlcXVl c3QgZm9yIG5vcm1hdGl2ZSBsYW5ndWFnZSBhYm91dCB0aGUgaWRlbnRpZmllci9yZWZlcmVuY2Vz IHRvIHRoZSBpZGVudGlmaWVyIGluIHRoZSBBQk5GLiBJIGJlbGlldmUgdGhlIGNvbnNlbnN1cyBp cyBydW5uaW5nIGluIHRoZSBvdGhlciBkaXJlY3Rpb24gb24gdGhhdCBpdGVtLiBFdmVuIGlmIGEg bWlub3IgY2hhbmdlIHdlcmUgbWFkZSB0byBhY2NvbW1vZGF0ZSBpdCwgdGhlcmUgd291bGQgYmUg dmVyeSBsaXR0bGUgdGV4dHVhbCBjaGFuZ2UgaW52b2x2ZWQuDQoNCkFyZSB3ZSB3YWl0aW5nIG9u IERvdWcgdG8gcG9zdCBpbml0aWFsLTAxPyBJIGRvbid0IHdhbnQgdGhlIHdlZWtzIHRvIHNsaXAg YXdheS4uLiBJJ3ZlIGJlZW4gd2FpdGluZyBvbiB0aGlzIHdvcmsgYSBsb25nIHRpbWUuDQoNCkFk ZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1 ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpDaGFpciwgVzNDIEludGVybmF0 aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDovL3d3dy53My5vcmcvSW50ZXJu YXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMg YW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============1572221621== 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 --===============1572221621==-- From ltru-bounces@lists.ietf.org Tue Jul 05 15:47:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DptNn-00011t-9S; Tue, 05 Jul 2005 15:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpeIz-00033d-IQ for ltru@megatron.ietf.org; Mon, 04 Jul 2005 23:41:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06623 for ; Mon, 4 Jul 2005 23:41:03 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpeje-0008VD-DF for ltru@ietf.org; Tue, 05 Jul 2005 00:08:41 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DpeIn-0006Fd-5H; Mon, 04 Jul 2005 20:40:53 -0700 Message-Id: <6.2.1.2.2.20050704182959.04ead220@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 05 Jul 2005 05:40:47 +0200 To: "Addison Phillips" , "Marion Gunn" From: r&d afrac Subject: RE: [Ltru] Referencing the Scheme within the Tag In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C014577@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C014577@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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Tue, 05 Jul 2005 15:46:58 -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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dear Marion, multilingualisation is a top priority of the WGIG. We will therefore most probably extensively discuss it through the coming months. For the reasons Addison gives and I documented in another mail, RFC 3066 will probably stay around until replaced by BCP 47 documenting the Multilingual Internet Framework or the MGN (Multilingual Global NGN). This is why we will keep http://rfc3066.org active and will document the various schemes (RFC 3066, "RFC 3066bis" and "RFC 3066ter" if they are published, x-tags, etc.). Once the issue stabilised, the site will be transfered to the CRC conference for a community management/ jfc At 18:10 04/07/2005, Addison Phillips wrote: >Okay, here's the main problem: we can't put a notation where you want it >and have valid ABNF. "Language-Tag" is not just some string. It is an >identifier. > >Secondly, the whole document should be referenced, not just the ABNF >(which will rarely be referenced). RFC numbers are not reused: it is their >sole advantage. Referencing RFC3066bis is a permanent way to say which >scheme you are using and will remain a useful reference even when there is >a "3066ter". > >Finally, there is a section in the document (2.2.9) that defines >conformance. This proposal belongs in that section. > >I'm not opposed to this minor adjustment, but I don't think it is practical. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 05 15:47:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DptNp-000139-1L; Tue, 05 Jul 2005 15:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpniN-0002s7-6R for ltru@megatron.ietf.org; Tue, 05 Jul 2005 09:43:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28050 for ; Tue, 5 Jul 2005 08:53:27 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpliz-0002Wf-Jd for ltru@ietf.org; Tue, 05 Jul 2005 07:36:26 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DplI2-0007Q4-Qh; Tue, 05 Jul 2005 04:08:35 -0700 Message-Id: <6.2.1.2.2.20050705114128.05470160@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 05 Jul 2005 13:08:26 +0200 To: Martin Duerst , "Peter Constable" , , debbie@ictmarketing.co.uk From: r&d afrac Subject: RE: [Ltru] Referencing the Scheme within the Tag In-Reply-To: <6.0.0.20.2.20050705103622.0874cc40@itmail.it.aoyama.ac.jp> References: <6.0.0.20.2.20050705103622.0874cc40@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Tue, 05 Jul 2005 15:46:59 -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 At 03:40 05/07/2005, Martin Duerst wrote: >Personally, and technically, I have to agree with Peter. >I'm also not sure ABNF allows '[' and ']' on the left side >of productions (which could be fixed easily by changing the >proposal to something like Languag-Tag-RFC-****, however). > >Please note that in general standards practice, it's the >using standard that defines what spec to use, so e.g. a >protocol or format spec using RFC3066bis will say something >like "protocol element foo is a Language-Tag according to >RFC 3066bis". Debbie, as long as the "RFC 3066" does not define the (possibly conditional to the format) purpose (decriptive, normative, etc.) of the tag there will be a possible ambiguity on a considered langtag own internal ambiguity. If this langtag system develops in using ISO 3166/15924/639 usage will probably decide. I suppose that an other way may develop from http://rfc3066.org warning: the use of a comment. It will permit to enter: en-Latn-us as a general confusing entry: as discussed we do not know it if is an in/out/exchange - required/advised etc. en.air-Latn-us could be understood as en - context RFC 3066, in signal, required to pursue (this is just an hint: could also be en.a.i.r-Lantn-us) jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 05 15:47:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DptNp-00013w-GE; Tue, 05 Jul 2005 15:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpntz-0001Q8-0P for ltru@megatron.ietf.org; Tue, 05 Jul 2005 09:55:55 -0400 Received: from sun8.loc.gov (sun8.loc.gov [140.147.249.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23193 for ; Tue, 5 Jul 2005 09:55:52 -0400 (EDT) Received: from sun8.loc.gov (localhost [127.0.0.1]) by sun8.loc.gov with ESMTP id j65DtIUs026238; Tue, 5 Jul 2005 09:55:18 -0400 (EDT) Received: from localhost (rgue@localhost) by sun8.loc.gov with ESMTP id j65DtEXr026226; Tue, 5 Jul 2005 09:55:14 -0400 (EDT) X-Authentication-Warning: sun8.loc.gov: rgue owned process doing -bs Date: Tue, 5 Jul 2005 09:55:14 -0400 (EDT) From: "Rebecca S. Guenther" To: Doug Ewell In-Reply-To: <000901c57ff9$289d2a20$030aa8c0@DEWELL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 05 Jul 2005 15:47:00 -0400 Cc: ietf-languages@iana.org, LTRU Working Group Subject: [Ltru] Re: Correct dates for Middle French? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 should be 1400-1600. We will correct the ISO 639-2 tables. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^ Rebecca S. Guenther ^^ ^^ Chair, ISO 639-2 Maintenance Agency ^^ ^^ Senior Networking and Standards Specialist ^^ ^^ Library of Congress ^^ ^^ Washington, DC 20540-4402 ^^ ^^ (202) 707-5092 (voice) (202) 707-0115 (FAX) ^^ ^^ rgue@loc.gov ^^ ^^ ^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ On Sun, 3 Jul 2005, Doug Ewell wrote: > I've just found an inconsistency in the tables listed on the ISO > 639-2/RA site for the code element "frm". These tables are linked from > the page located at http://www.loc.gov/standards/iso639-2/langhome.html. > > In the tables sorted by English name of language and French name of > language (both HTML and plain text), the associated language name is: > > French, Middle (ca.1400-1600) > > In the tables sorted by ISO 639-2 alpha-3 code (both HTML and two > plain-text versions), the language name is: > > French, Middle (ca.1400-1800) > > In other words, the difference is between 1600 and 1800 as the ending > date for "Middle French." > > Intuitively, 1600 seems more correct, and this is the version that has > been used in the ISO/DIS 639-3 draft tables. However, the Initial > Language Subtag Registry at > http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-00.txt > currently lists 1800, since it was generated from the ISO 639-2 table > sorted by alpha-3 code. > > >From the LTRU and ietf-languages people, I would like confirmation that > 1600 is the correct ending date, not 1800 as currently shown, and that > this should be corrected in the registry. > > >From the ISO 639-2 people, I would like to request that the official > tables be made consistent with each other, displaying the same > association between codes and language names regardless of how the list > is sorted. > > -- > 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 Jul 05 16:18:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dptrk-0000SO-2M; Tue, 05 Jul 2005 16:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dptrh-0000SJ-S7 for ltru@megatron.ietf.org; Tue, 05 Jul 2005 16:17:57 -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 QAA17527 for ; Tue, 5 Jul 2005 16:17:50 -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 <20050705201719.RDXH19267.mta10.adelphia.net@DEWELL> for ; Tue, 5 Jul 2005 16:17:19 -0400 Message-ID: <00e501c5819e$532cfbc0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 5 Jul 2005 13:15: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: last call scheduled? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > Are we waiting on Doug to post initial-01? I don't want the weeks to > slip away... I've been waiting on this work a long time. I've been waiting for feedback on the double-bracketed items before submitting initial-01. So far I have received none. I've posted a new editor's copy with all bracketed items deleted (as I have proposed they should be), and with the "Middle French" date error corrected. If I haven't received any feedback on this, public or private, before 1400 UTC Wednesday (7:00 am Pacific time), I'll submit it to IETF as is. I share Addison's concern about needless delay. http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-01.txt (.html, .xml) -- 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 Jul 05 17:04:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpub3-0002uy-S0; Tue, 05 Jul 2005 17:04:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpuZU-00020M-6C for ltru@megatron.ietf.org; Tue, 05 Jul 2005 17:03:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27392 for ; Tue, 5 Jul 2005 17:01:36 -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 1DpukC-0005WD-Tw for ltru@ietf.org; Tue, 05 Jul 2005 17:14:20 -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 Jul 2005 13:48: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: last call scheduled? Date: Tue, 5 Jul 2005 13:48:07 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C014867@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: last call scheduled? Thread-Index: AcWBoFCma98q7FQWTIm2/HVNRqrfNwAAKHjQ From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 05 Jul 2005 20:48:07.0697 (UTC) FILETIME=[D919F810:01C581A2] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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="===============0583404638==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0583404638== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 U3VnZ2VzdGlvbjoNCg0KVXNlIHlvdXIgcG93ZXJzIGFzIGVkaXRvciB0byBlaXRoZXIga2VlcCB0 ZXh0IG9yIGV4cHVuZ2UgdGV4dC4gSWYgeW91IGFyZSBmZWFyZnVsIHRoYXQgc29tZW9uZSB3aWxs IHdhbnQgb25lIG9yIGFub3RoZXIgcGhyYXNlIGJhY2ssIGVuY2xvc2UgdGhlIHJlbW92ZWQgdGV4 dCBpbiBhbiBYTUwgY29tbWVudDogPCEtLSBjb21tZW50IC0tPg0KDQpQZW9wbGUgd2hvIGRvbid0 IGNhcmUgZG9uJ3QgY29tbWVudC4gVGhlcmUgaXMgYW4gaW5maW5pdGUgc3VwcGx5IG9mIGludGVn ZXJzIGZvciBmaXhpbmcgImVkaXRpbmcgbWlzdGFrZXMiIGFuZCBpZiB5b3Ugd2FpdCBmb3Igc29t ZW9uZSBlbHNlIHRvIGRpY3RhdGUgdGhlIHRleHQsIHlvdSBtaWdodCB3YWl0IGEgbG9uZyB0aW1l LiBJJ3ZlIHBlcnNvbmFsbHkgZm91bmQgaXQgdXNlZnVsIHRvIHN0aWNrIGEgdmVyeSBkZWZpbml0 ZSBzdGFrZSBpbiB0aGUgZ3JvdW5kIChpbiB0aGUgZm9ybSBvZiB0ZXh0KS4NCg0KUGVyc29uYWxs eSBJIHdvdWxkOg0KDQoxLiBDaGFuZ2U6IA0KDQpTdWNoIHRhZ3MgbXVzdCBoYXZlIHRoZWlyIHJl Y29yZCBjaGFuZ2VkIC4uLg0KDQpUbyByZWFkOg0KDQotLQ0KU3VjaCB0YWdzIHdpbGwgaGF2ZSB0 aGVpciByZWNvcmQuLi4NCi0tDQoNCi8vIEF2b2lkaW5nIG5vcm1hdGl2ZSBsYW5ndWFnZSB3aGlj aCBpc24ndCBhcHByb3ByaWF0ZSBoZXJlLg0KDQoyLiBLZWVwOg0KDQpOb3RlIHRoYXQgcHJldmlv dXMgYXBwcm92YWwgb2YgYSB0YWcgdW5kZXIgUkZDIDMwNjYgaXMgbm90IGEgZ3VhcmFudGVlIG9m IGFwcHJvdmFsIG9mIGEgdmFyaWFudCBzdWJ0YWcgdW5kZXIgdGhpcyBkb2N1bWVudC4gVGhlIGV4 aXN0aW5nIFJGQyAzMDY2IHRhZyBtYWludGFpbnMgaXRzIHZhbGlkaXR5LCBidXQgdGhlIG9yaWdp bmFsIHJlYXNvbiBmb3IgaXRzIHJlZ2lzdHJhdGlvbiBtaWdodCBoYXZlIGJlY29tZSBvYnNvbGV0 ZS4gDQoNCi8vIEV4cGxhbmF0aW9ucyBhcmUgZ29vZCB0byBrZWVwIGluIGJvdGggcGxhY2VzLg0K DQozLiBSZW1vdmU6DQoNCkZvciBleGFtcGxlLCB0aGUgc3VidGFnICdib29udCcgY291bGQgYmUg cmVnaXN0ZXJlZCwgcmVzdWx0aW5nIGluIHRoZSBjaGFuZ2Ugb2YgdGhlIGdyYW5kZmF0aGVyZWQg dGFnICJlbi1ib29udCIgdG8gdHlwZSAicmVkdW5kYW50IiBpbiB0aGUgcmVnaXN0cnkuDQoNCi8v IFN1cGVyZmx1b3VzLg0KDQo0LiBSZW1vdmU6DQoNClsgWyBSZWdpc3RyYXRpb25zIHRoYXQgYXJl IGluIHByb2Nlc3MgdW5kZXIgdGhlIHJ1bGVzIGRlZmluZWQgaW4gUkZDIDMwNjYgbWF5IGJlIGNv bXBsZXRlZCB1bmRlciB0aGUgZm9ybWVyIHJ1bGVzLCBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUg UkZDIDMwNjYgbGFuZ3VhZ2UgdGFnIHJldmlld2VyLiBdIF0NCg0KDQovLyBBbHNvIHN1cGVyZmx1 b3VzLg0KDQo1LiBNb2RpZnk6DQoNCi0tDQpOZXcgcmVnaXN0cmF0aW9ucyBjb21wbGV0ZWQgdW5k ZXIgUkZDIDMwNjYgd2VyZSBlbnRlcmVkIGludG8gdGhlIElMU1IgdXNpbmcgdGhlIHJ1bGVzIGRl ZmluZWQgYWJvdmUuDQotLQ0KDQpUbyByZWFkOg0KDQotLQ0KQW55IGFkZGl0aW9uYWwgcmVnaXN0 cmF0aW9ucyBjb21wbGV0ZWQgYWZ0ZXIgYWRvcHRpb24gb2YgW2RyYWZ0LXJlZ2lzdHJ5XSB1c2lu ZyB0aGUgcnVsZXMgaW4gUkZDIDMwNjYgd2lsbCBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGlzIGRv Y3VtZW50IHVzaW5nIHRoZSBydWxlcyBkZWZpbmVkIGFib3ZlIG9yIHdpbGwgaGF2ZSBhcHByb3By aWF0ZSByZWNvcmRzIHNlcGFyYXRlbHkgc3VibWl0dGVkIGJ5IHRoZSBMYW5ndWFnZSBTdWJ0YWcg UmV2aWV3ZXIgYWNjb3JkaW5nIHRvIHRoZSBydWxlcyBpbiBbZHJhZnQtcmVnaXN0cnldLg0KLS0N Cg0KNi4gUmVtb3ZlOg0KDQpbIFsgVXNlcnMgb2YgdGFncyB0aGF0IGFyZSBncmFuZGZhdGhlcmVk IHNob3VsZCBjb25zaWRlciByZWdpc3RlcmluZyBhcHByb3ByaWF0ZSBzdWJ0YWdzIGluIHRoZSBM YW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgKGJ1dCBhcmUgbm90IHJlcXVpcmVkIHRvKS4gXSBdDQoN CkJlc3QgUmVnYXJkcywNCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxp emF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25h bGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5v dCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZyBbbWFpbHRv Omx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIERvdWcgRXdlbGwN Cj4gU2VudDogZGVuIDUganVsaSAyMDA1IDEzOjE2DQo+IFRvOiBMVFJVIFdvcmtpbmcgR3JvdXAN Cj4gU3ViamVjdDogW0x0cnVdIFJlOiBsYXN0IGNhbGwgc2NoZWR1bGVkPw0KPiANCj4gQWRkaXNv biBQaGlsbGlwcyA8YWRkaXNvbiBkb3QgcGhpbGxpcHMgYXQgcXVlc3QgZG90IGNvbT4gd3JvdGU6 DQo+IA0KPiA+IEFyZSB3ZSB3YWl0aW5nIG9uIERvdWcgdG8gcG9zdCBpbml0aWFsLTAxPyBJIGRv bid0IHdhbnQgdGhlIHdlZWtzIHRvDQo+ID4gc2xpcCBhd2F5Li4uIEkndmUgYmVlbiB3YWl0aW5n IG9uIHRoaXMgd29yayBhIGxvbmcgdGltZS4NCj4gDQo+IEkndmUgYmVlbiB3YWl0aW5nIGZvciBm ZWVkYmFjayBvbiB0aGUgZG91YmxlLWJyYWNrZXRlZCBpdGVtcyBiZWZvcmUNCj4gc3VibWl0dGlu ZyBpbml0aWFsLTAxLiAgU28gZmFyIEkgaGF2ZSByZWNlaXZlZCBub25lLg0KPiANCj4gSSd2ZSBw b3N0ZWQgYSBuZXcgZWRpdG9yJ3MgY29weSB3aXRoIGFsbCBicmFja2V0ZWQgaXRlbXMgZGVsZXRl ZCAoYXMgSQ0KPiBoYXZlIHByb3Bvc2VkIHRoZXkgc2hvdWxkIGJlKSwgYW5kIHdpdGggdGhlICJN aWRkbGUgRnJlbmNoIiBkYXRlIGVycm9yDQo+IGNvcnJlY3RlZC4gIElmIEkgaGF2ZW4ndCByZWNl aXZlZCBhbnkgZmVlZGJhY2sgb24gdGhpcywgcHVibGljIG9yDQo+IHByaXZhdGUsIGJlZm9yZSAx NDAwIFVUQyBXZWRuZXNkYXkgKDc6MDAgYW0gUGFjaWZpYyB0aW1lKSwgSSdsbCBzdWJtaXQNCj4g aXQgdG8gSUVURiBhcyBpcy4gIEkgc2hhcmUgQWRkaXNvbidzIGNvbmNlcm4gYWJvdXQgbmVlZGxl c3MgZGVsYXkuDQo+IA0KPiBodHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0L35kZXdlbGwvZHJhZnQt aWV0Zi1sdHJ1LWluaXRpYWwtMDEudHh0DQo+ICguaHRtbCwgLnhtbCkNCj4gDQo+IC0tDQo+IERv dWcgRXdlbGwNCj4gRnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+IGh0dHA6Ly91c2Vycy5hZGVscGhp YS5uZXQvfmRld2VsbC8NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBsaXN0cy5p ZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQoN Cg== --===============0583404638== 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 --===============0583404638==-- From ltru-bounces@lists.ietf.org Tue Jul 05 17:35:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpv4W-0000LU-6G; Tue, 05 Jul 2005 17:35:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpv4T-0000Go-LB for ltru@megatron.ietf.org; Tue, 05 Jul 2005 17:35:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02330 for ; Tue, 5 Jul 2005 17:35:08 -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 1DpvMu-00017X-5I for ltru@ietf.org; Tue, 05 Jul 2005 17:54:17 -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 <20050705212614.TKPM14360.mta13.adelphia.net@DEWELL>; Tue, 5 Jul 2005 17:26:14 -0400 Message-ID: <00fe01c581a7$c6a8cd00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C014867@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: last call scheduled? Date: Tue, 5 Jul 2005 14:23: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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Addison Phillips wrote: > 2. Keep: > > Note that previous approval of a tag under RFC 3066 is not a guarantee > of approval of a variant subtag under this document. The existing RFC > 3066 tag maintains its validity, but the original reason for its > registration might have become obsolete. OK, except I've changed "this document" to [draft-registry] for obvious reasons. > 5. Modify: > > -- > New registrations completed under RFC 3066 were entered into the ILSR > using the rules defined above. > -- > > To read: > > -- > Any additional registrations completed after adoption of [draft- > registry] using the rules in RFC 3066 will be incorporated into this > document using the rules defined above or will have appropriate > records separately submitted by the Language Subtag Reviewer according > to the rules in [draft-registry]. I assume this is supposed to replace both sentences in the paragraph. I made a minor edit to reflect that the additional registrations will be incorporated into the Language Subtag Registry, not necessarily "this document" (i.e. the *initial* registry), and I tweaked the somewhat clumsy "registrations... will have records submitted" construction. Replacing this paragraph also has the nice side effect of removing the typo "eequest." All other suggested changes seemed reasonable and were incorporated. New editor's copy is now available. -- 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 Jul 05 18:04:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpvXE-0006ki-JE; Tue, 05 Jul 2005 18:04:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpvXC-0006ep-Cv for ltru@megatron.ietf.org; Tue, 05 Jul 2005 18:04:54 -0400 Received: from unix.megared.net.mx (megamail.megared.com.mx [200.52.207.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05586 for ; Tue, 5 Jul 2005 18:04:51 -0400 (EDT) Received: from [192.168.2.170] ([10.60.88.84]) by unix.megared.net.mx (8.11.7/8.11.7) with ESMTP id j65M4Ga68608 for ; Tue, 5 Jul 2005 17:04:17 -0500 (CDT) Message-ID: <42CB03D4.20801@megared.net.mx> Date: Tue, 05 Jul 2005 17:04:04 -0500 From: "Dylan N. Pierce" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ltru@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Private Use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org (This is a re-send of an e-mail I originally sent to the authors of a previous draft; I have since been educated as to the proper way to comment.) Dear Mr. Phillips and Mr. Davis, First, please forgive me if I'm not following proper procedure in commenting on this draft; while I do have a strong programmer's interest in this standard, I admit that I'm not typically a participant in these procedures and haven't thoroughly educated myself on the policies for submitting comments. I would like to recommend an addition to this draft, for which I think I can make a rather compelling case based on hypothetical but quite reasonable scenarios. Personally, I hope very much that your draft becomes a standard, as the problems with a canonical parsing of current RFC 3066 language tags are well-known and bothersome to developers everywhere. Your draft strikes me as an excellent way to finally standardize the practice in a way which will be accessible to all developers without having to investigate thirty different standards and documents from ten different organizations. Regarding Section 3.4 on extensions and extension namespace: You already have here a mechanism in place for extending this specification. I would like to suggest an extension which should probably be incorporated into the main specification. I believe you should define an "organization convention" extension for use by private companies and organizations for their own purposes. I realize that a "private use" extension is already defined in section 2.2.7. However, I maintain that the private use extension is not sufficient for potential development and interdevelopment among important organizations, as there is no way a parsing agent could assume anything significant about the tags which follow. And yet, the registration of 3.4 extensions is also insufficient because, frankly, you'll rapidly run out of letters if you make a sincere effort to define namespace for private companies and organizations. Let's take a concrete example. Let's say that the American Library Association (ALA) decides to define an extension to help them classify books by reading level. As your specification stands, they have two choices: they can register a 3.4 extension (we'll say they register "L") and then use their subtags as follows: en-US-L-g6: A book written in English as spoken in the United States at the sixth-grade reading level. The ALA would have excellent reasons for wanting such a tag, as it would greatly facilitate the database querying and transfer of material to public schools. However, we see the first problem: the ALA has their tag, which many schools would use. Then, Associated Press would want their tag to indicate regional assumptions. We'll give them "P" (for "press"): en-US-P-ky: An article written in English as spoken in the United States which assumes readers are already familiar with names, cities, politics, etc., in Kentucky. (They would use this to distribute versions to Kentucky press where they don't have to explain that Frankfurt is the capital, distinguishing them from national or international versions which would make no such assumption and explicitly specify that Frankfurt is the capital.) If we keep up like this, as I mentioned, we'll rapidly run out of singleton letters. Everyone will want one, some for valid reasons, others for silly reasons, and then your registration authority would be in the unenviable position of having to make value judgments regarding what is valid and what is silly, given such limited real estate. Furthermore, you'll be putting the organizations themselves in a difficult position. For example, if the ALA decides to modify their convention, this is something that is only of interest to them and the people who use their specification. However, in order to make their own internal changes, they will technically have to go through the entire process of revising a stable specification through the registration authority (according to 3.4, which requires stability and canonical representation), something which is never recommendable. And finally, parsing agents which have no interest in the ALA's tag (which will be most of them) will nonetheless have the burden of checking conformance. If we take the other approach, and say, "We have the 'x' tag for private use. The ALA and AP can take that tag and follow it up however they want," then we're creating another problem. All of the parsing agents which do have an interest in those tags cannot be guaranteed that they mean what they think they mean. For example, if the ALA decides to go with: en-US-x-ala-g6 But subsequently the Associate Press decides that their private tag "x-ala" means articles of interest to Alabamans, then what's the ALA do to when they want to classify articles written by the AP? The problem is that parsing user agents will be unable to assume anything about the tag that follows, and once a conflict occurs, both tags become either useless, or subject to the type of interpretation that a human might perform easily but a machine cannot. The solution is simply to define an organizational namespace. We take a random tag--we'll say "P" for private--and then allow companies and organizations to register their own namespace. Everything that follows their namespace tag is then interpreted according to their standard, whatever that may be. For example, the ALA would register "ala," the AP would register "ap," Microsoft would register "mcrsoft," Adobe would register "adobe" and so on. Then, anyone seeing a tag like this: en-US-P-ala-g6 could know unambiguously that whatever follows the P-ala is to be interpreted by the ALA's own convention, whatever that might be. Each registering organization could then be responsible for the stability and canonical representations of their own namespace without affecting the stability of the specification as a whole. Parsing agents which are not interested in the AP's tags simply knows to ignore anything after the "P" tag that isn't an organization in which it has an interest. Parsing agents that are interested can now know with assurance that the information is what they're looking for. Companies and organizations can establish their own standards which can easily evolve to suit their needs. Private companies can establish compatibility standards between themselves which won't affect the specification as a whole. This could be infinitely extensible merely by setting aside one of the organizational tags to mean "check the next set." For example, if the American Library association registers "ala" as above, and then later the Association of Libertarians and Anarchists shows up, finds that all the mnemonic representations of their name are already used and there's not much space left on the registery (and with 368 alphanumeric possibilities, that's not likely, but let's pretend), they could define their namespace as "set2-ala" (assuming we've already decided that "set2" is the tag when means "check the next set"). This allows all companies and organizations which have a need to define their own namespaces and then use them as the needs of their particular domain indicate in a way that is nonetheless unambiguously established for parsing agents which can then make error-free decisions about whether or not the information which follows is useful to their needs, all done without sacrificing the stability of the main specification. This is the extent of my speculation on the issue. I did consider the possibility of using Java-package-name-like identifiers tied to domain registration, so that Microsoft could have the "com-microsoft" tag and the ALA could have the "org-ala" tag, but this would end up violating the eight-character rule and allow just any yahoo with a website to include whatever he sees fit (en-US-com-sexychicks-38D comes to mind), which I don't think is a desirable solution at all. If you have found this comment at all useful, I would appreciate hearing back. Sincerely, Dylan N. Pierce IT Coordinator, TykeTek TykeTek/Diapositivas Gloria Salvador Quevedo y Zubieta #821 Int. 6 Col. la Perla C.P. 44360 Guadalajara, Jal. MEXICO E-Mail: dylanpierce@megared.net.mx Telephone: +52 (33) 3617.3660 Cellular: +52 (33) 1149.7057 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 06 00:36:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq1e9-0004Ru-Pt; Wed, 06 Jul 2005 00:36:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq1e8-0004Q1-B0 for ltru@megatron.ietf.org; Wed, 06 Jul 2005 00:36:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23260 for ; Wed, 6 Jul 2005 00:36:25 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq251-00006j-U2 for ltru@ietf.org; Wed, 06 Jul 2005 01:04:17 -0400 Received: from h-68-166-189-124.snvacaid.dynamic.covad.net ([68.166.189.124] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dq1dx-0005cJ-00 for ltru@ietf.org; Wed, 06 Jul 2005 00:36:17 -0400 Message-ID: <01fc01c581e4$d4569da0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Tue, 5 Jul 2005 21:40:25 -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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Ltru] Restoration of privileges 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Since there is some question about whether the message Randy posted at http://www1.ietf.org/mail-archive/web/ltru/current/msg01897.html was explicit enough as an RFC 3934 warning to Mr. Morfin, we are restoring his posting privileges. *This* message is an explicit warning to him that he must stay on topic for the group, avoid personal attacks, and cease mis-representing the positions of other participants to retain those privileges. If his postings become disruptive, his ltru WG mailing list posting privileges will be revoked. Randy & Martin, ltru co-chairs P.S. I am not able to reach the mailing list's administrative interface right now, even though the IETF web site is reachable. I apologize for the delay. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 06 01:43:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq2hO-0003S9-Kv; Wed, 06 Jul 2005 01: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 1Dpwxa-0005yQ-76 for ltru@megatron.ietf.org; Tue, 05 Jul 2005 19:36:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20070 for ; Tue, 5 Jul 2005 19:34:41 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpx8h-0001nX-KO for ltru@ietf.org; Tue, 05 Jul 2005 19:47:44 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dpwhg-0006l4-AI; Tue, 05 Jul 2005 16:19:50 -0700 Message-Id: <6.2.1.2.2.20050706001224.05117b90@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 06 Jul 2005 01:18:59 +0200 To: "Dylan N. Pierce" , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Private Use Tags In-Reply-To: <42CB03D4.20801@megared.net.mx> References: <42CB03D4.20801@megared.net.mx> 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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id TAA20070 X-Mailman-Approved-At: Wed, 06 Jul 2005 01:43:52 -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 Dear Dylan, this request makes a lot of sense. There are many issues there. A few one= s. 1. you characterise in a way the use of a document. I am not sure this=20 directly fits with the characterisation of a language. But it characteris= e=20 a relation channel. I mean by that the way the document is intended to be= =20 received, send or exchanged, and from there classified. Today the propose= d=20 Draft leaves this undefined in at least two ways: - first paragraph. It says "Human beings on our planet have, past and=20 present, used a number of languages. There are many reasons why one woul= d=20 want to identify the language used when presenting or requesting=20 information.". One could say that "used" may relate to exchanged,=20 "presenting" to send and "requesting" to received, with some variation=20 because for example requesting does no mean that it was received. - part 2. "The language tag always defines a language as used (which=20 includes being spoken, written, signed, or otherwise signaled) by=20 human beings for communication of information to other human beings.=20 Computer languages such as programming languages are explicitly excluded.= " The problem here is that a language is not defined (what it is? how is it= =20 identified? etc.) however the langtag is normative of that something. The= =20 usage of the proposed langtags can only be subjective (the perception of=20 the users) and the discussed language to be rather undefined concepts. Yo= ur=20 proposition creates languages _values_ (the instanciation of the Kentucky= =20 press). I am not sure you can really qualify it within the Draft framewor= k.=20 This is because it is filtered by a media (Kentucky press) and not by a=20 speakers community (unless you mean the readers - or the authors? - of t= he=20 Kentucky press). Please recall that they do not want to accept man/comput= er=20 and computer/computer languages. This obviously creates a classification=20 problem with StarWars, what is H2D2 speaking? and Yoda who is not a human= =20 being? The Japanese Fair of Robotics this years, shown Dro=EFds interrela= ting=20 in Japanese or in English. There is also a vacuum for computer generated=20 texts, alarms, etc. Would you introduce "r" for Robots? but that would=20 oppose the spirit of the Draft? 2. you want to permit organisations and persons to define their personal=20 name space (cf. John Klensin recent Draft on IANA) and define their own=20 format. This was recently proposed and denied. The first problem you meet= =20 with this is size of the namespace you need and its structure. You consid= er=20 that Microsoft would register "mcrsoft", why that? Mr. Sungil Yoon who ow= ns=20 McrSoft.com has the right to use it. You will say that "Microsoft" is=20 longer than 8alpha. Right, but RFC 1766 said that you cannot change that=20 and is to be respected by consensus of this WG. Obviously you can object = to=20 this consensus, I will too, others will probably too and this will not be= =20 anymore a consensus. But short of that, only user owning universal rights= =20 (every class, every country) can claim a tag (like "mercedes" or=20 "cocacola") otherwise we have conflicts. I note that RFC 2860 can also create a problem for the Draft. Your naming= =20 part is by essence an ICANN part of the IANA: the Registrar and Examiner=20 must be designated by the ICANN BoD and appeals probably subject to GAC.=20 This should be reflected in the Draft. Is this really what you want? Another problem you may not have investigated is that Microsoft could hav= e=20 different branches and needs, for example "microsoft.corp", "microsoft.us= ",=20 etc. the languages spoken in its different branches being certainly=20 different. This is why we have introduced three warnings you can find on=20 http://rfc3066.org: - there is no subtag size limit in the x-tags part - the "." and the ":" are accepted characters, "." introducing a comment = or=20 an additional part and ":" permitting to use URNs? For us=20 "x-en.microsoft.us-Latn-de" qualifies the language of a Mr. Gates visitin= g=20 Germany. But please note that, if this proposition, initially presented by F.=20 Charles, cannot conflict with any previous format since it is a private=20 area, it is not supported by this WG, what is deemed to have consensually= =20 opposed, (one or two objections). 3. you consider the notions of referent (ex.: commonly accepted reading=20 level -L-6) and context (to know about the Kentucky cities and life). The= se=20 are two levels which are very important to the support of a relation=20 (together with their dates - as per ISO 11179 - to know which version is = to=20 be used). Other referents can be Dictionaries, Grammars, publishers, etc.= =20 Other contexts can be style, mimics, accents, etc. These notions are most= =20 probably too complex for the Draft and can be multiplied and need=20 priorities in case of conflicts when two referential systems have differe= nt=20 descriptions. Please accept that the Draft only supports one single mode=20 (script) and has no provision (yet) to support other modes. All this can/should certainly be supported. But this would call for a=20 general framework introduction of language support (BCP 47) within the=20 Internet architecture, as a continuation/extension of the RFC 3066. In th= is=20 case the Draft would be an application of this framework. The sentence=20 "This document replaces RFC 3066" should then be replaced by "this docume= nt=20 complements RFC 3066": this is a part of the debate over the Charter, th= is=20 WG consensus does seem to want to engage. 4. you say you do not consider that using domain names would be adequate,= =20 but you do not document it. This is one of the solutions to support=20 individual/avatars and contexts grids. I would therefore be interested yo= u=20 document your position. This is a point which is hotly debated in some IS= O=20 committees, and belongs to what is qualified as the "pulverisation" of a=20 user-centric Internet (i.e. its ultimate granularity). Work currently=20 carried one coreboxes and OPES (WG-OPES) go down to this degree and even=20 below (the individual relation level and context: the way you speak when=20 you are with someone else specific, under some identified circumstances.=20 ex: the language you use with a cop who stopped you on the road). Thank you for this interesting thinking. jfc At 00:04 06/07/2005, Dylan N. Pierce wrote: >(This is a re-send of an e-mail I originally sent to the authors of a=20 >previous draft; I have since been educated as to the proper way to comme= nt.) > >Dear Mr. Phillips and Mr. Davis, > >First, please forgive me if I'm not following proper procedure in=20 >commenting on this draft; while I do have a strong programmer's interest= =20 >in this standard, I admit that I'm not typically a participant in these=20 >procedures and haven't thoroughly educated myself on the policies for=20 >submitting comments. > >I would like to recommend an addition to this draft, for which I think I= =20 >can make a rather compelling case based on hypothetical but quite=20 >reasonable scenarios. Personally, I hope very much that your draft becom= es=20 >a standard, as the problems with a canonical parsing of current RFC 3066= =20 >language tags are well-known and bothersome to developers everywhere. Yo= ur=20 >draft strikes me as an excellent way to finally standardize the practice= =20 >in a way which will be accessible to all developers without having to=20 >investigate thirty different standards and documents from ten different=20 >organizations. > >Regarding Section 3.4 on extensions and extension namespace: You already= =20 >have here a mechanism in place for extending this specification. I would= =20 >like to suggest an extension which should probably be incorporated into=20 >the main specification. I believe you should define an "organization=20 >convention" extension for use by private companies and organizations for= =20 >their own purposes. > >I realize that a "private use" extension is already defined in section=20 >2.2.7. However, I maintain that the private use extension is not=20 >sufficient for potential development and interdevelopment among importan= t=20 >organizations, as there is no way a parsing agent could assume anything=20 >significant about the tags which follow. And yet, the registration of 3.= 4=20 >extensions is also insufficient because, frankly, you'll rapidly run out= =20 >of letters if you make a sincere effort to define namespace for private=20 >companies and organizations. > >Let's take a concrete example. Let's say that the American Library=20 >Association (ALA) decides to define an extension to help them classify=20 >books by reading level. As your specification stands, they have two=20 >choices: they can register a 3.4 extension (we'll say they register "L")= =20 >and then use their subtags as follows: > >en-US-L-g6: A book written in English as spoken in the United States at=20 >the sixth-grade reading level. > >The ALA would have excellent reasons for wanting such a tag, as it would= =20 >greatly facilitate the database querying and transfer of material to=20 >public schools. > >However, we see the first problem: the ALA has their tag, which many=20 >schools would use. Then, Associated Press would want their tag to indica= te=20 >regional assumptions. We'll give them "P" (for "press"): > >en-US-P-ky: An article written in English as spoken in the United States= =20 >which assumes readers are already familiar with names, cities, politics,= =20 >etc., in Kentucky. (They would use this to distribute versions to Kentuc= ky=20 >press where they don't have to explain that Frankfurt is the capital,=20 >distinguishing them from national or international versions which would=20 >make no such assumption and explicitly specify that Frankfurt is the cap= ital.) > >If we keep up like this, as I mentioned, we'll rapidly run out of=20 >singleton letters. Everyone will want one, some for valid reasons, other= s=20 >for silly reasons, and then your registration authority would be in the=20 >unenviable position of having to make value judgments regarding what is=20 >valid and what is silly, given such limited real estate. > >Furthermore, you'll be putting the organizations themselves in a difficu= lt=20 >position. For example, if the ALA decides to modify their convention, th= is=20 >is something that is only of interest to them and the people who use the= ir=20 >specification. However, in order to make their own internal changes, the= y=20 >will technically have to go through the entire process of revising a=20 >stable specification through the registration authority (according to 3.= 4,=20 >which requires stability and canonical representation), something which = is=20 >never recommendable. > >And finally, parsing agents which have no interest in the ALA's tag (whi= ch=20 >will be most of them) will nonetheless have the burden of checking confo= rmance. > >If we take the other approach, and say, "We have the 'x' tag for private= =20 >use. The ALA and AP can take that tag and follow it up however they want= ,"=20 >then we're creating another problem. All of the parsing agents which do=20 >have an interest in those tags cannot be guaranteed that they mean what=20 >they think they mean. > >For example, if the ALA decides to go with: > >en-US-x-ala-g6 > >But subsequently the Associate Press decides that their private tag=20 >"x-ala" means articles of interest to Alabamans, then what's the ALA do = to=20 >when they want to classify articles written by the AP? The problem is th= at=20 >parsing user agents will be unable to assume anything about the tag that= =20 >follows, and once a conflict occurs, both tags become either useless, or= =20 >subject to the type of interpretation that a human might perform easily=20 >but a machine cannot. > >The solution is simply to define an organizational namespace. We take a=20 >random tag--we'll say "P" for private--and then allow companies and=20 >organizations to register their own namespace. Everything that follows=20 >their namespace tag is then interpreted according to their standard,=20 >whatever that may be. For example, the ALA would register "ala," the AP=20 >would register "ap," Microsoft would register "mcrsoft," Adobe would=20 >register "adobe" and so on. > >Then, anyone seeing a tag like this: > >en-US-P-ala-g6 > >could know unambiguously that whatever follows the P-ala is to be=20 >interpreted by the ALA's own convention, whatever that might be. Each=20 >registering organization could then be responsible for the stability and= =20 >canonical representations of their own namespace without affecting the=20 >stability of the specification as a whole. > >Parsing agents which are not interested in the AP's tags simply knows to= =20 >ignore anything after the "P" tag that isn't an organization in which it= =20 >has an interest. Parsing agents that are interested can now know with=20 >assurance that the information is what they're looking for. Companies an= d=20 >organizations can establish their own standards which can easily evolve = to=20 >suit their needs. Private companies can establish compatibility standard= s=20 >between themselves which won't affect the specification as a whole. > >This could be infinitely extensible merely by setting aside one of the=20 >organizational tags to mean "check the next set." For example, if the=20 >American Library association registers "ala" as above, and then later th= e=20 >Association of Libertarians and Anarchists shows up, finds that all the=20 >mnemonic representations of their name are already used and there's not=20 >much space left on the registery (and with 368 alphanumeric possibilitie= s,=20 >that's not likely, but let's pretend), they could define their namespace= =20 >as "set2-ala" (assuming we've already decided that "set2" is the tag whe= n=20 >means "check the next set"). > >This allows all companies and organizations which have a need to define=20 >their own namespaces and then use them as the needs of their particular=20 >domain indicate in a way that is nonetheless unambiguously established f= or=20 >parsing agents which can then make error-free decisions about whether or= =20 >not the information which follows is useful to their needs, all done=20 >without sacrificing the stability of the main specification. > >This is the extent of my speculation on the issue. I did consider the=20 >possibility of using Java-package-name-like identifiers tied to domain=20 >registration, so that Microsoft could have the "com-microsoft" tag and t= he=20 >ALA could have the "org-ala" tag, but this would end up violating the=20 >eight-character rule and allow just any yahoo with a website to include=20 >whatever he sees fit (en-US-com-sexychicks-38D comes to mind), which I=20 >don't think is a desirable solution at all. > >If you have found this comment at all useful, I would appreciate hearing= back. > >Sincerely, >Dylan N. Pierce >IT Coordinator, TykeTek > >TykeTek/Diapositivas Gloria >Salvador Quevedo y Zubieta #821 Int. 6 >Col. la Perla >C.P. 44360 Guadalajara, Jal. >MEXICO > >E-Mail: dylanpierce@megared.net.mx >Telephone: +52 (33) 3617.3660 >Cellular: +52 (33) 1149.7057 > >_______________________________________________ >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 Jul 06 02:57:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq3qh-0000eH-5d; Wed, 06 Jul 2005 02:57:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq3qf-0000dH-MQ for ltru@megatron.ietf.org; Wed, 06 Jul 2005 02:57:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22489 for ; Wed, 6 Jul 2005 02:57:32 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dq4Hb-0006w9-NZ for ltru@ietf.org; Wed, 06 Jul 2005 03:25:24 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jul 2005 23:57:21 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jul 2005 23:57:21 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Private Use Tags Date: Tue, 5 Jul 2005 23:53:28 -0700 Message-ID: Thread-Topic: [Ltru] Private Use Tags Thread-Index: AcWBrcXoa5ab+HaRRv2SQRlUxKuHmgARklUQ From: "Peter Constable" To: X-OriginalArrivalTime: 06 Jul 2005 06:57:21.0381 (UTC) FILETIME=[F4CB8150:01C581F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Dylan N. Pierce > The solution is simply to define an organizational namespace. We take a > random tag--we'll say "P" for private--and then allow companies and > organizations to register their own namespace. Everything that follows > their namespace tag is then interpreted according to their standard, > whatever that may be. For example, the ALA would register "ala," the AP > would register "ap," Microsoft would register "mcrsoft," Adobe would > register "adobe" and so on. This reminds me a bit of an idea Gary Simons and I came up with in 2000, though we were thinking about alternate naming agencies for the primary language subtag, not private-use subtags. The particular benefit of your proposal is realized if extensions are defined by agencies rather than for particular functions. It's clear that there are far more than 35 agencies that could potentially want their own variant extensions, but not clear that there are that many functions. Up to now, I don't think anyone has mentioned the possibility that extensions could be defined for use within single agencies. I'd be open to seeing your idea considered further. It doesn't have to go into this document, however: it's an extension, and this doc provides the framework needed for creating extensions. Given the late date and the delays this doc has seen, I recommend that we not pursue adding this into *this* document, but that you consider preparing an internet draft for your proposed extension and present it for discussion once this is approved (i.e. waiting until there is an approved framework on which to propose extensions). Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 06 04:52:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq5db-0007dd-66; Wed, 06 Jul 2005 04:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dq5da-0007cp-EH for ltru@megatron.ietf.org; Wed, 06 Jul 2005 04:52:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22670 for ; Wed, 6 Jul 2005 04:52:08 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dq64W-0005kS-3g for ltru@ietf.org; Wed, 06 Jul 2005 05:20:01 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Wed, 6 Jul 2005 09:45: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.1830); Wed, 6 Jul 2005 09:45:48 +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] Private Use Tags Date: Wed, 6 Jul 2005 09:45:48 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A212BC8C20@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Private Use Tags Thread-Index: AcWB7eTbJX1E2TjaQ1Wval7RVoaSDwAGedRw From: "L.Gillam" To: ltru X-OriginalArrivalTime: 06 Jul 2005 08:45:48.0936 (UTC) FILETIME=[1B999880:01C58207] 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 > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of r&d afrac > Sent: 06 July 2005 00:19 > To: Dylan N. Pierce; ltru@ietf.org > Subject: Re: [Ltru] Private Use Tags [snip] > This obviously creates a=20 > classification=20 > problem with StarWars, what is H2D2 speaking? and Yoda who is=20 > not a human=20 > being?=20 Others refer to "Yodish" and write it in various places for yet others to read. Klingon is in 639-2. When does it become a human language? _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 06 11: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 1DqBdS-0003TS-O2; Wed, 06 Jul 2005 11: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 1DqBdQ-0003TK-IS for ltru@megatron.ietf.org; Wed, 06 Jul 2005 11:16:24 -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 LAA08646 for ; Wed, 6 Jul 2005 11:16:20 -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 <20050706151547.DPTH14360.mta13.adelphia.net@DEWELL>; Wed, 6 Jul 2005 11:15:47 -0400 Message-ID: <004d01c5823d$6242fb60$030aa8c0@DEWELL> From: "Doug Ewell" To: Date: Wed, 6 Jul 2005 08:14:19 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004A_01C58202.B53C4AA0" 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 Cc: LTRU Working Group Subject: [Ltru] Submission: LTRU initial-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_000_004A_01C58202.B53C4AA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear Editor, Attached please find the second draft of the LTRU initial-registry document, "draft-ietf-ltru-initial-01", in text format. Best regards, -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ ------=_NextPart_000_004A_01C58202.B53C4AA0 Content-Type: text/plain; name="draft-ietf-ltru-initial-01.txt" Content-Disposition: attachment; filename="draft-ietf-ltru-initial-01.txt" Content-Transfer-Encoding: quoted-printable LTRU D. Ewell, Ed. Internet-Draft July 5, 2005 Expires: January 6, 2006 Initial Language Subtag Registry draft-ietf-ltru-initial-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 6, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines the initial contents of the Language Subtag Registry specified in RFC 3066bis, "Tags for Identifying Languages." This memo does not define the permanent contents of the registry. Ewell Expires January 6, 2006 [Page 1] =0C Internet-Draft Initial Language Subtag Registry July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Initialization of the Registry . . . . . . . . . . . . . . . 4 3. Initial Registry Contents . . . . . . . . . . . . . . . . . 7 4. Omitted Code Elements . . . . . . . . . . . . . . . . . . . 112 5. Security Considerations . . . . . . . . . . . . . . . . . . 113 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 114 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 115 7.1 Normative References . . . . . . . . . . . . . . . . . . 115 7.2 Informative References . . . . . . . . . . . . . . . . . 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . 115 Intellectual Property and Copyright Statements . . . . . . . 116 Ewell Expires January 6, 2006 [Page 2] =0C Internet-Draft Initial Language Subtag Registry July 2005 1. Introduction [I-D.ietf-ltru-registry] provides for a Language Subtag Registry and describes its format. This memo defines the initial contents of the Language Subtag Registry, using the criteria described in Section 2. The Language Subtag Registry is formatted in a modified record-jar text format, as described in [record-jar]. The specific format of the registry, and the definition and intended purpose of each of the fields, are described in [I-D.ietf-ltru-registry]. The registry is expected to change over time, as new subtags are registered and existing subtags are modified or deprecated. The process of updating the registry is described in Section 3 of [I-D.ietf-ltru-registry]. This memo does not define the permanent contents of the registry and should not be represented as doing so. Many of the subtags defined in this registry are based on code elements defined in [ISO-639-1], [ISO-639-2], [ISO-15924], [ISO-3166-1], and [UN-M.49]. This registry is not a mirror of the code lists defined by these standards, and should not be used as one. The process for determining the contents of this registry is defined in Section 3.7 of [I-D.ietf-ltru-registry]. Ewell Expires January 6, 2006 [Page 3] =0C Internet-Draft Initial Language Subtag Registry July 2005 2. Initialization of the Registry Section 3.7 of [I-D.ietf-ltru-registry] requires that the LTRU working group create an initial version of the the Language Subtag Registry and populate it with the initial set of subtags. This involves converting the entries from the existing IANA language tag registry defined by RFC 3066 to the new format, as well as defining valid subtags from various source standards. This section defines the process used to create the initial registry entries. The initial set of records is based on the following standards: [ISO- 639-1], [ISO-639-2], [ISO-15924], and [ISO-3166-1]. The following criteria were used to select and format the records of the subtags included in the initial Language Subtag Registry (hereafter "ILSR"): 1. For each source standard, the date of the standard referenced in RFC 1766 was selected as the starting date. Code elements that were valid on that date in the selected standard were added to the ILSR. Code elements that were previously assigned, but which were vacated or withdrawn before that date, were not added to the ILSR. 2. For each successive change to the standard, any additional assignments up to the date of the adoption of [I-D.ietf-ltru- registry] were added to the ILSR. Values that have been withdrawn are marked as deprecated, but not removed. Changes in meaning or assignment of a subtag were permitted during this process (for example, the ISO 3166 code element 'CS' was originally assigned to Czechoslovakia and is now assigned to Serbia and Montenegro). Code elements from [UN-M.49] were also included in the ILSR using the criteria above, with the following additional rules: 3. UN numeric code elements assigned to "macro-geographical (continental)" as of the date of adoption of [I-D.ietf-ltru- registry] were added to the ILSR and thereby made valid for use in language tags. 4. The UN numeric code elements for "economic groupings" or "other groupings," and the alphanumeric code elements in Appendix X of the UN document, were not added to the ILSR. 5. The UN numeric code elements for countries or areas not associated with an assigned ISO 3166 alpha-2 code element were not added to the ILSR. These values may be requested for registration by individuals using the process defined in [I-D.ietf-ltru- registry] and according to the rules described therein. Ewell Expires January 6, 2006 [Page 4] =0C Internet-Draft Initial Language Subtag Registry July 2005 6. Items withdrawn, vacated, deprecated, modified, or otherwise judged by the LTRU working group to be questionable were not added to the ILSR. These code elements are listed in Section 4, indicating that they are valid for registration using the process in [I-D.ietf-ltru-registry] but were not included initially. Listing of these code elements in this section is not a guarantee of future registration. Using the initial set of subtags described above, the tags in the RFC 3066 registry were evaluated as follows: 7. Tags in the RFC 3066 registry that are not deprecated, consist entirely of subtags already in this document, and have the correct form and format for tags defined by [I-D.ietf-ltru-registry] were converted to records of type "redundant" in the ILSR. For example, "zh-Hant" is now defined by [I-D.ietf-ltru-registry] because 'zh' is an ISO 639-1 code element and 'Hant' is an ISO 15924 code element, and both are defined as subtags in the ILSR. 8. Tags in the RFC 3066 registry that contain one or more subtags that either do not match the valid registration pattern or are not otherwise defined by [I-D.ietf-ltru-registry] were converted to corresponding records of type "grandfathered" in the ILSR. These records cannot become type "redundant" except by revision of [I-D.ietf-ltru-registry], but may have a "Deprecated" and "Preferred-Value" field added to them if a subsequent subtag assignment or combination of assignments renders the tag obsolete. 9. Tags in the RFC 3066 registry that have a notation that they are deprecated were converted to records of type "grandfathered" in the ILSR. The record for the grandfathered entry contains a "Deprecated" field with the most appropriate date that can be determined for when the RFC 3066 record was deprecated. The "Comments" field may optionally contain a reason for the deprecation. The "Preferred-Value" field contains a tag that replaces the value. For example, the RFC 3066 tag "art-lojban" is deprecated and thus appears as a grandfathered tag in the ILSR. Its "Deprecated" field contains the deprecation date (in this case "2003-09-02") and the "Preferred-Value" field the value "jbo". 10. The remaining tags in the RFC 3066 registry are not deprecated and have a format consistent with language tags as defined by [I-D.ietf-ltru-registry] but contain subtags which are not defined in the ILSR. These subtags are eligible for registration as variants. The ILSR contains appropriate variant records for the following list of subtags, and the registered RFC 3066 tags containing these subtags were entered into the ILSR as type "redundant": Ewell Expires January 6, 2006 [Page 5] =0C Internet-Draft Initial Language Subtag Registry July 2005 1901 (use with Prefix: de) 1996 (use with Prefix: de) nedis (use with Prefix: sl) rozaj (use with Prefix: sl) 11. All remaining RFC 3066 registered tags were converted to records of type "grandfathered" in the ILSR. Interested parties may use the registration process in [I-D.ietf-ltru-registry] to attempt to register the variant subtags not already present in the Language Subtag Registry. If all of the subtags in the original tag become fully defined by the resulting registrations, then the original tag is superseded by [I-D.ietf-ltru-registry]. Such tags will have their record changed from type "grandfathered" to type "redundant" in the registry. Note that previous approval of a tag under RFC 3066 is not a guarantee of approval of a variant subtag under [I-D.ietf-ltru-registry]. The existing RFC 3066 tag maintains its validity, but the original reason for its registration might have become obsolete. Any additional registrations completed after the adoption of [I-D.ietf-ltru-registry] using the rules in RFC 3066 will be incorporated into the Language Subtag Registry using the rules defined above, or will result in the submission of appropriate records by the Language Subtag Reviewer according to the rules in [I-D.ietf-ltru-registry]. All existing RFC 3066 language tag registrations will be maintained in perpetuity. Ewell Expires January 6, 2006 [Page 6] =0C Internet-Draft Initial Language Subtag Registry July 2005 3. Initial Registry Contents The initial Language Subtag Registry follows. The registry begins with the line that starts with the string "File-Date" and continues to the end of this section. Headers, footers, line breaks, and other vertical whitespace introduced by the RFC process are not significant. Leading horizontal whitespace indicates a continued line in the record-jar format, and must not be deleted. File-Date: 2005-07-05 %% Type: language Subtag: aa Description: Afar Added: 2005-07-05 %% Type: language Subtag: ab Description: Abkhazian Added: 2005-07-05 Suppress-Script: Cyrl %% Type: language Subtag: ae Description: Avestan Added: 2005-07-05 %% Type: language Subtag: af Description: Afrikaans Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ak Description: Akan Added: 2005-07-05 %% Type: language Subtag: am Description: Amharic Added: 2005-07-05 Suppress-Script: Ethi %% Type: language Subtag: an Description: Aragonese Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 7] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: ar Description: Arabic Added: 2005-07-05 Suppress-Script: Arab %% Type: language Subtag: as Description: Assamese Added: 2005-07-05 Suppress-Script: Beng %% Type: language Subtag: av Description: Avaric Added: 2005-07-05 %% Type: language Subtag: ay Description: Aymara Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: az Description: Azerbaijani Added: 2005-07-05 %% Type: language Subtag: ba Description: Bashkir Added: 2005-07-05 %% Type: language Subtag: be Description: Belarusian Added: 2005-07-05 Suppress-Script: Cyrl %% Type: language Subtag: bg Description: Bulgarian Added: 2005-07-05 Suppress-Script: Cyrl %% Type: language Subtag: bh Ewell Expires January 6, 2006 [Page 8] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Bihari Added: 2005-07-05 %% Type: language Subtag: bi Description: Bislama Added: 2005-07-05 %% Type: language Subtag: bm Description: Bambara Added: 2005-07-05 %% Type: language Subtag: bn Description: Bengali Added: 2005-07-05 Suppress-Script: Beng %% Type: language Subtag: bo Description: Tibetan Added: 2005-07-05 %% Type: language Subtag: br Description: Breton Added: 2005-07-05 %% Type: language Subtag: bs Description: Bosnian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ca Description: Catalan Description: Valencian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ce Description: Chechen Added: 2005-07-05 %% Type: language Ewell Expires January 6, 2006 [Page 9] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: ch Description: Chamorro Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: co Description: Corsican Added: 2005-07-05 %% Type: language Subtag: cr Description: Cree Added: 2005-07-05 %% Type: language Subtag: cs Description: Czech Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: cu Description: Church Slavic Description: Old Slavonic Description: Church Slavonic Description: Old Bulgarian Description: Old Church Slavonic Added: 2005-07-05 %% Type: language Subtag: cv Description: Chuvash Added: 2005-07-05 %% Type: language Subtag: cy Description: Welsh Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: da Description: Danish Added: 2005-07-05 Suppress-Script: Latn %% Type: language Ewell Expires January 6, 2006 [Page 10] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: de Description: German Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: dv Description: Divehi Added: 2005-07-05 Suppress-Script: Thaa %% Type: language Subtag: dz Description: Dzongkha Added: 2005-07-05 Suppress-Script: Tibt %% Type: language Subtag: ee Description: Ewe Added: 2005-07-05 %% Type: language Subtag: el Description: Greek, Modern (1453-) Added: 2005-07-05 Suppress-Script: Grek %% Type: language Subtag: en Description: English Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: eo Description: Esperanto Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: es Description: Spanish Description: Castilian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Ewell Expires January 6, 2006 [Page 11] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: et Description: Estonian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: eu Description: Basque Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: fa Description: Persian Added: 2005-07-05 Suppress-Script: Arab %% Type: language Subtag: ff Description: Fulah Added: 2005-07-05 %% Type: language Subtag: fi Description: Finnish Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: fj Description: Fijian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: fo Description: Faroese Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: fr Description: French Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: fy Ewell Expires January 6, 2006 [Page 12] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Frisian Added: 2005-07-05 %% Type: language Subtag: ga Description: Irish Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: gd Description: Gaelic Description: Scottish Gaelic Added: 2005-07-05 %% Type: language Subtag: gl Description: Gallegan Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: gn Description: Guarani Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: gu Description: Gujarati Added: 2005-07-05 Suppress-Script: Gujr %% Type: language Subtag: gv Description: Manx Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ha Description: Hausa Added: 2005-07-05 %% Type: language Subtag: he Description: Hebrew Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 13] =0C Internet-Draft Initial Language Subtag Registry July 2005 Suppress-Script: Hebr %% Type: language Subtag: hi Description: Hindi Added: 2005-07-05 Suppress-Script: Deva %% Type: language Subtag: ho Description: Hiri Motu Added: 2005-07-05 %% Type: language Subtag: hr Description: Croatian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ht Description: Haitian Description: Haitian Creole Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: hu Description: Hungarian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: hy Description: Armenian Added: 2005-07-05 Suppress-Script: Armn %% Type: language Subtag: hz Description: Herero Added: 2005-07-05 %% Type: language Subtag: ia Description: Interlingua (International Auxiliary Language Association) Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 14] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: id Description: Indonesian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ie Description: Interlingue Added: 2005-07-05 %% Type: language Subtag: ig Description: Igbo Added: 2005-07-05 %% Type: language Subtag: ii Description: Sichuan Yi Added: 2005-07-05 %% Type: language Subtag: ik Description: Inupiaq Added: 2005-07-05 %% Type: language Subtag: in Description: Indonesian Added: 2005-07-05 Preferred-Value: id Deprecated: 1989-01-01 Suppress-Script: Latn %% Type: language Subtag: io Description: Ido Added: 2005-07-05 %% Type: language Subtag: is Description: Icelandic Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: it Ewell Expires January 6, 2006 [Page 15] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Italian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: iu Description: Inuktitut Added: 2005-07-05 %% Type: language Subtag: iw Description: Hebrew Added: 2005-07-05 Preferred-Value: he Deprecated: 1989-01-01 Suppress-Script: Hebr %% Type: language Subtag: ja Description: Japanese Added: 2005-07-05 %% Type: language Subtag: ji Description: Yiddish Added: 2005-07-05 Preferred-Value: yi Deprecated: 1989-01-01 %% Type: language Subtag: jv Description: Javanese Added: 2005-07-05 %% Type: language Subtag: jw Description: Javanese Added: 2005-07-05 Preferred-Value: jv Deprecated: 2001-08-13 Comments: published by error in Table 1 of ISO 639:1988 %% Type: language Subtag: ka Description: Georgian Added: 2005-07-05 Suppress-Script: Geor %% Ewell Expires January 6, 2006 [Page 16] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: kg Description: Kongo Added: 2005-07-05 %% Type: language Subtag: ki Description: Kikuyu Description: Gikuyu Added: 2005-07-05 %% Type: language Subtag: kj Description: Kuanyama Description: Kwanyama Added: 2005-07-05 %% Type: language Subtag: kk Description: Kazakh Added: 2005-07-05 Suppress-Script: Cyrl %% Type: language Subtag: kl Description: Kalaallisut Description: Greenlandic Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: km Description: Khmer Added: 2005-07-05 Suppress-Script: Khmr %% Type: language Subtag: kn Description: Kannada Added: 2005-07-05 Suppress-Script: Knda %% Type: language Subtag: ko Description: Korean Added: 2005-07-05 %% Type: language Ewell Expires January 6, 2006 [Page 17] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: kr Description: Kanuri Added: 2005-07-05 %% Type: language Subtag: ks Description: Kashmiri Added: 2005-07-05 %% Type: language Subtag: ku Description: Kurdish Added: 2005-07-05 %% Type: language Subtag: kv Description: Komi Added: 2005-07-05 %% Type: language Subtag: kw Description: Cornish Added: 2005-07-05 %% Type: language Subtag: ky Description: Kirghiz Added: 2005-07-05 %% Type: language Subtag: la Description: Latin Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: lb Description: Luxembourgish Description: Letzeburgesch Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: lg Description: Ganda Added: 2005-07-05 %% Type: language Ewell Expires January 6, 2006 [Page 18] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: li Description: Limburgan Description: Limburger Description: Limburgish Added: 2005-07-05 %% Type: language Subtag: ln Description: Lingala Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: lo Description: Lao Added: 2005-07-05 Suppress-Script: Laoo %% Type: language Subtag: lt Description: Lithuanian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: lu Description: Luba-Katanga Added: 2005-07-05 %% Type: language Subtag: lv Description: Latvian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: mg Description: Malagasy Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: mh Description: Marshallese Added: 2005-07-05 Suppress-Script: Latn %% Type: language Ewell Expires January 6, 2006 [Page 19] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: mi Description: Maori Added: 2005-07-05 %% Type: language Subtag: mk Description: Macedonian Added: 2005-07-05 Suppress-Script: Cyrl %% Type: language Subtag: ml Description: Malayalam Added: 2005-07-05 Suppress-Script: Mlym %% Type: language Subtag: mn Description: Mongolian Added: 2005-07-05 %% Type: language Subtag: mo Description: Moldavian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: mr Description: Marathi Added: 2005-07-05 Suppress-Script: Deva %% Type: language Subtag: ms Description: Malay Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: mt Description: Maltese Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: my Description: Burmese Ewell Expires January 6, 2006 [Page 20] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 Suppress-Script: Mymr %% Type: language Subtag: na Description: Nauru Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: nb Description: Norwegian Bokmål Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: nd Description: Ndebele, North Description: North Ndebele Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ne Description: Nepali Added: 2005-07-05 Suppress-Script: Deva %% Type: language Subtag: ng Description: Ndonga Added: 2005-07-05 %% Type: language Subtag: nl Description: Dutch Description: Flemish Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: nn Description: Norwegian Nynorsk Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: no Ewell Expires January 6, 2006 [Page 21] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Norwegian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: nr Description: Ndebele, South Description: South Ndebele Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: nv Description: Navajo Description: Navaho Added: 2005-07-05 %% Type: language Subtag: ny Description: Chichewa Description: Chewa Description: Nyanja Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: oc Description: Occitan (post 1500) Description: Provençal Added: 2005-07-05 %% Type: language Subtag: oj Description: Ojibwa Added: 2005-07-05 %% Type: language Subtag: om Description: Oromo Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: or Description: Oriya Added: 2005-07-05 Suppress-Script: Orya %% Ewell Expires January 6, 2006 [Page 22] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: os Description: Ossetian Description: Ossetic Added: 2005-07-05 %% Type: language Subtag: pa Description: Panjabi Description: Punjabi Added: 2005-07-05 Suppress-Script: Guru %% Type: language Subtag: pi Description: Pali Added: 2005-07-05 %% Type: language Subtag: pl Description: Polish Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ps Description: Pushto Added: 2005-07-05 Suppress-Script: Arab %% Type: language Subtag: pt Description: Portuguese Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: qu Description: Quechua Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: rm Description: Raeto-Romance Added: 2005-07-05 %% Type: language Ewell Expires January 6, 2006 [Page 23] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: rn Description: Rundi Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ro Description: Romanian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ru Description: Russian Added: 2005-07-05 Suppress-Script: Cyrl %% Type: language Subtag: rw Description: Kinyarwanda Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: sa Description: Sanskrit Added: 2005-07-05 %% Type: language Subtag: sc Description: Sardinian Added: 2005-07-05 %% Type: language Subtag: sd Description: Sindhi Added: 2005-07-05 %% Type: language Subtag: se Description: Northern Sami Added: 2005-07-05 %% Type: language Subtag: sg Description: Sango Added: 2005-07-05 Suppress-Script: Latn Ewell Expires January 6, 2006 [Page 24] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: sh Description: Serbo-Croatian Added: 2005-07-05 Deprecated: 2000-02-18 %% Type: language Subtag: si Description: Sinhala Description: Sinhalese Added: 2005-07-05 Suppress-Script: Sinh %% Type: language Subtag: sk Description: Slovak Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: sl Description: Slovenian Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: sm Description: Samoan Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: sn Description: Shona Added: 2005-07-05 %% Type: language Subtag: so Description: Somali Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: sq Description: Albanian Added: 2005-07-05 Suppress-Script: Latn Ewell Expires January 6, 2006 [Page 25] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: sr Description: Serbian Added: 2005-07-05 %% Type: language Subtag: ss Description: Swati Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: st Description: Sotho, Southern Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: su Description: Sundanese Added: 2005-07-05 %% Type: language Subtag: sv Description: Swedish Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: sw Description: Swahili Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ta Description: Tamil Added: 2005-07-05 Suppress-Script: Taml %% Type: language Subtag: te Description: Telugu Added: 2005-07-05 Suppress-Script: Telu %% Type: language Ewell Expires January 6, 2006 [Page 26] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: tg Description: Tajik Added: 2005-07-05 %% Type: language Subtag: th Description: Thai Added: 2005-07-05 Suppress-Script: Thai %% Type: language Subtag: ti Description: Tigrinya Added: 2005-07-05 Suppress-Script: Ethi %% Type: language Subtag: tk Description: Turkmen Added: 2005-07-05 %% Type: language Subtag: tl Description: Tagalog Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: tn Description: Tswana Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: to Description: Tonga (Tonga Islands) Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: tr Description: Turkish Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ts Description: Tsonga Ewell Expires January 6, 2006 [Page 27] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: tt Description: Tatar Added: 2005-07-05 %% Type: language Subtag: tw Description: Twi Added: 2005-07-05 %% Type: language Subtag: ty Description: Tahitian Added: 2005-07-05 %% Type: language Subtag: ug Description: Uighur Description: Uyghur Added: 2005-07-05 %% Type: language Subtag: uk Description: Ukrainian Added: 2005-07-05 Suppress-Script: Cyrl %% Type: language Subtag: ur Description: Urdu Added: 2005-07-05 Suppress-Script: Arab %% Type: language Subtag: uz Description: Uzbek Added: 2005-07-05 %% Type: language Subtag: ve Description: Venda Added: 2005-07-05 Suppress-Script: Latn %% Type: language Ewell Expires January 6, 2006 [Page 28] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: vi Description: Vietnamese Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: vo Description: Volapük Added: 2005-07-05 %% Type: language Subtag: wa Description: Walloon Added: 2005-07-05 %% Type: language Subtag: wo Description: Wolof Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: xh Description: Xhosa Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: yi Description: Yiddish Added: 2005-07-05 Suppress-Script: Hebr %% Type: language Subtag: yo Description: Yoruba Added: 2005-07-05 %% Type: language Subtag: za Description: Zhuang Description: Chuang Added: 2005-07-05 %% Type: language Subtag: zh Description: Chinese Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 29] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: zu Description: Zulu Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ace Description: Achinese Added: 2005-07-05 %% Type: language Subtag: ach Description: Acoli Added: 2005-07-05 %% Type: language Subtag: ada Description: Adangme Added: 2005-07-05 %% Type: language Subtag: ady Description: Adyghe Description: Adygei Added: 2005-07-05 %% Type: language Subtag: afa Description: Afro-Asiatic (Other) Added: 2005-07-05 %% Type: language Subtag: afh Description: Afrihili Added: 2005-07-05 %% Type: language Subtag: akk Description: Akkadian Added: 2005-07-05 %% Type: language Subtag: ale Description: Aleut Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 30] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: alg Description: Algonquian languages Added: 2005-07-05 %% Type: language Subtag: alt Description: Southern Altai Added: 2005-07-05 %% Type: language Subtag: ang Description: English, Old (ca. 450-1100) Added: 2005-07-05 %% Type: language Subtag: apa Description: Apache languages Added: 2005-07-05 %% Type: language Subtag: arc Description: Aramaic Added: 2005-07-05 %% Type: language Subtag: arn Description: Araucanian Added: 2005-07-05 %% Type: language Subtag: arp Description: Arapaho Added: 2005-07-05 %% Type: language Subtag: art Description: Artificial (Other) Added: 2005-07-05 %% Type: language Subtag: arw Description: Arawak Added: 2005-07-05 %% Type: language Subtag: ast Description: Asturian Ewell Expires January 6, 2006 [Page 31] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Bable Added: 2005-07-05 %% Type: language Subtag: ath Description: Athapascan languages Added: 2005-07-05 %% Type: language Subtag: aus Description: Australian languages Added: 2005-07-05 %% Type: language Subtag: awa Description: Awadhi Added: 2005-07-05 %% Type: language Subtag: bad Description: Banda Added: 2005-07-05 %% Type: language Subtag: bai Description: Bamileke languages Added: 2005-07-05 %% Type: language Subtag: bal Description: Baluchi Added: 2005-07-05 %% Type: language Subtag: ban Description: Balinese Added: 2005-07-05 %% Type: language Subtag: bas Description: Basa Added: 2005-07-05 %% Type: language Subtag: bat Description: Baltic (Other) Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 32] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: bej Description: Beja Added: 2005-07-05 %% Type: language Subtag: bem Description: Bemba Added: 2005-07-05 %% Type: language Subtag: ber Description: Berber (Other) Added: 2005-07-05 %% Type: language Subtag: bho Description: Bhojpuri Added: 2005-07-05 %% Type: language Subtag: bik Description: Bikol Added: 2005-07-05 %% Type: language Subtag: bin Description: Bini Added: 2005-07-05 %% Type: language Subtag: bla Description: Siksika Added: 2005-07-05 %% Type: language Subtag: bnt Description: Bantu (Other) Added: 2005-07-05 %% Type: language Subtag: bra Description: Braj Added: 2005-07-05 %% Type: language Subtag: btk Description: Batak (Indonesia) Ewell Expires January 6, 2006 [Page 33] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: language Subtag: bua Description: Buriat Added: 2005-07-05 %% Type: language Subtag: bug Description: Buginese Added: 2005-07-05 %% Type: language Subtag: byn Description: Blin Description: Bilin Added: 2005-07-05 %% Type: language Subtag: cad Description: Caddo Added: 2005-07-05 %% Type: language Subtag: cai Description: Central American Indian (Other) Added: 2005-07-05 %% Type: language Subtag: car Description: Carib Added: 2005-07-05 %% Type: language Subtag: cau Description: Caucasian (Other) Added: 2005-07-05 %% Type: language Subtag: ceb Description: Cebuano Added: 2005-07-05 %% Type: language Subtag: cel Description: Celtic (Other) Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 34] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: chb Description: Chibcha Added: 2005-07-05 %% Type: language Subtag: chg Description: Chagatai Added: 2005-07-05 %% Type: language Subtag: chk Description: Chuukese Added: 2005-07-05 %% Type: language Subtag: chm Description: Mari Added: 2005-07-05 %% Type: language Subtag: chn Description: Chinook jargon Added: 2005-07-05 %% Type: language Subtag: cho Description: Choctaw Added: 2005-07-05 %% Type: language Subtag: chp Description: Chipewyan Added: 2005-07-05 %% Type: language Subtag: chr Description: Cherokee Added: 2005-07-05 %% Type: language Subtag: chy Description: Cheyenne Added: 2005-07-05 %% Type: language Subtag: cmc Description: Chamic languages Ewell Expires January 6, 2006 [Page 35] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: language Subtag: cop Description: Coptic Added: 2005-07-05 %% Type: language Subtag: cpe Description: Creoles and pidgins, English-based (Other) Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: cpf Description: Creoles and pidgins, French-based (Other) Added: 2005-07-05 %% Type: language Subtag: cpp Description: Creoles and pidgins, Portuguese-based (Other) Added: 2005-07-05 %% Type: language Subtag: crh Description: Crimean Tatar Description: Crimean Turkish Added: 2005-07-05 %% Type: language Subtag: crp Description: Creoles and pidgins (Other) Added: 2005-07-05 %% Type: language Subtag: csb Description: Kashubian Added: 2005-07-05 %% Type: language Subtag: cus Description: Cushitic (Other) Added: 2005-07-05 %% Type: language Subtag: dak Description: Dakota Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 36] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: dar Description: Dargwa Added: 2005-07-05 %% Type: language Subtag: day Description: Dayak Added: 2005-07-05 %% Type: language Subtag: del Description: Delaware Added: 2005-07-05 %% Type: language Subtag: den Description: Slave (Athapascan) Added: 2005-07-05 %% Type: language Subtag: dgr Description: Dogrib Added: 2005-07-05 %% Type: language Subtag: din Description: Dinka Added: 2005-07-05 %% Type: language Subtag: doi Description: Dogri Added: 2005-07-05 %% Type: language Subtag: dra Description: Dravidian (Other) Added: 2005-07-05 %% Type: language Subtag: dsb Description: Lower Sorbian Added: 2005-07-05 %% Type: language Subtag: dua Ewell Expires January 6, 2006 [Page 37] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Duala Added: 2005-07-05 %% Type: language Subtag: dum Description: Dutch, Middle (ca. 1050-1350) Added: 2005-07-05 %% Type: language Subtag: dyu Description: Dyula Added: 2005-07-05 %% Type: language Subtag: efi Description: Efik Added: 2005-07-05 %% Type: language Subtag: egy Description: Egyptian (Ancient) Added: 2005-07-05 %% Type: language Subtag: eka Description: Ekajuk Added: 2005-07-05 %% Type: language Subtag: elx Description: Elamite Added: 2005-07-05 %% Type: language Subtag: enm Description: English, Middle (1100-1500) Added: 2005-07-05 %% Type: language Subtag: ewo Description: Ewondo Added: 2005-07-05 %% Type: language Subtag: fan Description: Fang Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 38] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: fat Description: Fanti Added: 2005-07-05 %% Type: language Subtag: fil Description: Filipino Description: Pilipino Added: 2005-07-05 %% Type: language Subtag: fiu Description: Finno-Ugrian (Other) Added: 2005-07-05 %% Type: language Subtag: fon Description: Fon Added: 2005-07-05 %% Type: language Subtag: frm Description: French, Middle (ca. 1400-1600) Added: 2005-07-05 %% Type: language Subtag: fro Description: French, Old (842-ca. 1400) Added: 2005-07-05 %% Type: language Subtag: fur Description: Friulian Added: 2005-07-05 %% Type: language Subtag: gaa Description: Ga Added: 2005-07-05 %% Type: language Subtag: gay Description: Gayo Added: 2005-07-05 %% Type: language Subtag: gba Ewell Expires January 6, 2006 [Page 39] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Gbaya Added: 2005-07-05 %% Type: language Subtag: gem Description: Germanic (Other) Added: 2005-07-05 %% Type: language Subtag: gez Description: Geez Added: 2005-07-05 %% Type: language Subtag: gil Description: Gilbertese Added: 2005-07-05 %% Type: language Subtag: gmh Description: German, Middle High (ca. 1050-1500) Added: 2005-07-05 %% Type: language Subtag: goh Description: German, Old High (ca. 750-1050) Added: 2005-07-05 %% Type: language Subtag: gon Description: Gondi Added: 2005-07-05 %% Type: language Subtag: gor Description: Gorontalo Added: 2005-07-05 %% Type: language Subtag: got Description: Gothic Added: 2005-07-05 %% Type: language Subtag: grb Description: Grebo Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 40] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: grc Description: Greek, Ancient (to 1453) Added: 2005-07-05 %% Type: language Subtag: gwi Description: Gwich´in Added: 2005-07-05 %% Type: language Subtag: hai Description: Haida Added: 2005-07-05 %% Type: language Subtag: haw Description: Hawaiian Added: 2005-07-05 %% Type: language Subtag: hil Description: Hiligaynon Added: 2005-07-05 %% Type: language Subtag: him Description: Himachali Added: 2005-07-05 %% Type: language Subtag: hit Description: Hittite Added: 2005-07-05 %% Type: language Subtag: hmn Description: Hmong Added: 2005-07-05 %% Type: language Subtag: hsb Description: Upper Sorbian Added: 2005-07-05 %% Type: language Subtag: hup Description: Hupa Ewell Expires January 6, 2006 [Page 41] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: language Subtag: iba Description: Iban Added: 2005-07-05 %% Type: language Subtag: ijo Description: Ijo Added: 2005-07-05 %% Type: language Subtag: ilo Description: Iloko Added: 2005-07-05 %% Type: language Subtag: inc Description: Indic (Other) Added: 2005-07-05 %% Type: language Subtag: ine Description: Indo-European (Other) Added: 2005-07-05 %% Type: language Subtag: inh Description: Ingush Added: 2005-07-05 %% Type: language Subtag: ira Description: Iranian (Other) Added: 2005-07-05 %% Type: language Subtag: iro Description: Iroquoian languages Added: 2005-07-05 %% Type: language Subtag: jbo Description: Lojban Added: 2005-07-05 %% Type: language Ewell Expires January 6, 2006 [Page 42] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: jpr Description: Judeo-Persian Added: 2005-07-05 %% Type: language Subtag: jrb Description: Judeo-Arabic Added: 2005-07-05 %% Type: language Subtag: kaa Description: Kara-Kalpak Added: 2005-07-05 %% Type: language Subtag: kab Description: Kabyle Added: 2005-07-05 %% Type: language Subtag: kac Description: Kachin Added: 2005-07-05 %% Type: language Subtag: kam Description: Kamba Added: 2005-07-05 %% Type: language Subtag: kar Description: Karen Added: 2005-07-05 %% Type: language Subtag: kaw Description: Kawi Added: 2005-07-05 %% Type: language Subtag: kbd Description: Kabardian Added: 2005-07-05 %% Type: language Subtag: kha Description: Khasi Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 43] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: khi Description: Khoisan (Other) Added: 2005-07-05 %% Type: language Subtag: kho Description: Khotanese Added: 2005-07-05 %% Type: language Subtag: kmb Description: Kimbundu Added: 2005-07-05 %% Type: language Subtag: kok Description: Konkani Added: 2005-07-05 Suppress-Script: Deva %% Type: language Subtag: kos Description: Kosraean Added: 2005-07-05 %% Type: language Subtag: kpe Description: Kpelle Added: 2005-07-05 %% Type: language Subtag: krc Description: Karachay-Balkar Added: 2005-07-05 %% Type: language Subtag: kro Description: Kru Added: 2005-07-05 %% Type: language Subtag: kru Description: Kurukh Added: 2005-07-05 %% Type: language Ewell Expires January 6, 2006 [Page 44] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: kum Description: Kumyk Added: 2005-07-05 %% Type: language Subtag: kut Description: Kutenai Added: 2005-07-05 %% Type: language Subtag: lad Description: Ladino Added: 2005-07-05 %% Type: language Subtag: lah Description: Lahnda Added: 2005-07-05 %% Type: language Subtag: lam Description: Lamba Added: 2005-07-05 %% Type: language Subtag: lez Description: Lezghian Added: 2005-07-05 %% Type: language Subtag: lol Description: Mongo Added: 2005-07-05 %% Type: language Subtag: loz Description: Lozi Added: 2005-07-05 %% Type: language Subtag: lua Description: Luba-Lulua Added: 2005-07-05 %% Type: language Subtag: lui Description: Luiseno Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 45] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: lun Description: Lunda Added: 2005-07-05 %% Type: language Subtag: luo Description: Luo (Kenya and Tanzania) Added: 2005-07-05 %% Type: language Subtag: lus Description: Lushai Added: 2005-07-05 %% Type: language Subtag: mad Description: Madurese Added: 2005-07-05 %% Type: language Subtag: mag Description: Magahi Added: 2005-07-05 %% Type: language Subtag: mai Description: Maithili Added: 2005-07-05 Suppress-Script: Deva %% Type: language Subtag: mak Description: Makasar Added: 2005-07-05 %% Type: language Subtag: man Description: Mandingo Added: 2005-07-05 %% Type: language Subtag: map Description: Austronesian (Other) Added: 2005-07-05 %% Type: language Ewell Expires January 6, 2006 [Page 46] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: mas Description: Masai Added: 2005-07-05 %% Type: language Subtag: mdf Description: Moksha Added: 2005-07-05 %% Type: language Subtag: mdr Description: Mandar Added: 2005-07-05 %% Type: language Subtag: men Description: Mende Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: mga Description: Irish, Middle (900-1200) Added: 2005-07-05 %% Type: language Subtag: mic Description: Mi'kmaq Description: Micmac Added: 2005-07-05 %% Type: language Subtag: min Description: Minangkabau Added: 2005-07-05 %% Type: language Subtag: mis Description: Miscellaneous languages Added: 2005-07-05 %% Type: language Subtag: mkh Description: Mon-Khmer (Other) Added: 2005-07-05 %% Type: language Subtag: mnc Ewell Expires January 6, 2006 [Page 47] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Manchu Added: 2005-07-05 %% Type: language Subtag: mni Description: Manipuri Added: 2005-07-05 %% Type: language Subtag: mno Description: Manobo languages Added: 2005-07-05 %% Type: language Subtag: moh Description: Mohawk Added: 2005-07-05 %% Type: language Subtag: mos Description: Mossi Added: 2005-07-05 %% Type: language Subtag: mul Description: Multiple languages Added: 2005-07-05 %% Type: language Subtag: mun Description: Munda languages Added: 2005-07-05 %% Type: language Subtag: mus Description: Creek Added: 2005-07-05 %% Type: language Subtag: mwl Description: Mirandese Added: 2005-07-05 %% Type: language Subtag: mwr Description: Marwari Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 48] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: myn Description: Mayan languages Added: 2005-07-05 %% Type: language Subtag: myv Description: Erzya Added: 2005-07-05 %% Type: language Subtag: nah Description: Nahuatl Added: 2005-07-05 %% Type: language Subtag: nai Description: North American Indian Added: 2005-07-05 %% Type: language Subtag: nap Description: Neapolitan Added: 2005-07-05 %% Type: language Subtag: nds Description: Low German Description: Low Saxon Description: German, Low Description: Saxon, Low Added: 2005-07-05 %% Type: language Subtag: new Description: Nepal Bhasa Description: Newari Added: 2005-07-05 %% Type: language Subtag: nia Description: Nias Added: 2005-07-05 %% Type: language Subtag: nic Description: Niger-Kordofanian (Other) Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 49] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: niu Description: Niuean Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: nog Description: Nogai Added: 2005-07-05 %% Type: language Subtag: non Description: Norse, Old Added: 2005-07-05 %% Type: language Subtag: nso Description: Northern Sotho Description: Pedi Description: Sepedi Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: nub Description: Nubian languages Added: 2005-07-05 %% Type: language Subtag: nwc Description: Classical Newari Description: Old Newari Description: Classical Nepal Bhasa Added: 2005-07-05 %% Type: language Subtag: nym Description: Nyamwezi Added: 2005-07-05 %% Type: language Subtag: nyn Description: Nyankole Added: 2005-07-05 %% Type: language Ewell Expires January 6, 2006 [Page 50] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: nyo Description: Nyoro Added: 2005-07-05 %% Type: language Subtag: nzi Description: Nzima Added: 2005-07-05 %% Type: language Subtag: osa Description: Osage Added: 2005-07-05 %% Type: language Subtag: ota Description: Turkish, Ottoman (1500-1928) Added: 2005-07-05 %% Type: language Subtag: oto Description: Otomian languages Added: 2005-07-05 %% Type: language Subtag: paa Description: Papuan (Other) Added: 2005-07-05 %% Type: language Subtag: pag Description: Pangasinan Added: 2005-07-05 %% Type: language Subtag: pal Description: Pahlavi Added: 2005-07-05 %% Type: language Subtag: pam Description: Pampanga Added: 2005-07-05 %% Type: language Subtag: pap Description: Papiamento Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 51] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: pau Description: Palauan Added: 2005-07-05 %% Type: language Subtag: peo Description: Persian, Old (ca. 600-400 B.C.) Added: 2005-07-05 %% Type: language Subtag: phi Description: Philippine (Other) Added: 2005-07-05 %% Type: language Subtag: phn Description: Phoenician Added: 2005-07-05 %% Type: language Subtag: pon Description: Pohnpeian Added: 2005-07-05 %% Type: language Subtag: pra Description: Prakrit languages Added: 2005-07-05 %% Type: language Subtag: pro Description: Provençal, Old (to 1500) Added: 2005-07-05 %% Type: language Subtag: qaa..qtz Description: PRIVATE USE Added: 2005-07-05 %% Type: language Subtag: raj Description: Rajasthani Added: 2005-07-05 %% Type: language Subtag: rap Ewell Expires January 6, 2006 [Page 52] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Rapanui Added: 2005-07-05 %% Type: language Subtag: rar Description: Rarotongan Added: 2005-07-05 %% Type: language Subtag: roa Description: Romance (Other) Added: 2005-07-05 %% Type: language Subtag: rom Description: Romany Added: 2005-07-05 %% Type: language Subtag: sad Description: Sandawe Added: 2005-07-05 %% Type: language Subtag: sah Description: Yakut Added: 2005-07-05 %% Type: language Subtag: sai Description: South American Indian (Other) Added: 2005-07-05 %% Type: language Subtag: sal Description: Salishan languages Added: 2005-07-05 %% Type: language Subtag: sam Description: Samaritan Aramaic Added: 2005-07-05 %% Type: language Subtag: sas Description: Sasak Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 53] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: sat Description: Santali Added: 2005-07-05 %% Type: language Subtag: scn Description: Sicilian Added: 2005-07-05 %% Type: language Subtag: sco Description: Scots Added: 2005-07-05 %% Type: language Subtag: sel Description: Selkup Added: 2005-07-05 %% Type: language Subtag: sem Description: Semitic (Other) Added: 2005-07-05 %% Type: language Subtag: sga Description: Irish, Old (to 900) Added: 2005-07-05 %% Type: language Subtag: sgn Description: Sign Languages Added: 2005-07-05 %% Type: language Subtag: shn Description: Shan Added: 2005-07-05 %% Type: language Subtag: sid Description: Sidamo Added: 2005-07-05 %% Type: language Subtag: sio Description: Siouan languages Ewell Expires January 6, 2006 [Page 54] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: language Subtag: sit Description: Sino-Tibetan (Other) Added: 2005-07-05 %% Type: language Subtag: sla Description: Slavic (Other) Added: 2005-07-05 %% Type: language Subtag: sma Description: Southern Sami Added: 2005-07-05 %% Type: language Subtag: smi Description: Sami languages (Other) Added: 2005-07-05 %% Type: language Subtag: smj Description: Lule Sami Added: 2005-07-05 %% Type: language Subtag: smn Description: Inari Sami Added: 2005-07-05 %% Type: language Subtag: sms Description: Skolt Sami Added: 2005-07-05 %% Type: language Subtag: snk Description: Soninke Added: 2005-07-05 %% Type: language Subtag: sog Description: Sogdian Added: 2005-07-05 %% Type: language Ewell Expires January 6, 2006 [Page 55] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: son Description: Songhai Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: srn Description: Sranan Tongo Added: 2005-07-05 %% Type: language Subtag: srr Description: Serer Added: 2005-07-05 %% Type: language Subtag: ssa Description: Nilo-Saharan (Other) Added: 2005-07-05 %% Type: language Subtag: suk Description: Sukuma Added: 2005-07-05 %% Type: language Subtag: sus Description: Susu Added: 2005-07-05 %% Type: language Subtag: sux Description: Sumerian Added: 2005-07-05 %% Type: language Subtag: syr Description: Syriac Added: 2005-07-05 %% Type: language Subtag: tai Description: Tai (Other) Added: 2005-07-05 %% Type: language Subtag: tem Description: Timne Ewell Expires January 6, 2006 [Page 56] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: ter Description: Tereno Added: 2005-07-05 %% Type: language Subtag: tet Description: Tetum Added: 2005-07-05 %% Type: language Subtag: tig Description: Tigre Added: 2005-07-05 %% Type: language Subtag: tiv Description: Tiv Added: 2005-07-05 %% Type: language Subtag: tkl Description: Tokelau Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: tlh Description: Klingon Description: tlhIngan-Hol Added: 2005-07-05 %% Type: language Subtag: tli Description: Tlingit Added: 2005-07-05 %% Type: language Subtag: tmh Description: Tamashek Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: tog Ewell Expires January 6, 2006 [Page 57] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Tonga (Nyasa) Added: 2005-07-05 %% Type: language Subtag: tpi Description: Tok Pisin Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: tsi Description: Tsimshian Added: 2005-07-05 %% Type: language Subtag: tum Description: Tumbuka Added: 2005-07-05 %% Type: language Subtag: tup Description: Tupi languages Added: 2005-07-05 %% Type: language Subtag: tut Description: Altaic (Other) Added: 2005-07-05 %% Type: language Subtag: tvl Description: Tuvalu Added: 2005-07-05 Suppress-Script: Latn %% Type: language Subtag: tyv Description: Tuvinian Added: 2005-07-05 %% Type: language Subtag: udm Description: Udmurt Added: 2005-07-05 %% Type: language Subtag: uga Description: Ugaritic Ewell Expires January 6, 2006 [Page 58] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: language Subtag: umb Description: Umbundu Added: 2005-07-05 %% Type: language Subtag: und Description: Undetermined Added: 2005-07-05 %% Type: language Subtag: vai Description: Vai Added: 2005-07-05 %% Type: language Subtag: vot Description: Votic Added: 2005-07-05 %% Type: language Subtag: wak Description: Wakashan languages Added: 2005-07-05 %% Type: language Subtag: wal Description: Walamo Added: 2005-07-05 %% Type: language Subtag: war Description: Waray Added: 2005-07-05 %% Type: language Subtag: was Description: Washo Added: 2005-07-05 %% Type: language Subtag: wen Description: Sorbian languages Added: 2005-07-05 %% Type: language Ewell Expires January 6, 2006 [Page 59] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: xal Description: Kalmyk Description: Oirat Added: 2005-07-05 %% Type: language Subtag: yao Description: Yao Added: 2005-07-05 %% Type: language Subtag: yap Description: Yapese Added: 2005-07-05 %% Type: language Subtag: ypk Description: Yupik languages Added: 2005-07-05 %% Type: language Subtag: zap Description: Zapotec Added: 2005-07-05 %% Type: language Subtag: zen Description: Zenaga Added: 2005-07-05 %% Type: language Subtag: znd Description: Zande Added: 2005-07-05 %% Type: language Subtag: zun Description: Zuni Added: 2005-07-05 %% Type: script Subtag: Arab Description: Arabic Added: 2005-07-05 %% Type: script Subtag: Armn Description: Armenian Ewell Expires January 6, 2006 [Page 60] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: script Subtag: Bali Description: Balinese Added: 2005-07-05 %% Type: script Subtag: Batk Description: Batak Added: 2005-07-05 %% Type: script Subtag: Beng Description: Bengali Added: 2005-07-05 %% Type: script Subtag: Blis Description: Blissymbols Added: 2005-07-05 %% Type: script Subtag: Bopo Description: Bopomofo Added: 2005-07-05 %% Type: script Subtag: Brah Description: Brahmi Added: 2005-07-05 %% Type: script Subtag: Brai Description: Braille Added: 2005-07-05 %% Type: script Subtag: Bugi Description: Buginese Added: 2005-07-05 %% Type: script Subtag: Buhd Description: Buhid Added: 2005-07-05 %% Type: script Ewell Expires January 6, 2006 [Page 61] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: Cans Description: Unified Canadian Aboriginal Syllabics Added: 2005-07-05 %% Type: script Subtag: Cham Description: Cham Added: 2005-07-05 %% Type: script Subtag: Cher Description: Cherokee Added: 2005-07-05 %% Type: script Subtag: Cirt Description: Cirth Added: 2005-07-05 %% Type: script Subtag: Copt Description: Coptic Added: 2005-07-05 %% Type: script Subtag: Cprt Description: Cypriot Added: 2005-07-05 %% Type: script Subtag: Cyrl Description: Cyrillic Added: 2005-07-05 %% Type: script Subtag: Cyrs Description: Cyrillic (Old Church Slavonic variant) Added: 2005-07-05 %% Type: script Subtag: Deva Description: Devanagari (Nagari) Added: 2005-07-05 %% Type: script Subtag: Dsrt Description: Deseret (Mormon) Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 62] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: script Subtag: Egyd Description: Egyptian demotic Added: 2005-07-05 %% Type: script Subtag: Egyh Description: Egyptian hieratic Added: 2005-07-05 %% Type: script Subtag: Egyp Description: Egyptian hieroglyphs Added: 2005-07-05 %% Type: script Subtag: Ethi Description: Ethiopic (Ge‘ez) Added: 2005-07-05 %% Type: script Subtag: Geok Description: Khutsuri (Asomtavruli and Nuskhuri) Added: 2005-07-05 %% Type: script Subtag: Geor Description: Georgian (Mkhedruli) Added: 2005-07-05 %% Type: script Subtag: Glag Description: Glagolitic Added: 2005-07-05 %% Type: script Subtag: Goth Description: Gothic Added: 2005-07-05 %% Type: script Subtag: Grek Description: Greek Added: 2005-07-05 %% Type: script Subtag: Gujr Ewell Expires January 6, 2006 [Page 63] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Gujarati Added: 2005-07-05 %% Type: script Subtag: Guru Description: Gurmukhi Added: 2005-07-05 %% Type: script Subtag: Hang Description: Hangul (Hangŭl, Hangeul) Added: 2005-07-05 %% Type: script Subtag: Hani Description: Han (Hanzi, Kanji, Hanja) Added: 2005-07-05 %% Type: script Subtag: Hano Description: Hanunoo (Hanunóo) Added: 2005-07-05 %% Type: script Subtag: Hans Description: Han (Simplified variant) Added: 2005-07-05 %% Type: script Subtag: Hant Description: Han (Traditional variant) Added: 2005-07-05 %% Type: script Subtag: Hebr Description: Hebrew Added: 2005-07-05 %% Type: script Subtag: Hira Description: Hiragana Added: 2005-07-05 %% Type: script Subtag: Hmng Description: Pahawh Hmong Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 64] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: script Subtag: Hrkt Description: (alias for Hiragana + Katakana) Added: 2005-07-05 %% Type: script Subtag: Hung Description: Old Hungarian Added: 2005-07-05 %% Type: script Subtag: Inds Description: Indus (Harappan) Added: 2005-07-05 %% Type: script Subtag: Ital Description: Old Italic (Etruscan, Oscan, etc.) Added: 2005-07-05 %% Type: script Subtag: Java Description: Javanese Added: 2005-07-05 %% Type: script Subtag: Kali Description: Kayah Li Added: 2005-07-05 %% Type: script Subtag: Kana Description: Katakana Added: 2005-07-05 %% Type: script Subtag: Khar Description: Kharoshthi Added: 2005-07-05 %% Type: script Subtag: Khmr Description: Khmer Added: 2005-07-05 %% Type: script Subtag: Knda Description: Kannada Ewell Expires January 6, 2006 [Page 65] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: script Subtag: Laoo Description: Lao Added: 2005-07-05 %% Type: script Subtag: Latf Description: Latin (Fraktur variant) Added: 2005-07-05 %% Type: script Subtag: Latg Description: Latin (Gaelic variant) Added: 2005-07-05 %% Type: script Subtag: Latn Description: Latin Added: 2005-07-05 %% Type: script Subtag: Lepc Description: Lepcha (Róng) Added: 2005-07-05 %% Type: script Subtag: Limb Description: Limbu Added: 2005-07-05 %% Type: script Subtag: Lina Description: Linear A Added: 2005-07-05 %% Type: script Subtag: Linb Description: Linear B Added: 2005-07-05 %% Type: script Subtag: Mand Description: Mandaean Added: 2005-07-05 %% Type: script Ewell Expires January 6, 2006 [Page 66] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: Maya Description: Mayan hieroglyphs Added: 2005-07-05 %% Type: script Subtag: Mero Description: Meroitic Added: 2005-07-05 %% Type: script Subtag: Mlym Description: Malayalam Added: 2005-07-05 %% Type: script Subtag: Mong Description: Mongolian Added: 2005-07-05 %% Type: script Subtag: Mymr Description: Myanmar (Burmese) Added: 2005-07-05 %% Type: script Subtag: Nkoo Description: N’Ko Added: 2005-07-05 %% Type: script Subtag: Ogam Description: Ogham Added: 2005-07-05 %% Type: script Subtag: Orkh Description: Orkhon Added: 2005-07-05 %% Type: script Subtag: Orya Description: Oriya Added: 2005-07-05 %% Type: script Subtag: Osma Description: Osmanya Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 67] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: script Subtag: Perm Description: Old Permic Added: 2005-07-05 %% Type: script Subtag: Phag Description: Phags-pa Added: 2005-07-05 %% Type: script Subtag: Phnx Description: Phoenician Added: 2005-07-05 %% Type: script Subtag: Plrd Description: Pollard Phonetic Added: 2005-07-05 %% Type: script Subtag: Qaaa..Qabx Description: PRIVATE USE Added: 2005-07-05 %% Type: script Subtag: Roro Description: Rongorongo Added: 2005-07-05 %% Type: script Subtag: Runr Description: Runic Added: 2005-07-05 %% Type: script Subtag: Sara Description: Sarati Added: 2005-07-05 %% Type: script Subtag: Shaw Description: Shavian (Shaw) Added: 2005-07-05 %% Type: script Subtag: Sinh Ewell Expires January 6, 2006 [Page 68] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Sinhala Added: 2005-07-05 %% Type: script Subtag: Sylo Description: Syloti Nagri Added: 2005-07-05 %% Type: script Subtag: Syrc Description: Syriac Added: 2005-07-05 %% Type: script Subtag: Syre Description: Syriac (Estrangelo variant) Added: 2005-07-05 %% Type: script Subtag: Syrj Description: Syriac (Western variant) Added: 2005-07-05 %% Type: script Subtag: Syrn Description: Syriac (Eastern variant) Added: 2005-07-05 %% Type: script Subtag: Tagb Description: Tagbanwa Added: 2005-07-05 %% Type: script Subtag: Tale Description: Tai Le Added: 2005-07-05 %% Type: script Subtag: Talu Description: New Tai Lue Added: 2005-07-05 %% Type: script Subtag: Taml Description: Tamil Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 69] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: script Subtag: Telu Description: Telugu Added: 2005-07-05 %% Type: script Subtag: Teng Description: Tengwar Added: 2005-07-05 %% Type: script Subtag: Tfng Description: Tifinagh (Berber) Added: 2005-07-05 %% Type: script Subtag: Tglg Description: Tagalog Added: 2005-07-05 %% Type: script Subtag: Thaa Description: Thaana Added: 2005-07-05 %% Type: script Subtag: Thai Description: Thai Added: 2005-07-05 %% Type: script Subtag: Tibt Description: Tibetan Added: 2005-07-05 %% Type: script Subtag: Ugar Description: Ugaritic Added: 2005-07-05 %% Type: script Subtag: Vaii Description: Vai Added: 2005-07-05 %% Type: script Subtag: Visp Description: Visible Speech Ewell Expires January 6, 2006 [Page 70] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: script Subtag: Xpeo Description: Old Persian Added: 2005-07-05 %% Type: script Subtag: Xsux Description: Cuneiform, Sumero-Akkadian Added: 2005-07-05 %% Type: script Subtag: Yiii Description: Yi Added: 2005-07-05 %% Type: script Subtag: Zxxx Description: Code for unwritten languages Added: 2005-07-05 %% Type: script Subtag: Zyyy Description: Code for undetermined script Added: 2005-07-05 %% Type: script Subtag: Zzzz Description: Code for uncoded script Added: 2005-07-05 %% Type: region Subtag: AA Description: PRIVATE USE Added: 2005-07-05 %% Type: region Subtag: AD Description: Andorra Added: 2005-07-05 %% Type: region Subtag: AE Description: United Arab Emirates Added: 2005-07-05 %% Type: region Ewell Expires January 6, 2006 [Page 71] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: AF Description: Afghanistan Added: 2005-07-05 %% Type: region Subtag: AG Description: Antigua and Barbuda Added: 2005-07-05 %% Type: region Subtag: AI Description: Anguilla Added: 2005-07-05 %% Type: region Subtag: AL Description: Albania Added: 2005-07-05 %% Type: region Subtag: AM Description: Armenia Added: 2005-07-05 %% Type: region Subtag: AN Description: Netherlands Antilles Added: 2005-07-05 %% Type: region Subtag: AO Description: Angola Added: 2005-07-05 %% Type: region Subtag: AQ Description: Antarctica Added: 2005-07-05 %% Type: region Subtag: AR Description: Argentina Added: 2005-07-05 %% Type: region Subtag: AS Description: American Samoa Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 72] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: region Subtag: AT Description: Austria Added: 2005-07-05 %% Type: region Subtag: AU Description: Australia Added: 2005-07-05 %% Type: region Subtag: AW Description: Aruba Added: 2005-07-05 %% Type: region Subtag: AX Description: Åland Islands Added: 2005-07-05 %% Type: region Subtag: AZ Description: Azerbaijan Added: 2005-07-05 %% Type: region Subtag: BA Description: Bosnia and Herzegovina Added: 2005-07-05 %% Type: region Subtag: BB Description: Barbados Added: 2005-07-05 %% Type: region Subtag: BD Description: Bangladesh Added: 2005-07-05 %% Type: region Subtag: BE Description: Belgium Added: 2005-07-05 %% Type: region Subtag: BF Ewell Expires January 6, 2006 [Page 73] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Burkina Faso Added: 2005-07-05 %% Type: region Subtag: BG Description: Bulgaria Added: 2005-07-05 %% Type: region Subtag: BH Description: Bahrain Added: 2005-07-05 %% Type: region Subtag: BI Description: Burundi Added: 2005-07-05 %% Type: region Subtag: BJ Description: Benin Added: 2005-07-05 %% Type: region Subtag: BM Description: Bermuda Added: 2005-07-05 %% Type: region Subtag: BN Description: Brunei Darussalam Added: 2005-07-05 %% Type: region Subtag: BO Description: Bolivia Added: 2005-07-05 %% Type: region Subtag: BR Description: Brazil Added: 2005-07-05 %% Type: region Subtag: BS Description: Bahamas Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 74] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: region Subtag: BT Description: Bhutan Added: 2005-07-05 %% Type: region Subtag: BU Description: Burma Added: 2005-07-05 Preferred-Value: MM Deprecated: 1989-12-05 %% Type: region Subtag: BV Description: Bouvet Island Added: 2005-07-05 %% Type: region Subtag: BW Description: Botswana Added: 2005-07-05 %% Type: region Subtag: BY Description: Belarus Added: 2005-07-05 %% Type: region Subtag: BZ Description: Belize Added: 2005-07-05 %% Type: region Subtag: CA Description: Canada Added: 2005-07-05 %% Type: region Subtag: CC Description: Cocos (Keeling) Islands Added: 2005-07-05 %% Type: region Subtag: CD Description: Congo, The Democratic Republic of the Added: 2005-07-05 %% Type: region Ewell Expires January 6, 2006 [Page 75] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: CF Description: Central African Republic Added: 2005-07-05 %% Type: region Subtag: CG Description: Congo Added: 2005-07-05 %% Type: region Subtag: CH Description: Switzerland Added: 2005-07-05 %% Type: region Subtag: CI Description: Côte d'Ivoire Added: 2005-07-05 %% Type: region Subtag: CK Description: Cook Islands Added: 2005-07-05 %% Type: region Subtag: CL Description: Chile Added: 2005-07-05 %% Type: region Subtag: CM Description: Cameroon Added: 2005-07-05 %% Type: region Subtag: CN Description: China Added: 2005-07-05 %% Type: region Subtag: CO Description: Colombia Added: 2005-07-05 %% Type: region Subtag: CR Description: Costa Rica Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 76] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: region Subtag: CS Description: Serbia and Montenegro Added: 2005-07-05 %% Type: region Subtag: CU Description: Cuba Added: 2005-07-05 %% Type: region Subtag: CV Description: Cape Verde Added: 2005-07-05 %% Type: region Subtag: CX Description: Christmas Island Added: 2005-07-05 %% Type: region Subtag: CY Description: Cyprus Added: 2005-07-05 %% Type: region Subtag: CZ Description: Czech Republic Added: 2005-07-05 %% Type: region Subtag: DD Description: German Democratic Republic Added: 2005-07-05 Preferred-Value: DE Deprecated: 1990-10-30 %% Type: region Subtag: DE Description: Germany Added: 2005-07-05 %% Type: region Subtag: DJ Description: Djibouti Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 77] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: region Subtag: DK Description: Denmark Added: 2005-07-05 %% Type: region Subtag: DM Description: Dominica Added: 2005-07-05 %% Type: region Subtag: DO Description: Dominican Republic Added: 2005-07-05 %% Type: region Subtag: DZ Description: Algeria Added: 2005-07-05 %% Type: region Subtag: EC Description: Ecuador Added: 2005-07-05 %% Type: region Subtag: EE Description: Estonia Added: 2005-07-05 %% Type: region Subtag: EG Description: Egypt Added: 2005-07-05 %% Type: region Subtag: EH Description: Western Sahara Added: 2005-07-05 %% Type: region Subtag: ER Description: Eritrea Added: 2005-07-05 %% Type: region Subtag: ES Description: Spain Ewell Expires January 6, 2006 [Page 78] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: region Subtag: ET Description: Ethiopia Added: 2005-07-05 %% Type: region Subtag: FI Description: Finland Added: 2005-07-05 %% Type: region Subtag: FJ Description: Fiji Added: 2005-07-05 %% Type: region Subtag: FK Description: Falkland Islands (Malvinas) Added: 2005-07-05 %% Type: region Subtag: FM Description: Micronesia, Federated States of Added: 2005-07-05 %% Type: region Subtag: FO Description: Faroe Islands Added: 2005-07-05 %% Type: region Subtag: FR Description: France Added: 2005-07-05 %% Type: region Subtag: FX Description: Metropolitan France Added: 2005-07-05 Preferred-Value: FR Deprecated: 1997-07-14 %% Type: region Subtag: GA Description: Gabon Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 79] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: region Subtag: GB Description: United Kingdom Added: 2005-07-05 %% Type: region Subtag: GD Description: Grenada Added: 2005-07-05 %% Type: region Subtag: GE Description: Georgia Added: 2005-07-05 %% Type: region Subtag: GF Description: French Guiana Added: 2005-07-05 %% Type: region Subtag: GH Description: Ghana Added: 2005-07-05 %% Type: region Subtag: GI Description: Gibraltar Added: 2005-07-05 %% Type: region Subtag: GL Description: Greenland Added: 2005-07-05 %% Type: region Subtag: GM Description: Gambia Added: 2005-07-05 %% Type: region Subtag: GN Description: Guinea Added: 2005-07-05 %% Type: region Subtag: GP Ewell Expires January 6, 2006 [Page 80] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Guadeloupe Added: 2005-07-05 %% Type: region Subtag: GQ Description: Equatorial Guinea Added: 2005-07-05 %% Type: region Subtag: GR Description: Greece Added: 2005-07-05 %% Type: region Subtag: GS Description: South Georgia and the South Sandwich Islands Added: 2005-07-05 %% Type: region Subtag: GT Description: Guatemala Added: 2005-07-05 %% Type: region Subtag: GU Description: Guam Added: 2005-07-05 %% Type: region Subtag: GW Description: Guinea-Bissau Added: 2005-07-05 %% Type: region Subtag: GY Description: Guyana Added: 2005-07-05 %% Type: region Subtag: HK Description: Hong Kong Added: 2005-07-05 %% Type: region Subtag: HM Description: Heard Island and McDonald Islands Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 81] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: region Subtag: HN Description: Honduras Added: 2005-07-05 %% Type: region Subtag: HR Description: Croatia Added: 2005-07-05 %% Type: region Subtag: HT Description: Haiti Added: 2005-07-05 %% Type: region Subtag: HU Description: Hungary Added: 2005-07-05 %% Type: region Subtag: ID Description: Indonesia Added: 2005-07-05 %% Type: region Subtag: IE Description: Ireland Added: 2005-07-05 %% Type: region Subtag: IL Description: Israel Added: 2005-07-05 %% Type: region Subtag: IN Description: India Added: 2005-07-05 %% Type: region Subtag: IO Description: British Indian Ocean Territory Added: 2005-07-05 %% Type: region Subtag: IQ Description: Iraq Ewell Expires January 6, 2006 [Page 82] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: region Subtag: IR Description: Iran, Islamic Republic of Added: 2005-07-05 %% Type: region Subtag: IS Description: Iceland Added: 2005-07-05 %% Type: region Subtag: IT Description: Italy Added: 2005-07-05 %% Type: region Subtag: JM Description: Jamaica Added: 2005-07-05 %% Type: region Subtag: JO Description: Jordan Added: 2005-07-05 %% Type: region Subtag: JP Description: Japan Added: 2005-07-05 %% Type: region Subtag: KE Description: Kenya Added: 2005-07-05 %% Type: region Subtag: KG Description: Kyrgyzstan Added: 2005-07-05 %% Type: region Subtag: KH Description: Cambodia Added: 2005-07-05 %% Type: region Ewell Expires January 6, 2006 [Page 83] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: KI Description: Kiribati Added: 2005-07-05 %% Type: region Subtag: KM Description: Comoros Added: 2005-07-05 %% Type: region Subtag: KN Description: Saint Kitts and Nevis Added: 2005-07-05 %% Type: region Subtag: KP Description: Korea, Democratic People's Republic of Added: 2005-07-05 %% Type: region Subtag: KR Description: Korea, Republic of Added: 2005-07-05 %% Type: region Subtag: KW Description: Kuwait Added: 2005-07-05 %% Type: region Subtag: KY Description: Cayman Islands Added: 2005-07-05 %% Type: region Subtag: KZ Description: Kazakhstan Added: 2005-07-05 %% Type: region Subtag: LA Description: Lao People's Democratic Republic Added: 2005-07-05 %% Type: region Subtag: LB Description: Lebanon Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 84] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: region Subtag: LC Description: Saint Lucia Added: 2005-07-05 %% Type: region Subtag: LI Description: Liechtenstein Added: 2005-07-05 %% Type: region Subtag: LK Description: Sri Lanka Added: 2005-07-05 %% Type: region Subtag: LR Description: Liberia Added: 2005-07-05 %% Type: region Subtag: LS Description: Lesotho Added: 2005-07-05 %% Type: region Subtag: LT Description: Lithuania Added: 2005-07-05 %% Type: region Subtag: LU Description: Luxembourg Added: 2005-07-05 %% Type: region Subtag: LV Description: Latvia Added: 2005-07-05 %% Type: region Subtag: LY Description: Libyan Arab Jamahiriya Added: 2005-07-05 %% Type: region Subtag: MA Ewell Expires January 6, 2006 [Page 85] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Morocco Added: 2005-07-05 %% Type: region Subtag: MC Description: Monaco Added: 2005-07-05 %% Type: region Subtag: MD Description: Moldova, Republic of Added: 2005-07-05 %% Type: region Subtag: MG Description: Madagascar Added: 2005-07-05 %% Type: region Subtag: MH Description: Marshall Islands Added: 2005-07-05 %% Type: region Subtag: MK Description: Macedonia, The Former Yugoslav Republic of Added: 2005-07-05 %% Type: region Subtag: ML Description: Mali Added: 2005-07-05 %% Type: region Subtag: MM Description: Myanmar Added: 2005-07-05 %% Type: region Subtag: MN Description: Mongolia Added: 2005-07-05 %% Type: region Subtag: MO Description: Macao Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 86] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: region Subtag: MP Description: Northern Mariana Islands Added: 2005-07-05 %% Type: region Subtag: MQ Description: Martinique Added: 2005-07-05 %% Type: region Subtag: MR Description: Mauritania Added: 2005-07-05 %% Type: region Subtag: MS Description: Montserrat Added: 2005-07-05 %% Type: region Subtag: MT Description: Malta Added: 2005-07-05 %% Type: region Subtag: MU Description: Mauritius Added: 2005-07-05 %% Type: region Subtag: MV Description: Maldives Added: 2005-07-05 %% Type: region Subtag: MW Description: Malawi Added: 2005-07-05 %% Type: region Subtag: MX Description: Mexico Added: 2005-07-05 %% Type: region Subtag: MY Description: Malaysia Ewell Expires January 6, 2006 [Page 87] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: region Subtag: MZ Description: Mozambique Added: 2005-07-05 %% Type: region Subtag: NA Description: Namibia Added: 2005-07-05 %% Type: region Subtag: NC Description: New Caledonia Added: 2005-07-05 %% Type: region Subtag: NE Description: Niger Added: 2005-07-05 %% Type: region Subtag: NF Description: Norfolk Island Added: 2005-07-05 %% Type: region Subtag: NG Description: Nigeria Added: 2005-07-05 %% Type: region Subtag: NI Description: Nicaragua Added: 2005-07-05 %% Type: region Subtag: NL Description: Netherlands Added: 2005-07-05 %% Type: region Subtag: NO Description: Norway Added: 2005-07-05 %% Type: region Ewell Expires January 6, 2006 [Page 88] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: NP Description: Nepal Added: 2005-07-05 %% Type: region Subtag: NR Description: Nauru Added: 2005-07-05 %% Type: region Subtag: NT Description: Neutral Zone Added: 2005-07-05 Deprecated: 1993-07-12 %% Type: region Subtag: NU Description: Niue Added: 2005-07-05 %% Type: region Subtag: NZ Description: New Zealand Added: 2005-07-05 %% Type: region Subtag: OM Description: Oman Added: 2005-07-05 %% Type: region Subtag: PA Description: Panama Added: 2005-07-05 %% Type: region Subtag: PE Description: Peru Added: 2005-07-05 %% Type: region Subtag: PF Description: French Polynesia Added: 2005-07-05 %% Type: region Subtag: PG Description: Papua New Guinea Ewell Expires January 6, 2006 [Page 89] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: region Subtag: PH Description: Philippines Added: 2005-07-05 %% Type: region Subtag: PK Description: Pakistan Added: 2005-07-05 %% Type: region Subtag: PL Description: Poland Added: 2005-07-05 %% Type: region Subtag: PM Description: Saint Pierre and Miquelon Added: 2005-07-05 %% Type: region Subtag: PN Description: Pitcairn Added: 2005-07-05 %% Type: region Subtag: PR Description: Puerto Rico Added: 2005-07-05 %% Type: region Subtag: PS Description: Palestinian Territory, Occupied Added: 2005-07-05 %% Type: region Subtag: PT Description: Portugal Added: 2005-07-05 %% Type: region Subtag: PW Description: Palau Added: 2005-07-05 %% Type: region Ewell Expires January 6, 2006 [Page 90] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: PY Description: Paraguay Added: 2005-07-05 %% Type: region Subtag: QA Description: Qatar Added: 2005-07-05 %% Type: region Subtag: QM..QZ Description: PRIVATE USE Added: 2005-07-05 %% Type: region Subtag: RE Description: Réunion Added: 2005-07-05 %% Type: region Subtag: RO Description: Romania Added: 2005-07-05 %% Type: region Subtag: RU Description: Russian Federation Added: 2005-07-05 %% Type: region Subtag: RW Description: Rwanda Added: 2005-07-05 %% Type: region Subtag: SA Description: Saudi Arabia Added: 2005-07-05 %% Type: region Subtag: SB Description: Solomon Islands Added: 2005-07-05 %% Type: region Subtag: SC Description: Seychelles Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 91] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: region Subtag: SD Description: Sudan Added: 2005-07-05 %% Type: region Subtag: SE Description: Sweden Added: 2005-07-05 %% Type: region Subtag: SG Description: Singapore Added: 2005-07-05 %% Type: region Subtag: SH Description: Saint Helena Added: 2005-07-05 %% Type: region Subtag: SI Description: Slovenia Added: 2005-07-05 %% Type: region Subtag: SJ Description: Svalbard and Jan Mayen Added: 2005-07-05 %% Type: region Subtag: SK Description: Slovakia Added: 2005-07-05 %% Type: region Subtag: SL Description: Sierra Leone Added: 2005-07-05 %% Type: region Subtag: SM Description: San Marino Added: 2005-07-05 %% Type: region Subtag: SN Ewell Expires January 6, 2006 [Page 92] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Senegal Added: 2005-07-05 %% Type: region Subtag: SO Description: Somalia Added: 2005-07-05 %% Type: region Subtag: SR Description: Suriname Added: 2005-07-05 %% Type: region Subtag: ST Description: Sao Tome and Principe Added: 2005-07-05 %% Type: region Subtag: SU Description: Union of Soviet Socialist Republics Added: 2005-07-05 Deprecated: 1992-08-30 %% Type: region Subtag: SV Description: El Salvador Added: 2005-07-05 %% Type: region Subtag: SY Description: Syrian Arab Republic Added: 2005-07-05 %% Type: region Subtag: SZ Description: Swaziland Added: 2005-07-05 %% Type: region Subtag: TC Description: Turks and Caicos Islands Added: 2005-07-05 %% Type: region Subtag: TD Description: Chad Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 93] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: region Subtag: TF Description: French Southern Territories Added: 2005-07-05 %% Type: region Subtag: TG Description: Togo Added: 2005-07-05 %% Type: region Subtag: TH Description: Thailand Added: 2005-07-05 %% Type: region Subtag: TJ Description: Tajikistan Added: 2005-07-05 %% Type: region Subtag: TK Description: Tokelau Added: 2005-07-05 %% Type: region Subtag: TL Description: Timor-Leste Added: 2005-07-05 %% Type: region Subtag: TM Description: Turkmenistan Added: 2005-07-05 %% Type: region Subtag: TN Description: Tunisia Added: 2005-07-05 %% Type: region Subtag: TO Description: Tonga Added: 2005-07-05 %% Type: region Subtag: TP Ewell Expires January 6, 2006 [Page 94] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: East Timor Added: 2005-07-05 Preferred-Value: TL Deprecated: 2002-11-15 %% Type: region Subtag: TR Description: Turkey Added: 2005-07-05 %% Type: region Subtag: TT Description: Trinidad and Tobago Added: 2005-07-05 %% Type: region Subtag: TV Description: Tuvalu Added: 2005-07-05 %% Type: region Subtag: TW Description: Taiwan, Province of China Added: 2005-07-05 %% Type: region Subtag: TZ Description: Tanzania, United Republic of Added: 2005-07-05 %% Type: region Subtag: UA Description: Ukraine Added: 2005-07-05 %% Type: region Subtag: UG Description: Uganda Added: 2005-07-05 %% Type: region Subtag: UM Description: United States Minor Outlying Islands Added: 2005-07-05 %% Type: region Subtag: US Description: United States Ewell Expires January 6, 2006 [Page 95] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-05 %% Type: region Subtag: UY Description: Uruguay Added: 2005-07-05 %% Type: region Subtag: UZ Description: Uzbekistan Added: 2005-07-05 %% Type: region Subtag: VA Description: Holy See (Vatican City State) Added: 2005-07-05 %% Type: region Subtag: VC Description: Saint Vincent and the Grenadines Added: 2005-07-05 %% Type: region Subtag: VE Description: Venezuela Added: 2005-07-05 %% Type: region Subtag: VG Description: Virgin Islands, British Added: 2005-07-05 %% Type: region Subtag: VI Description: Virgin Islands, U.S. Added: 2005-07-05 %% Type: region Subtag: VN Description: Viet Nam Added: 2005-07-05 %% Type: region Subtag: VU Description: Vanuatu Added: 2005-07-05 %% Type: region Ewell Expires January 6, 2006 [Page 96] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: WF Description: Wallis and Futuna Added: 2005-07-05 %% Type: region Subtag: WS Description: Samoa Added: 2005-07-05 %% Type: region Subtag: XA..XZ Description: PRIVATE USE Added: 2005-07-05 %% Type: region Subtag: YD Description: Yemen, Democratic Added: 2005-07-05 Preferred-Value: YE Deprecated: 1990-08-14 %% Type: region Subtag: YE Description: Yemen Added: 2005-07-05 %% Type: region Subtag: YT Description: Mayotte Added: 2005-07-05 %% Type: region Subtag: YU Description: Yugoslavia Added: 2005-07-05 Preferred-Value: CS Deprecated: 2003-07-23 %% Type: region Subtag: ZA Description: South Africa Added: 2005-07-05 %% Type: region Subtag: ZM Description: Zambia Added: 2005-07-05 %% Ewell Expires January 6, 2006 [Page 97] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: region Subtag: ZR Description: Zaire Added: 2005-07-05 Preferred-Value: CD Deprecated: 1997-07-14 %% Type: region Subtag: ZW Description: Zimbabwe Added: 2005-07-05 %% Type: region Subtag: ZZ Description: PRIVATE USE Added: 2005-07-05 %% Type: region Subtag: 001 Description: World Added: 2005-07-05 %% Type: region Subtag: 002 Description: Africa Added: 2005-07-05 %% Type: region Subtag: 005 Description: South America Added: 2005-07-05 %% Type: region Subtag: 009 Description: Oceania Added: 2005-07-05 %% Type: region Subtag: 011 Description: Western Africa Added: 2005-07-05 %% Type: region Subtag: 013 Description: Central America Added: 2005-07-05 %% Type: region Ewell Expires January 6, 2006 [Page 98] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: 014 Description: Eastern Africa Added: 2005-07-05 %% Type: region Subtag: 015 Description: Northern Africa Added: 2005-07-05 %% Type: region Subtag: 017 Description: Middle Africa Added: 2005-07-05 %% Type: region Subtag: 018 Description: Southern Africa Added: 2005-07-05 %% Type: region Subtag: 019 Description: Americas Added: 2005-07-05 %% Type: region Subtag: 021 Description: Northern America Added: 2005-07-05 %% Type: region Subtag: 029 Description: Caribbean Added: 2005-07-05 %% Type: region Subtag: 030 Description: Eastern Asia Added: 2005-07-05 %% Type: region Subtag: 034 Description: Southern Asia Added: 2005-07-05 %% Type: region Subtag: 035 Description: South-Eastern Asia Added: 2005-07-05 Ewell Expires January 6, 2006 [Page 99] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: region Subtag: 039 Description: Southern Europe Added: 2005-07-05 %% Type: region Subtag: 053 Description: Australia and New Zealand Added: 2005-07-05 %% Type: region Subtag: 054 Description: Melanesia Added: 2005-07-05 %% Type: region Subtag: 057 Description: Micronesia Added: 2005-07-05 %% Type: region Subtag: 061 Description: Polynesia Added: 2005-07-05 %% Type: region Subtag: 142 Description: Asia Added: 2005-07-05 %% Type: region Subtag: 143 Description: Central Asia Added: 2005-07-05 %% Type: region Subtag: 145 Description: Western Asia Added: 2005-07-05 %% Type: region Subtag: 150 Description: Europe Added: 2005-07-05 %% Type: region Subtag: 151 Ewell Expires January 6, 2006 [Page 100] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Eastern Europe Added: 2005-07-05 %% Type: region Subtag: 154 Description: Northern Europe Added: 2005-07-05 %% Type: region Subtag: 155 Description: Western Europe Added: 2005-07-05 %% Type: region Subtag: 419 Description: Latin America and the Caribbean Added: 2005-07-05 %% Type: variant Subtag: 1901 Description: Traditional German orthography Added: 2005-07-05 Prefix: de %% Type: variant Subtag: 1996 Description: German orthography of 1996 Added: 2005-07-05 Prefix: de %% Type: variant Subtag: nedis Description: Natisone dialect Description: Nadiza dialect Added: 2005-07-05 Prefix: sl %% Type: variant Subtag: rozaj Description: Resian Description: Resianic Description: Rezijan Added: 2005-07-05 Prefix: sl %% Type: grandfathered Tag: art-lojban Description: Lojban Ewell Expires January 6, 2006 [Page 101] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2001-11-11 Preferred-Value: jbo Deprecated: 2003-09-02 Comments: replaced by ISO code jbo %% Type: grandfathered Tag: cel-gaulish Description: Gaulish Added: 2001-05-25 %% Type: grandfathered Tag: en-boont Description: Boontling Added: 2003-02-14 %% Type: grandfathered Tag: en-GB-oed Description: English, Oxford English Dictionary spelling Added: 2003-07-09 %% Type: grandfathered Tag: en-scouse Description: Scouse Added: 2000-05-25 %% Type: grandfathered Tag: i-ami Description: 'Amis Added: 1999-05-25 %% Type: grandfathered Tag: i-bnn Description: Bunun Added: 1999-05-25 %% Type: grandfathered Tag: i-default Description: Default Language Added: 1998-03-10 %% Type: grandfathered Tag: i-enochian Description: Enochian Added: 2002-07-03 %% Type: grandfathered Tag: i-hak Description: Hakka Ewell Expires January 6, 2006 [Page 102] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 1999-01-31 Preferred-Value: zh-hakka Deprecated: 2000-01-10 %% Type: grandfathered Tag: i-klingon Description: Klingon Added: 1999-05-26 Preferred-Value: tlh Deprecated: 2004-02-24 Comments: replaced by ISO code tlh %% Type: grandfathered Tag: i-lux Description: Luxembourgish Added: 1997-09-19 Preferred-Value: lb Deprecated: 1998-09-09 Comments: replaced by ISO code lb %% Type: grandfathered Tag: i-mingo Description: Mingo Added: 1997-09-19 %% Type: grandfathered Tag: i-navajo Description: Navajo Added: 1997-09-19 Preferred-Value: nv Deprecated: 2000-02-18 Comments: replaced by ISO code nv %% Type: grandfathered Tag: i-pwn Description: Paiwan Added: 1999-05-25 %% Type: grandfathered Tag: i-tao Description: Tao Added: 1999-05-25 %% Type: grandfathered Tag: i-tay Description: Tayal Added: 1999-05-25 %% Ewell Expires January 6, 2006 [Page 103] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: grandfathered Tag: i-tsu Description: Tsou Added: 1999-05-25 %% Type: grandfathered Tag: no-bok Description: Norwegian Bokmal Added: 1995-08-23 Preferred-Value: nb Deprecated: 2000-02-18 Comments: replaced by ISO code nb %% Type: grandfathered Tag: no-nyn Description: Norwegian Nynorsk Added: 1995-08-23 Preferred-Value: nn Deprecated: 2000-02-18 Comments: replaced by ISO code nn %% Type: grandfathered Tag: sgn-BE-fr Description: Belgian-French Sign Language Added: 2001-11-11 %% Type: grandfathered Tag: sgn-BE-nl Description: Belgian-Flemish Sign Language Added: 2001-11-11 %% Type: grandfathered Tag: sgn-CH-de Description: Swiss German Sign Language Added: 2001-11-11 %% Type: grandfathered Tag: zh-gan Description: Kan or Gan Added: 1999-12-18 %% Type: grandfathered Tag: zh-guoyu Description: Mandarin or Standard Chinese Added: 1999-12-18 %% Type: grandfathered Tag: zh-hakka Ewell Expires January 6, 2006 [Page 104] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Hakka Added: 1999-12-18 %% Type: grandfathered Tag: zh-min Description: Min, Fuzhou, Hokkien, Amoy, or Taiwanese Added: 1999-12-18 %% Type: grandfathered Tag: zh-min-nan Description: Minnan, Hokkien, Amoy, Taiwanese, Southern Min, Southern Fujian, Hoklo, Southern Fukien, Ho-lo Added: 2001-03-26 %% Type: grandfathered Tag: zh-wuu Description: Shanghaiese or Wu Added: 1999-12-18 %% Type: grandfathered Tag: zh-xiang Description: Xiang or Hunanese Added: 1999-12-18 %% Type: grandfathered Tag: zh-yue Description: Cantonese Added: 1999-12-18 %% Type: redundant Tag: az-Arab Description: Azerbaijani in Arabic script Added: 2003-05-30 %% Type: redundant Tag: az-Cyrl Description: Azerbaijani in Cyrillic script Added: 2003-05-30 %% Type: redundant Tag: az-Latn Description: Azerbaijani in Latin script Added: 2003-05-30 %% Type: redundant Tag: be-Latn Description: Belarusian in Latin script Added: 2005-01-06 Ewell Expires January 6, 2006 [Page 105] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: redundant Tag: bs-Cyrl Description: Bosnian in Cyrillic script Added: 2005-02-17 %% Type: redundant Tag: bs-Latn Description: Bosnian in Latin script Added: 2005-02-17 %% Type: redundant Tag: de-1901 Description: German, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-1996 Description: German, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: de-AT-1901 Description: German, Austrian variant, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-AT-1996 Description: German, Austrian variant, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: de-CH-1901 Description: German, Swiss variant, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-CH-1996 Description: German, Swiss variant, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: de-DE-1901 Description: German, German variant, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-DE-1996 Ewell Expires January 6, 2006 [Page 106] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: German, German variant, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: iu-Cans Description: Inuktitut in Canadian Aboriginal Syllabic script Added: 2005-02-17 %% Type: redundant Tag: iu-Latn Description: Inuktitut in Latin script Added: 2005-02-17 %% Type: redundant Tag: mn-Cyrl Description: Mongolian in Cyrillic script Added: 2005-02-17 %% Type: redundant Tag: mn-Mong Description: Mongolian in Mongolian script Added: 2005-02-17 %% Type: redundant Tag: sgn-BR Description: Brazilian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-CO Description: Colombian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-DE Description: German Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-DK Description: Danish Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-ES Description: Spanish Sign Language Added: 2001-11-11 %% Ewell Expires January 6, 2006 [Page 107] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: redundant Tag: sgn-FR Description: French Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-GB Description: British Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-GR Description: Greek Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-IE Description: Irish Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-IT Description: Italian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-JP Description: Japanese Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-MX Description: Mexican Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-NI Description: Nicaraguan Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-NL Description: Dutch Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-NO Description: Norwegian Sign Language Ewell Expires January 6, 2006 [Page 108] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2001-11-11 %% Type: redundant Tag: sgn-PT Description: Portuguese Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-SE Description: Swedish Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-US Description: American Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-ZA Description: South African Sign Language Added: 2001-11-11 %% Type: redundant Tag: sl-nedis Description: Natisone dialect, Nadiza dialect Added: 2004-06-01 %% Type: redundant Tag: sl-rozaj Description: Resian, Resianic, Rezijan Added: 2003-10-09 %% Type: redundant Tag: sr-Cyrl Description: Serbian in Cyrillic script Added: 2003-05-30 %% Type: redundant Tag: sr-Latn Description: Serbian in Latin script Added: 2003-05-30 %% Type: redundant Tag: tg-Arab Description: Tajik in Arabic script Added: 2005-02-17 %% Type: redundant Ewell Expires January 6, 2006 [Page 109] =0C Internet-Draft Initial Language Subtag Registry July 2005 Tag: tg-Cyrl Description: Tajik in Cyrillic script Added: 2005-02-17 %% Type: redundant Tag: uz-Cyrl Description: Uzbek in Cyrillic script Added: 2003-05-30 %% Type: redundant Tag: uz-Latn Description: Uzbek in Latin script Added: 2003-05-30 %% Type: redundant Tag: yi-latn Description: Yiddish, in Latin script Added: 2003-01-07 %% Type: redundant Tag: zh-Hans Description: simplified Chinese Added: 2003-05-30 %% Type: redundant Tag: zh-Hans-CN Description: PRC Mainland Chinese in simplified script Added: 2005-04-13 %% Type: redundant Tag: zh-Hans-HK Description: Hong Kong Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hans-MO Description: Macao Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hans-SG Description: Singapore Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hans-TW Description: Taiwan Chinese in simplified script Added: 2005-04-11 Ewell Expires January 6, 2006 [Page 110] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: redundant Tag: zh-Hant Description: traditional Chinese Added: 2003-05-30 %% Type: redundant Tag: zh-Hant-CN Description: PRC Mainland Chinese in traditional script Added: 2005-04-13 %% Type: redundant Tag: zh-Hant-HK Description: Hong Kong Chinese in traditional script Added: 2005-04-11 %% Type: redundant Tag: zh-Hant-MO Description: Macao Chinese in traditional script Added: 2005-04-11 %% Type: redundant Tag: zh-Hant-SG Description: Singapore Chinese in traditional script Added: 2005-04-11 %% Type: redundant Tag: zh-Hant-TW Description: Taiwan Chinese in traditional script Added: 2005-04-11 Ewell Expires January 6, 2006 [Page 111] =0C Internet-Draft Initial Language Subtag Registry July 2005 4. Omitted Code Elements The following code elements from [UN-M.49] were not assigned as subtags in the initial Language Subtag Registry, but are valid candidates for registration as region subtags, using the process in [I-D.ietf-ltru-registry]: 200 Czechoslovakia 830 Channel Islands 831 Guernsey 832 Jersey 833 Isle of Man Ewell Expires January 6, 2006 [Page 112] =0C Internet-Draft Initial Language Subtag Registry July 2005 5. Security Considerations This document specifies the initial contents to be used by IANA in populating the Language Subtag Registry. For security considerations relevant to that registry and the use of language tags, see [I-D.ietf-ltru-registry]. Ewell Expires January 6, 2006 [Page 113] =0C Internet-Draft Initial Language Subtag Registry July 2005 6. IANA Considerations This document provides the initial content for the Language Subtag Registry to be maintained by IANA. For details on the procedures for the format and ongoing maintenance of this registry, see [I-D.ietf- ltru-registry]. Ewell Expires January 6, 2006 [Page 114] =0C Internet-Draft Initial Language Subtag Registry July 2005 7. References 7.1 Normative References [I-D.ietf-ltru-registry] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", June 2005. 7.2 Informative References [ISO-15924] ISO TC46/WG3, "ISO 15924:2003 (E/F) - Codes for the representation of names of scripts", January 2004. [ISO-3166-1] International Organization for Standardization, "ISO 3166- 1:1988 - Codes for the representation of names of countries, 3rd edition", August 1988. [ISO-639-1] International Organization for Standardization, "ISO 639- 1:2002 - Codes for the representation of names of languages - Part 1: Alpha-2 code", 2002. [ISO-639-2] International Organization for Standardization, "ISO 639- 2:1998 - Codes for the representation of names of languages - Part 2: Alpha-3 code - edition 1", August 1988. [UN-M.49] United Nations Statistical Division, "Standard Country or Area Codes for Statistical Use", June 1999. [record-jar] Raymond, E., "The Art of Unix Programming", 2003. Author's Address Doug Ewell (editor) Email: dewell@adelphia.net URI: http://users.adelphia.net/~dewell Ewell Expires January 6, 2006 [Page 115] =0C Internet-Draft Initial Language Subtag Registry July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ewell Expires January 6, 2006 [Page 116] =0C ------=_NextPart_000_004A_01C58202.B53C4AA0 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_000_004A_01C58202.B53C4AA0-- From ltru-bounces@lists.ietf.org Wed Jul 06 12:34:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqCqb-0002JG-2o; Wed, 06 Jul 2005 12:34:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqCqF-0001ng-9g for ltru@megatron.ietf.org; Wed, 06 Jul 2005 12:33:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18405 for ; Wed, 6 Jul 2005 12:33: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 1DqDAf-0007U4-FJ for ltru@ietf.org; Wed, 06 Jul 2005 12:54: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 Jul 2005 09:28:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Jul 2005 09:28:30 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C014AE7@irvmbxw01.quest.com> Thread-Topic: draft-phillips-langtags... (Resend) Thread-Index: AcWBqqylO7UeGN05QwWtLK3u5U1n6gAAGT+wACb7MAA= From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 06 Jul 2005 16:28:30.0931 (UTC) FILETIME=[BF09DA30:01C58247] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Ltru] FW: draft-phillips-langtags... (Resend) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0839192618==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0839192618== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 U2luY2UgRHlsYW4gaGFzIGZvcndhcmRlZCBoaXMgbWVzc2FnZSB0byB0aGUgbGlzdCwgSSB0aG91 Z2h0IGl0IGFwcHJvcHJpYXRlIHRoYXQgSSBmb3J3YXJkIG15IHJlc3BvbnNlIGFzIHdlbGwgKHJh dGhlciB0aGFuIHJlY2FzdCBpdCkuIEkgc3VwcG9ydCB0aGUgaWRlYSBvZiBhbiBleHRlbnNpb24g b2YgZXh0ZW5zaW9ucyBiZWluZyB3cml0dGVuIGluIHRoaXMgV0cgZm9sbG93aW5nIGFkb3B0aW9u IG9mIGRyYWZ0LXJlZ2lzdHJ5IGFuZCBvdXIgd29yayBvbiBkcmFmdC1tYXRjaGluZy4NCg0KQmVz dCBSZWdhcmRzLA0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRp b24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXph dGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEg ZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogQWRkaXNvbiBQaGlsbGlwcw0KPiBTZW50OiBkZW4gNSBqdWxpIDIw MDUgMTU6MDYNCj4gVG86ICdEci4gRHlsYW4gTi4gUGllcmNlJw0KPiBDYzogJ01hcmsgRGF2aXMn DQo+IFN1YmplY3Q6IFJFOiBkcmFmdC1waGlsbGlwcy1sYW5ndGFncy4uLiAoUmVzZW5kKQ0KPiAN Cj4gRGVhciBEci4gUGllcmNlLA0KPiANCj4gSSB3aWxsIGZpcnN0IG5vdGUgdGhhdCB0aGUgSUVU RiBpcyBhIHZvbHVudGVlciBvcmdhbml6YXRpb246IHdvcmtpbmcNCj4gZ3JvdXBzIGFyZSBzZWxm LWFwcG9pbnRpbmcuIEFsbCB5b3UgaGF2ZSB0byBkbyBpcyBqb2luIHRoZSBtYWlsaW5nIGxpc3Qu DQo+IE1vcmUgcGVvcGxlIHdlaWdoaW5nIGluIG9uIHRoZSAic3VwcG9ydGluZyIgc2lkZSBvZiB0 aGUgZHJhZnQgd2lsbCBoZWxwIHVzDQo+IGdldCB0aHJvdWdoIG91ciBMYXN0IENhbGxzLg0KPiAN Cj4gTWFyayBhbmQgSSBoYXZlIGxvbmcgYmVlbiBhd2FyZSBvZiB0aGUgbGltaXRhdGlvbiBvZiBz aW5nbGV0b24gbGV0dGVycy4NCj4gRXNzZW50aWFsbHkgdGhlcmUgYXJlIG9ubHkgMjUgYXZhaWxh YmxlIHBvc2l0aW9ucyAoMzUgaWYgd2UgYWxsb3cgZGlnaXRzKSwNCj4gd2hpY2ggaXNuJ3QgdmVy eSBtYW55IGFzIHlvdSBub3RlLiBUaGUgcXVlc3Rpb24gaGFzIGFsd2F5cyBiZWVuIHdoZXRoZXIN Cj4gdGhlcmUgYXJlIGEgbGFyZ2Ugb3Igc21hbGwgbnVtYmVyIG9mIHByYWN0aWNhbCBleHRlbnNp b25zIHRvIGxhbmd1YWdlIHRhZ3MNCj4gbHVya2luZyBhYm91dC4gQXMgbG9uZyBhcyB3ZSBhcmUg dGFsa2luZyBhYm91dCBpbmRpdmlkdWFscyBvciBzbWFsbA0KPiBjb21tdW5pdGllcyAoSSBsaWtl IHRvIGltYWdpbmUgcHJvZmVzc29ycyBvZiBsaW5ndWlzdGljcyB0cmFkaW5nIGVzb3RlcmljDQo+ IHBhcGVycykgdGhlIHgtIHRhZ3Mgd29yayBmaW5lLiBPcmdhbml6YXRpb25zIHdpbGwsIGFzIHlv dSBub3RlLCB3YW50IGFuDQo+IGV4dGVuc2lvbiBvZiB0aGVpciBvd24uDQo+IA0KPiBJbmNvcnBv cmF0aW5nIHN1Y2ggYSBwdWJsaWMgZXh0ZW5zaW9uLW9mLWV4dGVuc2lvbnMgaW50byB0aGUgcmVn aXN0cnkNCj4gZHJhZnQgd291bGQgYmUgb25lIG1lY2hhbmlzbSBmb3IgYWNoaWV2aW5nIHlvdXIg ZGVzaWduIGdvYWwuIEFub3RoZXIgd291bGQNCj4gYmUgdG8gd2FpdCBmb3IgdGhlIGRyYWZ0IHRv IGdvIHRocm91Z2ggYW5kIHRoZW4gd3JpdGUgYW4gSW50ZXJuZXQtRHJhZnQNCj4gcHJvcG9zaW5n IGl0IGFzIGFuIGV4dGVuc2lvbi4gVGhpcyBtaWdodCBiZSBhbiBhcHByb3ByaWF0ZSB0YXNrIGZv ciB0aGUNCj4gTFRSVSB3b3JraW5nIGdyb3VwLg0KPiANCj4gRm9yIGV4YW1wbGUsIElBTkEgY291 bGQgcmVzZXJ2ZSB0aGUgbGV0dGVyICJpLSIgZm9yIElBTkEgcmVnaXN0ZXJlZA0KPiBleHRlbnNp b24gc2NoZW1lcyBiYXNlZCBvbiB0aGUgZGVzaWduIHlvdSBwcm9wb3NlLiBUaGVuIHRoZXJlIHdv dWxkIHRoZW4NCj4gYmUgYSBwdWJsaWMgcmVnaXN0cnkgdG8gZW50ZXIgdGhlIGV4dGVuc2lvbnMg aW50by4NCj4gDQo+IEluIGFueSBjYXNlLCBjaGVjayBvdXQgdGhlIGxpbmtzIG9uIG15IHBlcnNv bmFsIHdlYiBzaXRlIGFuZCBjb25zaWRlcg0KPiBqb2luaW5nIHRoZSBMVFJVIHdvcmtpbmcgZ3Jv dXAuDQo+IA0KPiBCZXN0IFJlZ2FyZHMsDQo+IA0KPiBBZGRpc29uDQo+IA0KPiBBZGRpc29uIFAu IFBoaWxsaXBzDQo+IEdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KPiBD aGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KPiANCj4g SW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCj4gSXQgaXMgYW4gYXJjaGl0 ZWN0dXJlLg0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IERy LiBEeWxhbiBOLiBQaWVyY2UgW21haWx0bzpkeWxhbnBpZXJjZUBtZWdhcmVkLm5ldC5teF0NCj4g PiBTZW50OiBkZW4gNSBqdWxpIDIwMDUgMTQ6NDINCj4gPiBUbzogQWRkaXNvbiBQaGlsbGlwcw0K PiA+IFN1YmplY3Q6IFJlOiBkcmFmdC1waGlsbGlwcy1sYW5ndGFncy4uLiAoUmVzZW5kKQ0KPiA+ DQpPcmlnaW5hbCBtZXNzYWdlIGRlbGV0ZWQuLi4NCg0K --===============0839192618== 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 --===============0839192618==-- From ltru-bounces@lists.ietf.org Wed Jul 06 12:49:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqD5Q-0007p6-Rj; Wed, 06 Jul 2005 12: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 1DqD5O-0007lC-Kq for ltru@megatron.ietf.org; Wed, 06 Jul 2005 12:49:22 -0400 Received: from unix.megared.net.mx (megamail.megared.com.mx [200.52.207.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20766 for ; Wed, 6 Jul 2005 12:49:19 -0400 (EDT) Received: from [192.168.2.170] ([10.60.88.84]) by unix.megared.net.mx (8.11.7/8.11.7) with ESMTP id j66Gmnn68457 for ; Wed, 6 Jul 2005 11:48:50 -0500 (CDT) Message-ID: <42CC0B62.9030802@megared.net.mx> Date: Wed, 06 Jul 2005 11:48:34 -0500 From: "Dylan N. Pierce" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ltru@ietf.org Subject: Re: [Ltru] Private Use Tags References: <42CB03D4.20801@megared.net.mx> <6.2.1.2.2.20050706001224.05117b90@mail.afrac.org> In-Reply-To: <6.2.1.2.2.20050706001224.05117b90@mail.afrac.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 response to jfc (forgive me if I don't yet understand how to ensure that my e-mail appears in the thread below the appropriate post; I freely admit this is my first time participating in a procedure such as this). Whenever I read a standard, for better or for worse, the question I am asking myself isn't, "What does this mean?" or "What purpose does this serve?" I am always asking myself, "How do I write a program that does this?" This is why RFC 3066, for all that it's a BCP, simply is inadequate; I am interested enough in this working group to come here and express a solid support for the current direction because having a language tag which is parsable according to constructable rules greatly reduces the amount of work any programmer has to do when developing for compliance. As such, I read your first point, regarding characterizing the use of a document, and it tells me something interesting about myself. The fact is, for all its irony, I'm not typically even remotely interested in how a document is used; I tend to focus on how a document is /filed/ by the people who use it. If a client tells me, "I want a list of all documents sorted alphabetically by the third sentence of the second chapter," I might ask, "Why? Are you sure?" but if the client insists, I'll dutifully begin writing the appropriate algorithsm. I admit that issues of defining "What is a language?" and its philosophical correlates are perhaps of coffee-table interest to me, but not of professional interest as a programmer. Instead I merely want to know how I serve to any random end-user the appropriate document following whatever language /he/ thinks he's speaking. This means I need my language tags to be /descriptive,/ not proscriptive, and they have to be extensible in a logical way. For better or for worse, if we are describing human languages, we must deal with the reality that human beings /do/ invent languages. It /is/ possible to find websites written in Klingon and poetry written in "Yodish." A bit disconcerting, to be sure, but possible. Certainly, if someone in my living room was trying to speak to me in Klingon, I'd probably request that he get a life, but /personally,/ I can do that. Professionally I can't; I can't use the fact that a man who speaks Esperanto, an equally artificial language, is more likely to have a girlfriend than a man who speaks Klingon as a justification for design limitations. Again, human beings /do/ invent languages and any tagging standard which does not account for this reality is inadequate for the task of classifying human languages. Effectively, I look at the language tag in this fashion: if, for any two random given people, I must use two different syntaxes to say the same thing, then I need a different tag. en-US and en-GB are different not just because the British like throwing in superfluous u's, but also because the word "fanny" gets me in more trouble in one place than in the other. Same with the word "mantequilla" en es-MX versus es-AR. Anyone interested in providing global content must be able to navigate these differences /and/ similar unpredictable differences which arise in the future. What happens, for example, when significant language-use differences are based on social class in the exact same region in the exact same tongue? No existing tag accounts for this; can we be sure that 35 possibilities for extension protect us against future social and creative inventions? Extensibility and modularity must be incorporated into the system from its inception or the system will fail. Human creativity and pop culture move altogether faster than specification revision committees. Ultimately, these tags are not, and /cannot/ be, proscriptive for how people are /allowed/ to classify languages; you can't program humans like a computer. Instead, they need to be descriptive of how human beings /use/ language--"use" it here in both senses, of how they actually speak, write or signal it, and also in how they already classify it for their own purposes of transmission, and that descriptiveness must share the same capacity for growth as the objects it describes. In other words, the tags used to describe languages must themselves be like languages: if the language changes from region to region, so must the tags. If languages divide or combine over time, so must the tags. And if languages can spring wholesale from the minds of hack science-fiction screenwriters, so must the tags. Further, if languages can be analyzed for factors important to one organization but irrelevant to another, so must the tags. The reading-level example, for instance, is intrinsically part of how language is used within a culture; the very educational institutions teaching the language divide material in this fashion. The regional press example points to how material is requested and provided, still however analyzed based on sheer linguistic--word choice and level of abstractness--factors. And since it would be daunting for a registration body to make any attempt at trying to track and describe the myriad of human possibilities for interpreting a language, best we put that charge directly in the hands of the people who do it for a living. Certainly this means that corporations will also use their namespace for less germaine reasons. And fortunately, parsing agents can ignore their tags and still remain completely in compliance: a small price to pay for effectively making the entire world a de facto but organized registration authority for how language is used worldwide. I've been informed both here and privately that perhaps a more appropriate approach would be to wait until this document becomes a standard and then propose organizational namespace as a new Internet Draft. Certainly, you guys know better than I do what we're up against and I'll defer to your best judgment. But the entire reason I so strongly support this project is because we undeniably /need/ a parsable internationalization architecture (as a programmer, /I/ need it, and I have yet to speak to a colleage who accuses RFC 3066 of being sufficient) and it needs to speak to all the ways in which languages are used, distributed, selected, and even (perhaps I'm making enemies here) invented. Extensibility can be anything from a lifesaver to a mere buzzword. For any descriptor to be extensible in a way which has value, it must be extensible in exactly the same ways in which the object it describes is extensible. If it is not, time and human creativity will obsolete it. Sincerely, Dylan N. Pierce _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 06 13:20:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqDZM-0006E5-Lk; Wed, 06 Jul 2005 13:20:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqA1p-0006Gr-MR for ltru@megatron.ietf.org; Wed, 06 Jul 2005 09:33:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21128 for ; Wed, 6 Jul 2005 09:32:11 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqAE9-0004dH-Io for ltru@ietf.org; Wed, 06 Jul 2005 09:46:14 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dq9mz-0002KA-1D for ltru@ietf.org; Wed, 06 Jul 2005 06:18:09 -0700 Message-Id: <6.2.1.2.2.20050706151619.0462a8e0@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 06 Jul 2005 15:17:01 +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.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 X-Mailman-Approved-At: Wed, 06 Jul 2005 13:20:19 -0400 Cc: Subject: [Ltru] does the Draft gives all the guidelines required by the 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 This WG has to reorganise a IANA registry (since for the time being the RFC 3066 IANA Registry is considered). Here is the most recent registration in that Registry. I will try to underline some of the complexity and confusion it contains by lack of RFC guidance, so everyone may check that the current Draft addresses these lacks and provides the guidelines and forms necessary to the language tags reviewers . This quick review will probably be useful for those on this list who work on an ISO 11179 metamodel for languages. >LANGUAGE TAG REGISTRATION FORM >Name of requester : Karen Broome >E-mail address of requester: karen_broome@spe.sony.com This information is of no interest to the users. It gives Karen Broome and possibly Sony a stewardship on the American Spanish some could seriously object. From this who is the es-419 steward in 2105? >Tag to be registered : es-419 >English name of language : Latin American Spanish Do we have a definition of language? Can the concept of "Latin American Spanish" be accepted as a language or as a metalanguage or as a variant or a language family, etc. according to this definition? Obviously references to ISO 639-4 will help but are not available yet. >Native name of language (transcribed into ASCII): espanol de America >Latina, espanol latinoamericano This information misses the French name of the language. >Reference to published description of the language (book or article): > >Lipski, John M. 1994. Latin American Spanish. Addison Wesley >Publishing Company. >Martin, Patrice. 2005. "The Quest for El Dorado: A Single Spanish for >All." Multilingual Computing & Technology. Vol. 12, No. 6 This kind of quote are of interest to some, but may also be contentious. I am not sure there are guidlines enough to avoid the contention. I also wander why such an information would be provided for this langtag while it is not for other. There should be only one metamodel for a concept in order to avoid conflicts. This part is alse a partial attempt to transform the es-419 concept into a value (registration by reference, instead of registration by declaration). I am not sure that this value is explicit enough and can not be considered as a registration by real documentation . It can be explicit for a linguist. I am not sure it is explicit for all the users. Have some rules been given that a computer or a non linguist could use to distinguish es-419 from es? >Any other relevant information : Same remark as above. >It is a common business practice to localize content into a neutral >version of Latin American Spanish to serve all or most Spanish-speaking >regions in Latin America. This code is intended to identify this neutral >variant of Latin American Spanish and distinguish it from Castilian found >in Europe. This is a standadisation text. "all or" does not fit (it seems however in line with the lack of clarity of RFC 3066 which the advantage of RFC 3066 as it can accept much). This rises the question of the American Spanish: what are the differences. What is the New Mexico Spanish? >This tag is intended for use on content that has been tailored for Spanish >audiences throughout Latin America. "use on content": I do not understand the full meaning. I expected identify, describe ...? "audience": is this a generic enough name? Is the Registry to consider the mode or the language? The use of "audience" seems to imply that the tag is to characterise "out" streams (IETF takes care of network protocols). > It is not a collection for all Latin American Spanish varieties; it > merely indicates that the author made choices in vocabulary, grammar, > spelling, etc. that would make the content reasonably acceptable to speakers Here we have a confusion. The text both speaks of author (source of content) and of speakers (other sources of content). I suppose that he wants to say "readers". This kind of confusion would be removed if instead of having to comment the tag, the examiner was provided a form giving him strict guidlines (identical for every tag). > of most or all Latin American Spanish varieties. (This tag does not > imply any further details regarding what those choices may have been, however.) This seems odd in a standardisation comment as it says that two people may legitimately have two orthogonal understandings of es-419. >This tag is intended primarily for cataloguing of localized content and >resources, rather than for specifying language preference on retrieval. This insist on the "out" or "sending" definition of a langtag. I have no problem with that, except that through "Latin America" the specification is through an "audience", i.e. through the expectation of a population? Or does that means that the langtag is to identify the way an authors responds to the expectations of a local population expressed in its own way to speak. I have no objection to that (it corresponds to a relational definition), but the definition should be explicit somewhere and scalable. Scalable means that the definition should be generalised and its technical implications (relation modes, non human interlocutors, etc.) should be addressed, so the examiner and the user of the registration form has a protocol defnition/documentation tool; >Ideally, a system should be able to deliver content labelled with this tag >in response to requests for any specific Latin American Spanish variety, >including but not limited to the following: the "not limited" seems to create a confusion with the "419" from the UN list. Unless it is a way to characterise the speaking audiences considering themselves attached to an es-419 community. I have no problem with that since it would be an IETF consistent definition attaching a language to an indentified network. But the notion should be generalised and its implications measured since they are certainly one of the basic elements of CRCs (Context and Reference Centres). But then we fall into the alanysis of Referents and Context issues which are the keys to the "not limited" vs. not "universal". In Internet architecture this means lingual classes. >es-AR, es-BO, es-CL, es-CO, es-CR, es-CU, es-DO, es-EC, es-FK, es-GT, >es-HN, es-MX, es-NI, es-PA, es-PE, es-PR, es-PY, es-SV, es-UY, es-VE. > >Of course, systems can also be implemented to offer this tag as a >user-preference option, Good. So we also have the langtag as a "in" descriptor. But here we have a partial decription: we have user preference but ignore if we can use it as a user capacity description. Can we use the langtag for language negociation and relation tuning towards best person to person interintelligibility. Also we have no hint about the kind of relation: is that a one to one, one to many, many to many? Is the negociation between pairs (senders or receivers) also possible in using the tag? > and a server should deliver content labelled with this tag when > requested for the same. Why? Does the Draft mention that SHOULD. What is the fall back possibility if it cannot. Up to now we are in a fluid human to human environment (also imposed by the current Draft). All the sudden we are on a machine to human (web site), machine to machine (web service), machine to underfined (mail, broadcast) environement. >On the other hand, it is not valid to assume that a request for "es-419" >can be serviced by returning content labelled as es-AR, or es-BO, es-CL, etc. Accepted. But is this the proper place to see this explicited? Should it not be part of warnings printed in the Draft defined form. Which other warnings should be provided to the user? >It would be appropriate to deliver content labelled with this tag in >response to the more generic request, "es" (cf. section 2.5 of RFC 3066). The wording seems extermely confusing. Why to use a specific es-419 if the wording is appropriate? At least priorities should be given and described: es-419 before es seems OK, but is as-AR to be delivered before or after es? I do not think these are minor questions. I am sure they belong to the Charter. I am not sure they belong to the Draft. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 06 14:41:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqEqE-0000hK-PD; Wed, 06 Jul 2005 14:41:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqEqC-0000gL-PC for ltru@megatron.ietf.org; Wed, 06 Jul 2005 14:41:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03212 for ; Wed, 6 Jul 2005 14:41:47 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqFHE-0004qF-OZ for ltru@ietf.org; Wed, 06 Jul 2005 15:09:45 -0400 Received: from h-64-105-136-184.snvacaid.dynamic.covad.net ([64.105.136.184] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqEq2-0001IG-00 for ltru@ietf.org; Wed, 06 Jul 2005 14:41:38 -0400 Message-ID: <00bc01c5825a$eadf56e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <42CB03D4.20801@megared.net.mx><6.2.1.2.2.20050706001224.05117b90@mail.afrac.org> <42CC0B62.9030802@megared.net.mx> Subject: Re: [Ltru] Private Use Tags Date: Wed, 6 Jul 2005 11:45:43 -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: 7e439b86d3292ef5adf93b694a43a576 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 Dylan - If I might summarize your message, I think you have four concerns: 1) are tags descriptive or prescriptive? 2) how well does the specification cope with new languages? 3) support for tagging other linguistics aspects of a document 4) is the space defined by the extension mechanism sufficiently large? As a technical contributor, I think your first concern can be definitively answered: "Language tags are, from a linguistic perspective, descriptive." Would it be helpful to include this sentence in the i-d? The only person who has argued otherwise, as far as I know, is Mr. Morfin. On your second concern, the support for novel or artificial languages, the draft is quite clear that if the language is used by humans for communication with humans, it is within scope. (Section 2) Since, as you affirm, Klingon is in use for human-to-human communication, it has been registered. I think this is a pretty convincing demonstration that the registry can cope with novel languages. Regarding your third concern, tagging other linguistic aspects of a document, as "social class" or "preferred spelling dictionary", I think you'd find some lack of agreement on whether these belong in a language tag or whether they should be regarded as distinct attributes. The working group does not need to resolve this question to meet the terms of its charter. My personal view is that this is a good thing; the universe of all possible attributes of linguistic interest is far to large to permit completion of our work in a reasonable time. I think using a language tag to encode all the linguistic attributes of a document makes as much sense as trying to boil the ocean. There's a big difference between identifying the language of a document and cataloging all its linguistic attributes. On your fourth concern, whether the space defined by the syntax of the extension mechanisms is sufficiently large, depends in large part on the extent to which you try to use language tags to address your third concern. If the only tool you have is a hammer, then every problem is a nail. :-) Randy ----- Original Message ----- > From: "Dylan N. Pierce" > To: > Sent: Wednesday, July 06, 2005 9:48 AM > Subject: Re: [Ltru] Private Use Tags > > In response to jfc (forgive me if I don't yet understand how to ensure > that my e-mail appears in the thread below the appropriate post; I > freely admit this is my first time participating in a procedure such as > this). > > Whenever I read a standard, for better or for worse, the question I am > asking myself isn't, "What does this mean?" or "What purpose does this > serve?" I am always asking myself, "How do I write a program that does > this?" This is why RFC 3066, for all that it's a BCP, simply is > inadequate; I am interested enough in this working group to come here > and express a solid support for the current direction because having a > language tag which is parsable according to constructable rules greatly > reduces the amount of work any programmer has to do when developing for > compliance. > > As such, I read your first point, regarding characterizing the use of a > document, and it tells me something interesting about myself. The fact > is, for all its irony, I'm not typically even remotely interested in how > a document is used; I tend to focus on how a document is /filed/ by the > people who use it. If a client tells me, "I want a list of all documents > sorted alphabetically by the third sentence of the second chapter," I > might ask, "Why? Are you sure?" but if the client insists, I'll > dutifully begin writing the appropriate algorithsm. > > I admit that issues of defining "What is a language?" and its > philosophical correlates are perhaps of coffee-table interest to me, but > not of professional interest as a programmer. Instead I merely want to > know how I serve to any random end-user the appropriate document > following whatever language /he/ thinks he's speaking. This means I need > my language tags to be /descriptive,/ not proscriptive, and they have to > be extensible in a logical way. > > For better or for worse, if we are describing human languages, we must > deal with the reality that human beings /do/ invent languages. It /is/ > possible to find websites written in Klingon and poetry written in > "Yodish." A bit disconcerting, to be sure, but possible. Certainly, if > someone in my living room was trying to speak to me in Klingon, I'd > probably request that he get a life, but /personally,/ I can do that. > Professionally I can't; I can't use the fact that a man who speaks > Esperanto, an equally artificial language, is more likely to have a > girlfriend than a man who speaks Klingon as a justification for design > limitations. Again, human beings /do/ invent languages and any tagging > standard which does not account for this reality is inadequate for the > task of classifying human languages. > > Effectively, I look at the language tag in this fashion: if, for any two > random given people, I must use two different syntaxes to say the same > thing, then I need a different tag. en-US and en-GB are different not > just because the British like throwing in superfluous u's, but also > because the word "fanny" gets me in more trouble in one place than in > the other. Same with the word "mantequilla" en es-MX versus es-AR. > Anyone interested in providing global content must be able to navigate > these differences /and/ similar unpredictable differences which arise in > the future. What happens, for example, when significant language-use > differences are based on social class in the exact same region in the > exact same tongue? No existing tag accounts for this; can we be sure > that 35 possibilities for extension protect us against future social and > creative inventions? Extensibility and modularity must be incorporated > into the system from its inception or the system will fail. Human > creativity and pop culture move altogether faster than specification > revision committees. > > Ultimately, these tags are not, and /cannot/ be, proscriptive for how > people are /allowed/ to classify languages; you can't program humans > like a computer. Instead, they need to be descriptive of how human > beings /use/ language--"use" it here in both senses, of how they > actually speak, write or signal it, and also in how they already > classify it for their own purposes of transmission, and that > descriptiveness must share the same capacity for growth as the objects > it describes. In other words, the tags used to describe languages must > themselves be like languages: if the language changes from region to > region, so must the tags. If languages divide or combine over time, so > must the tags. And if languages can spring wholesale from the minds of > hack science-fiction screenwriters, so must the tags. > > Further, if languages can be analyzed for factors important to one > organization but irrelevant to another, so must the tags. The > reading-level example, for instance, is intrinsically part of how > language is used within a culture; the very educational institutions > teaching the language divide material in this fashion. The regional > press example points to how material is requested and provided, still > however analyzed based on sheer linguistic--word choice and level of > abstractness--factors. And since it would be daunting for a registration > body to make any attempt at trying to track and describe the myriad of > human possibilities for interpreting a language, best we put that charge > directly in the hands of the people who do it for a living. Certainly > this means that corporations will also use their namespace for less > germaine reasons. And fortunately, parsing agents can ignore their tags > and still remain completely in compliance: a small price to pay for > effectively making the entire world a de facto but organized > registration authority for how language is used worldwide. > > I've been informed both here and privately that perhaps a more > appropriate approach would be to wait until this document becomes a > standard and then propose organizational namespace as a new Internet > Draft. Certainly, you guys know better than I do what we're up against > and I'll defer to your best judgment. But the entire reason I so > strongly support this project is because we undeniably /need/ a parsable > internationalization architecture (as a programmer, /I/ need it, and I > have yet to speak to a colleage who accuses RFC 3066 of being > sufficient) and it needs to speak to all the ways in which languages are > used, distributed, selected, and even (perhaps I'm making enemies here) > invented. > > Extensibility can be anything from a lifesaver to a mere buzzword. For > any descriptor to be extensible in a way which has value, it must be > extensible in exactly the same ways in which the object it describes is > extensible. If it is not, time and human creativity will obsolete it. > > Sincerely, > Dylan N. Pierce > > _______________________________________________ > 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 Jul 06 15:04:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqFCb-0003fz-UV; Wed, 06 Jul 2005 15:04:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqFCZ-0003fQ-Un for ltru@megatron.ietf.org; Wed, 06 Jul 2005 15:04:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05708 for ; Wed, 6 Jul 2005 15:04: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.43) id 1DqFdb-0007L5-8g for ltru@ietf.org; Wed, 06 Jul 2005 15:32:52 -0400 Received: from eupig1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 6 Jul 2005 19:04:25 +0000 Message-ID: Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IJ70097RZNDMK@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 06 Jul 2005 19:04:25 +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 Jul 2005 19:04:24 +0000 Date: Wed, 06 Jul 2005 20:04:24 +0100 From: Misha Wolf Subject: RE: [Ltru] Private Use Tags To: ltru@ietf.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Private Use Tags thread-index: AcWCWozKVtYRPl+zRe+kUTiuFezh4wAAlI9w Content-Class: urn:content-classes:message X-OriginalArrivalTime: 06 Jul 2005 19:04:24.0937 (UTC) FILETIME=[8675E590:01C5825D] X-Spam-Score: 0.8 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Dylan, As you mentioned the ALA and educational levels in one of your=20 postings, I will briefly note that Dublin Core [1] uses distinct=20 elements for: - language: A language of the intellectual content of the=20 resource. - educationLevel: A general statement describing the education=20 or training context. Alternatively, a more specific statement=20 of the location of the audience in terms of its progression=20 through an education or training context. educationLevel is defined to be a refinement of ... - audience: A class of entity for whom the resource is intended=20 or useful. I think they got it right :-) [1] http://www.dublincore.org/ Regards, 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 Wed Jul 06 15:33:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqFeP-0003kQ-6h; Wed, 06 Jul 2005 15: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 1DqFeN-0003hJ-50 for ltru@megatron.ietf.org; Wed, 06 Jul 2005 15:33:39 -0400 Received: from unix.megared.net.mx (megamail.megared.com.mx [200.52.207.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09057 for ; Wed, 6 Jul 2005 15:33:37 -0400 (EDT) Received: from [192.168.2.170] ([10.60.88.84]) by unix.megared.net.mx (8.11.7/8.11.7) with ESMTP id j66JX6413649; Wed, 6 Jul 2005 14:33:06 -0500 (CDT) Message-ID: <42CC31E2.6010100@megared.net.mx> Date: Wed, 06 Jul 2005 14:32:50 -0500 From: "Dylan N. Pierce" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn , ltru@ietf.org Subject: Re: [Ltru] Private Use Tags References: <42CB03D4.20801@megared.net.mx><6.2.1.2.2.20050706001224.05117b90@mail.afrac.org> <42CC0B62.9030802@megared.net.mx> <00bc01c5825a$eadf56e0$7f1afea9@oemcomputer> In-Reply-To: <00bc01c5825a$eadf56e0$7f1afea9@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 Randy, Sounds pretty accurate to me. Remembering that my point of view is generally always tainted by use-case scenarios, you'll have to forgive my tendency to focus on an infinitude of "What if?" hypotheticals when everyone around me merely wants to ship a finished product; that happens at my home company, as well. Regarding point one, I imagine it's a case of being too close to the issue. Of /course/ we know they're descriptive. But these things are designed to be used by actual people, and people can be picky. I'm sure Mr. Morfin is not unique in that regard. If something as simple as specifying, "These tags are descriptive, not prescriptive, and do not represent a limiting factor in languages or variations an application may support," could head off a perceived slight by the unrepresented, that doesn't seem to be an excessively high cost. Regarding two, actually, I'm in complete agreement with you; I didn't mean my side trip down that road to be taken as a point of contention with the current draft. Rather, it was more a direct response to jfc's concerns about ever-spiraling artificial languages, to serve as a sort of affirmation that yes, the number of artificial languages will most likely continue to grow, and our job isn't to do anything about that other than design a mechanism which can describe it. I have no argument that the current mechanism seems to fulfill that need. The third point is the interesting one (and, as you noted, the fourth point merely follows from it). Perhaps my mistake was including examples; those are too easy to take as straw men. My position is most definitely /not/ that the language tags should be used to catalog other linguistic aspects of the document. Making the specification that precise would, in fact, be rather /against/ the direction I want to go; it would simply be eliminating more possibilities by defining canonical ones. My suggestion, instead, is an attempt to refine the private-use tag system to include organizational namespaces so that organizations /that would be using private tags anyway/ for whatever purposes they felt legitimate--perhaps including but certainly not limited to other linguistic features--can have an added guarantee that, when intercommunicating with other organizations who agree with their tags, their respective specialized parsing agents can definitively know that the particular private tag they are looking at is, in fact, the one of interest to them and not someone else's private tag that happens to share the same letters. Exactly /what/ this would be used for is, as you have rightly noted, quite beyond the scope of this project and would probably bore us all to death anyway (as if I'm not doing that already). So no, please don't misunderstand me; I'm not campaigning for a complete linguistic analysis in the tag. I'm campaigning for increased compatibility by having a clear, machine-readable way of informing those people who are already taking advantage of private-use tags that the particular private tag they are looking at is in fact the one they meant to look at. That kind of clarity and assurance, I believe, would benefit everyone. Sincerely, Dylan N. Pierce _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 06 16:34:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqGbX-0001wy-T3; Wed, 06 Jul 2005 16: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 1DqGbV-0001vU-8t for ltru@megatron.ietf.org; Wed, 06 Jul 2005 16:34:45 -0400 Received: from pop-altamira.atl.sa.earthlink.net (pop-altamira.atl.sa.earthlink.net [207.69.195.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23993 for ; Wed, 6 Jul 2005 16:34:43 -0400 (EDT) Received: from h-64-105-136-184.snvacaid.dynamic.covad.net ([64.105.136.184] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqGbT-000130-00 for ltru@lists.ietf.org; Wed, 06 Jul 2005 16:34:43 -0400 Message-ID: <001c01c5826a$b7d597e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <42CB03D4.20801@megared.net.mx><6.2.1.2.2.20050706001224.05117b90@mail.afrac.org> <42CC0B62.9030802@megared.net.mx> <00bc01c5825a$eadf56e0$7f1afea9@oemcomputer> <42CC31E2.6010100@megared.net.mx> Subject: Re: [Ltru] Private Use Tags Date: Wed, 6 Jul 2005 13:38: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 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 - (as a technical contributor) > From: "Dylan N. Pierce" > To: "Randy Presuhn" ; > Sent: Wednesday, July 06, 2005 12:32 PM > Subject: Re: [Ltru] Private Use Tags ... (much agreement elided) ... > The third point is the interesting one (and, as you noted, the fourth > point merely follows from it). Perhaps my mistake was including > examples; those are too easy to take as straw men. My position is most > definitely /not/ that the language tags should be used to catalog other > linguistic aspects of the document. Making the specification that > precise would, in fact, be rather /against/ the direction I want to go; > it would simply be eliminating more possibilities by defining canonical > ones. > > My suggestion, instead, is an attempt to refine the private-use tag > system to include organizational namespaces so that organizations /that > would be using private tags anyway/ for whatever purposes they felt > legitimate--perhaps including but certainly not limited to other > linguistic features--can have an added guarantee that, when > intercommunicating with other organizations who agree with their tags, > their respective specialized parsing agents can definitively know that > the particular private tag they are looking at is, in fact, the one of > interest to them and not someone else's private tag that happens to > share the same letters. Exactly /what/ this would be used for is, as you > have rightly noted, quite beyond the scope of this project and would > probably bore us all to death anyway (as if I'm not doing that already). > > So no, please don't misunderstand me; I'm not campaigning for a complete > linguistic analysis in the tag. I'm campaigning for increased > compatibility by having a clear, machine-readable way of informing those > people who are already taking advantage of private-use tags that the > particular private tag they are looking at is in fact the one they meant > to look at. That kind of clarity and assurance, I believe, would benefit > everyone. ... Thanks for the clarification. I think there's really a policy question underneath this: how strongly do we want to encourage the registration of subtags? If the point of having a registry is to provide open access to information that allows someone to figure out what a tag signifies, and to promote consistent tagging of data, motivated by a desire to promote interoperability, then I think it's important to emphasize the "last resort" nature of private-use tags. As you note, the need to structure a space of private use tags arises when there is a risk that they would "leak". I such a case, the use is no longer "private", and properly registered tags should be used instead. I think this is especially true if there is any reason anyone else would be interested in material in the language in question. An example of a mechanism that could provide extreme extensibility would be something like http://www.iana.org/assignments/enterprise-numbers. We certainly had plenty of experience with that in the IETF's Operations and Management area. Some of the problems with such a discipline (or any mechanism that encourages the use of (sub)tags which are not publicly registered) include: 1. there may be multiple ways to say the same thing (especially bad for matching, but also a problem for those tagging content) 2. there is no common way to find out what a given (sub)tag means 3. when different organizations have their own registries, the rigor with which the registrations are maintained varies wildly. 4. when an organization dissolves or is aborbed by another organization, its registry often is lost in the shuffle, but the data lives on These are the kind of real problems the SNMP and CMIP communities have experienced. In the case of language tagging, I believe the need for vendor- or organization-specific (sub)tags is even lower, and the value of a common set of registrations is even higher. Consequently, even though I think there is value in permitting private use extensions, I think we should do nothing to encourage their proliferation. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 06 21:36:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLJK-00021m-Ca; Wed, 06 Jul 2005 21:36:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLJJ-00020c-3A for ltru@megatron.ietf.org; Wed, 06 Jul 2005 21:36:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23081 for ; Wed, 6 Jul 2005 21:36:15 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqLkO-0003f2-TD for ltru@ietf.org; Wed, 06 Jul 2005 22:04:17 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqLJE-0002G3-N7; Wed, 06 Jul 2005 18:36:13 -0700 Message-Id: <6.2.1.2.2.20050707011113.053243f0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 07 Jul 2005 02:01:25 +0200 To: ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Restoration of privileges and warning In-Reply-To: <01fc01c581e4$d4569da0$7f1afea9@oemcomputer> References: <01fc01c581e4$d4569da0$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 06:40 06/07/2005, Randy Presuhn wrote: >Hi - >Since there is some question about whether the message Randy posted >at http://www1.ietf.org/mail-archive/web/ltru/current/msg01897.html >was explicit enough as an RFC 3934 warning to Mr. Morfin, we are >restoring his posting privileges. *This* message is an explicit warning >to him that he must stay on topic for the group, avoid personal >attacks, and cease mis-representing the positions of other participants >to retain those privileges. If his postings become disruptive, his >ltru WG mailing list posting privileges will be revoked. > >Randy & Martin, ltru co-chairs Dear all, Having previously appealed from the decision to ban me to the ADs I am not at liberty to comment this. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 06 21:36:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLJK-00022A-Gx; Wed, 06 Jul 2005 21:36:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLJJ-00020i-AC for ltru@megatron.ietf.org; Wed, 06 Jul 2005 21:36:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23083 for ; Wed, 6 Jul 2005 21:36:15 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqLkO-0003f3-T9 for ltru@ietf.org; Wed, 06 Jul 2005 22:04:17 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqLJF-0002G3-P4; Wed, 06 Jul 2005 18:36:14 -0700 Message-Id: <6.2.1.2.2.20050707020333.05450b20@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 07 Jul 2005 02:17:45 +0200 To: "Randy Presuhn" , From: r&d afrac Subject: Re: [Ltru] Private Use Tags In-Reply-To: <00bc01c5825a$eadf56e0$7f1afea9@oemcomputer> References: <42CB03D4.20801@megared.net.mx> <6.2.1.2.2.20050706001224.05117b90@mail.afrac.org> <42CC0B62.9030802@megared.net.mx> <00bc01c5825a$eadf56e0$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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:45 06/07/2005, Randy Presuhn wrote: >Hi Dylan - > >If I might summarize your message, I think you have four concerns: > 1) are tags descriptive or prescriptive? > 2) how well does the specification cope with new languages? > 3) support for tagging other linguistics aspects of a document > 4) is the space defined by the extension mechanism sufficiently large? > >As a technical contributor, I think your first concern can be definitively >answered: "Language tags are, from a linguistic perspective, descriptive." >Would it be helpful to include this sentence in the i-d? The only person >who has argued otherwise, as far as I know, is Mr. Morfin. I am afraid this may be a mis-representation of my position. I do not want it to be said "descriptive", I wand it to be defined. This being said, I would certainly welcome the wording proposed by Dylan: I am not sure wat your "linguistic perspective" want to say, all the more than languages are not defined. >On your second concern, the support for novel or artificial languages, the >draft is quite clear that if the language is used by humans for communication >with humans, it is within scope. (Section 2) Since, as you affirm, >Klingon is >in use for human-to-human communication, it has been registered. I think >this is a pretty convincing demonstration that the registry can cope with >novel >languages. > >Regarding your third concern, tagging other linguistic aspects of a document, >as "social class" or "preferred spelling dictionary", I think you'd find some >lack of agreement on whether these belong in a language tag or whether >they should be regarded as distinct attributes. Referent and context (or style) defines versions of a language. >The working group does not >need to resolve this question to meet the terms of its charter. I disagree. Not on the integration of ISO codes. But on scalability. > My personal >view is that this is a good thing; the universe of all possible attributes of >linguistic interest is far to large to permit completion of our work in a >reasonable time. No. It is sufficient to say that referent and context subtags (particulars of a language, and particulars to its mode of usage) are given a format and to be registered. This only calls for the use of ".". en.oxford.casual-Latn-US is OK with me. Or en.IBM.admin-Latn-US. Parsers need only to stop at the first "." in a subtag. > I think using a language tag to encode all the >linguistic attributes of a document makes as much sense as trying to >boil the ocean. There's a big difference between identifying the language >of a document and cataloging all its linguistic attributes. True. This is why the idea to formally attach non related attributes is an odd idea. Also to document it via an RFC and to make it a IANA registry. But if you really want it, it is to be engaged correctly. This means it must scale. >On your fourth concern, whether the space defined by the syntax of the >extension mechanisms is sufficiently large, depends in large part on the >extent to which you try to use language tags to address your third concern. >If the only tool you have is a hammer, then every problem is a nail. :-) Scalability is the limit. What means there is no limit. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 06 21:36:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLJK-00022Y-LF; Wed, 06 Jul 2005 21:36:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLJJ-00021d-Kq for ltru@megatron.ietf.org; Wed, 06 Jul 2005 21:36:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23089 for ; Wed, 6 Jul 2005 21:36:15 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqLkO-0003f1-T5 for ltru@ietf.org; Wed, 06 Jul 2005 22:04:17 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqLJD-0002G3-7e; Wed, 06 Jul 2005 18:36:11 -0700 Message-Id: <6.2.1.2.2.20050706232617.05468ae0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 07 Jul 2005 03:36:04 +0200 To: "Dylan N. Pierce" , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Private Use Tags In-Reply-To: <42CC0B62.9030802@megared.net.mx> References: <42CB03D4.20801@megared.net.mx> <6.2.1.2.2.20050706001224.05117b90@mail.afrac.org> <42CC0B62.9030802@megared.net.mx> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 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 Dylan, thank you for your response. I think we are in agreement on many things. But - you are a programmer - you know that from a concept to a program there must be an analysis and a development. Also, there is a added complexity which is that we are the IETF and not Open Source or Unicode. This means that we have to deal with networks, what means asynchronous interactions in real time with unknown final agents. There are simple rules from experience which help through this complexity which have been summarized by the present IETF Chair in RFC 1958. It is really worth reading and try to think that way and if possible improve it. Obviously you add your experience. I see you are following this. There are three rules which are basic for me: (a) except the rule which says that, everything can change (b) kiss, keep it simple, stable, stupid, etc. (c) scalability which means that you must be able to apply the theory of that rule everywhere it can apply and it will work, a correlative one is that you should not solve two things which may become similar in two different ways. In a nusthell this means open consistency: open, everything is possible, consistency, one single idea should apply because sometime, somewhere you will have a conflict. This is basically what you say everywhere. There is however a difference between what you say about programing and what I say about architecture: just think a step further, because here we are normating. So you _are_ to ask "why?" and not "are you sure", but "if we want that, we all have to do it that way for greatest efficiency": you aree like the client of your client. You build the envirnonment he will use to ask you to develop an application. At 18:48 06/07/2005, Dylan N. Pierce wrote: >In response to jfc (forgive me if I don't yet understand how to ensure >that my e-mail appears in the thread below the appropriate post; I freely >admit this is my first time participating in a procedure such as this). > >Whenever I read a standard, for better or for worse, the question I am >asking myself isn't, "What does this mean?" or "What purpose does this >serve?" I am always asking myself, "How do I write a program that does >this?" This is why RFC 3066, for all that it's a BCP, simply is >inadequate; I am interested enough in this working group to come here and >express a solid support for the current direction because having a >language tag which is parsable according to constructable rules greatly >reduces the amount of work any programmer has to do when developing for >compliance. The problem specific to this group was decscribed by Addison. He says and we all agree: RFC 3066 is too imprecise. There are two responses to that: 1. people like me who say (for my applications) "great, I am free" 2. people like Addison (for his XML or Unicode, etc.) and you for you applications who say "gee, I am lost". The role of the Draft is to address (2) while protecting (1). Now, you say: (3) "great, but I want more", and the role of the Draft should be to provide more. Now, you see we have a problem, because the Draft is expected to provide (1), (2) and (3) and provides only (2). What the Internet community (charter) expects from a BCP 47 is to address the problems of RFC 3066, which only provided (1). This can be done in two ways: 1. in writing a language tags framework for the Internet, of which the Draft will support (2) and will be ready to support as many (3) as you need. 2. because much work has been spent on (2) and that x-tags permit to support other formats and explore (3), to keep (1) and add (2) in just changing "replace RFC 3066" by "complement RFC 3066". Then we can all freely work. >As such, I read your first point, regarding characterizing the use of a >document, and it tells me something interesting about myself. The fact is, >for all its irony, I'm not typically even remotely interested in how a >document is used; I tend to focus on how a document is /filed/ by the >people who use it. Then you are more a programer (an author) than a networker. However, please note that you use the terms "people who use it". You do not say "people it is intended for". So you consider some action by the "non authors". >If a client tells me, "I want a list of all documents sorted >alphabetically by the third sentence of the second chapter," I might ask, >"Why? Are you sure?" but if the client insists, I'll dutifully begin >writing the appropriate algorithsm. > >I admit that issues of defining "What is a language?" and its >philosophical correlates are perhaps of coffee-table interest to me, but >not of professional interest as a programmer. I am not sure of that !!! Identfying a language is a very complex bit a programing. The language will be defined by statistical rules, etc. Look for example the orthographic correction of Word, which support multilanguage text and considers the language of the paragraph. This means a very interesting piece of code to decide that a paragraph is French and the next one is English. But, mainly,as a networker you see a language is an interaction protocol. No basic conceptual difference between http and English and C. But they can be used in many different modes and over many different media. Now, as a programer you become all the sudden very interested when due to that the language is not going to be the same depending on the mode or the media because the mode or the media is going to interfere with the restitution or because you will be able to compact exchanges (what you do for example with an error message). >Instead I merely want to know how I serve to any random end-user the >appropriate document following whatever language /he/ thinks he's >speaking. This means I need my language tags to be /descriptive,/ not >proscriptive, and they have to be extensible in a logical way. Descriptive/prescriptive have a meaning only in a context of use and by which partner of the exchange at which point of the exchange. If I describe what is necessary it becomes prescriptive. Full agreement with the extensibility requirement. >For better or for worse, if we are describing human languages, we must >deal with the reality that human beings /do/ invent languages. Yes all the time. And the worst of it is they invent it for machines too. If I tell you printf("you %s\n", "right"). What is it? > It /is/ possible to find websites written in Klingon and poetry written > in "Yodish." A bit disconcerting, to be sure, but possible. Certainly, if > someone in my living room was trying to speak to me in Klingon, I'd > probably request that he get a life, but /personally,/ I can do that. > Professionally I can't; Why? If your customer is Lucas, I bet you will do what he wants and you will send your bill. Open consistency, or scalability. >I can't use the fact that a man who speaks Esperanto, an equally >artificial language, is more likely to have a girlfriend than a man who >speaks Klingon as a justification for design limitations. Again, human >beings /do/ invent languages and any tagging standard which does not >account for this reality is inadequate for the task of classifying human >languages. Right! >Effectively, I look at the language tag in this fashion: if, for any two >random given people, I must use two different syntaxes to say the same >thing, then I need a different tag. en-US and en-GB are different not just >because the British like throwing in superfluous u's, but also because the >word "fanny" gets me in more trouble in one place than in the other. Right! But this may be also true with people who have lived something good/bad in common a word alludes to. >Same with the word "mantequilla" en es-MX versus es-AR. Anyone interested >in providing global content must be able to navigate these differences >/and/ similar unpredictable differences which arise in the future. What >happens, for example, when significant language-use differences are based >on social class in the exact same region in the exact same tongue? 100% agreement. >No existing tag accounts for this; can we be sure that 35 possibilities >for extension protect us against future social and creative inventions? We can be sure of not. And why would pentatridecimal be a limit (why 35 BTW?). >Extensibility and modularity must be incorporated into the system from its >inception or the system will fail. Human creativity and pop culture move >altogether faster than specification revision committees. 100% agreement. But remember you are a programer. So you must consider how to implement it. The work we carry is the following/ 1. two or more people dialoging/polyloging together establish a space of exchanges. This space has common references, we name referents (never mind at this stage what they are). 2. in so doing the establish relations. Each relation has its own context which modify (enrich, reduce, modify, etc.) the referent. 3. the exhanges are carried in using person to person interintelligibility protocols named "languages" supported by the end to end interoperation. 4. the referents and contexts are supported by "CRC" (common reference centers) where all the protocols elements (which extend far further than the pure language dscussed here, but will include the DNS, the LADP Directories being uses, etc.) can be seeked. For example through the DNS, OPES, etc. 5. one of the first thing people will do will be to negotiate the environment of the exchange and of the relation. For example, they will start negotiating the protocol: http/ftp?, English, French, Spanish;;; what is the most adequate to general exchange and to specific relations? You see that for example I use English here, but French would be better for me and I could try Spanish with you. At a given time you negotiate a Spanish context when you quote "mantequilla" (as a French speaker es-MX and es-AR are the same). You see that depending on the language we negotiated at a given time in the exchange or relation, if we quote a Web site, it will be different and if we call an LDAP directory the result may be different if it is multilingual. >Ultimately, these tags are not, and /cannot/ be, proscriptive for how >people are /allowed/ to classify languages; you can't program humans like >a computer. Instead, they need to be descriptive of how human beings /use/ >language--"use" it here in both senses, of how they actually speak, write >or signal it, and also in how they already classify it for their own >purposes of transmission, and that descriptiveness must share the same >capacity for growth as the objects it describes. In other words, the tags >used to describe languages must themselves be like languages: if the >language changes from region to region, so must the tags. If languages >divide or combine over time, so must the tags. And if languages can spring >wholesale from the minds of hack science-fiction screenwriters, so must >the tags. Right. And the way this is done on a distributed network is subsidiarity. This means that one (several?) semantics are to be defined (for mutual understanding, parsing, filtering, etc.) - as this Draft does for one - and people can use it the way they want. When you registered "megared" or "dylanpierce" the rule was first come fist serve. You were free. >Further, if languages can be analyzed for factors important to one >organization but irrelevant to another, so must the tags. The >reading-level example, for instance, is intrinsically part of how language >is used within a culture; the very educational institutions teaching the >language divide material in this fashion. The regional press example >points to how material is requested and provided, still however analyzed >based on sheer linguistic--word choice and level of abstractness--factors. >And since it would be daunting for a registration body to make any attempt >at trying to track and describe the myriad of human possibilities for >interpreting a language, best we put that charge directly in the hands of >the people who do it for a living. "who do it for a living" or "who live with it"? >Certainly this means that corporations will also use their namespace for >less germaine reasons. And fortunately, parsing agents can ignore their >tags and still remain completely in compliance: a small price to pay for >effectively making the entire world a de facto but organized registration >authority for how language is used worldwide. people empowerment is usually the best solution when you deal with people realtions. However you run into conflict easly because people tend to want to do the same thing. You usually have three ways to address this: the centralised hierarchy, which quickly lead to control (this is the system the Draft creates with strict reference to ISO), the decentralised system with needs some kind of technical oligarchy and also has some lose ends (this is the current RFC 3066 system), the distributed system where you do not have registration hierachichal trees but forests (everyone can create its own registry). Dealing with centralisation is quite sipmlifying. And a temptation. But it does not work, because as you describe it the world is centralised, decentralised and distributed at the same time. >I've been informed both here and privately that perhaps a more appropriate >approach would be to wait until this document becomes a standard and then >propose organizational namespace as a new Internet Draft. This is not possible as long as this Draft wants to replace RFC 3066. This is no problem if it complements it. Then there are two solutions: - either you proposition is general and you propose a framework for the Internet language idenfication which will replace RFC 3066 as BCP 47. - or your proposition only specifies one additional semantic in parallel of the current Draft semantic and you refer to RFC 3066 > Certainly, you guys know better than I do what we're up against and I'll > defer to your best judgment. Up to you to decide. If the Draft replaces RFC 3066 your extensions will have to obey the Draft not RFC 3066. Look at what it implies. IMHO if you want to intriduce "p-" you are far better off now than starting a new document. Simply because they want the document to go through and you could block it without "p-" if your "p-" gathers support. Afterward, everyone will tell you "wait for experience" "we have decided no", etc. We have the IDN experience. IDNA (Internationalised Domain Names applications) has been accepted by WG Members on the ground that it would be experimental and if it did not work we could change it. It does not work. M$ do not intend to implement it, yet after two years and China has split from the main Internet with its own co-root on the issue to correct it. IMHO (and we dispute on that, the same as we disputed over IDNs) this Draft if accepted will do the same. So it is very important to give it all the possible flexibility to give it a chance. >But the entire reason I so strongly support this project is because we >undeniably /need/ a parsable internationalization architecture (as a >programmer, /I/ need it, and I have yet to speak to a colleage who accuses >RFC 3066 of being sufficient) and it needs to speak to all the ways in >which languages are used, distributed, selected, and even (perhaps I'm >making enemies here) invented. Full agreement. But I do not think anyone will tell that RFC 3066 is sufficient: RFC 3066 is less restrictive. Actually what is wrong is the "langtag" by itself instead of supporting all the tags people really needs, whithout tying them into rigid supertags. >Extensibility can be anything from a lifesaver to a mere buzzword. For any >descriptor to be extensible in a way which has value, it must be >extensible in exactly the same ways in which the object it describes is >extensible. If it is not, time and human creativity will obsolete it. Amen. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 06 21:36:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLJK-00022w-Pf; Wed, 06 Jul 2005 21:36:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqLJJ-00021c-Jh for ltru@megatron.ietf.org; Wed, 06 Jul 2005 21:36:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23088 for ; Wed, 6 Jul 2005 21:36:15 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqLkP-0003fA-BS for ltru@ietf.org; Wed, 06 Jul 2005 22:04:17 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqLJH-0002G3-UI; Wed, 06 Jul 2005 18:36:16 -0700 Message-Id: <6.2.1.2.2.20050707021758.05455ae0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 07 Jul 2005 02:30:53 +0200 To: "Dylan N. Pierce" , Randy Presuhn , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Private Use Tags In-Reply-To: <42CC31E2.6010100@megared.net.mx> References: <42CB03D4.20801@megared.net.mx> <6.2.1.2.2.20050706001224.05117b90@mail.afrac.org> <42CC0B62.9030802@megared.net.mx> <00bc01c5825a$eadf56e0$7f1afea9@oemcomputer> <42CC31E2.6010100@megared.net.mx> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 21:32 06/07/2005, Dylan N. Pierce wrote: >Sounds pretty accurate to me. Remembering that my point of view is >generally always tainted by use-case scenarios, you'll have to forgive my >tendency to focus on an infinitude of "What if?" hypotheticals when >everyone around me merely wants to ship a finished product; that happens >at my home company, as well. Seems you are a good guy for QA. >Regarding point one, I imagine it's a case of being too close to the >issue. Of /course/ we know they're descriptive. But these things are >designed to be used by actual people, and people can be picky. I'm sure >Mr. Morfin is not unique in that regard. If something as simple as >specifying, "These tags are descriptive, not prescriptive, and do not >represent a limiting factor in languages or variations an application may >support," could head off a perceived slight by the unrepresented, that >doesn't seem to be an excessively high cost. Good start. I think it could do more. But good thing. >Regarding two, actually, I'm in complete agreement with you; I didn't mean >my side trip down that road to be taken as a point of contention with the >current draft. Rather, it was more a direct response to jfc's concerns >about ever-spiraling artificial languages, to serve as a sort of >affirmation that yes, the number of artificial languages will most likely >continue to grow, and our job isn't to do anything about that other than >design a mechanism which can describe it. I have no argument that the >current mechanism seems to fulfill that need. Here I object. - it is for human/human only. I do not know what it means nowadays. - please read at the practical limitations imposed via ISO >So no, please don't misunderstand me; I'm not campaigning for a complete >linguistic analysis in the tag. I'm campaigning for increased >compatibility by having a clear, machine-readable way of informing those >people who are already taking advantage of private-use tags that the >particular private tag they are looking at is in fact the one they meant >to look at. That kind of clarity and assurance, I believe, would benefit >everyone. This is called a semantic + vocabulary. This is not complex to achieve and there are many ways. But we are here engaged into the RFC 3066 format. The Draft wants a more strict semantic. A more strict semantic means more possible conflicts. You then reduce the risk in reducing the scope (your initial definition). Now, you want to extend the scope in adding reduced scopes: this is good as it gives more possibilities while not enlarging the risks of conflicts. But you are limited by the format ... Our approach to that is to say (it was suggested here) we take "x-", reduce its constraints and document it. If developers do not support our extension it will not work, what is not a problem since our system does not want to be compatible in the "x-" part. We could probably find a compromise. For everyone position to be supported. See my other mail. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 07 02:35:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqPyO-0003Vj-NS; Thu, 07 Jul 2005 02: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 1DqPyN-0003Su-FW for ltru@megatron.ietf.org; Thu, 07 Jul 2005 02:34:59 -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 CAA02912 for ; Thu, 7 Jul 2005 02:34:57 -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 <20050707063427.FGYW19267.mta10.adelphia.net@DEWELL> for ; Thu, 7 Jul 2005 02:34:27 -0400 Message-ID: <000a01c582bd$e44cdec0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050706184415.FRGA21785.mta5.adelphia.net@megatron.ietf.org> Date: Wed, 6 Jul 2005 23:34:11 -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: does the Draft gives all the guidelines required by the 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 Jefsey Morfin wrote: >> LANGUAGE TAG REGISTRATION FORM >> Name of requester : Karen Broome >> E-mail address of requester: karen_broome@spe.sony.com > > This information is of no interest to the users. It gives Karen Broome > and possibly Sony a stewardship on the American Spanish some could > seriously object. Incorrect. It says right there, "Name of requester." It is the name of the person who has filed the request to have the language tag registered. Neither RFC 3066 nor any other document implies or requires that the requester has any expertise in the language. The presence of "sony.com" in Karen's e-mail address says nothing about Sony's support of, or opposition to, her request, just as the presence of "adelphia.net" in my e-mail address says nothing about whether Adelphia agrees with what I say here. It is true that most users will not care who requested a tag, once the tag is registered. >> Native name of language (transcribed into ASCII): espanol de America >> Latina, espanol latinoamericano > > This information misses the French name of the language. Rightly or wrongly, this information is not required by RFC 3066. See page 8. >From the remainder of his comments, I take it Jefsey opposes the registration of "es-419". -- 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 Thu Jul 07 07:20:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqUR1-0006c6-Dm; Thu, 07 Jul 2005 07:20:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqUQz-0006ao-T4 for ltru@megatron.ietf.org; Thu, 07 Jul 2005 07:20:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24966 for ; Thu, 7 Jul 2005 07:20:46 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqUs9-0004zb-9o for ltru@ietf.org; Thu, 07 Jul 2005 07:48:55 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqUQk-00012j-Fc; Thu, 07 Jul 2005 04:20:34 -0700 Message-Id: <6.2.1.2.2.20050707113255.04098240@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 07 Jul 2005 13:20:26 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: does the Draft gives all the guidelines required by the Registry In-Reply-To: <000a01c582bd$e44cdec0$030aa8c0@DEWELL> References: <20050706184415.FRGA21785.mta5.adelphia.net@megatron.ietf.org> <000a01c582bd$e44cdec0$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Doug, I wish first you do not misconstrue by error my comments. I do not criticise what Michael has done (he himself has asked possible discrepancies to be fixed off line, what shows this is not easy for him). I want us to check, on probably the most complex example so far, that the current Draft would have helped him better. I wish too to see if it removes the difficulties which may lead to the removal of this registry from the IANA. Because people in charge may be "very hesitant to involve IANA in any direct way with either the language or country code authorities". So, my references are not to the RFC 3066 but to the Draft. At 08:34 07/07/2005, Doug Ewell wrote: >Jefsey Morfin wrote: > > >> LANGUAGE TAG REGISTRATION FORM > >> Name of requester : Karen Broome > >> E-mail address of requester: karen_broome@spe.sony.com > > > > This information is of no interest to the users. It gives Karen Broome > > and possibly Sony a stewardship on the American Spanish some could > > seriously object. > >Incorrect. It says right there, "Name of requester." It is the name of >the person who has filed the request to have the language tag >registered. Neither RFC 3066 nor any other document implies or requires >that the requester has any expertise in the language. I am glad you write that. 1. I think the first requirement should be that he is authoritative in the language or an active user of the language. 2. the Draft gives the registrant a priority/authority in discussing modifications concerning the language I want to see removed, for the reason you give: nothing "implies or requires that the request has any expertise in the language". 3. actually I do not see any reason why this name is recorded. No one owns a language: the request just represents the lingual or the global internet commuity. Otherwise the participants to the ietf-languages mailing list should also be recorded. 4. IMHO the procedure should be the otherway around. Anyone can register any language except if within 15 days were risen serious objections accepted by the Reviewer. >The presence of "sony.com" in Karen's e-mail address says nothing about >Sony's support of, or opposition to, her request, just as the presence >of "adelphia.net" in my e-mail address says nothing about whether >Adelphia agrees with what I say here. > >It is true that most users will not care who requested a tag, once the >tag is registered. This is not necessarily the feeling everywhere. When Peter Constable and Mark Davis registered Tajik and Chinese langtags, you may have noted that several times the mention was made on the ietf-languages@alvestrand.no mailing list these requests were made by Microsoft and IBM. I took acception of that in made some publicity of it (what was reproached to me). A Government note was copied to me about the concern that this might lead sales people to label their product "xxxx IANA registered xx-xxxx-xx inside". This is in direct line with the IAB fear in RFC 3869 (I quote: "The principal thesis of this document is that if commercial funding is the main source of funding for future Internet research, the future of the Internet infrastructure could be in trouble."). You will understand that as a non-commercially funded searcher (AFRAC is a non-profit), I share these concerns expressed by several officials from different countries on different continents. > >> Native name of language (transcribed into ASCII): espanol de America > >> Latina, espanol latinoamericano > > > > This information misses the French name of the language. > >Rightly or wrongly, this information is not required by RFC 3066. See >page 8. I know and this is why I note it. General consensus among the non English mother tongue and a broad part of educated English mother tongue searchers I know is that the best fit is to use English as a koine and a quick experimentation tool due to its capacity to accept lose definitions and intuitive mutual rough understanding, and to use French as a reference language. The QA comes from a simultaneous work in both languages. The famous example of MPEG shown that MPEG convergence (radio, TV, media) could not have happen without a first working bridge between the English standard texts in French (to have a common term definition of the difference standards) to support the further work in English and a finalisation through duallanguage QA. Translation of the French version with the assistance of the English version is often easier and more precise in other languages. > >From the remainder of his comments, I take it Jefsey opposes the > registration of "es-419". Total misconstruction of my comment. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 07 09:46:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWhx-0008WQ-GF; Thu, 07 Jul 2005 09:46:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqWhw-0008Vr-Lg for ltru@megatron.ietf.org; Thu, 07 Jul 2005 09:46:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07609 for ; Thu, 7 Jul 2005 09:46:26 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqX97-0000Oo-Pe for ltru@ietf.org; Thu, 07 Jul 2005 10:14:35 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqWho-0007Wf-Bd for ltru@ietf.org; Thu, 07 Jul 2005 06:46:21 -0700 Message-Id: <6.2.1.2.2.20050707150832.0532b8b0@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 07 Jul 2005 15:46:11 +0200 To: ltru@ietf.org From: r&d afrac Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [Ltru] please, get real! X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 been challenged privately to explain publicly why I wanted to see the RFC 3066 Registry removed from the IANA. I suppose this is just another troll, but I think the point important enough to explain it however obvious, challenged or not. A debate goes on, on the IETF main list, to know if IESG was entitled to refuse a code point to Dr. Lawrence Robert. This permits some to follow on 25 years old feuds, or to come back on old RFCs, or to propose changes to RFC 2860, as if it was not the result on a negotiation where the other partner is now confirmed as the US Government. What is important to us, is to observe that the political layer is quickly reached when a registry manager is considered as a Judge and not as a simple registration collector. - I proposed the Registry to act as a smart recorder: everything is accepted except if consensually opposed on the opinion of the reviewer. This would reduce the risks of contention and speed-up the process. - The concerns remains high with the documentation of issues subject to national policies. Let say that I want to register en-Latn-US and I describe the language with a reference to an American translation of a French Cook Book (we all know that I could give much poorer examples). What would be the response? But in using ISO 3166, we enter political langtags. Even a simple national map, a nation's name are political. So, languages.... If you consider the following: http://news.yahoo.com/s/afp/20050613/tc_afp/chinainternetcompanymicrosoft;_ylt=AsL7orP4gnws5tkilESYvF0jtBAF;_ylu=X3oDMTBiMW04NW9mBHNlYwMlJVRPUCUl the permitted pages will necessarily be stamped. This is no different from Kentucky press as a concept. This is a language with a referent similar to anyEnglish referent but with some terms contextually removed. Necessarily at some stage, librarian, press, readers, on-line archives, etc. will want to classify the pages using that filtered language. Our role is not to judge but to enable: we need to support it (and it is probably good to expose it). But, frankly, is it to IETF (or even ICANN), and to Michael Everson to sponsor such a registration? To IANA to broadcast it under the approval of IESG? I do not think so. I say that such a problem for the IANA, ICANN and everyone, mainly comes from the form of RFC 3066 registration described by the Draft. The Internet Community should be mature enough to identify and address the problem. To do that it trusts this WG. Please, get real! jfc PS. I suspect that now a friend/avatar(?) of my challenger will ask that I am expelled because I rise the proper questions. I mention this because I am tired of this personal teasing and I wish it to stop. If you people are so aware of this debate, why not to join the WG-ltru? Or may you are on it (I do not know all the 57 members of the list). _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 07 10:58:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXq1-0007zQ-EE; Thu, 07 Jul 2005 10:58:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXpz-0007yg-9m for ltru@megatron.ietf.org; Thu, 07 Jul 2005 10:58:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15067 for ; Thu, 7 Jul 2005 10:58:48 -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.43) id 1DqYHA-0004OV-Ml for ltru@ietf.org; Thu, 07 Jul 2005 11:26: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 Jul 2005 08:00: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] please, get real! Date: Thu, 7 Jul 2005 08:00:21 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C014E56@irvmbxw01.quest.com> Thread-Topic: [Ltru] please, get real! Thread-Index: AcWC+q1FYgcA36snQ1aq+BOIsjZvQgACLOSQ From: "Addison Phillips" To: X-OriginalArrivalTime: 07 Jul 2005 15:00:22.0990 (UTC) FILETIME=[9997D6E0:01C58304] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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 To remove the RFC 3066 registry from IANA would require a new RFC, such = as we are working on here, so... Where do you propose to put the registry if not IANA? A proposal to host = it somewhere else should include the "somewhere else". For the remainder of the issues in your note below, obviously no one on = this list is going to convince you to change your position and at least = a number of us are not going to change our positions (that we have done = the right things with the draft). I suggest we agree to disagree and = move along in the process. 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 r&d afrac > Sent: 2005?7?7? 6:46 > To: ltru@ietf.org > Subject: [Ltru] please, get real! >=20 > I have been challenged privately to explain publicly why I wanted to = see > the RFC 3066 Registry removed from the IANA. I suppose this is just > another > troll, but I think the point important enough to explain it however > obvious, challenged or not. >=20 > A debate goes on, on the IETF main list, to know if IESG was entitled = to > refuse a code point to Dr. Lawrence Robert. This permits some to = follow on > 25 years old feuds, or to come back on old RFCs, or to propose changes = to > RFC 2860, as if it was not the result on a negotiation where the other > partner is now confirmed as the US Government. What is important to = us, is > to observe that the political layer is quickly reached when a registry > manager is considered as a Judge and not as a simple registration > collector. >=20 > - I proposed the Registry to act as a smart recorder: everything is > accepted except if consensually opposed on the opinion of the = reviewer. > This would reduce the risks of contention and speed-up the process. >=20 > - The concerns remains high with the documentation of issues subject = to > national policies. Let say that I want to register en-Latn-US and > I describe the language with a reference to an American translation = of a > French Cook Book (we all know that I could give much poorer examples). > What > would be the response? >=20 > But in using ISO 3166, we enter political langtags. Even a simple = national > map, a nation's name are political. So, languages.... >=20 > If you consider the following: > = http://news.yahoo.com/s/afp/20050613/tc_afp/chinainternetcompanymicrosoft= ; > = _ylt=3DAsL7orP4gnws5tkilESYvF0jtBAF;_ylu=3DX3oDMTBiMW04NW9mBHNlYwMlJVRPUC= Ul > the permitted pages will necessarily be stamped. This is no different = from > Kentucky press as a concept. This is a language with a referent = similar to > anyEnglish referent but with some terms contextually removed. = Necessarily > at some stage, librarian, press, readers, on-line archives, etc. will = want > to classify the pages using that filtered language. Our role is not to > judge but to enable: we need to support it (and it is probably good to > expose it). >=20 > But, frankly, is it to IETF (or even ICANN), and to Michael Everson to > sponsor such a registration? To IANA to broadcast it under the = approval of > IESG? I do not think so. I say that such a problem for the IANA, ICANN = and > everyone, mainly comes from the form of RFC 3066 registration = described by > the Draft. The Internet Community should be mature enough to identify = and > address the problem. To do that it trusts this WG. >=20 > Please, get real! > jfc >=20 > PS. I suspect that now a friend/avatar(?) of my challenger will ask = that I > am expelled because I rise the proper questions. I mention this = because I > am tired of this personal teasing and I wish it to stop. If you people = are > so aware of this debate, why not to join the WG-ltru? Or may you are = on it > (I do not know all the 57 members of the list). >=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 Jul 07 11:01:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXsP-0000N9-C4; Thu, 07 Jul 2005 11:01:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqXsN-0000Mz-Ey for ltru@megatron.ietf.org; Thu, 07 Jul 2005 11:01:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15361 for ; Thu, 7 Jul 2005 11:01:14 -0400 (EDT) Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqYJW-0004X3-OT for ltru@ietf.org; Thu, 07 Jul 2005 11:29:24 -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 <20050707150058.UPGD19267.mta10.adelphia.net@DEWELL> for ; Thu, 7 Jul 2005 11:00:58 -0400 Message-ID: <008b01c58304$94f7c1e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050706184415.FRGA21785.mta5.adelphia.net@megatron.ietf.org> <000a01c582bd$e44cdec0$030aa8c0@DEWELL> <6.2.1.2.2.20050707113255.04098240@mail.afrac.org> Subject: Re: [Ltru] Re: does the Draft gives all the guidelines required by the Registry Date: Thu, 7 Jul 2005 08:00: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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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 r&d afrac wrote: > I wish first you do not misconstrue by error my comments. I do not > criticise what Michael has done (he himself has asked possible > discrepancies to be fixed off line, what shows this is not easy for > him). I want us to check, on probably the most complex example so far, > that the current Draft would have helped him better. I thought the problems with the "es-419" registration were of a fairly minor clerical nature, not complex and technical. > I wish too to see if it removes the difficulties which may lead to the > removal of this registry from the IANA. Because people in charge may > be "very hesitant to involve IANA in any direct way with either the > language or country code authorities". What "people in charge"? What "removal"? RFC 3066 designates a Language Tag Reviewer who may, from time to time, have occasion to deal directly with ISO 639/RA and ISO 3166/MA, but not on a regular basis. The draft does the same for the Language Subtag Reviewer. IANA is not involved with these agencies at all; the Reviewer forwards material to them with instructions to put the material in the registry. >>> This information is of no interest to the users. It gives Karen >>> Broome and possibly Sony a stewardship on the American Spanish some >>> could seriously object. >> >> Incorrect. It says right there, "Name of requester." It is the name >> of the person who has filed the request to have the language tag >> registered. Neither RFC 3066 nor any other document implies or >> requires that the requester has any expertise in the language. > > I am glad you write that. > > 1. I think the first requirement should be that he is authoritative in > the language or an active user of the language. The requester needs to have a need or desire to assign a tag to new or existing material in the language, and know enough *about* the language to establish that this need or desire is not met by existing tags. Note that I did not say the requester has to *know* the language, but rather know *about* it. This is exactly Karen's situation: she needs to be able to assign a tag to Spanish-language material that has been determined to be suitable for a wide range of Latin American audiences. She may not have been involved in the process of making that determination, and she may not even speak Spanish, but she is the one responsible for tagging the material, and understands enough about (a) Spanish and its regional differences and (b) RFC 3066 and tagging to know what needs to be done. As you correctly state later, no one "owns" a language. The requester of a tag (or, under the current draft, a subtag) is just that: the person who made the request. Some people may imagine that this implies some sort of ownership, but those people would be mistaken. > 2. the Draft gives the registrant a priority/authority in discussing > modifications concerning the language I want to see removed, for the > reason you give: nothing "implies or requires that the request has any > expertise in the language". RFC 3066 gave the requester the same priority with regard to her request. Again, the requester is assumed to be someone with expertise and authority in her operational need to tag material in language X, not necessarily someone with expertise and authority in language X. I hope this distinction is clear. > 3. actually I do not see any reason why this name is recorded. No one > owns a language: the request just represents the lingual or the global > internet commuity. Otherwise the participants to the ietf-languages > mailing list should also be recorded. The name is recorded for clerical reasons. It is not necessary for using or understanding the tag. The participants in the ietf-languages mailing list are recorded, of course, in the publicly available archives. > 4. IMHO the procedure should be the otherway around. Anyone can > register any language except if within 15 days were risen serious > objections accepted by the Reviewer. That's sort of the way it is, except that people do not register tags directly; they request them, ietf-languages discusses them, the Reviewer approves them, and IANA does the clerical work of updating the registry. >> The presence of "sony.com" in Karen's e-mail address says nothing >> about Sony's support of, or opposition to, her request, just as the >> presence of "adelphia.net" in my e-mail address says nothing about >> whether Adelphia agrees with what I say here. >> >> It is true that most users will not care who requested a tag, once >> the tag is registered. > > This is not necessarily the feeling everywhere. When Peter Constable > and Mark Davis registered Tajik and Chinese langtags, you may have > noted that several times the mention was made on the > ietf-languages@alvestrand.no mailing list these requests were made by > Microsoft and IBM. I took acception of that in made some publicity of > it (what was reproached to me). All requests are made by individuals. Sometimes those individuals are acting on the basis of their employers' business need. That is my understanding of the connection between Microsoft and IBM and the tags you mention. The requester of "en-scouse" back in 2000 was Keith Szlamp. His e-mail address, back then, was . I have no way of knowing whether Keith requested this tag out of personal amusement, or because he is a speaker of Scouse or an academic expert on it, or because he worked for a multi-billion-euro company whose business needs demanded it. But I know that if I want more information about this registration, I might try looking up "Keith Szlamp" on the Internet, or check whether his e-mail address from 2000 is still active. That is why information about the requester might be of value. > A Government note was copied to me about the concern that this might > lead sales people to label their product "xxxx IANA registered > xx-xxxx-xx inside". This is in direct line with the IAB fear in RFC > 3869 (I quote: "The principal thesis of this document is that if > commercial funding is the main source of funding for future Internet > research, the future of the Internet infrastructure could be in > trouble."). Such labeling would be inappropriate. (It would not be the first time sales people had done such a thing, though.) RFC 3066 provides for tags to be registered in an IANA registry. If that mechanism is used in accordance with the RFC, as happened with Scouse and with the Tajik and Chinese registrations, there is no negative impact on IANA or the Internet infrastructure. The same is true for registering subtags uner the draft. > You will understand that as a non-commercially funded searcher (AFRAC > is a non-profit), I share these concerns expressed by several > officials from different countries on different continents. Sometimes it is necessary to respond to people's concerns by showing them that everything is fine and that their fears are unfounded. No non-commercial interests are harmed when a tag or subtag is registered because a commercial operation needs it. >>>> Native name of language (transcribed into ASCII): espanol de >>>> America Latina, espanol latinoamericano >>> >>> This information misses the French name of the language. >> >> Rightly or wrongly, this information is not required by RFC 3066. >> See page 8. > > I know and this is why I note it. General consensus among the non > English mother tongue and a broad part of educated English mother > tongue searchers I know is that the best fit is to use English as a > koine and a quick experimentation tool due to its capacity to accept > lose definitions and intuitive mutual rough understanding, and to use > French as a reference language. The QA comes from a simultaneous work > in both languages. The famous example of MPEG shown that MPEG > convergence (radio, TV, media) could not have happen without a first > working bridge between the English standard texts in French (to have a > common term definition of the difference standards) to support the > further work in English and a finalisation through duallanguage QA. > > Translation of the French version with the assistance of the English > version is often easier and more precise in other languages. I won't get into the relative merits of the French and English languages. Toutes les deux sont bonnes, n'est-ce pas ? You may recall that I originally favored the addition of French descriptions, which had never been required of RFC 1766 and 3066 registrations. What killed it for me, and perhaps others, was the proposal to expand this concept exponentially, by turning the registry into a compendium of "every language name in every language." Do you remember who proposed that? >> From the remainder of his comments, I take it Jefsey opposes the >> registration of "es-419". > > Total misconstruction of my comment. I am glad you do not oppose the registration. That you oppose the draft is well documented. -- 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 Thu Jul 07 11:29:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYJI-0006lt-0V; Thu, 07 Jul 2005 11:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYJG-0006k3-NC for ltru@megatron.ietf.org; Thu, 07 Jul 2005 11:29:06 -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 LAA17659 for ; Thu, 7 Jul 2005 11:29: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 <20050707152835.WGDS19267.mta10.adelphia.net@DEWELL> for ; Thu, 7 Jul 2005 11:28:35 -0400 Message-ID: <009601c58308$814e5a60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050707150203.XJDO21353.mta3.adelphia.net@megatron.ietf.org> Date: Thu, 7 Jul 2005 08:28: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 Cc: Subject: [Ltru] Re: please, get real! X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 r&d afrac wrote: > But in using ISO 3166, we enter political langtags. Even a simple > national map, a nation's name are political. So, languages.... This is why the descriptions in region subtags are (a) not normative and (b) taken directly from an ISO standard, which is assumed to be politically and culturally unbiased. This has been explained already. -- 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 Thu Jul 07 11:33:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYNg-0001Rn-Gz; Thu, 07 Jul 2005 11:33:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYNe-0001Lo-Er for ltru@megatron.ietf.org; Thu, 07 Jul 2005 11:33:38 -0400 Received: from unix.megared.net.mx (megamail.megared.com.mx [200.52.207.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18442 for ; Thu, 7 Jul 2005 11:33:35 -0400 (EDT) Received: from [192.168.2.170] ([10.60.88.84]) by unix.megared.net.mx (8.11.7/8.11.7) with ESMTP id j67FWxR30952 for ; Thu, 7 Jul 2005 10:33:00 -0500 (CDT) Message-ID: <42CD4B2A.2080607@megared.net.mx> Date: Thu, 07 Jul 2005 10:32:58 -0500 From: "Dylan N. Pierce" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ltru@ietf.org Subject: Re: [Ltru] Private Use Tags References: <42CB03D4.20801@megared.net.mx><6.2.1.2.2.20050706001224.05117b90@mail.afrac.org> <42CC0B62.9030802@megared.net.mx> <00bc01c5825a$eadf56e0$7f1afea9@oemcomputer> <42CC31E2.6010100@megared.net.mx> <001c01c5826a$b7d597e0$7f1afea9@oemcomputer> In-Reply-To: <001c01c5826a$b7d597e0$7f1afea9@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > Thanks for the clarification. I think there's really a policy question > underneath this: how strongly do we want to encourage the registration > of subtags? I'd have to agree with this. Probably this entire side discussion can be put to bed by taking a firm stand one way or the other on the answer to this question. > If the point of having a registry is to provide open access > to information that allows someone to figure out what a tag signifies, > and to promote consistent tagging of data, motivated by a desire to promote > interoperability, then I think it's important to emphasize the "last resort" > nature of private-use tags. Eliminating them completely would be the way to achieve these things with certainty. Having them as sort of a "wild, wild west" area where there is no law and anyone can do whatever they want actually does the opposite of the three things you mention here (provide open access, promote consistent tagging, promote interoperability). What I was proposing was, perhaps, a kind of middle-ground for these two extremes. Something in between complete, non-extensible regimentation and "may God have mercy on your soul." I'm beginning to see what the objections are about, and I wonder if perhaps including private tags in the first place wasn't a concession that shouldn't have been made. > As you note, the need to structure a space of private use tags arises > when there is a risk that they would "leak". I such a case, the use > is no longer "private", and properly registered tags should be > used instead. I think this is especially true if there is any reason > anyone else would be interested in material in the language in question. Leakage is going to happen. Sun Microsystems, for example, finds the third subtag to be an excellent place to include currency information ("es-ES-EURO"). Every copy of the JDK they've shipped since 1.2 has gone out that way. So on the one hand, they're hardly keeping it "private" and on the other hand, I haven't seen any petition for a registration of currency information in the third subtag, and I'd probably oppose it if I did (currency is even /less/ a part of language than reading level, in my opinion). Point being that, if people are already doing it, and it seems reasonable (as it does to me, but I'm hardly representative) that people will continue doing it, we can either /act/ like they're going to do it, and respond to those needs, or we can clearly tell them, "Just don't do it /here/." >[some skippage of your text] > > Consequently, even though I think there is value in permitting private use > extensions, I think we should do nothing to encourage their proliferation. > > Randy Regarding the part I didn't copy over, I begin to see the problems. It makes me want to reverse my position to the point of saying, "Let's eliminate private tags completely; if someone uses something of their own, it's officially no longer in compliance with the specification." My belief is that if something is there, it will be used (and perhaps in ways we do not foresee). If something is not to be used, it should not be there. I'm uncomfortable with the idea of "discouraged extensibility." Just to head off misinterpretation, let me go on record as stating that if I were called upon to vote for this draft as it stands, if my vote would matter, I would vote to pass it. It's certainly better than its predecessor and that's why I took an interest in these proceedings in the first place. I don't want the perfect to be the enemy of the good, so for all intents and purposes, I support the draft. But given what you've explained to me, I declare very firmly: we should stake out the "policy question" explicitly. Either we /do/ want to include private use tags, at which point we should set up a mechanism to ensure that the private use tags themselves do (as you put it) "promote open access, promote consistent tagging and promote interoperability" (by handling leakage and providing a way to know which private tag is which)... or we do /not/ really want to encourage private use tags, which we could do more consistently by simply saying, "These tags cover language, dialect and script, and nothing more. Anything over and above this should be handled outside the tag," and eliminate private use tags completely. Dylan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 07 11:53:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYhF-0006yF-U7; Thu, 07 Jul 2005 11:53:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYhF-0006yA-3S for ltru@megatron.ietf.org; Thu, 07 Jul 2005 11:53:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20358 for ; Thu, 7 Jul 2005 11:53: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.43) id 1DqZ8R-0001Qu-BK for ltru@ietf.org; Thu, 07 Jul 2005 12:22:00 -0400 Received: from eupig1 (unverified) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Thu, 7 Jul 2005 15:55:00 +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 <0IJ9006CSLDTXX@eupig1.dtc.lon.ime.reuters.com>; Thu, 07 Jul 2005 15:53:36 +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 Jul 2005 16:50:56 +0100 Date: Thu, 07 Jul 2005 16:48:28 +0100 From: Misha Wolf Subject: RE: [Ltru] Private Use Tags To: "Dylan N. Pierce" , ltru@ietf.org MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Private Use Tags thread-index: AcWDChbt7LZuicQPRq6Tavc0eWdI3AAAQq3A Content-Class: urn:content-classes:message X-OriginalArrivalTime: 07 Jul 2005 15:50:57.0185 (UTC) FILETIME=[AA1D4110:01C5830B] X-Spam-Score: 0.8 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Dylan N. Pierce wrote: > Leakage is going to happen. Sun Microsystems, for example, finds=20 > the third subtag to be an excellent place to include currency=20 > information ("es-ES-EURO"). Every copy of the JDK they've shipped=20 > since 1.2 has gone out that way. This sounds like a locale ID, not a language ID. Does it use "-"=20 separators or "_"? 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 Jul 07 12:06:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYta-0004Mr-Ez; Thu, 07 Jul 2005 12:06:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYtY-0004LY-UZ for ltru@megatron.ietf.org; Thu, 07 Jul 2005 12:06:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21359 for ; Thu, 7 Jul 2005 12:06: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.43) id 1DqZKk-0002sg-4z for ltru@ietf.org; Thu, 07 Jul 2005 12:34:44 -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 Jul 2005 09:08: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: does the Draft gives all the guidelinesrequired by the Registry Date: Thu, 7 Jul 2005 09:08:06 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C014EDA@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: does the Draft gives all the guidelinesrequired by the Registry Thread-Index: AcWC5kqTt410AWGuSbuYSyNfrLkVhgAHjuzw From: "Addison Phillips" To: "r&d afrac" , "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 07 Jul 2005 16:08:07.0109 (UTC) FILETIME=[0FFF2F50:01C5830E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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 responses below. I'll note that you are straying from the draft, = which has already addressed your concerns in this area. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 > > > This information is of no interest to the users. It gives Karen = Broome > > > and possibly Sony a stewardship on the American Spanish some could > > > seriously object. > > > >Incorrect. It says right there, "Name of requester." It is the name = of > >the person who has filed the request to have the language tag > >registered. Neither RFC 3066 nor any other document implies or = requires > >that the requester has any expertise in the language. >=20 > I am glad you write that. >=20 > 1. I think the first requirement should be that he is authoritative in = the > language or an active user of the language. [Addison Phillips]=20 We can't require that from the requester: you propose a test for = language authority? It is nice/best when the requester is authoritative = about the language, but we cannot require it. > 2. the Draft gives the registrant a priority/authority in discussing > modifications concerning the language I want to see removed, for the > reason > you give: nothing "implies or requires that the request has any = expertise > in the language". [Addison Phillips]=20 Read the draft. RFC 3066 says something about the requester and gives = that person some level of "authority" about a registered tag. The draft = reduces this level of authority somewhat (it suggests that objections by = the original requester will be taken more seriously than others), but = this is not normative in any sense. > 3. actually I do not see any reason why this name is recorded. No one = owns > a language: the request just represents the lingual or the global = internet > commuity. Otherwise the participants to the ietf-languages mailing = list > should also be recorded. [Addison Phillips]=20 The name is not recorded in the registry under the draft. > 4. IMHO the procedure should be the otherway around. Anyone can = register > any language except if within 15 days were risen serious objections > accepted by the Reviewer. [Addison Phillips]=20 Suggest how you would modify text in the draft. It is possible to read = both RFC 3066 and the draft in the way you suggest (i.e. if no one = raises serious objections, then the Reviewer is somehow obligated to = register the tag/subtag--lack of serious objections equals consensus) >=20 > >The presence of "sony.com" in Karen's e-mail address says nothing = about > >Sony's support of, or opposition to, her request, just as the = presence > >of "adelphia.net" in my e-mail address says nothing about whether > >Adelphia agrees with what I say here. > > > >It is true that most users will not care who requested a tag, once = the > >tag is registered. >=20 > This is not necessarily the feeling everywhere. When Peter Constable = and > Mark Davis registered Tajik and Chinese langtags, you may have noted = that > several times the mention was made on the ietf-languages@alvestrand.no > mailing list these requests were made by Microsoft and IBM.=20 [Addison Phillips]=20 Those requests were supported by those companies. Companies may have an = official position; whether such a position matters or not is a separate = question. I took > acception of that in made some publicity of it (what was reproached to = me). > A Government note was copied to me about the concern that this might = lead > sales people to label their product "xxxx IANA registered xx-xxxx-xx > inside". This is in direct line with the IAB fear in RFC 3869 (I = quote: > "The principal thesis of this document is that if commercial funding = is > the > main source of funding for future Internet research, the future of the > Internet infrastructure could be in trouble."). [Addison Phillips]=20 Incomprehensible. >=20 > You will understand that as a non-commercially funded searcher (AFRAC = is a > non-profit), I share these concerns expressed by several officials = from > different countries on different continents. [Addison Phillips]=20 People not corresponding on this list do not exist, insofar as RFC 2026 = recognizes. We can't respond to vague concerns of people we cannot = correspond with outselves. >=20 > > >> Native name of language (transcribed into ASCII): espanol de = America > > >> Latina, espanol latinoamericano > > > > > > This information misses the French name of the language. > > > >Rightly or wrongly, this information is not required by RFC 3066. = See > >page 8. >=20 > I know and this is why I note it. General consensus among the non = English > mother tongue and a broad part of educated English mother tongue = searchers > I know is that the best fit is to use English as a koine and a quick > experimentation tool due to its capacity to accept lose definitions = and > intuitive mutual rough understanding, and to use French as a reference > language. The QA comes from a simultaneous work in both languages. The > famous example of MPEG shown that MPEG convergence (radio, TV, media) > could > not have happen without a first working bridge between the English > standard > texts in French (to have a common term definition of the difference > standards) to support the further work in English and a finalisation > through duallanguage QA. [Addison Phillips]=20 But your objection was to getting the native name of the language = instead of getting French? In fact, the draft has already dealt with this issue and allows French = (or any other language) to be registered in the description field. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 07 12:16:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqYzA-00077p-E8; Thu, 07 Jul 2005 12: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 1DqYz8-00077j-SL for ltru@megatron.ietf.org; Thu, 07 Jul 2005 12:12:22 -0400 Received: from unix.megared.net.mx (megamail.megared.com.mx [200.52.207.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21891 for ; Thu, 7 Jul 2005 12:12:19 -0400 (EDT) Received: from [192.168.2.170] ([10.60.88.84]) by unix.megared.net.mx (8.11.7/8.11.7) with ESMTP id j67GBhR37998; Thu, 7 Jul 2005 11:11:45 -0500 (CDT) Message-ID: <42CD543E.1060304@megared.net.mx> Date: Thu, 07 Jul 2005 11:11:42 -0500 From: "Dylan N. Pierce" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Misha Wolf , ltru@ietf.org Subject: Re: [Ltru] Private Use Tags References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Misha, It is, in fact, the locale ID. But it would be disingenuous to present that distinction as a significant difference. Effectively, the locale ID /is/ a language ID "plus." To whit, an "extended" or "modified" language tag, used for Sun's own purposes... which is exactly what we're talking about here. According to Sun's own documentation, "The language argument is a valid ISO Language Code. These codes are the lower-case, two-letter codes as defined by ISO-639.... The country argument is a valid ISO Country Code. These codes are the upper-case, two-letter codes as defined by ISO-3166." And its purpose is so that applications can decide in what language to serve the documents (in this case, UI output). In other words, the difference between what they're doing and what we're doing is, at best, cosmetic; I imagine the Java programmers did it this way for the same reasons I have to take shortcuts in my own code: because existing language tags alone aren't sufficient for these purposes. If this new draft takes these issues into consideration, we might be able to all get back on the same page again. Dylan Misha Wolf wrote: > Dylan N. Pierce wrote: > > >>Leakage is going to happen. Sun Microsystems, for example, finds >>the third subtag to be an excellent place to include currency >>information ("es-ES-EURO"). Every copy of the JDK they've shipped >>since 1.2 has gone out that way. > > > This sounds like a locale ID, not a language ID. Does it use "-" > separators or "_"? > > 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 From ltru-bounces@lists.ietf.org Thu Jul 07 12:36:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZMG-0007vs-41; Thu, 07 Jul 2005 12:36:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZMF-0007vg-3b for ltru@megatron.ietf.org; Thu, 07 Jul 2005 12:36:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23764 for ; Thu, 7 Jul 2005 12:36:12 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqZnR-0006OH-P0 for ltru@ietf.org; Thu, 07 Jul 2005 13:04:23 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 09:36: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.1830); Thu, 7 Jul 2005 09:36:03 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Private Use Tags Date: Thu, 7 Jul 2005 09:36:02 -0700 Message-ID: Thread-Topic: [Ltru] Private Use Tags Thread-Index: AcWDDs5kNXFvOc/NRnOx2uAMv8Mf/gAAYrZw From: "Peter Constable" To: X-OriginalArrivalTime: 07 Jul 2005 16:36:03.0234 (UTC) FILETIME=[F70B9020:01C58311] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 > Dylan N. Pierce > It is, in fact, the locale ID. But it would be disingenuous to present > that distinction as a significant difference. Effectively, the locale ID > /is/ a language ID "plus." True, insofar as every locale has language as one of its constituent properties. But I believe (as others here have heard me say) that there is a definite difference. A language tag is a metadata element used to declare attributes of content wrt language variety and written form, or to request content according to those attributes; a locale ID is an API parameter used to tailor software processes, or to tag resources used to tailor those processes, wrt a variety of cultural parameters, some of which pertain to language but others of which do not. Very often, the information in a language tag is sufficient for use as a locale ID, but not in the general case. > According to Sun's own documentation, "The language argument is a valid > ISO Language Code. These codes are the lower-case, two-letter codes as > defined by ISO-639.... The country argument is a valid ISO Country > Code. These codes are the upper-case, two-letter codes as defined by > ISO-3166." And its purpose is so that applications can decide in what > language to serve the documents (in this case, UI output). I haven't reviewed their implementation or documentation, but something doesn't make sense here: if the purpose of these IDs is only to select UI strings, then I wouldn't expect these IDs would ever need to include a component for currency. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 07 12:58:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZhp-0004J2-K2; Thu, 07 Jul 2005 12:58:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqZho-0004It-Ci for ltru@megatron.ietf.org; Thu, 07 Jul 2005 12:58:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25525 for ; Thu, 7 Jul 2005 12:58:29 -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.43) id 1Dqa91-0000Up-6I for ltru@ietf.org; Thu, 07 Jul 2005 13:26: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 Jul 2005 10:00: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] Private Use Tags Date: Thu, 7 Jul 2005 10:00:04 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C014F4C@irvmbxw01.quest.com> Thread-Topic: [Ltru] Private Use Tags Thread-Index: AcWDDs5kNXFvOc/NRnOx2uAMv8Mf/gAAYrZwAAET7TA= From: "Addison Phillips" To: "Peter Constable" , X-OriginalArrivalTime: 07 Jul 2005 17:00:09.0102 (UTC) FILETIME=[54D982E0:01C58315] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Note that these IDs do not appear outside of Java, e.g. in = Accept-Language headers and the like. They are limited to Java internal = usage (which creates problems when negotiating the locale over the = Internet--there is work underway at W3C I18N Core Working Group on this = problem, which is a separate problem from the language tag 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 Peter Constable > Sent: 2005?7?7? 9:36 > To: ltru@ietf.org > Subject: RE: [Ltru] Private Use Tags >=20 > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On Behalf Of > > Dylan N. Pierce >=20 >=20 > > It is, in fact, the locale ID. But it would be disingenuous to = present > > that distinction as a significant difference. Effectively, the = locale > ID > > /is/ a language ID "plus." >=20 > True, insofar as every locale has language as one of its constituent > properties. But I believe (as others here have heard me say) that = there > is a definite difference. A language tag is a metadata element used to > declare attributes of content wrt language variety and written form, = or > to request content according to those attributes; a locale ID is an = API > parameter used to tailor software processes, or to tag resources used = to > tailor those processes, wrt a variety of cultural parameters, some of > which pertain to language but others of which do not. Very often, the > information in a language tag is sufficient for use as a locale ID, = but > not in the general case. >=20 >=20 > > According to Sun's own documentation, "The language argument is a > valid > > ISO Language Code. These codes are the lower-case, two-letter codes = as > > defined by ISO-639.... The country argument is a valid ISO Country > > Code. These codes are the upper-case, two-letter codes as defined by > > ISO-3166." And its purpose is so that applications can decide in = what > > language to serve the documents (in this case, UI output). >=20 > I haven't reviewed their implementation or documentation, but = something > doesn't make sense here: if the purpose of these IDs is only to select > UI strings, then I wouldn't expect these IDs would ever need to = include > a component for currency. >=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 Thu Jul 07 13:30:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqaCK-0004rS-9U; Thu, 07 Jul 2005 13:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqaCI-0004on-En for ltru@megatron.ietf.org; Thu, 07 Jul 2005 13:30:02 -0400 Received: from unix.megared.net.mx (megamail.megared.com.mx [200.52.207.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27807 for ; Thu, 7 Jul 2005 13:29:58 -0400 (EDT) Received: from [192.168.2.170] ([10.60.88.84]) by unix.megared.net.mx (8.11.7/8.11.7) with ESMTP id j67HTSP54202 for ; Thu, 7 Jul 2005 12:29:29 -0500 (CDT) Message-ID: <42CD6675.9040400@megared.net.mx> Date: Thu, 07 Jul 2005 12:29:25 -0500 From: "Dylan N. Pierce" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ltru@ietf.org Subject: Re: [Ltru] Private Use Tags References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 [From Peter Constable:] > [I]f the purpose of these IDs is only to select > UI strings, then I wouldn't expect these IDs would ever need to > include a component for currency. If the UI string includes a currency, a percent, a number with a decimal point or thousands separators, or regionally ambiguous language--any of the things that knowing what language something is written in helps us navigate--then it would need that information. > A language tag is a metadata element used to > declare attributes of content wrt language variety and written form, or > to request content according to those attributes; a locale ID is an API > parameter used to tailor software processes, or to tag resources used to > tailor those processes, wrt a variety of cultural parameters, some of > which pertain to language but others of which do not. Very often, the > information in a language tag is sufficient for use as a locale ID, but > not in the general case. If this is true--and I believe that it is--then it speaks well to the topic under discussion. After all, if two things serve pretty much the same purpose, but one of them does /more/, then basically, you have a subclass. And that's exactly what we're looking at here: using a universal tag, and being able to have a section of it for your own private subclass. Again, this would get everyone back on the same page. After all, Sun didn't have to use ISO values; they could have invented their own private system from scratch. They didn't because (1) why duplicate work that's already done? and (2) those values /almost/--but not qute--were all they needed. [From Addison Phillips:] > They are limited to Java internal usage (which creates problems when > negotiating the locale over the Internet--there is work underway at > W3C I18N Core Working Group on this problem, which is a separate > problem from the language tag problem). So then tags with defined extensibility could additionally solve the problem of negotiating the locale over the Internet? That doesn't sound like a separate problem. It sounds like (and please forgive me; I'm not trying to make enemies) perhaps some organizational notions of conceptual purity--"This is language and this is not, this is our jurisdiction and this is not!"--is causing us to divide essentially one practical problem into several provincial miniproblems that are not being solved in terms of each other, as they should be. But if this is the case--things are already in their boxes--then the question becomes, "Is it worth trying to argue outside the box?" The answer to that question is usually no, unless you're friends with the CEO. Or married to his daughter. Dylan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 07 14: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 1DqatF-0003UY-UP; Thu, 07 Jul 2005 14:14:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqatE-0003US-3Y for ltru@megatron.ietf.org; Thu, 07 Jul 2005 14:14:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00992 for ; Thu, 7 Jul 2005 14:14:21 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqbKQ-0000i3-Ug for ltru@ietf.org; Thu, 07 Jul 2005 14:42:32 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Jul 2005 11:14: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.1830); Thu, 7 Jul 2005 11:14:12 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Private Use Tags Date: Thu, 7 Jul 2005 11:14:11 -0700 Message-ID: Thread-Topic: [Ltru] Private Use Tags Thread-Index: AcWDGaOmn+ryNAVNTEOfMLtnUs/8DQAAyS4g From: "Peter Constable" To: X-OriginalArrivalTime: 07 Jul 2005 18:14:12.0230 (UTC) FILETIME=[AD290A60:01C5831F] X-Spam-Score: 0.3 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 > Dylan N. Pierce > > [I]f the purpose of these IDs is only to select > > UI strings, then I wouldn't expect these IDs would ever need to > > include a component for currency. >=20 > If the UI string includes a currency, a percent, a number with a decimal > point or thousands separators, or regionally ambiguous language--any of > the things that knowing what language something is written in helps us > navigate--then it would need that information. All that is saying is that knowing the language helps pick a locale that is likely to be appropriate, which I don't question. But you described the API as selecting UI language, which should not be the same as selecting a locale. I'm not aware of any scenario in which selecting the UI language should require specifying a currency. =20 > > A language tag is a metadata element... > If this is true--and I believe that it is--then it speaks well to the > topic under discussion. After all, if two things serve pretty much the > same purpose, but one of them does /more/, then basically, you have a > subclass. No disagreement. > And that's exactly what we're looking at here: using a > universal tag, and being able to have a section of it for your own > private subclass. But I wouldn't suggest that that should be done for locale IDs. At least, there are valid scenarios, particularly in relation to Web services, in which there is a need to interchange locale IDs publicly. > > They are limited to Java internal usage (which creates problems when > > negotiating the locale over the Internet--there is work underway at > > W3C I18N Core Working Group on this problem, which is a separate > > problem from the language tag problem). >=20 > So then tags with defined extensibility could additionally solve the > problem of negotiating the locale over the Internet? That doesn't sound > like a separate problem. The key factor that creates a difference is the purpose: extensions for locale IDs needed in public interchange versus extensions for private-use. > It sounds like (and please forgive me; I'm not > trying to make enemies) perhaps some organizational notions of > conceptual purity--"This is language and this is not, this is our > jurisdiction and this is not!"--is causing us to divide essentially one > practical problem into several provincial miniproblems that are not > being solved in terms of each other, as they should be. I can't speak for others; for my part, I think that RFC 3066bis needs to be designed for a primary set of applications, which include many for which RFC 3066 is already used, and those applications involve *language* identification, not *locale* identification. While it would be appropriate in some Web application to pass locale information, e.g. www.localtrains.com/schedule.asp?date=3D2005-07-07&loc=3Den-us_24hr it would *not* be appropriate to put locale information (i.e. information that goes beyond strictly language identification) in the xml:lang attribute of some XML entity as in Thus, I very much think we should limit RFC 3066bis to *language* tags, and look to some derivative specification or protocols (possibly an RFC 3066bis extension) to use 3066bis tags as one building block in creating locale IDs. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 07 14:52:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqbUM-0005H5-4F; Thu, 07 Jul 2005 14:52:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqbUL-0005Go-2F for ltru@megatron.ietf.org; Thu, 07 Jul 2005 14:52:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08091 for ; Thu, 7 Jul 2005 14:52:43 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqbvY-0006eH-Up for ltru@ietf.org; Thu, 07 Jul 2005 15:20: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 j67IqRNc008845; Thu, 7 Jul 2005 14:52:28 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Thu, 7 Jul 2005 14:52:27 -0400 Date: Thu, 7 Jul 2005 14:52:27 -0400 From: "John.Cowan" To: "Dylan N. Pierce" Subject: Re: [Ltru] Private Use Tags Message-ID: <20050707185227.GD876@NYCMJCOWA2> References: <42CD543E.1060304@megared.net.mx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42CD543E.1060304@megared.net.mx> User-Agent: Mutt/1.4.2.1i 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 Dylan N. Pierce scripsit: > According to Sun's own documentation, "The language argument is a valid > ISO Language Code. These codes are the lower-case, two-letter codes as > defined by ISO-639.... The country argument is a valid ISO Country > Code. These codes are the upper-case, two-letter codes as defined by > ISO-3166." And its purpose is so that applications can decide in what > language to serve the documents (in this case, UI output). In other > words, the difference between what they're doing and what we're doing > is, at best, cosmetic; In fact not; the difference is deep and conceptual. The country subtag in a locale ID serves an entirely different purpose from the one in a language tag. Rather than meaning "The variant of the language commonly used in country X", it means "Using the various notational and cultural conventions of country X". For example, the Mohawk language (ISO 639-2 code 'moh') is spoken on both sides of the U.S.-Canadian border, but does not come in national variants "moh-US" and "moh-CA"; though well-formed and valid per RFC 3066, these tags are not useful. However, for someone using a computer in Mohawk, the locale IDs "moh_US" and "moh_CA" are eminently useful: the first signals a desire for U.S. dollars and Fred Flintstone units, the second a desire for Canadian dollars and metric units. Similarly, "en-DE" does not make much sense, as there is no German national variant of the English language (jokes about "Ve haf vays!" aside), but "en_DE" represents using the English language in a German national context, with euros and metric units and German-style postal addresses. Indeed, in principle there is no reason why a locale ID like "en-us_DE" can't be useful: this says that the context is still euros, etc., but the dictionary now contains specifically American English. -- 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@lists.ietf.org Thu Jul 07 15:50:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqcNv-0005Hy-JU; Thu, 07 Jul 2005 15:50:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqcNn-00057B-1r; Thu, 07 Jul 2005 15:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13880; Thu, 7 Jul 2005 15:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqcp1-0004eV-L9; Thu, 07 Jul 2005 16:18:12 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DqcNl-0001H8-Aa; Thu, 07 Jul 2005 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 07 Jul 2005 15:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-initial-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 : Initial Language Subtag Registry Author(s) : D. Ewell Filename : draft-ietf-ltru-initial-01.txt Pages : 116 Date : 2005-7-7 This memo defines the initial contents of the Language Subtag Registry specified in RFC 3066bis, "Tags for Identifying Languages." This memo does not define the permanent contents of the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-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-initial-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-initial-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-7-7123832.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-initial-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-initial-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-7123832.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 Jul 07 16:26:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqcwm-0005mo-Rn; Thu, 07 Jul 2005 16:26:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqcwl-0005m5-CU for ltru@megatron.ietf.org; Thu, 07 Jul 2005 16:26:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25863 for ; Thu, 7 Jul 2005 16:26:07 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-par.bigfish.com ([217.117.146.230] helo=mail5-par-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqdNs-0003AC-GA for ltru@ietf.org; Thu, 07 Jul 2005 16:54:18 -0400 Received: from mail5-par.bigfish.com (localhost.localdomain [127.0.0.1]) by mail5-par-R.bigfish.com (Postfix) with ESMTP id 0481740AB7B for ; Thu, 7 Jul 2005 20:25:46 +0000 (UTC) X-BigFish: VP Received: by mail5-par (MessageSwitch) id 1120767945972521_28384; Thu, 7 Jul 2005 20:25:45 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail5-par.bigfish.com (Postfix) with ESMTP id C467D40A7A7 for ; Thu, 7 Jul 2005 20:25:45 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005070713094425:2940 ; Thu, 7 Jul 2005 13:09:44 -0700 To: ltru@ietf.org Subject: RE: [Ltru] Re: does the Draft gives all the guidelinesrequired by the Registry MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Thu, 7 Jul 2005 12:59:14 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/07/2005 12:59:14, Serialize complete at 07/07/2005 12:59:14, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/07/2005 01:09:44 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/07/2005 01:33:19 PM, Serialize complete at 07/07/2005 01:33:19 PM Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) 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 I did not initially respond to Jefsey's e-mail because some of the text that concerned him was not mine (and will be removed) and I did not feel that arguing with these points with someone who questions the validity of my native language would be productive. Since you all responded ... my position is this: * I have a need for a complete set of standardized language tags for subtitled and dubbed product and find RFC 3066 to be the best existing solution. * I did a gap analysis to see what was missing from the RFC 3066 registrations and submitted registrations for the tags I felt I needed that were not already registered. My source data included language lists from studios other than Sony, and language data from AGICOA, an organization headquartered in French-speaking Switzerland. * I followed the current registration procedure, which calls for things like the native name of the language and specifically does NOT call for the French name of the language. To enter the French name would have been a gross error according to the registration procedure. To argue such things in the context of a specific registration is confusing. * Any concerns Jefsey might have that I am part of Peter and Addison's secret kabal that wants to rule the world one language at a time are unfounded. I do not propose myself as the ruler of all that is Latin American Spanish. Nor does Sony Pictures. I am simply entering my name and e-mail so that anyone who needs further information about the registration can contact me. I do not use my personal e-mail address for such purposes. The people who need these tags are most often not authorities on individual languages. They are people who need to describe whole sets of languages and linguistic concepts. I do what I can to increase the breadth of my linguistic knowledge through my work at Sony Pictures, personal research, and my involvement on this list. That said, representation of language data is just one of many standardization issues I face. Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 07 20:13:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqgRw-0003or-Ja; Thu, 07 Jul 2005 20:10:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqgRq-0003oI-0L for ltru@megatron.ietf.org; Thu, 07 Jul 2005 20:10:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18078 for ; Thu, 7 Jul 2005 20:10:28 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqgt7-0001ZU-Px for ltru@ietf.org; Thu, 07 Jul 2005 20:38:42 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqgRn-0000Ry-O4; Thu, 07 Jul 2005 17:10:28 -0700 Message-Id: <6.2.1.2.2.20050707223847.04022bc0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 07 Jul 2005 22:53:57 +0200 To: Karen_Broome@spe.sony.com, ltru@ietf.org From: r&d afrac Subject: RE: [Ltru] Re: does the Draft gives all the guidelinesrequired by the Registry 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 - afrac.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 21:59 07/07/2005, Karen_Broome@spe.sony.com wrote: >I did not initially respond to Jefsey's e-mail because some of the text >that concerned him was not mine (and will be removed) and I did not feel >that arguing with these points with someone who questions the validity of >my native language would be productive. ????? could you explain that ???? thank you. >* Any concerns Jefsey might have that I am part of Peter and Addison's >secret kabal that wants to rule the world one language at a time are >unfounded. ?????? You have never been considered, except because you were considered and I documented why you should not. ?????? Secret Kabal? I think Unicode is documented commercial consortium (I am a paying member of) whose members have legitimate interests. The only difficulty is - as documented by IAB - these commercial interests should seriously pay attention to common and public interest and to other types of traffic rather than exclusively to their own propositions. All this is perfectly documented in RFC 3869 (this is its main thesis according to its authors). The ways of this type of lack of attention are documented in RFC 3774. I only suggest that everyone accepts these analysis of the IETF, as normal part of the culture of an IETF WG, and that we can work together in a normal manner. I also suggest that this kind of ad hominem does not help. >I do not propose myself as the ruler of all that is Latin >American Spanish. Nor does Sony Pictures. I am simply entering my name and >e-mail so that anyone who needs further information about the registration >can contact me. I do not use my personal e-mail address for such purposes. Once again, you are not concerned by all this. This mail and your confusion are only the proof that the current procedure (which not the one of the Draft) is inadequate. Even in misreading someone else positions, Karen should never have felt concerned. The best way to make sure of that is never to mention the name of the requested. I submit that this give more liberty to everyone to support or to oppose. >The people who need these tags are most often not authorities on >individual languages. They are people who need to describe whole sets of >languages and linguistic concepts. Yes. This is why I say that if we have to come to qualify the requesters they should be authoritative or users. But I prefer anonymous proponent and discussion over the advisability (confusion, impacts, etc.) of the registration. > I do what I can to increase the breadth >of my linguistic knowledge through my work at Sony Pictures, personal >research, and my involvement on this list. Be thanked for that. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 07 20:13:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqgRs-0003oa-8x; Thu, 07 Jul 2005 20:10:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqgRp-0003oH-Nt for ltru@megatron.ietf.org; Thu, 07 Jul 2005 20:10:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18075 for ; Thu, 7 Jul 2005 20:10:27 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqgt7-0001ZN-3L for ltru@ietf.org; Thu, 07 Jul 2005 20:38:41 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqgRW-0000Ry-4v; Thu, 07 Jul 2005 17:10:22 -0700 Message-Id: <6.2.1.2.2.20050707175801.05037630@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Jul 2005 02:10:00 +0200 To: "Addison Phillips" , From: r&d afrac Subject: RE: [Ltru] please, get real! In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C014E56@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C014E56@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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 Addison, At 17:00 07/07/2005, Addison Phillips wrote: >To remove the RFC 3066 registry from IANA would require a new RFC, such as >we are working on here, so... Yes. This what I am talking about. As explained, RFC 2860 is an MoU between ICANN, IANA and IETF. This MoU is in limbo because no one knows if ICANN still has the capacity to sign it. Legally speaking the IANA is an USG property, contracted on a yearly basis to ICANN. There are serious legal considerations about the right of the USG to give it away without a Bill (General Accounting Office, Congress). The USG said they did not want to give it away nor probably to continue to lease it, but to keep it - ICANN assisting. This is up to the ICANN lawyers to see into it and USG to explain/negotiate at the WSIS. The key links are under http://nicso.org/iana.htm I document the reason why for four years. I ran a two year test bed including it and started the AFRAC exploration under public and private interests supervision: there is no way USA security and identity can be run by foreign undetermined interests, no more than France security and identity can be run by the USA or lose foreign undetermined interests. And the same is true for every other nation and culture (look at Tamils). The US position was triggered by the Internet balkanisation (and USA adds to it) which results from the IETF IDN propositions and from this Draft. It lead to a DNS split because IDNs are not accepted (already three non legacy TLDs resolving in the top zone). It will lead to a IANA split, this Draft being the trigger, by countries and cultures not accepting to be subject to an US Registry nor to foreign decisions, appreciations, definitions, correlations other than the one they accepted/decided through ISO. The immediate solution of compromise I propose is simple: that ISO 3166 and ISO 639 issues are understood as "name and numbers" issues and are therefore temporarily put into the ICANN part of the IANA (cf. RFC 2860), under the control of the GAC. This will permit countries to be involved when their ISO 3166 code is affected. Then to remove that Registry from the US IANA, to transfer a copy of it to the ICANN Common Reference Center, as well as to AFRAC and other national CRCs round the world, under an ISO 11179 commonly designed intergovernance. Other solutions will probably be discussed in different fora (as suggested by the US Statement of Principles). I do not expect this to be seriously addressed before the Tunis meeting. But preparation has started. >For the remainder of the issues in your note below, obviously no one on >this list is going to convince you to change your position and at least a >number of us are not going to change our positions (that we have done the >right things with the draft). I suggest we agree to disagree and move >along in the process. Unfortunately this is not possible. As I indicated it many times: I only object one word in your document ("replace RFC 3066" instead of "complement RFC 3066") but it makes that I cannot give up and that your Draft cannot be accepted. Or split your Drafts in another way: what is generic for the Registry management in terms of metamodel in a BCP 47, and regroup everything which concerns your particular format and its filters in the second document. Please understand your choice: - either you want a US Registry, by a US IANA managed by a US ICANN (this is the US Statement of Principles, the US law and the increasing international understanding ). Do not expect a return to the position ante: because everything is based on trust. No one would trust the US if they changed their mind again. Also the US attitude is the correct one: all the other Govs share the obligation to do the same and the USA said they will help. This has a name "digital umbrella", if you add culture to it, it is "e-colonisation"; the counter proposition is partition if organised, balkanisation otherwise. My own proposition is compartmentalisation, for risks and interference containment, but network continuity. CRCs are a key element of the needed network new granularity. We created AFRAC for that. - or you ultimately want a global distributed register for the whole internet (all the transitions are possible). I will then be involved since I am the only one having worked for four years on its preparation, having a team and ties assisting it, being on the board of organisations which will be influent there, specifying and planning to have a working server by September, etc.. If I am in this WG it is to gain the best knowledge of the Registry Language issue and Multilingual Internet, and to find the best solution for all through an RFC or a WSIS declaration. I think this should be also your target. What is sad is that I will have a running code, while you will still be blocked by a one single word. The IANA/ICANN situation where a single person could decide about a worldwide IANA registry under the control of a few allies is coming to an end. I cannot document what will be the short term future because we start discussing it, and that the people involved are not necessarily those who used to be involved up to now. But I expect that by Septembre/Novembre we will know far better, technically and politically. I can however tell you from the past that this should go quickly enough (one or two years) once States becomes involved. I think I cannot be clearer? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 07 20:20:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqgbS-0001N5-PP; Thu, 07 Jul 2005 20: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 1DqgbQ-0001Mz-OZ for ltru@megatron.ietf.org; Thu, 07 Jul 2005 20:20:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18564 for ; Thu, 7 Jul 2005 20:20:23 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqh2h-00024V-MH for ltru@ietf.org; Thu, 07 Jul 2005 20:48:36 -0400 Received: from h-68-165-4-55.noclli.covad.net ([68.165.4.55] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqgbN-00041w-00 for ltru@ietf.org; Thu, 07 Jul 2005 20:20:22 -0400 Message-ID: <008d01c58353$6969e900$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <42CD543E.1060304@megared.net.mx> <20050707185227.GD876@NYCMJCOWA2> Subject: Re: [Ltru] Private Use Tags Date: Thu, 7 Jul 2005 17:24: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: 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 Hi - > From: "John.Cowan" > To: "Dylan N. Pierce" > Cc: > Sent: Thursday, July 07, 2005 11:52 AM > Subject: Re: [Ltru] Private Use Tags ... This discussion of how, despite surface similarities, language tags and locale identifiers are very different things, though educational, is diverting us from a much more important question that Dylan raised when he wrote: | But given what you've explained to me, I declare very firmly: we should | stake out the "policy question" explicitly. Either we /do/ want to | include private use tags, at which point we should set up a mechanism to | ensure that the private use tags themselves do (as you put it) "promote | open access, promote consistent tagging and promote interoperability" | (by handling leakage and providing a way to know which private tag is | which)... or we do /not/ really want to encourage private use tags, | which we could do more consistently by simply saying, "These tags cover | language, dialect and script, and nothing more. Anything over and above | this should be handled outside the tag," and eliminate private use tags | completely. So, unless there is a specific proposal for text that will further clarify that language tags should not be confused with locales, let's get back to Dylan's question so we can wrap things up. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 07 21:04:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqhIW-0002iP-Ux; Thu, 07 Jul 2005 21:04:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqhIU-0002hx-Tf for ltru@megatron.ietf.org; Thu, 07 Jul 2005 21:04:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21924 for ; Thu, 7 Jul 2005 21:04:52 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqhjl-0006c3-RA for ltru@ietf.org; Thu, 07 Jul 2005 21:33:07 -0400 Received: from h-68-165-4-55.noclli.covad.net ([68.165.4.55] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqhIR-0002X1-00 for ltru@ietf.org; Thu, 07 Jul 2005 21:04:51 -0400 Message-ID: <00a001c58359$a14e04e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C014E56@irvmbxw01.quest.com> <6.2.1.2.2.20050707175801.05037630@mail.afrac.org> Subject: Re: [Ltru] please, get real! Date: Thu, 7 Jul 2005 18:09:02 -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: 21c69d3cfc2dd19218717dbe1d974352 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: "r&d afrac" > To: "Addison Phillips" ; > Sent: Thursday, July 07, 2005 5:10 PM > Subject: RE: [Ltru] please, get real! ... > The immediate solution of compromise I propose is simple: that ISO 3166 and > ISO 639 issues are understood as "name and numbers" issues and are > therefore temporarily put into the ICANN part of the IANA (cf. RFC 2860), > under the control of the GAC. This will permit countries to be involved > when their ISO 3166 code is affected. Then to remove that Registry from the > US IANA, to transfer a copy of it to the ICANN Common Reference Center, as > well as to AFRAC and other national CRCs round the world, under an ISO > 11179 commonly designed intergovernance. This discussion does not belong here. The administration of ISO 3166 and ISO 639 by definition belongs to ISO, and the ltru WG in the IETF is not ISO. ... > Unfortunately this is not possible. As I indicated it many times: I only > object one word in your document ("replace RFC 3066" instead of "complement > RFC 3066") but it makes that I cannot give up and that your Draft cannot be > accepted. This is what we in the IETF call a "non-starter". The working group charter is abundantly clear in directing us to produce "a successor to RFC 3066". Not a "complement". A successor. > Or split your Drafts in another way: what is generic for the Registry > management in terms of metamodel in a BCP 47, and regroup everything which > concerns your particular format and its filters in the second document. ... This is not what we were chartered to do. We were chartered to produce two documents: the first is "a successor to RFC 3066" and the second document will "describe matching algorithms". The mechanics of populating the registry required a third document, but the ADs saw this as not requiring a charter update. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 00:40:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqkfa-0002qH-Lg; Fri, 08 Jul 2005 00:40:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqkfV-0002pk-Ah for ltru@megatron.ietf.org; Fri, 08 Jul 2005 00:40:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04889 for ; Fri, 8 Jul 2005 00:40:50 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dql6m-00019x-Dg for ltru@ietf.org; Fri, 08 Jul 2005 01:09:07 -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 j684eYsf228752 for ; Fri, 8 Jul 2005 00:40:34 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j684eYcC195644 for ; Thu, 7 Jul 2005 22:40:34 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j684eXRd022850 for ; Thu, 7 Jul 2005 22:40:33 -0600 Received: from markdavis (sig-9-48-124-202.mts.ibm.com [9.48.124.202]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j684eW77022780; Thu, 7 Jul 2005 22:40:33 -0600 Message-ID: <01e801c58377$2cabf160$6501a8c0@sanjose.ibm.com> From: "Mark Davis" To: "John.Cowan" , "Dylan N. Pierce" References: <42CD543E.1060304@megared.net.mx> <20050707185227.GD876@NYCMJCOWA2> Subject: Re: [Ltru] Private Use Tags Date: Thu, 7 Jul 2005 21:29:01 -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.1506 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j684eYsf228752 X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 I do not think that this line is at all as clear as you would think. The notion of a locale is very fuzzy: most of the items that people associate with it, other than language, are merely guesses. The currency of a transaction is often completely independent of the user's location; I cou= ld be buying something on the web and pay euros, or pounds, or dollars, no matter where I live. The same goes for timezones, even units. (We all remember the rocket that failed because two people in the same country we= re interpreting a number as being in different units). It is a fairly rough approximation to assume the values of these from seeing en_UK (or en-UK).= Of course, that may be all that the information that someone has, but you ca= n't read into it more than a good guess. And other areas get fuzzy as well. I= s sort order a language or a locale issue? The language is clearly a core part of what people mean by 'locale', and anything beyond that is pretty speculative. A real locale id shades off i= nto something more like a bundle of preferences. But this is all pretty off-topic; I really hope we can focus on just the items we need to finish off to get this thing to last call. =E2=80=8EMark ----- Original Message -----=20 From: "John.Cowan" To: "Dylan N. Pierce" Cc: Sent: Thursday, July 07, 2005 11:52 Subject: Re: [Ltru] Private Use Tags > Dylan N. Pierce scripsit: > > > According to Sun's own documentation, "The language argument is a val= id > > ISO Language Code. These codes are the lower-case, two-letter codes a= s > > defined by ISO-639.... The country argument is a valid ISO Country > > Code. These codes are the upper-case, two-letter codes as defined by > > ISO-3166." And its purpose is so that applications can decide in what > > language to serve the documents (in this case, UI output). In other > > words, the difference between what they're doing and what we're doing > > is, at best, cosmetic; > > In fact not; the difference is deep and conceptual. The country subtag > in a locale ID serves an entirely different purpose from the one in a > language tag. Rather than meaning "The variant of the language commonl= y > used in country X", it means "Using the various notational and cultural > conventions of country X". > > For example, the Mohawk language (ISO 639-2 code 'moh') is spoken on > both sides of the U.S.-Canadian border, but does not come in national > variants "moh-US" and "moh-CA"; though well-formed and valid per RFC > 3066, these tags are not useful. However, for someone using a computer > in Mohawk, the locale IDs "moh_US" and "moh_CA" are eminently useful: > the first signals a desire for U.S. dollars and Fred Flintstone units, > the second a desire for Canadian dollars and metric units. > > Similarly, "en-DE" does not make much sense, as there is no German > national variant of the English language (jokes about "Ve haf > vays!" aside), but "en_DE" represents using the English language in a > German national context, with euros and metric units and German-style > postal addresses. > > Indeed, in principle there is no reason why a locale ID like "en-us_DE" > can't be useful: this says that the context is still euros, etc., > but the dictionary now contains specifically American English. > > --=20 > Newbies always ask: John Cowan > "Elements or attributes? http://www.ccil.org/~co= wan > Which will serve me best?" http://www.reutershealth.com > Those who know roar like lions; jcowan@reutershealth.co= m > Wise hackers smile like tigers. --a tanka, or exten= ded haiku > > _______________________________________________ > 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 Jul 08 00:55:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqktT-0001hy-DS; Fri, 08 Jul 2005 00:55:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqktR-0001ht-Ip for ltru@megatron.ietf.org; Fri, 08 Jul 2005 00:55:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05646 for ; Fri, 8 Jul 2005 00:55:13 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqlKl-0002KL-9h for ltru@ietf.org; Fri, 08 Jul 2005 01:23:31 -0400 Received: from h-68-165-6-127.noclli.covad.net ([68.165.6.127] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqktL-0007Xd-00 for ltru@ietf.org; Fri, 08 Jul 2005 00:55:11 -0400 Message-ID: <001c01c58379$cf5eb8a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <42CD543E.1060304@megared.net.mx><20050707185227.GD876@NYCMJCOWA2> <01e801c58377$2cabf160$6501a8c0@sanjose.ibm.com> Subject: Re: [Ltru] Private Use Tags Date: Thu, 7 Jul 2005 21:59: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: 9a2be21919e71dc6faef12b370c4ecf5 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 take off-topic discussions elsewhere. As you yourself write: "I really hope we can focus on just the items we need to finish off to get this thing to last call." Randy, ltru co-chair ----- Original Message ----- From: "Mark Davis" To: "John.Cowan" ; "Dylan N. Pierce" Cc: Sent: Thursday, July 07, 2005 9:29 PM Subject: Re: [Ltru] Private Use Tags I do not think that this line is at all as clear as you would think. The notion of a locale is very fuzzy: most of the items that people associate with it, other than language, are merely guesses. The currency of a transaction is often completely independent of the user's location; I could be buying something on the web and pay euros, or pounds, or dollars, no matter where I live. The same goes for timezones, even units. (We all remember the rocket that failed because two people in the same country were interpreting a number as being in different units). It is a fairly rough approximation to assume the values of these from seeing en_UK (or en-UK). Of course, that may be all that the information that someone has, but you can't read into it more than a good guess. And other areas get fuzzy as well. Is sort order a language or a locale issue? The language is clearly a core part of what people mean by 'locale', and anything beyond that is pretty speculative. A real locale id shades off into something more like a bundle of preferences. But this is all pretty off-topic; I really hope we can focus on just the items we need to finish off to get this thing to last call. ?Mark ----- Original Message ----- From: "John.Cowan" To: "Dylan N. Pierce" Cc: Sent: Thursday, July 07, 2005 11:52 Subject: Re: [Ltru] Private Use Tags > Dylan N. Pierce scripsit: > > > According to Sun's own documentation, "The language argument is a valid > > ISO Language Code. These codes are the lower-case, two-letter codes as > > defined by ISO-639.... The country argument is a valid ISO Country > > Code. These codes are the upper-case, two-letter codes as defined by > > ISO-3166." And its purpose is so that applications can decide in what > > language to serve the documents (in this case, UI output). In other > > words, the difference between what they're doing and what we're doing > > is, at best, cosmetic; > > In fact not; the difference is deep and conceptual. The country subtag > in a locale ID serves an entirely different purpose from the one in a > language tag. Rather than meaning "The variant of the language commonly > used in country X", it means "Using the various notational and cultural > conventions of country X". > > For example, the Mohawk language (ISO 639-2 code 'moh') is spoken on > both sides of the U.S.-Canadian border, but does not come in national > variants "moh-US" and "moh-CA"; though well-formed and valid per RFC > 3066, these tags are not useful. However, for someone using a computer > in Mohawk, the locale IDs "moh_US" and "moh_CA" are eminently useful: > the first signals a desire for U.S. dollars and Fred Flintstone units, > the second a desire for Canadian dollars and metric units. > > Similarly, "en-DE" does not make much sense, as there is no German > national variant of the English language (jokes about "Ve haf > vays!" aside), but "en_DE" represents using the English language in a > German national context, with euros and metric units and German-style > postal addresses. > > Indeed, in principle there is no reason why a locale ID like "en-us_DE" > can't be useful: this says that the context is still euros, etc., > but the dictionary now contains specifically American English. > > -- > 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 > > _______________________________________________ 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 Jul 08 01:45:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqlfY-000222-QB; Fri, 08 Jul 2005 01:45:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqlfX-00021K-Ew for ltru@megatron.ietf.org; Fri, 08 Jul 2005 01:44:59 -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 BAA08186 for ; Fri, 8 Jul 2005 01:44: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 <20050708054416.EYCL24042.mta11.adelphia.net@DEWELL> for ; Fri, 8 Jul 2005 01:44:16 -0400 Message-ID: <009201c58380$07af2ae0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 7 Jul 2005 22:43: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 Cc: Subject: [Ltru] Re: I-D ACTION:draft-ietf-ltru-initial-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 The introductory paragraph in Section 3 says of the initial registry contents: "Leading horizontal whitespace indicates a continued line in the record-jar format, and must not be deleted." Unfortunately, the RFC process inserts three spaces before every line in the registry (plain text version only, not HTML). I'm concerned that someone might infer that these spaces should be retained, which would be a Bad Thing. All lines in a record-jar file, except continuation lines, must begin with a non-space. Therefore, I propose amending this sentence as follows: "Leading horizontal whitespace relative to the 'File-Date' line indicates a continued line in the record-jar format, and must not be deleted." Comments? -- 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 Fri Jul 08 01:47:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqliE-00033w-VH; Fri, 08 Jul 2005 01: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 1DqliA-000306-Bn for ltru@megatron.ietf.org; Fri, 08 Jul 2005 01:47:44 -0400 Received: from unix.megared.net.mx (megamail.megared.com.mx [200.52.207.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08386 for ; Fri, 8 Jul 2005 01:47:35 -0400 (EDT) Received: from [192.168.2.170] ([10.60.88.84]) by unix.megared.net.mx (8.11.7/8.11.7) with ESMTP id j685ksb11497; Fri, 8 Jul 2005 00:47:04 -0500 (CDT) Message-ID: <42CE134B.1000009@megared.net.mx> Date: Fri, 08 Jul 2005 00:46:51 -0500 From: "Dylan N. Pierce" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn , ltru@ietf.org Subject: Re: [Ltru] Private Use Tags References: <42CD543E.1060304@megared.net.mx> <20050707185227.GD876@NYCMJCOWA2> <008d01c58353$6969e900$7f1afea9@oemcomputer> In-Reply-To: <008d01c58353$6969e900$7f1afea9@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 [Randy Presuhn writes:] > This discussion of how, despite surface similarities, language > tags and locale identifiers are very different things, though > educational, is diverting us from a much more important question > that Dylan raised when he wrote: > > | But given what you've explained to me, I declare very firmly: we should > | stake out the "policy question" explicitly. Either we /do/ want to > | include private use tags, at which point we should set up a mechanism to > | ensure that the private use tags themselves do (as you put it) "promote > | open access, promote consistent tagging and promote interoperability" > | (by handling leakage and providing a way to know which private tag is > | which)... or we do /not/ really want to encourage private use tags, > | which we could do more consistently by simply saying, "These tags cover > | language, dialect and script, and nothing more. Anything over and above > | this should be handled outside the tag," and eliminate private use tags > | completely. > > So, unless there is a specific proposal for text that will further clarify that > language tags should not be confused with locales, let's get back to > Dylan's question so we can wrap things up. > > Randy, ltru co-chair To keep us on topic: Given the suggestion that originally brought me here, and the issues that unfolded from it, I'd have to agree that Randy is correct, and this is what it boils down to. We're trying to nail down a specification here that, in addition to fulfilling the mandate given, will also have the added benefit of actually being /used/ by the people who need it. I'm sympathetic to a mandate, and I certainly do not want to derail the move toward final call (remember, I /want/ this specification to pass). But this specification is either doing, "Just this," or it's doing, "This, and more." And I'm happy either way... But if it's doing "Just this," then let's put our money where our mouths are and say, "Just this." We don't need private use tags at all if we are in agreement that corollary information, no matter how closely related, should be handled outside the tag and, as Randy notes, we shouldn't encourage the twisting of the tag by saying, "Here's your scribble area." Cripes, all of XML is the scribble area; we can afford to keep the tag clean. On the other hand, if we're doing "This, and more," then I would believe we have a responsibility to ensure that the "more" proceeds in an orderly fashion--to be read, "open, consistent and interoperable." As I said, I'm happy either way, but I don't think it's a non-issue. I suppose part of the question becomes, "How much work do we want to have to do /after/ the specification is in place?" If we eliminate the scribble area, the answer is none. If we implement a namespace, the answer is, "It becomes the registrar's problem." And if we leave a wide-open private use area, the answer becomes, "Well, it depends on what people actually do... and how much they step on each other's toes... until they come back to us demanding a solution." Needless to say, I favor one of the first two options. Dylan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 01:51:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqllm-0005Hm-90; Fri, 08 Jul 2005 01:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqllk-0005Fj-C9 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 01:51:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08533 for ; Fri, 8 Jul 2005 01:51:23 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqmD3-0007ND-NL for ltru@ietf.org; Fri, 08 Jul 2005 02:19:38 -0400 Received: from h-68-165-6-127.noclli.covad.net ([68.165.6.127] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dqllg-00047E-00 for ltru@ietf.org; Fri, 08 Jul 2005 01:51:20 -0400 Message-ID: <032701c58381$a5a98fa0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0BEB8C68@irvmbxw01.quest.com><42C1C615.C0A@xyzzy.claranet.de> <000801c57c2d$eebc0840$7f1afea9@oemcomputer> Subject: Re: [Ltru] Finishing off #1026 (Was: Re: status? last call?) Date: Thu, 7 Jul 2005 22:55:25 -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: 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 Hi - > From: "Randy Presuhn" > To: > Sent: Tuesday, June 28, 2005 3:08 PM > Subject: [Ltru] Finishing off #1026 (Was: Re: status? last call?) ... > Ok, I've re-opened 1026 until this is resolved. ... The last post I saw on this topic was Frank's posting in message http://www1.ietf.org/mail-archive/web/ltru/current/msg02459.html This post and the preceding ones did't leave me feeling the issue was truly wrapped up. Are we now content that Jersey, Guernsey, and UN region number handling in general work the way we want them to? I'd like a "hum" on this, because the last few posts in this thread leave me thinking that the drafts are less than perfectly clear. If you have think the text (in both i-ds) is ok, say so. If you think it isn't, PLEASE suggest a replacement you could live with. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 01:54:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqlor-00070t-HM; Fri, 08 Jul 2005 01:54:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqlop-00070i-Es for ltru@megatron.ietf.org; Fri, 08 Jul 2005 01:54:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08675 for ; Fri, 8 Jul 2005 01:54:31 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqmG6-0007dm-PM for ltru@ietf.org; Fri, 08 Jul 2005 02:22:47 -0400 Received: from h-68-165-6-127.noclli.covad.net ([68.165.6.127] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dqlok-00051i-00 for ltru@ietf.org; Fri, 08 Jul 2005 01:54:30 -0400 Message-ID: <033a01c58382$19101a40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <009201c58380$07af2ae0$030aa8c0@DEWELL> Subject: Horizontal whitespace (was Re: [Ltru] Re: I-D ACTION: draft-ietf-ltru-initial-01.txt) Date: Thu, 7 Jul 2005 22:58:43 -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 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: "Doug Ewell" > To: "LTRU Working Group" > Sent: Thursday, July 07, 2005 10:43 PM > Subject: [Ltru] Re: I-D ACTION:draft-ietf-ltru-initial-01.txt > > The introductory paragraph in Section 3 says of the initial registry > contents: > > "Leading horizontal whitespace indicates a continued line in the > record-jar format, and must not be deleted." > > Unfortunately, the RFC process inserts three spaces before every line in > the registry (plain text version only, not HTML). I'm concerned that > someone might infer that these spaces should be retained, which would be > a Bad Thing. All lines in a record-jar file, except continuation lines, > must begin with a non-space. > > Therefore, I propose amending this sentence as follows: > > "Leading horizontal whitespace relative to the 'File-Date' line > indicates a continued line in the record-jar format, and must not be > deleted." > > Comments? ... As a technical contributor, I like this pragmatic solution. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 02:02:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqlwr-0002sF-Qw; Fri, 08 Jul 2005 02:02:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqlwq-0002rZ-IS for ltru@megatron.ietf.org; Fri, 08 Jul 2005 02:02: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 CAA11764 for ; Fri, 8 Jul 2005 02:02: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 <20050708060214.MOOX29002.mta9.adelphia.net@DEWELL> for ; Fri, 8 Jul 2005 02:02:14 -0400 Message-ID: <009901c58382$89634a60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org> Date: Thu, 7 Jul 2005 23:01:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: status? last call? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Wed, 29 Jun 2005 04:29:28 +0200, Frank Ellermann wrote: > We better wait to see what that will be, an "initial registry" > with a separate section of obscure unregistered subtags is odd. Actually, I think it's a good idea to list the UN codes that were excluded from the registry and explain why. This has certainly been one of the more contentious aspects of the development of the initial registry. > And what unregistered ISO 3166 alpha-2 codes are "eligible for > registration" ? IMHO there should be no section about obscure > unregistered subtags in the initial registry, it's not some > kind of "unregistry". No ISO 3166 codes fall into this category, only UN numeric codes. >> The new text allows items listed as registrable to be >> registered, provided they meet other rules. > > I'm not yet convinced. IIRC we said that 830..833 must not be > registered because that would block a future GG, IM, and JE as > stated in 3.3 (8): > > | Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do > | not conflict with existing subtags of the associated type and > | whose meaning is not the same as an existing subtag of the > | same type are entered into the IANA registry as new records. Section 3.3 (11) of the registry draft now covers this. We may NOT register 830 through 833. Rather, someone is supposed to petition ISO 3166/MA to add the corresponding alpha-2 codes. (Joseph Martinez, Chief Information Officer for the MA, told me such a request would have to come from BSI.) In other words, the wording in the initial-registry draft is WRONG. Section 2, item 6 currently reads: "Items withdrawn, vacated, deprecated, modified, or otherwise judged by the LTRU working group to be questionable were not added to the ILSR. These code elements are listed in Section 4 (Omitted Code Elements), indicating that they are valid for registration using the process in [I-D.ietf-ltru-registry] but were not included initially. Listing of these code elements in this section is not a guarantee of future registration." This needs to be changed to read: "Items withdrawn, vacated, deprecated, modified, or otherwise judged by the LTRU working group to be questionable were not added to the ILSR. These code elements are listed in Section 4 (Omitted Code Elements), indicating that they are not valid for registration, except as provided in Section 3.3 (item 10E) of [I-D.ietf-ltru-registry]." There's no longer any need for the third sentence; in fact, it's almost a guarantee that they will *never* be registered. Likewise, the introductory text in Section 4 currently reads: "The following code elements from [UN-M.49] were not assigned as subtags in the initial Language Subtag Registry, but are valid candidates for registration as region subtags, using the process in [I-D.ietf-ltru-registry]:" and should be changed to: "The following code elements from [UN-M.49] were not assigned as subtags in the initial Language Subtag Registry, and may not be registered except as provided in Section 3.3 (item 10E) of [I-D.ietf-ltru-registry]:" Thanks to Frank for his diligence in following up on this issue. I will add these changes to a draft-initial-02, as well as the "leading whitespace" text mentioned in my other post. Does anyone have any other comments besides this? If not, I think draft-initial-02 will be just about ready for Last Call. -- 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 Fri Jul 08 02:21:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqmF0-0003fY-Og; Fri, 08 Jul 2005 02:21:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqmEz-0003fQ-7P for ltru@megatron.ietf.org; Fri, 08 Jul 2005 02:21:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29970 for ; Fri, 8 Jul 2005 02:21:35 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqmgI-0001kU-UE for ltru@ietf.org; Fri, 08 Jul 2005 02:49:52 -0400 Received: from h-68-165-6-127.noclli.covad.net ([68.165.6.127] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqmEw-0002qt-00 for ltru@ietf.org; Fri, 08 Jul 2005 02:21:34 -0400 Message-ID: <038b01c58385$e0e63740$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.0.0.20.2.20050705103622.0874cc40@itmail.it.aoyama.ac.jp> Date: Thu, 7 Jul 2005 23:25: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: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] [psg.com #1058] Referencing the tagging scheme X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - The proposal is in message http://www1.ietf.org/mail-archive/web/ltru/current/msg02535.html Followed by discussion starting with message http://www1.ietf.org/mail-archive/web/ltru/current/msg02536.html At this time, it sounds like we have some WG members strongly in favor of the proposal, and some others who view it as neither necessary nor harmful, so I plan to mark this one as "resolved", assuming the editors will make the necessary changes. If there are technical objections to adopting this proposal, this is your last chance to make them. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 02:27:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqmKd-00063Y-Aw; Fri, 08 Jul 2005 02: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 1DqmKa-00060t-QT for ltru@megatron.ietf.org; Fri, 08 Jul 2005 02:27:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01635 for ; Fri, 8 Jul 2005 02:27:23 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqmlv-000296-C1 for ltru@ietf.org; Fri, 08 Jul 2005 02:55:39 -0400 Received: from h-68-165-6-127.noclli.covad.net ([68.165.6.127] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqmKY-0003xS-00 for ltru@ietf.org; Fri, 08 Jul 2005 02:27:22 -0400 Message-ID: <039e01c58386$b0651cc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org> <009901c58382$89634a60$030aa8c0@DEWELL> Subject: Re: [Ltru] Finishing off #1026 (Was: Re: status? last call?) Date: Thu, 7 Jul 2005 23:31: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: a87a9cdae4ac5d3fbeee75cd0026d632 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 - With Doug's comments below, can we wrap up issue #1026? Randy, ltru co-chair > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Thursday, July 07, 2005 11:01 PM > Subject: [Ltru] Re: status? last call? > > On Wed, 29 Jun 2005 04:29:28 +0200, Frank Ellermann claranet dot de> wrote: > > > We better wait to see what that will be, an "initial registry" > > with a separate section of obscure unregistered subtags is odd. > > Actually, I think it's a good idea to list the UN codes that were > excluded from the registry and explain why. This has certainly been one > of the more contentious aspects of the development of the initial > registry. > > > And what unregistered ISO 3166 alpha-2 codes are "eligible for > > registration" ? IMHO there should be no section about obscure > > unregistered subtags in the initial registry, it's not some > > kind of "unregistry". > > No ISO 3166 codes fall into this category, only UN numeric codes. > > >> The new text allows items listed as registrable to be > >> registered, provided they meet other rules. > > > > I'm not yet convinced. IIRC we said that 830..833 must not be > > registered because that would block a future GG, IM, and JE as > > stated in 3.3 (8): > > > > | Codes assigned by ISO 639, ISO 15924, and ISO 3166 that do > > | not conflict with existing subtags of the associated type and > > | whose meaning is not the same as an existing subtag of the > > | same type are entered into the IANA registry as new records. > > Section 3.3 (11) of the registry draft now covers this. We may NOT > register 830 through 833. Rather, someone is supposed to petition ISO > 3166/MA to add the corresponding alpha-2 codes. (Joseph Martinez, Chief > Information Officer for the MA, told me such a request would have to > come from BSI.) > > In other words, the wording in the initial-registry draft is WRONG. > Section 2, item 6 currently reads: > > "Items withdrawn, vacated, deprecated, modified, or otherwise judged by > the LTRU working group to be questionable were not added to the ILSR. > These code elements are listed in Section 4 (Omitted Code Elements), > indicating that they are valid for registration using the process in > [I-D.ietf-ltru-registry] but were not included initially. Listing of > these code elements in this section is not a guarantee of future > registration." > > This needs to be changed to read: > > "Items withdrawn, vacated, deprecated, modified, or otherwise judged by > the LTRU working group to be questionable were not added to the ILSR. > These code elements are listed in Section 4 (Omitted Code Elements), > indicating that they are not valid for registration, except as provided > in Section 3.3 (item 10E) of [I-D.ietf-ltru-registry]." > > There's no longer any need for the third sentence; in fact, it's almost > a guarantee that they will *never* be registered. > > Likewise, the introductory text in Section 4 currently reads: > > "The following code elements from [UN-M.49] were not assigned as subtags > in the initial Language Subtag Registry, but are valid candidates for > registration as region subtags, using the process in > [I-D.ietf-ltru-registry]:" > > and should be changed to: > > "The following code elements from [UN-M.49] were not assigned as subtags > in the initial Language Subtag Registry, and may not be registered > except as provided in Section 3.3 (item 10E) of > [I-D.ietf-ltru-registry]:" > > Thanks to Frank for his diligence in following up on this issue. > > I will add these changes to a draft-initial-02, as well as the "leading > whitespace" text mentioned in my other post. Does anyone have any other > comments besides this? If not, I think draft-initial-02 will be just > about ready for Last Call. > > -- > 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 Fri Jul 08 02:35:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqmSs-0001nV-MY; Fri, 08 Jul 2005 02:35:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqmSr-0001nN-LI for ltru@megatron.ietf.org; Fri, 08 Jul 2005 02:35:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02412 for ; Fri, 8 Jul 2005 02:35:56 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqmuC-0003Dc-9y for ltru@ietf.org; Fri, 08 Jul 2005 03:04:12 -0400 Received: from h-68-165-6-127.noclli.covad.net ([68.165.6.127] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqmSp-0005uX-00 for ltru@ietf.org; Fri, 08 Jul 2005 02:35:55 -0400 Message-ID: <03b401c58387$e24c4500$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 7 Jul 2005 23:40: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.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ltru] Issues #1054, #1055, and #1057 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - Newly recorded tickets in the issue tracker at https://rt.psg.com/ (user and password are "ietf"): Issue #1054 is "move rules for initial registry to initial registry i-d", and I've given it a status of "resolved". Issue #1055 is "correct dates for middle french entry", also with a status of "resolved". Issue #1057 is "use of zh-Hant-TW vs zh-cmn-Hant in examples", which I've marked "rejected". If you think I've misread consensus on any of these or believe further discussion is needed, please include the issue number in your posting's subject line. Editors, please verify that the drafts reflect these resolutions. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 02:43:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqmZq-0007dh-5D; Fri, 08 Jul 2005 02:43:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqmZo-0007at-K7 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 02:43:08 -0400 Received: from unix.megared.net.mx (megamail.megared.com.mx [200.52.207.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02790 for ; Fri, 8 Jul 2005 02:43:07 -0400 (EDT) Received: from [192.168.2.170] ([10.60.88.84]) by unix.megared.net.mx (8.11.7/8.11.7) with ESMTP id j686gZb49053; Fri, 8 Jul 2005 01:42:36 -0500 (CDT) Message-ID: <42CE2056.8070408@megared.net.mx> Date: Fri, 08 Jul 2005 01:42:30 -0500 From: "Dylan N. Pierce" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Ewell , ltru@ietf.org Subject: Re: [Ltru] Re: status? last call? References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org> <009901c58382$89634a60$030aa8c0@DEWELL> In-Reply-To: <009901c58382$89634a60$030aa8c0@DEWELL> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > Does anyone have any other > comments besides this? If not, I think draft-initial-02 will be just > about ready for Last Call. Just a question, for my own peace of mind; no matter what the answer is, I have no intention of objecting to the document. I note in the descriptions of several tags the use of Unicode code points. (Example: Provençal). I note that Unicode isn't referenced in the document, although draft-10 does reference STD 63. It is obvious to me that those escapes are meant to represent Unicode characters. I just want to make sure that what is obvious to me really is obvious. Forgive me if I'm flaunting my ignorance. Dylan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 02:48:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqmen-0000nN-L4; Fri, 08 Jul 2005 02:48:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqmem-0000nI-1E for ltru@megatron.ietf.org; Fri, 08 Jul 2005 02:48:16 -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 CAA03209 for ; Fri, 8 Jul 2005 02:48: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 <20050708064744.OFEC19267.mta10.adelphia.net@DEWELL> for ; Fri, 8 Jul 2005 02:47:44 -0400 Message-ID: <00a201c58388$ec5c73c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050708062957.UTUJ21785.mta5.adelphia.net@megatron.ietf.org> Date: Thu, 7 Jul 2005 23:47:34 -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: Finishing off #1026 (Was: Re: status? last call?) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > With Doug's comments below, can we wrap up issue #1026? I vote to wrap up this issue as resolved. In regard to the general matter of registering UN numeric code elements for countries and country-like entities (as opposed to macro regions), I believe they should NOT be eligible for individual registration, so that they may remain available as the "last resort" option in case of ISO 3166 code conflicts. In regard to the specific matter of region subtags for Guernsey, Jersey, and Isle of Man, I believe we have spent more than enough time discussing these regions. As I stated weeks ago, no evidence has come to light that any language "as used in" these regions is AT ALL different from the same language "as used in" the UK or elsewhere. -- 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 Fri Jul 08 02:49:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqmfo-0001Th-A4; Fri, 08 Jul 2005 02:49:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqmfn-0001SR-6E for ltru@megatron.ietf.org; Fri, 08 Jul 2005 02:49:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03273 for ; Fri, 8 Jul 2005 02:49:17 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqn77-0004U6-DR for ltru@ietf.org; Fri, 08 Jul 2005 03:17:34 -0400 Received: from h-68-165-6-127.noclli.covad.net ([68.165.6.127] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dqmfk-0001rx-00 for ltru@ietf.org; Fri, 08 Jul 2005 02:49:16 -0400 Message-ID: <03c901c58389$bf9fb440$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 7 Jul 2005 23:53:29 -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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] [psg.com #1059] horizontal whitespace handling in 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 Hi - > Message > http://www1.ietf.org/mail-archive/web/ltru/current/msg02587.html > identifies an unfortunate interaction between record-jar > format and the RFC editing process, and proposes a solution. I plan to mark this item "resolved" unless there are strenuous objections. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 02:57:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqmnF-0004QN-2w; Fri, 08 Jul 2005 02:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqmnD-0004PI-22 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 02:56:59 -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 CAA03684 for ; Fri, 8 Jul 2005 02:56:56 -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 <20050708065626.OJPE19267.mta10.adelphia.net@DEWELL>; Fri, 8 Jul 2005 02:56:26 -0400 Message-ID: <00a701c5838a$21e66540$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org> <009901c58382$89634a60$030aa8c0@DEWELL> <42CE2056.8070408@megared.net.mx> Subject: Re: [Ltru] Re: status? last call? Date: Thu, 7 Jul 2005 23:56: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 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 Dylan N. Pierce wrote: > I note in the descriptions of several tags the use of Unicode code > points. (Example: Provençal). I note that Unicode isn't > referenced in the document, although draft-10 does reference STD 63. > > It is obvious to me that those escapes are meant to represent Unicode > characters. I just want to make sure that what is obvious to me really > is obvious. Forgive me if I'm flaunting my ignorance. The initial-registry draft refers the reader to the registry-structure draft for all details concerning the format and encoding conventions of the registry. The registry-structure draft, in turn, does contain an informative reference to Unicode 4.1.0. -- 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 Fri Jul 08 03:32:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqnLX-0006HO-4Y; Fri, 08 Jul 2005 03:32:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqnLU-0006HI-WE for ltru@megatron.ietf.org; Fri, 08 Jul 2005 03:32: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 DAA05935 for ; Fri, 8 Jul 2005 03:32:22 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DqnLK-0005X5-7k for ltru@lists.ietf.org; Fri, 08 Jul 2005 09:32:14 +0200 Received: from du-001-048.access.de.clara.net ([212.82.227.48]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Jul 2005 09:32:14 +0200 Received: from nobody by du-001-048.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Jul 2005 09:32:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Jul 2005 09:31:27 +0200 Organization: Lines: 16 Message-ID: <42CE2BCF.3376@xyzzy.claranet.de> References: <6.0.0.20.2.20050705103622.0874cc40@itmail.it.aoyama.ac.jp> <038b01c58385$e0e63740$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-048.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1058] Referencing the tagging scheme X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > If there are technical objections to adopting this proposal, > this is your last chance to make them. See The proposal makes no sense, is not allowed in ABNF, and should be rejected. If you are talking about this idea: | Language-Tag[RFC3066bis]= (lang [...] Variations with hyphens, underscores, or other decorations are not better. ABNF is no meta data. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 03:49:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqncN-0008CC-9O; Fri, 08 Jul 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 1DqncL-0008C4-4a for ltru@megatron.ietf.org; Fri, 08 Jul 2005 03:49:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07150 for ; Fri, 8 Jul 2005 03:49:47 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqo3f-0002MR-Ty for ltru@ietf.org; Fri, 08 Jul 2005 04:18:05 -0400 Received: from h-68-165-7-174.noclli.covad.net ([68.165.7.174] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqncE-0003Bf-00 for ltru@ietf.org; Fri, 08 Jul 2005 03:49:42 -0400 Message-ID: <004601c58392$2d9795a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <42CD543E.1060304@megared.net.mx> <20050707185227.GD876@NYCMJCOWA2> <008d01c58353$6969e900$7f1afea9@oemcomputer> <42CE134B.1000009@megared.net.mx> Date: Fri, 8 Jul 2005 00:52: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.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Subject: [Ltru] [psg.com #1061] eliminate (or proscribe) Private Use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Note that I've added an issue number(https://rt.psg.com/ user& password ietf) (as a technical contributor) > From: "Dylan N. Pierce" > To: "Randy Presuhn" ; > Sent: Thursday, July 07, 2005 10:46 PM > Subject: Re: [Ltru] Private Use Tags ... > But if it's doing "Just this," then let's put our money where our mouths > are and say, "Just this." We don't need private use tags at all if we > are in agreement that corollary information, no matter how closely > related, should be handled outside the tag and, as Randy notes, we > shouldn't encourage the twisting of the tag by saying, "Here's your > scribble area." Cripes, all of XML is the scribble area; we can afford > to keep the tag clean. > > On the other hand, if we're doing "This, and more," then I would believe > we have a responsibility to ensure that the "more" proceeds in an > orderly fashion--to be read, "open, consistent and interoperable." > > As I said, I'm happy either way, but I don't think it's a non-issue. I > suppose part of the question becomes, "How much work do we want to have > to do /after/ the specification is in place?" If we eliminate the > scribble area, the answer is none. If we implement a namespace, the > answer is, "It becomes the registrar's problem." And if we leave a > wide-open private use area, the answer becomes, "Well, it depends on > what people actually do... and how much they step on each other's > toes... until they come back to us demanding a solution." > > Needless to say, I favor one of the first two options. ... Eliminating them completely might be hard for some to swallow. (I'm guessing. If others can confirm one way or the other, please do so.) Section 4.5 of http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-08.txt currently says: Private-use subtags require private agreement between the parties that intend to use or exchange language tags that use them and great caution SHOULD be used in employing them in content or protocols intended for general use. Private-use subtags are simply useless for information exchange without prior arrangement. Would a stronger version of this (or the following paragraphs address the concerns? If so, proposed text would be appreciated. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 03:50:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqncr-0008Fz-QD; Fri, 08 Jul 2005 03:50:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqncq-0008Fu-A8 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 03:50:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07161 for ; Fri, 8 Jul 2005 03:50:18 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqo4C-0002Nk-7G for ltru@ietf.org; Fri, 08 Jul 2005 04:18:36 -0400 Received: from h-68-165-7-174.noclli.covad.net ([68.165.7.174] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dqncp-0003Fa-00 for ltru@ietf.org; Fri, 08 Jul 2005 03:50:19 -0400 Message-ID: <004701c58392$4596c5e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 8 Jul 2005 00:54:29 -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: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [Ltru] [psg.com #1060] refine private use extensions to include namespace X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - > ------------------------------------------------------------------------- > The discussion thread starts with message > http://www1.ietf.org/mail-archive/web/ltru/current/msg02547.html > The proposal was refined in message > http://www1.ietf.org/mail-archive/web/ltru/current/msg02558.html > "My suggestion, instead, is an attempt to refine the private-use tag > system to include organizational namespaces so that organizations /that > would be using private tags anyway/ for whatever purposes they felt > legitimate--perhaps including but certainly not limited to other > linguistic features--can have an added guarantee that, when > intercommunicating with other organizations who agree with their tags, > their respective specialized parsing agents can definitively know that > the particular private tag they are looking at is, in fact, the one of > interest to them and not someone else's private tag that happens to > share the same letters. Exactly /what/ this would be used for is, as > you > have rightly noted, quite beyond the scope of this project and would > probably bore us all to death anyway (as if I'm not doing that > already)." > > After additional discussion, the proposal was withdrawn, see message > http://www1.ietf.org/mail-archive/web/ltru/current/msg02570.html > > > Consequently, this item is marked "rejected". If further discussion of this issue is needed, please include the ticket number in your subject line. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 04:02:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqnoq-0006T4-9R; Fri, 08 Jul 2005 04: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 1Dqnoo-0006Sy-Ii for ltru@megatron.ietf.org; Fri, 08 Jul 2005 04:02:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08007 for ; Fri, 8 Jul 2005 04:02:40 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqoGA-0003f7-5B for ltru@ietf.org; Fri, 08 Jul 2005 04:30:58 -0400 Received: from h-68-165-7-174.noclli.covad.net ([68.165.7.174] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dqnom-0005M2-00 for ltru@ietf.org; Fri, 08 Jul 2005 04:02:40 -0400 Message-ID: <007801c58393$fe78fbe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050704023055.JYPG21785.mta5.adelphia.net@megatron.ietf.org><003c01c58056$dae65c80$030aa8c0@DEWELL><6.2.1.2.2.20050704094915.04952d80@mail.afrac.org> <001d01c580b8$1d4f4800$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: IANA ISO 3166 related Registries Date: Fri, 8 Jul 2005 01:06: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.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 Hi - Our charter explicitly assigns to us the task of describing "the structure of the IANA registry". Consequently, registry proposals that do not result in an IANA registry are out of order. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 04:49:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqoXh-0005Ms-Ra; Fri, 08 Jul 2005 04: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 1DqoXg-0005M9-DU for ltru@megatron.ietf.org; Fri, 08 Jul 2005 04:49: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 EAA11254 for ; Fri, 8 Jul 2005 04:49:01 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DqoXX-0005aA-FK for ltru@lists.ietf.org; Fri, 08 Jul 2005 10:48:55 +0200 Received: from du-001-048.access.de.clara.net ([212.82.227.48]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Jul 2005 10:48:55 +0200 Received: from nobody by du-001-048.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Jul 2005 10:48:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 08 Jul 2005 10:45:31 +0200 Organization: Lines: 51 Message-ID: <42CE3D2A.1067@xyzzy.claranet.de> References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org> <009901c58382$89634a60$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-048.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: status? last call? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 think it's a good idea to list the UN codes that were > excluded from the registry and explain why. For _valid_ UN numbers at date-B I got the idea, and that covers 831..833 for File-Date: 2005-07-05, even 830, tough. But not 200. the only "200" on their page belongs to 2005. 200 is AFAIK also no "valid candidate for registration". And it never was, so even a time machine wouldn't help. IANA: Are we sure that they manage it to extract the real registry from your I-D ? Scott said "assume the worst" or similar. Maybe a short note "remove page headers and three leading spaces in all lines of chapter 3, the first line should be the File-Date line" helps in the IANA considerations. Otherwise I get: | 958 (sub)tags in 5014 lines, 279 xrefs okay Some comments like "replaced by ISO code lb" aren't strictly necessary, the Prefered-Value: lb is clear. But no problem. [eligible 3166 codes] > No ISO 3166 codes fall into this category, only UN numeric > codes. That's still wrong in draft -08 (2.2.4 3E). [830..833] > Section 3.3 (11) of the registry draft now covers this. Really, it lists all four #1026 codes, why do they want that you have a complete chapter about excatly the same four codes ? IANA is most probably not interested what we do NOT register. >| The following code elements from [UN-M.49] were not assigned >| as subtags in the initial Language Subtag Registry, and may >| not be registered except as provided in Section 3.3 (item >| 10E) of [I-D.ietf-ltru-registry]:" Okay (but get rid of 200). > I think draft-initial-02 will be just about ready for Last > Call. ACK, but draft -08 2.2.4 3E might be still wrong, bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 05:11:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqotS-0001Ul-1i; Fri, 08 Jul 2005 05: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 1DqotP-0001S0-On for ltru@megatron.ietf.org; Fri, 08 Jul 2005 05:11:31 -0400 Received: from unix.megared.net.mx (megamail.megared.com.mx [200.52.207.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12708 for ; Fri, 8 Jul 2005 05:11:29 -0400 (EDT) Received: from [192.168.2.170] ([10.60.88.84]) by unix.megared.net.mx (8.11.7/8.11.7) with ESMTP id j689Akh84049; Fri, 8 Jul 2005 04:10:48 -0500 (CDT) Message-ID: <42CE4312.2080203@megared.net.mx> Date: Fri, 08 Jul 2005 04:10:42 -0500 From: "Dylan N. Pierce" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn , ltru@ietf.org Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe) Private Use Tags References: <42CD543E.1060304@megared.net.mx> <20050707185227.GD876@NYCMJCOWA2> <008d01c58353$6969e900$7f1afea9@oemcomputer> <42CE134B.1000009@megared.net.mx> <004601c58392$2d9795a0$7f1afea9@oemcomputer> In-Reply-To: <004601c58392$2d9795a0$7f1afea9@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 Randy Presuhn wrote: > Would a stronger version of this (or the following paragraphs address the > concerns? If so, proposed text would be appreciated. Another way of looking at the concern. Reading from 4.5: "For example, the region subtags 'AA', 'ZZ' and in the ranges 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) MAY be used to form a language tag. A tag such as "zh-Hans-XQ" conveys a great deal of public, interchangeable information about the language material (that it is Chinese in the simplified Chinese script and is suitable for some geographic region 'XQ'). While the precise geographic region is not known outside of private agreement, the tag conveys far more information than an opaque tag such as "x-someLang", which contains no information about the language subtag or script subtag outside of the private agreement." The tag "zh-Hans-XQ" provides enough information that parsing agents know what they don't know: the region. The legitimate-but-opaque tag "zh-Hans-x-whoKnows" might contain a privately-defined region... but if so, why not use the first option? It also might contain something that's completely outside the intended scope of the language tag. If we're serious about what these tags are meant to represent, why make it possible to work against it? This returns to the "scribble space" issue. I'm not sure a stronger version of the warning itself would clarify this. It would have to say something like: "Private-use subtags require private agreement between the parties that intend to use or exchange language tags that use them and they MUST NOT be used in content or protocols intended for general use unless it can be guaranteed that they will not inadvertently show up in parsing agents used by other parties with private-use agreements that coincedentally employ the same alphanumeric sequence." Which sounds ridiculous. Okay, yes, I intentionally made it sound ridiculous, but this is the point: if we're documenting language, region, script and variant, it's easy enough to indicate "unknown region" when encountering a private-use region subtag. If you encounter a pure private-use "x," all you know is that it is either an unknown language, script, region or variant that doesn't want to admit it, or an unknown something else that's outside the scope of the language tag completely. What does allowing an unknown "something else" gain in clarity or interoperability? Returning to Addison's original reply to my first proposal (now withdrawn, but for this very reason), if the "something else" really is legitimate, then a new RFC can be written to make use of the reserved tags. If not, then it's in the wrong place, and if you've ever tried to keep an office organized, you know that allowing folks to put things in the wrong place is an excellent way to ensure that later on, no one knows where to look for them (except, perhaps, by "private agreement," which is how I keep from losing my coffee cup). So I guess at this point, what I am looking at isn't proposed new text, or proposed changes in text, but a proposed elimination of text, to whit, the text defining the private-use subtag "x". My question: is the gain in "swallowing comfort" won by unregulated, unparsable private-use tags worth the corresponding loss in clarity and interoperability? If the answer is an honest resounding "Yes" from everyone else with an interest in this issue, I'll concede the point and go away. But if we're doing it just because we're just not willing to take that final step of saying, "/This/ is what these tags define, and nothing else," because we're nervous about the commitment, then I have a feeling we might be making a mistake. Dylan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 07:57:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrUE-0006k0-4A; Fri, 08 Jul 2005 07:57:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrUD-0006jh-93 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 07:57:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24261 for ; Fri, 8 Jul 2005 07:57:38 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqrvY-0000Hm-Eh for ltru@ietf.org; Fri, 08 Jul 2005 08:25:57 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqrU5-0006jq-0S; Fri, 08 Jul 2005 04:57:33 -0700 Message-Id: <6.2.1.2.2.20050708130647.03e462a0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Jul 2005 13:08:33 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: status? last call? In-Reply-To: <00a701c5838a$21e66540$030aa8c0@DEWELL> References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org> <009901c58382$89634a60$030aa8c0@DEWELL> <42CE2056.8070408@megared.net.mx> <00a701c5838a$21e66540$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 - afrac.org 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: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 08:56 08/07/2005, Doug Ewell wrote: >Dylan N. Pierce wrote: > > > I note in the descriptions of several tags the use of Unicode code > > points. (Example: Provençal). I note that Unicode isn't > > referenced in the document, although draft-10 does reference STD 63. > > > > It is obvious to me that those escapes are meant to represent Unicode > > characters. I just want to make sure that what is obvious to me really > > is obvious. Forgive me if I'm flaunting my ignorance. > >The initial-registry draft refers the reader to the registry-structure >draft for all details concerning the format and encoding conventions of >the registry. The registry-structure draft, in turn, does contain an >informative reference to Unicode 4.1.0. This cannot be as this is not an ISO 639-4 accepted reference. Nothing protects the IETF which is not an ISO nor a Unicode expert, from conflict. As the Chair put it, ISO is ISO and IETF is IETF. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 07:57:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrUE-0006kO-8n; Fri, 08 Jul 2005 07:57:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrUD-0006jj-A1 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 07:57:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24262 for ; Fri, 8 Jul 2005 07:57:38 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqrvY-0000Hr-EU for ltru@ietf.org; Fri, 08 Jul 2005 08:25:57 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqrU6-0006jq-2O; Fri, 08 Jul 2005 04:57:34 -0700 Message-Id: <6.2.1.2.2.20050708131037.04028eb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Jul 2005 13:24:48 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe) Private Use Tags In-Reply-To: <004601c58392$2d9795a0$7f1afea9@oemcomputer> References: <42CD543E.1060304@megared.net.mx> <20050707185227.GD876@NYCMJCOWA2> <008d01c58353$6969e900$7f1afea9@oemcomputer> <42CE134B.1000009@megared.net.mx> <004601c58392$2d9795a0$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 - afrac.org X-Spam-Score: 0.0 (/) 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 At 09:52 08/07/2005, Randy Presuhn wrote: >Hi -Eliminating them completely might be hard for some to swallow. (I'm >guessing. >If others can confirm one way or the other, please do so.) > >Section 4.5 of >http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-08.txt >currently says: > Private-use subtags require private agreement between the parties > that intend to use or exchange language tags that use them and great > caution SHOULD be used in employing them in content or protocols > intended for general use. Private-use subtags are simply useless for > information exchange without prior arrangement. > >Would a stronger version of this (or the following paragraphs address the >concerns? If so, proposed text would be appreciated. Let be candid, this is another way to reduce the scope of the Draft without telling it plainly. The followin text: Private-use subtags require private agreement between the parties that intend to use or exchange language tags that use them. Great caution SHOULD be used in employing them in content or protocols intended for general use. Private-use subtags SHOULD respect the general format contraints. Even used in a private context, general libraries are legitimate in only using the part of each subtag which matches the general ABNF [or in disregarding the subtags wich does not match the general ABNF]. Private-use subtags are simply useless for information exchange without prior arrangement. Would be OK for us (even with the [or ...] being used). This provides an escape sequence from the Draft. Not the best and most elegant, but workable: this is what we will do anyway. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 07:57:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrUE-0006km-ER; Fri, 08 Jul 2005 07:57:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrUD-0006ji-92 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 07:57:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24252 for ; Fri, 8 Jul 2005 07:57:37 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqrvY-0000Hk-EZ for ltru@ietf.org; Fri, 08 Jul 2005 08:25:56 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqrU3-0006jq-UK; Fri, 08 Jul 2005 04:57:32 -0700 Message-Id: <6.2.1.2.2.20050708125414.03fef8f0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Jul 2005 13:02:24 +0200 To: "Mark Davis" , "John.Cowan" , "Dylan N. Pierce" From: r&d afrac Subject: Re: [Ltru] Private Use Tags In-Reply-To: <01e801c58377$2cabf160$6501a8c0@sanjose.ibm.com> References: <42CD543E.1060304@megared.net.mx> <20050707185227.GD876@NYCMJCOWA2> <01e801c58377$2cabf160$6501a8c0@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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA24252 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 06:29 08/07/2005, Mark Davis wrote: >I do not think that this line is at all as clear as you would think. The >notion of a locale is very fuzzy: most of the items that people associat= e >with it, other than language, are merely guesses. The currency of a >transaction is often completely independent of the user's location; I co= uld >be buying something on the web and pay euros, or pounds, or dollars, no >matter where I live. The same goes for timezones, even units. (We all >remember the rocket that failed because two people in the same country w= ere >interpreting a number as being in different units). It is a fairly rough >approximation to assume the values of these from seeing en_UK (or en-UK)= . Of >course, that may be all that the information that someone has, but you c= an't >read into it more than a good guess. And other areas get fuzzy as well. = Is >sort order a language or a locale issue? > >The language is clearly a core part of what people mean by 'locale', and >anything beyond that is pretty speculative. A real locale id shades off = into >something more like a bundle of preferences. > >But this is all pretty off-topic; I really hope we can focus on just the >items we need to finish off to get this thing to last call. Mark, the whole issue is that a langtag is to identify something. These=20 somethings are not defined in your Draft. The Last Call will identify tha= t=20 among others, and will fail again. Unless the game consists for you too, = in=20 accumulating the failed Last Call and draining competences from all over=20 the world in a waste of time, please identify: - each subtag you use - their correlations into the subtag you propose - which becomes more and= =20 more different from the lose catch all RFC 3066 lack of definition. RFC=20 3066 was general and never said as you keep adding "this of off-topic". A= ll=20 what I ask is you say what is on topic. This at least would help Randy's mails about "stay on topic" clearer. Or in 2007 we will still be discussing about the 8th Last Call. Am I the=20 only one to truely want to see something matching the charter being deliv= ered. The charter does not say to _narrow_ the scope but to address the problem= s,=20 which are that the scope is not large enough and not structured enough to= =20 support all the encountered needs. jfc >=E2=80=8EMark > >----- Original Message ----- >From: "John.Cowan" >To: "Dylan N. Pierce" >Cc: >Sent: Thursday, July 07, 2005 11:52 >Subject: Re: [Ltru] Private Use Tags > > > > Dylan N. Pierce scripsit: > > > > > According to Sun's own documentation, "The language argument is a v= alid > > > ISO Language Code. These codes are the lower-case, two-letter codes= as > > > defined by ISO-639.... The country argument is a valid ISO Country > > > Code. These codes are the upper-case, two-letter codes as defined b= y > > > ISO-3166." And its purpose is so that applications can decide in wh= at > > > language to serve the documents (in this case, UI output). In other > > > words, the difference between what they're doing and what we're doi= ng > > > is, at best, cosmetic; > > > > In fact not; the difference is deep and conceptual. The country subt= ag > > in a locale ID serves an entirely different purpose from the one in a > > language tag. Rather than meaning "The variant of the language commo= nly > > used in country X", it means "Using the various notational and cultur= al > > conventions of country X". > > > > For example, the Mohawk language (ISO 639-2 code 'moh') is spoken on > > both sides of the U.S.-Canadian border, but does not come in national > > variants "moh-US" and "moh-CA"; though well-formed and valid per RFC > > 3066, these tags are not useful. However, for someone using a comput= er > > in Mohawk, the locale IDs "moh_US" and "moh_CA" are eminently useful: > > the first signals a desire for U.S. dollars and Fred Flintstone units= , > > the second a desire for Canadian dollars and metric units. > > > > Similarly, "en-DE" does not make much sense, as there is no German > > national variant of the English language (jokes about "Ve haf > > vays!" aside), but "en_DE" represents using the English language in a > > German national context, with euros and metric units and German-style > > postal addresses. > > > > Indeed, in principle there is no reason why a locale ID like "en-us_D= E" > > can't be useful: this says that the context is still euros, etc., > > but the dictionary now contains specifically American English. > > > > -- > > 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 ext= ended >haiku > > > > _______________________________________________ > > 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 Fri Jul 08 07:57:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrUE-0006lA-Ib; Fri, 08 Jul 2005 07:57:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqrUD-0006jg-9l for ltru@megatron.ietf.org; Fri, 08 Jul 2005 07:57:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24257 for ; Fri, 8 Jul 2005 07:57:38 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqrvY-0000IE-Ed for ltru@ietf.org; Fri, 08 Jul 2005 08:25:57 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqrU7-0006jq-8C; Fri, 08 Jul 2005 04:57:35 -0700 Message-Id: <6.2.1.2.2.20050708132837.04055660@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Jul 2005 13:37:25 +0200 To: "Dylan N. Pierce" , Randy Presuhn , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe) Private Use Tags In-Reply-To: <42CE4312.2080203@megared.net.mx> References: <42CD543E.1060304@megared.net.mx> <20050707185227.GD876@NYCMJCOWA2> <008d01c58353$6969e900$7f1afea9@oemcomputer> <42CE134B.1000009@megared.net.mx> <004601c58392$2d9795a0$7f1afea9@oemcomputer> <42CE4312.2080203@megared.net.mx> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 11:10 08/07/2005, Dylan N. Pierce wrote: >Randy Presuhn wrote: >>Would a stronger version of this (or the following paragraphs address the >>concerns? If so, proposed text would be appreciated. > >Another way of looking at the concern. is to respect the charter and retrocompatibility with RFC 3066. We extensively use and plan to use "x-tags". The way we see (from our perspectibe) it is that x-tags are the standard format: - "x-" is the language tag indicating sequence and we experimentaly use to signify that the text enters/finish English - "xn--" is an extended name (punycoded name) (we experimentaly use and to mean that the text was punny coded and to be restored) The Draft sequence are default special cases. Obviously if "x-" retrocompabilty was not assured, we would have no more problem in introducing "x-tags" as a separate taging system. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 09:42:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqt7t-0004Tc-8l; Fri, 08 Jul 2005 09:42:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqt7s-0004TU-EQ for ltru@megatron.ietf.org; Fri, 08 Jul 2005 09:42:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02164 for ; Fri, 8 Jul 2005 09:42:42 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqtZG-00008u-BP for ltru@ietf.org; Fri, 08 Jul 2005 10:11:03 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jul 2005 06:42:31 -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); Fri, 8 Jul 2005 06:42:30 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Private Use Tags Date: Fri, 8 Jul 2005 06:42:43 -0700 Message-ID: Thread-Topic: [Ltru] Private Use Tags Thread-Index: AcWDgJqIo6cyhu03RIagFR1bfSeUmwAQaASg From: "Peter Constable" To: X-OriginalArrivalTime: 08 Jul 2005 13:42:30.0747 (UTC) FILETIME=[E321E2B0:01C583C2] 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 Dylan N. Pierce > But if it's doing "Just this," then let's put our money where our mouths > are and say, "Just this." We don't need private use tags at all We cannot eliminate private-use tags completely: we must at least retain x *("-" 1*8Alpha) to remain backward compatible with existing implementations of 3066. I don't think we want current users' tags to break on new parsers. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 09:46:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqtBm-0006Dp-0h; Fri, 08 Jul 2005 09: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 1DqtBl-0006Dh-8q for ltru@megatron.ietf.org; Fri, 08 Jul 2005 09:46:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02411 for ; Fri, 8 Jul 2005 09:46:43 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqtd7-0000VF-5u for ltru@ietf.org; Fri, 08 Jul 2005 10:15:04 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jul 2005 06:46: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.1830); Fri, 8 Jul 2005 06:46:32 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1058] Referencing the tagging scheme Date: Fri, 8 Jul 2005 06:46:45 -0700 Message-ID: Thread-Topic: [Ltru] Re: [psg.com #1058] Referencing the tagging scheme Thread-Index: AcWDj0kUPray2gM8TxqIWmUbC7+p/wANCglQ From: "Peter Constable" To: "Frank Ellermann" , X-OriginalArrivalTime: 08 Jul 2005 13:46:32.0014 (UTC) FILETIME=[72F04EE0:01C583C3] 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 +1 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > Sent: Friday, July 08, 2005 12:31 AM > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #1058] Referencing the tagging scheme >=20 > Randy Presuhn wrote: >=20 > > If there are technical objections to adopting this proposal, > > this is your last chance to make them. >=20 > See >=20 > The proposal makes no sense, is not allowed in ABNF, and > should be rejected. If you are talking about this idea: >=20 > | Language-Tag[RFC3066bis]=3D (lang > [...] >=20 > Variations with hyphens, underscores, or other decorations > are not better. ABNF is no meta data. 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 Fri Jul 08 09:52:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqtHO-0001Ia-IR; Fri, 08 Jul 2005 09:52:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqtHM-0001IL-AN for ltru@megatron.ietf.org; Fri, 08 Jul 2005 09:52:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02935 for ; Fri, 8 Jul 2005 09:52:30 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqtil-0000um-9S for ltru@ietf.org; Fri, 08 Jul 2005 10:20:51 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jul 2005 06:52:22 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jul 2005 06:52:22 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1061] eliminate (or proscribe) Private Use Tags Date: Fri, 8 Jul 2005 06:52:35 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #1061] eliminate (or proscribe) Private Use Tags Thread-Index: AcWDkdn/98NJzxHBTPGZ3gEdSRQg8AAMk2mw From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 08 Jul 2005 13:52:22.0637 (UTC) FILETIME=[43ED21D0:01C583C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 [re posting with appropriate subject] > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Dylan N. Pierce > But if it's doing "Just this," then let's put our money where our mouths > are and say, "Just this." We don't need private use tags at all We cannot eliminate private-use tags completely: we must at least retain x *("-" 1*8Alpha) to remain backward compatible with existing implementations of 3066. I don't think we want current users' tags to break on new parsers. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 10:34:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqtw5-0007C0-Ql; Fri, 08 Jul 2005 10:34:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqtw5-0007Bv-8S for ltru@megatron.ietf.org; Fri, 08 Jul 2005 10:34:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06961 for ; Fri, 8 Jul 2005 10:34:35 -0400 (EDT) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DquNS-0003O4-Fa for ltru@ietf.org; Fri, 08 Jul 2005 11:02:56 -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 <20050708143420.BHOP29002.mta9.adelphia.net@DEWELL> for ; Fri, 8 Jul 2005 10:34:20 -0400 Message-ID: <00f101c583ca$075a0660$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org> <009901c58382$89634a60$030aa8c0@DEWELL> <42CE2056.8070408@megared.net.mx> <00a701c5838a$21e66540$030aa8c0@DEWELL> <6.2.1.2.2.20050708130647.03e462a0@mail.afrac.org> Subject: Re: [Ltru] Re: status? last call? Date: Fri, 8 Jul 2005 07:33: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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 r&d afrac wrote: >> The initial-registry draft refers the reader to the registry- >> structure draft for all details concerning the format and encoding >> conventions of the registry. The registry-structure draft, in turn, >> does contain an informative reference to Unicode 4.1.0. > > This cannot be as this is not an ISO 639-4 accepted reference. Nothing > protects the IETF which is not an ISO nor a Unicode expert, from > conflict. As the Chair put it, ISO is ISO and IETF is IETF. I have no idea what this means. Are you saying that the initial-registry draft needs to include an explicit reference to the Unicode Standard, instead of indirectly referencing it through the registry-structure draft? I don't see what ISO 639-4 has to do with any of 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@lists.ietf.org Fri Jul 08 10:42:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqu3z-00032K-Uy; Fri, 08 Jul 2005 10:42:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqu3y-00032C-4H for ltru@megatron.ietf.org; Fri, 08 Jul 2005 10:42:46 -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 KAA07642 for ; Fri, 8 Jul 2005 10:42: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 <20050708144214.CGYD19267.mta10.adelphia.net@DEWELL> for ; Fri, 8 Jul 2005 10:42:14 -0400 Message-ID: <010001c583cb$1b785d80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050708091150.FDRY15546.mta1.adelphia.net@megatron.ietf.org> Date: Fri, 8 Jul 2005 07:41: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 Cc: Subject: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I do not favor either removing or further discouraging private-use tags or subtags in "x-". I'll have more to say about this later. -- 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 Fri Jul 08 12:46:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqvzn-0003ZM-0c; Fri, 08 Jul 2005 12:46:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqvzk-0003ZB-V4 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 12:46:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27212 for ; Fri, 8 Jul 2005 12:46:30 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqwR9-00056n-FH for ltru@ietf.org; Fri, 08 Jul 2005 13:14: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 j68GkCFM014085 for ; Fri, 8 Jul 2005 12:46:13 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 8 Jul 2005 12:46:12 -0400 Date: Fri, 8 Jul 2005 12:46:12 -0400 From: "John.Cowan" To: ltru@ietf.org Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags Message-ID: <20050708164612.GD4776@NYCMJCOWA2> References: <20050708091150.FDRY15546.mta1.adelphia.net@megatron.ietf.org> <010001c583cb$1b785d80$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010001c583cb$1b785d80$030aa8c0@DEWELL> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Doug Ewell scripsit: > I do not favor either removing or further discouraging private-use tags > or subtags in "x-". I'll have more to say about this later. +1 -- John Cowan jcowan@reutershealth.com www.ccil.org/~cowan www.reutershealth.com If I have seen farther than others, it is because I was standing on the shoulders of giants. --Isaac Newton _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 14:17:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqxND-0003W3-B5; Fri, 08 Jul 2005 14:14:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqxNB-0003Vx-NB for ltru@megatron.ietf.org; Fri, 08 Jul 2005 14:14:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02727 for ; Fri, 8 Jul 2005 14:14:48 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqxoc-0000Hv-1c for ltru@ietf.org; Fri, 08 Jul 2005 14:43:11 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqxN8-0001dJ-T4; Fri, 08 Jul 2005 11:14:47 -0700 Message-Id: <6.2.1.2.2.20050708193920.0498eeb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Jul 2005 19:54:54 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: status? last call? In-Reply-To: <00f101c583ca$075a0660$030aa8c0@DEWELL> References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org> <009901c58382$89634a60$030aa8c0@DEWELL> <42CE2056.8070408@megared.net.mx> <00a701c5838a$21e66540$030aa8c0@DEWELL> <6.2.1.2.2.20050708130647.03e462a0@mail.afrac.org> <00f101c583ca$075a0660$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 - afrac.org X-Spam-Score: 0.0 (/) 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 At 16:33 08/07/2005, Doug Ewell wrote: >r&d afrac wrote: > > >> The initial-registry draft refers the reader to the registry- > >> structure draft for all details concerning the format and encoding > >> conventions of the registry. The registry-structure draft, in turn, > >> does contain an informative reference to Unicode 4.1.0. > > > > This cannot be as this is not an ISO 639-4 accepted reference. Nothing > > protects the IETF which is not an ISO nor a Unicode expert, from > > conflict. As the Chair put it, ISO is ISO and IETF is IETF. > >I have no idea what this means. Are you saying that the >initial-registry draft needs to include an explicit reference to the >Unicode Standard, instead of indirectly referencing it through the >registry-structure draft? No. I say directly or indirectly you cannot reference an third party. Unicode is a consortium of private interets, the same as W3C, etc. This WG is to deal with ISO 639, 3166 and 15924, plus UN M.49 (in a way I partly disagree with because the format is confusing). Outside of that no other code has been accepted: because no other maintainer has committed to stay compatible with these codes and her commitment accepted by the IETF. >I don't see what ISO 639-4 has to do with any of this. ISO 639-4 is the ISO document which commits on the consistency of ISO 639 series, 15924 and 3166 series. ISO 639-4 is to describe the possible relations between these codes. The matter is debated and not made. It would be odd if IETF standardised relations between codes the authors of that codes would identify as wrong. This is why we must do the things in sequence. Our charter is to deal with ISO 639. The author of ISO 639-3 being at the origin of all this effort, I undersnand that he insisted on ISO 639-3. I find other ISO 639-3 based formats more interesting networkwise, but all this is a question of technical experimentation and testing by users. I always marvel at people who invent best common practices. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 15: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 1DqyAm-0006ws-VU; Fri, 08 Jul 2005 15: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 1DqyAl-0006wn-CO for ltru@megatron.ietf.org; Fri, 08 Jul 2005 15:06:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07359 for ; Fri, 8 Jul 2005 15:06:02 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqycC-0002RS-1z for ltru@ietf.org; Fri, 08 Jul 2005 15:34:25 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jul 2005 12:05: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.1830); Fri, 8 Jul 2005 12:05:52 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: status? last call? Date: Fri, 8 Jul 2005 12:06:05 -0700 Message-ID: Thread-Topic: [Ltru] Re: status? last call? Thread-Index: AcWD6RFzbIkKzJ/ERa+nOd6izD+NjgAAbjxQ From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 08 Jul 2005 19:05:52.0039 (UTC) FILETIME=[0F341B70:01C583F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 r&d afrac > ISO 639-4 is the ISO document which commits on the consistency of ISO 639 > series, 15924 and 3166 series. ISO 639-4 does not attempt to ensure consistency in ISO 15924 or ISO 3166. > ISO 639-4 is to describe the possible > relations between these codes. The matter is debated and not made. It > would > be odd if IETF standardised relations between codes the authors of that > codes would identify as wrong. ISO 639-4 will describe in general terms that the ISO 639 codes can be combined with other codes defined in other standards. It will not define any specific constraints (e.g. that Latf cannot be used in combination with zh), nor will it impose any particular syntactic mechanisms for combining different codes. Nothing being done in the draft for 3066bis is contrary to what is anticipated in ISO 639-4. > This is why we must do the things in > sequence. Our charter is to deal with ISO 639. No, our charter is to revise RFC 3066. I don't see "deal with ISO 639" anywhere in the charter. > The author of ISO 639-3 > being at the origin of all this effort, All what effort? AFAIK, the editor for 639-3 cannot claim to be the origin for LTRU, work on 3066bis, 639-4, or even 639-3. > I undersnand that he insisted on > ISO 639-3.=20 I have not insisted on anything to do with ISO 639-3 in the context of LTRU. Suggestions for future developments, particularly in relation to incorporation of 639-3 and in relation to extlang, have been made, and there has been some broad consensus on general issues. But nothing has transpired on the basis of my insistence. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 15:18:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyN4-0002sg-UT; Fri, 08 Jul 2005 15:18:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqyN3-0002sW-Cn for ltru@megatron.ietf.org; Fri, 08 Jul 2005 15:18:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09176 for ; Fri, 8 Jul 2005 15:18:41 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqyoQ-00030r-4H for ltru@ietf.org; Fri, 08 Jul 2005 15:47:05 -0400 Received: from h-68-166-189-12.noclli.covad.net ([68.166.189.12] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqyMs-0003rF-00 for ltru@ietf.org; Fri, 08 Jul 2005 15:18:34 -0400 Message-ID: <004301c583f2$6c063e80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050708091150.FDRY15546.mta1.adelphia.net@megatron.ietf.org><010001c583cb$1b785d80$030aa8c0@DEWELL> <20050708164612.GD4776@NYCMJCOWA2> Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private UseTags Date: Fri, 8 Jul 2005 12:22: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.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: "John.Cowan" > To: > Sent: Friday, July 08, 2005 9:46 AM > Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private UseTags > > Doug Ewell scripsit: > > > I do not favor either removing or further discouraging private-use tags > > or subtags in "x-". I'll have more to say about this later. > > +1 ... It's clear from the posts so far that "eliminate" won't get consensus support, due to legacy concerns. So, please, let's narrow the discussion to whether the text makes the risks / limitations on the use of them sufficiently clear. There are currently two proposals for text: (1) "Private-use subtags require private agreement between the parties that intend to use or exchange language tags that use them and they MUST NOT be used in content or protocols intended for general use unless it can be guaranteed that they will not inadvertently show up in parsing agents used by other parties with private-use agreements that coincedentally employ the same alphanumeric sequence." (2) "Private-use subtags require private agreement between the parties that intend to use or exchange language tags that use them. Great caution SHOULD be used in employing them in content or protocols intended for general use. Private-use subtags SHOULD respect the general format contraints. Even used in a private context, general libraries are legitimate in only using the part of each subtag which matches the general ABNF [or in disregarding the subtags wich does not match the general ABNF]. Private-use subtags are simply useless for information exchange without prior arrangement." As a technical contributor, I rather like (1), even though its proposer says it was deliberately written to sound ridiculous. I can't support (2) in its current form, but could live with a modified version of (2) that I'll call (2a): (2) "Private-use subtags require private agreement between parties intending to use them. Use great caution if employing them in content or protocols intended for general use. Private-use subtags MUST conform to the format contraints specified in the ABNF. Private-use subtags are useless for information exchange without prior arrangement." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 15:24:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqySw-0000h8-46; Fri, 08 Jul 2005 15:24:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqySu-0000gy-Pa for ltru@megatron.ietf.org; Fri, 08 Jul 2005 15:24:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09803 for ; Fri, 8 Jul 2005 15:24:47 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqyuL-0003L2-O4 for ltru@ietf.org; Fri, 08 Jul 2005 15:53:10 -0400 Received: from h-68-166-189-12.noclli.covad.net ([68.166.189.12] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqySr-0005ss-00 for ltru@ietf.org; Fri, 08 Jul 2005 15:24:46 -0400 Message-ID: <005001c583f3$49a0e560$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: [psg.com #1058] Referencing the tagging scheme Date: Fri, 8 Jul 2005 12:28: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: 68c8cc8a64a9d0402e43b8eee9fc4199 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 - Ok, I think we've gone from a weak "accept" to a rough consensus to reject this proposal. I've updated the ticket accordingly. If you think there is value in further discussion, please include the issue number in the subject line. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 15:48:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqyq9-0006sJ-Gl; Fri, 08 Jul 2005 15:48:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqyq7-0006sE-91 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 15:48:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11575 for ; Fri, 8 Jul 2005 15:48:45 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqzHZ-0004SG-Ce for ltru@ietf.org; Fri, 08 Jul 2005 16:17:09 -0400 Received: from h-68-166-189-12.noclli.covad.net ([68.166.189.12] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dqyq5-0006Nm-00 for ltru@ietf.org; Fri, 08 Jul 2005 15:48:45 -0400 Message-ID: <007301c583f6$a2e901e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org><009901c58382$89634a60$030aa8c0@DEWELL><42CE2056.8070408@megared.net.mx><00a701c5838a$21e66540$030aa8c0@DEWELL><6.2.1.2.2.20050708130647.03e462a0@mail.afrac.org><00f101c583ca$075a0660$030aa8c0@DEWELL> <6.2.1.2.2.20050708193920.0498eeb0@mail.afrac.org> Date: Fri, 8 Jul 2005 12:52: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.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [Ltru] #891, #943, #978 are already resolved (was: status? last call?) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - Issue #891 (support for non-ASCII representations of language names), issue #934 (repertoire for descriptions in registry entries) issue #987 (format of character references) were resolved long ago. No technical argument to re-open any of these has been presented in this thread. The resolution of these requires reference to the NCR notation. Complaints that such a technically necessary reference would be inappropriate seem disingenuous at best. Let's waste no more time or electrons on this. Randy, ltru co-chair ----- Original Message ----- > From: "r&d afrac" > To: "Doug Ewell" ; "LTRU Working Group" > Sent: Friday, July 08, 2005 10:54 AM > Subject: Re: [Ltru] Re: status? last call? > > At 16:33 08/07/2005, Doug Ewell wrote: > >r&d afrac wrote: > > > > >> The initial-registry draft refers the reader to the registry- > > >> structure draft for all details concerning the format and encoding > > >> conventions of the registry. The registry-structure draft, in turn, > > >> does contain an informative reference to Unicode 4.1.0. > > > > > > This cannot be as this is not an ISO 639-4 accepted reference. Nothing > > > protects the IETF which is not an ISO nor a Unicode expert, from > > > conflict. As the Chair put it, ISO is ISO and IETF is IETF. > > > >I have no idea what this means. Are you saying that the > >initial-registry draft needs to include an explicit reference to the > >Unicode Standard, instead of indirectly referencing it through the > >registry-structure draft? > > No. I say directly or indirectly you cannot reference an third party. > Unicode is a consortium of private interets, the same as W3C, etc. This WG > is to deal with ISO 639, 3166 and 15924, plus UN M.49 (in a way I partly > disagree with because the format is confusing). Outside of that no other > code has been accepted: because no other maintainer has committed to stay > compatible with these codes and her commitment accepted by the IETF. > > >I don't see what ISO 639-4 has to do with any of this. > > ISO 639-4 is the ISO document which commits on the consistency of ISO 639 > series, 15924 and 3166 series. ISO 639-4 is to describe the possible > relations between these codes. The matter is debated and not made. It would > be odd if IETF standardised relations between codes the authors of that > codes would identify as wrong. This is why we must do the things in > sequence. Our charter is to deal with ISO 639. The author of ISO 639-3 > being at the origin of all this effort, I undersnand that he insisted on > ISO 639-3. I find other ISO 639-3 based formats more interesting > networkwise, but all this is a question of technical experimentation and > testing by users. I always marvel at people who invent best common practices. > 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 Fri Jul 08 16:14:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqzF5-0000L3-SG; Fri, 08 Jul 2005 16:14:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqzF3-0000IQ-RX for ltru@megatron.ietf.org; Fri, 08 Jul 2005 16:14:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18629 for ; Fri, 8 Jul 2005 16:14:31 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqzgU-0007RA-SL for ltru@ietf.org; Fri, 08 Jul 2005 16:42:56 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqzF0-0000ns-Rp; Fri, 08 Jul 2005 13:14:31 -0700 Message-Id: <6.2.1.2.2.20050708211132.0498be80@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Jul 2005 22:14:21 +0200 To: "Peter Constable" , "LTRU Working Group" From: r&d afrac Subject: RE: [Ltru] Re: status? last call? 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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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 21:06 08/07/2005, Peter Constable wrote: > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] >On > > Behalf Of r&d afrac > > > > ISO 639-4 is the ISO document which commits on the consistency of ISO >639 > > series, 15924 and 3166 series. >ISO 639-4 does not attempt to ensure consistency in ISO 15924 or ISO >3166. > > > > ISO 639-4 is to describe the possible > > relations between these codes. The matter is debated and not made. It > > would > > be odd if IETF standardised relations between codes the authors of >that > > codes would identify as wrong. > >ISO 639-4 will describe in general terms that the ISO 639 codes can be >combined with other codes defined in other standards. It will not define >any specific constraints (e.g. that Latf cannot be used in combination >with zh), you speak of code elements. > nor will it impose any particular syntactic mechanisms for >combining different codes. Correlations are to be documented. Some propositions are fuzzy. I will not tell you that the Draft is verbose and incomplete in definitions: ISO texts tend to be much more concise and accurate. Standard call for a rigor in terminology I do not find in the Draft. As long I have not seen the approved ISO document I think it is a waste of time to want to acclimate it into the IETF. >Nothing being done in the draft for 3066bis is contrary to what is >anticipated in ISO 639-4. You are prophet? One is probable: this WG has voted "no" to ISO 11179. > > This is why we must do the things in > > sequence. Our charter is to deal with ISO 639. > >No, our charter is to revise RFC 3066. I don't see "deal with ISO 639" >anywhere in the charter. Oh! > > The author of ISO 639-3 > > being at the origin of all this effort, > >All what effort? AFAIK, the editor for 639-3 cannot claim to be the >origin for LTRU, work on 3066bis, 639-4, or even 639-3. Don't be so humble .... you made some progress since http://xml.coverpages.org/Constable-LanguageIdentificationIssues20020204.html and this is good. But some other priorities were added. > > I undersnand that he insisted on > > ISO 639-3. > >I have not insisted on anything to do with ISO 639-3 in the context of >LTRU. Suggestions for future developments, particularly in relation to >incorporation of 639-3 and in relation to extlang, have been made, and >there has been some broad consensus on general issues. But nothing has >transpired on the basis of my insistence. I meant that ISO 639-3 is specifically quoted in the Charter (I know ... it is not). There is no shame to that! Without you we would certainly not be so far. But the problem - that you very well evaluated BTW from the very beginning - is that this approach is for IT. Computers. Objects. The problem is all that is that you do not consider the most important difference between Unicode, W3C and IETF is that Unicode deals with static objects (a character is a character). W3C deals with dynamic objects (pages being accessed, web services, applications). IETF deals with interactive objects (networks), and this is not easy - all the more than this precise topic (multilingualism) deals a layer more above end to end interoperability, with person to person Interintelligbility and (I pretend) with community into community inculturation. The strength of RFC 3066 is to be lose. We all know it is incomplete, with errors, and not much respected. But this way it supports in a way the much wider scope to be dealt with. The Draft understands the problem, but tries to resolve it in an IT way, even in a static way, because Addison as a W3C knows that a web service, an XML page, an HTML page can work with it. And Mark Davis knows that he can accommodate Locales with that. But they fail to see that the Internet cannot accommodate that narrowing. So, when challenged they say the DNS is odious, the dont want to address Java, they dont really respond to LDAP, they ignore OPES, they say that CRCs are inflammatory, etc. That cannot work. I fully understand their problem. But understanding is not identifying and not resolving. This is why they must start with a recital of all the used words and give their meaning. So we understand what they want to talk about. From there we can help. Before we will stay in confusion for ever. RFC 3066 confusion was acceptable because it was not structured. The Draft is structured: confusion cannot play the same role as with RFC 3066. And the Charter tells us to fix the problems of RFC 3066. All your supporters can claim for years that I am disruptive, that I do not propose text changes, that this is a no starter, etc... that will not change that the Draft today is meaningless and adding text to a meaningless document (a part from the cosmetic proposed for the last three months) is impossible. Now, if you give it a meaning (which is very easy) you will be obliged to chose which meaning and this way to acknowledge it has a precise scope. Back to December: this scope is narrower than RFC 3066 and the Draft cannot be a replacement for BCP 47. What is a language in a network? What is a script in a network? What is a country in a network? What is the purpose of a langtag in a network? These are the basic questions. What are you talking about? There is a huge difference between a monologue (Unicode: I send), a dialogue (W3C - I send/receive one to one) and a polylogue (IETF - we exchange many to many all over the place). There is a big difference between the hardware of a typographer, the software if an IT engineer as you related SIL to, and the brainware of a cultural community. You made a comparison of SIL and linguasphere, and said SIL was more adapted to computer and linguasphere to understand the sociolinguistic elements. As a brainware person, I think you were right in a way, but as an English mother tongue person, you do not relate your culture as other people often do to your language (you probably see the American culture as more attached to the nation, the flag, the history, the literature). There are all the variations on Earth: as a French speaking person, I relate my culture to the capabilities of my language and my nation and history are more examples of the capacity of the language than the other way around. Great authors did not build French, they are natural by-products of the common people language and effort. There is no Shakespeare in French: there are millions of co-speakers. This certainly influenced our values. Franck could tell, but I suppose German is similar? Try to understand the African culture if you do not understand the coexistance of language, family, economy, poetry, in a quasi geographical continuity. What are going to mean there "sn, co, iv, bn, etc.???". But I also think you miss a layer above which is the noosphere of which the languages are the internal protocols. I will not buy Theilard and Engelbart ideas on SuperBrain, but what you are opposed today are the structures of this noosphere which say "no good" to your limitations. They can be very useful tools, practical solutions, etc. but not to manage the whole thing... That Draft can complement RFC 3066, not replace it. All what Randy can say will not change that: or it has to be rewritten, starting from a clean sheet analysis of the Charter .... This is why I proposed we co-write it at the beginning. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 16:38:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqzbx-0005lf-0c; Fri, 08 Jul 2005 16:38:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqzbu-0005g8-Ma for ltru@megatron.ietf.org; Fri, 08 Jul 2005 16:38:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26327 for ; Fri, 8 Jul 2005 16:38:08 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr03M-000254-5q for ltru@ietf.org; Fri, 08 Jul 2005 17:06:33 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqzbO-0005Z3-1f; Fri, 08 Jul 2005 13:37:38 -0700 Message-Id: <6.2.1.2.2.20050708222617.04e662b0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Jul 2005 22:36:25 +0200 To: "Randy Presuhn" , From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private UseTags In-Reply-To: <004301c583f2$6c063e80$7f1afea9@oemcomputer> References: <20050708091150.FDRY15546.mta1.adelphia.net@megatron.ietf.org> <010001c583cb$1b785d80$030aa8c0@DEWELL> <20050708164612.GD4776@NYCMJCOWA2> <004301c583f2$6c063e80$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 - afrac.org X-Spam-Score: 0.0 (/) 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 At 21:22 08/07/2005, Randy Presuhn wrote: >(2) "Private-use subtags require private agreement between parties > intending to use them. Use great caution if employing them in > content or protocols intended for general use. Private-use subtags > MUST conform to the format contraints specified in the ABNF. > Private-use subtags are useless for information exchange without > prior arrangement." I must apologise for the troll ... I knew you would respond this way. Randy, you bring nothing new, here. The ABNF is already a MUST. Repeating a law you cannot enforce is not what is expected. What is expected is you to define the verdict when your MUST is disregarded. You know that we will not respect that MUST. We fully documented it, we have an on-line site for that - and most probably many others will do it because - as Prof. F. Charles documented it - it does not make sense. I know you do not care about others, but nevertheless there will be a group of users (may be substantial) who will disregard the MUST. What the general developper wants to know is what is him to do in that case. I propose two responses. You may have another one. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 16:38:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqzbz-0005qc-5A; Fri, 08 Jul 2005 16:38:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqzbx-0005nL-V3 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 16:38:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26340 for ; Fri, 8 Jul 2005 16:38:11 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr03P-00025T-Vh for ltru@ietf.org; Fri, 08 Jul 2005 17:06:36 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DqzbM-0005Z3-Vb; Fri, 08 Jul 2005 13:37:37 -0700 Message-Id: <6.2.1.2.2.20050708221842.04e3feb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 08 Jul 2005 22:37:16 +0200 To: "Randy Presuhn" , From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1058] Referencing the tagging scheme In-Reply-To: <005001c583f3$49a0e560$7f1afea9@oemcomputer> References: <005001c583f3$49a0e560$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 21:28 08/07/2005, Randy Presuhn wrote: >Hi - >Ok, I think we've gone from a weak "accept" to a rough consensus >to reject this proposal. I've updated the ticket accordingly. > >If you think there is value in further discussion, please include the issue >number in the subject line. For my own culture, I would be interested in understanding what are your criteria for rough consensus. My reading of this question is that practical observation makes a kind of referencing de facto built-in in usage? It would be better to document how - this is related to updates, dates, etc. But it might call for a revamp of the document structure. So I agree that we drop the matter. But "reject" may discourage futher more interesting ideas. I liked the Kentucky press and their tagging system. Anyway, it is your show. Let it be your way. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 16:56:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqztc-0001aG-HD; Fri, 08 Jul 2005 16:56:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqztZ-0001a8-UB for ltru@megatron.ietf.org; Fri, 08 Jul 2005 16:56:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27422 for ; Fri, 8 Jul 2005 16:56:23 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr0L1-0002kL-6u for ltru@ietf.org; Fri, 08 Jul 2005 17:24:48 -0400 Received: from h-68-166-189-12.noclli.covad.net ([68.166.189.12] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqztR-0004yL-00 for ltru@ietf.org; Fri, 08 Jul 2005 16:56:18 -0400 Message-ID: <00a501c58400$134ff200$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org><009901c58382$89634a60$030aa8c0@DEWELL> <42CE3D2A.1067@xyzzy.claranet.de> Date: Fri, 8 Jul 2005 14:00:11 -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: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Ltru] issue #200 is resolved (was: Re: status? last call?) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: Friday, July 08, 2005 1:45 AM > Subject: [Ltru] Re: status? last call? > > Doug Ewell wrote: > > > I think it's a good idea to list the UN codes that were > > excluded from the registry and explain why. > > For _valid_ UN numbers at date-B I got the idea, and that > covers 831..833 for File-Date: 2005-07-05, even 830, tough. > > But not 200. the only "200" on their page belongs to 2005. > 200 is AFAIK also no "valid candidate for registration". > And it never was, so even a time machine wouldn't help. ... PLEASE keep the issue number in your postings. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 17:00:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqzxK-0003oH-R2; Fri, 08 Jul 2005 17:00:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqzxH-0003jd-Tr for ltru@megatron.ietf.org; Fri, 08 Jul 2005 17:00:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27641 for ; Fri, 8 Jul 2005 17:00:13 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr0Oj-0002up-OL for ltru@ietf.org; Fri, 08 Jul 2005 17:28:38 -0400 Received: from h-68-166-189-12.noclli.covad.net ([68.166.189.12] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DqzxF-0006HX-00 for ltru@ietf.org; Fri, 08 Jul 2005 17:00:13 -0400 Message-ID: <00a601c58400$a037b900$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org><009901c58382$89634a60$030aa8c0@DEWELL> <42CE3D2A.1067@xyzzy.claranet.de> Date: Fri, 8 Jul 2005 14:04:25 -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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] issues #875 and #878 (was: status? last call?) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: Friday, July 08, 2005 1:45 AM > Subject: [Ltru] Re: status? last call? ... > IANA: Are we sure that they manage it to extract the real > registry from your I-D ? Scott said "assume the worst" or > similar. > > Maybe a short note "remove page headers and three leading > spaces in all lines of chapter 3, the first line should > be the File-Date line" helps in the IANA considerations. ... As a technical contributor, I think this is overengineering. >From experience with other RFCs that establish registries, I know that IANA works closely with document editors and WG chairs in setting things up. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 17:13:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr0AH-0003mQ-KY; Fri, 08 Jul 2005 17:13:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr0AF-0003lk-TO for ltru@megatron.ietf.org; Fri, 08 Jul 2005 17:13:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28331 for ; Fri, 8 Jul 2005 17:13:37 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr0bi-0003Vp-6M for ltru@ietf.org; Fri, 08 Jul 2005 17:42:02 -0400 Received: from h-68-166-189-12.noclli.covad.net ([68.166.189.12] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr0AD-0002XB-00 for ltru@ietf.org; Fri, 08 Jul 2005 17:13:37 -0400 Message-ID: <00c301c58402$7f028600$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org><009901c58382$89634a60$030aa8c0@DEWELL> <42CE3D2A.1067@xyzzy.claranet.de> Subject: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Date: Fri, 8 Jul 2005 14:17: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.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: Friday, July 08, 2005 1:45 AM > Subject: [Ltru] Re: status? last call? ... > [eligible 3166 codes] > > No ISO 3166 codes fall into this category, only UN numeric > > codes. > > That's still wrong in draft -08 (2.2.4 3E). > > [830..833] > > Section 3.3 (11) of the registry draft now covers this. > > Really, it lists all four #1026 codes, why do they want that > you have a complete chapter about excatly the same four codes ? > IANA is most probably not interested what we do NOT register. > > >| The following code elements from [UN-M.49] were not assigned > >| as subtags in the initial Language Subtag Registry, and may > >| not be registered except as provided in Section 3.3 (item > >| 10E) of [I-D.ietf-ltru-registry]:" > > Okay (but get rid of 200). > > > I think draft-initial-02 will be just about ready for Last > > Call. > > ACK, but draft -08 2.2.4 3E might be still wrong, bye, Frank ... The text that is there in the -08 registry draft says: E. UN numeric codes and ISO 3166 alpha-2 codes for countries or areas listed as eligible for registration in [initial- registry] but not presently registered MAY be entered into the IANA registry via the process described in Section 3.4. Once registered, these codes MAY be used to form language tags. As a technical contributor, I think this is the right thing to do, but it sounds like Frank and I are having trouble reconciling it with, for example, Doug's understanding: "In regard to the general matter of registering UN numeric code elements for countries and country-like entities (as opposed to macro regions), I believe they should NOT be eligible for individual registration, so that they may remain available as the "last resort" option in case of ISO 3166 code conflicts." As a thought experiment, work through the "es-419" case using both approaches. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 17:18:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr0FD-00065Y-SY; Fri, 08 Jul 2005 17:18:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr0FD-00065F-D8 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 17:18:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00459 for ; Fri, 8 Jul 2005 17:18:44 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr0ge-0004Fm-Ue for ltru@ietf.org; Fri, 08 Jul 2005 17:47:09 -0400 Received: from h-68-166-189-12.noclli.covad.net ([68.166.189.12] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr0FA-000414-00 for ltru@ietf.org; Fri, 08 Jul 2005 17:18:44 -0400 Message-ID: <00ce01c58403$355d4340$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050629114419.FFKU24938.mta8.adelphia.net@megatron.ietf.org><009901c58382$89634a60$030aa8c0@DEWELL><42CE3D2A.1067@xyzzy.claranet.de> <00a501c58400$134ff200$7f1afea9@oemcomputer> Subject: Re: [Ltru] issue #900 is resolved (was: Re: status? last call?) Date: Fri, 8 Jul 2005 14:22: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.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 - ----- Original Message ----- > From: "Randy Presuhn" > To: > Sent: Friday, July 08, 2005 2:00 PM > Subject: [Ltru] issue #200 is resolved (was: Re: status? last call?) ... Ooops. Instead of issue #200, I meant issue #900, whose topic is code 200. The editors should ensure that their documents indeed reflect the resolution of that issue. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 17:56:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr0pv-00065T-1m; Fri, 08 Jul 2005 17:56:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr0pt-00065K-Dz for ltru@megatron.ietf.org; Fri, 08 Jul 2005 17:56:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07840 for ; Fri, 8 Jul 2005 17:56:39 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr1HL-0006tN-FZ for ltru@ietf.org; Fri, 08 Jul 2005 18:25:04 -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 j68LuUeL059628 for ; Fri, 8 Jul 2005 17:56:30 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j68LuTcC218156 for ; Fri, 8 Jul 2005 15:56:30 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j68LuTOU021765 for ; Fri, 8 Jul 2005 15:56:29 -0600 Received: from markdavis (sig-9-48-123-133.mts.ibm.com [9.48.123.133]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j68LuPSM021589; Fri, 8 Jul 2005 15:56:29 -0600 Message-ID: <025f01c58407$e26e63d0$6501a8c0@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , References: <6.0.0.20.2.20050705103622.0874cc40@itmail.it.aoyama.ac.jp> <038b01c58385$e0e63740$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #1058] Referencing the tagging scheme Date: Fri, 8 Jul 2005 14:55:02 -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.1506 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j68LuUeL059628 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 In those two messages, there was no firm proposal for a change that the editors could make. The only thing that approaching that was from Peter: "But, this is something that belongs in *consuming* protocols, not in this document. At most, this document can suggest that applications incorporate support for such meta-metadata."But that is not language, and Peter goes on to say:" Given that there are lots of existing applications= / consuming protocols of RFC 3066 that do *not* do this, and given that adding text of this sort isn't likely going to change them, I wouldn't make it a priority. "Which I agree with. So I see "no action" as the correct resolution.=E2=80=8EMark----- Original Message -----=20 From: "Randy Presuhn" To: Sent: Thursday, July 07, 2005 23:25 Subject: [Ltru] [psg.com #1058] Referencing the tagging scheme > Hi - > > The proposal is in message > http://www1.ietf.org/mail-archive/web/ltru/current/msg02535.html > Followed by discussion starting with message > http://www1.ietf.org/mail-archive/web/ltru/current/msg02536.html > > At this time, it sounds like we have some WG members strongly > in favor of the proposal, and some others who view it as neither > necessary nor harmful, so I plan to mark this one as "resolved", > assuming the editors will make the necessary changes. > > If there are technical objections to adopting this proposal, > this is your last chance to make them. > > 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@lists.ietf.org Fri Jul 08 17:58:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr0rb-0007xR-It; Fri, 08 Jul 2005 17:58:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr0rZ-0007xC-C1 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 17:58:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07935 for ; Fri, 8 Jul 2005 17:58:22 -0400 (EDT) Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr1Iz-0006ye-8N for ltru@ietf.org; Fri, 08 Jul 2005 18:26:48 -0400 Received: from h-68-166-189-12.noclli.covad.net ([68.166.189.12] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr0rQ-0003K1-00 for ltru@ietf.org; Fri, 08 Jul 2005 17:58:16 -0400 Message-ID: <001e01c58408$bbe24460$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <00a501c57c27$b8492fa0$7f1afea9@oemcomputer><6.2.1.2.2.20050629001557.04a7ee80@mail.afrac.org> <004101c57c65$69f2fb40$7f1afea9@oemcomputer> Subject: Re: [Ltru] Resolving issue #944 Date: Fri, 8 Jul 2005 15:02: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: 68c8cc8a64a9d0402e43b8eee9fc4199 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've marked issue #944 "resolved". (This is the lengthy discussion of length constraints) If you object, or believe still more discusssion of this topic is required, PLEASE include the issue number in your subject line. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 18:02:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr0vd-0001a8-PA; Fri, 08 Jul 2005 18:02:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr0vc-0001a3-DY for ltru@megatron.ietf.org; Fri, 08 Jul 2005 18:02:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08230 for ; Fri, 8 Jul 2005 18:02:33 -0400 (EDT) Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr1N5-000769-Mc for ltru@ietf.org; Fri, 08 Jul 2005 18:30:59 -0400 Received: from h-68-166-189-12.noclli.covad.net ([68.166.189.12] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr0vb-0004yr-00 for ltru@ietf.org; Fri, 08 Jul 2005 18:02:35 -0400 Message-ID: <002501c58409$54605a60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.0.0.20.2.20050705103622.0874cc40@itmail.it.aoyama.ac.jp> <038b01c58385$e0e63740$7f1afea9@oemcomputer> <025f01c58407$e26e63d0$6501a8c0@sanjose.ibm.com> Subject: Re: [Ltru] [psg.com #1058] Referencing the tagging scheme Date: Fri, 8 Jul 2005 15:06:02 -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: ea4ac80f790299f943f0a53be7e1a21a 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: "Mark Davis" > To: "Randy Presuhn" ; > Sent: Friday, July 08, 2005 2:55 PM > Subject: Re: [Ltru] [psg.com #1058] Referencing the tagging scheme > > In those two messages, there was no firm proposal for a change that the > editors could make. The only thing that approaching that was from Peter: > "But, this is something that belongs in *consuming* protocols, not in > this document. At most, this document can suggest that applications > incorporate support for such meta-metadata."But that is not language, and > Peter goes on to say:" Given that there are lots of existing applications / > consuming protocols > of RFC 3066 that do *not* do this, and given that adding text of this > sort isn't likely going to change them, I wouldn't make it a priority. > "Which I agree with. So I see "no action" as the correct > resolution.?Mark ... By "no action" do you mean (a) keep the ticket open, rather than rejecting it (its current status) (b) not adopt the proposed change (in any of the various flavours that appeared in the discussion) => mark the ticket "rejected" ? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 18:33:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1PE-0002Td-88; Fri, 08 Jul 2005 18:33:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1PC-0002PF-6v for ltru@megatron.ietf.org; Fri, 08 Jul 2005 18:33:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10902 for ; Fri, 8 Jul 2005 18:33:07 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr1qf-00082u-Fx for ltru@ietf.org; Fri, 08 Jul 2005 19:01:34 -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 j68MX0eL400128 for ; Fri, 8 Jul 2005 18:33:00 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j68MX0cC240088 for ; Fri, 8 Jul 2005 16:33:00 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j68MX0i5015365 for ; Fri, 8 Jul 2005 16:33:00 -0600 Received: from markdavis (sig-9-48-123-133.mts.ibm.com [9.48.123.133]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j68MWvxo015320; Fri, 8 Jul 2005 16:32:59 -0600 Message-ID: <029201c5840c$fd6cff20$6501a8c0@sanjose.ibm.com> From: "Mark Davis" To: "Dylan N. Pierce" , "Randy Presuhn" , References: <42CD543E.1060304@megared.net.mx> <20050707185227.GD876@NYCMJCOWA2> <008d01c58353$6969e900$7f1afea9@oemcomputer> <42CE134B.1000009@megared.net.mx><004601c58392$2d9795a0$7f1afea9@oemcomputer> <42CE4312.2080203@megared.net.mx> Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe) Private Use Tags Date: Fri, 8 Jul 2005 15:32:55 -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.1506 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j68MX0eL400128 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Private use tags serve a purpose; they do not need to be associated with = a region. I see no reason to make any change, nor do I see a reason to revi= sit all of this over and over again. =E2=80=8EMark ----- Original Message -----=20 From: "Dylan N. Pierce" To: "Randy Presuhn" ; Sent: Friday, July 08, 2005 02:10 Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe) Private Use Tags > Randy Presuhn wrote: > > Would a stronger version of this (or the following paragraphs address the > > concerns? If so, proposed text would be appreciated. > > Another way of looking at the concern. Reading from 4.5: > > "For example, the region subtags 'AA', 'ZZ' and in the ranges > 'QM'-'QZ' and 'XA'-'XZ' (derived from ISO 3166 private use codes) MAY > be used to form a language tag. A tag such as "zh-Hans-XQ" conveys a > great deal of public, interchangeable information about the language > material (that it is Chinese in the simplified Chinese script and is > suitable for some geographic region 'XQ'). While the precise > geographic region is not known outside of private agreement, the tag > conveys far more information than an opaque tag such as "x-someLang", > which contains no information about the language subtag or script > subtag outside of the private agreement." > > The tag "zh-Hans-XQ" provides enough information that parsing agents > know what they don't know: the region. The legitimate-but-opaque tag > "zh-Hans-x-whoKnows" might contain a privately-defined region... but if > so, why not use the first option? It also might contain something that'= s > completely outside the intended scope of the language tag. If we're > serious about what these tags are meant to represent, why make it > possible to work against it? This returns to the "scribble space" issue. > > I'm not sure a stronger version of the warning itself would clarify > this. It would have to say something like: > > "Private-use subtags require private agreement between the parties > that intend to use or exchange language tags that use them and they > MUST NOT be used in content or protocols intended for general use > unless it can be guaranteed that they will not inadvertently show up > in parsing agents used by other parties with private-use agreements > that coincedentally employ the same alphanumeric sequence." > > Which sounds ridiculous. Okay, yes, I intentionally made it sound > ridiculous, but this is the point: if we're documenting language, > region, script and variant, it's easy enough to indicate "unknown > region" when encountering a private-use region subtag. If you encounter > a pure private-use "x," all you know is that it is either an unknown > language, script, region or variant that doesn't want to admit it, or a= n > unknown something else that's outside the scope of the language tag > completely. > > What does allowing an unknown "something else" gain in clarity or > interoperability? Returning to Addison's original reply to my first > proposal (now withdrawn, but for this very reason), if the "something > else" really is legitimate, then a new RFC can be written to make use o= f > the reserved tags. If not, then it's in the wrong place, and if you've > ever tried to keep an office organized, you know that allowing folks to > put things in the wrong place is an excellent way to ensure that later > on, no one knows where to look for them (except, perhaps, by "private > agreement," which is how I keep from losing my coffee cup). > > So I guess at this point, what I am looking at isn't proposed new text, > or proposed changes in text, but a proposed elimination of text, to > whit, the text defining the private-use subtag "x". My question: is the > gain in "swallowing comfort" won by unregulated, unparsable private-use > tags worth the corresponding loss in clarity and interoperability? > > If the answer is an honest resounding "Yes" from everyone else with an > interest in this issue, I'll concede the point and go away. But if we'r= e > doing it just because we're just not willing to take that final step of > saying, "/This/ is what these tags define, and nothing else," because > we're nervous about the commitment, then I have a feeling we might be > making a mistake. > > Dylan > > _______________________________________________ > 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 Jul 08 18:34:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1Qs-0003AT-Pt; Fri, 08 Jul 2005 18:34:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1Qr-00035J-MW for ltru@megatron.ietf.org; Fri, 08 Jul 2005 18:34:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11015 for ; Fri, 8 Jul 2005 18:34:51 -0400 (EDT) Received: from rly-ip04.mx.aol.com ([64.12.138.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr1sB-00086G-0e for ltru@ietf.org; Fri, 08 Jul 2005 19:03:17 -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 RELAYIN5-642ceff7215c; Fri, 08 Jul 2005 18:34:26 -0400 Received: from DEBHOME (ACCBCB2A.ipt.aol.com [172.203.203.42]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j68MYG8F031659; Fri, 8 Jul 2005 18:34:16 -0400 Message-Id: <200507082234.j68MYG8F031659@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Mark Davis'" , "'Randy Presuhn'" , Subject: RE: [Ltru] [psg.com #1058] Referencing the tagging scheme Date: Fri, 8 Jul 2005 23:34:46 +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 In-Reply-To: <025f01c58407$e26e63d0$6501a8c0@sanjose.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWEB/UA16zGB9GLTauAhDymLZS/XwABDaCw X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.7 (++) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 Just to clarify as some people seem to have missed it... this is a copy = of the proposed text in my initial post: =93Implementers MAY reference this scheme within the language tag itself = using the following syntax: Language-Tag (Scheme_RFC_3066_bis) =3D ..." Which was then changed to: Language-Tag[RFC****]=3D... And further suggestions included: Language-Tag-RFC****=3D... One final word on this: Mark wrote: > Peter goes on to say:" Given that there are lots of existing = applications > / consuming protocols of RFC 3066 that do *not* do this, and given = that=20 > adding text of this sort isn't likely going to change them, I wouldn't = > make it a priority. Personally, I like to see new precedents being set... it's called = progress I believe... ;-) (no comments required) Regards Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] = On > Behalf Of Mark Davis > Sent: 08 July 2005 22:55 > To: Randy Presuhn; ltru@ietf.org > Subject: Re: [Ltru] [psg.com #1058] Referencing the tagging scheme >=20 > In those two messages, there was no firm proposal for a change that = the > editors could make. The only thing that approaching that was from = Peter: > "But, this is something that belongs in *consuming* protocols, not in > this document. At most, this document can suggest that applications > incorporate support for such meta-metadata."But that is not language, = and > Peter goes on to say:" Given that there are lots of existing = applications > / > consuming protocols > of RFC 3066 that do *not* do this, and given that adding text of this > sort isn't likely going to change them, I wouldn't make it a priority. > "Which I agree with. So I see "no action" as the correct > resolution.=FDMark----- Original Message ----- > From: "Randy Presuhn" > To: > Sent: Thursday, July 07, 2005 23:25 > Subject: [Ltru] [psg.com #1058] Referencing the tagging scheme >=20 >=20 > > Hi - > > > > The proposal is in message > > http://www1.ietf.org/mail-archive/web/ltru/current/msg02535.html > > Followed by discussion starting with message > > http://www1.ietf.org/mail-archive/web/ltru/current/msg02536.html > > > > At this time, it sounds like we have some WG members strongly > > in favor of the proposal, and some others who view it as neither > > necessary nor harmful, so I plan to mark this one as "resolved", > > assuming the editors will make the necessary changes. > > > > If there are technical objections to adopting this proposal, > > this is your last chance to make them. > > > > Randy, ltru co-chair > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > >=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 Fri Jul 08 18:38:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1Uf-00050H-Jq; Fri, 08 Jul 2005 18:38:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1Ue-000504-9y for ltru@megatron.ietf.org; Fri, 08 Jul 2005 18:38:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11339 for ; Fri, 8 Jul 2005 18:38:45 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr1w7-0008Ek-2x for ltru@ietf.org; Fri, 08 Jul 2005 19:07:11 -0400 Received: from h-64-105-137-104.noclli.covad.net ([64.105.137.104] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr1Ub-0000Ra-00 for ltru@ietf.org; Fri, 08 Jul 2005 18:38:45 -0400 Message-ID: <001c01c5840e$627b8d40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <42CD543E.1060304@megared.net.mx> <20050707185227.GD876@NYCMJCOWA2> <008d01c58353$6969e900$7f1afea9@oemcomputer> <42CE134B.1000009@megared.net.mx><004601c58392$2d9795a0$7f1afea9@oemcomputer> <42CE4312.2080203@megared.net.mx> <029201c5840c$fd6cff20$6501a8c0@sanjose.ibm.com> Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe) Private Use Tags Date: Fri, 8 Jul 2005 15:42: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.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: "Mark Davis" > To: "Dylan N. Pierce" ; "Randy Presuhn" ; > Sent: Friday, July 08, 2005 3:32 PM > Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe) Private Use Tags > > Private use tags serve a purpose; they do not need to be associated with a > region. I see no reason to make any change, nor do I see a reason to revisit > all of this over and over again. ... Rather than rehashing endlessly, please see http://www1.ietf.org/mail-archive/web/ltru/current/msg02617.html where I suggested we further narrow the debate in hopes of getting a resolution. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 18:39:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1V6-0005Fo-Sb; Fri, 08 Jul 2005 18:39:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1V4-0005Fj-W5 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 18:39:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11436 for ; Fri, 8 Jul 2005 18:39:12 -0400 (EDT) Received: from e35.co.us.ibm.com ([32.97.110.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr1wY-0008Fr-Cf for ltru@ietf.org; Fri, 08 Jul 2005 19:07:38 -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 j68Md5OM104182 for ; Fri, 8 Jul 2005 18:39:05 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j68Md5cC018446 for ; Fri, 8 Jul 2005 16:39:05 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j68Md4oD025833 for ; Fri, 8 Jul 2005 16:39:04 -0600 Received: from markdavis (sig-9-48-123-133.mts.ibm.com [9.48.123.133]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j68Md2m1025759; Fri, 8 Jul 2005 16:39:03 -0600 Message-ID: <029d01c5840d$d67f10a0$6501a8c0@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <009201c58380$07af2ae0$030aa8c0@DEWELL> <033a01c58382$19101a40$7f1afea9@oemcomputer> Subject: Re: Horizontal whitespace (was Re: [Ltru] Re: I-D ACTION:draft-ietf-ltru-initial-01.txt) Date: Fri, 8 Jul 2005 15:38:28 -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.1506 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e35.co.us.ibm.com id j68Md5OM104182 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 agree with the goal. I'd suggest explaining in a bit more detail, howev= er: Headers, footers, line breaks, and other vertical whitespace introduced by the RFC process are not significant. Leading horizontal whitespace indicates a continued line in the record-jar format, and must not be deleted.=3D> In the IANA registry that is produced from this document in the record-ja= r format, leading horizontal whitespace is significant, and indicates a continued line. However, in this document, headers, footers, line breaks, and other whitespace is introduced by the RFC process. To correctly interpret the data in this document, these extraneous characters must be disregarded. In particular, a number of horizontal whitespace characters that is greater than what is found on the 'File-Date' line indicates a continued line in the record-jar format, and must not be deleted. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Thursday, July 07, 2005 22:58 Subject: Horizontal whitespace (was Re: [Ltru] Re: I-D ACTION:draft-ietf-ltru-initial-01.txt) > Hi - > > > From: "Doug Ewell" > > To: "LTRU Working Group" > > Sent: Thursday, July 07, 2005 10:43 PM > > Subject: [Ltru] Re: I-D ACTION:draft-ietf-ltru-initial-01.txt > > > > The introductory paragraph in Section 3 says of the initial registry > > contents: > > > > "Leading horizontal whitespace indicates a continued line in the > > record-jar format, and must not be deleted." > > > > Unfortunately, the RFC process inserts three spaces before every line= in > > the registry (plain text version only, not HTML). I'm concerned that > > someone might infer that these spaces should be retained, which would= be > > a Bad Thing. All lines in a record-jar file, except continuation lin= es, > > must begin with a non-space. > > > > Therefore, I propose amending this sentence as follows: > > > > "Leading horizontal whitespace relative to the 'File-Date' line > > indicates a continued line in the record-jar format, and must not be > > deleted." > > > > Comments? > ... > > As a technical contributor, I like this pragmatic solution. > > 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 Fri Jul 08 18:49:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1f5-0008N7-Do; Fri, 08 Jul 2005 18:49:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1f3-0008Mp-Qa for ltru@megatron.ietf.org; Fri, 08 Jul 2005 18:49:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13379 for ; Fri, 8 Jul 2005 18:49:31 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr26X-0000bW-GY for ltru@ietf.org; Fri, 08 Jul 2005 19:17:57 -0400 Received: from h-64-105-137-104.noclli.covad.net ([64.105.137.104] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr1f2-0003Il-00 for ltru@ietf.org; Fri, 08 Jul 2005 18:49:32 -0400 Message-ID: <002701c5840f$e4cad0c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <009201c58380$07af2ae0$030aa8c0@DEWELL> <033a01c58382$19101a40$7f1afea9@oemcomputer> <029d01c5840d$d67f10a0$6501a8c0@sanjose.ibm.com> Date: Fri, 8 Jul 2005 15:53:43 -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: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Ltru] issue #1059 Horizontal whitespace X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: "Mark Davis" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Friday, July 08, 2005 3:38 PM > Subject: Re: Horizontal whitespace (was Re: [Ltru] Re: I-D ACTION:draft-ietf-ltru-initial-01.txt) > > I agree with the goal. I'd suggest explaining in a bit more detail, however: > > Headers, footers, line breaks, and other > vertical whitespace introduced by the RFC process are not > significant. Leading horizontal whitespace indicates a continued > line in the record-jar format, and must not be deleted.=> > > In the IANA registry that is produced from this document in the record-jar > format, leading horizontal whitespace is significant, and indicates a > continued line. However, in this document, headers, footers, line breaks, > and other whitespace is introduced by the RFC process. To correctly > interpret the data in this document, these extraneous characters must be > disregarded. In particular, a number of horizontal whitespace characters > that is greater than what is found on the 'File-Date' line indicates a > continued line in the record-jar format, and must not be deleted. ... As a contributor who has edited RFCs establishing registries, and who has chaired WGs producing such RFCs, I feel quite confident in saying that this is complete and total over-kill. We don't do this for ABNF, MIB modules, ASN.1 modules, or any of the other machine-parseable stuff that finds itself published in RFCs. The folks at IANA have repeatedly proven that they know enough to strip headers, footers, etc. I could support Doug's original proposal because it addressed a not-100%-obvious potential problem, but I can't support this amended proposal. If the rest of the WG supports it, I won't oppose it, but I think the amended proposal would set a bad precedent. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 18:51:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1gs-0001hq-E3; Fri, 08 Jul 2005 18:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1gq-0001dI-SR for ltru@megatron.ietf.org; Fri, 08 Jul 2005 18:51:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14003 for ; Fri, 8 Jul 2005 18:51:22 -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.43) id 1Dr28K-0000n1-Dc for ltru@ietf.org; Fri, 08 Jul 2005 19:19:48 -0400 Received: from uknsprd1 (unverified) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Fri, 8 Jul 2005 22:52:26 +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 <0IJB00FADZH1CJ@eupig2.dtc.lon.ime.reuters.com>; Fri, 08 Jul 2005 23:51:01 +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 Jul 2005 23:51:00 +0100 Date: Fri, 08 Jul 2005 23:50:59 +0100 From: Misha Wolf Subject: RE: [Ltru] [psg.com #1058] Referencing the tagging scheme To: Debbie Garside Message-id: <1987416CA83AC7499AC772F92E2DBF780413E0B6@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=windows-1255 Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] [psg.com #1058] Referencing the tagging scheme thread-index: AcWEB/UA16zGB9GLTauAhDymLZS/XwABDaCwAADKxcA= Content-Class: urn:content-classes:message X-OriginalArrivalTime: 08 Jul 2005 22:51:00.0193 (UTC) FILETIME=[82B0D510:01C5840F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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 I find this incomprehensible. What does it mean? Let's=20 say I have:

Yo!

=20 What, exactly, are you suggesting that I do? Misha -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On B= ehalf Of Debbie Garside Sent: 08 July 2005 23:35 To: 'Mark Davis'; 'Randy Presuhn'; ltru@ietf.org Subject: RE: [Ltru] [psg.com #1058] Referencing the tagging scheme Just to clarify as some people seem to have missed it... this is a copy of the proposed text in my initial post: =93Implementers MAY reference this scheme within the language tag itself us= ing the following syntax: Language-Tag (Scheme_RFC_3066_bis) =3D ..." Which was then changed to: Language-Tag[RFC****]=3D... And further suggestions included: Language-Tag-RFC****=3D... One final word on this: Mark wrote: > Peter goes on to say:" Given that there are lots of existing applications > / consuming protocols of RFC 3066 that do *not* do this, and given that= > adding text of this sort isn't likely going to change them, I wouldn't= > make it a priority. Personally, I like to see new precedents being set... it's called progress I believe... ;-) (no comments required) Regards Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Mark Davis > Sent: 08 July 2005 22:55 > To: Randy Presuhn; ltru@ietf.org > Subject: Re: [Ltru] [psg.com #1058] Referencing the tagging scheme >=20 > In those two messages, there was no firm proposal for a change that the > editors could make. The only thing that approaching that was from Peter: > "But, this is something that belongs in *consuming* protocols, not in > this document. At most, this document can suggest that applications > incorporate support for such meta-metadata."But that is not language, and > Peter goes on to say:" Given that there are lots of existing applications > / > consuming protocols > of RFC 3066 that do *not* do this, and given that adding text of this > sort isn't likely going to change them, I wouldn't make it a priority. > "Which I agree with. So I see "no action" as the correct > resolution.=FDMark----- Original Message ----- > From: "Randy Presuhn" > To: > Sent: Thursday, July 07, 2005 23:25 > Subject: [Ltru] [psg.com #1058] Referencing the tagging scheme >=20 >=20 > > Hi - > > > > The proposal is in message > > http://www1.ietf.org/mail-archive/web/ltru/current/msg02535.html > > Followed by discussion starting with message > > http://www1.ietf.org/mail-archive/web/ltru/current/msg02536.html > > > > At this time, it sounds like we have some WG members strongly > > in favor of the proposal, and some others who view it as neither > > necessary nor harmful, so I plan to mark this one as "resolved", > > assuming the editors will make the necessary changes. > > > > If there are technical objections to adopting this proposal, > > this is your last chance to make them. > > > > Randy, ltru co-chair > > > > > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > >=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 ----------------------------------------------------------------- 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 Fri Jul 08 19:09:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1yS-0001JH-GV; Fri, 08 Jul 2005 19:09:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1yQ-0001I3-Q4 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 19:09:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15584 for ; Fri, 8 Jul 2005 19:09:30 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr2Ps-0001dn-CC for ltru@ietf.org; Fri, 08 Jul 2005 19:37:57 -0400 Received: from h-64-105-137-104.noclli.covad.net ([64.105.137.104] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr1yI-0000At-00 for ltru@ietf.org; Fri, 08 Jul 2005 19:09:26 -0400 Message-ID: <007f01c58412$ab7868c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Date: Fri, 8 Jul 2005 16:13:36 -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: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ltru] [psg.com #1062] Add appendix of rationales / FAQ for key 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Recording another issue that I think has been wrapped up... > ------------------------------------------------------------------------- > In message > http://www1.ietf.org/mail-archive/web/ltru/current/msg02466.html > it was noted that several questions keep coming up from newcomers, > particularly with regard to subtag order. Should the rationale > for the decisions be added to an appendix, just as explanatory > material was added to explain length constraints? In follow-up postings, text was proposed and agreed. Although the result was not an appendex/faq per se, the essence of the issue was addressed, so I've marked this item resolved. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 19:09:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1ym-0001Pe-QO; Fri, 08 Jul 2005 19:09:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr1yl-0001Oq-EW for ltru@megatron.ietf.org; Fri, 08 Jul 2005 19:09:55 -0400 Received: from qmail.megared.net.mx (qmail.megared.net.mx [200.52.193.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15593 for ; Fri, 8 Jul 2005 19:09:52 -0400 (EDT) Received: (qmail 8395 invoked from network); 8 Jul 2005 23:09:23 -0000 Received: from unknown (HELO shield.megared.net.mx) ([10.0.57.151]) (envelope-sender ) by qmail.megared.net.mx (qmail-ldap-1.03) with SMTP for ; 8 Jul 2005 23:09:23 -0000 Received: from [192.168.2.170] ([10.60.88.84]) by shield.megared.net.mx (8.11.7/8.11.7) with ESMTP id j68N9N189784 for ; Fri, 8 Jul 2005 18:09:23 -0500 (CDT) Message-ID: <42CF079D.4000003@megared.net.mx> Date: Fri, 08 Jul 2005 18:09:17 -0500 From: "Dylan N. Pierce" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ltru@ietf.org Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private UseTags Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 Randy Presuhn wrote: > .... There are currently two proposals for text: > > (1) "Private-use subtags require private agreement between the parties > that intend to use or exchange language tags that use them and they > MUST NOT be used in content or protocols intended for general use > unless it can be guaranteed that they will not inadvertently show up > in parsing agents used by other parties with private-use agreements > that coincedentally employ the same alphanumeric sequence." > > (2) "Private-use subtags require private agreement between the parties > that intend to use or exchange language tags that use them. Great > caution SHOULD be used in employing them in content or protocols > intended for general use. Private-use subtags SHOULD respect the > general format contraints. Even used in a private context, general > libraries are legitimate in only using the part of each subtag which > matches the general ABNF [or in disregarding the subtags wich > does not match the general ABNF]. Private-use subtags are > simply useless for information exchange without prior arrangement." > > (2[a]) "Private-use subtags require private agreement between parties > intending to use them. Use great caution if employing them in > content or protocols intended for general use. Private-use subtags > MUST conform to the format contraints specified in the ABNF. > Private-use subtags are useless for information exchange without > prior arrangement." > > Randy How about a non-ridiculous middle ground? (3) "Private-use subtags require private agreement between parties intending to use them. They MUST NOT be designed for distribution outside of the private agreements for which they are intended. Tags intended for wider distribution SHOULD be registered instead as extensions with the [registration authority]. There MUST NOT be consequences for any application which chooses to ignore private use tags. Developers of private use tags should use great caution in ensuring that their applications are aware of, and can handle, the possibility of a conflicting private use tag from an external private agreement which appears similar to one of their own." If we can't get rid of them, after all, the least we can do is ensure that the poor working hacks like me receive a heads-up in unambiguous language. Programmers /do/ read these things, but we can't always assume they think through the implications well. No harm in throwing them a rope. --Dylan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 19:33:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2Lz-0006la-Vy; Fri, 08 Jul 2005 19:33:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2Lx-0006io-AE for ltru@megatron.ietf.org; Fri, 08 Jul 2005 19:33:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16831 for ; Fri, 8 Jul 2005 19:33:50 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr2nP-0002TX-BY for ltru@ietf.org; Fri, 08 Jul 2005 20:02:17 -0400 Received: from h-64-105-137-104.noclli.covad.net ([64.105.137.104] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr2Ls-0005kN-00 for ltru@ietf.org; Fri, 08 Jul 2005 19:33:48 -0400 Message-ID: <009101c58416$14677a80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <42CF079D.4000003@megared.net.mx> Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags Date: Fri, 8 Jul 2005 16:38: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: 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 Hi - > From: "Dylan N. Pierce" > To: > Sent: Friday, July 08, 2005 4:09 PM > Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe)Private UseTags ... > How about a non-ridiculous middle ground? > > (3) "Private-use subtags require private agreement between parties > intending to use them. They MUST NOT be designed for distribution > outside of the private agreements for which they are intended. Tags > intended for wider distribution SHOULD be registered instead as > extensions with the [registration authority]. There MUST NOT be > consequences for any application which chooses to ignore private use > tags. Developers of private use tags should use great caution in > ensuring that their applications are aware of, and can handle, the > possibility of a conflicting private use tag from an external private > agreement which appears similar to one of their own." > > If we can't get rid of them, after all, the least we can do is ensure > that the poor working hacks like me receive a heads-up in unambiguous > language. Programmers /do/ read these things, but we can't always assume > they think through the implications well. No harm in throwing them a rope. ... As a technical contributor, I agree whole-heartedly with your rationale. I'd tweak the proposal a bit... (4) "Private-use subtags require agreement between parties intending to use them. They MUST NOT be distributed beyond the scope of the relevant agreements. Subtags intended for wider distribution MUST be registered. Developers of private-use subtags are warned that, despite this prohibition, private-use subtags might "leak" beyond the scope of the agreement defining them. This means that applications making use of private-use tags need to be able to cope with conflicting (same character sequence but differing semantics) and unknown private-use tags. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 19:38:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2Q8-0008SD-EO; Fri, 08 Jul 2005 19: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 1Dr2Q7-0008S8-Fb for ltru@megatron.ietf.org; Fri, 08 Jul 2005 19:38:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17107 for ; Fri, 8 Jul 2005 19:38:08 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr2ra-0002b9-Jm for ltru@ietf.org; Fri, 08 Jul 2005 20:06: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 j68Nbru0015590; Fri, 8 Jul 2005 19:37:53 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 8 Jul 2005 19:37:53 -0400 Date: Fri, 8 Jul 2005 19:37:53 -0400 From: "John.Cowan" To: Randy Presuhn Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags Message-ID: <20050708233753.GJ4776@NYCMJCOWA2> References: <42CF079D.4000003@megared.net.mx> <009101c58416$14677a80$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009101c58416$14677a80$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.2.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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn scripsit: > (4) "Private-use subtags require agreement between parties > intending to use them. They MUST NOT be distributed beyond the scope > of the relevant agreements. Subtags intended for wider > distribution MUST be registered. Developers of private-use subtags are > warned that, despite this prohibition, private-use subtags might > "leak" beyond the scope of the agreement defining them. This means that > applications making use of private-use tags need to be able to cope with > conflicting (same character sequence but differing semantics) and unknown > private-use tags. Let's go with this language and close the issue. -- While staying with the Asonu, I met a man from John Cowan the Candensian plane, which is very much like jcowan@reutershealth.com ours, only more of it consists of Toronto. http://:www.ccil.org/~cowan --Ursula K. Le Guin, Changing Planes _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 19:52:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2e8-0000f4-U9; Fri, 08 Jul 2005 19:52:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2e6-0000ew-OU for ltru@megatron.ietf.org; Fri, 08 Jul 2005 19:52:39 -0400 Received: from qmail.megared.net.mx (qmail.megared.net.mx [200.52.193.180]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18022 for ; Fri, 8 Jul 2005 19:52:35 -0400 (EDT) Received: (qmail 21213 invoked from network); 8 Jul 2005 23:52:07 -0000 Received: from unknown (HELO shield.megared.net.mx) ([10.0.57.151]) (envelope-sender ) by qmail.megared.net.mx (qmail-ldap-1.03) with SMTP for ; 8 Jul 2005 23:52:07 -0000 Received: from [192.168.2.170] ([10.60.88.84]) by shield.megared.net.mx (8.11.7/8.11.7) with ESMTP id j68Nq7107267 for ; Fri, 8 Jul 2005 18:52:07 -0500 (CDT) Message-ID: <42CF11A1.8000906@megared.net.mx> Date: Fri, 08 Jul 2005 18:52:01 -0500 From: "Dylan N. Pierce" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ltru@ietf.org Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags References: <42CF079D.4000003@megared.net.mx> <009101c58416$14677a80$7f1afea9@oemcomputer> In-Reply-To: <009101c58416$14677a80$7f1afea9@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > (4) "Private-use subtags require agreement between parties > intending to use them. They MUST NOT be distributed beyond the scope > of the relevant agreements. Subtags intended for wider > distribution MUST be registered. Developers of private-use subtags are > warned that, despite this prohibition, private-use subtags might > "leak" beyond the scope of the agreement defining them. This means that > applications making use of private-use tags need to be able to cope with > conflicting (same character sequence but differing semantics) and unknown > private-use tags. I have no problem with any of the changes you made here; just one point on an omission which I'm willing to abandon immediately if my case is unconvincing. Regarding the line in my original: "There MUST NOT be consequences for any application which chooses to ignore private use tags." This, in my mind, was a protection against the MS-JVM phenomenon, where an organization with wide product distribution can implement its own private refinements, and then, simply through product saturation, win a position with products that don't quite "work" without their refinements. To make sure that even an enormous company or organization can't, simply through product share, implement a fait accompli adaptation of the standard. If that possibility doesn't bother anyone, I willingly abandon the petition on that line. Dylan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 20:01:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2mZ-0005bT-2S; Fri, 08 Jul 2005 20:01:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2mX-0005bG-K0 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 20:01:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18460 for ; Fri, 8 Jul 2005 20:01:18 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr3E1-0003Q9-L8 for ltru@ietf.org; Fri, 08 Jul 2005 20:29:45 -0400 Received: from h-64-105-137-104.noclli.covad.net ([64.105.137.104] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr2mV-0004JP-00 for ltru@ietf.org; Fri, 08 Jul 2005 20:01:19 -0400 Message-ID: <001601c58419$ec2f5160$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <42CF079D.4000003@megared.net.mx><009101c58416$14677a80$7f1afea9@oemcomputer> <42CF11A1.8000906@megared.net.mx> Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags Date: Fri, 8 Jul 2005 17:05: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.1 (/) 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 - > From: "Dylan N. Pierce" > To: > Sent: Friday, July 08, 2005 4:52 PM > Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags > > > (4) "Private-use subtags require agreement between parties > > intending to use them. They MUST NOT be distributed beyond the scope > > of the relevant agreements. Subtags intended for wider > > distribution MUST be registered. Developers of private-use subtags are > > warned that, despite this prohibition, private-use subtags might > > "leak" beyond the scope of the agreement defining them. This means that > > applications making use of private-use tags need to be able to cope with > > conflicting (same character sequence but differing semantics) and unknown > > private-use tags. > > I have no problem with any of the changes you made here; just one point > on an omission which I'm willing to abandon immediately if my case is > unconvincing. Regarding the line in my original: > > "There MUST NOT be consequences for any application which chooses to > ignore private use tags." > > This, in my mind, was a protection against the MS-JVM phenomenon, where > an organization with wide product distribution can implement its own > private refinements, and then, simply through product saturation, win a > position with products that don't quite "work" without their > refinements. To make sure that even an enormous company or organization > can't, simply through product share, implement a fait accompli > adaptation of the standard. > > If that possibility doesn't bother anyone, I willingly abandon the > petition on that line. ... To clarify... As a technical contributor, I had dropped the "consequences" sentence because I couldn't figure out exactly what it was supposed to mean, particularly in the RFC 2119 interpretation of the "MUST NOT" keyword. There isn't anything we can really do about a private-use subtag that enters the wider realm of discourse. Those familiar with SMTP and NNTP headers may be able to think of similar situations from the past. :-) It's one of the inherent risks of having this kind of mechanism, but it's already a legacy problem. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 20:06:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2rF-00005i-2u; Fri, 08 Jul 2005 20:06:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2rD-00005U-Kk for ltru@megatron.ietf.org; Fri, 08 Jul 2005 20:06:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18769 for ; Fri, 8 Jul 2005 20:06:08 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr3Ih-0003av-0T for ltru@ietf.org; Fri, 08 Jul 2005 20:34:36 -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 j69061KB007823 for ; Fri, 8 Jul 2005 20:06:01 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j69061Cf233322 for ; Fri, 8 Jul 2005 20:06:01 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j69061jL022998 for ; Fri, 8 Jul 2005 20:06:01 -0400 Received: from markdavis (sig-9-48-117-155.mts.ibm.com [9.48.117.155]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with SMTP id j6905x8e022971; Fri, 8 Jul 2005 20:06:00 -0400 Message-ID: <007b01c58419$fca5cba0$9b753009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , References: <6.0.0.20.2.20050705103622.0874cc40@itmail.it.aoyama.ac.jp><038b01c58385$e0e63740$7f1afea9@oemcomputer><025f01c58407$e26e63d0$6501a8c0@sanjose.ibm.com> <002501c58409$54605a60$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #1058] Referencing the tagging scheme Date: Fri, 8 Jul 2005 17:05:58 -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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e3.ny.us.ibm.com id j69061KB007823 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Mark it as rejected. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: Sent: Friday, July 08, 2005 15:06 Subject: Re: [Ltru] [psg.com #1058] Referencing the tagging scheme > Hi - > > > From: "Mark Davis" > > To: "Randy Presuhn" ; > > Sent: Friday, July 08, 2005 2:55 PM > > Subject: Re: [Ltru] [psg.com #1058] Referencing the tagging scheme > > > > In those two messages, there was no firm proposal for a change that t= he > > editors could make. The only thing that approaching that was from Pet= er: > > "But, this is something that belongs in *consuming* protocols, not in > > this document. At most, this document can suggest that applications > > incorporate support for such meta-metadata."But that is not language, and > > Peter goes on to say:" Given that there are lots of existing applications / > > consuming protocols > > of RFC 3066 that do *not* do this, and given that adding text of this > > sort isn't likely going to change them, I wouldn't make it a priority. > > "Which I agree with. So I see "no action" as the correct > > resolution.?Mark > ... > > By "no action" do you mean > (a) keep the ticket open, rather than rejecting it (its current stat= us) > (b) not adopt the proposed change (in any of the various flavours th= at > appeared in the discussion) =3D> mark the ticket "rejected" > ? > > 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@lists.ietf.org Fri Jul 08 20:09:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2ue-0002Dy-Pd; Fri, 08 Jul 2005 20:09:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr2ud-0002Dn-Q4 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 20:09:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18985 for ; Fri, 8 Jul 2005 20:09:40 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr3M6-0003m5-TZ for ltru@ietf.org; Fri, 08 Jul 2005 20:38:08 -0400 Received: from h-64-105-137-104.noclli.covad.net ([64.105.137.104] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr2uW-0006H5-00 for ltru@ietf.org; Fri, 08 Jul 2005 20:09:37 -0400 Message-ID: <004701c5841b$14dae380$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.0.0.20.2.20050705103622.0874cc40@itmail.it.aoyama.ac.jp><038b01c58385$e0e63740$7f1afea9@oemcomputer><025f01c58407$e26e63d0$6501a8c0@sanjose.ibm.com> <002501c58409$54605a60$7f1afea9@oemcomputer> <007b01c58419$fca5cba0$9b753009@sanjose.ibm.com> Subject: Re: [Ltru] [psg.com #1058] Referencing the tagging scheme Date: Fri, 8 Jul 2005 17:13: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.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: "Mark Davis" > To: "Randy Presuhn" ; > Sent: Friday, July 08, 2005 5:05 PM > Subject: Re: [Ltru] [psg.com #1058] Referencing the tagging scheme > > Mark it as rejected. ... Happened nearly five hours ago. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 20:25:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr39k-0002X2-GI; Fri, 08 Jul 2005 20:25:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr39i-0002Wt-OY for ltru@megatron.ietf.org; Fri, 08 Jul 2005 20:25:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19690 for ; Fri, 8 Jul 2005 20:25:17 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr3bD-0004G3-9Q for ltru@ietf.org; Fri, 08 Jul 2005 20:53:43 -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 j690P9bU021448 for ; Fri, 8 Jul 2005 20:25:09 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j690P93u257388 for ; Fri, 8 Jul 2005 20:25:09 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j690P9fk016005 for ; Fri, 8 Jul 2005 20:25:09 -0400 Received: from markdavis (sig-9-48-117-155.mts.ibm.com [9.48.117.155]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with SMTP id j690P7Oj015977; Fri, 8 Jul 2005 20:25:08 -0400 Message-ID: <009501c5841c$a8d047a0$9b753009@sanjose.ibm.com> From: "Mark Davis" To: "John.Cowan" , "Randy Presuhn" References: <42CF079D.4000003@megared.net.mx><009101c58416$14677a80$7f1afea9@oemcomputer> <20050708233753.GJ4776@NYCMJCOWA2> Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags Date: Fri, 8 Jul 2005 17:25: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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e6.ny.us.ibm.com id j690P9bU021448 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 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 We can't say: >> They MUST NOT be distributed beyond the scope > > of the relevant agreements. since people doing the distribution may not know what the scope is. >> Subtags intended for wider > > distribution MUST be registered. This is not actionable. wider than what? If I am using a protocol that transports language tags, is it incumbent upon me to examine the meaning = of all of them? I think not. The only thing we can really say is that: - don't use private use tags if you can at all avoid it - the only meaning they have is up to private agreement between parties - be aware if you do use them that they have no meaning -- or a different meaning! -- outside of the scope of a particular private agreement. Randy's original is better: > (2) "Private-use subtags require private agreement between parties > intending to use them. Use great caution if employing them in > content or protocols intended for general use. Private-use subtags > MUST conform to the format contraints specified in the ABNF. > Private-use subtags are useless for information exchange without > prior arrangement." Except that the "Private-use subtags MUST conform to the format constrain= ts specified in the ABNF." is redundant. ALL subtags must conform to the for= mat constraints specified in the ABNF. So I would just suggest the simpler (2) "Private-use subtags have no meaning outside of a private agreement between parties. They may also be given different meanings by different private agreements between those or other parties. Thus they SHOULD NOT b= e used wherever there is alternative, and they SHOULD NOT be used in conten= t or protocols intended for general use. =E2=80=8EMark ----- Original Message -----=20 From: "John.Cowan" To: "Randy Presuhn" Cc: Sent: Friday, July 08, 2005 16:37 Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use T= ags > Randy Presuhn scripsit: > > > (4) "Private-use subtags require agreement between parties > > intending to use them. They MUST NOT be distributed beyond the scop= e > > of the relevant agreements. Subtags intended for wider > > distribution MUST be registered. Developers of private-use subtags = are > > warned that, despite this prohibition, private-use subtags might > > "leak" beyond the scope of the agreement defining them. This means that > > applications making use of private-use tags need to be able to cope with > > conflicting (same character sequence but differing semantics) and unknown > > private-use tags. > > Let's go with this language and close the issue. > > --=20 > While staying with the Asonu, I met a man from John Cowan > the Candensian plane, which is very much like jcowan@reutershealth.com > ours, only more of it consists of Toronto. http://:www.ccil.org/~cowan > --Ursula K. Le Guin, Changing Planes > > _______________________________________________ > 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 Jul 08 20:56:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr3dg-0003vd-4D; Fri, 08 Jul 2005 20:56:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr3de-0003sd-Ko for ltru@megatron.ietf.org; Fri, 08 Jul 2005 20:56:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21734 for ; Fri, 8 Jul 2005 20:56:12 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr459-0005Ha-3p for ltru@ietf.org; Fri, 08 Jul 2005 21:24:39 -0400 Received: from h-64-105-137-104.noclli.covad.net ([64.105.137.104] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr3dc-00027g-00 for ltru@ietf.org; Fri, 08 Jul 2005 20:56:12 -0400 Message-ID: <016201c58421$970fa7e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <42CF079D.4000003@megared.net.mx><009101c58416$14677a80$7f1afea9@oemcomputer> <20050708233753.GJ4776@NYCMJCOWA2> <009501c5841c$a8d047a0$9b753009@sanjose.ibm.com> Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags Date: Fri, 8 Jul 2005 18:00: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: 4b800b1eab964a31702fa68f1ff0e955 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: "Mark Davis" > To: "John.Cowan" ; "Randy Presuhn" > Cc: > Sent: Friday, July 08, 2005 5:25 PM > Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags > > We can't say: > > >> They MUST NOT be distributed beyond the scope > > > of the relevant agreements. > > since people doing the distribution may not know what the scope is. That's the point of using an RFC 2119 "MUST NOT". It means "things won't work if you do this". > >> Subtags intended for wider > > > distribution MUST be registered. > > This is not actionable. wider than what? If I am using a protocol that > transports language tags, is it incumbent upon me to examine the meaning of > all of them? I think not. No. Again, this is an RFC 2119 "MUST". It means, "in order for things to work correctly , you have to do this". It is not imposing a requirement on the things that shovel tags around, just on the entity (which may be a human) that decides how to tag something. > The only thing we can really say is that: > - don't use private use tags if you can at all avoid it > - the only meaning they have is up to private agreement between parties > - be aware if you do use them that they have no meaning -- or a different > meaning! -- outside of the scope of a particular private agreement. Here we're agreed. > Randy's original is better: > > > (2) "Private-use subtags require private agreement between parties > > intending to use them. Use great caution if employing them in > > content or protocols intended for general use. Private-use subtags > > MUST conform to the format contraints specified in the ABNF. > > Private-use subtags are useless for information exchange without > > prior arrangement." > > Except that the "Private-use subtags MUST conform to the format constraints > specified in the ABNF." is redundant. ALL subtags must conform to the format > constraints specified in the ABNF. So I would just suggest the simpler The reason I included the redundant element is because there indications that someone plans to disregard the ABNF in their implementation. Such is their right, but I don't want them to have any excuses when things don't work correctly. > (2) "Private-use subtags have no meaning outside of a private agreement > between parties. They may also be given different meanings by different > private agreements between those or other parties. Thus they SHOULD NOT be > used wherever there is alternative, and they SHOULD NOT be used in content > or protocols intended for general use. ... I could also live with this, if it will allow us to put this item to rest, though I'd prefer if the second "SHOULD NOT" were a "MUST NOT". Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 08 21:17:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr3xv-0006qo-DY; Fri, 08 Jul 2005 21: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 1Dr3xs-0006qe-T1 for ltru@megatron.ietf.org; Fri, 08 Jul 2005 21:17:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22571 for ; Fri, 8 Jul 2005 21:17:07 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr4PN-0005rt-DL for ltru@ietf.org; Fri, 08 Jul 2005 21:45:33 -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 j691GpeL286878 for ; Fri, 8 Jul 2005 21:16:51 -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 j691GpgJ418912 for ; Fri, 8 Jul 2005 19:16:51 -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 j691GpJ2016284 for ; Fri, 8 Jul 2005 19:16:51 -0600 Received: from markdavis (sig-9-48-118-49.mts.ibm.com [9.48.118.49]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j691Gm1n016268; Fri, 8 Jul 2005 19:16:50 -0600 Message-ID: <002701c58423$e11e0550$6501a8c0@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , References: <42CF079D.4000003@megared.net.mx><009101c58416$14677a80$7f1afea9@oemcomputer><20050708233753.GJ4776@NYCMJCOWA2><009501c5841c$a8d047a0$9b753009@sanjose.ibm.com> <016201c58421$970fa7e0$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags Date: Fri, 8 Jul 2005 18:16: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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j691GpeL286878 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 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 > > Except that the "Private-use subtags MUST conform to the format constraints > > specified in the ABNF." is redundant. ALL subtags must conform to the format > > constraints specified in the ABNF. So I would just suggest the simple= r > > The reason I included the redundant element is because there indication= s > that someone plans to disregard the ABNF in their implementation. Such > is their right, but I don't want them to have any excuses when things > don't work correctly. The thing that bothers me is that some might conclude that *other* subtag= s don't have to conform to the format constraints. So how about: Private-use subtags, like all other subtags, MUST conform to the format constraints specified in the ABNF. > > > (2) "Private-use subtags have no meaning outside of a private agreeme= nt > > between parties. They may also be given different meanings by differe= nt > > private agreements between those or other parties. Thus they SHOULD N= OT be > > used wherever there is alternative, and they SHOULD NOT be used in content > > or protocols intended for general use. > ... > > I could also live with this, if it will allow us to put this item to re= st, > though I'd prefer if the second "SHOULD NOT" were a "MUST NOT". I thought of saying MUST NOT, but that is too strong. There may be a priv= ate use tag for something that is later added. You wouldn't want to say that = the tag is then not conformant. So I suggest the language plus the format cla= use you wanted: (2) "Private-use subtags have no meaning outside of a private agreement between parties. They may also be given different meanings by different private agreements between those or other parties. Thus they SHOULD NOT b= e used wherever there is alternative, and they SHOULD NOT be used in conten= t or protocols intended for general use. Private-use subtags, like all othe= r subtags, MUST conform to the format constraints specified in the ABNF. What do you think of that? =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: Sent: Friday, July 08, 2005 18:00 Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use T= ags > Hi - > > > From: "Mark Davis" > > To: "John.Cowan" ; "Randy Presuhn" > > Cc: > > Sent: Friday, July 08, 2005 5:25 PM > > Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private U= se Tags > > > > We can't say: > > > > >> They MUST NOT be distributed beyond the scope > > > > of the relevant agreements. > > > > since people doing the distribution may not know what the scope is. > > That's the point of using an RFC 2119 "MUST NOT". It means "things > won't work if you do this". > > > >> Subtags intended for wider > > > > distribution MUST be registered. > > > > This is not actionable. wider than what? If I am using a protocol tha= t > > transports language tags, is it incumbent upon me to examine the mean= ing of > > all of them? I think not. > > No. Again, this is an RFC 2119 "MUST". It means, "in order for things > to work correctly , you have to do this". It is not imposing a requirement > on the things that shovel tags around, just on the entity (which may be= a human) > that decides how to tag something. > > > The only thing we can really say is that: > > - don't use private use tags if you can at all avoid it > > - the only meaning they have is up to private agreement between parti= es > > - be aware if you do use them that they have no meaning -- or a different > > meaning! -- outside of the scope of a particular private agreement. > > Here we're agreed. > > > Randy's original is better: > > > > > (2) "Private-use subtags require private agreement between parties > > > intending to use them. Use great caution if employing them in > > > content or protocols intended for general use. Private-use subt= ags > > > MUST conform to the format contraints specified in the ABNF. > > > Private-use subtags are useless for information exchange withou= t > > > prior arrangement." > > > > Except that the "Private-use subtags MUST conform to the format constraints > > specified in the ABNF." is redundant. ALL subtags must conform to the format > > constraints specified in the ABNF. So I would just suggest the simple= r > > The reason I included the redundant element is because there indication= s > that someone plans to disregard the ABNF in their implementation. Such > is their right, but I don't want them to have any excuses when things > don't work correctly. > > > (2) "Private-use subtags have no meaning outside of a private agreeme= nt > > between parties. They may also be given different meanings by differe= nt > > private agreements between those or other parties. Thus they SHOULD N= OT be > > used wherever there is alternative, and they SHOULD NOT be used in content > > or protocols intended for general use. > ... > > I could also live with this, if it will allow us to put this item to re= st, > though I'd prefer if the second "SHOULD NOT" were a "MUST NOT". > > 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 Fri Jul 08 23:02:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr5bf-0006gq-LX; Fri, 08 Jul 2005 23:02:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr5be-0006gk-0S for ltru@megatron.ietf.org; Fri, 08 Jul 2005 23:02:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02990 for ; Fri, 8 Jul 2005 23:02:15 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr639-0002Xd-Vc for ltru@ietf.org; Fri, 08 Jul 2005 23:30:44 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dr5bY-0004dD-5h; Fri, 08 Jul 2005 20:02:12 -0700 Message-Id: <6.2.1.2.2.20050709040106.0567d070@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 09 Jul 2005 04:44:15 +0200 To: "Mark Davis" , "Randy Presuhn" , From: r&d afrac Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags In-Reply-To: <002701c58423$e11e0550$6501a8c0@sanjose.ibm.com> References: <42CF079D.4000003@megared.net.mx> <009101c58416$14677a80$7f1afea9@oemcomputer> <20050708233753.GJ4776@NYCMJCOWA2> <009501c5841c$a8d047a0$9b753009@sanjose.ibm.com> <016201c58421$970fa7e0$7f1afea9@oemcomputer> <002701c58423$e11e0550$6501a8c0@sanjose.ibm.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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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:16 09/07/2005, Mark Davis wrote: >(2) "Private-use subtags have no meaning outside of a private agreement >between parties. They may also be given different meanings by different >private agreements between those or other parties. Thus they SHOULD NOT be >used wherever there is alternative, and they SHOULD NOT be used in content >or protocols intended for general use. Private-use subtags, like all other >subtags, MUST conform to the format constraints specified in the ABNF. > >What do you think of that? Dear Mark and Randy, I submit that this is not a very important change in text, but it translates an important change in the spirit of RFC 3066. This is a true lack of spirit retrocompatibility. I have nothing against that. To the contrary the abandon of strict retrocompatbility permits interesting other innovations. But I do not want to suggest them without being supported by a consensus, otherwise Randy will say I rise closed issues. There are 57 folks on this list. I suppose that we could say that this proposition is supported by a consensus if 29 (50% +1) supports it. Either this proposition is adopted by consensus (I support it), strict retrocompatibility is forgotten: then I will propose something everyone could agree with to replace x-tags (but which would be opposed now on the grounds of retrocompatibility) - or it is not and we will continue with x-tags. So please every supporter of this change, and/or opponent to x-tags as we want to use them rises hand or humms. Those who supports x-tags, IMHO you can support Mark's text because if strict retrocompatibility is abandonned, the solution I would propose could even be better. But there is no need to work on it if there is not a real consensus. Thank you. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 09 01:20:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr7ln-0005OM-SY; Sat, 09 Jul 2005 01:20:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr7ln-0005Mt-2N for ltru@megatron.ietf.org; Sat, 09 Jul 2005 01:20: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 BAA10870 for ; Sat, 9 Jul 2005 01:20: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 <20050709052023.FSWG24042.mta11.adelphia.net@DEWELL> for ; Sat, 9 Jul 2005 01:20:23 -0400 Message-ID: <004c01c58445$e2efbfa0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050708091150.FDRY15546.mta1.adelphia.net@megatron.ietf.org> Date: Fri, 8 Jul 2005 22:20: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 Cc: Subject: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags Dylan N. Pierce wrote: > But if it's doing "Just this," then let's put our money where our > mouths are and say, "Just this." We don't need private use tags at > all if we are in agreement that corollary information, no matter how > closely related, should be handled outside the tag and, as Randy > notes, we shouldn't encourage the twisting of the tag by saying, > "Here's your scribble area." I don't think it's a matter of encouraging. Users who want to twist the tag will do so, whether we want them to or not. Private-use subtags in "x-" give them a way to stay conformant while still tacking private crud onto the end of a tag, and it gives tag consumers a way to stay conformant while choosing to either (a) attempt to interpret the crud or (b) ignore it. > Cripes, all of XML is the scribble area; we can afford > to keep the tag clean. This language-tag thing isn't just for XML, as we've said. Randy replied: > Would a stronger version of this (or the following paragraphs address > the concerns? If so, proposed text would be appreciated. I think Section 4.5 is strong enough as it is. It says that PU tagging requires a private agreement, which is true. It says to be cautious about allowing them to leak into the general environment, which is true. It employs the rather strong word "useless." I don't see much benefit in either removing the feature or beating users over the head with warnings not to use it. More later, as I get to additional messages on this topic. I'm making my way through 5 digests' worth of LTRU material, which I do NOT get a chance to respond to while I'm at 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@lists.ietf.org Sat Jul 09 01:31:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr7w7-0002eb-9S; Sat, 09 Jul 2005 01:31:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr7w6-0002dK-0T for ltru@megatron.ietf.org; Sat, 09 Jul 2005 01:31: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 BAA11809 for ; Sat, 9 Jul 2005 01:31:32 -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 <20050709053102.SARR29002.mta9.adelphia.net@DEWELL> for ; Sat, 9 Jul 2005 01:31:02 -0400 Message-ID: <005901c58447$6211b800$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050708091150.FDRY15546.mta1.adelphia.net@megatron.ietf.org> Date: Fri, 8 Jul 2005 22:30: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 Cc: Subject: [Ltru] [psg.com #900] Re: status? last call? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > For _valid_ UN numbers at date-B I got the idea, and that > covers 831..833 for File-Date: 2005-07-05, even 830, tough. > > But not 200. the only "200" on their page belongs to 2005. > 200 is AFAIK also no "valid candidate for registration". > And it never was, so even a time machine wouldn't help. OK, if nobody else objects, I agree to remove 200 from Section 4 of draft-initial-02. > IANA: Are we sure that they manage it to extract the real > registry from your I-D ? Scott said "assume the worst" or > similar. > > Maybe a short note "remove page headers and three leading > spaces in all lines of chapter 3, the first line should > be the File-Date line" helps in the IANA considerations. I thought this was already clear enough in the introductory text to Section 3. I suppose I could add a pointer to that text in the "IANA Considerations" section. Actually repeating the text seems quite unnecessary. > Some comments like "replaced by ISO code lb" aren't strictly > necessary, the Prefered-Value: lb is clear. But no problem. I completely agree about the sheer uselessness of comments like this, whose information is wholly duplicated within other fields. I don't like them, and didn't want to put them in. But others seems to like them. >> No ISO 3166 codes fall into this category, only UN numeric >> codes. > > That's still wrong in draft -08 (2.2.4 3E). The fact that (3E) says unassigned UN codes may be registered is wrong, and inconsistent with Section 3.3 (11), and needs to be fixed. (This is my opinion, and subsequent messages showed there is not complete agreement about this. More later.) The fact that (3E) also mentions ISO codes is not much of a problem; it is not incumbent on draft-registry to reflect the exact contents of draft-initial (if so, the latter would be unnecessary). But the rules would be different: ISO codes not already included would be registrable, while UN codes would not. > Really, it lists all four #1026 codes, why do they want that > you have a complete chapter about excatly the same four codes ? > IANA is most probably not interested what we do NOT register. But readers might be. It's not a long chapter. -- 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 Jul 09 01:53:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr8HP-0006qW-QK; Sat, 09 Jul 2005 01:53:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr8HN-0006qO-Sa for ltru@megatron.ietf.org; Sat, 09 Jul 2005 01:53:33 -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 BAA12815 for ; Sat, 9 Jul 2005 01:53:29 -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 <20050709055256.SMXQ29002.mta9.adelphia.net@DEWELL> for ; Sat, 9 Jul 2005 01:52:56 -0400 Message-ID: <006001c5844a$6fa11080$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050708091150.FDRY15546.mta1.adelphia.net@megatron.ietf.org> Date: Fri, 8 Jul 2005 22:52: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: [psg.com #1061] eliminate (or proscribe) Private Use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Dylan N. Pierce wrote: > The tag "zh-Hans-XQ" provides enough information that parsing agents > know what they don't know: the region. The legitimate-but-opaque tag > "zh-Hans-x-whoKnows" might contain a privately-defined region... but > if so, why not use the first option? It also might contain something > that's completely outside the intended scope of the language tag. If > we're serious about what these tags are meant to represent, why make > it possible to work against it? This returns to the "scribble space" > issue. Private-use regions should be encoded as "XQ" (or whatever), private-use scripts as "Qaaa" (or whatever), and so forth. I do not question that. Private-use subtags of the form "x-whoKnows" are best used for concepts that, if registered, would take the form of a variant or an extension -- something for which built-in private-use areas are not available. I agree completely that "zh-Hans-XQ" is better than "zh-Hans-x-whoKnows", *IF* the private-use thing in question is a region. But if the tagger is attempting to indicate a spoken accent, or some other attribute of the language variety other than region, and doesn't have a registered variant or extension RFC to turn to, then the subtag in "x-" is really her only alternative. > I'm not sure a stronger version of the warning itself would clarify > this. It would have to say something like: > > "Private-use subtags require private agreement between the parties > that intend to use or exchange language tags that use them and they > MUST NOT be used in content or protocols intended for general use > unless it can be guaranteed that they will not inadvertently show up > in parsing agents used by other parties with private-use agreements > that coincedentally employ the same alphanumeric sequence." I think this is far too strong. It is impossible to "guarantee" that such leakage, even if inadvertent, will not occur. It is possible to encourage taggers strongly not to toss these things out into the marketplace willy-nilly, as some sort of corporate de-facto standard (Dylan talks about this later), and it might be a good idea to add such wording. But I think MUST NOT goes too far. > What does allowing an unknown "something else" gain in clarity or > interoperability? The ability to concoct a private agreement and achieve interoperability within the confines of that agreement. > So I guess at this point, what I am looking at isn't proposed new > text, or proposed changes in text, but a proposed elimination of text, > to whit, the text defining the private-use subtag "x". My question: > is the gain in "swallowing comfort" won by unregulated, unparsable > private-use tags worth the corresponding loss in clarity and > interoperability? It doesn't tend to work out that way. Currently, RFC 3066 allows private-use whole-tags (not subtags) of the form "x-whoKnows" (which of course are much less interoperable than "zh-Hans-x-whoKnows" since they don't contain ANY publicly understood information), and it turns out that there is no great problem with private-use x-tags being generated and spread all over the internet and elsewhere. They just aren't that common in the real world. (In fact, during the "matching" portion of our show, we heard repeatedly that many existing tag parsers assume all RFC 3066 tags are of the form "xx" or "xx-xx" and would choke on script subtags; these parsers obviously would choke on private tags as well.) In short, I think the problem is overstated. -- 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 Jul 09 02:07:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr8VH-0006vP-GA; Sat, 09 Jul 2005 02:07:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr8VF-0006pV-GH for ltru@megatron.ietf.org; Sat, 09 Jul 2005 02:07: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 CAA21157 for ; Sat, 9 Jul 2005 02:07:51 -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 <20050709060718.SBQR19267.mta10.adelphia.net@DEWELL> for ; Sat, 9 Jul 2005 02:07:18 -0400 Message-ID: <006501c5844c$716bd380$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050708202214.FJXR27419.mta2.adelphia.net@megatron.ietf.org> Date: Fri, 8 Jul 2005 23:07: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: Subject: [Ltru] Re: status? last call? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 r&d afrac wrote: > No. I say directly or indirectly you cannot reference an third party. I've never heard of a requirement for RFCs, or even BCPs, that says informative references may only consist of ISO standards and other RFCs. Can you point me to a reference? > Unicode is a consortium of private interets, the same as W3C, etc. I don't see how this is relevant, but would it make a difference if we referenced ISO/IEC 10646 instead? Can you point me to a reference that says the work of an industry consortium may not be cited in an RFC? > This WG is to deal with ISO 639, 3166 and 15924, plus UN M.49 (in a > way I partly disagree with because the format is confusing). Outside > of that no other code has been accepted: because no other maintainer > has committed to stay compatible with these codes and her commitment > accepted by the IETF. Both Unicode and ISO 10646 are referenced in numerous RFCs. >> I don't see what ISO 639-4 has to do with any of this. > > ISO 639-4 is the ISO document which commits on the consistency of ISO > 639 series, 15924 and 3166 series. ISO 639-4 is a committee draft. We can't be required to adhere to a standard that doesn't exist yet. > The author of ISO 639-3 being at the origin of all this effort, I > undersnand that he insisted on ISO 639-3. This comment is not relevant to the document under discussion, which does not support ISO 639-3. (It can't, since that standard is also in draft stage.) -- 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 Jul 09 02:13:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr8YX-0000bY-EG; Sat, 09 Jul 2005 02: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 1Dr8YU-0000Z8-K1 for ltru@megatron.ietf.org; Sat, 09 Jul 2005 02:11: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 CAA24450 for ; Sat, 9 Jul 2005 02:11:12 -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 <20050709061042.TYVF14360.mta13.adelphia.net@DEWELL> for ; Sat, 9 Jul 2005 02:10:42 -0400 Message-ID: <006a01c5844c$e9895680$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050708202214.FJXR27419.mta2.adelphia.net@megatron.ietf.org> Date: Fri, 8 Jul 2005 23:10: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 Cc: Subject: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > I can't support (2) in its current form, but could live with a > modified version of (2) that I'll call (2a): > > (2) "Private-use subtags require private agreement between parties > intending to use them. Use great caution if employing them in > content or protocols intended for general use. Private-use subtags > MUST conform to the format contraints specified in the ABNF. > Private-use subtags are useless for information exchange without > prior arrangement." Stop right there. That one is great; let's go with it. (Well, OK, let's spell "constraint" correctly and then go with 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 Sat Jul 09 02:35:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr8vl-00052w-TK; Sat, 09 Jul 2005 02:35:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr8vk-00052r-7I for ltru@megatron.ietf.org; Sat, 09 Jul 2005 02:35:16 -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 CAA05760 for ; Sat, 9 Jul 2005 02:35: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 <20050709063444.UHDH14360.mta13.adelphia.net@DEWELL> for ; Sat, 9 Jul 2005 02:34:44 -0400 Message-ID: <007901c58450$44398e80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050708202214.FJXR27419.mta2.adelphia.net@megatron.ietf.org> Date: Fri, 8 Jul 2005 23:34:31 -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: status? last call? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 r&d afrac wrote: > So, when challenged they say the DNS is odious, the dont want to address > Java, they dont really respond to LDAP, they ignore OPES, they say that > CRCs are inflammatory, etc. Several fine examples of misrepresenting the words and intents of others. Addison wrote on 2005-01-04 on ietf-languages: > Asking the IESG to abandon the Last Call because you don't like the > draft or because you don't care for our responses to you is, frankly, > odious. Let the process play out. r&d continued: > As a brainware person, I think you were right in a way, but as an > English mother tongue person, you do not relate your culture as other > people often do to your language (you probably see the American > culture as more attached to the nation, the flag, the history, the > literature). There are all the variations on Earth: as a French > speaking person, I relate my culture to the capabilities of my > language and my nation and history are more examples of the capacity > of the language than the other way around. Great authors did not build > French, they are natural by-products of the common people language and > effort. There is no Shakespeare in French: there are millions of > co-speakers. This certainly influenced our values. Franck could tell, > but I suppose German is similar? Try to understand the African culture > if you do not understand the coexistance of language, family, economy, > poetry, in a quasi geographical continuity. What are going to mean > there "sn, co, iv, bn, etc.???". A person who knows not a single word of Shona and knows nothing of the culture of the Shona-speaking people can still work to develop a tagging mechanism by which Shona text can be indicated by use of the string "sn". -- 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 Jul 09 02:47:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr97e-0003B7-83; Sat, 09 Jul 2005 02: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 1Dr97c-00037e-VJ for ltru@megatron.ietf.org; Sat, 09 Jul 2005 02:47: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 CAA06319 for ; Sat, 9 Jul 2005 02:47:31 -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 <20050709064701.SVBA19267.mta10.adelphia.net@DEWELL> for ; Sat, 9 Jul 2005 02:47:01 -0400 Message-ID: <008201c58451$f915cca0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050708223320.STFK4366.mta6.adelphia.net@megatron.ietf.org> Date: Fri, 8 Jul 2005 23:46:43 -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: Finishing off #1026 (Was: Re: status? last call?) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > The text that is there in the -08 registry draft says: > > E. UN numeric codes and ISO 3166 alpha-2 codes for countries > or areas listed as eligible for registration in [initial- > registry] but not presently registered MAY be entered into > the IANA registry via the process described in Section 3.4. > Once registered, these codes MAY be used to form language > tags. > > As a technical contributor, I think this is the right thing to do, but > it sounds like Frank and I are having trouble reconciling it with, for > example, Doug's understanding: > "In regard to the general matter of registering UN numeric code > elements for countries and country-like entities (as opposed to macro > regions), I believe they should NOT be eligible for individual > registration, so that they may remain available as the "last resort" > option in case of ISO 3166 code conflicts." The draft is not consistent with itself. Section 2.2.4 (3E), quoted above, says we can register such subtags. Section 3.4 (11), to which I referred, says we may not. > As a thought experiment, work through the "es-419" case using both > approaches. "419" is not pertinent to this discussion. It represents a macrogeographical area, not a country or country-like region. As such, it could not be equivalent to an ISO 3166 code element, and consequently there are no restrictions on registering 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 Sat Jul 09 03:09:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr9Sg-0006KB-R0; Sat, 09 Jul 2005 03:09:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr9Se-0006Ee-Nl for ltru@megatron.ietf.org; Sat, 09 Jul 2005 03:09:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07646 for ; Sat, 9 Jul 2005 03:09:14 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr9uC-0003kl-Jz for ltru@ietf.org; Sat, 09 Jul 2005 03:37:45 -0400 Received: from h-68-165-2-157.snvacaid.dynamic.covad.net ([68.165.2.157] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr9SV-0002G6-00 for ltru@ietf.org; Sat, 09 Jul 2005 03:09:07 -0400 Message-ID: <000301c58455$aa905740$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050708202214.FJXR27419.mta2.adelphia.net@megatron.ietf.org> <007901c58450$44398e80$030aa8c0@DEWELL> Date: Sat, 9 Jul 2005 00:09:43 -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: 4b800b1eab964a31702fa68f1ff0e955 Cc: Subject: [Ltru] Re: [psg.com #881] status? last call? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - The technical content of your message pertains to issue #881, the request to remove registrant information from the registry. This was rejected long ago; there's no need to belabor the point. Let's wrap up the open issues instead. If you feel compelled to address an issue already closed, please include the issue number in the subject. That helps me sort through things more quickly, which will help bring us all to last call sooner. Randy ----- Original Message ----- > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Friday, July 08, 2005 11:34 PM > Subject: [Ltru] Re: status? last call? > > r&d afrac wrote: > > > So, when challenged they say the DNS is odious, the dont want to > address > > Java, they dont really respond to LDAP, they ignore OPES, they say > that > > CRCs are inflammatory, etc. > > Several fine examples of misrepresenting the words and intents of > others. Addison wrote on 2005-01-04 on ietf-languages: > > > Asking the IESG to abandon the Last Call because you don't like the > > draft or because you don't care for our responses to you is, frankly, > > odious. Let the process play out. > > r&d continued: > > > As a brainware person, I think you were right in a way, but as an > > English mother tongue person, you do not relate your culture as other > > people often do to your language (you probably see the American > > culture as more attached to the nation, the flag, the history, the > > literature). There are all the variations on Earth: as a French > > speaking person, I relate my culture to the capabilities of my > > language and my nation and history are more examples of the capacity > > of the language than the other way around. Great authors did not build > > French, they are natural by-products of the common people language and > > effort. There is no Shakespeare in French: there are millions of > > co-speakers. This certainly influenced our values. Franck could tell, > > but I suppose German is similar? Try to understand the African culture > > if you do not understand the coexistance of language, family, economy, > > poetry, in a quasi geographical continuity. What are going to mean > > there "sn, co, iv, bn, etc.???". > > A person who knows not a single word of Shona and knows nothing of the > culture of the Shona-speaking people can still work to develop a tagging > mechanism by which Shona text can be indicated by use of the string > "sn". > > -- > 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 Sat Jul 09 03:09:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr9Sh-0006Kd-32; Sat, 09 Jul 2005 03:09:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr9Se-0006Ef-OP for ltru@megatron.ietf.org; Sat, 09 Jul 2005 03:09:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07647 for ; Sat, 9 Jul 2005 03:09:14 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dr9uC-0003kX-K3 for ltru@ietf.org; Sat, 09 Jul 2005 03:37:45 -0400 Received: from h-68-165-2-157.snvacaid.dynamic.covad.net ([68.165.2.157] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dr9SS-0002G6-00 for ltru@ietf.org; Sat, 09 Jul 2005 03:09:04 -0400 Message-ID: <000001c58455$a91f1400$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <42CF079D.4000003@megared.net.mx><009101c58416$14677a80$7f1afea9@oemcomputer><20050708233753.GJ4776@NYCMJCOWA2><009501c5841c$a8d047a0$9b753009@sanjose.ibm.com> <016201c58421$970fa7e0$7f1afea9@oemcomputer> <002701c58423$e11e0550$6501a8c0@sanjose.ibm.com> Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags Date: Fri, 8 Jul 2005 23:04: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: 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 Hi - > From: "Mark Davis" > To: "Randy Presuhn" ; > Sent: Friday, July 08, 2005 6:16 PM > Subject: Re: [Ltru] [psg.com #1061] eliminate (or proscribe)Private Use Tags > > > > Except that the "Private-use subtags MUST conform to the format > constraints > > > specified in the ABNF." is redundant. ALL subtags must conform to the > format > > > constraints specified in the ABNF. So I would just suggest the simpler > > > > The reason I included the redundant element is because there indications > > that someone plans to disregard the ABNF in their implementation. Such > > is their right, but I don't want them to have any excuses when things > > don't work correctly. > > The thing that bothers me is that some might conclude that *other* subtags > don't have to conform to the format constraints. So how about: > > Private-use subtags, like all other subtags, MUST conform to the format > constraints specified in the ABNF. > > > > > (2) "Private-use subtags have no meaning outside of a private agreement > > > between parties. They may also be given different meanings by different > > > private agreements between those or other parties. Thus they SHOULD NOT > be > > > used wherever there is alternative, and they SHOULD NOT be used in > content > > > or protocols intended for general use. > > ... > > > > I could also live with this, if it will allow us to put this item to rest, > > though I'd prefer if the second "SHOULD NOT" were a "MUST NOT". > > I thought of saying MUST NOT, but that is too strong. There may be a private > use tag for something that is later added. You wouldn't want to say that the > tag is then not conformant. So I suggest the language plus the format clause > you wanted: > > > (2) "Private-use subtags have no meaning outside of a private agreement > between parties. They may also be given different meanings by different > private agreements between those or other parties. Thus they SHOULD NOT be > used wherever there is alternative, and they SHOULD NOT be used in content > or protocols intended for general use. Private-use subtags, like all other > subtags, MUST conform to the format constraints specified in the ABNF. > > What do you think of that? ... This, too, would be ok for me. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 09 03:18:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr9bk-0002JU-TI; Sat, 09 Jul 2005 03:18:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dr9bg-0002JO-RK for ltru@megatron.ietf.org; Sat, 09 Jul 2005 03:18: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 DAA08142 for ; Sat, 9 Jul 2005 03:18:33 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dr9bZ-0008EJ-7a for ltru@lists.ietf.org; Sat, 09 Jul 2005 09:18:29 +0200 Received: from 212.82.251.25 ([212.82.251.25]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jul 2005 09:18:29 +0200 Received: from nobody by 212.82.251.25 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 09 Jul 2005 09:18:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sat, 09 Jul 2005 09:08:53 +0200 Organization: Lines: 22 Message-ID: <42CF7805.2BD7@xyzzy.claranet.de> References: <20050708091150.FDRY15546.mta1.adelphia.net@megatron.ietf.org> <005901c58447$6211b800$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.25 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #900] Re: status? last call? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 agree to remove 200 from Section 4 of draft-initial-02. Fine. [IANA] > Actually repeating the text seems quite unnecessary. Okay, Randy said it should work without more details. [Comments replicating the Preferred-Value] > I completely agree about the sheer uselessness of comments > like this, whose information is wholly duplicated within > other fields. I don't like them, and didn't want to put > them in. But others seems to like them. I don't recall any "others", but it's no problem, only ugly. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 09 09:55:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrFnK-0000q3-SR; Sat, 09 Jul 2005 09:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrFnJ-0000pE-IW for ltru@megatron.ietf.org; Sat, 09 Jul 2005 09:55:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01638 for ; Sat, 9 Jul 2005 09:54:59 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrGEv-0004OH-5r for ltru@ietf.org; Sat, 09 Jul 2005 10:23:33 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DrFn1-0001Ix-MW; Sat, 09 Jul 2005 06:54:50 -0700 Message-Id: <6.2.1.2.2.20050709144837.0398f9f0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 09 Jul 2005 15:54:33 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: status? last call? In-Reply-To: <007901c58450$44398e80$030aa8c0@DEWELL> References: <20050708202214.FJXR27419.mta2.adelphia.net@megatron.ietf.org> <007901c58450$44398e80$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 sorry I have to go to the Luxembourg meeting where I will not have email access, my battery just having failed me. I just see from that collection of mails that the IETF process has advantages but also meets its problems. This is certainly not easy to address. This may be why it is better at maintaining/reducing than at developping (cf. Harald Alvestrand, RFC 3774, etc.) The two quotes below I think denote that kind of difficulty. At 08:34 09/07/2005, Doug Ewell wrote: >Several fine examples of misrepresenting the words and intents of >others. Addison wrote on 2005-01-04 on ietf-languages: > > > Asking the IESG to abandon the Last Call because you don't like the > > draft or because you don't care for our responses to you is, frankly, > > odious. Let the process play out. The Last Call process is precisely to permit to ask IESG to abandon a document in documenting why. > > Try to understand the African culture > > if you do not understand the coexistance of language, family, economy, > > poetry, in a quasi geographical continuity. What are going to mean > > there "sn, co, iv, bn, etc.???". > >A person who knows not a single word of Shona and knows nothing of the >culture of the Shona-speaking people can still work to develop a tagging >mechanism by which Shona text can be indicated by use of the string >"sn". This, I believe, describes perfectly why the Draft doctrine adds to the basic error of RFC 3066 attenuated by its lose application (that IETF has the capacity to correlate non protocol parameters). Jon Postel had clearly established it: this is none of the IANA business. Not only it seems that cultural empowerment is ignored by the author of this text. But, since the topic here is ISO 3166, it shows a remakable confusion between Senegal and Zimbabwe which precisely document my point and the difficulty to establish general rules in a world made of particulars. Please, let save time. Let not wait for another negative last call and start from a clean sheet analysis of the Charter at the light of the world and Internet reality. Call this a non-starter, I call this a new-starter. Let understand where and why RFC 3066 may be wrong. How to correct it - probably in a totally different way from the current Draft. Let build the Global Lingual Codification Framework the Internet community needs. Then use the Draft relevant parts to support the XML, HTML, CLDR needs for those wanting to stay compatible with the old RFC 3066 approach. jfc PS. I do not see much success with call for a consensus. Too bad. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 09 13: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 1DrIhc-00089l-4y; Sat, 09 Jul 2005 13: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 1DrIha-00089d-Lm for ltru@megatron.ietf.org; Sat, 09 Jul 2005 13:01:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12227 for ; Sat, 9 Jul 2005 13:01:15 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrJ9D-0002k8-Ju for ltru@ietf.org; Sat, 09 Jul 2005 13:29:52 -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 j69H11UU005979; Sat, 9 Jul 2005 10:01:01 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Sat, 9 Jul 2005 10:01:44 -0700 Message-ID: From: "McDonald, Ira" To: "'Randy Presuhn'" , LTRU Working Group Subject: RE: [Ltru] issue #1059 Horizontal whitespace Date: Sat, 9 Jul 2005 10:01:42 -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: 10ba05e7e8a9aa6adb025f426bef3a30 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, +1 I agree with Randy - machine-readable formats are regularly published in RFCs, without problems - the user community and IANA have scripts and C tools to strip the RFC artifacts from the various machine-readable formats. 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, July 08, 2005 6:54 PM > To: LTRU Working Group > Subject: [Ltru] issue #1059 Horizontal whitespace > > > Hi - > > > From: "Mark Davis" > > To: "Randy Presuhn" ; "LTRU > Working Group" > > Sent: Friday, July 08, 2005 3:38 PM > > Subject: Re: Horizontal whitespace (was Re: [Ltru] Re: I-D > ACTION:draft-ietf-ltru-initial-01.txt) > > > > > I agree with the goal. I'd suggest explaining in a bit more > detail, however: > > > > Headers, footers, line breaks, and other > > vertical whitespace introduced by the RFC process are not > > significant. Leading horizontal whitespace indicates a continued > > line in the record-jar format, and must not be deleted.=> > > > > In the IANA registry that is produced from this document in > the record-jar > > format, leading horizontal whitespace is significant, and > indicates a > > continued line. However, in this document, headers, > footers, line breaks, > > and other whitespace is introduced by the RFC process. To correctly > > interpret the data in this document, these extraneous > characters must be > > disregarded. In particular, a number of horizontal > whitespace characters > > that is greater than what is found on the 'File-Date' line > indicates a > > continued line in the record-jar format, and must not be deleted. > ... > > As a contributor who has edited RFCs establishing registries, > and who has > chaired WGs producing such RFCs, I feel quite confident in > saying that this > is complete and total over-kill. We don't do this for ABNF, > MIB modules, > ASN.1 modules, or any of the other machine-parseable stuff that finds > itself published in RFCs. The folks at IANA have repeatedly > proven that > they know enough to strip headers, footers, etc. I could > support Doug's > original proposal because it addressed a not-100%-obvious > potential problem, > but I can't support this amended proposal. If the rest of > the WG supports > it, I won't oppose it, but I think the amended proposal would > set a bad precedent. > > 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 Sat Jul 09 13:42:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrJLa-0007ao-2X; Sat, 09 Jul 2005 13:42:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrJLZ-0007aj-05 for ltru@megatron.ietf.org; Sat, 09 Jul 2005 13:42: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 NAA13898 for ; Sat, 9 Jul 2005 13:42:33 -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 <20050709174205.KIJP19267.mta10.adelphia.net@DEWELL> for ; Sat, 9 Jul 2005 13:42:05 -0400 Message-ID: <001401c584ad$68991a40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050709160302.YPWK4366.mta6.adelphia.net@megatron.ietf.org> Date: Sat, 9 Jul 2005 10:41:15 -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: [psg.com #881] status? last call? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 r&d afrac wrote: >> A person who knows not a single word of Shona and knows nothing of >> the culture of the Shona-speaking people can still work to develop a >> tagging mechanism by which Shona text can be indicated by use of the >> string "sn". > > This, I believe, describes perfectly why the Draft doctrine adds to > the basic error of RFC 3066 attenuated by its lose application (that > IETF has the capacity to correlate non protocol parameters). Jon > Postel had clearly established it: this is none of the IANA business. > Not only it seems that cultural empowerment is ignored by the author > of this text. But, since the topic here is ISO 3166, it shows a > remakable confusion between Senegal and Zimbabwe which precisely > document my point and the difficulty to establish general rules in a > world made of particulars. RFC 1766 and 3066 and the current draft use two-letter strings as both language identifiers and country identifiers. There are strict contextual rules for their use: a country code can never appear by itself in a language tag. If you are attempting to show that the draft introduces "remarkable confusion" because the two-letter string "sn" could be either a language subtag for Shona or a region subtag for Senegal, you have failed utterly. You have only proven that it is possible to confuse people by referring to things out of context. I am finished with this thread. -- 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 Jul 09 16:02:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrLWs-0000zz-Ht; Sat, 09 Jul 2005 16:02:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrLWr-0000xG-Rq for ltru@megatron.ietf.org; Sat, 09 Jul 2005 16:02:25 -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 QAA22585 for ; Sat, 9 Jul 2005 16:02:23 -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 <20050709200154.MVMY14360.mta13.adelphia.net@DEWELL> for ; Sat, 9 Jul 2005 16:01:54 -0400 Message-ID: <003001c584c0$dd04e540$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050709160302.YPWK4366.mta6.adelphia.net@megatron.ietf.org> Date: Sat, 9 Jul 2005 13:00:31 -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: [psg.com #1061] eliminate (or proscribe) Private Use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org In the interest of achieving consensus, I won't argue further about the exact wording of this section. I do insist that private-use tags and subtags in "x-" not be removed from the grammar, or proscribed entirely. It MUST be legal for consenting adults to generate and interpret "x-this" and "en-x-that" in the privacy of their homes. -- 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 Jul 09 16:24:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrLsS-00014y-PF; Sat, 09 Jul 2005 16:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrLsR-00014e-4l for ltru@megatron.ietf.org; Sat, 09 Jul 2005 16:24:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23416 for ; Sat, 9 Jul 2005 16:24:40 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrMK4-0001jr-V5 for ltru@ietf.org; Sat, 09 Jul 2005 16:53:18 -0400 Received: from h-64-105-136-46.snvacaid.dynamic.covad.net ([64.105.136.46] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DrLsK-00032p-00 for ltru@ietf.org; Sat, 09 Jul 2005 16:24:36 -0400 Message-ID: <000601c584c4$d0658de0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050709160302.YPWK4366.mta6.adelphia.net@megatron.ietf.org> <003001c584c0$dd04e540$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags Date: Sat, 9 Jul 2005 13:28: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.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: "Doug Ewell" > To: "LTRU Working Group" > Sent: Saturday, July 09, 2005 1:00 PM > Subject: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags > > In the interest of achieving consensus, I won't argue further about the > exact wording of this section. I do insist that private-use tags and > subtags in "x-" not be removed from the grammar, or proscribed entirely. > It MUST be legal for consenting adults to generate and interpret > "x-this" and "en-x-that" in the privacy of their homes. ... I think we're all agreed on that. Based on the discussion, I'll leave it to the editors to pick appropriate words to reflect our rough consensus that private use tags and subtags should remain in the document, but there should be a "health warning" regarding the risks associated with using them. Several alternative wordings have been offered, and I think the feedback on the mailing list will provide sufficient guidance to the editors to form text we can live with. With that, I'll mark this issue resolved. If someone finds the words they choose unacceptable, we can re-open the issue. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 09 16:47:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrMEI-0001MJ-Ed; Sat, 09 Jul 2005 16:47:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrMEF-0001KT-Co for ltru@megatron.ietf.org; Sat, 09 Jul 2005 16:47: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 QAA24221 for ; Sat, 9 Jul 2005 16:47:12 -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 <20050709204642.DKCM24042.mta11.adelphia.net@DEWELL> for ; Sat, 9 Jul 2005 16:46:42 -0400 Message-ID: <004e01c584c7$46fef700$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 9 Jul 2005 13:46: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: Subject: [Ltru] Additional descriptions not found in ISO X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 A list member whose judgment I trust wrote this to me off-list, and I thought it was appropriate to bring it onto the list: > Would it be appropriate to add "Bangla" as a description > under the "Bengali" entry? > > I see these as two separate entries on a lot of the lists I've > reviewed. The initial registry includes Description fields taken directly from the relevant ISO and UN standards. I tried to be very diligent about copying them exactly, to the point of using the ISO 3166 country names "Korea, Democratic People's Republic of" and "Libyan Arab Jamahiriya," which I would never use in conversation, and the ISO 639 language name "Low German; Low Saxon; German, Low; Saxon, Low" (split into multiple Description fields), which I consider major overkill. The only conscious changes I made were to add a space between the period and the digit in constructions like "English, Old (ca.450-1100)". ISO 639 lists "Bengali" as the only English name for the code element "bn". However, it is certainly true that the name "Bangla" is often used as well, particularly by native Bengali speakers. There are probably other examples as well. My understanding is that: 1. The Description field is not normative, and user agents are free to substitute any name that does not materially change the meaning of the subtag. It's OK for a user interface to replace "Bengali" with "Bangla," but not with "Italian." 2. Additional Description fields can always be proposed for registration after the RFC goes live, subject to the restriction about not changing the meaning. 3. The initial registry is meant as a starting point, where 869 subtags and their descriptions are registered with the blanket justification that they appear in the core standards. Adding a single alternative description that is not in the standards would open the door for other such requests, which is what the individual-registration process is supposed to be for. It would probably be best to hold off on such requests until the RFC goes live, and use the procedure in Section 3.4 to request them at that time. Is this more or less the hum of the group, or do we need a ticket? -- 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 Jul 09 16:51:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrMIO-0002q3-UB; Sat, 09 Jul 2005 16: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 1DrMIL-0002py-5V for ltru@megatron.ietf.org; Sat, 09 Jul 2005 16:51:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24345 for ; Sat, 9 Jul 2005 16:51:26 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrMk0-0002VH-B8 for ltru@ietf.org; Sat, 09 Jul 2005 17:20:04 -0400 Received: from h-64-105-136-46.snvacaid.dynamic.covad.net ([64.105.136.46] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DrMIJ-0000VQ-00 for ltru@ietf.org; Sat, 09 Jul 2005 16:51:27 -0400 Message-ID: <000f01c584c8$8feb1100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050708223320.STFK4366.mta6.adelphia.net@megatron.ietf.org> <008201c58451$f915cca0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Date: Sat, 9 Jul 2005 13:55: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: 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 Hi - As a technical contributor... > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Friday, July 08, 2005 11:46 PM > Subject: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) ... > The draft is not consistent with itself. Section 2.2.4 (3E), quoted > above, says we can register such subtags. Section 3.4 (11), to which I > referred, says we may not. ... I think you mean section 3.3 (11). The text there in the http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-08.txt draft says: 11. Codes assigned by UN M.49 to countries or areas (as opposed to geographical regions and sub-regions) for which there is no corresponding ISO 3166 code MUST NOT be registered, except under the previous provisions (as a surrogate for an ISO 3166 code that cannot itself be registered). If it is necessary to identify a region for which only a UN M.49 code exists in language tags, then the registration authority for ISO 3166 SHOULD be petitioned to assign a code, which can then be registered for use in language tags. At the time this document was written, there were only four such codes: 830 (Channel Islands), 831 (Guernsey), 832 (Jersey), and 833 (Isle of Man). This rule exists so that UN M.49 codes remain available as the value of last resort in cases where ISO 3166 reassigns a deprecated value in the registry. The difference in our understanding comes from the last sentence. I think Doug is reading it as the *sole* condition under which rule 3.3(11) may be employed. I, and I think Frank, read it as the *motivation* for the rule, rather than a limiting condition. The two readings play out differently if the ISO 3166 registration authority fails to assign a code when petitioned. In Doug's reading, there's no registration, and the party needing the code is out of luck. In the alternative reading, after some undefined (I'd leave it up to the collective intelligence of the language tag mailing list) period, the UN M.49 code could be registered. The question for the WG is which behaviour is better / less bad? I propose adding one sentence to 3.3(11) to make it more consistent with 2.2.4 (3E): "If the petition for a code assignment ISO 3166 is refused or not acted on in a timely manner, the Language Subtag Reviewer MAY procede with the registration using the UN M.49 code." Or words to that effect. This is very much a pathological corner case, and I hate to see us spending so much time on it, so let's pick one of the alternative, make the text clear which one we've picked, and be done with it. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 09 17:03:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrMTY-0006CX-DS; Sat, 09 Jul 2005 17:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrMTU-0006CS-Ql for ltru@megatron.ietf.org; Sat, 09 Jul 2005 17:03:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24891 for ; Sat, 9 Jul 2005 17:02:57 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrMv9-0002oW-U6 for ltru@ietf.org; Sat, 09 Jul 2005 17:31:36 -0400 Received: from h-64-105-136-46.snvacaid.dynamic.covad.net ([64.105.136.46] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DrMTS-0002lD-00 for ltru@ietf.org; Sat, 09 Jul 2005 17:02:59 -0400 Message-ID: <001401c584ca$2cd8e7c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <004e01c584c7$46fef700$030aa8c0@DEWELL> Subject: Re: [Ltru] Additional descriptions not found in ISO Date: Sat, 9 Jul 2005 14:07:11 -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: 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: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Saturday, July 09, 2005 1:46 PM > Subject: [Ltru] Additional descriptions not found in ISO > > A list member whose judgment I trust wrote this to me off-list, and I > thought it was appropriate to bring it onto the list: > > > Would it be appropriate to add "Bangla" as a description > > under the "Bengali" entry? > > > > I see these as two separate entries on a lot of the lists I've > > reviewed. > > The initial registry includes Description fields taken directly from the > relevant ISO and UN standards. I tried to be very diligent about > copying them exactly, to the point of using the ISO 3166 country names > "Korea, Democratic People's Republic of" and "Libyan Arab Jamahiriya," > which I would never use in conversation, and the ISO 639 language name > "Low German; Low Saxon; German, Low; Saxon, Low" (split into multiple > Description fields), which I consider major overkill. The only > conscious changes I made were to add a space between the period and the > digit in constructions like "English, Old (ca.450-1100)". > > ISO 639 lists "Bengali" as the only English name for the code element > "bn". However, it is certainly true that the name "Bangla" is often > used as well, particularly by native Bengali speakers. There are > probably other examples as well. > > My understanding is that: > > 1. The Description field is not normative, and user agents are free to > substitute any name that does not materially change the meaning of the > subtag. It's OK for a user interface to replace "Bengali" with > "Bangla," but not with "Italian." > > 2. Additional Description fields can always be proposed for > registration after the RFC goes live, subject to the restriction about > not changing the meaning. > > 3. The initial registry is meant as a starting point, where 869 subtags > and their descriptions are registered with the blanket justification > that they appear in the core standards. Adding a single alternative > description that is not in the standards would open the door for other > such requests, which is what the individual-registration process is > supposed to be for. It would probably be best to hold off on such > requests until the RFC goes live, and use the procedure in Section 3.4 > to request them at that time. > > Is this more or less the hum of the group, or do we need a ticket? ... As technical contributor: I think not doing it here is the correct choice. Handling requests to add information or modify those fields is properly the role of ietf-languages@ietf.org Doing it here would not add any unique value to the process and would slow us down. As co-chair: As you put it, you're not proposing any changes to anything, so I've not created a ticket in the https://rt.psg.com/ (user/password "ietf") system. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 09 17:57:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrNJv-0001Ma-BW; Sat, 09 Jul 2005 17:57:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrNJu-0001MQ-Nt for ltru@megatron.ietf.org; Sat, 09 Jul 2005 17:57:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27345 for ; Sat, 9 Jul 2005 17:57:06 -0400 (EDT) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrNlU-0004bF-VE for ltru@ietf.org; Sat, 09 Jul 2005 18:25:45 -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 j69LupMp836566 for ; Sat, 9 Jul 2005 17:56:51 -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 j69LupwB415646 for ; Sat, 9 Jul 2005 15:56:51 -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 j69LuoiD002443 for ; Sat, 9 Jul 2005 15:56:50 -0600 Received: from markdavis (sig-9-48-104-92.mts.ibm.com [9.48.104.92]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j69LunQa002424; Sat, 9 Jul 2005 15:56:50 -0600 Message-ID: <00a801c584d1$1b6cbeb0$6501a8c0@sanjose.ibm.com> From: "Mark Davis" To: "McDonald, Ira" , "'Randy Presuhn'" , "LTRU Working Group" References: Subject: Re: [Ltru] issue #1059 Horizontal whitespace Date: Sat, 9 Jul 2005 14:56: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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e32.co.us.ibm.com id j69LupMp836566 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 objection then. =E2=80=8EMark ----- Original Message -----=20 From: "McDonald, Ira" To: "'Randy Presuhn'" ; "LTRU Working Group= " Sent: Saturday, July 09, 2005 10:01 Subject: RE: [Ltru] issue #1059 Horizontal whitespace > Hi, > > +1 > > I agree with Randy - machine-readable formats are regularly > published in RFCs, without problems - the user community and > IANA have scripts and C tools to strip the RFC artifacts from > the various machine-readable formats. > > 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, July 08, 2005 6:54 PM > > To: LTRU Working Group > > Subject: [Ltru] issue #1059 Horizontal whitespace > > > > > > Hi - > > > > > From: "Mark Davis" > > > To: "Randy Presuhn" ; "LTRU > > Working Group" > > > Sent: Friday, July 08, 2005 3:38 PM > > > Subject: Re: Horizontal whitespace (was Re: [Ltru] Re: I-D > > ACTION:draft-ietf-ltru-initial-01.txt) > > > > > > > > I agree with the goal. I'd suggest explaining in a bit more > > detail, however: > > > > > > Headers, footers, line breaks, and other > > > vertical whitespace introduced by the RFC process are not > > > significant. Leading horizontal whitespace indicates a continue= d > > > line in the record-jar format, and must not be deleted.=3D> > > > > > > In the IANA registry that is produced from this document in > > the record-jar > > > format, leading horizontal whitespace is significant, and > > indicates a > > > continued line. However, in this document, headers, > > footers, line breaks, > > > and other whitespace is introduced by the RFC process. To correctly > > > interpret the data in this document, these extraneous > > characters must be > > > disregarded. In particular, a number of horizontal > > whitespace characters > > > that is greater than what is found on the 'File-Date' line > > indicates a > > > continued line in the record-jar format, and must not be deleted. > > ... > > > > As a contributor who has edited RFCs establishing registries, > > and who has > > chaired WGs producing such RFCs, I feel quite confident in > > saying that this > > is complete and total over-kill. We don't do this for ABNF, > > MIB modules, > > ASN.1 modules, or any of the other machine-parseable stuff that finds > > itself published in RFCs. The folks at IANA have repeatedly > > proven that > > they know enough to strip headers, footers, etc. I could > > support Doug's > > original proposal because it addressed a not-100%-obvious > > potential problem, > > but I can't support this amended proposal. If the rest of > > the WG supports > > it, I won't oppose it, but I think the amended proposal would > > set a bad precedent. > > > > 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@lists.ietf.org Sat Jul 09 17:58:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrNL1-0001O4-PG; Sat, 09 Jul 2005 17: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 1DrNL0-0001Nz-7a for ltru@megatron.ietf.org; Sat, 09 Jul 2005 17:58:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27366 for ; Sat, 9 Jul 2005 17:58:15 -0400 (EDT) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrNmf-0004e1-Si for ltru@ietf.org; Sat, 09 Jul 2005 18:26:54 -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 j69Lw8nf491164 for ; Sat, 9 Jul 2005 17:58:08 -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 j69Lw8wB391766 for ; Sat, 9 Jul 2005 15:58:08 -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 j69Lw8Sq003314 for ; Sat, 9 Jul 2005 15:58:08 -0600 Received: from markdavis (sig-9-48-104-92.mts.ibm.com [9.48.104.92]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j69Lw6IG003290; Sat, 9 Jul 2005 15:58:07 -0600 Message-ID: <00b601c584d1$498484e0$6501a8c0@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <20050708223320.STFK4366.mta6.adelphia.net@megatron.ietf.org><008201c58451$f915cca0$030aa8c0@DEWELL> <000f01c584c8$8feb1100$7f1afea9@oemcomputer> Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Date: Sat, 9 Jul 2005 14:58: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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e33.co.us.ibm.com id j69Lw8nf491164 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 agree with the clarification Randy suggests. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Saturday, July 09, 2005 13:55 Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) > Hi - > > As a technical contributor... > > > From: "Doug Ewell" > > To: "LTRU Working Group" > > Sent: Friday, July 08, 2005 11:46 PM > > Subject: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) > ... > > The draft is not consistent with itself. Section 2.2.4 (3E), quoted > > above, says we can register such subtags. Section 3.4 (11), to which= I > > referred, says we may not. > ... > > I think you mean section 3.3 (11). The text there in the > http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-08.txt > draft says: > > 11. Codes assigned by UN M.49 to countries or areas (as opposed to > geographical regions and sub-regions) for which there is no > corresponding ISO 3166 code MUST NOT be registered, except unde= r > the previous provisions (as a surrogate for an ISO 3166 code > that cannot itself be registered). If it is necessary to > identify a region for which only a UN M.49 code exists in > language tags, then the registration authority for ISO 3166 > SHOULD be petitioned to assign a code, which can then be > registered for use in language tags. At the time this document > was written, there were only four such codes: 830 (Channel > Islands), 831 (Guernsey), 832 (Jersey), and 833 (Isle of Man). > This rule exists so that UN M.49 codes remain available as the > value of last resort in cases where ISO 3166 reassigns a > deprecated value in the registry. > > The difference in our understanding comes from the last sentence. I th= ink > Doug is reading it as the *sole* condition under which rule 3.3(11) may > be employed. I, and I think Frank, read it as the *motivation* for the > rule, rather than a limiting condition. The two readings play out > differently if the ISO 3166 registration authority fails to assign a > code when petitioned. In Doug's reading, there's no registration, > and the party needing the code is out of luck. In the alternative > reading, after some undefined (I'd leave it up to the collective > intelligence of the language tag mailing list) period, the UN M.49 > code could be registered. The question for the WG is which behaviour > is better / less bad? > > I propose adding one sentence to 3.3(11) to make it more consistent wit= h > 2.2.4 (3E): "If the petition for a code assignment ISO 3166 is refused > or not acted on in a timely manner, the Language Subtag Reviewer MAY > procede with the registration using the UN M.49 code." Or words to > that effect. > > This is very much a pathological corner case, and I hate to see us > spending so much time on it, so let's pick one of the alternative, > make the text clear which one we've picked, and be done with it. > > 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 Sat Jul 09 19:09:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrORX-0001q6-J1; Sat, 09 Jul 2005 19:09:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrORW-0001q1-9D for ltru@megatron.ietf.org; Sat, 09 Jul 2005 19:09:06 -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 TAA01546 for ; Sat, 9 Jul 2005 19:09:01 -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 <20050709230828.ICQU24042.mta11.adelphia.net@DEWELL> for ; Sat, 9 Jul 2005 19:08:28 -0400 Message-ID: <005701c584da$bb525800$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050709215901.UXHV4366.mta6.adelphia.net@megatron.ietf.org> Date: Sat, 9 Jul 2005 16:05:41 -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 TAA01546 Cc: Subject: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: >> The draft is not consistent with itself. Section 2.2.4 (3E), quoted >> above, says we can register such subtags. Section 3.4 (11), to which >> I referred, says we may not. > ... > > I think you mean section 3.3 (11). Yep. > The text there in the > http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-08.txt > draft says: > ... > This rule exists so that UN M.49 codes remain available as the > value of last resort in cases where ISO 3166 reassigns a > deprecated value in the registry. > > The difference in our understanding comes from the last sentence. I > think Doug is reading it as the *sole* condition under which rule > 3.3(11) may be employed. That is correct. > I, and I think Frank, read it as the *motivation* for the > rule, rather than a limiting condition. The two readings play out > differently if the ISO 3166 registration authority fails to assign a > code when petitioned. In Doug's reading, there's no registration, > and the party needing the code is out of luck. In the alternative > reading, after some undefined (I'd leave it up to the collective > intelligence of the language tag mailing list) period, the UN M.49 > code could be registered. The question for the WG is which behaviour > is better / less bad? It depends on how likely we think this scenario is (using Guernsey as an example; substitute Jersey or IOM as appropriate): We add region subtag 831, and then at some point in the future, ISO 3166/MA adds code element GG, resulting in widespread popular association of the symbol GG with Guernsey, and criticism of the LTRU project for having assigned 831 instead. This is what I thought one of Frank's biggest concerns was. (The other was that the MA, having reserved GG for Guernsey, would assign it to some other entity X first, then withdraw it and assign it to Guernsey, which could no longer have region subtag GG because it was already permanently assigned in the registry to entity X. This chain of events seems too unlikely to worry about.) The alternative is that we *don't* add region subtag 831, but either (a) wait for the unrealistic scenario above, resulting in 831 after all, or (b) wait for the MA to assign GG, resulting in GG. In this scenario, we might wait forever, and in the meantime it would be impossible to indicate Guernsey in a language tag, except with a private-use subtag (or a non-conformant extension). I wasn't worried about this impossibility before, since the use of English, Manx, etc. in these locations seems not to differ from other locations. However, I did a bit of checking, and can't figure out a way to tag Dg=C3=A8rn=C3=A9siais (the Norman language of Guernsey) or J=C3=A8= rriais (the Norman language of Jersey). There doesn't seem to be an ISO 639-1 or -2 code element (and therefore a language subtag) for Norman languages in general, and definitely not for these two specifically. ISO/DIS 639-3 has only a single code element "xno" for "Anglo-Norman," which may or may not fit the description of either Dg=C3=A8rn=C3=A9siais or J=C3=A8rri= ais; but even if it is, and even if RFC 3066ter includes "xno" as a language subtag, there is no way to use it to differentiate between "Anglo-Norman used in Guernsey" (i.e. Dg=C3=A8rn=C3=A9siais) and "Anglo-Norman used in Jersey" = (i.e. J=C3=A8rriais) unless region subtags exist for Guernsey and Jersey. (Of course, ietf-languages could avoid this quagmire by petitioning ISO 639/RA to assign code elements for Dg. and J., or failing that, registering them directly.) So if we want to allow 831 and friends to be individually registrable, cool, but let's not come back later and say, "Wait a minute! We needed 831 as a safety net! What were we thinking?" > I propose adding one sentence to 3.3(11) to make it more consistent > with 2.2.4 (3E): "If the petition for a code assignment ISO 3166 is > refused or not acted on in a timely manner, the Language Subtag > Reviewer MAY procede with the registration using the UN M.49 code." > Or words to that effect. If we do this, the text in Section 2 (6) and Section 4 of draft-initial-01 will remain unchanged in draft-02. (It had been proposed to change it to indicate that the subtags could not be registered.) So the decision on this question affects both draft-registry and draft-initial. -- 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 Jul 09 19:40:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrOvr-0004W3-9q; Sat, 09 Jul 2005 19:40:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrOvp-0004VV-NL for ltru@megatron.ietf.org; Sat, 09 Jul 2005 19:40:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02925 for ; Sat, 9 Jul 2005 19:40:21 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrPNW-0007r4-2v for ltru@ietf.org; Sat, 09 Jul 2005 20:09:02 -0400 Received: from h-64-105-136-46.snvacaid.dynamic.covad.net ([64.105.136.46] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DrOvn-0003YF-00 for ltru@ietf.org; Sat, 09 Jul 2005 19:40:23 -0400 Message-ID: <000401c584e0$28fdf580$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050709215901.UXHV4366.mta6.adelphia.net@megatron.ietf.org> <005701c584da$bb525800$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Date: Sat, 9 Jul 2005 16:44:33 -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: 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: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Saturday, July 09, 2005 4:05 PM > Subject: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) ... > So if we want to allow 831 and friends to be individually registrable, > cool, but let's not come back later and say, "Wait a minute! We needed > 831 as a safety net! What were we thinking?" > > > I propose adding one sentence to 3.3(11) to make it more consistent > > with 2.2.4 (3E): "If the petition for a code assignment ISO 3166 is > > refused or not acted on in a timely manner, the Language Subtag > > Reviewer MAY procede with the registration using the UN M.49 code." > > Or words to that effect. ... They'd still be a safety net - they'd only (in this case) be registerable if the ISO 3166 code assignment request is refused or ignored. The decision whether to accept the registration would still be subject to debate on the ietf-languages@iana.org list. At least that was my thinking. If UN M.49 changes 831's meaning to refer to something else, then there is a problem with the whole idea of them being a safety net. If a request for an ISO 3166 code to match 831 is first refused, and then a couple years later accepted, well, that's just FUBAR. :-) Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 09 21:50:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrQxD-0006NX-W2; Sat, 09 Jul 2005 21: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 1DrQxC-0006Jm-9u for ltru@megatron.ietf.org; Sat, 09 Jul 2005 21:49:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10187 for ; Sat, 9 Jul 2005 21:49:55 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrROt-0004F1-1R for ltru@ietf.org; Sat, 09 Jul 2005 22:18: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 j6A1naBt020704; Sat, 9 Jul 2005 21:49:37 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Sat, 9 Jul 2005 21:49:36 -0400 Date: Sat, 9 Jul 2005 21:49:36 -0400 From: "John.Cowan" To: Doug Ewell Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Message-ID: <20050710014936.GD7948@NYCMJCOWA2> References: <20050709215901.UXHV4366.mta6.adelphia.net@megatron.ietf.org> <005701c584da$bb525800$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <005701c584da$bb525800$030aa8c0@DEWELL> User-Agent: Mutt/1.4.2.1i Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.reutershealth.com id j6A1naBt020704 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: ietf-languages@iana.org, 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: > However, I did a bit of checking, and can't figure out a way > to tag Dg=E8rn=E9siais (the Norman language of Guernsey) or J=E8rriais = (the > Norman language of Jersey). There doesn't seem to be an ISO 639-1 or -= 2 > code element (and therefore a language subtag) for Norman languages in > general, and definitely not for these two specifically. ISO/DIS 639-3 > has only a single code element "xno" for "Anglo-Norman," which may or > may not fit the description of either Dg=E8rn=E9siais or J=E8rriais; bu= t even > if it is, and even if RFC 3066ter includes "xno" as a language subtag, > there is no way to use it to differentiate between "Anglo-Norman used i= n > Guernsey" (i.e. Dg=E8rn=E9siais) and "Anglo-Norman used in Jersey" (i.e. > J=E8rriais) unless region subtags exist for Guernsey and Jersey. Quite right. In fact, 'xno' is apparently meant for the now extinct Norman French once spoken in England, and does not cover Dg=E8rn=E9siais and J=E8rriais at all. Rather, the Ethnologue (and *a fortiori* ISO 639-3) considers them varieties of "fr", like all the *langues d'o=EFl* except Walloon and Picard (probably because those two have some official status in Belgium). So either they need to be registered as variants, or the semi-official GG and JE codes need to be made official by the ISO 3166/MA, or the U.N. codes need to be used. I think the second of these is the best option, but apparently BSI and only BSI can press for it. Is there any one here from BSI who is willing to do so? Since this affects current as well as future status, I have cross-posted to ietf-languages@iana.org and ltru@ietf.org. --=20 The first thing you learn in a lawin' family John Cowan is that there ain't no definite answers jcowan@reutershealth.com to anything. --Calpurnia in To Kill A Mockingbird _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 09 23: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 1DrSAj-00066t-F5; Sat, 09 Jul 2005 23: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 1DrSAi-000650-9S for ltru@megatron.ietf.org; Sat, 09 Jul 2005 23:08:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13194 for ; Sat, 9 Jul 2005 23:07:57 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrScP-0006lY-LU for ltru@ietf.org; Sat, 09 Jul 2005 23:36:38 -0400 Received: from h-68-165-3-7.snvacaid.dynamic.covad.net ([68.165.3.7] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DrSAb-00074K-00 for ltru@ietf.org; Sat, 09 Jul 2005 23:07:53 -0400 Message-ID: <001401c584fd$27cf0c40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050709215901.UXHV4366.mta6.adelphia.net@megatron.ietf.org><005701c584da$bb525800$030aa8c0@DEWELL> <20050710014936.GD7948@NYCMJCOWA2> Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Date: Sat, 9 Jul 2005 20:12: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.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 - As a technical contributor, and only on the ltru-relevant aspects... > From: "John.Cowan" > To: "Doug Ewell" > Cc: ; > Sent: Saturday, July 09, 2005 6:49 PM > Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) ... > So either they need to be registered as variants, or the semi-official > GG and JE codes need to be made official by the ISO 3166/MA, or the > U.N. codes need to be used. > > I think the second of these is the best option, but apparently BSI and > only BSI can press for it. Is there any one here from BSI who is willing > to do so? ... I agree the second option seems to make the most sense. Both the second and, if the effort to get GG and JE made "official" fails, the third options John offers would be consistent with my proposal to add a sentence to 3.3(11) saying something like "If the petition for a code assignment ISO 3166 is refused or not acted on in a timely manner, the Language Subtag Reviewer MAY procede with the registration using the UN M.49 code." The third would not be permitted if we go with Doug's interpretation, and would, in that case, require the use of the first option rather than offering a choice. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 10 00:06:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrT5j-0005qo-5V; Sun, 10 Jul 2005 00:06:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrT5h-0005ns-Ib for ltru@megatron.ietf.org; Sun, 10 Jul 2005 00:06:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15774 for ; Sun, 10 Jul 2005 00:06:47 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrTXM-0000Ge-RE for ltru@ietf.org; Sun, 10 Jul 2005 00:35:30 -0400 Received: from h-68-166-188-152.snvacaid.dynamic.covad.net ([68.166.188.152] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DrT5b-0007fE-00 for ltru@ietf.org; Sun, 10 Jul 2005 00:06:47 -0400 Message-ID: <004001c58505$60a3b7c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Date: Sat, 9 Jul 2005 21:10: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: 52e1467c2184c31006318542db5614d5 Cc: Subject: [Ltru] id nits in draft-ietf-ltru-registry-08.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 Hi - I ran http://ietf.levkowetz.com/tools/idnits/idnits.pyht on the -08 of the registry draft, and got the following output: idnits 1.74 tmp/draft-ietf-ltru-registry-08.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. No nits found. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: - Line 139 has weird spacing: '... being spoke...' - Line 778 has weird spacing: '...logical line ...' - Line 779 has weird spacing: '...prising a fie...' - Line 780 has weird spacing: '...ld-body porti...' - Line 781 has weird spacing: '... this conce...' - (13 more instances...) No nits found. At least some of the "weird spacing" warnings are legitimate warnings, and the text needs to be fixed in those cases. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 10 00:25:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrTNl-0004KV-2e; Sun, 10 Jul 2005 00:25:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrTNj-0004KN-Bw for ltru@megatron.ietf.org; Sun, 10 Jul 2005 00:25:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16731 for ; Sun, 10 Jul 2005 00:25:27 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrTpO-0000wp-EK for ltru@ietf.org; Sun, 10 Jul 2005 00:54:10 -0400 Received: from h-68-166-188-152.snvacaid.dynamic.covad.net ([68.166.188.152] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DrTNU-0006jT-00 for ltru@ietf.org; Sun, 10 Jul 2005 00:25:16 -0400 Message-ID: <00a801c58507$f3dadf80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Sat, 9 Jul 2005 21:28:29 -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: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [Ltru] minor editorial bits in -08 of registry 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - A few very minor things jumped out at me from -08 of the registry draft. If these aren't already fixed, they should be: "Supress" -> "Suppress" "SIL" abbreviation should be expanded on first use "Thie field" -> "The field" "stylesheet" -> "style sheet" "the the" -> "the" "othography" -> orthography Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 10 00:39:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrTbd-000060-T8; Sun, 10 Jul 2005 00: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 1DrTbd-00005v-5O for ltru@megatron.ietf.org; Sun, 10 Jul 2005 00:39:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17515 for ; Sun, 10 Jul 2005 00:39:49 -0400 (EDT) Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrU3L-0001Rj-DW for ltru@ietf.org; Sun, 10 Jul 2005 01:08:32 -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 j6A4dZ10215814 for ; Sun, 10 Jul 2005 00:39:35 -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 j6A4dYcC201940 for ; Sat, 9 Jul 2005 22:39:35 -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 j6A4dYY4009939 for ; Sat, 9 Jul 2005 22:39:34 -0600 Received: from markdavis (sig-9-48-121-129.mts.ibm.com [9.48.121.129]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j6A4dWKq009912; Sat, 9 Jul 2005 22:39:34 -0600 Message-ID: <012c01c58509$5d47beb0$6501a8c0@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <20050709215901.UXHV4366.mta6.adelphia.net@megatron.ietf.org><005701c584da$bb525800$030aa8c0@DEWELL> <000401c584e0$28fdf580$7f1afea9@oemcomputer> Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Date: Sat, 9 Jul 2005 18:07:26 -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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e34.co.us.ibm.com id j6A4dZ10215814 X-Spam-Score: 0.7 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 agree. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Saturday, July 09, 2005 16:44 Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) > Hi - > > > From: "Doug Ewell" > > To: "LTRU Working Group" > > Sent: Saturday, July 09, 2005 4:05 PM > > Subject: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) > ... > > So if we want to allow 831 and friends to be individually registrable= , > > cool, but let's not come back later and say, "Wait a minute! We need= ed > > 831 as a safety net! What were we thinking?" > > > > > I propose adding one sentence to 3.3(11) to make it more consistent > > > with 2.2.4 (3E): "If the petition for a code assignment ISO 3166 i= s > > > refused or not acted on in a timely manner, the Language Subtag > > > Reviewer MAY procede with the registration using the UN M.49 code." > > > Or words to that effect. > ... > > They'd still be a safety net - they'd only (in this case) be registerab= le > if the ISO 3166 code assignment request is refused or ignored. The decision > whether to accept the registration would still be subject to debate on = the > ietf-languages@iana.org list. At least that was my thinking. > > If UN M.49 changes 831's meaning to refer to something else, then there= is > a problem with the whole idea of them being a safety net. If a request for > an ISO 3166 code to match 831 is first refused, and then a couple years later > accepted, well, that's just FUBAR. :-) > > 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 Sun Jul 10 01: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 1DrTyW-0006vj-Kl; Sun, 10 Jul 2005 01:03:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrTyU-0006vb-Ft for ltru@megatron.ietf.org; Sun, 10 Jul 2005 01:03:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18438 for ; Sun, 10 Jul 2005 01:03:26 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrUQA-00029Y-3m for ltru@ietf.org; Sun, 10 Jul 2005 01:32:07 -0400 Received: from h-68-166-188-152.snvacaid.dynamic.covad.net ([68.166.188.152] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DrTyO-0007Fn-00 for ltru@ietf.org; Sun, 10 Jul 2005 01:03:24 -0400 Message-ID: <00ae01c5850d$497faba0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Sat, 9 Jul 2005 22:07: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: c0bedb65cce30976f0bf60a0a39edea4 Cc: Subject: [Ltru] editorial nits in initial 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 Hi - A few minor editorial comments on the -01 registry draft. Need to ensure that the "RFC 3066bis" in the Abstract gets replaced with the actual RFC number during the RFC editing process. "This memo does not define the permanent contents of the registry." isn't quite what we need to say. If there's no objection, I suggest something like "Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieue of the registry." The last sentence of section 1 ("The process for determining the contents of this registry is defined in Section 3.7 of [I-D.ietf-ltru-registry].") isn't needed, since that material immediately follows. (I bet the RFC editor gets rid of the inter-section page breaks. :-) "the the" -> "the" "RFC 3066" needs a reference. (informative) "This section defines the process used to create the initial registry entries." -> "This section describes the process that was used to create the initial registry entries." "The initial set of records is based on the following standards:" -> "The initial set of records was based on the following standards:" "7. Tags in the RFC 3066 registry that are not deprecated, consist entirely of subtags already in this document, and have the correct" -> "7. Tags in the RFC 3066 registry that were not deprecated, consisted entirely of subtags already in that document, and have the correct" / 8. Tags in the RFC 3066 registry that contain one or more subtags that either do not match the valid registration pattern or are not otherwise defined by [I-D.ietf-ltru-registry] were converted to corresponding records of type "grandfathered" in the ILSR. / -> / 8. Tags in the RFC 3066 registry that contained one or more subtags that either did not match the valid registration pattern or were not otherwise defined by [I-D.ietf-ltru-registry] were converted to corresponding records of type "grandfathered" in the ILSR. / / 9. Tags in the RFC 3066 registry that have a notation that they are deprecated were converted to records of type "grandfathered"/ -> / 9. Tags in the RFC 3066 registry that had a notation that they were deprecated were converted to records of type "grandfathered"/ "original tag is superseded by [I-D.ietf-ltru-registry]." -> " original tag is superseded." Do we really need this paragraph in this document? Any additional registrations completed after the adoption of [I-D.ietf-ltru-registry] using the rules in RFC 3066 will be incorporated into the Language Subtag Registry using the rules defined above, or will result in the submission of appropriate records by the Language Subtag Reviewer according to the rules in [I-D.ietf-ltru-registry]. This paragraph also doesn't belong in this document. All existing RFC 3066 language tag registrations will be maintained in perpetuity. It's about registry maintenance, rather than initialization. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 10 01:32:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrUQj-00074L-Uf; Sun, 10 Jul 2005 01:32:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrUQh-00074D-Qz for ltru@megatron.ietf.org; Sun, 10 Jul 2005 01:32:40 -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 BAA19331 for ; Sun, 10 Jul 2005 01:32: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 <20050710053208.KETG29002.mta9.adelphia.net@DEWELL>; Sun, 10 Jul 2005 01:32:08 -0400 Message-ID: <000601c58510$9e526ca0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" , References: <20050709215901.UXHV4366.mta6.adelphia.net@megatron.ietf.org> <005701c584da$bb525800$030aa8c0@DEWELL> <20050710014936.GD7948@NYCMJCOWA2> Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Date: Sat, 9 Jul 2005 22:31:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 BAA19331 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 John dot Cowan wrote: > Quite right. In fact, 'xno' is apparently meant for the now extinct > Norman French once spoken in England, and does not cover Dg=E8rn=E9siai= s > and J=E8rriais at all. Rather, the Ethnologue (and *a fortiori* ISO > 639-3) considers them varieties of "fr", like all the *langues d'o=EFl* > except Walloon and Picard (probably because those two have some > official status in Belgium). According to Wikipedia, "Dg=E8rn=E9siais is recognised (along with J=E8rr= iais, Irish, Scottish Gaelic, Welsh, Manx and Scots (in Scotland and Northern Ireland)) as a regional language by the British and Irish governments within the framework of the British-Irish Council." So if it is true that Walloon and Picard are encoded separately because of their status in Belgium, BSI might consider that Dg=E8rn=E9siais and J=E8rriais should benefit in a similar 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@lists.ietf.org Sun Jul 10 06:22:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrYwx-0000jU-1q; Sun, 10 Jul 2005 06:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrYwv-0000jP-9S for ltru@megatron.ietf.org; Sun, 10 Jul 2005 06:22:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21873 for ; Sun, 10 Jul 2005 06:22:09 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrZOd-0000tv-Nm for ltru@ietf.org; Sun, 10 Jul 2005 06:50:54 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6AALdC05805; Sun, 10 Jul 2005 19:21:39 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 096fba86_f12e_11d9_834a_0030482532aa_1597; Sun, 10 Jul 2005 19:33:21 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO007A7A; 10 Jul 05 19:27:07 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 10 Jul 05 19:26:39 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.250.5) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG007A73; 10 Jul 05 19:26:32 +0900 Message-Id: <6.0.0.20.2.20050710172451.075d30a0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 10 Jul 2005 17:30:04 +0900 To: r&d afrac , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: status? last call? In-Reply-To: <6.2.1.2.2.20050709144837.0398f9f0@mail.afrac.org> References: <20050708202214.FJXR27419.mta2.adelphia.net@megatron.ietf.org> <007901c58450$44398e80$030aa8c0@DEWELL> <6.2.1.2.2.20050709144837.0398f9f0@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 [chair hat off] At 22:54 05/07/09, r&d afrac wrote: >This, I believe, describes perfectly why the Draft doctrine adds to the basic error of RFC 3066 attenuated by its lose application (that IETF has the capacity to correlate non protocol parameters). Jon Postel had clearly established it: this is none of the IANA business. Not only it seems that cultural empowerment is ignored by the author of this text. But, since the topic here is ISO 3166, it shows a remakable confusion between Senegal and Zimbabwe which precisely document my point and the difficulty to establish general rules in a world made of particulars. I don't see why RFC 1766, RFC 3066, and RFC 3066 would ignore cultural empowerment. After all, these specs allow for people (anybody with an email account!) to apply for a registration. This is much more flexible than ISO process (which fortunately has become somewhat more flexible recently). Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 10 09:51:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrcDn-0002w3-GZ; Sun, 10 Jul 2005 09:51:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrcDm-0002vy-JY for ltru@megatron.ietf.org; Sun, 10 Jul 2005 09:51: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 JAA02159 for ; Sun, 10 Jul 2005 09:51:47 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DrcDB-0008V5-Ks for ltru@lists.ietf.org; Sun, 10 Jul 2005 15:51:13 +0200 Received: from du-001-201.access.de.clara.net ([212.82.227.201]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jul 2005 15:51:13 +0200 Received: from nobody by du-001-201.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 10 Jul 2005 15:51:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 10 Jul 2005 15:49:58 +0200 Organization: Lines: 7 Message-ID: <42D12786.42BE@xyzzy.claranet.de> References: <00a801c58507$f3dadf80$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-201.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: minor editorial bits in -08 of registry 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > "othography" -> orthography www.w3.org/2002/01/spellchecker is quite nice (Addison could even add new terms to its dictionary) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 10 11:14:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrdVu-0006AR-8H; Sun, 10 Jul 2005 11:14:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrdVt-0006AM-9q for ltru@megatron.ietf.org; Sun, 10 Jul 2005 11:14:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07490 for ; Sun, 10 Jul 2005 11:14: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.43) id 1Drdxg-0002ob-Q3 for ltru@ietf.org; Sun, 10 Jul 2005 11:43:22 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 08:14: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] minor editorial bits in -08 of registry draft Date: Sun, 10 Jul 2005 08:14:21 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C108BE0@irvmbxw01.quest.com> Thread-Topic: [Ltru] minor editorial bits in -08 of registry draft Thread-Index: AcWFB53iGcTM1rQwTnuj345JcviHhwAWjKYA From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 10 Jul 2005 15:14:21.0982 (UTC) FILETIME=[0CE91BE0:01C58562] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 A fresh spell-check and cleanup of these items will be posted as = draft-09 shortly. I'm digesting the flurry of email from a brief = (three-day) hiatus (went fishing, literally). 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: 2005?7?9? 21:28 > To: LTRU Working Group > Subject: [Ltru] minor editorial bits in -08 of registry draft >=20 > Hi - >=20 > A few very minor things jumped out at me from -08 of the registry = draft. > If these aren't already fixed, they should be: >=20 > "Supress" -> "Suppress" > "SIL" abbreviation should be expanded on first use > "Thie field" -> "The field" > "stylesheet" -> "style sheet" > "the the" -> "the" > "othography" -> orthography >=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 Sun Jul 10 11:21:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drdcy-000828-C3; Sun, 10 Jul 2005 11:21:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drdcw-0007zi-Qu for ltru@megatron.ietf.org; Sun, 10 Jul 2005 11:21:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07781 for ; Sun, 10 Jul 2005 11:21: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.43) id 1Dre4k-000338-VI for ltru@ietf.org; Sun, 10 Jul 2005 11:50:40 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 08:21:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Additional descriptions not found in ISO Date: Sun, 10 Jul 2005 08:21:41 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C108BE1@irvmbxw01.quest.com> Thread-Topic: [Ltru] Additional descriptions not found in ISO Thread-Index: AcWEx6SPNv3PM2muQvKvTUql7R7WJgAmw8AQ From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 10 Jul 2005 15:21:42.0562 (UTC) FILETIME=[13844820:01C58563] X-Spam-Score: 0.0 (/) 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: , Content-Type: multipart/mixed; boundary="===============1760676130==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1760676130== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiAyLiAgQWRkaXRpb25hbCBEZXNjcmlwdGlvbiBmaWVsZHMgY2FuIGFsd2F5cyBiZSBwcm9wb3Nl ZCBmb3INCj4gcmVnaXN0cmF0aW9uIGFmdGVyIHRoZSBSRkMgZ29lcyBsaXZlLCBzdWJqZWN0IHRv IHRoZSByZXN0cmljdGlvbiBhYm91dA0KPiBub3QgY2hhbmdpbmcgdGhlIG1lYW5pbmcuDQoNCk1v cmVvdmVyLCB0aGUgJ0Rlc2NyaXB0aW9uJyBmaWVsZCBpcyBub3QgZ3VhcmFudGVlZCB0byBiZSBz dGFibGU6IGl0IGNhbiBiZSBlZGl0ZWQgdmlhIHRoZSByZWdpc3RyYXRpb24gcHJvY2Vzcy4gVGhl cmUgaXMgcXVpdGUgYSBsaXN0IG9mIHRoaW5ncyB0aGF0IGNhbiBiZSBjaGFuZ2VkIGFib3V0IGl0 IGluIFNlY3Rpb24gMy4zKHJ1bGUgMikuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlw cw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzNDIElu dGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFsaXph dGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQoNCg== --===============1760676130== 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 --===============1760676130==-- From ltru-bounces@lists.ietf.org Sun Jul 10 11:28:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrdjS-0001GE-Vo; Sun, 10 Jul 2005 11:28:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrdjS-0001G9-0e for ltru@megatron.ietf.org; Sun, 10 Jul 2005 11:28:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08137 for ; Sun, 10 Jul 2005 11:28: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.43) id 1DreBH-0003Gd-5B for ltru@ietf.org; Sun, 10 Jul 2005 11:57:23 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 08:28:28 -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 #1061] eliminate (or proscribe) Private Use Tags Date: Sun, 10 Jul 2005 08:28:27 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C108BE2@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags Thread-Index: AcWETVcepqna5PM3T4upYscy5FG8+wBFnZOg From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 10 Jul 2005 15:28:28.0722 (UTC) FILETIME=[059B6120:01C58564] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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="===============0729420777==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0729420777== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSdsbCBhZGQgdGhlIGFkZGl0aW9uYWwgdGV4dCBhYm91dCBwcml2YXRlIHVzZSBzdWJ0YWdzIHRv IHNlY3Rpb24gNC41LiBJbiByZWFkaW5nIHRoaXMgdGhyZWFkOiBkaWQgYW55b25lIGxvb2sgYXQg dGhlIGV4aXN0aW5nIHNlY3Rpb24gNC41PyE/DQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGls bGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwgVzND IEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlvbmFs aXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0 Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBP ZiBEb3VnIEV3ZWxsDQo+IFNlbnQ6IDIwMDXlubQ35pyIOOaXpSAyMzoxMQ0KPiBUbzogTFRSVSBX b3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFtMdHJ1XSBSZTogW3BzZy5jb20gIzEwNjFdIGVsaW1p bmF0ZSAob3IgcHJvc2NyaWJlKSBQcml2YXRlIFVzZQ0KPiBUYWdzDQo+IA0KPiBSYW5keSBQcmVz dWhuIDxyYW5keSB1bmRlcnNjb3JlIHByZXN1aG4gYXQgbWluZHNwcmluZyBkb3QgY29tPiB3cm90 ZToNCj4gDQo+ID4gSSBjYW4ndCBzdXBwb3J0ICgyKSBpbiBpdHMgY3VycmVudCBmb3JtLCBidXQg Y291bGQgbGl2ZSB3aXRoIGENCj4gPiBtb2RpZmllZCB2ZXJzaW9uIG9mICgyKSB0aGF0IEknbGwg Y2FsbCAoMmEpOg0KPiA+DQo+ID4gKDIpICJQcml2YXRlLXVzZSBzdWJ0YWdzIHJlcXVpcmUgcHJp dmF0ZSBhZ3JlZW1lbnQgYmV0d2VlbiBwYXJ0aWVzDQo+ID4gICAgIGludGVuZGluZyB0byB1c2Ug dGhlbS4gVXNlIGdyZWF0IGNhdXRpb24gaWYgZW1wbG95aW5nIHRoZW0gaW4NCj4gPiAgICAgY29u dGVudCBvciBwcm90b2NvbHMgaW50ZW5kZWQgZm9yIGdlbmVyYWwgdXNlLiBQcml2YXRlLXVzZSBz dWJ0YWdzDQo+ID4gICAgIE1VU1QgY29uZm9ybSB0byB0aGUgZm9ybWF0IGNvbnRyYWludHMgc3Bl Y2lmaWVkIGluIHRoZSBBQk5GLg0KPiA+ICAgICBQcml2YXRlLXVzZSBzdWJ0YWdzIGFyZSB1c2Vs ZXNzIGZvciBpbmZvcm1hdGlvbiBleGNoYW5nZSB3aXRob3V0DQo+ID4gICAgIHByaW9yIGFycmFu Z2VtZW50LiINCj4gDQo+IFN0b3AgcmlnaHQgdGhlcmUuICBUaGF0IG9uZSBpcyBncmVhdDsgbGV0 J3MgZ28gd2l0aCBpdC4gIChXZWxsLCBPSywNCj4gbGV0J3Mgc3BlbGwgImNvbnN0cmFpbnQiIGNv cnJlY3RseSBhbmQgdGhlbiBnbyB3aXRoIGl0LikNCj4gDQo+IC0tDQo+IERvdWcgRXdlbGwNCj4g RnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+IGh0dHA6Ly91c2Vycy5hZGVscGhpYS5uZXQvfmRld2Vs bC8NCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQo= --===============0729420777== 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 --===============0729420777==-- From ltru-bounces@lists.ietf.org Sun Jul 10 11:43:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrdxX-0004le-Jy; Sun, 10 Jul 2005 11:43:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrdxW-0004lT-51 for ltru@megatron.ietf.org; Sun, 10 Jul 2005 11:43:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08713 for ; Sun, 10 Jul 2005 11:43: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.43) id 1DrePL-0003ow-AW for ltru@ietf.org; Sun, 10 Jul 2005 12:11:55 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 08: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] minor editorial bits in -08 of registry draft Date: Sun, 10 Jul 2005 08:43:00 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C108BE3@irvmbxw01.quest.com> Thread-Topic: [Ltru] minor editorial bits in -08 of registry draft Thread-Index: AcWFB53iGcTM1rQwTnuj345JcviHhwAXh5Uw From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 10 Jul 2005 15:43:00.0742 (UTC) FILETIME=[0D5F1260:01C58566] 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 Done these. Interestingly, "SIL" no longer stands for anything, if their web site is = to be believed. To use their formal name, I changed the paragraph = thusly: For example: Users who wished to utilize codes from the Ethnologue = publication of SIL International for=20 Language identification might agree to exchange tags such as=20 "az-Arab-x-AZE-derbend". This example contains two private-use = subtags.=20 The first is 'AZE' and the second is 'derbend'. 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: 2005?7?9? 21:28 > To: LTRU Working Group > Subject: [Ltru] minor editorial bits in -08 of registry draft >=20 > Hi - >=20 > A few very minor things jumped out at me from -08 of the registry = draft. > If these aren't already fixed, they should be: >=20 > "Supress" -> "Suppress" > "SIL" abbreviation should be expanded on first use > "Thie field" -> "The field" > "stylesheet" -> "style sheet" > "the the" -> "the" > "othography" -> orthography >=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 Sun Jul 10 11:54:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dre8e-0007eS-5N; Sun, 10 Jul 2005 11: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 1Dre8c-0007eJ-Kt for ltru@megatron.ietf.org; Sun, 10 Jul 2005 11:54:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09083 for ; Sun, 10 Jul 2005 11:54:36 -0400 (EDT) Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DreaR-0004HE-0C for ltru@ietf.org; Sun, 10 Jul 2005 12:23:24 -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 <20050710155423.UKZK19267.mta10.adelphia.net@DEWELL>; Sun, 10 Jul 2005 11:54:23 -0400 Message-ID: <000a01c58567$9f197aa0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C108BE2@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags Date: Sun, 10 Jul 2005 08:54: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 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 Addison Phillips wrote: > In reading this thread: did anyone look at the existing section 4.5?!? I did; it was my basis for claiming the wording was already strong enough. -- 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 Jul 10 11:56:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dre9w-00086h-KH; Sun, 10 Jul 2005 11:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dre9v-0007x8-19 for ltru@megatron.ietf.org; Sun, 10 Jul 2005 11:55:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09200 for ; Sun, 10 Jul 2005 11:55:54 -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.43) id 1Drebi-0004Im-1T for ltru@ietf.org; Sun, 10 Jul 2005 12:24:42 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 08:55:43 -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: Finishing off #1026 (Was: Re: status? last call?) Date: Sun, 10 Jul 2005 08:55:42 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C108BE4@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Thread-Index: AcWE0YcrXhFHGscMTCK8JnsGW798qQAlUCIg From: "Addison Phillips" To: "Mark Davis" , "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 10 Jul 2005 15:55:43.0510 (UTC) FILETIME=[D4043B60:01C58567] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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="===============0784599114==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0784599114== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 V2hpY2ggbWFrZXMgdGhlIHRleHQgaW4gcnVsZSAxMSBhIHByb2JsZW06IHRoZXJlIGlzIGEgTVVT VCBOT1QgZm9sbG93ZWQgYnkgYSBNQVkuIEkgcGVyZm9ybWVkIHRoZSByZXF1ZXN0ZWQgZWRpdHMs IGNoYW5nZWQgdGhlIE1VU1QgTk9UIHRvIFNIT1VMRCBOT1QsIHJlZmVyZW5jZWQgdGhlIHJlZ2lz dHJhdGlvbiBwcm9jZXNzICh0aGUgc3VidGFnIHJldmlld2VyIGRvZXMgTk9UIHJlZ2lzdGVyIHRo ZXNlIHRoaW5ncyB3aXRob3V0IGEgcmVxdWVzdCksIGFuZCBkaWQgc29tZSBlZGl0b3JpYWwgdHVn Z2luZyBhcyBmb2xsb3dzOg0KDQo8dD5Db2RlcyBhc3NpZ25lZCBieSBVTiBNLjQ5IHRvIGNvdW50 cmllcyBvciBhcmVhcyAoYXMgb3Bwb3NlZCB0byBnZW9ncmFwaGljYWwgcmVnaW9ucyBhbmQgc3Vi LXJlZ2lvbnMpIGZvciB3aGljaCB0aGVyZSBpcyBubyBjb3JyZXNwb25kaW5nIElTTyAzMTY2IGNv ZGUgU0hPVUxEIE5PVCBiZSByZWdpc3RlcmVkLCBleGNlcHQgdW5kZXIgdGhlIHByZXZpb3VzIHBy b3Zpc2lvbnMgKGFzIGEgc3Vycm9nYXRlIGZvciBhbiBJU08gMzE2NiBjb2RlIHRoYXQgaXMgYmxv Y2tlZCBmcm9tIHJlZ2lzdHJhdGlvbiBieSBhbiBleGlzdGluZyBzdWJ0YWcpLiBJZiBpdCBiZWNv bWVzIG5lY2Vzc2FyeSB0byBpZGVudGlmeSBhIHJlZ2lvbiBmb3Igd2hpY2ggb25seSBhIFVOIE0u NDkgY29kZSBleGlzdHMgaW4gbGFuZ3VhZ2UgdGFncywgdGhlbiB0aGUgcmVnaXN0cmF0aW9uIGF1 dGhvcml0eSBmb3IgSVNPIDMxNjYgU0hPVUxEIGJlIHBldGl0aW9uZWQgdG8gYXNzaWduIGEgY29k ZTogc3VjaCBhIGNvZGUgY291bGQgdGhlbiBiZSByZWdpc3RlcmVkIGZvciB1c2UgaW4gbGFuZ3Vh Z2UgdGFncy4gSWYgdGhlIHBldGl0aW9uIGZvciBhIGNvZGUgYXNzaWdubWVudCBieSBJU08gMzE2 NiBpcyByZWZ1c2VkDQpvciBub3QgYWN0ZWQgb24gaW4gYSB0aW1lbHkgbWFubmVyLCB0aGUgcmVn aXN0cmF0aW9uIHByb2Nlc3MgZGVzY3JpYmVkIGluIDx4cmVmIHRhcmdldD0icmVnaXN0cmF0aW9u UHJvYyI+PC94cmVmPiBNQVkgdGhlbiBiZSB1c2VkIHRvIHJlcXVlc3QgYW5kIHRoZSBMYW5ndWFn ZSBTdWJ0YWcgUmV2aWV3ZXIgTUFZDQpwcm9jZWVkIHdpdGggdGhlIHJlZ2lzdHJhdGlvbiBvZiB0 aGUgY29ycmVzcG9uZGluZyBVTiBNLjQ5IGNvZGUuIEF0IHRoZSB0aW1lIHRoaXMgZG9jdW1lbnQg d2FzIHdyaXR0ZW4sIHRoZXJlIHdlcmUgb25seSBmb3VyIHN1Y2ggY29kZXM6IDgzMCAoQ2hhbm5l bCBJc2xhbmRzKSwgODMxIChHdWVybnNleSksIDgzMiAoSmVyc2V5KSwgYW5kIDgzMyAoSXNsZSBv ZiBNYW4pLiBUaGlzIHJ1bGUgZXhpc3RzIHNvIHRoYXQgVU4gTS40OSBjb2RlcyByZW1haW4gYXZh aWxhYmxlIGFzIHRoZSB2YWx1ZSBvZiBsYXN0IHJlc29ydCBpbiBjYXNlcyB3aGVyZSBJU08gMzE2 NiByZWFzc2lnbnMgYSBkZXByZWNhdGVkIHZhbHVlIGluIHRoZSByZWdpc3RyeS48L3Q+DQoNCkFk ZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2Fy ZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0K SW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVj dHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3Vu Y2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnXSBP bg0KPiBCZWhhbGYgT2YgTWFyayBEYXZpcw0KPiBTZW50OiAyMDA15bm0N+aciDnml6UgMTQ6NTgN Cj4gVG86IFJhbmR5IFByZXN1aG47IExUUlUgV29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBSZTog W0x0cnVdIFJlOiBGaW5pc2hpbmcgb2ZmICMxMDI2IChXYXM6IFJlOiBzdGF0dXM/IGxhc3QgY2Fs bD8pDQo+IA0KPiBJIGFncmVlIHdpdGggdGhlIGNsYXJpZmljYXRpb24gUmFuZHkgc3VnZ2VzdHMu DQo+IA0KPiDigI5NYXJrDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZy b206ICJSYW5keSBQcmVzdWhuIiA8cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbT4NCj4gVG86 ICJMVFJVIFdvcmtpbmcgR3JvdXAiIDxsdHJ1QGlldGYub3JnPg0KPiBTZW50OiBTYXR1cmRheSwg SnVseSAwOSwgMjAwNSAxMzo1NQ0KPiBTdWJqZWN0OiBSZTogW0x0cnVdIFJlOiBGaW5pc2hpbmcg b2ZmICMxMDI2IChXYXM6IFJlOiBzdGF0dXM/IGxhc3QgY2FsbD8pDQo+IA0KPiANCj4gPiBIaSAt DQo+ID4NCj4gPiBBcyBhIHRlY2huaWNhbCBjb250cmlidXRvci4uLg0KPiA+DQo+ID4gPiBGcm9t OiAiRG91ZyBFd2VsbCIgPGRld2VsbEBhZGVscGhpYS5uZXQ+DQo+ID4gPiBUbzogIkxUUlUgV29y a2luZyBHcm91cCIgPGx0cnVAaWV0Zi5vcmc+DQo+ID4gPiBTZW50OiBGcmlkYXksIEp1bHkgMDgs IDIwMDUgMTE6NDYgUE0NCj4gPiA+IFN1YmplY3Q6IFtMdHJ1XSBSZTogRmluaXNoaW5nIG9mZiAj MTAyNiAoV2FzOiBSZTogc3RhdHVzPyBsYXN0IGNhbGw/KQ0KPiA+IC4uLg0KPiA+ID4gVGhlIGRy YWZ0IGlzIG5vdCBjb25zaXN0ZW50IHdpdGggaXRzZWxmLiAgU2VjdGlvbiAyLjIuNCAoM0UpLCBx dW90ZWQNCj4gPiA+IGFib3ZlLCBzYXlzIHdlIGNhbiByZWdpc3RlciBzdWNoIHN1YnRhZ3MuICBT ZWN0aW9uIDMuNCAoMTEpLCB0byB3aGljaA0KPiBJDQo+ID4gPiByZWZlcnJlZCwgc2F5cyB3ZSBt YXkgbm90Lg0KPiA+IC4uLg0KPiA+DQo+ID4gSSB0aGluayB5b3UgbWVhbiBzZWN0aW9uIDMuMyAo MTEpLiAgVGhlIHRleHQgdGhlcmUgaW4gdGhlDQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1sdHJ1LXJlZ2lzdHJ5LTA4LnR4dA0KPiA+IGRyYWZ0IHNh eXM6DQo+ID4NCj4gPiAgICAxMS4gIENvZGVzIGFzc2lnbmVkIGJ5IFVOIE0uNDkgdG8gY291bnRy aWVzIG9yIGFyZWFzIChhcyBvcHBvc2VkIHRvDQo+ID4gICAgICAgICBnZW9ncmFwaGljYWwgcmVn aW9ucyBhbmQgc3ViLXJlZ2lvbnMpIGZvciB3aGljaCB0aGVyZSBpcyBubw0KPiA+ICAgICAgICAg Y29ycmVzcG9uZGluZyBJU08gMzE2NiBjb2RlIE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQsIGV4Y2Vw dCB1bmRlcg0KPiA+ICAgICAgICAgdGhlIHByZXZpb3VzIHByb3Zpc2lvbnMgKGFzIGEgc3Vycm9n YXRlIGZvciBhbiBJU08gMzE2NiBjb2RlDQo+ID4gICAgICAgICB0aGF0IGNhbm5vdCBpdHNlbGYg YmUgcmVnaXN0ZXJlZCkuICBJZiBpdCBpcyBuZWNlc3NhcnkgdG8NCj4gPiAgICAgICAgIGlkZW50 aWZ5IGEgcmVnaW9uIGZvciB3aGljaCBvbmx5IGEgVU4gTS40OSBjb2RlIGV4aXN0cyBpbg0KPiA+ ICAgICAgICAgbGFuZ3VhZ2UgdGFncywgdGhlbiB0aGUgcmVnaXN0cmF0aW9uIGF1dGhvcml0eSBm b3IgSVNPIDMxNjYNCj4gPiAgICAgICAgIFNIT1VMRCBiZSBwZXRpdGlvbmVkIHRvIGFzc2lnbiBh IGNvZGUsIHdoaWNoIGNhbiB0aGVuIGJlDQo+ID4gICAgICAgICByZWdpc3RlcmVkIGZvciB1c2Ug aW4gbGFuZ3VhZ2UgdGFncy4gIEF0IHRoZSB0aW1lIHRoaXMgZG9jdW1lbnQNCj4gPiAgICAgICAg IHdhcyB3cml0dGVuLCB0aGVyZSB3ZXJlIG9ubHkgZm91ciBzdWNoIGNvZGVzOiA4MzAgKENoYW5u ZWwNCj4gPiAgICAgICAgIElzbGFuZHMpLCA4MzEgKEd1ZXJuc2V5KSwgODMyIChKZXJzZXkpLCBh bmQgODMzIChJc2xlIG9mIE1hbikuDQo+ID4gICAgICAgICBUaGlzIHJ1bGUgZXhpc3RzIHNvIHRo YXQgVU4gTS40OSBjb2RlcyByZW1haW4gYXZhaWxhYmxlIGFzIHRoZQ0KPiA+ICAgICAgICAgdmFs dWUgb2YgbGFzdCByZXNvcnQgaW4gY2FzZXMgd2hlcmUgSVNPIDMxNjYgcmVhc3NpZ25zIGENCj4g PiAgICAgICAgIGRlcHJlY2F0ZWQgdmFsdWUgaW4gdGhlIHJlZ2lzdHJ5Lg0KPiA+DQo+ID4gVGhl IGRpZmZlcmVuY2UgaW4gb3VyIHVuZGVyc3RhbmRpbmcgY29tZXMgZnJvbSB0aGUgbGFzdCBzZW50 ZW5jZS4gIEkNCj4gdGhpbmsNCj4gPiBEb3VnIGlzIHJlYWRpbmcgaXQgYXMgdGhlICpzb2xlKiBj b25kaXRpb24gdW5kZXIgd2hpY2ggcnVsZSAzLjMoMTEpIG1heQ0KPiA+IGJlIGVtcGxveWVkLiAg SSwgYW5kIEkgdGhpbmsgRnJhbmssIHJlYWQgaXQgYXMgdGhlICptb3RpdmF0aW9uKiBmb3IgdGhl DQo+ID4gcnVsZSwgcmF0aGVyIHRoYW4gYSBsaW1pdGluZyBjb25kaXRpb24uICBUaGUgdHdvIHJl YWRpbmdzIHBsYXkgb3V0DQo+ID4gZGlmZmVyZW50bHkgaWYgdGhlIElTTyAzMTY2IHJlZ2lzdHJh dGlvbiBhdXRob3JpdHkgZmFpbHMgdG8gYXNzaWduIGENCj4gPiBjb2RlIHdoZW4gcGV0aXRpb25l ZC4gIEluIERvdWcncyByZWFkaW5nLCB0aGVyZSdzIG5vIHJlZ2lzdHJhdGlvbiwNCj4gPiBhbmQg dGhlIHBhcnR5IG5lZWRpbmcgdGhlIGNvZGUgaXMgb3V0IG9mIGx1Y2suICBJbiB0aGUgYWx0ZXJu YXRpdmUNCj4gPiByZWFkaW5nLCBhZnRlciBzb21lIHVuZGVmaW5lZCAoSSdkIGxlYXZlIGl0IHVw IHRvIHRoZSBjb2xsZWN0aXZlDQo+ID4gaW50ZWxsaWdlbmNlIG9mIHRoZSBsYW5ndWFnZSB0YWcg bWFpbGluZyBsaXN0KSBwZXJpb2QsIHRoZSBVTiBNLjQ5DQo+ID4gY29kZSBjb3VsZCBiZSByZWdp c3RlcmVkLiAgVGhlIHF1ZXN0aW9uIGZvciB0aGUgV0cgaXMgd2hpY2ggYmVoYXZpb3VyDQo+ID4g aXMgYmV0dGVyIC8gbGVzcyBiYWQ/DQo+ID4NCj4gPiBJIHByb3Bvc2UgYWRkaW5nIG9uZSBzZW50 ZW5jZSB0byAzLjMoMTEpIHRvIG1ha2UgaXQgbW9yZSBjb25zaXN0ZW50IHdpdGgNCj4gPiAyLjIu NCAoM0UpOiAgIklmIHRoZSBwZXRpdGlvbiBmb3IgYSBjb2RlIGFzc2lnbm1lbnQgSVNPIDMxNjYg aXMgcmVmdXNlZA0KPiA+IG9yIG5vdCBhY3RlZCBvbiBpbiBhIHRpbWVseSBtYW5uZXIsIHRoZSBM YW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgTUFZDQo+ID4gcHJvY2VkZSB3aXRoIHRoZSByZWdpc3Ry YXRpb24gdXNpbmcgdGhlIFVOIE0uNDkgY29kZS4iICBPciB3b3JkcyB0bw0KPiA+IHRoYXQgZWZm ZWN0Lg0KPiA+DQo+ID4gVGhpcyBpcyB2ZXJ5IG11Y2ggYSBwYXRob2xvZ2ljYWwgY29ybmVyIGNh c2UsIGFuZCBJIGhhdGUgdG8gc2VlIHVzDQo+ID4gc3BlbmRpbmcgc28gbXVjaCB0aW1lIG9uIGl0 LCBzbyBsZXQncyBwaWNrIG9uZSBvZiB0aGUgYWx0ZXJuYXRpdmUsDQo+ID4gbWFrZSB0aGUgdGV4 dCBjbGVhciB3aGljaCBvbmUgd2UndmUgcGlja2VkLCBhbmQgYmUgZG9uZSB3aXRoIGl0Lg0KPiA+ DQo+ID4gUmFuZHkNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gTHRydSBtYWlsaW5nIGxpc3QNCj4gPiBM dHJ1QGxpc3RzLmlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbHRydQ0KPiA+DQo+ID4NCj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBs aXN0cy5pZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9s dHJ1DQoNCg== --===============0784599114== 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 --===============0784599114==-- From ltru-bounces@lists.ietf.org Sun Jul 10 12:14:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DreRy-00043i-KD; Sun, 10 Jul 2005 12:14:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DreRx-00043d-GY for ltru@megatron.ietf.org; Sun, 10 Jul 2005 12:14: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 MAA10086 for ; Sun, 10 Jul 2005 12:14: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 <20050710161404.DGRT24042.mta11.adelphia.net@DEWELL> for ; Sun, 10 Jul 2005 12:14:04 -0400 Message-ID: <001101c5856a$56eb0e80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050710155701.KLZM24938.mta8.adelphia.net@megatron.ietf.org> Date: Sun, 10 Jul 2005 09:13:40 -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: Finishing off #1026 (Was: Re: status? last call?) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 OK, so the final answer is that we will allow 831 and friends to be registered, after a good faith effort is made to avoid it. I'll edit the text in draft-initial to feature the word MAY. I think we should all take a solemn vow never to allow 830 to be registered, though, now that 831 and 832 exist. -- 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 Jul 10 12: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 1DreaZ-0006WA-Og; Sun, 10 Jul 2005 12: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 1DreaX-0006W5-IS for ltru@megatron.ietf.org; Sun, 10 Jul 2005 12:23:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10426 for ; Sun, 10 Jul 2005 12:23: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.43) id 1Drf2M-00059c-7R for ltru@ietf.org; Sun, 10 Jul 2005 12:52:15 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 09:23: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 #1061] eliminate (or proscribe) Private Use Tags Date: Sun, 10 Jul 2005 09:23:18 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C108BE5@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags Thread-Index: AcWFZ6ZsVMd6LVt+Sc6bm6Q273iAxQAA5xBQ From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 10 Jul 2005 16:23:19.0203 (UTC) FILETIME=[AEE2EF30:01C5856B] 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="===============1582328641==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1582328641== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBoYWQgYSBkZXZpbCBvZiBhIHRpbWUgc3F1YXJpbmcgdGhlIHRocmVhZCB3aXRoIG1vZGlmaWNh dGlvbnMgdG8gc2VjdGlvbiAyLjIuNyBhbmQgc2VjdGlvbiA0LjUuIFdoYXQgSSBlbmRlZCB1cCBk b2luZyB3YXMgYWRkaW5nIHRoaXMgInJ1bGUiIHRvIHNlY3Rpb24gMi4yLjc6DQoNCjx0PlByaXZh dGUgdXNlIHN1YnRhZ3MgYXJlIE5PVCBSRUNPTU1FTkRFRCB3aGVyZSBhbHRlcm5hdGl2ZXMgZXhp c3Qgb3IgZm9yIGdlbmVyYWwgaW50ZXJjaGFuZ2UuIFNlZSA8eHJlZiB0YXJnZXQ9InByaXZhdGV1 c2UiPjwveHJlZj4gZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gcHJpdmF0ZSB1c2Ugc3VidGFnIGNo b2ljZS48L3Q+DQoNCi4uLiBhbmQgdGhlbiBkb2luZyBhbGwgdGhlIHJlcXVlc3RlZCBlZGl0aW5n IGluIHNlY3Rpb24gNC41Lg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFy Y2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24g Q29yZSBXb3JraW5nIEdyb3VwDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1 cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IERvdWcgRXdlbGwgW21haWx0bzpkZXdlbGxAYWRlbHBoaWEubmV0XQ0KPiBT ZW50OiAyMDA15bm0N+aciDEw5pelIDg6NTQNCj4gVG86IExUUlUgV29ya2luZyBHcm91cA0KPiBD YzogQWRkaXNvbiBQaGlsbGlwcw0KPiBTdWJqZWN0OiBSZTogW0x0cnVdIFJlOiBbcHNnLmNvbSAj MTA2MV0gZWxpbWluYXRlIChvciBwcm9zY3JpYmUpIFByaXZhdGUNCj4gVXNlIFRhZ3MNCj4gDQo+ IEFkZGlzb24gUGhpbGxpcHMgPGFkZGlzb24gZG90IHBoaWxsaXBzIGF0IHF1ZXN0IGRvdCBjb20+ IHdyb3RlOg0KPiANCj4gPiBJbiByZWFkaW5nIHRoaXMgdGhyZWFkOiBkaWQgYW55b25lIGxvb2sg YXQgdGhlIGV4aXN0aW5nIHNlY3Rpb24gNC41PyE/DQo+IA0KPiBJIGRpZDsgaXQgd2FzIG15IGJh c2lzIGZvciBjbGFpbWluZyB0aGUgd29yZGluZyB3YXMgYWxyZWFkeSBzdHJvbmcNCj4gZW5vdWdo Lg0KPiANCj4gLS0NCj4gRG91ZyBFd2VsbA0KPiBGdWxsZXJ0b24sIENhbGlmb3JuaWENCj4gaHR0 cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiANCg0KDQo= --===============1582328641== 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 --===============1582328641==-- From ltru-bounces@lists.ietf.org Sun Jul 10 12:32:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dreio-0008Qv-Ta; Sun, 10 Jul 2005 12:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drein-0008Qq-JN for ltru@megatron.ietf.org; Sun, 10 Jul 2005 12:32:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10717 for ; Sun, 10 Jul 2005 12:31: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.43) id 1DrfAd-0005Rg-9H for ltru@ietf.org; Sun, 10 Jul 2005 13:00:47 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 09:31:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 10 Jul 2005 09:31:47 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C108BE7@irvmbxw01.quest.com> Thread-Topic: draft-09 on inter-locale Thread-Index: AcWFbNsUfL9Xno5kTG+mZ1/bYtDQ8A== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 10 Jul 2005 16:31:48.0350 (UTC) FILETIME=[DE5C99E0:01C5856C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Ltru] draft-09 on inter-locale X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1013834338==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1013834338== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 Li4uIHRvIGJlIHN1Ym1pdHRlZCBhZnRlciBJIGRvIGVkaXRvcmlhbCBjbGVhbnVwICh5ZXMsIGxp a2Ugc3BlbGwtY2hlY2tpbmcpLg0KDQpodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJh ZnQtaWV0Zi1sdHJ1LXJlZ2lzdHJ5LTA5LnR4dA0KaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29t L0lEL2RyYWZ0LWlldGYtbHRydS1yZWdpc3RyeS0wOS5odG1sDQoNCkFkZGlzb24NCg0KQWRkaXNv biBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpo dHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENv cmUgV29ya2luZyBHcm91cA0KaHR0cDovL3d3dy53My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRl cm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJl LiANCg0KDQo= --===============1013834338== 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 --===============1013834338==-- From ltru-bounces@lists.ietf.org Sun Jul 10 13:51:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drfxr-0000fH-56; Sun, 10 Jul 2005 13: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 1Drfxo-0000dp-R5 for ltru@megatron.ietf.org; Sun, 10 Jul 2005 13:51: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 NAA14147 for ; Sun, 10 Jul 2005 13:51:35 -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 <20050710175105.YNVE19267.mta10.adelphia.net@DEWELL> for ; Sun, 10 Jul 2005 13:51:05 -0400 Message-ID: <002401c58577$c4854d40$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050710155701.KLZM24938.mta8.adelphia.net@megatron.ietf.org> Date: Sun, 10 Jul 2005 10:49: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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: editorial nits in initial 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 Randy Presuhn wrote: > Need to ensure that the "RFC 3066bis" in the Abstract gets replaced > with the actual RFC number during the RFC editing process. Just let me know how to do that. I tried making this a reference to [I-D.ietf-ltru-registry], but one tool or another didn't like that in the Abstract. > "This memo does not define the permanent contents of the registry." > isn't quite what we need to say. If there's no objection, I suggest > something like "Since the contents of this memo only serve as a > starting point for the registry, it is inappropriate to use this memo > in lieue of the registry." (s/lieue/lieu/) I'm not sure I see the practical difference, but I made the change. Do I need to change the last sentence of the third paragraph of the Introduction as well? > The last sentence of section 1 ("The process for determining the > contents of this registry is defined in Section 3.7 of > [I-D.ietf-ltru-registry].") isn't needed, since that material > immediately follows. Right, that was a holdover from the days before the current Section 2 was created. > (I bet the RFC editor gets rid of the inter-section page breaks. :-) I had to delete so the text in the nested lists in Section 2 wouldn't come out all jammed together. This had the side effect of introducing the page breaks between sections. If anyone can show me a better way to do this, I'd appreciate it. > "the the" -> "the" Done. > "RFC 3066" needs a reference. (informative) Done, everywhere RFC 3066 is mentioned. The one mention of RFC 1766 was also turned into a reference. There are now a LOT more references than before. I also removed the first hyphen in references like [ISO-639-1], changing it to [ISO639-1], because that seems to be the convention. I left [UN-M.49] alone, since it was just too ugly otherwise. > "This section defines the process used to create the initial registry > entries." -> > "This section describes the process that was used to create the > initial registry entries." Done. > "The initial set of records is based on the following standards:" -> > "The initial set of records was based on the following standards:" Done, along with similar present/past tense corrections. > "7. Tags in the RFC 3066 registry that are not deprecated, consist > entirely of subtags already in this document, and have the > correct" -> > "7. Tags in the RFC 3066 registry that were not deprecated, consisted > entirely of subtags already in that document, and have the > correct" No, it's *this* document, the initial registry. The RFC 3066 registry doesn't have subtags, only whole tags. > Do we really need this paragraph in this document? > Any additional registrations completed after the adoption of > [I-D.ietf-ltru-registry] using the rules in RFC 3066 will be > incorporated into the Language Subtag Registry using the rules > defined above, or will result in the submission of appropriate > records by the Language Subtag Reviewer according to the rules in > [I-D.ietf-ltru-registry]. Addison proposed that text on July 5 to replace "New registrations completed under RFC 3066 were entered into the ILSR using the rules defined above." Personally I agree that no text related to ongoing maintenance of the registry belongs in draft-initial. I've commented out the above text, not deleted it, in case a battle ensues about retaining it. > This paragraph also doesn't belong in this document. > All existing RFC 3066 language tag registrations will be maintained > in perpetuity. > It's about registry maintenance, rather than initialization. I agree, and have commented this out as well. Actually, I think all of item 11 from "Interested parties" to the end should be deleted, as it also pertains to registry maintenance, but I'll wait to hear a humming sound before I do anything about it. I have not added any references or explanations regarding the use of Unicode escape sequences. Section 1 briefly mentions record-jar, but then defers all other format-related details to [draft-registry]. 200 has been expurgated from Section 4. Draft-initial-02 is now available: http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-02.txt http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-02.html http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-02.xml -- 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 Jul 10 14:01:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drg7q-0002r4-5l; Sun, 10 Jul 2005 14:01:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drg7o-0002hd-BC for ltru@megatron.ietf.org; Sun, 10 Jul 2005 14:01:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14484 for ; Sun, 10 Jul 2005 14:01:54 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrgZd-0008Vh-Ks for ltru@ietf.org; Sun, 10 Jul 2005 14:30:43 -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 j6AI1beL486824 for ; Sun, 10 Jul 2005 14:01:37 -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 j6AI1b2D370188 for ; Sun, 10 Jul 2005 12:01:37 -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 j6AI1QJt005957 for ; Sun, 10 Jul 2005 12:01:26 -0600 Received: from markdavis (sig-9-48-107-155.mts.ibm.com [9.48.107.155]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j6AI1OC1005693; Sun, 10 Jul 2005 12:01:26 -0600 Message-ID: <01a601c58579$62c4aa40$6501a8c0@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C108BE7@irvmbxw01.quest.com> Subject: Re: [Ltru] draft-09 on inter-locale Date: Sun, 10 Jul 2005 10:55:04 -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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j6AI1beL486824 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 The private use stuff looks fine now. Good job. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "LTRU Working Group" Sent: Sunday, July 10, 2005 09:31 Subject: [Ltru] draft-09 on inter-locale > ... to be submitted after I do editorial cleanup (yes, like spell-checking). > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-09.txt > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-09.html > > 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 Sun Jul 10 14:11:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrgGo-0004qN-PR; Sun, 10 Jul 2005 14: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 1DrgGm-0004q3-Rc for ltru@megatron.ietf.org; Sun, 10 Jul 2005 14:11:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14865 for ; Sun, 10 Jul 2005 14:11:11 -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.43) id 1Drgid-0000OF-8G for ltru@ietf.org; Sun, 10 Jul 2005 14:39:59 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 10 Jul 2005 11:10:58 -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: editorial nits in initial registry draft -01 Date: Sun, 10 Jul 2005 11:10:58 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C108BE8@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: editorial nits in initial registry draft -01 Thread-Index: AcWFeD1vC5BFu0+HRmy5D57/sqaI8AAAgQ1w From: "Addison Phillips" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 10 Jul 2005 18:10:58.0926 (UTC) FILETIME=[B92E70E0:01C5857A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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="===============0169872187==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0169872187== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 WW91J3JlIG5vdCBzdXBwb3NlZCB0byBoYXZlIGEgcmVmZXJlbmNlIGluIHRoZSBhYnN0cmFjdCwg bm8/IEkgZ290IGJlYXQgdXAgb24gdGhhdCBmb3Igd2Vla3MuDQoNCldoeSBub3Qgc2F5Og0KDQoi VGhpcyBtZW1vIGRlZmluZXMgdGhlIGluaXRpYWwgY29udGVudHMgb2YgdGhlIExhbmd1YWdlIFN1 YnRhZyBSZWdpc3RyeSBmb3IgdXNlIGluIGZvcm1pbmcgdGFncyBmb3IgdGhlIGlkZW50aWZpY2F0 aW9uIG9mIGxhbmd1YWdlcy4iDQoNClRoZSBpbnRyb2R1Y3Rpb24gY2FuIHNheSB3aGVyZSBkcmFm dC1yZWdpc3RyeSBpcyBhdCBhbmQgYWxsIHRoYXQuDQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQ aGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpDaGFpciwg VzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KDQpJbnRlcm5hdGlv bmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsdHJ1LWJvdW5jZXNAbGlzdHMu aWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmddIE9uDQo+IEJlaGFs ZiBPZiBEb3VnIEV3ZWxsDQo+IFNlbnQ6IDIwMDXlubQ35pyIMTDml6UgMTA6NTANCj4gVG86IExU UlUgV29ya2luZyBHcm91cA0KPiBTdWJqZWN0OiBbTHRydV0gUmU6IGVkaXRvcmlhbCBuaXRzIGlu IGluaXRpYWwgcmVnaXN0cnkgZHJhZnQgLTAxDQo+IA0KPiBSYW5keSBQcmVzdWhuIDxyYW5keSB1 bmRlcnNjb3JlIHByZXN1aG4gYXQgbWluZHNwcmluZyBkb3QgY29tPiB3cm90ZToNCj4gDQo+ID4g TmVlZCB0byBlbnN1cmUgdGhhdCB0aGUgIlJGQyAzMDY2YmlzIiBpbiB0aGUgQWJzdHJhY3QgZ2V0 cyByZXBsYWNlZA0KPiA+IHdpdGggdGhlIGFjdHVhbCBSRkMgbnVtYmVyIGR1cmluZyB0aGUgUkZD IGVkaXRpbmcgcHJvY2Vzcy4NCj4gDQo+IEp1c3QgbGV0IG1lIGtub3cgaG93IHRvIGRvIHRoYXQu ICBJIHRyaWVkIG1ha2luZyB0aGlzIGEgcmVmZXJlbmNlIHRvDQo+IFtJLUQuaWV0Zi1sdHJ1LXJl Z2lzdHJ5XSwgYnV0IG9uZSB0b29sIG9yIGFub3RoZXIgZGlkbid0IGxpa2UgdGhhdCBpbg0KPiB0 aGUgQWJzdHJhY3QuDQo+IA0KPiA+ICJUaGlzIG1lbW8gZG9lcyBub3QgZGVmaW5lIHRoZSBwZXJt YW5lbnQgY29udGVudHMgb2YgdGhlIHJlZ2lzdHJ5LiINCj4gPiBpc24ndCBxdWl0ZSB3aGF0IHdl IG5lZWQgdG8gc2F5LiAgSWYgdGhlcmUncyBubyBvYmplY3Rpb24sIEkgc3VnZ2VzdA0KPiA+IHNv bWV0aGluZyBsaWtlICJTaW5jZSB0aGUgY29udGVudHMgb2YgdGhpcyBtZW1vIG9ubHkgc2VydmUg YXMgYQ0KPiA+IHN0YXJ0aW5nIHBvaW50IGZvciB0aGUgcmVnaXN0cnksIGl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIHRoaXMgbWVtbw0KPiA+IGluIGxpZXVlIG9mIHRoZSByZWdpc3RyeS4iDQo+ IA0KPiAocy9saWV1ZS9saWV1LykNCj4gDQo+IEknbSBub3Qgc3VyZSBJIHNlZSB0aGUgcHJhY3Rp Y2FsIGRpZmZlcmVuY2UsIGJ1dCBJIG1hZGUgdGhlIGNoYW5nZS4gIERvDQo+IEkgbmVlZCB0byBj aGFuZ2UgdGhlIGxhc3Qgc2VudGVuY2Ugb2YgdGhlIHRoaXJkIHBhcmFncmFwaCBvZiB0aGUNCj4g SW50cm9kdWN0aW9uIGFzIHdlbGw/DQo+IA0KPiA+IFRoZSBsYXN0IHNlbnRlbmNlIG9mIHNlY3Rp b24gMSAoIlRoZSBwcm9jZXNzIGZvciBkZXRlcm1pbmluZyB0aGUNCj4gPiBjb250ZW50cyBvZiB0 aGlzIHJlZ2lzdHJ5IGlzIGRlZmluZWQgIGluIFNlY3Rpb24gMy43IG9mDQo+ID4gW0ktRC5pZXRm LWx0cnUtcmVnaXN0cnldLiIpIGlzbid0IG5lZWRlZCwgc2luY2UgdGhhdCBtYXRlcmlhbA0KPiA+ IGltbWVkaWF0ZWx5IGZvbGxvd3MuDQo+IA0KPiBSaWdodCwgdGhhdCB3YXMgYSBob2xkb3ZlciBm cm9tIHRoZSBkYXlzIGJlZm9yZSB0aGUgY3VycmVudCBTZWN0aW9uIDINCj4gd2FzIGNyZWF0ZWQu DQo+IA0KPiA+IChJIGJldCB0aGUgUkZDIGVkaXRvciBnZXRzIHJpZCBvZiB0aGUgaW50ZXItc2Vj dGlvbiBwYWdlIGJyZWFrcy4gIDotKQ0KPiANCj4gSSBoYWQgdG8gZGVsZXRlIDw/cmZjIGNvbXBh Y3Q9InllcyIgPz4gc28gdGhlIHRleHQgaW4gdGhlIG5lc3RlZCBsaXN0cw0KPiBpbiBTZWN0aW9u IDIgd291bGRuJ3QgY29tZSBvdXQgYWxsIGphbW1lZCB0b2dldGhlci4gIFRoaXMgaGFkIHRoZSBz aWRlDQo+IGVmZmVjdCBvZiBpbnRyb2R1Y2luZyB0aGUgcGFnZSBicmVha3MgYmV0d2VlbiBzZWN0 aW9ucy4gIElmIGFueW9uZSBjYW4NCj4gc2hvdyBtZSBhIGJldHRlciB3YXkgdG8gZG8gdGhpcywg SSdkIGFwcHJlY2lhdGUgaXQuDQo+IA0KPiA+ICJ0aGUgdGhlIiAtPiAidGhlIg0KPiANCj4gRG9u ZS4NCj4gDQo+ID4gIlJGQyAzMDY2IiBuZWVkcyBhIHJlZmVyZW5jZS4gIChpbmZvcm1hdGl2ZSkN Cj4gDQo+IERvbmUsIGV2ZXJ5d2hlcmUgUkZDIDMwNjYgaXMgbWVudGlvbmVkLiAgVGhlIG9uZSBt ZW50aW9uIG9mIFJGQyAxNzY2IHdhcw0KPiBhbHNvIHR1cm5lZCBpbnRvIGEgcmVmZXJlbmNlLiAg VGhlcmUgYXJlIG5vdyBhIExPVCBtb3JlIHJlZmVyZW5jZXMgdGhhbg0KPiBiZWZvcmUuDQo+IA0K PiBJIGFsc28gcmVtb3ZlZCB0aGUgZmlyc3QgaHlwaGVuIGluIHJlZmVyZW5jZXMgbGlrZSBbSVNP LTYzOS0xXSwgY2hhbmdpbmcNCj4gaXQgdG8gW0lTTzYzOS0xXSwgYmVjYXVzZSB0aGF0IHNlZW1z IHRvIGJlIHRoZSBjb252ZW50aW9uLiAgSSBsZWZ0DQo+IFtVTi1NLjQ5XSBhbG9uZSwgc2luY2Ug aXQgd2FzIGp1c3QgdG9vIHVnbHkgb3RoZXJ3aXNlLg0KPiANCj4gPiAiVGhpcyBzZWN0aW9uIGRl ZmluZXMgdGhlIHByb2Nlc3MgdXNlZCB0byBjcmVhdGUgdGhlIGluaXRpYWwgcmVnaXN0cnkNCj4g PiBlbnRyaWVzLiIgLT4NCj4gPiAiVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgcHJvY2VzcyB0 aGF0IHdhcyB1c2VkIHRvIGNyZWF0ZSB0aGUNCj4gPiBpbml0aWFsIHJlZ2lzdHJ5IGVudHJpZXMu Ig0KPiANCj4gRG9uZS4NCj4gDQo+ID4gIlRoZSBpbml0aWFsIHNldCBvZiByZWNvcmRzIGlzIGJh c2VkIG9uIHRoZSBmb2xsb3dpbmcgc3RhbmRhcmRzOiIgLT4NCj4gPiAiVGhlIGluaXRpYWwgc2V0 IG9mIHJlY29yZHMgd2FzIGJhc2VkIG9uIHRoZSBmb2xsb3dpbmcgc3RhbmRhcmRzOiINCj4gDQo+ IERvbmUsIGFsb25nIHdpdGggc2ltaWxhciBwcmVzZW50L3Bhc3QgdGVuc2UgY29ycmVjdGlvbnMu DQo+IA0KPiA+ICI3LiAgVGFncyBpbiB0aGUgUkZDIDMwNjYgcmVnaXN0cnkgdGhhdCBhcmUgbm90 IGRlcHJlY2F0ZWQsIGNvbnNpc3QNCj4gPiAgICAgICBlbnRpcmVseSBvZiBzdWJ0YWdzIGFscmVh ZHkgaW4gdGhpcyBkb2N1bWVudCwgYW5kIGhhdmUgdGhlDQo+ID4gICAgICAgY29ycmVjdCIgLT4N Cj4gPiAiNy4gIFRhZ3MgaW4gdGhlIFJGQyAzMDY2IHJlZ2lzdHJ5IHRoYXQgd2VyZSBub3QgZGVw cmVjYXRlZCwgY29uc2lzdGVkDQo+ID4gICAgICAgZW50aXJlbHkgb2Ygc3VidGFncyBhbHJlYWR5 IGluIHRoYXQgZG9jdW1lbnQsIGFuZCBoYXZlIHRoZQ0KPiA+ICAgICAgIGNvcnJlY3QiDQo+IA0K PiBObywgaXQncyAqdGhpcyogZG9jdW1lbnQsIHRoZSBpbml0aWFsIHJlZ2lzdHJ5LiAgVGhlIFJG QyAzMDY2IHJlZ2lzdHJ5DQo+IGRvZXNuJ3QgaGF2ZSBzdWJ0YWdzLCBvbmx5IHdob2xlIHRhZ3Mu DQo+IA0KPiA+IERvIHdlIHJlYWxseSBuZWVkIHRoaXMgcGFyYWdyYXBoICBpbiB0aGlzIGRvY3Vt ZW50Pw0KPiA+ICAgIEFueSBhZGRpdGlvbmFsIHJlZ2lzdHJhdGlvbnMgY29tcGxldGVkIGFmdGVy IHRoZSBhZG9wdGlvbiBvZg0KPiA+ICAgIFtJLUQuaWV0Zi1sdHJ1LXJlZ2lzdHJ5XSB1c2luZyB0 aGUgcnVsZXMgaW4gUkZDIDMwNjYgd2lsbCBiZQ0KPiA+ICAgIGluY29ycG9yYXRlZCBpbnRvIHRo ZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgdXNpbmcgdGhlIHJ1bGVzDQo+ID4gICAgZGVmaW5l ZCBhYm92ZSwgb3Igd2lsbCByZXN1bHQgaW4gdGhlIHN1Ym1pc3Npb24gb2YgYXBwcm9wcmlhdGUN Cj4gPiAgICByZWNvcmRzIGJ5IHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgYWNjb3JkaW5n IHRvIHRoZSBydWxlcyBpbg0KPiA+ICAgIFtJLUQuaWV0Zi1sdHJ1LXJlZ2lzdHJ5XS4NCj4gDQo+ IEFkZGlzb24gcHJvcG9zZWQgdGhhdCB0ZXh0IG9uIEp1bHkgNSB0byByZXBsYWNlICJOZXcgcmVn aXN0cmF0aW9ucw0KPiBjb21wbGV0ZWQgdW5kZXIgUkZDIDMwNjYgd2VyZSBlbnRlcmVkIGludG8g dGhlIElMU1IgdXNpbmcgdGhlIHJ1bGVzDQo+IGRlZmluZWQgYWJvdmUuIiAgUGVyc29uYWxseSBJ IGFncmVlIHRoYXQgbm8gdGV4dCByZWxhdGVkIHRvIG9uZ29pbmcNCj4gbWFpbnRlbmFuY2Ugb2Yg dGhlIHJlZ2lzdHJ5IGJlbG9uZ3MgaW4gZHJhZnQtaW5pdGlhbC4gIEkndmUgY29tbWVudGVkDQo+ IG91dCB0aGUgYWJvdmUgdGV4dCwgbm90IGRlbGV0ZWQgaXQsIGluIGNhc2UgYSBiYXR0bGUgZW5z dWVzIGFib3V0DQo+IHJldGFpbmluZyBpdC4NCj4gDQo+ID4gVGhpcyBwYXJhZ3JhcGggYWxzbyBk b2Vzbid0IGJlbG9uZyBpbiB0aGlzIGRvY3VtZW50Lg0KPiA+ICAgIEFsbCBleGlzdGluZyBSRkMg MzA2NiBsYW5ndWFnZSB0YWcgcmVnaXN0cmF0aW9ucyB3aWxsIGJlIG1haW50YWluZWQNCj4gPiAg ICBpbiBwZXJwZXR1aXR5Lg0KPiA+IEl0J3MgYWJvdXQgcmVnaXN0cnkgbWFpbnRlbmFuY2UsIHJh dGhlciB0aGFuIGluaXRpYWxpemF0aW9uLg0KPiANCj4gSSBhZ3JlZSwgYW5kIGhhdmUgY29tbWVu dGVkIHRoaXMgb3V0IGFzIHdlbGwuICBBY3R1YWxseSwgSSB0aGluayBhbGwgb2YNCj4gaXRlbSAx MSBmcm9tICJJbnRlcmVzdGVkIHBhcnRpZXMiIHRvIHRoZSBlbmQgc2hvdWxkIGJlIGRlbGV0ZWQs IGFzIGl0DQo+IGFsc28gcGVydGFpbnMgdG8gcmVnaXN0cnkgbWFpbnRlbmFuY2UsIGJ1dCBJJ2xs IHdhaXQgdG8gaGVhciBhIGh1bW1pbmcNCj4gc291bmQgYmVmb3JlIEkgZG8gYW55dGhpbmcgYWJv dXQgaXQuDQo+IA0KPiBJIGhhdmUgbm90IGFkZGVkIGFueSByZWZlcmVuY2VzIG9yIGV4cGxhbmF0 aW9ucyByZWdhcmRpbmcgdGhlIHVzZSBvZg0KPiBVbmljb2RlIGVzY2FwZSBzZXF1ZW5jZXMuICBT ZWN0aW9uIDEgYnJpZWZseSBtZW50aW9ucyByZWNvcmQtamFyLCBidXQNCj4gdGhlbiBkZWZlcnMg YWxsIG90aGVyIGZvcm1hdC1yZWxhdGVkIGRldGFpbHMgdG8gW2RyYWZ0LXJlZ2lzdHJ5XS4NCj4g DQo+IDIwMCBoYXMgYmVlbiBleHB1cmdhdGVkIGZyb20gU2VjdGlvbiA0Lg0KPiANCj4gRHJhZnQt aW5pdGlhbC0wMiBpcyBub3cgYXZhaWxhYmxlOg0KPiBodHRwOi8vdXNlcnMuYWRlbHBoaWEubmV0 L35kZXdlbGwvZHJhZnQtaWV0Zi1sdHJ1LWluaXRpYWwtMDIudHh0DQo+IGh0dHA6Ly91c2Vycy5h ZGVscGhpYS5uZXQvfmRld2VsbC9kcmFmdC1pZXRmLWx0cnUtaW5pdGlhbC0wMi5odG1sDQo+IGh0 dHA6Ly91c2Vycy5hZGVscGhpYS5uZXQvfmRld2VsbC9kcmFmdC1pZXRmLWx0cnUtaW5pdGlhbC0w Mi54bWwNCj4gDQo+IC0tDQo+IERvdWcgRXdlbGwNCj4gRnVsbGVydG9uLCBDYWxpZm9ybmlhDQo+ IGh0dHA6Ly91c2Vycy5hZGVscGhpYS5uZXQvfmRld2VsbC8NCj4gDQo+IA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHRydSBtYWlsaW5n IGxpc3QNCj4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --===============0169872187== 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 --===============0169872187==-- From ltru-bounces@lists.ietf.org Sun Jul 10 15:22:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrhNn-0003Lh-IK; Sun, 10 Jul 2005 15:22:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrhNl-0003La-MT for ltru@megatron.ietf.org; Sun, 10 Jul 2005 15:22:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19842 for ; Sun, 10 Jul 2005 15:22:27 -0400 (EDT) Received: from mta9.adelphia.net ([68.168.78.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drhpb-0002o4-Ne for ltru@ietf.org; Sun, 10 Jul 2005 15:51:16 -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 <20050710192214.DGJA29002.mta9.adelphia.net@DEWELL>; Sun, 10 Jul 2005 15:22:14 -0400 Message-ID: <000601c58584$90ca9520$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C108BE8@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: editorial nits in initial registry draft -01 Date: Sun, 10 Jul 2005 12:21: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 X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Addison Phillips wrote: > Why not say: > > "This memo defines the initial contents of the Language Subtag > Registry for use in forming tags for the identification of languages." > > The introduction can say where draft-registry is at and all that. Why not, indeed? Makes sense to me. I made that change, and in case of dispute. -- 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 Jul 10 18:07:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drjx5-00034p-5p; Sun, 10 Jul 2005 18:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drjx3-00034k-D7 for ltru@megatron.ietf.org; Sun, 10 Jul 2005 18:07:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27740 for ; Sun, 10 Jul 2005 18:07:02 -0400 (EDT) Received: from lakermmtao11.cox.net ([68.230.240.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrkOs-0008Iq-VB for ltru@ietf.org; Sun, 10 Jul 2005 18:35:54 -0400 Received: from A31P ([68.100.55.187]) by lakermmtao11.cox.net (InterMail vM.6.01.05.00 201-2131-123-20050610) with ESMTP id <20050710220631.MOCR221.lakermmtao11.cox.net@A31P>; Sun, 10 Jul 2005 18:06:31 -0400 From: "Scott Hollenbeck" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: editorial nits in initial registry draft -01 Date: Sun, 10 Jul 2005 18:06:30 -0400 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.2527 In-Reply-To: <002401c58577$c4854d40$030aa8c0@DEWELL> Thread-Index: AcWFeBqs5RQMdcZ8Q+CdfrNEqRiGcQAIvpRQ Message-Id: <20050710220631.MOCR221.lakermmtao11.cox.net@A31P> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 > -----Original Message----- > From: Doug Ewell [mailto:dewell@adelphia.net] > Sent: Sunday, July 10, 2005 1:50 PM > To: LTRU Working Group > Subject: [Ltru] Re: editorial nits in initial registry draft -01 > > Randy Presuhn wrote: > > > Need to ensure that the "RFC 3066bis" in the Abstract gets replaced > > with the actual RFC number during the RFC editing process. > > Just let me know how to do that. I tried making this a > reference to [I-D.ietf-ltru-registry], but one tool or > another didn't like that in the Abstract. Don't put references in the abstract. It has to be complete when separated from the rest of the document. If you want to describe another document that will become an RFC, just use the current I-D name for now and add a note to the RFC Editor below the abstract to let them know that the name of the I-D should be replaced with "RFC " when the registry document is published as an RFC. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 10 18:08:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrjyI-0003MM-HL; Sun, 10 Jul 2005 18: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 1DrjyE-0003M1-I0 for ltru@megatron.ietf.org; Sun, 10 Jul 2005 18:08:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27903 for ; Sun, 10 Jul 2005 18:08:15 -0400 (EDT) Received: from lakermmtao05.cox.net ([68.230.240.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrkQ6-0008KY-0S for ltru@ietf.org; Sun, 10 Jul 2005 18:37:07 -0400 Received: from A31P ([68.100.55.187]) by lakermmtao05.cox.net (InterMail vM.6.01.05.00 201-2131-123-20050610) with ESMTP id <20050710220801.MWDV27261.lakermmtao05.cox.net@A31P>; Sun, 10 Jul 2005 18:08:01 -0400 From: "Scott Hollenbeck" To: "'Addison Phillips'" , "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: editorial nits in initial registry draft -01 Date: Sun, 10 Jul 2005 18:07:59 -0400 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.2527 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C108BE8@irvmbxw01.quest.com> Thread-Index: AcWFeD1vC5BFu0+HRmy5D57/sqaI8AAAgQ1wAAhbBhA= Message-Id: <20050710220801.MWDV27261.lakermmtao05.cox.net@A31P> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Sunday, July 10, 2005 2:11 PM > To: Doug Ewell; LTRU Working Group > Subject: RE: [Ltru] Re: editorial nits in initial registry draft -01 > > You're not supposed to have a reference in the abstract, no? > I got beat up on that for weeks. > > Why not say: > > "This memo defines the initial contents of the Language > Subtag Registry for use in forming tags for the > identification of languages." > > The introduction can say where draft-registry is at and all that. This is better than my suggestion to mention the I-D name and adding an RFC Editor note. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 10 23:36:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drp6H-0001Hq-Qx; Sun, 10 Jul 2005 23: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 1Drp6F-0001HV-CU for ltru@megatron.ietf.org; Sun, 10 Jul 2005 23:36: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 XAA15272 for ; Sun, 10 Jul 2005 23:36:52 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Drp61-00071O-ED for ltru@lists.ietf.org; Mon, 11 Jul 2005 05:36:46 +0200 Received: from 62.80.58.60 ([62.80.58.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Jul 2005 05:36:41 +0200 Received: from nobody by 62.80.58.60 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Jul 2005 05:36:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 11 Jul 2005 05:35:57 +0200 Organization: Lines: 9 Message-ID: <42D1E91D.56DB@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C108BE4@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: 62.80.58.60 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Finishing off #1026 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: >| registration authority for ISO 3166 SHOULD be petitioned to >| assign a code: Please insert between "code:" and "such", s/such/Such/ Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 11 00:13:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drpfo-0000Yt-FR; Mon, 11 Jul 2005 00: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 1Drpfm-0000Yo-2j for ltru@megatron.ietf.org; Mon, 11 Jul 2005 00:13:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17146 for ; Mon, 11 Jul 2005 00:13:34 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drq7h-0002k9-KJ for ltru@ietf.org; Mon, 11 Jul 2005 00:42:29 -0400 Received: from h-68-166-38-110.snvacaid.dynamic.covad.net ([68.166.38.110] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Drpfk-0004ec-00 for ltru@ietf.org; Mon, 11 Jul 2005 00:13:36 -0400 Message-ID: <008701c585cf$80980ca0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "'LTRU Working Group'" References: <20050710220801.MWDV27261.lakermmtao05.cox.net@A31P> Subject: Re: [Ltru] Re: editorial nits in initial registry draft -01 Date: Sun, 10 Jul 2005 21:17: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.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: "Scott Hollenbeck" > To: "'Addison Phillips'" ; "'Doug Ewell'" ; "'LTRU Working Group'" > Sent: Sunday, July 10, 2005 3:07 PM > Subject: RE: [Ltru] Re: editorial nits in initial registry draft -01 ... > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > Sent: Sunday, July 10, 2005 2:11 PM > > To: Doug Ewell; LTRU Working Group > > Subject: RE: [Ltru] Re: editorial nits in initial registry draft -01 ... > > Why not say: > > > > "This memo defines the initial contents of the Language > > Subtag Registry for use in forming tags for the > > identification of languages." > > > > The introduction can say where draft-registry is at and all that. > > This is better than my suggestion to mention the I-D name and adding an RFC > Editor note. ... +1 Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 11 03:45:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrsyN-0006Iw-Bf; Mon, 11 Jul 2005 03: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 1DrsyJ-0006Dc-Us for ltru@megatron.ietf.org; Mon, 11 Jul 2005 03:45: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 DAA19454 for ; Mon, 11 Jul 2005 03:44:56 -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 <20050711074422.ZTQY19267.mta10.adelphia.net@DEWELL>; Mon, 11 Jul 2005 03:44:22 -0400 Message-ID: <003c01c585ec$1c1d8580$030aa8c0@DEWELL> From: "Doug Ewell" To: Date: Mon, 11 Jul 2005 00:42:36 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0039_01C585B1.6EF54300" 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 Cc: LTRU Working Group Subject: [Ltru] Submission: LTRU initial-registry draft-02 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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_000_0039_01C585B1.6EF54300 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear Editor, Attached please find the third draft of the LTRU initial-registry document, "draft-ietf-ltru-initial-02", in text format. Best regards, -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ ------=_NextPart_000_0039_01C585B1.6EF54300 Content-Type: text/plain; name="draft-ietf-ltru-initial-02.txt" Content-Disposition: attachment; filename="draft-ietf-ltru-initial-02.txt" Content-Transfer-Encoding: quoted-printable LTRU D. Ewell, Ed. Internet-Draft July 10, 2005 Expires: January 11, 2006 Initial Language Subtag Registry draft-ietf-ltru-initial-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 11, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines the initial contents of the Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieu of the registry. Ewell Expires January 11, 2006 [Page 1] =0C Internet-Draft Initial Language Subtag Registry July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Initialization of the Registry . . . . . . . . . . . . . . . 4 3. Initial Registry Contents . . . . . . . . . . . . . . . . . 7 4. Omitted Code Elements . . . . . . . . . . . . . . . . . . . 112 5. Security Considerations . . . . . . . . . . . . . . . . . . 113 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 114 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 115 7.1 Normative References . . . . . . . . . . . . . . . . . . 115 7.2 Informative References . . . . . . . . . . . . . . . . . 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . 116 Intellectual Property and Copyright Statements . . . . . . . 117 Ewell Expires January 11, 2006 [Page 2] =0C Internet-Draft Initial Language Subtag Registry July 2005 1. Introduction [I-D.ietf-ltru-registry] provides for a Language Subtag Registry and describes its format. This memo defines the initial contents of the Language Subtag Registry, using the criteria described in Section 2. The Language Subtag Registry is formatted in a modified record-jar text format, as described in [record-jar]. The specific format of the registry, and the definition and intended purpose of each of the fields, are described in [I-D.ietf-ltru-registry]. The registry is expected to change over time, as new subtags are registered and existing subtags are modified or deprecated. The process of updating the registry is described in Section 3 of [I-D.ietf-ltru-registry]. This memo does not define the permanent contents of the registry and should not be represented as doing so. Many of the subtags defined in this registry are based on code elements defined in [ISO639-1], [ISO639-2], [ISO15924], [ISO3166-1], and [UN-M.49]. This registry is not a mirror of the code lists defined by these standards, and should not be used as one. Ewell Expires January 11, 2006 [Page 3] =0C Internet-Draft Initial Language Subtag Registry July 2005 2. Initialization of the Registry Section 3.7 of [I-D.ietf-ltru-registry] requires that the LTRU working group create an initial version of the Language Subtag Registry and populate it with the initial set of subtags. This involves converting the entries from the existing IANA language tag registry defined by [RFC3066] to the new format, as well as defining valid subtags from various source standards. This section describes the process that was used to create the initial registry entries. The initial set of records was based on the following standards: [ISO639-1], [ISO639-2], [ISO15924], and [ISO3166-1]. The following criteria were used to select and format the records of the subtags included in the initial Language Subtag Registry (hereafter "ILSR"): 1. For each source standard, the date of the standard referenced in [RFC1766] was selected as the starting date. Code elements that were valid on that date in the selected standard were added to the ILSR. Code elements that were previously assigned, but which were vacated or withdrawn before that date, were not added to the ILSR. 2. For each successive change to the standard, any additional assignments up to the date of the adoption of [I-D.ietf-ltru- registry] were added to the ILSR. Values that have been withdrawn are marked as deprecated, but not removed. Changes in meaning or assignment of a subtag were permitted during this process (for example, the [ISO3166-1] code element 'CS' was originally assigned to Czechoslovakia and is now assigned to Serbia and Montenegro). Code elements from [UN-M.49] were also included in the ILSR using the criteria above, with the following additional rules: 3. UN numeric code elements assigned to "macro-geographical (continental)" as of the date of adoption of [I-D.ietf-ltru- registry] were added to the ILSR and thereby made valid for use in language tags. 4. The UN numeric code elements for "economic groupings" or "other groupings," and the alphanumeric code elements in Appendix X of the UN document, were not added to the ILSR. 5. The UN numeric code elements for countries or areas not associated with an assigned [ISO3166-1] alpha-2 code element were not added to the ILSR. These values may be requested for registration by individuals using the process defined in [I-D.ietf-ltru-registry] and according to the rules described therein. Ewell Expires January 11, 2006 [Page 4] =0C Internet-Draft Initial Language Subtag Registry July 2005 6. Items withdrawn, vacated, deprecated, modified, or otherwise judged by the LTRU working group to be questionable were not added to the ILSR. These code elements are listed in Section 4, indicating that they are valid for registration using the process in [I-D.ietf-ltru-registry] but were not included initially. Listing of these code elements in this section is not a guarantee of future registration. Using the initial set of subtags described above, the tags in the [RFC3066] registry were evaluated as follows: 7. Tags in the [RFC3066] registry that were not deprecated, consisted entirely of subtags already in this document, and have the correct form and format for tags defined by [I-D.ietf-ltru- registry] were converted to records of type "redundant" in the ILSR. For example, "zh-Hant" is now defined by [I-D.ietf-ltru- registry] because 'zh' is an [ISO639-1] code element and 'Hant' is an [ISO15924] code element, and both are defined as subtags in the ILSR. 8. Tags in the [RFC3066] registry that contained one or more subtags that either did not match the valid registration pattern or were not otherwise defined by [I-D.ietf-ltru-registry] were converted to corresponding records of type "grandfathered" in the ILSR. These records cannot become type "redundant" except by revision of [I-D.ietf-ltru-registry], but may have a "Deprecated" and "Preferred-Value" field added to them if a subsequent subtag assignment or combination of assignments renders the tag obsolete. 9. Tags in the [RFC3066] registry that had a notation that they were deprecated were converted to records of type "grandfathered" in the ILSR. The record for the grandfathered entry contains a "Deprecated" field with the most appropriate date that can be determined for when the [RFC3066] record was deprecated. The "Comments" field may optionally contain a reason for the deprecation. The "Preferred-Value" field contains a tag that replaces the value. For example, the [RFC3066] tag "art-lojban" is deprecated and thus appears as a grandfathered tag in the ILSR. Its "Deprecated" field contains the deprecation date (in this case "2003-09-02") and the "Preferred-Value" field the value "jbo". 10. The remaining tags in the [RFC3066] registry are not deprecated and have a format consistent with language tags as defined by [I-D.ietf-ltru-registry] but contain subtags which are not defined in the ILSR. These subtags are eligible for registration as variants. The ILSR contains appropriate variant records for the following list of subtags, and the registered [RFC3066] tags containing these subtags were entered into the ILSR Ewell Expires January 11, 2006 [Page 5] =0C Internet-Draft Initial Language Subtag Registry July 2005 as type "redundant": 1901 (use with Prefix: de) 1996 (use with Prefix: de) nedis (use with Prefix: sl) rozaj (use with Prefix: sl) 11. All remaining [RFC3066] registered tags were converted to records of type "grandfathered" in the ILSR. Interested parties may use the registration process in [I-D.ietf-ltru-registry] to attempt to register the variant subtags not already present in the Language Subtag Registry. If all of the subtags in the original tag become fully defined by the resulting registrations, then the original tag is superseded. Such tags will have their record changed from type "grandfathered" to type "redundant" in the registry. Note that previous approval of a tag under [RFC3066] is not a guarantee of approval of a variant subtag under [I-D.ietf- ltru-registry]. The existing [RFC3066] tag maintains its validity, but the original reason for its registration might have become obsolete. Ewell Expires January 11, 2006 [Page 6] =0C Internet-Draft Initial Language Subtag Registry July 2005 3. Initial Registry Contents The initial Language Subtag Registry follows. The registry begins with the line that starts with the string "File-Date" and continues to the end of this section. Headers, footers, line breaks, and other vertical whitespace introduced by the RFC process are not significant. Leading horizontal whitespace relative to the "File- Date" line indicates a continued line in the record-jar format, and must not be deleted. File-Date: 2005-07-10 %% Type: language Subtag: aa Description: Afar Added: 2005-07-10 %% Type: language Subtag: ab Description: Abkhazian Added: 2005-07-10 Suppress-Script: Cyrl %% Type: language Subtag: ae Description: Avestan Added: 2005-07-10 %% Type: language Subtag: af Description: Afrikaans Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ak Description: Akan Added: 2005-07-10 %% Type: language Subtag: am Description: Amharic Added: 2005-07-10 Suppress-Script: Ethi %% Type: language Subtag: an Description: Aragonese Ewell Expires January 11, 2006 [Page 7] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: language Subtag: ar Description: Arabic Added: 2005-07-10 Suppress-Script: Arab %% Type: language Subtag: as Description: Assamese Added: 2005-07-10 Suppress-Script: Beng %% Type: language Subtag: av Description: Avaric Added: 2005-07-10 %% Type: language Subtag: ay Description: Aymara Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: az Description: Azerbaijani Added: 2005-07-10 %% Type: language Subtag: ba Description: Bashkir Added: 2005-07-10 %% Type: language Subtag: be Description: Belarusian Added: 2005-07-10 Suppress-Script: Cyrl %% Type: language Subtag: bg Description: Bulgarian Added: 2005-07-10 Suppress-Script: Cyrl %% Type: language Ewell Expires January 11, 2006 [Page 8] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: bh Description: Bihari Added: 2005-07-10 %% Type: language Subtag: bi Description: Bislama Added: 2005-07-10 %% Type: language Subtag: bm Description: Bambara Added: 2005-07-10 %% Type: language Subtag: bn Description: Bengali Added: 2005-07-10 Suppress-Script: Beng %% Type: language Subtag: bo Description: Tibetan Added: 2005-07-10 %% Type: language Subtag: br Description: Breton Added: 2005-07-10 %% Type: language Subtag: bs Description: Bosnian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ca Description: Catalan Description: Valencian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ce Description: Chechen Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 9] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: ch Description: Chamorro Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: co Description: Corsican Added: 2005-07-10 %% Type: language Subtag: cr Description: Cree Added: 2005-07-10 %% Type: language Subtag: cs Description: Czech Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: cu Description: Church Slavic Description: Old Slavonic Description: Church Slavonic Description: Old Bulgarian Description: Old Church Slavonic Added: 2005-07-10 %% Type: language Subtag: cv Description: Chuvash Added: 2005-07-10 %% Type: language Subtag: cy Description: Welsh Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: da Description: Danish Added: 2005-07-10 Suppress-Script: Latn %% Ewell Expires January 11, 2006 [Page 10] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: de Description: German Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: dv Description: Divehi Added: 2005-07-10 Suppress-Script: Thaa %% Type: language Subtag: dz Description: Dzongkha Added: 2005-07-10 Suppress-Script: Tibt %% Type: language Subtag: ee Description: Ewe Added: 2005-07-10 %% Type: language Subtag: el Description: Greek, Modern (1453-) Added: 2005-07-10 Suppress-Script: Grek %% Type: language Subtag: en Description: English Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: eo Description: Esperanto Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: es Description: Spanish Description: Castilian Added: 2005-07-10 Suppress-Script: Latn %% Ewell Expires January 11, 2006 [Page 11] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: et Description: Estonian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: eu Description: Basque Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: fa Description: Persian Added: 2005-07-10 Suppress-Script: Arab %% Type: language Subtag: ff Description: Fulah Added: 2005-07-10 %% Type: language Subtag: fi Description: Finnish Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: fj Description: Fijian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: fo Description: Faroese Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: fr Description: French Added: 2005-07-10 Suppress-Script: Latn %% Type: language Ewell Expires January 11, 2006 [Page 12] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: fy Description: Frisian Added: 2005-07-10 %% Type: language Subtag: ga Description: Irish Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: gd Description: Gaelic Description: Scottish Gaelic Added: 2005-07-10 %% Type: language Subtag: gl Description: Gallegan Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: gn Description: Guarani Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: gu Description: Gujarati Added: 2005-07-10 Suppress-Script: Gujr %% Type: language Subtag: gv Description: Manx Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ha Description: Hausa Added: 2005-07-10 %% Type: language Subtag: he Description: Hebrew Ewell Expires January 11, 2006 [Page 13] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 Suppress-Script: Hebr %% Type: language Subtag: hi Description: Hindi Added: 2005-07-10 Suppress-Script: Deva %% Type: language Subtag: ho Description: Hiri Motu Added: 2005-07-10 %% Type: language Subtag: hr Description: Croatian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ht Description: Haitian Description: Haitian Creole Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: hu Description: Hungarian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: hy Description: Armenian Added: 2005-07-10 Suppress-Script: Armn %% Type: language Subtag: hz Description: Herero Added: 2005-07-10 %% Type: language Subtag: ia Description: Interlingua (International Auxiliary Language Association) Ewell Expires January 11, 2006 [Page 14] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: language Subtag: id Description: Indonesian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ie Description: Interlingue Added: 2005-07-10 %% Type: language Subtag: ig Description: Igbo Added: 2005-07-10 %% Type: language Subtag: ii Description: Sichuan Yi Added: 2005-07-10 %% Type: language Subtag: ik Description: Inupiaq Added: 2005-07-10 %% Type: language Subtag: in Description: Indonesian Added: 2005-07-10 Preferred-Value: id Deprecated: 1989-01-01 Suppress-Script: Latn %% Type: language Subtag: io Description: Ido Added: 2005-07-10 %% Type: language Subtag: is Description: Icelandic Added: 2005-07-10 Suppress-Script: Latn %% Type: language Ewell Expires January 11, 2006 [Page 15] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: it Description: Italian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: iu Description: Inuktitut Added: 2005-07-10 %% Type: language Subtag: iw Description: Hebrew Added: 2005-07-10 Preferred-Value: he Deprecated: 1989-01-01 Suppress-Script: Hebr %% Type: language Subtag: ja Description: Japanese Added: 2005-07-10 %% Type: language Subtag: ji Description: Yiddish Added: 2005-07-10 Preferred-Value: yi Deprecated: 1989-01-01 %% Type: language Subtag: jv Description: Javanese Added: 2005-07-10 %% Type: language Subtag: jw Description: Javanese Added: 2005-07-10 Preferred-Value: jv Deprecated: 2001-08-13 Comments: published by error in Table 1 of ISO 639:1988 %% Type: language Subtag: ka Description: Georgian Added: 2005-07-10 Suppress-Script: Geor Ewell Expires January 11, 2006 [Page 16] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: kg Description: Kongo Added: 2005-07-10 %% Type: language Subtag: ki Description: Kikuyu Description: Gikuyu Added: 2005-07-10 %% Type: language Subtag: kj Description: Kuanyama Description: Kwanyama Added: 2005-07-10 %% Type: language Subtag: kk Description: Kazakh Added: 2005-07-10 Suppress-Script: Cyrl %% Type: language Subtag: kl Description: Kalaallisut Description: Greenlandic Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: km Description: Khmer Added: 2005-07-10 Suppress-Script: Khmr %% Type: language Subtag: kn Description: Kannada Added: 2005-07-10 Suppress-Script: Knda %% Type: language Subtag: ko Description: Korean Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 17] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: kr Description: Kanuri Added: 2005-07-10 %% Type: language Subtag: ks Description: Kashmiri Added: 2005-07-10 %% Type: language Subtag: ku Description: Kurdish Added: 2005-07-10 %% Type: language Subtag: kv Description: Komi Added: 2005-07-10 %% Type: language Subtag: kw Description: Cornish Added: 2005-07-10 %% Type: language Subtag: ky Description: Kirghiz Added: 2005-07-10 %% Type: language Subtag: la Description: Latin Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: lb Description: Luxembourgish Description: Letzeburgesch Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: lg Description: Ganda Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 18] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: li Description: Limburgan Description: Limburger Description: Limburgish Added: 2005-07-10 %% Type: language Subtag: ln Description: Lingala Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: lo Description: Lao Added: 2005-07-10 Suppress-Script: Laoo %% Type: language Subtag: lt Description: Lithuanian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: lu Description: Luba-Katanga Added: 2005-07-10 %% Type: language Subtag: lv Description: Latvian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: mg Description: Malagasy Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: mh Description: Marshallese Added: 2005-07-10 Suppress-Script: Latn %% Ewell Expires January 11, 2006 [Page 19] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: mi Description: Maori Added: 2005-07-10 %% Type: language Subtag: mk Description: Macedonian Added: 2005-07-10 Suppress-Script: Cyrl %% Type: language Subtag: ml Description: Malayalam Added: 2005-07-10 Suppress-Script: Mlym %% Type: language Subtag: mn Description: Mongolian Added: 2005-07-10 %% Type: language Subtag: mo Description: Moldavian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: mr Description: Marathi Added: 2005-07-10 Suppress-Script: Deva %% Type: language Subtag: ms Description: Malay Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: mt Description: Maltese Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: my Ewell Expires January 11, 2006 [Page 20] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Burmese Added: 2005-07-10 Suppress-Script: Mymr %% Type: language Subtag: na Description: Nauru Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: nb Description: Norwegian Bokmål Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: nd Description: Ndebele, North Description: North Ndebele Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ne Description: Nepali Added: 2005-07-10 Suppress-Script: Deva %% Type: language Subtag: ng Description: Ndonga Added: 2005-07-10 %% Type: language Subtag: nl Description: Dutch Description: Flemish Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: nn Description: Norwegian Nynorsk Added: 2005-07-10 Suppress-Script: Latn %% Type: language Ewell Expires January 11, 2006 [Page 21] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: no Description: Norwegian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: nr Description: Ndebele, South Description: South Ndebele Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: nv Description: Navajo Description: Navaho Added: 2005-07-10 %% Type: language Subtag: ny Description: Chichewa Description: Chewa Description: Nyanja Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: oc Description: Occitan (post 1500) Description: Provençal Added: 2005-07-10 %% Type: language Subtag: oj Description: Ojibwa Added: 2005-07-10 %% Type: language Subtag: om Description: Oromo Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: or Description: Oriya Added: 2005-07-10 Suppress-Script: Orya Ewell Expires January 11, 2006 [Page 22] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: os Description: Ossetian Description: Ossetic Added: 2005-07-10 %% Type: language Subtag: pa Description: Panjabi Description: Punjabi Added: 2005-07-10 Suppress-Script: Guru %% Type: language Subtag: pi Description: Pali Added: 2005-07-10 %% Type: language Subtag: pl Description: Polish Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ps Description: Pushto Added: 2005-07-10 Suppress-Script: Arab %% Type: language Subtag: pt Description: Portuguese Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: qu Description: Quechua Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: rm Description: Raeto-Romance Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 23] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: rn Description: Rundi Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ro Description: Romanian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ru Description: Russian Added: 2005-07-10 Suppress-Script: Cyrl %% Type: language Subtag: rw Description: Kinyarwanda Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: sa Description: Sanskrit Added: 2005-07-10 %% Type: language Subtag: sc Description: Sardinian Added: 2005-07-10 %% Type: language Subtag: sd Description: Sindhi Added: 2005-07-10 %% Type: language Subtag: se Description: Northern Sami Added: 2005-07-10 %% Type: language Subtag: sg Description: Sango Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 24] =0C Internet-Draft Initial Language Subtag Registry July 2005 Suppress-Script: Latn %% Type: language Subtag: sh Description: Serbo-Croatian Added: 2005-07-10 Deprecated: 2000-02-18 %% Type: language Subtag: si Description: Sinhala Description: Sinhalese Added: 2005-07-10 Suppress-Script: Sinh %% Type: language Subtag: sk Description: Slovak Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: sl Description: Slovenian Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: sm Description: Samoan Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: sn Description: Shona Added: 2005-07-10 %% Type: language Subtag: so Description: Somali Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: sq Description: Albanian Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 25] =0C Internet-Draft Initial Language Subtag Registry July 2005 Suppress-Script: Latn %% Type: language Subtag: sr Description: Serbian Added: 2005-07-10 %% Type: language Subtag: ss Description: Swati Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: st Description: Sotho, Southern Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: su Description: Sundanese Added: 2005-07-10 %% Type: language Subtag: sv Description: Swedish Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: sw Description: Swahili Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ta Description: Tamil Added: 2005-07-10 Suppress-Script: Taml %% Type: language Subtag: te Description: Telugu Added: 2005-07-10 Suppress-Script: Telu %% Ewell Expires January 11, 2006 [Page 26] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: tg Description: Tajik Added: 2005-07-10 %% Type: language Subtag: th Description: Thai Added: 2005-07-10 Suppress-Script: Thai %% Type: language Subtag: ti Description: Tigrinya Added: 2005-07-10 Suppress-Script: Ethi %% Type: language Subtag: tk Description: Turkmen Added: 2005-07-10 %% Type: language Subtag: tl Description: Tagalog Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: tn Description: Tswana Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: to Description: Tonga (Tonga Islands) Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: tr Description: Turkish Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ts Ewell Expires January 11, 2006 [Page 27] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Tsonga Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: tt Description: Tatar Added: 2005-07-10 %% Type: language Subtag: tw Description: Twi Added: 2005-07-10 %% Type: language Subtag: ty Description: Tahitian Added: 2005-07-10 %% Type: language Subtag: ug Description: Uighur Description: Uyghur Added: 2005-07-10 %% Type: language Subtag: uk Description: Ukrainian Added: 2005-07-10 Suppress-Script: Cyrl %% Type: language Subtag: ur Description: Urdu Added: 2005-07-10 Suppress-Script: Arab %% Type: language Subtag: uz Description: Uzbek Added: 2005-07-10 %% Type: language Subtag: ve Description: Venda Added: 2005-07-10 Suppress-Script: Latn %% Ewell Expires January 11, 2006 [Page 28] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: vi Description: Vietnamese Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: vo Description: Volapük Added: 2005-07-10 %% Type: language Subtag: wa Description: Walloon Added: 2005-07-10 %% Type: language Subtag: wo Description: Wolof Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: xh Description: Xhosa Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: yi Description: Yiddish Added: 2005-07-10 Suppress-Script: Hebr %% Type: language Subtag: yo Description: Yoruba Added: 2005-07-10 %% Type: language Subtag: za Description: Zhuang Description: Chuang Added: 2005-07-10 %% Type: language Subtag: zh Description: Chinese Ewell Expires January 11, 2006 [Page 29] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: language Subtag: zu Description: Zulu Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ace Description: Achinese Added: 2005-07-10 %% Type: language Subtag: ach Description: Acoli Added: 2005-07-10 %% Type: language Subtag: ada Description: Adangme Added: 2005-07-10 %% Type: language Subtag: ady Description: Adyghe Description: Adygei Added: 2005-07-10 %% Type: language Subtag: afa Description: Afro-Asiatic (Other) Added: 2005-07-10 %% Type: language Subtag: afh Description: Afrihili Added: 2005-07-10 %% Type: language Subtag: akk Description: Akkadian Added: 2005-07-10 %% Type: language Subtag: ale Description: Aleut Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 30] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: alg Description: Algonquian languages Added: 2005-07-10 %% Type: language Subtag: alt Description: Southern Altai Added: 2005-07-10 %% Type: language Subtag: ang Description: English, Old (ca. 450-1100) Added: 2005-07-10 %% Type: language Subtag: apa Description: Apache languages Added: 2005-07-10 %% Type: language Subtag: arc Description: Aramaic Added: 2005-07-10 %% Type: language Subtag: arn Description: Araucanian Added: 2005-07-10 %% Type: language Subtag: arp Description: Arapaho Added: 2005-07-10 %% Type: language Subtag: art Description: Artificial (Other) Added: 2005-07-10 %% Type: language Subtag: arw Description: Arawak Added: 2005-07-10 %% Type: language Subtag: ast Ewell Expires January 11, 2006 [Page 31] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Asturian Description: Bable Added: 2005-07-10 %% Type: language Subtag: ath Description: Athapascan languages Added: 2005-07-10 %% Type: language Subtag: aus Description: Australian languages Added: 2005-07-10 %% Type: language Subtag: awa Description: Awadhi Added: 2005-07-10 %% Type: language Subtag: bad Description: Banda Added: 2005-07-10 %% Type: language Subtag: bai Description: Bamileke languages Added: 2005-07-10 %% Type: language Subtag: bal Description: Baluchi Added: 2005-07-10 %% Type: language Subtag: ban Description: Balinese Added: 2005-07-10 %% Type: language Subtag: bas Description: Basa Added: 2005-07-10 %% Type: language Subtag: bat Description: Baltic (Other) Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 32] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: bej Description: Beja Added: 2005-07-10 %% Type: language Subtag: bem Description: Bemba Added: 2005-07-10 %% Type: language Subtag: ber Description: Berber (Other) Added: 2005-07-10 %% Type: language Subtag: bho Description: Bhojpuri Added: 2005-07-10 %% Type: language Subtag: bik Description: Bikol Added: 2005-07-10 %% Type: language Subtag: bin Description: Bini Added: 2005-07-10 %% Type: language Subtag: bla Description: Siksika Added: 2005-07-10 %% Type: language Subtag: bnt Description: Bantu (Other) Added: 2005-07-10 %% Type: language Subtag: bra Description: Braj Added: 2005-07-10 %% Type: language Subtag: btk Ewell Expires January 11, 2006 [Page 33] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Batak (Indonesia) Added: 2005-07-10 %% Type: language Subtag: bua Description: Buriat Added: 2005-07-10 %% Type: language Subtag: bug Description: Buginese Added: 2005-07-10 %% Type: language Subtag: byn Description: Blin Description: Bilin Added: 2005-07-10 %% Type: language Subtag: cad Description: Caddo Added: 2005-07-10 %% Type: language Subtag: cai Description: Central American Indian (Other) Added: 2005-07-10 %% Type: language Subtag: car Description: Carib Added: 2005-07-10 %% Type: language Subtag: cau Description: Caucasian (Other) Added: 2005-07-10 %% Type: language Subtag: ceb Description: Cebuano Added: 2005-07-10 %% Type: language Subtag: cel Description: Celtic (Other) Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 34] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: chb Description: Chibcha Added: 2005-07-10 %% Type: language Subtag: chg Description: Chagatai Added: 2005-07-10 %% Type: language Subtag: chk Description: Chuukese Added: 2005-07-10 %% Type: language Subtag: chm Description: Mari Added: 2005-07-10 %% Type: language Subtag: chn Description: Chinook jargon Added: 2005-07-10 %% Type: language Subtag: cho Description: Choctaw Added: 2005-07-10 %% Type: language Subtag: chp Description: Chipewyan Added: 2005-07-10 %% Type: language Subtag: chr Description: Cherokee Added: 2005-07-10 %% Type: language Subtag: chy Description: Cheyenne Added: 2005-07-10 %% Type: language Subtag: cmc Ewell Expires January 11, 2006 [Page 35] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Chamic languages Added: 2005-07-10 %% Type: language Subtag: cop Description: Coptic Added: 2005-07-10 %% Type: language Subtag: cpe Description: Creoles and pidgins, English-based (Other) Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: cpf Description: Creoles and pidgins, French-based (Other) Added: 2005-07-10 %% Type: language Subtag: cpp Description: Creoles and pidgins, Portuguese-based (Other) Added: 2005-07-10 %% Type: language Subtag: crh Description: Crimean Tatar Description: Crimean Turkish Added: 2005-07-10 %% Type: language Subtag: crp Description: Creoles and pidgins (Other) Added: 2005-07-10 %% Type: language Subtag: csb Description: Kashubian Added: 2005-07-10 %% Type: language Subtag: cus Description: Cushitic (Other) Added: 2005-07-10 %% Type: language Subtag: dak Description: Dakota Ewell Expires January 11, 2006 [Page 36] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: language Subtag: dar Description: Dargwa Added: 2005-07-10 %% Type: language Subtag: day Description: Dayak Added: 2005-07-10 %% Type: language Subtag: del Description: Delaware Added: 2005-07-10 %% Type: language Subtag: den Description: Slave (Athapascan) Added: 2005-07-10 %% Type: language Subtag: dgr Description: Dogrib Added: 2005-07-10 %% Type: language Subtag: din Description: Dinka Added: 2005-07-10 %% Type: language Subtag: doi Description: Dogri Added: 2005-07-10 %% Type: language Subtag: dra Description: Dravidian (Other) Added: 2005-07-10 %% Type: language Subtag: dsb Description: Lower Sorbian Added: 2005-07-10 %% Type: language Ewell Expires January 11, 2006 [Page 37] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: dua Description: Duala Added: 2005-07-10 %% Type: language Subtag: dum Description: Dutch, Middle (ca. 1050-1350) Added: 2005-07-10 %% Type: language Subtag: dyu Description: Dyula Added: 2005-07-10 %% Type: language Subtag: efi Description: Efik Added: 2005-07-10 %% Type: language Subtag: egy Description: Egyptian (Ancient) Added: 2005-07-10 %% Type: language Subtag: eka Description: Ekajuk Added: 2005-07-10 %% Type: language Subtag: elx Description: Elamite Added: 2005-07-10 %% Type: language Subtag: enm Description: English, Middle (1100-1500) Added: 2005-07-10 %% Type: language Subtag: ewo Description: Ewondo Added: 2005-07-10 %% Type: language Subtag: fan Description: Fang Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 38] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: fat Description: Fanti Added: 2005-07-10 %% Type: language Subtag: fil Description: Filipino Description: Pilipino Added: 2005-07-10 %% Type: language Subtag: fiu Description: Finno-Ugrian (Other) Added: 2005-07-10 %% Type: language Subtag: fon Description: Fon Added: 2005-07-10 %% Type: language Subtag: frm Description: French, Middle (ca. 1400-1600) Added: 2005-07-10 %% Type: language Subtag: fro Description: French, Old (842-ca. 1400) Added: 2005-07-10 %% Type: language Subtag: fur Description: Friulian Added: 2005-07-10 %% Type: language Subtag: gaa Description: Ga Added: 2005-07-10 %% Type: language Subtag: gay Description: Gayo Added: 2005-07-10 %% Type: language Ewell Expires January 11, 2006 [Page 39] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: gba Description: Gbaya Added: 2005-07-10 %% Type: language Subtag: gem Description: Germanic (Other) Added: 2005-07-10 %% Type: language Subtag: gez Description: Geez Added: 2005-07-10 %% Type: language Subtag: gil Description: Gilbertese Added: 2005-07-10 %% Type: language Subtag: gmh Description: German, Middle High (ca. 1050-1500) Added: 2005-07-10 %% Type: language Subtag: goh Description: German, Old High (ca. 750-1050) Added: 2005-07-10 %% Type: language Subtag: gon Description: Gondi Added: 2005-07-10 %% Type: language Subtag: gor Description: Gorontalo Added: 2005-07-10 %% Type: language Subtag: got Description: Gothic Added: 2005-07-10 %% Type: language Subtag: grb Description: Grebo Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 40] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: grc Description: Greek, Ancient (to 1453) Added: 2005-07-10 %% Type: language Subtag: gwi Description: Gwich´in Added: 2005-07-10 %% Type: language Subtag: hai Description: Haida Added: 2005-07-10 %% Type: language Subtag: haw Description: Hawaiian Added: 2005-07-10 %% Type: language Subtag: hil Description: Hiligaynon Added: 2005-07-10 %% Type: language Subtag: him Description: Himachali Added: 2005-07-10 %% Type: language Subtag: hit Description: Hittite Added: 2005-07-10 %% Type: language Subtag: hmn Description: Hmong Added: 2005-07-10 %% Type: language Subtag: hsb Description: Upper Sorbian Added: 2005-07-10 %% Type: language Subtag: hup Ewell Expires January 11, 2006 [Page 41] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Hupa Added: 2005-07-10 %% Type: language Subtag: iba Description: Iban Added: 2005-07-10 %% Type: language Subtag: ijo Description: Ijo Added: 2005-07-10 %% Type: language Subtag: ilo Description: Iloko Added: 2005-07-10 %% Type: language Subtag: inc Description: Indic (Other) Added: 2005-07-10 %% Type: language Subtag: ine Description: Indo-European (Other) Added: 2005-07-10 %% Type: language Subtag: inh Description: Ingush Added: 2005-07-10 %% Type: language Subtag: ira Description: Iranian (Other) Added: 2005-07-10 %% Type: language Subtag: iro Description: Iroquoian languages Added: 2005-07-10 %% Type: language Subtag: jbo Description: Lojban Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 42] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: jpr Description: Judeo-Persian Added: 2005-07-10 %% Type: language Subtag: jrb Description: Judeo-Arabic Added: 2005-07-10 %% Type: language Subtag: kaa Description: Kara-Kalpak Added: 2005-07-10 %% Type: language Subtag: kab Description: Kabyle Added: 2005-07-10 %% Type: language Subtag: kac Description: Kachin Added: 2005-07-10 %% Type: language Subtag: kam Description: Kamba Added: 2005-07-10 %% Type: language Subtag: kar Description: Karen Added: 2005-07-10 %% Type: language Subtag: kaw Description: Kawi Added: 2005-07-10 %% Type: language Subtag: kbd Description: Kabardian Added: 2005-07-10 %% Type: language Subtag: kha Description: Khasi Ewell Expires January 11, 2006 [Page 43] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: language Subtag: khi Description: Khoisan (Other) Added: 2005-07-10 %% Type: language Subtag: kho Description: Khotanese Added: 2005-07-10 %% Type: language Subtag: kmb Description: Kimbundu Added: 2005-07-10 %% Type: language Subtag: kok Description: Konkani Added: 2005-07-10 Suppress-Script: Deva %% Type: language Subtag: kos Description: Kosraean Added: 2005-07-10 %% Type: language Subtag: kpe Description: Kpelle Added: 2005-07-10 %% Type: language Subtag: krc Description: Karachay-Balkar Added: 2005-07-10 %% Type: language Subtag: kro Description: Kru Added: 2005-07-10 %% Type: language Subtag: kru Description: Kurukh Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 44] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: kum Description: Kumyk Added: 2005-07-10 %% Type: language Subtag: kut Description: Kutenai Added: 2005-07-10 %% Type: language Subtag: lad Description: Ladino Added: 2005-07-10 %% Type: language Subtag: lah Description: Lahnda Added: 2005-07-10 %% Type: language Subtag: lam Description: Lamba Added: 2005-07-10 %% Type: language Subtag: lez Description: Lezghian Added: 2005-07-10 %% Type: language Subtag: lol Description: Mongo Added: 2005-07-10 %% Type: language Subtag: loz Description: Lozi Added: 2005-07-10 %% Type: language Subtag: lua Description: Luba-Lulua Added: 2005-07-10 %% Type: language Subtag: lui Description: Luiseno Ewell Expires January 11, 2006 [Page 45] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: language Subtag: lun Description: Lunda Added: 2005-07-10 %% Type: language Subtag: luo Description: Luo (Kenya and Tanzania) Added: 2005-07-10 %% Type: language Subtag: lus Description: Lushai Added: 2005-07-10 %% Type: language Subtag: mad Description: Madurese Added: 2005-07-10 %% Type: language Subtag: mag Description: Magahi Added: 2005-07-10 %% Type: language Subtag: mai Description: Maithili Added: 2005-07-10 Suppress-Script: Deva %% Type: language Subtag: mak Description: Makasar Added: 2005-07-10 %% Type: language Subtag: man Description: Mandingo Added: 2005-07-10 %% Type: language Subtag: map Description: Austronesian (Other) Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 46] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: mas Description: Masai Added: 2005-07-10 %% Type: language Subtag: mdf Description: Moksha Added: 2005-07-10 %% Type: language Subtag: mdr Description: Mandar Added: 2005-07-10 %% Type: language Subtag: men Description: Mende Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: mga Description: Irish, Middle (900-1200) Added: 2005-07-10 %% Type: language Subtag: mic Description: Mi'kmaq Description: Micmac Added: 2005-07-10 %% Type: language Subtag: min Description: Minangkabau Added: 2005-07-10 %% Type: language Subtag: mis Description: Miscellaneous languages Added: 2005-07-10 %% Type: language Subtag: mkh Description: Mon-Khmer (Other) Added: 2005-07-10 %% Type: language Ewell Expires January 11, 2006 [Page 47] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: mnc Description: Manchu Added: 2005-07-10 %% Type: language Subtag: mni Description: Manipuri Added: 2005-07-10 %% Type: language Subtag: mno Description: Manobo languages Added: 2005-07-10 %% Type: language Subtag: moh Description: Mohawk Added: 2005-07-10 %% Type: language Subtag: mos Description: Mossi Added: 2005-07-10 %% Type: language Subtag: mul Description: Multiple languages Added: 2005-07-10 %% Type: language Subtag: mun Description: Munda languages Added: 2005-07-10 %% Type: language Subtag: mus Description: Creek Added: 2005-07-10 %% Type: language Subtag: mwl Description: Mirandese Added: 2005-07-10 %% Type: language Subtag: mwr Description: Marwari Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 48] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: myn Description: Mayan languages Added: 2005-07-10 %% Type: language Subtag: myv Description: Erzya Added: 2005-07-10 %% Type: language Subtag: nah Description: Nahuatl Added: 2005-07-10 %% Type: language Subtag: nai Description: North American Indian Added: 2005-07-10 %% Type: language Subtag: nap Description: Neapolitan Added: 2005-07-10 %% Type: language Subtag: nds Description: Low German Description: Low Saxon Description: German, Low Description: Saxon, Low Added: 2005-07-10 %% Type: language Subtag: new Description: Nepal Bhasa Description: Newari Added: 2005-07-10 %% Type: language Subtag: nia Description: Nias Added: 2005-07-10 %% Type: language Subtag: nic Description: Niger-Kordofanian (Other) Ewell Expires January 11, 2006 [Page 49] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: language Subtag: niu Description: Niuean Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: nog Description: Nogai Added: 2005-07-10 %% Type: language Subtag: non Description: Norse, Old Added: 2005-07-10 %% Type: language Subtag: nso Description: Northern Sotho Description: Pedi Description: Sepedi Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: nub Description: Nubian languages Added: 2005-07-10 %% Type: language Subtag: nwc Description: Classical Newari Description: Old Newari Description: Classical Nepal Bhasa Added: 2005-07-10 %% Type: language Subtag: nym Description: Nyamwezi Added: 2005-07-10 %% Type: language Subtag: nyn Description: Nyankole Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 50] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: nyo Description: Nyoro Added: 2005-07-10 %% Type: language Subtag: nzi Description: Nzima Added: 2005-07-10 %% Type: language Subtag: osa Description: Osage Added: 2005-07-10 %% Type: language Subtag: ota Description: Turkish, Ottoman (1500-1928) Added: 2005-07-10 %% Type: language Subtag: oto Description: Otomian languages Added: 2005-07-10 %% Type: language Subtag: paa Description: Papuan (Other) Added: 2005-07-10 %% Type: language Subtag: pag Description: Pangasinan Added: 2005-07-10 %% Type: language Subtag: pal Description: Pahlavi Added: 2005-07-10 %% Type: language Subtag: pam Description: Pampanga Added: 2005-07-10 %% Type: language Subtag: pap Description: Papiamento Ewell Expires January 11, 2006 [Page 51] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: language Subtag: pau Description: Palauan Added: 2005-07-10 %% Type: language Subtag: peo Description: Persian, Old (ca. 600-400 B.C.) Added: 2005-07-10 %% Type: language Subtag: phi Description: Philippine (Other) Added: 2005-07-10 %% Type: language Subtag: phn Description: Phoenician Added: 2005-07-10 %% Type: language Subtag: pon Description: Pohnpeian Added: 2005-07-10 %% Type: language Subtag: pra Description: Prakrit languages Added: 2005-07-10 %% Type: language Subtag: pro Description: Provençal, Old (to 1500) Added: 2005-07-10 %% Type: language Subtag: qaa..qtz Description: PRIVATE USE Added: 2005-07-10 %% Type: language Subtag: raj Description: Rajasthani Added: 2005-07-10 %% Type: language Ewell Expires January 11, 2006 [Page 52] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: rap Description: Rapanui Added: 2005-07-10 %% Type: language Subtag: rar Description: Rarotongan Added: 2005-07-10 %% Type: language Subtag: roa Description: Romance (Other) Added: 2005-07-10 %% Type: language Subtag: rom Description: Romany Added: 2005-07-10 %% Type: language Subtag: sad Description: Sandawe Added: 2005-07-10 %% Type: language Subtag: sah Description: Yakut Added: 2005-07-10 %% Type: language Subtag: sai Description: South American Indian (Other) Added: 2005-07-10 %% Type: language Subtag: sal Description: Salishan languages Added: 2005-07-10 %% Type: language Subtag: sam Description: Samaritan Aramaic Added: 2005-07-10 %% Type: language Subtag: sas Description: Sasak Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 53] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: language Subtag: sat Description: Santali Added: 2005-07-10 %% Type: language Subtag: scn Description: Sicilian Added: 2005-07-10 %% Type: language Subtag: sco Description: Scots Added: 2005-07-10 %% Type: language Subtag: sel Description: Selkup Added: 2005-07-10 %% Type: language Subtag: sem Description: Semitic (Other) Added: 2005-07-10 %% Type: language Subtag: sga Description: Irish, Old (to 900) Added: 2005-07-10 %% Type: language Subtag: sgn Description: Sign Languages Added: 2005-07-10 %% Type: language Subtag: shn Description: Shan Added: 2005-07-10 %% Type: language Subtag: sid Description: Sidamo Added: 2005-07-10 %% Type: language Subtag: sio Ewell Expires January 11, 2006 [Page 54] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Siouan languages Added: 2005-07-10 %% Type: language Subtag: sit Description: Sino-Tibetan (Other) Added: 2005-07-10 %% Type: language Subtag: sla Description: Slavic (Other) Added: 2005-07-10 %% Type: language Subtag: sma Description: Southern Sami Added: 2005-07-10 %% Type: language Subtag: smi Description: Sami languages (Other) Added: 2005-07-10 %% Type: language Subtag: smj Description: Lule Sami Added: 2005-07-10 %% Type: language Subtag: smn Description: Inari Sami Added: 2005-07-10 %% Type: language Subtag: sms Description: Skolt Sami Added: 2005-07-10 %% Type: language Subtag: snk Description: Soninke Added: 2005-07-10 %% Type: language Subtag: sog Description: Sogdian Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 55] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: son Description: Songhai Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: srn Description: Sranan Tongo Added: 2005-07-10 %% Type: language Subtag: srr Description: Serer Added: 2005-07-10 %% Type: language Subtag: ssa Description: Nilo-Saharan (Other) Added: 2005-07-10 %% Type: language Subtag: suk Description: Sukuma Added: 2005-07-10 %% Type: language Subtag: sus Description: Susu Added: 2005-07-10 %% Type: language Subtag: sux Description: Sumerian Added: 2005-07-10 %% Type: language Subtag: syr Description: Syriac Added: 2005-07-10 %% Type: language Subtag: tai Description: Tai (Other) Added: 2005-07-10 %% Type: language Subtag: tem Ewell Expires January 11, 2006 [Page 56] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Timne Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: ter Description: Tereno Added: 2005-07-10 %% Type: language Subtag: tet Description: Tetum Added: 2005-07-10 %% Type: language Subtag: tig Description: Tigre Added: 2005-07-10 %% Type: language Subtag: tiv Description: Tiv Added: 2005-07-10 %% Type: language Subtag: tkl Description: Tokelau Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: tlh Description: Klingon Description: tlhIngan-Hol Added: 2005-07-10 %% Type: language Subtag: tli Description: Tlingit Added: 2005-07-10 %% Type: language Subtag: tmh Description: Tamashek Added: 2005-07-10 Suppress-Script: Latn %% Type: language Ewell Expires January 11, 2006 [Page 57] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: tog Description: Tonga (Nyasa) Added: 2005-07-10 %% Type: language Subtag: tpi Description: Tok Pisin Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: tsi Description: Tsimshian Added: 2005-07-10 %% Type: language Subtag: tum Description: Tumbuka Added: 2005-07-10 %% Type: language Subtag: tup Description: Tupi languages Added: 2005-07-10 %% Type: language Subtag: tut Description: Altaic (Other) Added: 2005-07-10 %% Type: language Subtag: tvl Description: Tuvalu Added: 2005-07-10 Suppress-Script: Latn %% Type: language Subtag: tyv Description: Tuvinian Added: 2005-07-10 %% Type: language Subtag: udm Description: Udmurt Added: 2005-07-10 %% Type: language Subtag: uga Ewell Expires January 11, 2006 [Page 58] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Ugaritic Added: 2005-07-10 %% Type: language Subtag: umb Description: Umbundu Added: 2005-07-10 %% Type: language Subtag: und Description: Undetermined Added: 2005-07-10 %% Type: language Subtag: vai Description: Vai Added: 2005-07-10 %% Type: language Subtag: vot Description: Votic Added: 2005-07-10 %% Type: language Subtag: wak Description: Wakashan languages Added: 2005-07-10 %% Type: language Subtag: wal Description: Walamo Added: 2005-07-10 %% Type: language Subtag: war Description: Waray Added: 2005-07-10 %% Type: language Subtag: was Description: Washo Added: 2005-07-10 %% Type: language Subtag: wen Description: Sorbian languages Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 59] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: language Subtag: xal Description: Kalmyk Description: Oirat Added: 2005-07-10 %% Type: language Subtag: yao Description: Yao Added: 2005-07-10 %% Type: language Subtag: yap Description: Yapese Added: 2005-07-10 %% Type: language Subtag: ypk Description: Yupik languages Added: 2005-07-10 %% Type: language Subtag: zap Description: Zapotec Added: 2005-07-10 %% Type: language Subtag: zen Description: Zenaga Added: 2005-07-10 %% Type: language Subtag: znd Description: Zande Added: 2005-07-10 %% Type: language Subtag: zun Description: Zuni Added: 2005-07-10 %% Type: script Subtag: Arab Description: Arabic Added: 2005-07-10 %% Type: script Subtag: Armn Ewell Expires January 11, 2006 [Page 60] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Armenian Added: 2005-07-10 %% Type: script Subtag: Bali Description: Balinese Added: 2005-07-10 %% Type: script Subtag: Batk Description: Batak Added: 2005-07-10 %% Type: script Subtag: Beng Description: Bengali Added: 2005-07-10 %% Type: script Subtag: Blis Description: Blissymbols Added: 2005-07-10 %% Type: script Subtag: Bopo Description: Bopomofo Added: 2005-07-10 %% Type: script Subtag: Brah Description: Brahmi Added: 2005-07-10 %% Type: script Subtag: Brai Description: Braille Added: 2005-07-10 %% Type: script Subtag: Bugi Description: Buginese Added: 2005-07-10 %% Type: script Subtag: Buhd Description: Buhid Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 61] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: script Subtag: Cans Description: Unified Canadian Aboriginal Syllabics Added: 2005-07-10 %% Type: script Subtag: Cham Description: Cham Added: 2005-07-10 %% Type: script Subtag: Cher Description: Cherokee Added: 2005-07-10 %% Type: script Subtag: Cirt Description: Cirth Added: 2005-07-10 %% Type: script Subtag: Copt Description: Coptic Added: 2005-07-10 %% Type: script Subtag: Cprt Description: Cypriot Added: 2005-07-10 %% Type: script Subtag: Cyrl Description: Cyrillic Added: 2005-07-10 %% Type: script Subtag: Cyrs Description: Cyrillic (Old Church Slavonic variant) Added: 2005-07-10 %% Type: script Subtag: Deva Description: Devanagari (Nagari) Added: 2005-07-10 %% Type: script Subtag: Dsrt Description: Deseret (Mormon) Ewell Expires January 11, 2006 [Page 62] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: script Subtag: Egyd Description: Egyptian demotic Added: 2005-07-10 %% Type: script Subtag: Egyh Description: Egyptian hieratic Added: 2005-07-10 %% Type: script Subtag: Egyp Description: Egyptian hieroglyphs Added: 2005-07-10 %% Type: script Subtag: Ethi Description: Ethiopic (Ge‘ez) Added: 2005-07-10 %% Type: script Subtag: Geok Description: Khutsuri (Asomtavruli and Nuskhuri) Added: 2005-07-10 %% Type: script Subtag: Geor Description: Georgian (Mkhedruli) Added: 2005-07-10 %% Type: script Subtag: Glag Description: Glagolitic Added: 2005-07-10 %% Type: script Subtag: Goth Description: Gothic Added: 2005-07-10 %% Type: script Subtag: Grek Description: Greek Added: 2005-07-10 %% Type: script Ewell Expires January 11, 2006 [Page 63] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: Gujr Description: Gujarati Added: 2005-07-10 %% Type: script Subtag: Guru Description: Gurmukhi Added: 2005-07-10 %% Type: script Subtag: Hang Description: Hangul (Hangŭl, Hangeul) Added: 2005-07-10 %% Type: script Subtag: Hani Description: Han (Hanzi, Kanji, Hanja) Added: 2005-07-10 %% Type: script Subtag: Hano Description: Hanunoo (Hanunóo) Added: 2005-07-10 %% Type: script Subtag: Hans Description: Han (Simplified variant) Added: 2005-07-10 %% Type: script Subtag: Hant Description: Han (Traditional variant) Added: 2005-07-10 %% Type: script Subtag: Hebr Description: Hebrew Added: 2005-07-10 %% Type: script Subtag: Hira Description: Hiragana Added: 2005-07-10 %% Type: script Subtag: Hmng Description: Pahawh Hmong Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 64] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: script Subtag: Hrkt Description: (alias for Hiragana + Katakana) Added: 2005-07-10 %% Type: script Subtag: Hung Description: Old Hungarian Added: 2005-07-10 %% Type: script Subtag: Inds Description: Indus (Harappan) Added: 2005-07-10 %% Type: script Subtag: Ital Description: Old Italic (Etruscan, Oscan, etc.) Added: 2005-07-10 %% Type: script Subtag: Java Description: Javanese Added: 2005-07-10 %% Type: script Subtag: Kali Description: Kayah Li Added: 2005-07-10 %% Type: script Subtag: Kana Description: Katakana Added: 2005-07-10 %% Type: script Subtag: Khar Description: Kharoshthi Added: 2005-07-10 %% Type: script Subtag: Khmr Description: Khmer Added: 2005-07-10 %% Type: script Subtag: Knda Ewell Expires January 11, 2006 [Page 65] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Kannada Added: 2005-07-10 %% Type: script Subtag: Laoo Description: Lao Added: 2005-07-10 %% Type: script Subtag: Latf Description: Latin (Fraktur variant) Added: 2005-07-10 %% Type: script Subtag: Latg Description: Latin (Gaelic variant) Added: 2005-07-10 %% Type: script Subtag: Latn Description: Latin Added: 2005-07-10 %% Type: script Subtag: Lepc Description: Lepcha (Róng) Added: 2005-07-10 %% Type: script Subtag: Limb Description: Limbu Added: 2005-07-10 %% Type: script Subtag: Lina Description: Linear A Added: 2005-07-10 %% Type: script Subtag: Linb Description: Linear B Added: 2005-07-10 %% Type: script Subtag: Mand Description: Mandaean Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 66] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: script Subtag: Maya Description: Mayan hieroglyphs Added: 2005-07-10 %% Type: script Subtag: Mero Description: Meroitic Added: 2005-07-10 %% Type: script Subtag: Mlym Description: Malayalam Added: 2005-07-10 %% Type: script Subtag: Mong Description: Mongolian Added: 2005-07-10 %% Type: script Subtag: Mymr Description: Myanmar (Burmese) Added: 2005-07-10 %% Type: script Subtag: Nkoo Description: N’Ko Added: 2005-07-10 %% Type: script Subtag: Ogam Description: Ogham Added: 2005-07-10 %% Type: script Subtag: Orkh Description: Orkhon Added: 2005-07-10 %% Type: script Subtag: Orya Description: Oriya Added: 2005-07-10 %% Type: script Subtag: Osma Description: Osmanya Ewell Expires January 11, 2006 [Page 67] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: script Subtag: Perm Description: Old Permic Added: 2005-07-10 %% Type: script Subtag: Phag Description: Phags-pa Added: 2005-07-10 %% Type: script Subtag: Phnx Description: Phoenician Added: 2005-07-10 %% Type: script Subtag: Plrd Description: Pollard Phonetic Added: 2005-07-10 %% Type: script Subtag: Qaaa..Qabx Description: PRIVATE USE Added: 2005-07-10 %% Type: script Subtag: Roro Description: Rongorongo Added: 2005-07-10 %% Type: script Subtag: Runr Description: Runic Added: 2005-07-10 %% Type: script Subtag: Sara Description: Sarati Added: 2005-07-10 %% Type: script Subtag: Shaw Description: Shavian (Shaw) Added: 2005-07-10 %% Type: script Ewell Expires January 11, 2006 [Page 68] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: Sinh Description: Sinhala Added: 2005-07-10 %% Type: script Subtag: Sylo Description: Syloti Nagri Added: 2005-07-10 %% Type: script Subtag: Syrc Description: Syriac Added: 2005-07-10 %% Type: script Subtag: Syre Description: Syriac (Estrangelo variant) Added: 2005-07-10 %% Type: script Subtag: Syrj Description: Syriac (Western variant) Added: 2005-07-10 %% Type: script Subtag: Syrn Description: Syriac (Eastern variant) Added: 2005-07-10 %% Type: script Subtag: Tagb Description: Tagbanwa Added: 2005-07-10 %% Type: script Subtag: Tale Description: Tai Le Added: 2005-07-10 %% Type: script Subtag: Talu Description: New Tai Lue Added: 2005-07-10 %% Type: script Subtag: Taml Description: Tamil Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 69] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: script Subtag: Telu Description: Telugu Added: 2005-07-10 %% Type: script Subtag: Teng Description: Tengwar Added: 2005-07-10 %% Type: script Subtag: Tfng Description: Tifinagh (Berber) Added: 2005-07-10 %% Type: script Subtag: Tglg Description: Tagalog Added: 2005-07-10 %% Type: script Subtag: Thaa Description: Thaana Added: 2005-07-10 %% Type: script Subtag: Thai Description: Thai Added: 2005-07-10 %% Type: script Subtag: Tibt Description: Tibetan Added: 2005-07-10 %% Type: script Subtag: Ugar Description: Ugaritic Added: 2005-07-10 %% Type: script Subtag: Vaii Description: Vai Added: 2005-07-10 %% Type: script Subtag: Visp Ewell Expires January 11, 2006 [Page 70] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Visible Speech Added: 2005-07-10 %% Type: script Subtag: Xpeo Description: Old Persian Added: 2005-07-10 %% Type: script Subtag: Xsux Description: Cuneiform, Sumero-Akkadian Added: 2005-07-10 %% Type: script Subtag: Yiii Description: Yi Added: 2005-07-10 %% Type: script Subtag: Zxxx Description: Code for unwritten languages Added: 2005-07-10 %% Type: script Subtag: Zyyy Description: Code for undetermined script Added: 2005-07-10 %% Type: script Subtag: Zzzz Description: Code for uncoded script Added: 2005-07-10 %% Type: region Subtag: AA Description: PRIVATE USE Added: 2005-07-10 %% Type: region Subtag: AD Description: Andorra Added: 2005-07-10 %% Type: region Subtag: AE Description: United Arab Emirates Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 71] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: region Subtag: AF Description: Afghanistan Added: 2005-07-10 %% Type: region Subtag: AG Description: Antigua and Barbuda Added: 2005-07-10 %% Type: region Subtag: AI Description: Anguilla Added: 2005-07-10 %% Type: region Subtag: AL Description: Albania Added: 2005-07-10 %% Type: region Subtag: AM Description: Armenia Added: 2005-07-10 %% Type: region Subtag: AN Description: Netherlands Antilles Added: 2005-07-10 %% Type: region Subtag: AO Description: Angola Added: 2005-07-10 %% Type: region Subtag: AQ Description: Antarctica Added: 2005-07-10 %% Type: region Subtag: AR Description: Argentina Added: 2005-07-10 %% Type: region Subtag: AS Description: American Samoa Ewell Expires January 11, 2006 [Page 72] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: region Subtag: AT Description: Austria Added: 2005-07-10 %% Type: region Subtag: AU Description: Australia Added: 2005-07-10 %% Type: region Subtag: AW Description: Aruba Added: 2005-07-10 %% Type: region Subtag: AX Description: Åland Islands Added: 2005-07-10 %% Type: region Subtag: AZ Description: Azerbaijan Added: 2005-07-10 %% Type: region Subtag: BA Description: Bosnia and Herzegovina Added: 2005-07-10 %% Type: region Subtag: BB Description: Barbados Added: 2005-07-10 %% Type: region Subtag: BD Description: Bangladesh Added: 2005-07-10 %% Type: region Subtag: BE Description: Belgium Added: 2005-07-10 %% Type: region Ewell Expires January 11, 2006 [Page 73] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: BF Description: Burkina Faso Added: 2005-07-10 %% Type: region Subtag: BG Description: Bulgaria Added: 2005-07-10 %% Type: region Subtag: BH Description: Bahrain Added: 2005-07-10 %% Type: region Subtag: BI Description: Burundi Added: 2005-07-10 %% Type: region Subtag: BJ Description: Benin Added: 2005-07-10 %% Type: region Subtag: BM Description: Bermuda Added: 2005-07-10 %% Type: region Subtag: BN Description: Brunei Darussalam Added: 2005-07-10 %% Type: region Subtag: BO Description: Bolivia Added: 2005-07-10 %% Type: region Subtag: BR Description: Brazil Added: 2005-07-10 %% Type: region Subtag: BS Description: Bahamas Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 74] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: region Subtag: BT Description: Bhutan Added: 2005-07-10 %% Type: region Subtag: BU Description: Burma Added: 2005-07-10 Preferred-Value: MM Deprecated: 1989-12-05 %% Type: region Subtag: BV Description: Bouvet Island Added: 2005-07-10 %% Type: region Subtag: BW Description: Botswana Added: 2005-07-10 %% Type: region Subtag: BY Description: Belarus Added: 2005-07-10 %% Type: region Subtag: BZ Description: Belize Added: 2005-07-10 %% Type: region Subtag: CA Description: Canada Added: 2005-07-10 %% Type: region Subtag: CC Description: Cocos (Keeling) Islands Added: 2005-07-10 %% Type: region Subtag: CD Description: Congo, The Democratic Republic of the Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 75] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: region Subtag: CF Description: Central African Republic Added: 2005-07-10 %% Type: region Subtag: CG Description: Congo Added: 2005-07-10 %% Type: region Subtag: CH Description: Switzerland Added: 2005-07-10 %% Type: region Subtag: CI Description: Côte d'Ivoire Added: 2005-07-10 %% Type: region Subtag: CK Description: Cook Islands Added: 2005-07-10 %% Type: region Subtag: CL Description: Chile Added: 2005-07-10 %% Type: region Subtag: CM Description: Cameroon Added: 2005-07-10 %% Type: region Subtag: CN Description: China Added: 2005-07-10 %% Type: region Subtag: CO Description: Colombia Added: 2005-07-10 %% Type: region Subtag: CR Description: Costa Rica Ewell Expires January 11, 2006 [Page 76] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: region Subtag: CS Description: Serbia and Montenegro Added: 2005-07-10 %% Type: region Subtag: CU Description: Cuba Added: 2005-07-10 %% Type: region Subtag: CV Description: Cape Verde Added: 2005-07-10 %% Type: region Subtag: CX Description: Christmas Island Added: 2005-07-10 %% Type: region Subtag: CY Description: Cyprus Added: 2005-07-10 %% Type: region Subtag: CZ Description: Czech Republic Added: 2005-07-10 %% Type: region Subtag: DD Description: German Democratic Republic Added: 2005-07-10 Preferred-Value: DE Deprecated: 1990-10-30 %% Type: region Subtag: DE Description: Germany Added: 2005-07-10 %% Type: region Subtag: DJ Description: Djibouti Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 77] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: region Subtag: DK Description: Denmark Added: 2005-07-10 %% Type: region Subtag: DM Description: Dominica Added: 2005-07-10 %% Type: region Subtag: DO Description: Dominican Republic Added: 2005-07-10 %% Type: region Subtag: DZ Description: Algeria Added: 2005-07-10 %% Type: region Subtag: EC Description: Ecuador Added: 2005-07-10 %% Type: region Subtag: EE Description: Estonia Added: 2005-07-10 %% Type: region Subtag: EG Description: Egypt Added: 2005-07-10 %% Type: region Subtag: EH Description: Western Sahara Added: 2005-07-10 %% Type: region Subtag: ER Description: Eritrea Added: 2005-07-10 %% Type: region Subtag: ES Ewell Expires January 11, 2006 [Page 78] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Spain Added: 2005-07-10 %% Type: region Subtag: ET Description: Ethiopia Added: 2005-07-10 %% Type: region Subtag: FI Description: Finland Added: 2005-07-10 %% Type: region Subtag: FJ Description: Fiji Added: 2005-07-10 %% Type: region Subtag: FK Description: Falkland Islands (Malvinas) Added: 2005-07-10 %% Type: region Subtag: FM Description: Micronesia, Federated States of Added: 2005-07-10 %% Type: region Subtag: FO Description: Faroe Islands Added: 2005-07-10 %% Type: region Subtag: FR Description: France Added: 2005-07-10 %% Type: region Subtag: FX Description: Metropolitan France Added: 2005-07-10 Preferred-Value: FR Deprecated: 1997-07-14 %% Type: region Subtag: GA Description: Gabon Ewell Expires January 11, 2006 [Page 79] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: region Subtag: GB Description: United Kingdom Added: 2005-07-10 %% Type: region Subtag: GD Description: Grenada Added: 2005-07-10 %% Type: region Subtag: GE Description: Georgia Added: 2005-07-10 %% Type: region Subtag: GF Description: French Guiana Added: 2005-07-10 %% Type: region Subtag: GH Description: Ghana Added: 2005-07-10 %% Type: region Subtag: GI Description: Gibraltar Added: 2005-07-10 %% Type: region Subtag: GL Description: Greenland Added: 2005-07-10 %% Type: region Subtag: GM Description: Gambia Added: 2005-07-10 %% Type: region Subtag: GN Description: Guinea Added: 2005-07-10 %% Type: region Ewell Expires January 11, 2006 [Page 80] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: GP Description: Guadeloupe Added: 2005-07-10 %% Type: region Subtag: GQ Description: Equatorial Guinea Added: 2005-07-10 %% Type: region Subtag: GR Description: Greece Added: 2005-07-10 %% Type: region Subtag: GS Description: South Georgia and the South Sandwich Islands Added: 2005-07-10 %% Type: region Subtag: GT Description: Guatemala Added: 2005-07-10 %% Type: region Subtag: GU Description: Guam Added: 2005-07-10 %% Type: region Subtag: GW Description: Guinea-Bissau Added: 2005-07-10 %% Type: region Subtag: GY Description: Guyana Added: 2005-07-10 %% Type: region Subtag: HK Description: Hong Kong Added: 2005-07-10 %% Type: region Subtag: HM Description: Heard Island and McDonald Islands Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 81] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: region Subtag: HN Description: Honduras Added: 2005-07-10 %% Type: region Subtag: HR Description: Croatia Added: 2005-07-10 %% Type: region Subtag: HT Description: Haiti Added: 2005-07-10 %% Type: region Subtag: HU Description: Hungary Added: 2005-07-10 %% Type: region Subtag: ID Description: Indonesia Added: 2005-07-10 %% Type: region Subtag: IE Description: Ireland Added: 2005-07-10 %% Type: region Subtag: IL Description: Israel Added: 2005-07-10 %% Type: region Subtag: IN Description: India Added: 2005-07-10 %% Type: region Subtag: IO Description: British Indian Ocean Territory Added: 2005-07-10 %% Type: region Subtag: IQ Ewell Expires January 11, 2006 [Page 82] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Iraq Added: 2005-07-10 %% Type: region Subtag: IR Description: Iran, Islamic Republic of Added: 2005-07-10 %% Type: region Subtag: IS Description: Iceland Added: 2005-07-10 %% Type: region Subtag: IT Description: Italy Added: 2005-07-10 %% Type: region Subtag: JM Description: Jamaica Added: 2005-07-10 %% Type: region Subtag: JO Description: Jordan Added: 2005-07-10 %% Type: region Subtag: JP Description: Japan Added: 2005-07-10 %% Type: region Subtag: KE Description: Kenya Added: 2005-07-10 %% Type: region Subtag: KG Description: Kyrgyzstan Added: 2005-07-10 %% Type: region Subtag: KH Description: Cambodia Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 83] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: region Subtag: KI Description: Kiribati Added: 2005-07-10 %% Type: region Subtag: KM Description: Comoros Added: 2005-07-10 %% Type: region Subtag: KN Description: Saint Kitts and Nevis Added: 2005-07-10 %% Type: region Subtag: KP Description: Korea, Democratic People's Republic of Added: 2005-07-10 %% Type: region Subtag: KR Description: Korea, Republic of Added: 2005-07-10 %% Type: region Subtag: KW Description: Kuwait Added: 2005-07-10 %% Type: region Subtag: KY Description: Cayman Islands Added: 2005-07-10 %% Type: region Subtag: KZ Description: Kazakhstan Added: 2005-07-10 %% Type: region Subtag: LA Description: Lao People's Democratic Republic Added: 2005-07-10 %% Type: region Subtag: LB Description: Lebanon Ewell Expires January 11, 2006 [Page 84] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: region Subtag: LC Description: Saint Lucia Added: 2005-07-10 %% Type: region Subtag: LI Description: Liechtenstein Added: 2005-07-10 %% Type: region Subtag: LK Description: Sri Lanka Added: 2005-07-10 %% Type: region Subtag: LR Description: Liberia Added: 2005-07-10 %% Type: region Subtag: LS Description: Lesotho Added: 2005-07-10 %% Type: region Subtag: LT Description: Lithuania Added: 2005-07-10 %% Type: region Subtag: LU Description: Luxembourg Added: 2005-07-10 %% Type: region Subtag: LV Description: Latvia Added: 2005-07-10 %% Type: region Subtag: LY Description: Libyan Arab Jamahiriya Added: 2005-07-10 %% Type: region Ewell Expires January 11, 2006 [Page 85] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: MA Description: Morocco Added: 2005-07-10 %% Type: region Subtag: MC Description: Monaco Added: 2005-07-10 %% Type: region Subtag: MD Description: Moldova, Republic of Added: 2005-07-10 %% Type: region Subtag: MG Description: Madagascar Added: 2005-07-10 %% Type: region Subtag: MH Description: Marshall Islands Added: 2005-07-10 %% Type: region Subtag: MK Description: Macedonia, The Former Yugoslav Republic of Added: 2005-07-10 %% Type: region Subtag: ML Description: Mali Added: 2005-07-10 %% Type: region Subtag: MM Description: Myanmar Added: 2005-07-10 %% Type: region Subtag: MN Description: Mongolia Added: 2005-07-10 %% Type: region Subtag: MO Description: Macao Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 86] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: region Subtag: MP Description: Northern Mariana Islands Added: 2005-07-10 %% Type: region Subtag: MQ Description: Martinique Added: 2005-07-10 %% Type: region Subtag: MR Description: Mauritania Added: 2005-07-10 %% Type: region Subtag: MS Description: Montserrat Added: 2005-07-10 %% Type: region Subtag: MT Description: Malta Added: 2005-07-10 %% Type: region Subtag: MU Description: Mauritius Added: 2005-07-10 %% Type: region Subtag: MV Description: Maldives Added: 2005-07-10 %% Type: region Subtag: MW Description: Malawi Added: 2005-07-10 %% Type: region Subtag: MX Description: Mexico Added: 2005-07-10 %% Type: region Subtag: MY Ewell Expires January 11, 2006 [Page 87] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Malaysia Added: 2005-07-10 %% Type: region Subtag: MZ Description: Mozambique Added: 2005-07-10 %% Type: region Subtag: NA Description: Namibia Added: 2005-07-10 %% Type: region Subtag: NC Description: New Caledonia Added: 2005-07-10 %% Type: region Subtag: NE Description: Niger Added: 2005-07-10 %% Type: region Subtag: NF Description: Norfolk Island Added: 2005-07-10 %% Type: region Subtag: NG Description: Nigeria Added: 2005-07-10 %% Type: region Subtag: NI Description: Nicaragua Added: 2005-07-10 %% Type: region Subtag: NL Description: Netherlands Added: 2005-07-10 %% Type: region Subtag: NO Description: Norway Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 88] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: region Subtag: NP Description: Nepal Added: 2005-07-10 %% Type: region Subtag: NR Description: Nauru Added: 2005-07-10 %% Type: region Subtag: NT Description: Neutral Zone Added: 2005-07-10 Deprecated: 1993-07-12 %% Type: region Subtag: NU Description: Niue Added: 2005-07-10 %% Type: region Subtag: NZ Description: New Zealand Added: 2005-07-10 %% Type: region Subtag: OM Description: Oman Added: 2005-07-10 %% Type: region Subtag: PA Description: Panama Added: 2005-07-10 %% Type: region Subtag: PE Description: Peru Added: 2005-07-10 %% Type: region Subtag: PF Description: French Polynesia Added: 2005-07-10 %% Type: region Subtag: PG Ewell Expires January 11, 2006 [Page 89] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Papua New Guinea Added: 2005-07-10 %% Type: region Subtag: PH Description: Philippines Added: 2005-07-10 %% Type: region Subtag: PK Description: Pakistan Added: 2005-07-10 %% Type: region Subtag: PL Description: Poland Added: 2005-07-10 %% Type: region Subtag: PM Description: Saint Pierre and Miquelon Added: 2005-07-10 %% Type: region Subtag: PN Description: Pitcairn Added: 2005-07-10 %% Type: region Subtag: PR Description: Puerto Rico Added: 2005-07-10 %% Type: region Subtag: PS Description: Palestinian Territory, Occupied Added: 2005-07-10 %% Type: region Subtag: PT Description: Portugal Added: 2005-07-10 %% Type: region Subtag: PW Description: Palau Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 90] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: region Subtag: PY Description: Paraguay Added: 2005-07-10 %% Type: region Subtag: QA Description: Qatar Added: 2005-07-10 %% Type: region Subtag: QM..QZ Description: PRIVATE USE Added: 2005-07-10 %% Type: region Subtag: RE Description: Réunion Added: 2005-07-10 %% Type: region Subtag: RO Description: Romania Added: 2005-07-10 %% Type: region Subtag: RU Description: Russian Federation Added: 2005-07-10 %% Type: region Subtag: RW Description: Rwanda Added: 2005-07-10 %% Type: region Subtag: SA Description: Saudi Arabia Added: 2005-07-10 %% Type: region Subtag: SB Description: Solomon Islands Added: 2005-07-10 %% Type: region Subtag: SC Description: Seychelles Ewell Expires January 11, 2006 [Page 91] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: region Subtag: SD Description: Sudan Added: 2005-07-10 %% Type: region Subtag: SE Description: Sweden Added: 2005-07-10 %% Type: region Subtag: SG Description: Singapore Added: 2005-07-10 %% Type: region Subtag: SH Description: Saint Helena Added: 2005-07-10 %% Type: region Subtag: SI Description: Slovenia Added: 2005-07-10 %% Type: region Subtag: SJ Description: Svalbard and Jan Mayen Added: 2005-07-10 %% Type: region Subtag: SK Description: Slovakia Added: 2005-07-10 %% Type: region Subtag: SL Description: Sierra Leone Added: 2005-07-10 %% Type: region Subtag: SM Description: San Marino Added: 2005-07-10 %% Type: region Ewell Expires January 11, 2006 [Page 92] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: SN Description: Senegal Added: 2005-07-10 %% Type: region Subtag: SO Description: Somalia Added: 2005-07-10 %% Type: region Subtag: SR Description: Suriname Added: 2005-07-10 %% Type: region Subtag: ST Description: Sao Tome and Principe Added: 2005-07-10 %% Type: region Subtag: SU Description: Union of Soviet Socialist Republics Added: 2005-07-10 Deprecated: 1992-08-30 %% Type: region Subtag: SV Description: El Salvador Added: 2005-07-10 %% Type: region Subtag: SY Description: Syrian Arab Republic Added: 2005-07-10 %% Type: region Subtag: SZ Description: Swaziland Added: 2005-07-10 %% Type: region Subtag: TC Description: Turks and Caicos Islands Added: 2005-07-10 %% Type: region Subtag: TD Description: Chad Ewell Expires January 11, 2006 [Page 93] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: region Subtag: TF Description: French Southern Territories Added: 2005-07-10 %% Type: region Subtag: TG Description: Togo Added: 2005-07-10 %% Type: region Subtag: TH Description: Thailand Added: 2005-07-10 %% Type: region Subtag: TJ Description: Tajikistan Added: 2005-07-10 %% Type: region Subtag: TK Description: Tokelau Added: 2005-07-10 %% Type: region Subtag: TL Description: Timor-Leste Added: 2005-07-10 %% Type: region Subtag: TM Description: Turkmenistan Added: 2005-07-10 %% Type: region Subtag: TN Description: Tunisia Added: 2005-07-10 %% Type: region Subtag: TO Description: Tonga Added: 2005-07-10 %% Type: region Ewell Expires January 11, 2006 [Page 94] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: TP Description: East Timor Added: 2005-07-10 Preferred-Value: TL Deprecated: 2002-11-15 %% Type: region Subtag: TR Description: Turkey Added: 2005-07-10 %% Type: region Subtag: TT Description: Trinidad and Tobago Added: 2005-07-10 %% Type: region Subtag: TV Description: Tuvalu Added: 2005-07-10 %% Type: region Subtag: TW Description: Taiwan, Province of China Added: 2005-07-10 %% Type: region Subtag: TZ Description: Tanzania, United Republic of Added: 2005-07-10 %% Type: region Subtag: UA Description: Ukraine Added: 2005-07-10 %% Type: region Subtag: UG Description: Uganda Added: 2005-07-10 %% Type: region Subtag: UM Description: United States Minor Outlying Islands Added: 2005-07-10 %% Type: region Subtag: US Ewell Expires January 11, 2006 [Page 95] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: United States Added: 2005-07-10 %% Type: region Subtag: UY Description: Uruguay Added: 2005-07-10 %% Type: region Subtag: UZ Description: Uzbekistan Added: 2005-07-10 %% Type: region Subtag: VA Description: Holy See (Vatican City State) Added: 2005-07-10 %% Type: region Subtag: VC Description: Saint Vincent and the Grenadines Added: 2005-07-10 %% Type: region Subtag: VE Description: Venezuela Added: 2005-07-10 %% Type: region Subtag: VG Description: Virgin Islands, British Added: 2005-07-10 %% Type: region Subtag: VI Description: Virgin Islands, U.S. Added: 2005-07-10 %% Type: region Subtag: VN Description: Viet Nam Added: 2005-07-10 %% Type: region Subtag: VU Description: Vanuatu Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 96] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: region Subtag: WF Description: Wallis and Futuna Added: 2005-07-10 %% Type: region Subtag: WS Description: Samoa Added: 2005-07-10 %% Type: region Subtag: XA..XZ Description: PRIVATE USE Added: 2005-07-10 %% Type: region Subtag: YD Description: Yemen, Democratic Added: 2005-07-10 Preferred-Value: YE Deprecated: 1990-08-14 %% Type: region Subtag: YE Description: Yemen Added: 2005-07-10 %% Type: region Subtag: YT Description: Mayotte Added: 2005-07-10 %% Type: region Subtag: YU Description: Yugoslavia Added: 2005-07-10 Preferred-Value: CS Deprecated: 2003-07-23 %% Type: region Subtag: ZA Description: South Africa Added: 2005-07-10 %% Type: region Subtag: ZM Description: Zambia Added: 2005-07-10 Ewell Expires January 11, 2006 [Page 97] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: region Subtag: ZR Description: Zaire Added: 2005-07-10 Preferred-Value: CD Deprecated: 1997-07-14 %% Type: region Subtag: ZW Description: Zimbabwe Added: 2005-07-10 %% Type: region Subtag: ZZ Description: PRIVATE USE Added: 2005-07-10 %% Type: region Subtag: 001 Description: World Added: 2005-07-10 %% Type: region Subtag: 002 Description: Africa Added: 2005-07-10 %% Type: region Subtag: 005 Description: South America Added: 2005-07-10 %% Type: region Subtag: 009 Description: Oceania Added: 2005-07-10 %% Type: region Subtag: 011 Description: Western Africa Added: 2005-07-10 %% Type: region Subtag: 013 Description: Central America Added: 2005-07-10 %% Ewell Expires January 11, 2006 [Page 98] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: region Subtag: 014 Description: Eastern Africa Added: 2005-07-10 %% Type: region Subtag: 015 Description: Northern Africa Added: 2005-07-10 %% Type: region Subtag: 017 Description: Middle Africa Added: 2005-07-10 %% Type: region Subtag: 018 Description: Southern Africa Added: 2005-07-10 %% Type: region Subtag: 019 Description: Americas Added: 2005-07-10 %% Type: region Subtag: 021 Description: Northern America Added: 2005-07-10 %% Type: region Subtag: 029 Description: Caribbean Added: 2005-07-10 %% Type: region Subtag: 030 Description: Eastern Asia Added: 2005-07-10 %% Type: region Subtag: 034 Description: Southern Asia Added: 2005-07-10 %% Type: region Subtag: 035 Description: South-Eastern Asia Ewell Expires January 11, 2006 [Page 99] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-07-10 %% Type: region Subtag: 039 Description: Southern Europe Added: 2005-07-10 %% Type: region Subtag: 053 Description: Australia and New Zealand Added: 2005-07-10 %% Type: region Subtag: 054 Description: Melanesia Added: 2005-07-10 %% Type: region Subtag: 057 Description: Micronesia Added: 2005-07-10 %% Type: region Subtag: 061 Description: Polynesia Added: 2005-07-10 %% Type: region Subtag: 142 Description: Asia Added: 2005-07-10 %% Type: region Subtag: 143 Description: Central Asia Added: 2005-07-10 %% Type: region Subtag: 145 Description: Western Asia Added: 2005-07-10 %% Type: region Subtag: 150 Description: Europe Added: 2005-07-10 %% Type: region Ewell Expires January 11, 2006 [Page 100] =0C Internet-Draft Initial Language Subtag Registry July 2005 Subtag: 151 Description: Eastern Europe Added: 2005-07-10 %% Type: region Subtag: 154 Description: Northern Europe Added: 2005-07-10 %% Type: region Subtag: 155 Description: Western Europe Added: 2005-07-10 %% Type: region Subtag: 419 Description: Latin America and the Caribbean Added: 2005-07-10 %% Type: variant Subtag: 1901 Description: Traditional German orthography Added: 2005-07-10 Prefix: de %% Type: variant Subtag: 1996 Description: German orthography of 1996 Added: 2005-07-10 Prefix: de %% Type: variant Subtag: nedis Description: Natisone dialect Description: Nadiza dialect Added: 2005-07-10 Prefix: sl %% Type: variant Subtag: rozaj Description: Resian Description: Resianic Description: Rezijan Added: 2005-07-10 Prefix: sl %% Type: grandfathered Tag: art-lojban Ewell Expires January 11, 2006 [Page 101] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Lojban Added: 2001-11-11 Preferred-Value: jbo Deprecated: 2003-09-02 Comments: replaced by ISO code jbo %% Type: grandfathered Tag: cel-gaulish Description: Gaulish Added: 2001-05-25 %% Type: grandfathered Tag: en-boont Description: Boontling Added: 2003-02-14 %% Type: grandfathered Tag: en-GB-oed Description: English, Oxford English Dictionary spelling Added: 2003-07-09 %% Type: grandfathered Tag: en-scouse Description: Scouse Added: 2000-05-25 %% Type: grandfathered Tag: i-ami Description: 'Amis Added: 1999-05-25 %% Type: grandfathered Tag: i-bnn Description: Bunun Added: 1999-05-25 %% Type: grandfathered Tag: i-default Description: Default Language Added: 1998-03-10 %% Type: grandfathered Tag: i-enochian Description: Enochian Added: 2002-07-03 %% Type: grandfathered Tag: i-hak Ewell Expires January 11, 2006 [Page 102] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Hakka Added: 1999-01-31 Preferred-Value: zh-hakka Deprecated: 2000-01-10 %% Type: grandfathered Tag: i-klingon Description: Klingon Added: 1999-05-26 Preferred-Value: tlh Deprecated: 2004-02-24 Comments: replaced by ISO code tlh %% Type: grandfathered Tag: i-lux Description: Luxembourgish Added: 1997-09-19 Preferred-Value: lb Deprecated: 1998-09-09 Comments: replaced by ISO code lb %% Type: grandfathered Tag: i-mingo Description: Mingo Added: 1997-09-19 %% Type: grandfathered Tag: i-navajo Description: Navajo Added: 1997-09-19 Preferred-Value: nv Deprecated: 2000-02-18 Comments: replaced by ISO code nv %% Type: grandfathered Tag: i-pwn Description: Paiwan Added: 1999-05-25 %% Type: grandfathered Tag: i-tao Description: Tao Added: 1999-05-25 %% Type: grandfathered Tag: i-tay Description: Tayal Added: 1999-05-25 Ewell Expires January 11, 2006 [Page 103] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: grandfathered Tag: i-tsu Description: Tsou Added: 1999-05-25 %% Type: grandfathered Tag: no-bok Description: Norwegian Bokmal Added: 1995-08-23 Preferred-Value: nb Deprecated: 2000-02-18 Comments: replaced by ISO code nb %% Type: grandfathered Tag: no-nyn Description: Norwegian Nynorsk Added: 1995-08-23 Preferred-Value: nn Deprecated: 2000-02-18 Comments: replaced by ISO code nn %% Type: grandfathered Tag: sgn-BE-fr Description: Belgian-French Sign Language Added: 2001-11-11 %% Type: grandfathered Tag: sgn-BE-nl Description: Belgian-Flemish Sign Language Added: 2001-11-11 %% Type: grandfathered Tag: sgn-CH-de Description: Swiss German Sign Language Added: 2001-11-11 %% Type: grandfathered Tag: zh-gan Description: Kan or Gan Added: 1999-12-18 %% Type: grandfathered Tag: zh-guoyu Description: Mandarin or Standard Chinese Added: 1999-12-18 %% Type: grandfathered Ewell Expires January 11, 2006 [Page 104] =0C Internet-Draft Initial Language Subtag Registry July 2005 Tag: zh-hakka Description: Hakka Added: 1999-12-18 %% Type: grandfathered Tag: zh-min Description: Min, Fuzhou, Hokkien, Amoy, or Taiwanese Added: 1999-12-18 %% Type: grandfathered Tag: zh-min-nan Description: Minnan, Hokkien, Amoy, Taiwanese, Southern Min, Southern Fujian, Hoklo, Southern Fukien, Ho-lo Added: 2001-03-26 %% Type: grandfathered Tag: zh-wuu Description: Shanghaiese or Wu Added: 1999-12-18 %% Type: grandfathered Tag: zh-xiang Description: Xiang or Hunanese Added: 1999-12-18 %% Type: grandfathered Tag: zh-yue Description: Cantonese Added: 1999-12-18 %% Type: redundant Tag: az-Arab Description: Azerbaijani in Arabic script Added: 2003-05-30 %% Type: redundant Tag: az-Cyrl Description: Azerbaijani in Cyrillic script Added: 2003-05-30 %% Type: redundant Tag: az-Latn Description: Azerbaijani in Latin script Added: 2003-05-30 %% Type: redundant Tag: be-Latn Description: Belarusian in Latin script Ewell Expires January 11, 2006 [Page 105] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-01-06 %% Type: redundant Tag: bs-Cyrl Description: Bosnian in Cyrillic script Added: 2005-02-17 %% Type: redundant Tag: bs-Latn Description: Bosnian in Latin script Added: 2005-02-17 %% Type: redundant Tag: de-1901 Description: German, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-1996 Description: German, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: de-AT-1901 Description: German, Austrian variant, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-AT-1996 Description: German, Austrian variant, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: de-CH-1901 Description: German, Swiss variant, traditional orthography Added: 2001-07-17 %% Type: redundant Tag: de-CH-1996 Description: German, Swiss variant, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: de-DE-1901 Description: German, German variant, traditional orthography Added: 2001-07-17 %% Type: redundant Ewell Expires January 11, 2006 [Page 106] =0C Internet-Draft Initial Language Subtag Registry July 2005 Tag: de-DE-1996 Description: German, German variant, orthography of 1996 Added: 2001-07-17 %% Type: redundant Tag: iu-Cans Description: Inuktitut in Canadian Aboriginal Syllabic script Added: 2005-02-17 %% Type: redundant Tag: iu-Latn Description: Inuktitut in Latin script Added: 2005-02-17 %% Type: redundant Tag: mn-Cyrl Description: Mongolian in Cyrillic script Added: 2005-02-17 %% Type: redundant Tag: mn-Mong Description: Mongolian in Mongolian script Added: 2005-02-17 %% Type: redundant Tag: sgn-BR Description: Brazilian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-CO Description: Colombian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-DE Description: German Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-DK Description: Danish Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-ES Description: Spanish Sign Language Added: 2001-11-11 Ewell Expires January 11, 2006 [Page 107] =0C Internet-Draft Initial Language Subtag Registry July 2005 %% Type: redundant Tag: sgn-FR Description: French Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-GB Description: British Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-GR Description: Greek Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-IE Description: Irish Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-IT Description: Italian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-JP Description: Japanese Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-MX Description: Mexican Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-NI Description: Nicaraguan Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-NL Description: Dutch Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-NO Ewell Expires January 11, 2006 [Page 108] =0C Internet-Draft Initial Language Subtag Registry July 2005 Description: Norwegian Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-PT Description: Portuguese Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-SE Description: Swedish Sign Language Added: 2001-11-11 %% Type: redundant Tag: sgn-US Description: American Sign Language Added: 2001-03-02 %% Type: redundant Tag: sgn-ZA Description: South African Sign Language Added: 2001-11-11 %% Type: redundant Tag: sl-nedis Description: Natisone dialect, Nadiza dialect Added: 2004-06-01 %% Type: redundant Tag: sl-rozaj Description: Resian, Resianic, Rezijan Added: 2003-10-09 %% Type: redundant Tag: sr-Cyrl Description: Serbian in Cyrillic script Added: 2003-05-30 %% Type: redundant Tag: sr-Latn Description: Serbian in Latin script Added: 2003-05-30 %% Type: redundant Tag: tg-Arab Description: Tajik in Arabic script Added: 2005-02-17 %% Ewell Expires January 11, 2006 [Page 109] =0C Internet-Draft Initial Language Subtag Registry July 2005 Type: redundant Tag: tg-Cyrl Description: Tajik in Cyrillic script Added: 2005-02-17 %% Type: redundant Tag: uz-Cyrl Description: Uzbek in Cyrillic script Added: 2003-05-30 %% Type: redundant Tag: uz-Latn Description: Uzbek in Latin script Added: 2003-05-30 %% Type: redundant Tag: yi-latn Description: Yiddish, in Latin script Added: 2003-01-07 %% Type: redundant Tag: zh-Hans Description: simplified Chinese Added: 2003-05-30 %% Type: redundant Tag: zh-Hans-CN Description: PRC Mainland Chinese in simplified script Added: 2005-04-13 %% Type: redundant Tag: zh-Hans-HK Description: Hong Kong Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hans-MO Description: Macao Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hans-SG Description: Singapore Chinese in simplified script Added: 2005-04-11 %% Type: redundant Tag: zh-Hans-TW Description: Taiwan Chinese in simplified script Ewell Expires January 11, 2006 [Page 110] =0C Internet-Draft Initial Language Subtag Registry July 2005 Added: 2005-04-11 %% Type: redundant Tag: zh-Hant Description: traditional Chinese Added: 2003-05-30 %% Type: redundant Tag: zh-Hant-CN Description: PRC Mainland Chinese in traditional script Added: 2005-04-13 %% Type: redundant Tag: zh-Hant-HK Description: Hong Kong Chinese in traditional script Added: 2005-04-11 %% Type: redundant Tag: zh-Hant-MO Description: Macao Chinese in traditional script Added: 2005-04-11 %% Type: redundant Tag: zh-Hant-SG Description: Singapore Chinese in traditional script Added: 2005-04-11 %% Type: redundant Tag: zh-Hant-TW Description: Taiwan Chinese in traditional script Added: 2005-04-11 Ewell Expires January 11, 2006 [Page 111] =0C Internet-Draft Initial Language Subtag Registry July 2005 4. Omitted Code Elements The following code elements from [UN-M.49] were not assigned as subtags in the initial Language Subtag Registry, but are valid candidates for registration as region subtags, using the process in [I-D.ietf-ltru-registry]: 830 Channel Islands 831 Guernsey 832 Jersey 833 Isle of Man Ewell Expires January 11, 2006 [Page 112] =0C Internet-Draft Initial Language Subtag Registry July 2005 5. Security Considerations This document specifies the initial contents to be used by IANA in populating the Language Subtag Registry. For security considerations relevant to that registry and the use of language tags, see [I-D.ietf-ltru-registry]. Ewell Expires January 11, 2006 [Page 113] =0C Internet-Draft Initial Language Subtag Registry July 2005 6. IANA Considerations This document provides the initial content for the Language Subtag Registry to be maintained by IANA. For details on the procedures for the format and ongoing maintenance of this registry, see [I-D.ietf- ltru-registry]. Ewell Expires January 11, 2006 [Page 114] =0C Internet-Draft Initial Language Subtag Registry July 2005 7. References 7.1 Normative References [I-D.ietf-ltru-registry] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", June 2005. 7.2 Informative References [ISO15924] ISO TC46/WG3, "ISO 15924:2003 (E/F) - Codes for the representation of names of scripts", January 2004. [ISO3166-1] International Organization for Standardization, "ISO 3166- 1:1988 - Codes for the representation of names of countries, 3rd edition", August 1988. [ISO639-1] International Organization for Standardization, "ISO 639- 1:2002 - Codes for the representation of names of languages - Part 1: Alpha-2 code", 2002. [ISO639-2] International Organization for Standardization, "ISO 639- 2:1998 - Codes for the representation of names of languages - Part 2: Alpha-3 code - edition 1", August 1988. [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [UN-M.49] United Nations Statistical Division, "Standard Country or Area Codes for Statistical Use", June 1999. [record-jar] Raymond, E., "The Art of Unix Programming", 2003. Ewell Expires January 11, 2006 [Page 115] =0C Internet-Draft Initial Language Subtag Registry July 2005 Author's Address Doug Ewell (editor) Email: dewell@adelphia.net URI: http://users.adelphia.net/~dewell Ewell Expires January 11, 2006 [Page 116] =0C Internet-Draft Initial Language Subtag Registry July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Ewell Expires January 11, 2006 [Page 117] =0C ------=_NextPart_000_0039_01C585B1.6EF54300 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_000_0039_01C585B1.6EF54300-- From ltru-bounces@lists.ietf.org Mon Jul 11 03:47:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drt0a-0006aH-Pu; Mon, 11 Jul 2005 03:47:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drt0a-0006Zk-6o for ltru@megatron.ietf.org; Mon, 11 Jul 2005 03:47:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19548 for ; Mon, 11 Jul 2005 03:47:17 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrtSX-0001fa-AK for ltru@ietf.org; Mon, 11 Jul 2005 04:16:13 -0400 Received: from h-68-166-38-110.snvacaid.dynamic.covad.net ([68.166.38.110] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Drt0X-0002G7-00 for ltru@ietf.org; Mon, 11 Jul 2005 03:47:17 -0400 Message-ID: <001001c585ed$5b049ee0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Mon, 11 Jul 2005 00:51: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: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ltru] Start of working group last call on initial registry and registry drafts X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - Now that we've wrapped up the last open issue (#1026), Martin and I have asked the editors to submit updated versions of the registry draft and the initial registry i-d. This will be a two-week working group last call, calculated from when the i-d availability annoucement goes out. Any issues raised from now on will be handled as last-call issues. As such, we request that you be especially clear in identifying the specific passage(s) that you find problematic, and, if possible, that you describe what you would change to address the problem, ideally by supplying replacement text. PLEASE take the the time to read these two documents. I expect they will be http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.txt and http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt; as always, the official announcement of i-d availability will be cc-ed to this mailing list, and will have the actual URLs of the drafts. We are not just interested in problems. We would like to hear from *everyone* who reads either document, even if it's just "I read it." Martin Duerst and Randy Presuhn, Ltru co-chairs _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 11 04:08:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrtL4-0002WQ-RN; Mon, 11 Jul 2005 04:08:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrtL2-0002WA-Tu for ltru@megatron.ietf.org; Mon, 11 Jul 2005 04:08:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20638 for ; Mon, 11 Jul 2005 04:08:26 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drtmz-0002Xs-6j for ltru@ietf.org; Mon, 11 Jul 2005 04:37:22 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6B88DI06985; Mon, 11 Jul 2005 17:08:13 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 9125ce50_f1e4_11d9_80c7_0030482532aa_28630; Mon, 11 Jul 2005 17:19:57 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO007C24; 11 Jul 05 17:13:43 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 11 Jul 05 17:13:35 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG007C1F; 11 Jul 05 17:13:29 +0900 Message-Id: <6.0.0.20.2.20050711101532.06f9ab50@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 11 Jul 2005 10:17:32 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: editorial nits in initial registry draft -01 In-Reply-To: <000601c58584$90ca9520$030aa8c0@DEWELL> References: <634978A7DF025A40BFEF33EB191E13BC0C108BE8@irvmbxw01.quest.com> <000601c58584$90ca9520$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Are we actually going to publish the -initial draft as an RFC? I seem to remember that at one point, the idea was to not do that, because by the time the RFC would be published, it would already be out of date. In that scenario, we planned to move -initial through (WG and IETF) last call and IESG approval, but then go directly to IANA and no further in the RFC process. If I'm out of sync here, I'm sorry. Regards, Martin. At 04:21 05/07/11, Doug Ewell wrote: >Addison Phillips wrote: > >> Why not say: >> >> "This memo defines the initial contents of the Language Subtag >> Registry for use in forming tags for the identification of languages." >> >> The introduction can say where draft-registry is at and all that. > >Why not, indeed? Makes sense to me. I made that change, and in case of dispute. > >-- >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 Jul 11 04:08:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrtL5-0002Wl-6j; Mon, 11 Jul 2005 04:08:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrtL2-0002WE-Uy for ltru@megatron.ietf.org; Mon, 11 Jul 2005 04:08:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20641 for ; Mon, 11 Jul 2005 04:08:27 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drtmz-0002Xt-6k for ltru@ietf.org; Mon, 11 Jul 2005 04:37:23 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6B88CC22411; Mon, 11 Jul 2005 17:08:12 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 909773c6_f1e4_11d9_80c7_0030482532aa_28630; Mon, 11 Jul 2005 17:19:56 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO007C23; 11 Jul 05 17:13:42 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 11 Jul 05 17:13:35 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG007C1E; 11 Jul 05 17:13:27 +0900 Message-Id: <6.0.0.20.2.20050711101316.06f99300@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 11 Jul 2005 10:14:21 +0900 To: r&d afrac , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: status? last call? [small correction] In-Reply-To: <6.0.0.20.2.20050710172451.075d30a0@itmail.it.aoyama.ac.jp> References: <20050708202214.FJXR27419.mta2.adelphia.net@megatron.ietf.org> <007901c58450$44398e80$030aa8c0@DEWELL> <6.2.1.2.2.20050709144837.0398f9f0@mail.afrac.org> <6.0.0.20.2.20050710172451.075d30a0@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 At 17:30 05/07/10, Martin Duerst wrote: >[chair hat off] > >At 22:54 05/07/09, r&d afrac wrote: > > >This, I believe, describes perfectly why the Draft doctrine adds to the basic error of RFC 3066 attenuated by its lose application (that IETF has the capacity to correlate non protocol parameters). Jon Postel had clearly established it: this is none of the IANA business. Not only it seems that cultural empowerment is ignored by the author of this text. But, since the topic here is ISO 3166, it shows a remakable confusion between Senegal and Zimbabwe which precisely document my point and the difficulty to establish general rules in a world made of particulars. > >I don't see why RFC 1766, RFC 3066, and RFC 3066 would ignore cultural empowerment. >After all, these specs allow for people (anybody with an email account!) to apply >for a registration. This is much more flexible than ISO process (which fortunately >has become somewhat more flexible recently). Sorry, a small correction. In the first line of my paragraph, it should read "RFC 1766, RFC3066, and RFC 3066bis". Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 11 05:29:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drubc-0002TP-GM; Mon, 11 Jul 2005 05: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 1Drubb-0002TK-1H for ltru@megatron.ietf.org; Mon, 11 Jul 2005 05:29: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 FAA25106 for ; Mon, 11 Jul 2005 05:29:35 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DrubU-00035k-1u for ltru@lists.ietf.org; Mon, 11 Jul 2005 11:29:32 +0200 Received: from 62.80.58.60 ([62.80.58.60]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Jul 2005 11:29:32 +0200 Received: from nobody by 62.80.58.60 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 11 Jul 2005 11:29:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 11 Jul 2005 11:27:16 +0200 Organization: Lines: 59 Message-ID: <42D23B74.4233@xyzzy.claranet.de> References: <003c01c585ec$1c1d8580$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: 62.80.58.60 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Submission: LTRU initial-registry draft-02 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > "draft-ietf-ltru-initial-02", in text format. | 3. UN numeric code elements assigned to "macro-geographical | (continental)" as of the date of adoption of [...] Just to prove that I've read it, maybe s/as of/regions as of/ In point six you say "These code elements are listed in Section 4, indicating that they are valid for registration" etc. This part belongs to your point five. Section 4 does not contain any "withdrawn, vacated, deprecated, or otherwise judged by the LTRU working group as questionable" items. Actually there were no items "judged as questionable" - you just followed the rules skipping all deprecated items. New wording: 5. The UN numeric code elements for countries or areas not associated with an assigned [ISO3166-1] alpha-2 code element were not added to the ILSR. These values + are listed in Section 4 and may be requested for registration by individuals using the process defined in [I-D.ietf-ltru-registry] and according to the rules described therein. + Listing of these code elements in this section is not a + guarantee of future registration. 6. Items withdrawn, vacated, deprecated, + or modified - modified, or otherwise judged by the LTRU working group - to be questionable were not added to the ILSR. - These code elements are listed in Section 4, indicating - that they are valid for registration using the process in - [I-D.ietf-ltru-registry] but were not included initially. - Listing of these code elements in this section is not a - guarantee of future registration. Otherwise that I-D should be ready - I didn't check all tags again assuming that you'd tell us if you did something more interesting than replacing some dates by 2005-07-10. All references are in fact referenced. No copyright problems, "not a mirror" is nice . No 2119 keywords. Longest line length 72. Exactly two folded lines, both okay: Description: Interlingua (International Auxiliary Language Association) Description: Minnan, Hokkien, Amoy, Taiwanese, Southern Min, Southern Fujian, Hoklo, Southern Fukien, Ho-lo No problems found, and now I don't want to hear 830, 831, 832, or 833 again for the rest of this year (sorry GG, IM, JE, we really did our best, please talk with your Duke). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 11 06:00:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drv5P-00087p-9w; Mon, 11 Jul 2005 06:00:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drv5O-00087F-3e for ltru@megatron.ietf.org; Mon, 11 Jul 2005 06:00:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26406 for ; Mon, 11 Jul 2005 06:00:19 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DrvXI-0006v9-5M for ltru@ietf.org; Mon, 11 Jul 2005 06:29:16 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Mon, 11 Jul 2005 10:42:04 +0100 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jul 2005 10:42:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Private Use Tags Date: Mon, 11 Jul 2005 10:42:02 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A2121A59CD@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Private Use Tags Thread-Index: AcWDDs5kNXFvOc/NRnOx2uAMv8Mf/gAAYrZwALoLD/A= From: "L.Gillam" To: petercon , ltru X-OriginalArrivalTime: 11 Jul 2005 09:42:02.0103 (UTC) FILETIME=[CA3AC870:01C585FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 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="===============1818609497==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1818609497== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C585FC.CA2FD8F5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C585FC.CA2FD8F5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Peter, =20 In the neutral corner, if there is such a thing, the distinction may not = be so clear for people whose reasoning goes that both use language codes = and country codes, and excluding differences in separator use they look = identical. As you identify, it is the intention of the combination that = differs. Some, who might process such metadata items into their = components may wonder how there can be a difference between "en" in one = context and "en" in another context. And this is something that a = certain section, I can't recall which, in WD 639-4, doesn't cover - it = just shows that various combinations are valid. Something to be looked = at in August no doubt. =20 In addition, I may have interpreted something from another contributor = to this list that may appear obvious to those involved, but may be less = than crystal clear to some new users - that currently the "registry" = uses codes for the representation of the "names" of languages, combines = them with codes for the "names" of countries, and creates a new semantic = around these such that the names can now used as identifiers for (some = fragment of) linguistic content. Nothing unusual in human activity, but = these differences in expectation for some as alluded to in the previous = paragraph, may be the cause of some misunderstandings as seen on this = list. =20 I don't claim to know what Sun do, but they may be combining a currency = value with a locale to identify "common" items that can be associated to = some locales but not generally others. It's a guess, but again you'd = need to know what their intention was in making such combinations.=20 =20 Such discussions, perhaps, help to draw these "shared" understandings = out into the open. Pointers to prior discussions of this nature may also = be of some use. ________________________________ From: ltru-bounces@lists.ietf.org on behalf of Peter Constable Sent: Thu 07/07/2005 17:36 To: ltru Subject: RE: [Ltru] Private Use Tags > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Dylan N. Pierce > It is, in fact, the locale ID. But it would be disingenuous to present > that distinction as a significant difference. Effectively, the locale ID > /is/ a language ID "plus." True, insofar as every locale has language as one of its constituent properties. But I believe (as others here have heard me say) that there is a definite difference. A language tag is a metadata element used to declare attributes of content wrt language variety and written form, or to request content according to those attributes; a locale ID is an API parameter used to tailor software processes, or to tag resources used to tailor those processes, wrt a variety of cultural parameters, some of which pertain to language but others of which do not. Very often, the information in a language tag is sufficient for use as a locale ID, but not in the general case. > According to Sun's own documentation, "The language argument is a valid > ISO Language Code. These codes are the lower-case, two-letter codes as > defined by ISO-639.... The country argument is a valid ISO Country > Code. These codes are the upper-case, two-letter codes as defined by > ISO-3166." And its purpose is so that applications can decide in what > language to serve the documents (in this case, UI output). I haven't reviewed their implementation or documentation, but something doesn't make sense here: if the purpose of these IDs is only to select UI strings, then I wouldn't expect these IDs would ever need to include a component for currency. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru ------_=_NextPart_001_01C585FC.CA2FD8F5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [Ltru] Private Use Tags=0A= =0A= =0A=
=0A=
 
=0A=
Peter,
=0A=
 
=0A=
In the neutral corner, if = there is such a =0A= thing, the distinction may not be so clear for people whose reasoning = goes that =0A= both use language codes and country codes, and = excluding differences in =0A= separator use they look identical. As you identify, it is the intention = of the =0A= combination that differs. Some, who might process such metadata items = into their =0A= components may wonder how there can be a difference between "en" in one = context =0A= and "en" in another context. And this is something that a certain = section, I =0A= can't recall which, in WD 639-4, doesn't cover - it just shows that = various =0A= combinations are valid. Something to be looked at in August no =0A= doubt.
=0A=
 
=0A=
In addition, I may = have interpreted =0A= something from another contributor to this list that may appear obvious = to those =0A= involved, but may be less than crystal clear to some new users = - that =0A= currently the "registry" uses codes for the representation of the = "names" of =0A= languages, combines them with codes for the "names" of countries, and = creates a =0A= new semantic around these such that the names can now used as = identifiers for =0A= (some fragment of) linguistic content. Nothing unusual in human = activity, but =0A= these differences in expectation for some as alluded to in the previous =0A= paragraph, may be the cause of some misunderstandings as seen on this =0A= list.
=0A=
 
=0A=
I don't claim to know what = Sun do, but they =0A= may be combining a currency value with a locale to identify "common" = items that =0A= can be associated to some locales but not generally others. It's a = guess, =0A= but again you'd need to know what their intention was in making such =0A= combinations.
=0A=
 
=0A=
Such discussions, perhaps, = help to draw =0A= these "shared" understandings out into the open. Pointers to prior = discussions =0A= of this nature may also be of some use.
=0A=
=0A=
=0A=
=0A=
From: = ltru-bounces@lists.ietf.org =0A= on behalf of Peter Constable
Sent: Thu 07/07/2005 = 17:36
To: =0A= ltru
Subject: RE: [Ltru] Private Use = Tags

=0A=
=0A=

> From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.iet= f.org]
On =0A= Behalf Of
> Dylan N. Pierce


> It is, in fact, the = locale ID. =0A= But it would be disingenuous to present
> that distinction as a =0A= significant difference. Effectively, the locale
ID
> /is/ a = language ID =0A= "plus."

True, insofar as every locale has language as one of its =0A= constituent
properties. But I believe (as others here have heard me = say) that =0A= there
is a definite difference. A language tag is a metadata element = used =0A= to
declare attributes of content wrt language variety and written = form, =0A= or
to request content according to those attributes; a locale ID is = an =0A= API
parameter used to tailor software processes, or to tag resources = used =0A= to
tailor those processes, wrt a variety of cultural parameters, some =0A= of
which pertain to language but others of which do not. Very often, =0A= the
information in a language tag is sufficient for use as a locale = ID, =0A= but
not in the general case.


> According to Sun's own =0A= documentation, "The language argument is a
valid
> ISO Language = Code. =0A= These codes are the lower-case, two-letter codes as
> defined by =0A= ISO-639....  The country argument is a valid ISO Country
> = Code. =0A= These codes are the upper-case, two-letter codes as defined by
> =0A= ISO-3166." And its purpose is so that applications can decide in = what
> =0A= language to serve the documents (in this case, UI output).

I = haven't =0A= reviewed their implementation or documentation, but something
doesn't = make =0A= sense here: if the purpose of these IDs is only to select
UI strings, = then I =0A= wouldn't expect these IDs would ever need to include
a component for =0A= currency.

Peter =0A= Constable

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

=0A= =0A= =0A= ------_=_NextPart_001_01C585FC.CA2FD8F5-- --===============1818609497== 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 --===============1818609497==-- From ltru-bounces@lists.ietf.org Mon Jul 11 13:37:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds2DU-0004a3-1Z; Mon, 11 Jul 2005 13: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 1Ds2DP-0004Zr-CH for ltru@megatron.ietf.org; Mon, 11 Jul 2005 13:37:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03830 for ; Mon, 11 Jul 2005 13:37: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.43) id 1Ds2fN-0001Bh-Fg for ltru@ietf.org; Mon, 11 Jul 2005 14:06:07 -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 Jul 2005 10:36:46 -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: Finishing off #1026 Date: Mon, 11 Jul 2005 10:36:46 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C108E6D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Finishing off #1026 Thread-Index: AcWFygzCE9QaHy/wT/OZR7GF6Ii0swAdGAbg From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 11 Jul 2005 17:36:46.0928 (UTC) FILETIME=[1C822500:01C5863F] X-Spam-Score: 0.2 (/) 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 I don't like the suggested edit. Instead I wordsmithed the paragraph = thusly: UN M.49 has codes for both countries and areas (such as '276' for = Germany) and geographical regions and sub-regions (such as '150' for = Europe). UN M.49 country or area codes for which there is no = corresponding ISO 3166 code SHOULD NOT be registered, except as a = surrogate for an ISO 3166 code that is blocked from registration by an = existing subtag. If such a code becomes necessary, then the registration = authority for ISO 3166 SHOULD first be petitioned to assign a code to = the region. If the petition for a code assignment by ISO 3166 is refused or not acted on in a timely manner, the registration process described = in MAY then be used to = register the corresponding UN M.49 code. At the time this document was = written, there were only four such codes: 830 (Channel Islands), 831 = (Guernsey), 832 (Jersey), and 833 (Isle of Man). This way UN M.49 codes = remain available as the value of last resort in cases where ISO 3166 = reassigns a deprecated value in the registry. 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?7?10? 20:36 > To: ltru@ietf.org > Subject: [Ltru] Re: Finishing off #1026 >=20 > Addison Phillips wrote: >=20 > >| registration authority for ISO 3166 SHOULD be petitioned to > >| assign a code: >=20 > Please insert between "code:" and "such", s/such/Such/ >=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 Mon Jul 11 13:56:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds2Vd-0000kz-3u; Mon, 11 Jul 2005 13:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds2VY-0000iu-V9; Mon, 11 Jul 2005 13:55:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05030; Mon, 11 Jul 2005 13:55: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.43) id 1Ds2x9-0001qN-5N; Mon, 11 Jul 2005 14:24: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, 11 Jul 2005 10:55:16 -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_01C58641.B135400C" Date: Mon, 11 Jul 2005 10:55:15 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C108E8C@irvmbxw01.quest.com> X-MS-Has-Attach: yes Thread-Topic: Submission: draft-09 of ltru-registry Thread-Index: AcWGQaxE4qUzrF+yQEKj2Hh2MiusiQ== From: "Addison Phillips" To: X-OriginalArrivalTime: 11 Jul 2005 17:55:16.0092 (UTC) FILETIME=[B19F23C0:01C58641] X-Spam-Score: 0.0 (/) X-Scan-Signature: df14bcb7b5bf82cff4f7efcddc72c1c6 Cc: ltru@ietf.org Subject: [Ltru] Submission: draft-09 of ltru-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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C58641.B135400C Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBFZGl0b3IsDQoNClBsZWFzZSBmaW5kIGF0dGFjaGVkIGRyYWZ0LTA5IG9mIGRyYWZ0LWll dGYtbHRydS1yZWdpc3RyeS4NCg0KRm9yIHRoZSBlZGl0b3JzLA0KDQpBZGRpc29uDQoNCkFkZGlz b24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0K aHR0cDovL3d3dy5xdWVzdC5jb20NCg0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBD b3JlIFdvcmtpbmcgR3JvdXANCmh0dHA6Ly93d3cudzMub3JnL0ludGVybmF0aW9uYWwNCg0KSW50 ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVy ZS4gDQoNCg== ------_=_NextPart_001_01C58641.B135400C Content-Type: text/plain; name="draft-ietf-ltru-registry-09.txt" Content-Description: draft-ietf-ltru-registry-09.txt Content-Disposition: attachment; filename="draft-ietf-ltru-registry-09.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBLiBQaGlsbGlwcywgRWQuDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUXVlc3QgU29mdHdhcmUNCkV4cGlyZXM6IEphbnVhcnkg MTIsIDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gRGF2aXMsIEVkLg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgSUJNDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEp1bHkgMTEsIDIwMDUNCg0KDQogICAgICAgICAgICAgICAgICAg ICBUYWdzIGZvciBJZGVudGlmeWluZyBMYW5ndWFnZXMNCiAgICAgICAgICAgICAgICAgICAgICBk cmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMDkNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBC eSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMg dGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hp Y2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQs IGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdpbGwgYmUgZGlz Y2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NCg0KICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5l ZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBn cm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhl ciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt IG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJy ZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQt RHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4 cGlyZSBvbiBKYW51YXJ5IDEyLCAyMDA2Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHly aWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLg0KDQpBYnN0cmFjdA0KDQogICBU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgc3RydWN0dXJlLCBjb250ZW50LCBjb25zdHJ1Y3Rp b24sIGFuZA0KICAgc2VtYW50aWNzIG9mIGxhbmd1YWdlIHRhZ3MgZm9yIHVzZSBpbiBjYXNlcyB3 aGVyZSBpdCBpcyBkZXNpcmFibGUgdG8NCiAgIGluZGljYXRlIHRoZSBsYW5ndWFnZSB1c2VkIGlu IGFuIGluZm9ybWF0aW9uIG9iamVjdC4gIEl0IGFsc28NCiAgIGRlc2NyaWJlcyBob3cgdG8gcmVn aXN0ZXIgdmFsdWVzIGZvciB1c2UgaW4gbGFuZ3VhZ2UgdGFncyBhbmQgdGhlDQogICBjcmVhdGlv biBvZiB1c2VyIGRlZmluZWQgZXh0ZW5zaW9ucyBmb3IgcHJpdmF0ZSBpbnRlcmNoYW5nZS4NCg0K DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDYg ICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNClRhYmxlIG9m IENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMi4gIFRoZSBMYW5ndWFnZSBUYWcgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAgIDIuMSAg IFN5bnRheCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDQNCiAgICAgMi4yICAgTGFuZ3VhZ2UgU3VidGFnIFNvdXJjZXMgYW5kIEludGVycHJldGF0 aW9uIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgICAgIDIuMi4xICAgUHJpbWFyeSBMYW5ndWFnZSBT dWJ0YWcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICAgICAgMi4yLjIgICBF eHRlbmRlZCBMYW5ndWFnZSBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkN CiAgICAgICAyLjIuMyAgIFNjcmlwdCBTdWJ0YWcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxMA0KICAgICAgIDIuMi40ICAgUmVnaW9uIFN1YnRhZyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQogICAgICAgMi4yLjUgICBWYXJpYW50 IFN1YnRhZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAgICAg ICAyLjIuNiAgIEV4dGVuc2lvbiBTdWJ0YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxNA0KICAgICAgIDIuMi43ICAgUHJpdmF0ZSBVc2UgU3VidGFncyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1DQogICAgICAgMi4yLjggICBQcmUtRXhpc3Rpbmcg UkZDIDMwNjYgUmVnaXN0cmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gMTYNCiAgICAgICAyLjIu OSAgIENsYXNzZXMgb2YgQ29uZm9ybWFuY2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxNg0KICAgMy4gIFJlZ2lzdHJ5IEZvcm1hdCBhbmQgTWFpbnRlbmFuY2UgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDE4DQogICAgIDMuMSAgIEZvcm1hdCBvZiB0aGUgSUFOQSBMYW5n dWFnZSBTdWJ0YWcgUmVnaXN0cnkgIC4gLiAuIC4gLiAuIC4gMTgNCiAgICAgMy4yICAgTWFpbnRl bmFuY2Ugb2YgdGhlIFJlZ2lzdHJ5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMw0K ICAgICAzLjMgICBTdGFiaWxpdHkgb2YgSUFOQSBSZWdpc3RyeSBFbnRyaWVzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDI1DQogICAgIDMuNCAgIFJlZ2lzdHJhdGlvbiBQcm9jZWR1cmUgZm9yIFN1 YnRhZ3MgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjgNCiAgICAgMy41ICAgUG9zc2liaWxpdGll cyBmb3IgUmVnaXN0cmF0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzMQ0KICAgICAz LjYgICBFeHRlbnNpb25zIGFuZCBFeHRlbnNpb25zIE5hbWVzcGFjZSAgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDMzDQogICAgIDMuNyAgIEluaXRpYWxpemF0aW9uIG9mIHRoZSBSZWdpc3RyeSAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMzYNCiAgIDQuICBGb3JtYXRpb24gYW5kIFByb2Nlc3Np bmcgb2YgTGFuZ3VhZ2UgVGFncyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAzNw0KICAgICA0LjEgICBD aG9pY2Ugb2YgTGFuZ3VhZ2UgVGFnIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDM3DQogICAgIDQuMiAgIE1lYW5pbmcgb2YgdGhlIExhbmd1YWdlIFRhZyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMzkNCiAgICAgNC4zICAgTGVuZ3RoIENvbnNpZGVyYXRpb25zICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0MA0KICAgICAgIDQuMy4xICAgV29y a2luZyB3aXRoIExpbWl0ZWQgQnVmZmVyIFNpemVzICAuIC4gLiAuIC4gLiAuIC4gLiAuIDQwDQog ICAgICAgNC4zLjIgICBUcnVuY2F0aW9uIG9mIExhbmd1YWdlIFRhZ3MgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gNDINCiAgICAgNC40ICAgQ2Fub25pY2FsaXphdGlvbiBvZiBMYW5ndWFnZSBU YWdzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Mg0KICAgICA0LjUgICBDb25zaWRlcmF0aW9u cyBmb3IgUHJpdmF0ZSBVc2UgU3VidGFncyAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ0DQogICA1LiAg SUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gNDYNCiAgICAgNS4xICAgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0Ng0KICAgICA1LjIgICBFeHRlbnNpb25zIFJlZ2lzdHJ5 ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ3DQogICA2LiAgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g NDgNCiAgIDcuICBDaGFyYWN0ZXIgU2V0IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiA0OQ0KICAgOC4gIENoYW5nZXMgZnJvbSBSRkMgMzA2NiAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUwDQogICA5LiAgUmVmZXJlbmNlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTQNCiAg ICAgOS4xICAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA1NA0KICAgICA5LjIgICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU1DQogICAgICAgQXV0aG9ycycgQWRkcmVzc2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTYNCiAgIEEuICBB Y2tub3dsZWRnZW1lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA1Nw0KICAgQi4gIEV4YW1wbGVzIG9mIExhbmd1YWdlIFRhZ3MgKEluZm9ybWF0aXZlKSAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU4DQogICAgICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFu ZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gNjENCg0KDQoNCg0KDQoNCg0K UGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAgICAg ICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3Mt cmVnaXN0cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQoxLiAgSW50cm9kdWN0aW9u DQoNCiAgIEh1bWFuIGJlaW5ncyBvbiBvdXIgcGxhbmV0IGhhdmUsIHBhc3QgYW5kIHByZXNlbnQs IHVzZWQgYSBudW1iZXIgb2YNCiAgIGxhbmd1YWdlcy4gIFRoZXJlIGFyZSBtYW55IHJlYXNvbnMg d2h5IG9uZSB3b3VsZCB3YW50IHRvIGlkZW50aWZ5IHRoZQ0KICAgbGFuZ3VhZ2UgdXNlZCB3aGVu IHByZXNlbnRpbmcgb3IgcmVxdWVzdGluZyBpbmZvcm1hdGlvbi4NCg0KICAgVXNlcidzIGxhbmd1 YWdlIHByZWZlcmVuY2VzIG9mdGVuIG5lZWQgdG8gYmUgaWRlbnRpZmllZCBzbyB0aGF0DQogICBh cHByb3ByaWF0ZSBwcm9jZXNzaW5nIGNhbiBiZSBhcHBsaWVkLiAgRm9yIGV4YW1wbGUsIHRoZSB1 c2VyJ3MNCiAgIGxhbmd1YWdlIHByZWZlcmVuY2VzIGluIGEgV2ViIGJyb3dzZXIgY2FuIGJlIHVz ZWQgdG8gc2VsZWN0IFdlYiBwYWdlcw0KICAgYXBwcm9wcmlhdGVseS4gIExhbmd1YWdlIHByZWZl cmVuY2VzIGNhbiBhbHNvIGJlIHVzZWQgdG8gc2VsZWN0IGFtb25nDQogICB0b29scyAoc3VjaCBh cyBkaWN0aW9uYXJpZXMpIHRvIGFzc2lzdCBpbiB0aGUgcHJvY2Vzc2luZyBvcg0KICAgdW5kZXJz dGFuZGluZyBvZiBjb250ZW50IGluIGRpZmZlcmVudCBsYW5ndWFnZXMuDQoNCiAgIEluIGFkZGl0 aW9uLCBrbm93bGVkZ2UgYWJvdXQgdGhlIHBhcnRpY3VsYXIgbGFuZ3VhZ2UgdXNlZCBieSBzb21l DQogICBwaWVjZSBvZiBpbmZvcm1hdGlvbiBjb250ZW50IG1pZ2h0IGJlIHVzZWZ1bCBvciBldmVu IHJlcXVpcmVkIGJ5IHNvbWUNCiAgIHR5cGVzIG9mIHByb2Nlc3Npbmc7IGZvciBleGFtcGxlIHNw ZWxsLWNoZWNraW5nLCBjb21wdXRlci1zeW50aGVzaXplZA0KICAgc3BlZWNoLCBCcmFpbGxlIHRy YW5zY3JpcHRpb24sIG9yIGhpZ2gtcXVhbGl0eSBwcmludCByZW5kZXJpbmdzLg0KDQogICBPbmUg bWVhbnMgb2YgaW5kaWNhdGluZyB0aGUgbGFuZ3VhZ2UgdXNlZCBpcyBieSBsYWJlbGluZyB0aGUN CiAgIGluZm9ybWF0aW9uIGNvbnRlbnQgd2l0aCBhbiBpZGVudGlmaWVyIG9yICJ0YWciLiAgVGhl c2UgdGFncyBjYW4gYmUNCiAgIHVzZWQgdG8gc3BlY2lmeSB1c2VyIHByZWZlcmVuY2VzIHdoZW4g c2VsZWN0aW5nIGluZm9ybWF0aW9uIGNvbnRlbnQsDQogICBvciBmb3IgbGFiZWxpbmcgYWRkaXRp b25hbCBhdHRyaWJ1dGVzIG9mIGNvbnRlbnQgYW5kIGFzc29jaWF0ZWQNCiAgIHJlc291cmNlcy4N Cg0KICAgVGFncyBjYW4gYWxzbyBiZSB1c2VkIHRvIGluZGljYXRlIGFkZGl0aW9uYWwgbGFuZ3Vh Z2UgYXR0cmlidXRlcyBvZg0KICAgY29udGVudC4gIEZvciBleGFtcGxlLCBpbmRpY2F0aW5nIHNw ZWNpZmljIGluZm9ybWF0aW9uIGFib3V0IHRoZQ0KICAgZGlhbGVjdCwgd3JpdGluZyBzeXN0ZW0s IG9yIG9ydGhvZ3JhcGh5IHVzZWQgaW4gYSBkb2N1bWVudCBvcg0KICAgcmVzb3VyY2UgbWF5IGVu YWJsZSB0aGUgdXNlciB0byBvYnRhaW4gaW5mb3JtYXRpb24gaW4gYSBmb3JtIHRoYXQNCiAgIHRo ZXkgY2FuIHVuZGVyc3RhbmQsIG9yIGltcG9ydGFudCBpbiBwcm9jZXNzaW5nIG9yIHJlbmRlcmlu ZyB0aGUNCiAgIGdpdmVuIGNvbnRlbnQgaW50byBhbiBhcHByb3ByaWF0ZSBmb3JtIG9yIHN0eWxl Lg0KDQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIHBhcnRpY3VsYXIgaWRlbnRpZmllciBt ZWNoYW5pc20gKHRoZQ0KICAgbGFuZ3VhZ2UgdGFnKSBhbmQgYSByZWdpc3RyYXRpb24gZnVuY3Rp b24gZm9yIHZhbHVlcyB0byBiZSB1c2VkIHRvDQogICBmb3JtIHRhZ3MuICBJdCBhbHNvIGRlZmlu ZXMgYSBtZWNoYW5pc20gZm9yIHByaXZhdGUgdXNlIHZhbHVlcyBhbmQNCiAgIGZ1dHVyZSBleHRl bnNpb24uDQoNCiAgIFRoaXMgZG9jdW1lbnQgcmVwbGFjZXMgUkZDIDMwNjYsIHdoaWNoIHJlcGxh Y2VkIFJGQyAxNzY2LiAgRm9yIGEgbGlzdA0KICAgb2YgY2hhbmdlcyBpbiB0aGlzIGRvY3VtZW50 LCBzZWUgU2VjdGlvbiA4Lg0KDQogICBUaGUga2V5d29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAi UkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5P VCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzDQogICBkb2N1 bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4NCg0K DQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgSmFudWFyeSAx MiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgSnVseSAyMDA1DQoNCg0K Mi4gIFRoZSBMYW5ndWFnZSBUYWcNCg0KICAgVGhlIGxhbmd1YWdlIHRhZyBhbHdheXMgZGVmaW5l cyBhIGxhbmd1YWdlIGFzIHVzZWQgKHdoaWNoIGluY2x1ZGVzDQogICBiZWluZyBzcG9rZW4sIHdy aXR0ZW4sIHNpZ25lZCwgb3Igb3RoZXJ3aXNlIHNpZ25hbGVkKSBieSBodW1hbiBiZWluZ3MNCiAg IGZvciBjb21tdW5pY2F0aW9uIG9mIGluZm9ybWF0aW9uIHRvIG90aGVyIGh1bWFuIGJlaW5ncy4g IENvbXB1dGVyDQogICBsYW5ndWFnZXMgc3VjaCBhcyBwcm9ncmFtbWluZyBsYW5ndWFnZXMgYXJl IGV4cGxpY2l0bHkgZXhjbHVkZWQuDQoNCjIuMSAgU3ludGF4DQoNCiAgIFRoZSBsYW5ndWFnZSB0 YWcgaXMgY29tcG9zZWQgb2Ygb25lIG9yIG1vcmUgcGFydHMgb3IgInN1YnRhZ3MiLiAgRWFjaA0K ICAgc3VidGFnIGNvbnNpc3RzIG9mIGEgc2VxdWVuY2Ugb2YgYWxwaGEtbnVtZXJpYyBjaGFyYWN0 ZXJzLiAgU3VidGFncw0KICAgYXJlIGRpc3Rpbmd1aXNoZWQgYW5kIHNlcGFyYXRlZCBmcm9tIG9u ZSBhbm90aGVyIGJ5IGEgaHlwaGVuICgiLSIsDQogICBBQk5GICV4MkQpLiAgQSBsYW5ndWFnZSB0 YWcgY29uc2lzdHMgb2YgYSAicHJpbWFyeSBsYW5ndWFnZSIgc3VidGFnDQogICBhbmQgYSAocG9z c2libHkgZW1wdHkpIHNlcmllcyBvZiBzdWJzZXF1ZW50IHN1YnRhZ3MsIGVhY2ggb2Ygd2hpY2gN CiAgIHJlZmluZXMgb3IgbmFycm93cyB0aGUgcmFuZ2Ugb2YgbGFuZ3VhZ2UgaWRlbnRpZmllZCBi eSB0aGUgb3ZlcmFsbA0KICAgdGFnLg0KDQogICBFYWNoIHR5cGUgb2Ygc3VidGFnIGlzIGRpc3Rp bmd1aXNoZWQgYnkgbGVuZ3RoLCBwb3NpdGlvbiBpbiB0aGUgdGFnLA0KICAgYW5kIGNvbnRlbnQ6 IHN1YnRhZ3MgY2FuIGJlIHJlY29nbml6ZWQgc29sZWx5IGJ5IHRoZXNlIGZlYXR1cmVzLg0KICAg VGhpcyBtYWtlcyBpdCBwb3NzaWJsZSB0byBjb25zdHJ1Y3QgYSBwYXJzZXIgdGhhdCBjYW4gZXh0 cmFjdCBhbmQNCiAgIGFzc2lnbiBzb21lIHNlbWFudGljIGluZm9ybWF0aW9uIHRvIHRoZSBzdWJ0 YWdzLCBldmVuIGlmIHRoZSBzcGVjaWZpYw0KICAgc3VidGFnIHZhbHVlcyBhcmUgbm90IHJlY29n bml6ZWQuICBUaHVzIGEgcGFyc2VyIG5lZWQgbm90IGhhdmUgYW4gdXAtDQogICB0by1kYXRlIGNv cHkgKG9yIGFueSBjb3B5IGF0IGFsbCkgb2YgdGhlIHN1YnRhZyByZWdpc3RyeSB0byBwZXJmb3Jt DQogICBtb3N0IHNlYXJjaGluZyBhbmQgbWF0Y2hpbmcgb3BlcmF0aW9ucy4NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA0 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgICAgSnVseSAyMDA1DQoNCg0KICAgVGhlIHN5bnRheCBvZiB0aGUgbGFuZ3VhZ2Ug dGFnIGluIEFCTkYgW1JGQzIyMzRiaXNdIGlzOg0KDQogICBMYW5ndWFnZS1UYWcgPSAobGFuZw0K ICAgICAgICAgICAgICAgICAgICozKCItIiBleHRsYW5nKQ0KICAgICAgICAgICAgICAgICAgIFsi LSIgc2NyaXB0XQ0KICAgICAgICAgICAgICAgICAgIFsiLSIgcmVnaW9uXQ0KICAgICAgICAgICAg ICAgICAgICooIi0iIHZhcmlhbnQpDQogICAgICAgICAgICAgICAgICAgKigiLSIgZXh0ZW5zaW9u KQ0KICAgICAgICAgICAgICAgICAgIFsiLSIgcHJpdmF0ZXVzZV0pDQogICAgICAgICAgICAgICAg ICAgLyBwcml2YXRldXNlICAgICAgICAgOyBwcml2YXRlIHVzZSB0YWcNCiAgICAgICAgICAgICAg ICAgICAvIGdyYW5kZmF0aGVyZWQgICAgICA7IGdyYW5kZmF0aGVyZWQgcmVnaXN0cmF0aW9ucw0K DQogICBsYW5nICAgICAgICAgICAgPSAyKjRBTFBIQSAgICAgICAgICAgOyBzaG9ydGVzdCBJU08g NjM5IGNvZGUNCiAgICAgICAgICAgICAgICAgICAvIHJlZ2lzdGVyZWQtbGFuZw0KICAgZXh0bGFu ZyAgICAgICAgID0gM0FMUEhBICAgICAgICAgICAgIDsgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UN CiAgIHNjcmlwdCAgICAgICAgICA9IDRBTFBIQSAgICAgICAgICAgICA7IElTTyAxNTkyNCBjb2Rl DQogICByZWdpb24gICAgICAgICAgPSAyQUxQSEEgICAgICAgICAgICAgOyBJU08gMzE2NiBjb2Rl DQogICAgICAgICAgICAgICAgICAgLyAzRElHSVQgICAgICAgICAgICAgOyBVTiBjb3VudHJ5IG51 bWJlcg0KICAgdmFyaWFudCAgICAgICAgID0gIDUqOGFscGhhbnVtICAgICAgIDsgcmVnaXN0ZXJl ZCB2YXJpYW50cw0KICAgICAgICAgICAgICAgICAgIC8gKCBESUdJVCAzYWxwaGFudW0gKQ0KICAg ZXh0ZW5zaW9uICAgICAgID0gc2luZ2xldG9uIDEqKCItIiAoMio4YWxwaGFudW0pKQ0KICAgcHJp dmF0ZXVzZSAgICAgID0gKCJ4Ii8iWCIpIDEqKCItIiAoMSo4YWxwaGFudW0pKQ0KICAgc2luZ2xl dG9uICAgICAgID0gJXg0MS01NyAvICV4NTktNUEgLyAleDYxLTc3IC8gJXg3OS03QSAvIERJR0lU DQogICAgICAgICAgICAgICAgICAgOyAiYSItInciIC8gInkiLSJ6IiAvICJBIi0iVyIgLyAiWSIt IloiIC8gIjAiLSI5Ig0KICAgICAgICAgICAgICAgICAgIDsgU2luZ2xlIGxldHRlcnM6IHgvWCBp cyByZXNlcnZlZCBmb3IgcHJpdmF0ZSB1c2UNCiAgIHJlZ2lzdGVyZWQtbGFuZyA9IDQqOEFMUEhB ICAgICAgICAgIDsgcmVnaXN0ZXJlZCBsYW5ndWFnZSBzdWJ0YWcNCiAgIGdyYW5kZmF0aGVyZWQg ICA9IDEqM0FMUEhBIDEqMigiLSIgKDIqOGFscGhhbnVtKSkNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDsgZ3JhbmRmYXRoZXJlZCByZWdpc3RyYXRpb24NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgTm90ZTogaSBpcyB0aGUgb25seSBzaW5n bGV0b24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsgdGhhdCBzdGFy dHMgYSBncmFuZGZhdGhlcmVkIHRhZw0KICAgYWxwaGFudW0gICAgICAgID0gKEFMUEhBIC8gRElH SVQpICAgOyBsZXR0ZXJzIGFuZCBudW1iZXJzDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIEZp Z3VyZSAxOiBMYW5ndWFnZSBUYWcgQUJORg0KDQogICBOb3RlOiBUaGVyZSBpcyBhIHN1YnRsZXR5 IGluIHRoZSBBQk5GIGZvciAndmFyaWFudCc6IHZhcmlhbnRzDQogICBzdGFydGluZyB3aXRoIGEg ZGlnaXQgTUFZIGJlIGZvdXIgY2hhcmFjdGVycyBsb25nLCB3aGlsZSB0aG9zZQ0KICAgc3RhcnRp bmcgd2l0aCBhIGxldHRlciBNVVNUIGJlIGF0IGxlYXN0IGZpdmUgY2hhcmFjdGVycyBsb25nLg0K DQogICBBbGwgc3VidGFncyBoYXZlIGEgbWF4aW11bSBsZW5ndGggb2YgZWlnaHQgY2hhcmFjdGVy cyBhbmQgd2hpdGVzcGFjZQ0KICAgaXMgbm90IHBlcm1pdHRlZCBpbiBhIGxhbmd1YWdlIHRhZy4g IEZvciBleGFtcGxlcyBvZiBsYW5ndWFnZSB0YWdzLA0KICAgc2VlIEFwcGVuZGl4IEIuDQoNCiAg IE5vdGUgdGhhdCBhbHRob3VnaCBbUkZDMjIzNGJpc10gcmVmZXJzIHRvIG9jdGV0cywgdGhlIGxh bmd1YWdlIHRhZ3MNCiAgIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGFyZSBzZXF1ZW5jZXMg b2YgY2hhcmFjdGVycyBmcm9tIHRoZSBVUy0NCiAgIEFTQ0lJIHJlcGVydG9pcmUuICBMYW5ndWFn ZSB0YWdzIE1BWSBiZSB1c2VkIGluIGRvY3VtZW50cyBhbmQNCiAgIGFwcGxpY2F0aW9ucyB0aGF0 IHVzZSBvdGhlciBlbmNvZGluZ3MsIHNvIGxvbmcgYXMgdGhlc2UgZW5jb21wYXNzIHRoZQ0KICAg VVMtQVNDSUkgcmVwZXJ0b2lyZS4gIEFuIGV4YW1wbGUgb2YgdGhpcyB3b3VsZCBiZSBhbiBYTUwg ZG9jdW1lbnQNCiAgIHRoYXQgdXNlcyB0aGUgVVRGLTE2TEUgW1JGQzI3ODFdIGVuY29kaW5nIG9m IFtVbmljb2RlXS4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgSmFudWFy eSAxMiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgSnVseSAyMDA1DQoN Cg0KICAgVGhlIHRhZ3MgYW5kIHRoZWlyIHN1YnRhZ3MsIGluY2x1ZGluZyBwcml2YXRlIHVzZSBh bmQgZXh0ZW5zaW9ucywgYXJlDQogICB0byBiZSB0cmVhdGVkIGFzIGNhc2UgaW5zZW5zaXRpdmU6 IHRoZXJlIGV4aXN0IGNvbnZlbnRpb25zIGZvciB0aGUNCiAgIGNhcGl0YWxpemF0aW9uIG9mIHNv bWUgb2YgdGhlIHN1YnRhZ3MsIGJ1dCB0aGVzZSBNVVNUIG5vdCBiZSB0YWtlbiB0bw0KICAgY2Fy cnkgbWVhbmluZy4NCg0KICAgRm9yIGV4YW1wbGU6DQoNCiAgIG8gIFtJU082MzktMV0gcmVjb21t ZW5kcyB0aGF0IGxhbmd1YWdlIGNvZGVzIGJlIHdyaXR0ZW4gaW4gbG93ZXIgY2FzZQ0KICAgICAg KCdtbicgTW9uZ29saWFuKS4NCg0KICAgbyAgW0lTTzMxNjZdIHJlY29tbWVuZHMgdGhhdCBjb3Vu dHJ5IGNvZGVzIGJlIGNhcGl0YWxpemVkICgnTU4nDQogICAgICBNb25nb2xpYSkuDQoNCiAgIG8g IFtJU08xNTkyNF0gcmVjb21tZW5kcyB0aGF0IHNjcmlwdCBjb2RlcyB1c2UgbG93ZXIgY2FzZSB3 aXRoIHRoZQ0KICAgICAgaW5pdGlhbCBsZXR0ZXIgY2FwaXRhbGl6ZWQgKCdDeXJsJyBDeXJpbGxp YykuDQoNCiAgIEhvd2V2ZXIsIGluIHRoZSB0YWdzIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVudCwg dGhlIHVwcGVyY2FzZSBVUy1BU0NJSQ0KICAgbGV0dGVycyBpbiB0aGUgcmFuZ2UgJ0EnIHRocm91 Z2ggJ1onIGFyZSBjb25zaWRlcmVkIGVxdWl2YWxlbnQgYW5kDQogICBtYXBwZWQgZGlyZWN0bHkg dG8gdGhlaXIgVVMtQVNDSUkgbG93ZXJjYXNlIGVxdWl2YWxlbnRzIGluIHRoZSByYW5nZQ0KICAg J2EnIHRocm91Z2ggJ3onLiAgVGh1cyB0aGUgdGFnICJtbi1DeXJsLU1OIiBpcyBub3QgZGlzdGlu Y3QgZnJvbSAiTU4tDQogICBjWVJMLW1uIiBvciAibU4tY1lyTC1NbiIgKG9yIGFueSBvdGhlciBj b21iaW5hdGlvbikgYW5kIGVhY2ggb2YgdGhlc2UNCiAgIHZhcmlhdGlvbnMgY29udmV5cyB0aGUg c2FtZSBtZWFuaW5nOiBNb25nb2xpYW4gd3JpdHRlbiBpbiB0aGUNCiAgIEN5cmlsbGljIHNjcmlw dCBhcyB1c2VkIGluIE1vbmdvbGlhLg0KDQoyLjIgIExhbmd1YWdlIFN1YnRhZyBTb3VyY2VzIGFu ZCBJbnRlcnByZXRhdGlvbg0KDQogICBUaGUgbmFtZXNwYWNlIG9mIGxhbmd1YWdlIHRhZ3MgYW5k IHRoZWlyIHN1YnRhZ3MgaXMgYWRtaW5pc3RlcmVkIGJ5DQogICB0aGUgSW50ZXJuZXQgQXNzaWdu ZWQgTnVtYmVycyBBdXRob3JpdHkgKElBTkEpIFtSRkMyODYwXSBhY2NvcmRpbmcgdG8NCiAgIHRo ZSBydWxlcyBpbiBTZWN0aW9uIDUgb2YgdGhpcyBkb2N1bWVudC4gIFRoZSByZWdpc3RyeSBtYWlu dGFpbmVkIGJ5DQogICBJQU5BIGlzIHRoZSBzb3VyY2UgZm9yIHZhbGlkIHN1YnRhZ3M6IG90aGVy IHN0YW5kYXJkcyByZWZlcmVuY2VkIGluDQogICB0aGlzIHNlY3Rpb24gcHJvdmlkZSB0aGUgc291 cmNlIG1hdGVyaWFsIGZvciB0aGF0IHJlZ2lzdHJ5Lg0KDQogICBUZXJtaW5vbG9neSBpbiB0aGlz IHNlY3Rpb246DQoNCiAgIG8gIFRhZyBvciB0YWdzIHJlZmVycyB0byBhIGNvbXBsZXRlIGxhbmd1 YWdlIHRhZywgc3VjaCBhcw0KICAgICAgImZyLUxhdG4tQ0EiLiAgRXhhbXBsZXMgb2YgdGFncyBp biB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbg0KICAgICAgZG91YmxlLXF1b3RlcyAoImVu LVVTIikuDQoNCiAgIG8gIFN1YnRhZyByZWZlcnMgdG8gYSBzcGVjaWZpYyBzZWN0aW9uIG9mIGEg dGFnLCBkZWxpbWl0ZWQgYnkgaHlwaGVuLA0KICAgICAgc3VjaCBhcyB0aGUgc3VidGFnICdMYXRu JyBpbiAiZnItTGF0bi1DQSIuICBFeGFtcGxlcyBvZiBzdWJ0YWdzIGluDQogICAgICB0aGlzIGRv Y3VtZW50IGFyZSBlbmNsb3NlZCBpbiBzaW5nbGUgcXVvdGVzICgnTGF0bicpLg0KDQogICBvICBD b2RlIG9yIGNvZGVzIHJlZmVycyB0byB2YWx1ZXMgZGVmaW5lZCBpbiBleHRlcm5hbCBzdGFuZGFy ZHMgKGFuZA0KICAgICAgd2hpY2ggYXJlIHVzZWQgYXMgc3VidGFncyBpbiB0aGlzIGRvY3VtZW50 KS4gIEZvciBleGFtcGxlLCAnTGF0bicNCiAgICAgIGlzIGFuIFtJU08xNTkyNF0gc2NyaXB0IGNv ZGUgd2hpY2ggd2FzIHVzZWQgdG8gZGVmaW5lIHRoZSAnTGF0bicNCiAgICAgIHNjcmlwdCBzdWJ0 YWcgZm9yIHVzZSBpbiBhIGxhbmd1YWdlIHRhZy4gIEV4YW1wbGVzIG9mIGNvZGVzIGluDQogICAg ICB0aGlzIGRvY3VtZW50IGFyZSBlbmNsb3NlZCBpbiBzaW5nbGUgcXVvdGVzICgnZW4nLCAnTGF0 bicpLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIs IDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNCiAg IFRoZSBkZWZpbml0aW9ucyBpbiB0aGlzIHNlY3Rpb24gYXBwbHkgdG8gdGhlIHZhcmlvdXMgc3Vi dGFncyB3aXRoaW4NCiAgIHRoZSBsYW5ndWFnZSB0YWdzIGRlZmluZWQgYnkgdGhpcyBkb2N1bWVu dCwgZXhjZXB0aW5nIHRob3NlDQogICAiZ3JhbmRmYXRoZXJlZCIgdGFncyBkZWZpbmVkIGluIFNl Y3Rpb24gMi4yLjguDQoNCiAgIExhbmd1YWdlIHRhZ3MgYXJlIGRlc2lnbmVkIHNvIHRoYXQgZWFj aCBzdWJ0YWcgdHlwZSBoYXMgdW5pcXVlIGxlbmd0aA0KICAgYW5kIGNvbnRlbnQgcmVzdHJpY3Rp b25zLiAgVGhlc2UgbWFrZSBpZGVudGlmaWNhdGlvbiBvZiB0aGUgc3VidGFnJ3MNCiAgIHR5cGUg cG9zc2libGUsIGV2ZW4gaWYgdGhlIGNvbnRlbnQgb2YgdGhlIHN1YnRhZyBpdHNlbGYgaXMNCiAg IHVucmVjb2duaXplZC4gIFRoaXMgYWxsb3dzIHRhZ3MgdG8gYmUgcGFyc2VkIGFuZCBwcm9jZXNz ZWQgd2l0aG91dA0KICAgcmVmZXJlbmNlIHRvIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgdW5k ZXJseWluZyBzdGFuZGFyZHMgb3IgdGhlDQogICBJQU5BIHJlZ2lzdHJ5IGFuZCBtYWtlcyB0aGUg YXNzb2NpYXRlZCBleGNlcHRpb24gaGFuZGxpbmcgd2hlbg0KICAgcGFyc2luZyB0YWdzIHNpbXBs ZXIuDQoNCiAgIFN1YnRhZ3MgaW4gdGhlIElBTkEgcmVnaXN0cnkgdGhhdCBkbyBub3QgY29tZSBm cm9tIGFuIHVuZGVybHlpbmcNCiAgIHN0YW5kYXJkIGNhbiBvbmx5IGFwcGVhciBpbiBzcGVjaWZp YyBwb3NpdGlvbnMgaW4gYSB0YWcuDQogICBTcGVjaWZpY2FsbHksIHRoZXkgY2FuIG9ubHkgb2Nj dXIgYXMgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWdzIG9yIGFzDQogICB2YXJpYW50IHN1YnRhZ3Mu DQoNCiAgIE5vdGUgdGhhdCBzZXF1ZW5jZXMgb2YgcHJpdmF0ZSB1c2UgYW5kIGV4dGVuc2lvbiBz dWJ0YWdzIE1VU1Qgb2NjdXINCiAgIGF0IHRoZSBlbmQgb2YgdGhlIHNlcXVlbmNlIG9mIHN1YnRh Z3MgYW5kIE1VU1QgTk9UIGJlIGludGVyc3BlcnNlZA0KICAgd2l0aCBzdWJ0YWdzIGRlZmluZWQg ZWxzZXdoZXJlIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgIFNpbmdsZSBsZXR0ZXIgYW5kIGRpZ2l0 IHN1YnRhZ3MgYXJlIHJlc2VydmVkIGZvciBjdXJyZW50IG9yIGZ1dHVyZQ0KICAgdXNlLiAgVGhl c2UgaW5jbHVkZSB0aGUgZm9sbG93aW5nIGN1cnJlbnQgdXNlczoNCg0KICAgbyAgVGhlIHNpbmds ZSBsZXR0ZXIgc3VidGFnICd4JyBpcyByZXNlcnZlZCB0byBpbnRyb2R1Y2UgYSBzZXF1ZW5jZQ0K ICAgICAgb2YgcHJpdmF0ZSB1c2Ugc3VidGFncy4gIFRoZSBpbnRlcnByZXRhdGlvbiBvZiBhbnkg cHJpdmF0ZSB1c2UNCiAgICAgIHN1YnRhZ3MgaXMgZGVmaW5lZCBzb2xlbHkgYnkgcHJpdmF0ZSBh Z3JlZW1lbnQgYW5kIGlzIG5vdCBkZWZpbmVkDQogICAgICBieSB0aGUgcnVsZXMgaW4gdGhpcyBz ZWN0aW9uIG9yIGluIGFueSBzdGFuZGFyZCBvciByZWdpc3RyeQ0KICAgICAgZGVmaW5lZCBpbiB0 aGlzIGRvY3VtZW50Lg0KDQogICBvICBBbGwgb3RoZXIgc2luZ2xlIGxldHRlciBzdWJ0YWdzIGFy ZSByZXNlcnZlZCB0byBpbnRyb2R1Y2UNCiAgICAgIHN0YW5kYXJkaXplZCBleHRlbnNpb24gc3Vi dGFnIHNlcXVlbmNlcyBhcyBkZXNjcmliZWQgaW4NCiAgICAgIFNlY3Rpb24gMy42Lg0KDQogICBU aGUgc2luZ2xlIGxldHRlciBzdWJ0YWcgJ2knIGlzIHVzZWQgYnkgc29tZSBncmFuZGZhdGhlcmVk IHRhZ3MsIHN1Y2gNCiAgIGFzICJpLWVub2NoaWFuIiwgd2hlcmUgaXQgYWx3YXlzIGFwcGVhcnMg aW4gdGhlIGZpcnN0IHBvc2l0aW9uIGFuZA0KICAgY2Fubm90IGJlIGNvbmZ1c2VkIHdpdGggYW4g ZXh0ZW5zaW9uLg0KDQoyLjIuMSAgUHJpbWFyeSBMYW5ndWFnZSBTdWJ0YWcNCg0KICAgVGhlIHBy aW1hcnkgbGFuZ3VhZ2Ugc3VidGFnIGlzIHRoZSBmaXJzdCBzdWJ0YWcgaW4gYSBsYW5ndWFnZSB0 YWcNCiAgICh3aXRoIHRoZSBleGNlcHRpb24gb2YgcHJpdmF0ZSB1c2UgYW5kIGNlcnRhaW4gZ3Jh bmRmYXRoZXJlZCB0YWdzKQ0KICAgYW5kIGNhbm5vdCBiZSBvbWl0dGVkLiAgVGhlIGZvbGxvd2lu ZyBydWxlcyBhcHBseSB0byB0aGUgcHJpbWFyeQ0KICAgbGFuZ3VhZ2Ugc3VidGFnOg0KDQogICAx LiAgQWxsIHR3byBjaGFyYWN0ZXIgbGFuZ3VhZ2Ugc3VidGFncyB3ZXJlIGRlZmluZWQgaW4gdGhl IElBTkENCiAgICAgICByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1lbnRzIGZvdW5k IGluIHRoZSBzdGFuZGFyZCBJU08NCiAgICAgICA2MzkgUGFydCAxLCAiSVNPIDYzOS0xOjIwMDIs IENvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSA3XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAg ICAgICAgICAgSnVseSAyMDA1DQoNCg0KICAgICAgIG5hbWVzIG9mIGxhbmd1YWdlcyAtLSBQYXJ0 IDE6IEFscGhhLTIgY29kZSIgW0lTTzYzOS0xXSwgb3IgdXNpbmcNCiAgICAgICBhc3NpZ25tZW50 cyBzdWJzZXF1ZW50bHkgbWFkZSBieSB0aGUgSVNPIDYzOSBQYXJ0IDEgbWFpbnRlbmFuY2UNCiAg ICAgICBhZ2VuY3kgb3IgZ292ZXJuaW5nIHN0YW5kYXJkaXphdGlvbiBib2RpZXMuDQoNCiAgIDIu ICBBbGwgdGhyZWUgY2hhcmFjdGVyIGxhbmd1YWdlIHN1YnRhZ3Mgd2VyZSBkZWZpbmVkIGluIHRo ZSBJQU5BDQogICAgICAgcmVnaXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3Vu ZCBpbiBJU08gNjM5IFBhcnQgMiwNCiAgICAgICAiSVNPIDYzOS0yOjE5OTggLSBDb2RlcyBmb3Ig dGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mDQogICAgICAgbGFuZ3VhZ2VzIC0tIFBhcnQg MjogQWxwaGEtMyBjb2RlIC0gZWRpdGlvbiAxIiBbSVNPNjM5LTJdLCBvcg0KICAgICAgIGFzc2ln bm1lbnRzIHN1YnNlcXVlbnRseSBtYWRlIGJ5IHRoZSBJU08gNjM5IFBhcnQgMiBtYWludGVuYW5j ZQ0KICAgICAgIGFnZW5jeSBvciBnb3Zlcm5pbmcgc3RhbmRhcmRpemF0aW9uIGJvZGllcy4NCg0K ICAgMy4gIFRoZSBzdWJ0YWdzIGluIHRoZSByYW5nZSAncWFhJyB0aHJvdWdoICdxdHonIGFyZSBy ZXNlcnZlZCBmb3INCiAgICAgICBwcml2YXRlIHVzZSBpbiBsYW5ndWFnZSB0YWdzLiAgVGhlc2Ug c3VidGFncyBjb3JyZXNwb25kIHRvIGNvZGVzDQogICAgICAgcmVzZXJ2ZWQgYnkgSVNPIDYzOS0y IGZvciBwcml2YXRlIHVzZS4gIFRoZXNlIGNvZGVzIE1BWSBiZSB1c2VkDQogICAgICAgZm9yIG5v bi1yZWdpc3RlcmVkIHByaW1hcnktbGFuZ3VhZ2Ugc3VidGFncyAoaW5zdGVhZCBvZiB1c2luZw0K ICAgICAgIHByaXZhdGUgdXNlIHN1YnRhZ3MgZm9sbG93aW5nICd4LScpLiAgUGxlYXNlIHJlZmVy IHRvIFNlY3Rpb24gNC41DQogICAgICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gb24gcHJpdmF0ZSB1 c2Ugc3VidGFncy4NCg0KICAgNC4gIEFsbCBmb3VyIGNoYXJhY3RlciBsYW5ndWFnZSBzdWJ0YWdz IGFyZSByZXNlcnZlZCBmb3IgcG9zc2libGUNCiAgICAgICBmdXR1cmUgc3RhbmRhcmRpemF0aW9u Lg0KDQogICA1LiAgQWxsIGxhbmd1YWdlIHN1YnRhZ3Mgb2YgNSB0byA4IGNoYXJhY3RlcnMgaW4g bGVuZ3RoIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkgd2VyZSBkZWZpbmVkIHZpYSB0aGUg cmVnaXN0cmF0aW9uIHByb2Nlc3MgaW4gU2VjdGlvbiAzLjQNCiAgICAgICBhbmQgTUFZIGJlIHVz ZWQgdG8gZm9ybSB0aGUgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcuICBBdCB0aGUgdGltZQ0KICAg ICAgIHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQsIHRoZXJlIHdlcmUgbm8gZXhhbXBsZXMgb2Yg dGhpcyBraW5kIG9mDQogICAgICAgc3VidGFnIGFuZCBmdXR1cmUgcmVnaXN0cmF0aW9ucyBvZiB0 aGlzIHR5cGUgd2lsbCBiZSBkaXNjb3VyYWdlZDoNCiAgICAgICBwcmltYXJ5IGxhbmd1YWdlcyBh cmUgc3Ryb25nbHkgUkVDT01NRU5ERUQgZm9yIHJlZ2lzdHJhdGlvbiB3aXRoDQogICAgICAgSVNP IDYzOSBhbmQgcHJvcG9zYWxzIHJlamVjdGVkIGJ5IElTTyA2MzkvUkEgd2lsbCBiZSBjbG9zZWx5 DQogICAgICAgc2NydXRpbml6ZWQgYmVmb3JlIHRoZXkgYXJlIHJlZ2lzdGVyZWQgd2l0aCBJQU5B Lg0KDQogICA2LiAgVGhlIHNpbmdsZSBjaGFyYWN0ZXIgc3VidGFnICd4JyBhcyB0aGUgcHJpbWFy eSBzdWJ0YWcgaW5kaWNhdGVzDQogICAgICAgdGhhdCB0aGUgbGFuZ3VhZ2UgdGFnIGNvbnNpc3Rz IHNvbGVseSBvZiBzdWJ0YWdzIHdob3NlIG1lYW5pbmcgaXMNCiAgICAgICBkZWZpbmVkIGJ5IHBy aXZhdGUgYWdyZWVtZW50LiAgRm9yIGV4YW1wbGUsIGluIHRoZSB0YWcgIngtZnItQ0giLA0KICAg ICAgIHRoZSBzdWJ0YWdzICdmcicgYW5kICdDSCcgU0hPVUxEIE5PVCBiZSB0YWtlbiB0byByZXBy ZXNlbnQgdGhlDQogICAgICAgRnJlbmNoIGxhbmd1YWdlIG9yIHRoZSBjb3VudHJ5IG9mIFN3aXR6 ZXJsYW5kIChvciBhbnkgb3RoZXIgdmFsdWUNCiAgICAgICBpbiB0aGUgSUFOQSByZWdpc3RyeSkg dW5sZXNzIHRoZXJlIGlzIGEgcHJpdmF0ZSBhZ3JlZW1lbnQgaW4NCiAgICAgICBwbGFjZSB0byBk byBzby4gIFNlZSBTZWN0aW9uIDQuNS4NCg0KICAgNy4gIFRoZSBzaW5nbGUgY2hhcmFjdGVyIHN1 YnRhZyAnaScgaXMgdXNlZCBieSBzb21lIGdyYW5kZmF0aGVyZWQNCiAgICAgICB0YWdzIChzZWUg U2VjdGlvbiAyLjIuOCkgc3VjaCBhcyAiaS1rbGluZ29uIiBhbmQgImktYm5uIi4gIChPdGhlcg0K ICAgICAgIGdyYW5kZmF0aGVyZWQgdGFncyBoYXZlIGEgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcg aW4gdGhlaXIgZmlyc3QNCiAgICAgICBwb3NpdGlvbikNCg0KICAgOC4gIE90aGVyIHZhbHVlcyBN VVNUIE5PVCBiZSBhc3NpZ25lZCB0byB0aGUgcHJpbWFyeSBzdWJ0YWcgZXhjZXB0IGJ5DQogICAg ICAgcmV2aXNpb24gb3IgdXBkYXRlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIE5vdGU6IEZvciBs YW5ndWFnZXMgdGhhdCBoYXZlIGJvdGggYW4gSVNPIDYzOS0xIHR3byBjaGFyYWN0ZXIgY29kZQ0K ICAgYW5kIGFuIElTTyA2MzktMiB0aHJlZSBjaGFyYWN0ZXIgY29kZSwgb25seSB0aGUgSVNPIDYz OS0xIHR3bw0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEy LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQog ICBjaGFyYWN0ZXIgY29kZSBpcyBkZWZpbmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5Lg0KDQogICBO b3RlOiBGb3IgbGFuZ3VhZ2VzIHRoYXQgaGF2ZSBubyBJU08gNjM5LTEgdHdvIGNoYXJhY3RlciBj b2RlIGFuZCBmb3INCiAgIHdoaWNoIHRoZSBJU08gNjM5LTIvVCAoVGVybWlub2xvZ3kpIGNvZGUg YW5kIHRoZSBJU08gNjM5LTIvQg0KICAgKEJpYmxpb2dyYXBoaWMpIGNvZGVzIGRpZmZlciwgb25s eSB0aGUgVGVybWlub2xvZ3kgY29kZSBpcyBkZWZpbmVkIGluDQogICB0aGUgSUFOQSByZWdpc3Ry eS4gIEF0IHRoZSB0aW1lIHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQsIGFsbA0KICAgbGFuZ3Vh Z2VzIHRoYXQgaGFkIGJvdGgga2luZHMgb2YgdGhyZWUgY2hhcmFjdGVyIGNvZGUgd2VyZSBhbHNv DQogICBhc3NpZ25lZCBhIHR3byBjaGFyYWN0ZXIgY29kZTsgaXQgaXMgbm90IGV4cGVjdGVkIHRo YXQgZnV0dXJlDQogICBhc3NpZ25tZW50cyBvZiB0aGlzIG5hdHVyZSB3aWxsIG9jY3VyLg0KDQog ICBOb3RlOiBUbyBhdm9pZCBwcm9ibGVtcyB3aXRoIHZlcnNpb25pbmcgYW5kIHN1YnRhZyBjaG9p Y2UgYXMNCiAgIGV4cGVyaWVuY2VkIGR1cmluZyB0aGUgdHJhbnNpdGlvbiBiZXR3ZWVuIFJGQyAx NzY2IGFuZCBSRkMgMzA2NiwgYXMNCiAgIHdlbGwgYXMgdGhlIGNhbm9uaWNhbCBuYXR1cmUgb2Yg c3VidGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQsIHRoZQ0KICAgSVNPIDYzOSBSZWdpc3Ry YXRpb24gQXV0aG9yaXR5IEpvaW50IEFkdmlzb3J5IENvbW1pdHRlZSAoSVNPIDYzOS8NCiAgIFJB LUpBQykgaGFzIGluY2x1ZGVkIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50IGluIFtpc282MzkucHJp bmNpcGxlc106DQoNCiAgICJBIGxhbmd1YWdlIGNvZGUgYWxyZWFkeSBpbiBJU08gNjM5LTIgYXQg dGhlIHBvaW50IG9mIGZyZWV6aW5nIElTTw0KICAgNjM5LTEgc2hhbGwgbm90IGxhdGVyIGJlIGFk ZGVkIHRvIElTTyA2MzktMS4gIFRoaXMgaXMgdG8gZW5zdXJlDQogICBjb25zaXN0ZW5jeSBpbiB1 c2FnZSBvdmVyIHRpbWUsIHNpbmNlIHVzZXJzIGFyZSBkaXJlY3RlZCBpbiBJbnRlcm5ldA0KICAg YXBwbGljYXRpb25zIHRvIGVtcGxveSB0aGUgYWxwaGEtMyBjb2RlIHdoZW4gYW4gYWxwaGEtMiBj b2RlIGZvciB0aGF0DQogICBsYW5ndWFnZSBpcyBub3QgYXZhaWxhYmxlLiINCg0KICAgSW4gb3Jk ZXIgdG8gYXZvaWQgaW5zdGFiaWxpdHkgb2YgdGhlIGNhbm9uaWNhbCBmb3JtIG9mIHRhZ3MsIGlm IGEgdHdvDQogICBjaGFyYWN0ZXIgY29kZSBpcyBhZGRlZCB0byBJU08gNjM5LTEgZm9yIGEgbGFu Z3VhZ2UgZm9yIHdoaWNoIGEgdGhyZWUNCiAgIGNoYXJhY3RlciBjb2RlIHdhcyBhbHJlYWR5IGlu Y2x1ZGVkIGluIElTTyA2MzktMiwgdGhlIHR3byBjaGFyYWN0ZXINCiAgIGNvZGUgd2lsbCBub3Qg YmUgYWRkZWQgYXMgYSBzdWJ0YWcgaW4gdGhlIHJlZ2lzdHJ5LiAgU2VlIFNlY3Rpb24gMy4zLg0K DQogICBGb3IgZXhhbXBsZSwgaWYgc29tZSBjb250ZW50IHdlcmUgdGFnZ2VkIHdpdGggJ2hhdycg KEhhd2FpaWFuKSwgd2hpY2gNCiAgIGN1cnJlbnRseSBoYXMgbm8gdHdvIGNoYXJhY3RlciBjb2Rl LCB0aGUgdGFnIHdvdWxkIG5vdCBiZSBpbnZhbGlkYXRlZA0KICAgaWYgSVNPIDYzOS0xIHdlcmUg dG8gYXNzaWduIGEgdHdvIGNoYXJhY3RlciBjb2RlIHRvIHRoZSBIYXdhaWlhbg0KICAgbGFuZ3Vh Z2UgYXQgYSBsYXRlciBkYXRlLg0KDQogICBGb3IgZXhhbXBsZSwgb25lIG9mIHRoZSBncmFuZGZh dGhlcmVkIElBTkEgcmVnaXN0cmF0aW9ucyBpcw0KICAgImktZW5vY2hpYW4iLiAgVGhlIHN1YnRh ZyAnZW5vY2hpYW4nIGNvdWxkIGJlIHJlZ2lzdGVyZWQgaW4gdGhlIElBTkENCiAgIHJlZ2lzdHJ5 IGFzIGEgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgKGFzc3VtaW5nIHRoYXQgSVNPIDYzOSBkb2Vz IG5vdA0KICAgcmVnaXN0ZXIgdGhpcyBsYW5ndWFnZSBmaXJzdCksIG1ha2luZyB0YWdzIHN1Y2gg YXMgImVub2NoaWFuLUFRIiBhbmQNCiAgICJlbm9jaGlhbi1MYXRuIiB2YWxpZC4NCg0KMi4yLjIg IEV4dGVuZGVkIExhbmd1YWdlIFN1YnRhZ3MNCg0KICAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBs eSB0byB0aGUgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnczoNCg0KICAgMS4gIFRocmVlIGxldHRl ciBzdWJ0YWdzIGltbWVkaWF0ZWx5IGZvbGxvd2luZyB0aGUgcHJpbWFyeSBzdWJ0YWcgYXJlDQog ICAgICAgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSBzdGFuZGFyZGl6YXRpb24sIGFudGljaXBhdGluZyB3 b3JrIHRoYXQgaXMNCiAgICAgICBjdXJyZW50bHkgdW5kZXIgd2F5IG9uIElTTyA2MzkuDQoNCiAg IDIuICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzIE1VU1QgZm9sbG93IHRoZSBwcmltYXJ5IHN1 YnRhZyBhbmQNCiAgICAgICBwcmVjZWRlIGFueSBvdGhlciBzdWJ0YWdzLg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAgICAgICAgICAg IFtQYWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQogICAzLiAgVGhlcmUgTUFZIGJlIHVw IHRvIHRocmVlIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZ3MuDQoNCiAgIDQuICBFeHRlbmRlZCBs YW5ndWFnZSBzdWJ0YWdzIE1VU1QgTk9UIGJlIHJlZ2lzdGVyZWQgb3IgdXNlZCB0byBmb3JtDQog ICAgICAgbGFuZ3VhZ2UgdGFncy4gIFRoZWlyIHN5bnRheCBpcyBkZXNjcmliZWQgaGVyZSBzbyB0 aGF0DQogICAgICAgaW1wbGVtZW50YXRpb25zIGNhbiBiZSBjb21wYXRpYmxlIHdpdGggYW55IGZ1 dHVyZSByZXZpc2lvbiBvZg0KICAgICAgIHRoaXMgZG9jdW1lbnQgd2hpY2ggZG9lcyBwcm92aWRl IGZvciB0aGVpciByZWdpc3RyYXRpb24uDQoNCiAgIEV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZyBy ZWNvcmRzLCBvbmNlIHRoZXkgYXBwZWFyIGluIHRoZSByZWdpc3RyeSwNCiAgIE1VU1QgaW5jbHVk ZSBleGFjdGx5IG9uZSAnUHJlZml4JyBmaWVsZCBpbmRpY2F0aW5nIGFuIGFwcHJvcHJpYXRlDQog ICBsYW5ndWFnZSBzdWJ0YWcgb3Igc2VxdWVuY2Ugb2Ygc3VidGFncyB0aGF0IE1VU1QgYWx3YXlz IGFwcGVhciBhcyBhDQogICBwcmVmaXggdG8gdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHN1YnRhZy4N Cg0KICAgRXhhbXBsZTogSW4gYSBmdXR1cmUgcmV2aXNpb24gb3IgdXBkYXRlIG9mIHRoaXMgZG9j dW1lbnQsIHRoZSB0YWcNCiAgICJ6aC1nYW4iIChyZWdpc3RlcmVkIHVuZGVyIFJGQyAzMDY2KSBt aWdodCBiZWNvbWUgYSB2YWxpZCBub24tDQogICBncmFuZGZhdGhlcmVkICh0aGF0IGlzLCByZWR1 bmRhbnQpIHRhZyBpbiB3aGljaCB0aGUgc3VidGFnICdnYW4nDQogICBtaWdodCByZXByZXNlbnQg dGhlIENoaW5lc2UgZGlhbGVjdCAnR2FuJy4NCg0KMi4yLjMgIFNjcmlwdCBTdWJ0YWcNCg0KICAg U2NyaXB0IHN1YnRhZ3MgYXJlIHVzZWQgdG8gaW5kaWNhdGUgdGhlIHNjcmlwdCBvciB3cml0aW5n IHN5c3RlbQ0KICAgdmFyaWF0aW9ucyB0aGF0IGRpc3Rpbmd1aXNoIHRoZSB3cml0dGVuIGZvcm1z IG9mIGEgbGFuZ3VhZ2Ugb3IgaXRzDQogICBkaWFsZWN0cy4gIFRoZSBmb2xsb3dpbmcgcnVsZXMg YXBwbHkgdG8gdGhlIHNjcmlwdCBzdWJ0YWdzOg0KDQogICAxLiAgQWxsIGZvdXIgY2hhcmFjdGVy IHN1YnRhZ3Mgd2VyZSBkZWZpbmVkIGFjY29yZGluZyB0bw0KICAgICAgIFtJU08xNTkyNF0tLSJD b2RlcyBmb3IgdGhlIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBuYW1lcyBvZg0KICAgICAgIHNjcmlw dHMiOiBhbHBoYS00IHNjcmlwdCBjb2Rlcywgb3Igc3Vic2VxdWVudGx5IGFzc2lnbmVkIGJ5IHRo ZQ0KICAgICAgIElTTyAxNTkyNCBtYWludGVuYW5jZSBhZ2VuY3kgb3IgZ292ZXJuaW5nIHN0YW5k YXJkaXphdGlvbiBib2RpZXMsDQogICAgICAgZGVub3RpbmcgdGhlIHNjcmlwdCBvciB3cml0aW5n IHN5c3RlbSB1c2VkIGluIGNvbmp1bmN0aW9uIHdpdGgNCiAgICAgICB0aGlzIGxhbmd1YWdlLg0K DQogICAyLiAgU2NyaXB0IHN1YnRhZ3MgTVVTVCBpbW1lZGlhdGVseSBmb2xsb3cgdGhlIHByaW1h cnkgbGFuZ3VhZ2UNCiAgICAgICBzdWJ0YWcgYW5kIGFsbCBleHRlbmRlZCBsYW5ndWFnZSBzdWJ0 YWdzIGFuZCBNVVNUIG9jY3VyIGJlZm9yZQ0KICAgICAgIGFueSBvdGhlciB0eXBlIG9mIHN1YnRh ZyBkZXNjcmliZWQgYmVsb3cuDQoNCiAgIDMuICBUaGUgc2NyaXB0IHN1YnRhZ3MgJ1FhYWEnIHRo cm91Z2ggJ1FhYngnIGFyZSByZXNlcnZlZCBmb3IgcHJpdmF0ZQ0KICAgICAgIHVzZSBpbiBsYW5n dWFnZSB0YWdzLiAgVGhlc2Ugc3VidGFncyBjb3JyZXNwb25kIHRvIGNvZGVzIHJlc2VydmVkDQog ICAgICAgYnkgSVNPIDE1OTI0IGZvciBwcml2YXRlIHVzZS4gIFRoZXNlIGNvZGVzIE1BWSBiZSB1 c2VkIGZvciBub24tDQogICAgICAgcmVnaXN0ZXJlZCBzY3JpcHQgdmFsdWVzLiAgUGxlYXNlIHJl ZmVyIHRvIFNlY3Rpb24gNC41IGZvciBtb3JlDQogICAgICAgaW5mb3JtYXRpb24gb24gcHJpdmF0 ZSB1c2Ugc3VidGFncy4NCg0KICAgNC4gIFNjcmlwdCBzdWJ0YWdzIGNhbm5vdCBiZSByZWdpc3Rl cmVkIHVzaW5nIHRoZSBwcm9jZXNzIGluDQogICAgICAgU2VjdGlvbiAzLjQgb2YgdGhpcyBkb2N1 bWVudC4gIFZhcmlhbnQgc3VidGFncyBNQVkgYmUgY29uc2lkZXJlZA0KICAgICAgIGZvciByZWdp c3RyYXRpb24gZm9yIHRoYXQgcHVycG9zZS4NCg0KICAgNS4gIFRoZXJlIE1VU1QgYmUgYXQgbW9z dCBvbmUgc2NyaXB0IHN1YnRhZyBpbiBhIGxhbmd1YWdlIHRhZyBhbmQgdGhlDQogICAgICAgc2Ny aXB0IHN1YnRhZyBTSE9VTEQgYmUgb21pdHRlZCB3aGVuIGl0IGFkZHMgbm8gZGlzdGluZ3Vpc2hp bmcNCiAgICAgICB2YWx1ZSB0byB0aGUgdGFnIG9yIHdoZW4gdGhlIHByaW1hcnkgbGFuZ3VhZ2Ug c3VidGFnJ3MgcmVjb3JkDQogICAgICAgaW5jbHVkZXMgYSBTdXBwcmVzcy1TY3JpcHQgZmllbGQg bGlzdGluZyB0aGUgYXBwbGljYWJsZSBzY3JpcHQNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICAgICAgSnVseSAyMDA1DQoNCg0KICAgICAgIHN1YnRhZy4NCg0KICAgRXhhbXBsZTogInNyLUxh dG4iIHJlcHJlc2VudHMgU2VyYmlhbiB3cml0dGVuIHVzaW5nIHRoZSBMYXRpbiBzY3JpcHQuDQoN CjIuMi40ICBSZWdpb24gU3VidGFnDQoNCiAgIFJlZ2lvbiBzdWJ0YWdzIGFyZSB1c2VkIHRvIGlu ZGljYXRlIGxpbmd1aXN0aWMgdmFyaWF0aW9ucyBhc3NvY2lhdGVkDQogICB3aXRoIG9yIGFwcHJv cHJpYXRlIHRvIGEgc3BlY2lmaWMgY291bnRyeSwgdGVycml0b3J5LCBvciByZWdpb24uDQogICBU eXBpY2FsbHksIGEgcmVnaW9uIHN1YnRhZyBpcyB1c2VkIHRvIGluZGljYXRlIHJlZ2lvbmFsIGRp YWxlY3RzIG9yDQogICB1c2FnZSwgb3IgcmVnaW9uLXNwZWNpZmljIHNwZWxsaW5nIGNvbnZlbnRp b25zLiAgQSByZWdpb24gc3VidGFnIGNhbg0KICAgYWxzbyBiZSB1c2VkIHRvIGluZGljYXRlIHRo YXQgY29udGVudCBpcyBleHByZXNzZWQgaW4gYSB3YXkgdGhhdCBpcw0KICAgYXBwcm9wcmlhdGUg Zm9yIHVzZSB0aHJvdWdob3V0IGEgcmVnaW9uOyBmb3IgaW5zdGFuY2UsIFNwYW5pc2gNCiAgIGNv bnRlbnQgdGFpbG9yZWQgdG8gYmUgdXNlZnVsIHRocm91Z2hvdXQgTGF0aW4gQW1lcmljYS4NCg0K ICAgVGhlIGZvbGxvd2luZyBydWxlcyBhcHBseSB0byB0aGUgcmVnaW9uIHN1YnRhZ3M6DQoNCiAg IDEuICBSZWdpb24gc3VidGFncyBNVVNUIGZvbGxvdyBhbnkgbGFuZ3VhZ2UsIGV4dGVuZGVkIGxh bmd1YWdlLCBvcg0KICAgICAgIHNjcmlwdCBzdWJ0YWdzIGFuZCBNVVNUIHByZWNlZGUgYWxsIG90 aGVyIHN1YnRhZ3MuDQoNCiAgIDIuICBBbGwgdHdvIGNoYXJhY3RlciBzdWJ0YWdzIGZvbGxvd2lu ZyB0aGUgcHJpbWFyeSBzdWJ0YWcgd2VyZQ0KICAgICAgIGRlZmluZWQgaW4gdGhlIElBTkEgcmVn aXN0cnkgYWNjb3JkaW5nIHRvIHRoZSBhc3NpZ25tZW50cyBmb3VuZA0KICAgICAgIGluIFtJU08z MTY2XS0tIkNvZGVzIGZvciB0aGUgcmVwcmVzZW50YXRpb24gb2YgbmFtZXMgb2YgY291bnRyaWVz DQogICAgICAgYW5kIHRoZWlyIHN1YmRpdmlzaW9ucyAtIFBhcnQgMTogQ291bnRyeSBjb2RlcyIt LWFscGhhLTIgY291bnRyeQ0KICAgICAgIGNvZGVzIG9yIGFzc2lnbm1lbnRzIHN1YnNlcXVlbnRs eSBtYWRlIGJ5IHRoZSBJU08gMzE2Ng0KICAgICAgIG1haW50ZW5hbmNlIGFnZW5jeSBvciBnb3Zl cm5pbmcgc3RhbmRhcmRpemF0aW9uIGJvZGllcy4NCg0KICAgMy4gIEFsbCB0aHJlZSBjaGFyYWN0 ZXIgc3VidGFncyBjb25zaXN0aW5nIG9mIGRpZ2l0IChudW1lcmljKQ0KICAgICAgIGNoYXJhY3Rl cnMgZm9sbG93aW5nIHRoZSBwcmltYXJ5IHN1YnRhZyB3ZXJlIGRlZmluZWQgaW4gdGhlIElBTkEN CiAgICAgICByZWdpc3RyeSBhY2NvcmRpbmcgdG8gdGhlIGFzc2lnbm1lbnRzIGZvdW5kIGluIFVO IFN0YW5kYXJkDQogICAgICAgQ291bnRyeSBvciBBcmVhIENvZGVzIGZvciBTdGF0aXN0aWNhbCAg VXNlIFtVTl9NLjQ5XSBvcg0KICAgICAgIGFzc2lnbm1lbnRzIHN1YnNlcXVlbnRseSBtYWRlIGJ5 IHRoZSBnb3Zlcm5pbmcgc3RhbmRhcmRzIGJvZHkuDQogICAgICAgTm90ZSB0aGF0IG5vdCBhbGwg b2YgdGhlIFVOIE0uNDkgY29kZXMgYXJlIGRlZmluZWQgaW4gdGhlIElBTkENCiAgICAgICByZWdp c3RyeS4gIFRoZSBmb2xsb3dpbmcgcnVsZXMgZGVmaW5lIHdoaWNoIGNvZGVzIGFyZSBlbnRlcmVk DQogICAgICAgaW50byB0aGUgcmVnaXN0cnkgYXMgdmFsaWQgc3VidGFnczoNCg0KICAgICAgIEEu ICBVTiBudW1lcmljIGNvZGVzIGFzc2lnbmVkIHRvICdtYWNyby1nZW9ncmFwaGljYWwNCiAgICAg ICAgICAgKGNvbnRpbmVudGFsKScgb3Igc3ViLXJlZ2lvbnMgTVVTVCBiZSByZWdpc3RlcmVkIGlu IHRoZQ0KICAgICAgICAgICByZWdpc3RyeS4gIFRoZXNlIGNvZGVzIGFyZSBub3QgYXNzb2NpYXRl ZCB3aXRoIGFuIGFzc2lnbmVkDQogICAgICAgICAgIElTTyAzMTY2IGFscGhhLTIgY29kZSBhbmQg cmVwcmVzZW50IHN1cHJhLW5hdGlvbmFsIGFyZWFzLA0KICAgICAgICAgICB1c3VhbGx5IGNvdmVy aW5nIG1vcmUgdGhhbiBvbmUgbmF0aW9uLCBzdGF0ZSwgcHJvdmluY2UsIG9yDQogICAgICAgICAg IHRlcnJpdG9yeS4NCg0KICAgICAgIEIuICBVTiBudW1lcmljIGNvZGVzIGZvciAnZWNvbm9taWMg Z3JvdXBpbmdzJyBvciAnb3RoZXINCiAgICAgICAgICAgZ3JvdXBpbmdzJyBNVVNUIE5PVCBiZSBy ZWdpc3RlcmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5IGFuZA0KICAgICAgICAgICBNVVNUIE5PVCBi ZSB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncy4NCg0KICAgICAgIEMuICBVTiBudW1lcmljIGNv ZGVzIGZvciBjb3VudHJpZXMgb3IgYXJlYXMgd2l0aCBhbWJpZ3VvdXMgSVNPDQogICAgICAgICAg IDMxNjYgYWxwaGEtMiBjb2Rlcywgd2hlbiBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5LCBNVVNU IGJlDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIw MDYgICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNCiAgICAg ICAgICAgZGVmaW5lZCBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGluIFNlY3Rpb24gMy4zIGFuZCBN VVNUIGJlDQogICAgICAgICAgIHVzZWQgdG8gZm9ybSBsYW5ndWFnZSB0YWdzIHRoYXQgcmVwcmVz ZW50IHRoZSBjb3VudHJ5IG9yDQogICAgICAgICAgIHJlZ2lvbiBmb3Igd2hpY2ggdGhleSBhcmUg ZGVmaW5lZC4NCg0KICAgICAgIEQuICBVTiBudW1lcmljIGNvZGVzIGZvciBjb3VudHJpZXMgb3Ig YXJlYXMgZm9yIHdoaWNoIHRoZXJlIGlzIGFuDQogICAgICAgICAgIGFzc29jaWF0ZWQgSVNPIDMx NjYgYWxwaGEtMiBjb2RlIGluIHRoZSByZWdpc3RyeSBNVVNUIE5PVCBiZQ0KICAgICAgICAgICBl bnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5IGFuZCBNVVNUIE5PVCBiZSB1c2VkIHRvIGZvcm0NCiAg ICAgICAgICAgbGFuZ3VhZ2UgdGFncy4gIE5vdGUgdGhhdCB0aGUgSVNPIDMxNjYtYmFzZWQgc3Vi dGFnIGluIHRoZQ0KICAgICAgICAgICByZWdpc3RyeSBNVVNUIGFjdHVhbGx5IGJlIGFzc29jaWF0 ZWQgd2l0aCB0aGUgVU4gTS40OSBjb2RlIGluDQogICAgICAgICAgIHF1ZXN0aW9uLg0KDQogICAg ICAgRS4gIFVOIG51bWVyaWMgY29kZXMgYW5kIElTTyAzMTY2IGFscGhhLTIgY29kZXMgZm9yIGNv dW50cmllcyBvcg0KICAgICAgICAgICBhcmVhcyBsaXN0ZWQgYXMgZWxpZ2libGUgZm9yIHJlZ2lz dHJhdGlvbiBpbiBbaW5pdGlhbC0NCiAgICAgICAgICAgcmVnaXN0cnldIGJ1dCBub3QgcHJlc2Vu dGx5IHJlZ2lzdGVyZWQgTUFZIGJlIGVudGVyZWQgaW50bw0KICAgICAgICAgICB0aGUgSUFOQSBy ZWdpc3RyeSB2aWEgdGhlIHByb2Nlc3MgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy40Lg0KICAgICAg ICAgICBPbmNlIHJlZ2lzdGVyZWQsIHRoZXNlIGNvZGVzIE1BWSBiZSB1c2VkIHRvIGZvcm0gbGFu Z3VhZ2UNCiAgICAgICAgICAgdGFncy4NCg0KICAgICAgIEYuICBBbGwgb3RoZXIgVU4gbnVtZXJp YyBjb2RlcyBmb3IgY291bnRyaWVzIG9yIGFyZWFzIHdoaWNoIGRvDQogICAgICAgICAgIG5vdCBo YXZlIGFuIGFzc29jaWF0ZWQgSVNPIDMxNjYgYWxwaGEtMiBjb2RlIE1VU1QgTk9UIGJlDQogICAg ICAgICAgIGVudGVyZWQgaW50byB0aGUgcmVnaXN0cnkgYW5kIE1VU1QgTk9UIGJlIHVzZWQgdG8g Zm9ybQ0KICAgICAgICAgICBsYW5ndWFnZSB0YWdzLiAgRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgdGhlc2UgY29kZXMsIHNlZQ0KICAgICAgICAgICBTZWN0aW9uIDMuMy4NCg0KICAgNC4gIE5v dGU6IFRoZSBhbHBoYW51bWVyaWMgY29kZXMgaW4gQXBwZW5kaXggWCBvZiB0aGUgVU4gZG9jdW1l bnQNCiAgICAgICBNVVNUIE5PVCBiZSBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5IGFuZCBNVVNU IE5PVCBiZSB1c2VkIHRvDQogICAgICAgZm9ybSBsYW5ndWFnZSB0YWdzLiAgKEF0IHRoZSB0aW1l IHRoaXMgZG9jdW1lbnQgd2FzIGNyZWF0ZWQgdGhlc2UNCiAgICAgICB2YWx1ZXMgbWF0Y2ggdGhl IElTTyAzMTY2IGFscGhhLTIgY29kZXMuKQ0KDQogICA1LiAgVGhlcmUgTVVTVCBiZSBhdCBtb3N0 IG9uZSByZWdpb24gc3VidGFnIGluIGEgbGFuZ3VhZ2UgdGFnIGFuZCB0aGUNCiAgICAgICByZWdp b24gc3VidGFnIE1BWSBiZSBvbWl0dGVkLCBhcyB3aGVuIGl0IGFkZHMgbm8gZGlzdGluZ3Vpc2hp bmcNCiAgICAgICB2YWx1ZSB0byB0aGUgdGFnLg0KDQogICA2LiAgVGhlIHJlZ2lvbiBzdWJ0YWdz ICdBQScsICdRTSctJ1FaJywgJ1hBJy0nWFonLCBhbmQgJ1paJyBhcmUNCiAgICAgICByZXNlcnZl ZCBmb3IgcHJpdmF0ZSB1c2UgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoZXNlIHN1YnRhZ3MNCiAgICAg ICBjb3JyZXNwb25kIHRvIGNvZGVzIHJlc2VydmVkIGJ5IElTTyAzMTY2IGZvciBwcml2YXRlIHVz ZS4gIFRoZXNlDQogICAgICAgY29kZXMgTUFZIGJlIHVzZWQgZm9yIHByaXZhdGUgdXNlIHJlZ2lv biBzdWJ0YWdzIChpbnN0ZWFkIG9mDQogICAgICAgdXNpbmcgYSBwcml2YXRlIHVzZSBzdWJ0YWcg c2VxdWVuY2UpLiAgUGxlYXNlIHJlZmVyIHRvDQogICAgICAgU2VjdGlvbiA0LjUgZm9yIG1vcmUg aW5mb3JtYXRpb24gb24gcHJpdmF0ZSB1c2Ugc3VidGFncy4NCg0KICAgImRlLUNIIiByZXByZXNl bnRzIEdlcm1hbiAoJ2RlJykgYXMgdXNlZCBpbiBTd2l0emVybGFuZCAoJ0NIJykuDQoNCiAgICJz ci1MYXRuLUNTIiByZXByZXNlbnRzIFNlcmJpYW4gKCdzcicpIHdyaXR0ZW4gdXNpbmcgTGF0aW4g c2NyaXB0DQogICAoJ0xhdG4nKSBhcyB1c2VkIGluIFNlcmJpYSBhbmQgTW9udGVuZWdybyAoJ0NT JykuDQoNCiAgICJlcy00MTkiIHJlcHJlc2VudHMgU3BhbmlzaCAoJ2VzJykgYXBwcm9wcmlhdGUg dG8gdGhlIFVOLWRlZmluZWQNCiAgIExhdGluIEFtZXJpY2EgYW5kIENhcmliYmVhbiByZWdpb24g KCc0MTknKS4NCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5 IDEyLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0K DQoyLjIuNSAgVmFyaWFudCBTdWJ0YWdzDQoNCiAgIFZhcmlhbnQgc3VidGFncyBhcmUgdXNlZCB0 byBpbmRpY2F0ZSBhZGRpdGlvbmFsLCB3ZWxsLXJlY29nbml6ZWQNCiAgIHZhcmlhdGlvbnMgdGhh dCBkZWZpbmUgYSBsYW5ndWFnZSBvciBpdHMgZGlhbGVjdHMgd2hpY2ggYXJlIG5vdA0KICAgY292 ZXJlZCBieSBvdGhlciBhdmFpbGFibGUgc3VidGFncy4gIFRoZSBmb2xsb3dpbmcgcnVsZXMgYXBw bHkgdG8gdGhlDQogICB2YXJpYW50IHN1YnRhZ3M6DQoNCiAgIDEuICBWYXJpYW50IHN1YnRhZ3Mg YXJlIG5vdCBhc3NvY2lhdGVkIHdpdGggYW55IGV4dGVybmFsIHN0YW5kYXJkLg0KICAgICAgIFZh cmlhbnQgc3VidGFncyBhbmQgdGhlaXIgbWVhbmluZ3MgYXJlIGRlZmluZWQgYnkgdGhlDQogICAg ICAgcmVnaXN0cmF0aW9uIHByb2Nlc3MgZGVmaW5lZCBpbiBTZWN0aW9uIDMuNC4NCg0KICAgMi4g IFZhcmlhbnQgc3VidGFncyBNVVNUIGZvbGxvdyBhbGwgb2YgdGhlIG90aGVyIGRlZmluZWQgc3Vi dGFncywgYnV0DQogICAgICAgcHJlY2VkZSBhbnkgZXh0ZW5zaW9uIG9yIHByaXZhdGUgdXNlIHN1 YnRhZyBzZXF1ZW5jZXMuDQoNCiAgIDMuICBNb3JlIHRoYW4gb25lIHZhcmlhbnQgTUFZIGJlIHVz ZWQgdG8gZm9ybSB0aGUgbGFuZ3VhZ2UgdGFnLg0KDQogICA0LiAgVmFyaWFudCBzdWJ0YWdzIE1V U1QgYmUgcmVnaXN0ZXJlZCB3aXRoIElBTkEgYWNjb3JkaW5nIHRvIHRoZQ0KICAgICAgIHJ1bGVz IGluIFNlY3Rpb24gMy40IG9mIHRoaXMgZG9jdW1lbnQgYmVmb3JlIGJlaW5nIHVzZWQgdG8gZm9y bQ0KICAgICAgIGxhbmd1YWdlIHRhZ3MuICBJbiBvcmRlciB0byBkaXN0aW5ndWlzaCB2YXJpYW50 cyBmcm9tIG90aGVyIHR5cGVzDQogICAgICAgb2Ygc3VidGFncywgcmVnaXN0cmF0aW9ucyBNVVNU IG1lZXQgdGhlIGZvbGxvd2luZyBsZW5ndGggYW5kDQogICAgICAgY29udGVudCByZXN0cmljdGlv bnM6DQoNCiAgICAgICAxLiAgVmFyaWFudCBzdWJ0YWdzIHRoYXQgYmVnaW4gd2l0aCBhIGxldHRl ciAoYS16LCBBLVopIE1VU1QgYmUNCiAgICAgICAgICAgYXQgbGVhc3QgZml2ZSBjaGFyYWN0ZXJz IGxvbmcuDQoNCiAgICAgICAyLiAgVmFyaWFudCBzdWJ0YWdzIHRoYXQgYmVnaW4gd2l0aCBhIGRp Z2l0ICgwLTkpIE1VU1QgYmUgYXQNCiAgICAgICAgICAgbGVhc3QgZm91ciBjaGFyYWN0ZXJzIGxv bmcuDQoNCiAgIFZhcmlhbnQgc3VidGFnIHJlY29yZHMgaW4gdGhlIGxhbmd1YWdlIHN1YnRhZyBy ZWdpc3RyeSBNQVkgaW5jbHVkZQ0KICAgb25lIG9yIG1vcmUgJ1ByZWZpeCcgZmllbGRzLCB3aGlj aCBpbmRpY2F0ZXMgdGhlIGxhbmd1YWdlIHRhZyBvciB0YWdzDQogICB0aGF0IHdvdWxkIG1ha2Ug YSBzdWl0YWJsZSBwcmVmaXggKHdpdGggb3RoZXIgc3VidGFncywgYXMNCiAgIGFwcHJvcHJpYXRl KSBpbiBmb3JtaW5nIGEgbGFuZ3VhZ2UgdGFnIHdpdGggdGhlIHZhcmlhbnQuICBGb3INCiAgIGV4 YW1wbGUsIHRoZSBzdWJ0YWcgJ25lZGlzJyBoYXMgYSBQcmVmaXggb2YgInNsIiwgbWFraW5nIGl0 IHN1aXRhYmxlDQogICB0byBmb3JtIGxhbmd1YWdlIHRhZ3Mgc3VjaCBhcyAic2wtbmVkaXMiIGFu ZCAic2wtSVQtbmVkaXMiLCBidXQgbm90DQogICBzdWl0YWJsZSBmb3IgdXNlIGluIGEgdGFnIHN1 Y2ggYXMgInpoLW5lZGlzIiBvciAiaXQtSVQtbmVkaXMiLg0KDQogICAic2wtbmVkaXMiIHJlcHJl c2VudHMgdGhlIE5hdGlzb25lIG9yIE5hZGl6YSBkaWFsZWN0IG9mIFNsb3Zlbmlhbi4NCg0KICAg ImRlLUNILTE5OTYiIHJlcHJlc2VudHMgR2VybWFuIGFzIHVzZWQgaW4gU3dpdHplcmxhbmQgYW5k IGFzIHdyaXR0ZW4NCiAgIHVzaW5nIHRoZSBzcGVsbGluZyByZWZvcm0gYmVnaW5uaW5nIGluIHRo ZSB5ZWFyIDE5OTYgQy5FLg0KDQogICBNb3N0IHZhcmlhbnRzIHRoYXQgc2hhcmUgYSBwcmVmaXgg YXJlIG11dHVhbGx5IGV4Y2x1c2l2ZS4gIEZvcg0KICAgZXhhbXBsZSwgdGhlIEdlcm1hbiBvcnRo b2dyYXBoaWMgdmFyaWF0aW9ucyAnMTk5NicgYW5kICcxOTAxJyBTSE9VTEQNCiAgIE5PVCBiZSB1 c2VkIGluIHRoZSBzYW1lIHRhZywgYXMgdGhleSByZXByZXNlbnQgdGhlIGRhdGVzIG9mIGRpZmZl cmVudA0KICAgc3BlbGxpbmcgcmVmb3Jtcy4gIEEgdmFyaWFudCB0aGF0IGNhbiBtZWFuaW5nZnVs bHkgYmUgdXNlZCBpbg0KICAgY29tYmluYXRpb24gd2l0aCBhbm90aGVyIHZhcmlhbnQgU0hPVUxE IGluY2x1ZGUgYSAnUHJlZml4JyBmaWVsZCBpbg0KICAgaXRzIHJlZ2lzdHJ5IHJlY29yZCB0aGF0 IGxpc3RzIHRoYXQgb3RoZXIgdmFyaWFudC4gIEZvciBleGFtcGxlLCBpZg0KICAgYW5vdGhlciBH ZXJtYW4gdmFyaWFudCAnZXhhbXBsZScgd2VyZSBjcmVhdGVkIHRoYXQgbWFkZSBzZW5zZSB0byB1 c2UNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAw NiAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg IGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgSnVseSAyMDA1DQoNCg0KICAgd2l0 aCAnMTk5NicsIHRoZW4gJ2V4YW1wbGUnIHNob3VsZCBpbmNsdWRlIHR3byBQcmVmaXggZmllbGRz OiAiZGUiDQogICBhbmQgImRlLTE5OTYiLg0KDQoyLjIuNiAgRXh0ZW5zaW9uIFN1YnRhZ3MNCg0K ICAgRXh0ZW5zaW9ucyBwcm92aWRlIGEgbWVjaGFuaXNtIGZvciBleHRlbmRpbmcgbGFuZ3VhZ2Ug dGFncyBmb3IgdXNlIGluDQogICB2YXJpb3VzIGFwcGxpY2F0aW9ucy4gIFNlZTogU2VjdGlvbiAz LjYuICBUaGUgZm9sbG93aW5nIHJ1bGVzIGFwcGx5DQogICB0byBleHRlbnNpb25zOg0KDQogICAx LiAgIEV4dGVuc2lvbiBzdWJ0YWdzIGFyZSBzZXBhcmF0ZWQgZnJvbSB0aGUgb3RoZXIgc3VidGFn cyBkZWZpbmVkDQogICAgICAgIGluIHRoaXMgZG9jdW1lbnQgYnkgYSBzaW5nbGUtbGV0dGVyIHN1 YnRhZyAoInNpbmdsZXRvbiIpLiAgVGhlDQogICAgICAgIHNpbmdsZXRvbiBNVVNUIGJlIG9uZSBh bGxvY2F0ZWQgdG8gYSByZWdpc3RyYXRpb24gYXV0aG9yaXR5IHZpYQ0KICAgICAgICB0aGUgbWVj aGFuaXNtIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNiBhbmQgY2Fubm90IGJlIHRoZSBsZXR0ZXIN CiAgICAgICAgJ3gnLCB3aGljaCBpcyByZXNlcnZlZCBmb3IgcHJpdmF0ZSB1c2Ugc3VidGFnIHNl cXVlbmNlcy4NCg0KICAgMi4gICBOb3RlOiBQcml2YXRlIHVzZSBzdWJ0YWcgc2VxdWVuY2VzIHN0 YXJ0aW5nIHdpdGggdGhlIHNpbmdsZXRvbg0KICAgICAgICBzdWJ0YWcgJ3gnIGFyZSBkZXNjcmli ZWQgYmVsb3cuDQoNCiAgIDMuICAgQW4gZXh0ZW5zaW9uIE1VU1QgZm9sbG93IGF0IGxlYXN0IGEg cHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcuDQogICAgICAgIFRoYXQgaXMsIGEgbGFuZ3VhZ2UgdGFn IGNhbm5vdCBiZWdpbiB3aXRoIGFuIGV4dGVuc2lvbi4NCiAgICAgICAgRXh0ZW5zaW9ucyBleHRl bmQgbGFuZ3VhZ2UgdGFncywgdGhleSBkbyBub3Qgb3ZlcnJpZGUgb3IgcmVwbGFjZQ0KICAgICAg ICB0aGVtLiAgRm9yIGV4YW1wbGUsICJhLXZhbHVlIiBpcyBub3QgYSB3ZWxsLWZvcm1lZCBsYW5n dWFnZSB0YWcsDQogICAgICAgIHdoaWxlICJkZS1hLXZhbHVlIiBpcy4NCg0KICAgNC4gICBFYWNo IHNpbmdsZXRvbiBzdWJ0YWcgTVVTVCBhcHBlYXIgYXQgbW9zdCBvbmUgdGltZSBpbiBlYWNoIHRh Zw0KICAgICAgICAob3RoZXIgdGhhbiBhcyBhIHByaXZhdGUgdXNlIHN1YnRhZykuICBUaGF0IGlz LCBzaW5nbGV0b24NCiAgICAgICAgc3VidGFncyBNVVNUIE5PVCBiZSByZXBlYXRlZC4gIEZvciBl eGFtcGxlLCB0aGUgdGFnICJlbi1hLWJiYi1hLQ0KICAgICAgICBjY2MiIGlzIGludmFsaWQgYmVj YXVzZSB0aGUgc3VidGFnICdhJyBhcHBlYXJzIHR3aWNlLiAgTm90ZSB0aGF0DQogICAgICAgIHRo ZSB0YWcgImVuLWEtYmJiLXgtYS1jY2MiIGlzIHZhbGlkIGJlY2F1c2UgdGhlIHNlY29uZA0KICAg ICAgICBhcHBlYXJhbmNlIG9mIHRoZSBzaW5nbGV0b24gJ2EnIGlzIGluIGEgcHJpdmF0ZSB1c2Ug c2VxdWVuY2UuDQoNCiAgIDUuICAgRXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBtZWV0IGFsbCBvZiB0 aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUNCiAgICAgICAgY29udGVudCBhbmQgZm9ybWF0IG9mIHN1 YnRhZ3MgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQogICA2LiAgIEV4dGVuc2lvbiBzdWJ0 YWdzIE1VU1QgbWVldCB3aGF0ZXZlciByZXF1aXJlbWVudHMgYXJlIHNldCBieSB0aGUNCiAgICAg ICAgZG9jdW1lbnQgdGhhdCBkZWZpbmVzIHRoZWlyIHNpbmdsZXRvbiBwcmVmaXggYW5kIHdoYXRl dmVyDQogICAgICAgIHJlcXVpcmVtZW50cyBhcmUgcHJvdmlkZWQgYnkgdGhlIG1haW50YWluaW5n IGF1dGhvcml0eS4NCg0KICAgNy4gICBFYWNoIGV4dGVuc2lvbiBzdWJ0YWcgTVVTVCBiZSBmcm9t IHR3byB0byBlaWdodCBjaGFyYWN0ZXJzIGxvbmcNCiAgICAgICAgYW5kIGNvbnNpc3Qgc29sZWx5 IG9mIGxldHRlcnMgb3IgZGlnaXRzLCB3aXRoIGVhY2ggc3VidGFnDQogICAgICAgIHNlcGFyYXRl ZCBieSBhIHNpbmdsZSAnLScuDQoNCiAgIDguICAgRWFjaCBzaW5nbGV0b24gTVVTVCBiZSBmb2xs b3dlZCBieSBhdCBsZWFzdCBvbmUgZXh0ZW5zaW9uDQogICAgICAgIHN1YnRhZy4gIEZvciBleGFt cGxlLCB0aGUgdGFnICJ0bGgtYS1iLWZvbyIgaXMgaW52YWxpZCBiZWNhdXNlDQogICAgICAgIHRo ZSBmaXJzdCBzaW5nbGV0b24gJ2EnIGlzIGZvbGxvd2VkIGltbWVkaWF0ZWx5IGJ5IGFub3RoZXIN CiAgICAgICAgc2luZ2xldG9uICdiJy4NCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAg ICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAg ICAgIEp1bHkgMjAwNQ0KDQoNCiAgIDkuICAgRXh0ZW5zaW9uIHN1YnRhZ3MgTVVTVCBmb2xsb3cg YWxsIGxhbmd1YWdlLCBleHRlbmRlZCBsYW5ndWFnZSwNCiAgICAgICAgc2NyaXB0LCByZWdpb24g YW5kIHZhcmlhbnQgc3VidGFncyBpbiBhIHRhZy4NCg0KICAgMTAuICBBbGwgc3VidGFncyBmb2xs b3dpbmcgdGhlIHNpbmdsZXRvbiBhbmQgYmVmb3JlIGFub3RoZXIgc2luZ2xldG9uDQogICAgICAg IGFyZSBwYXJ0IG9mIHRoZSBleHRlbnNpb24uICBFeGFtcGxlOiBJbiB0aGUgdGFnICJmci1hLUxh dG4iLCB0aGUNCiAgICAgICAgc3VidGFnICdMYXRuJyBkb2VzIG5vdCByZXByZXNlbnQgdGhlIHNj cmlwdCBzdWJ0YWcgJ0xhdG4nDQogICAgICAgIGRlZmluZWQgaW4gdGhlIElBTkEgTGFuZ3VhZ2Ug U3VidGFnIFJlZ2lzdHJ5LiAgSXRzIG1lYW5pbmcgaXMNCiAgICAgICAgZGVmaW5lZCBieSB0aGUg ZXh0ZW5zaW9uICdhJy4NCg0KICAgMTEuICBJbiB0aGUgZXZlbnQgdGhhdCBtb3JlIHRoYW4gb25l IGV4dGVuc2lvbiBhcHBlYXJzIGluIGEgc2luZ2xlDQogICAgICAgIHRhZywgdGhlIHRhZyBTSE9V TEQgYmUgY2Fub25pY2FsaXplZCBhcyBkZXNjcmliZWQgaW4NCiAgICAgICAgU2VjdGlvbiA0LjQu DQoNCiAgIEZvciBleGFtcGxlLCBpZiB0aGUgcHJlZml4IHNpbmdsZXRvbiAncicgYW5kIHRoZSBz aG93biBzdWJ0YWdzIHdlcmUNCiAgIGRlZmluZWQsIHRoZW4gdGhlIGZvbGxvd2luZyB0YWcgd291 bGQgYmUgYSB2YWxpZCBleGFtcGxlOiAiZW4tTGF0bi0NCiAgIEdCLWJvb250LXItZXh0ZW5kZWQt c2VxdWVuY2UteC1wcml2YXRlIg0KDQoyLjIuNyAgUHJpdmF0ZSBVc2UgU3VidGFncw0KDQogICBQ cml2YXRlIHVzZSBzdWJ0YWdzIGFyZSB1c2VkIHRvIGluZGljYXRlIGRpc3RpbmN0aW9ucyBpbiBs YW5ndWFnZQ0KICAgaW1wb3J0YW50IGluIGEgZ2l2ZW4gY29udGV4dCBieSBwcml2YXRlIGFncmVl bWVudC4gIFRoZSBmb2xsb3dpbmcNCiAgIHJ1bGVzIGFwcGx5IHRvIHByaXZhdGUgdXNlIHN1YnRh Z3M6DQoNCiAgIDEuICBQcml2YXRlIHVzZSBzdWJ0YWdzIGFyZSBzZXBhcmF0ZWQgZnJvbSB0aGUg b3RoZXIgc3VidGFncyBkZWZpbmVkDQogICAgICAgaW4gdGhpcyBkb2N1bWVudCBieSB0aGUgcmVz ZXJ2ZWQgc2luZ2xlLWNoYXJhY3RlciBzdWJ0YWcgJ3gnLg0KDQogICAyLiAgUHJpdmF0ZSB1c2Ug c3VidGFncyBNVVNUIGNvbmZvcm0gdG8gdGhlIGZvcm1hdCBhbmQgY29udGVudA0KICAgICAgIGNv bnN0cmFpbnRzIGRlZmluZWQgaW4gdGhlIEFCTkYgZm9yIGFsbCBzdWJ0YWdzLg0KDQogICAzLiAg UHJpdmF0ZSB1c2Ugc3VidGFncyBNVVNUIGZvbGxvdyBhbGwgbGFuZ3VhZ2UsIGV4dGVuZGVkIGxh bmd1YWdlLA0KICAgICAgIHNjcmlwdCwgcmVnaW9uLCB2YXJpYW50LCBhbmQgZXh0ZW5zaW9uIHN1 YnRhZ3MgaW4gdGhlIHRhZy4NCiAgICAgICBBbm90aGVyIHdheSBvZiBzYXlpbmcgdGhpcyBpcyB0 aGF0IGFsbCBzdWJ0YWdzIGZvbGxvd2luZyB0aGUNCiAgICAgICBzaW5nbGV0b24gJ3gnIE1VU1Qg YmUgY29uc2lkZXJlZCBwcml2YXRlIHVzZS4gIEV4YW1wbGU6IFRoZQ0KICAgICAgIHN1YnRhZyAn VVMnIGluIHRoZSB0YWcgImVuLXgtVVMiIGlzIGEgcHJpdmF0ZSB1c2Ugc3VidGFnLg0KDQogICA0 LiAgQSB0YWcgTUFZIGNvbnNpc3QgZW50aXJlbHkgb2YgcHJpdmF0ZSB1c2Ugc3VidGFncy4NCg0K ICAgNS4gIE5vIHNvdXJjZSBpcyBkZWZpbmVkIGZvciBwcml2YXRlIHVzZSBzdWJ0YWdzLiAgVXNl IG9mIHByaXZhdGUgdXNlDQogICAgICAgc3VidGFncyBpcyBieSBwcml2YXRlIGFncmVlbWVudCBv bmx5Lg0KDQogICA2LiAgUHJpdmF0ZSB1c2Ugc3VidGFncyBhcmUgTk9UIFJFQ09NTUVOREVEIHdo ZXJlIGFsdGVybmF0aXZlcyBleGlzdA0KICAgICAgIG9yIGZvciBnZW5lcmFsIGludGVyY2hhbmdl LiAgU2VlIFNlY3Rpb24gNC41IGZvciBtb3JlIGluZm9ybWF0aW9uDQogICAgICAgb24gcHJpdmF0 ZSB1c2Ugc3VidGFnIGNob2ljZS4NCg0KICAgRm9yIGV4YW1wbGU6IFVzZXJzIHdobyB3aXNoZWQg dG8gdXRpbGl6ZSBjb2RlcyBmcm9tIHRoZSBFdGhub2xvZ3VlDQogICBwdWJsaWNhdGlvbiBvZiBT SUwgSW50ZXJuYXRpb25hbCBmb3IgbGFuZ3VhZ2UgaWRlbnRpZmljYXRpb24gbWlnaHQNCiAgIGFn cmVlIHRvIGV4Y2hhbmdlIHRhZ3Mgc3VjaCBhcyAiYXotQXJhYi14LUFaRS1kZXJiZW5kIi4gIFRo aXMgZXhhbXBsZQ0KICAgY29udGFpbnMgdHdvIHByaXZhdGUgdXNlIHN1YnRhZ3MuICBUaGUgZmly c3QgaXMgJ0FaRScgYW5kIHRoZSBzZWNvbmQNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAg IEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAg ICAgSnVseSAyMDA1DQoNCg0KICAgaXMgJ2RlcmJlbmQnLg0KDQoyLjIuOCAgUHJlLUV4aXN0aW5n IFJGQyAzMDY2IFJlZ2lzdHJhdGlvbnMNCg0KICAgRXhpc3RpbmcgSUFOQS1yZWdpc3RlcmVkIGxh bmd1YWdlIHRhZ3MgZnJvbSBSRkMgMTc2NiBhbmQvb3IgUkZDIDMwNjYNCiAgIG1haW50YWluIHRo ZWlyIHZhbGlkaXR5LiAgSUFOQSB3aWxsIG1haW50YWluIHRoZXNlIHRhZ3MgaW4gdGhlDQogICBy ZWdpc3RyeSB1bmRlciBlaXRoZXIgdGhlICJncmFuZGZhdGhlcmVkIiBvciAicmVkdW5kYW50IiB0 eXBlLiAgRm9yDQogICBtb3JlIGluZm9ybWF0aW9uIHNlZSBTZWN0aW9uIDMuNy4NCg0KICAgSXQg aXMgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCBhbGwgbGFuZ3VhZ2UgdGFncyBmb3JtZWQgdW5kZXIg dGhlDQogICBndWlkZWxpbmVzIGluIHRoaXMgZG9jdW1lbnQgd2VyZSBlaXRoZXIgbGVnYWwsIHdl bGwtZm9ybWVkIHRhZ3Mgb3INCiAgIGNvdWxkIGhhdmUgYmVlbiByZWdpc3RlcmVkIHVuZGVyIFJG QyAzMDY2Lg0KDQoyLjIuOSAgQ2xhc3NlcyBvZiBDb25mb3JtYW5jZQ0KDQogICBJbXBsZW1lbnRh dGlvbnMgc29tZXRpbWVzIG5lZWQgdG8gZGVzY3JpYmUgdGhlaXIgY2FwYWJpbGl0aWVzIHdpdGgN CiAgIHJlZ2FyZCB0byB0aGUgcnVsZXMgYW5kIHByYWN0aWNlcyBkZXNjcmliZWQgaW4gdGhpcyBk b2N1bWVudC4gIFRoZXJlDQogICBhcmUgdHdvIGNsYXNzZXMgb2YgY29uZm9ybWluZyBpbXBsZW1l bnRhdGlvbnMgZGVzY3JpYmVkIGJ5IHRoaXMNCiAgIGRvY3VtZW50OiAid2VsbC1mb3JtZWQiIHBy b2Nlc3NvcnMgYW5kICJ2YWxpZGF0aW5nIiBwcm9jZXNzb3JzLg0KICAgQ2xhaW1zIG9mIGNvbmZv cm1hbmNlIFNIT1VMRCBleHBsaWNpdGx5IHJlZmVyZW5jZSBvbmUgb2YgdGhlc2UNCiAgIGRlZmlu aXRpb25zLg0KDQogICBBbiBpbXBsZW1lbnRhdGlvbiB0aGF0IGNsYWltcyB0byBjaGVjayBmb3Ig d2VsbC1mb3JtZWQgbGFuZ3VhZ2UgdGFncw0KICAgTVVTVDoNCg0KICAgbyAgQ2hlY2sgdGhhdCB0 aGUgdGFnIGFuZCBhbGwgb2YgaXRzIHN1YnRhZ3MsIGluY2x1ZGluZyBleHRlbnNpb24gYW5kDQog ICAgICBwcml2YXRlIHVzZSBzdWJ0YWdzLCBjb25mb3JtIHRvIHRoZSBBQk5GIG9yIHRoYXQgdGhl IHRhZyBpcyBvbiB0aGUNCiAgICAgIGxpc3Qgb2YgZ3JhbmRmYXRoZXJlZCB0YWdzLg0KDQogICBv ICBDaGVjayB0aGF0IHNpbmdsZXRvbiBzdWJ0YWdzIHRoYXQgaWRlbnRpZnkgZXh0ZW5zaW9ucyBk byBub3QNCiAgICAgIHJlcGVhdC4gIEZvciBleGFtcGxlLCB0aGUgdGFnICJlbi1hLXh4LWIteXkt YS16eiIgaXMgbm90IHdlbGwtDQogICAgICBmb3JtZWQuDQoNCiAgIFdlbGwtZm9ybWVkIHByb2Nl c3NvcnMgYXJlIHN0cm9uZ2x5IGVuY291cmFnZWQgdG8gaW1wbGVtZW50IHRoZQ0KICAgY2Fub25p Y2FsaXphdGlvbiBydWxlcyBjb250YWluZWQgaW4gU2VjdGlvbiA0LjQuDQoNCiAgIEFuIGltcGxl bWVudGF0aW9uIHRoYXQgY2xhaW1zIHRvIGJlIHZhbGlkYXRpbmcgTVVTVDoNCg0KICAgbyAgQ2hl Y2sgdGhhdCB0aGUgdGFnIGlzIHdlbGwtZm9ybWVkLg0KDQogICBvICBTcGVjaWZ5IHRoZSBwYXJ0 aWN1bGFyIHJlZ2lzdHJ5IGRhdGUgZm9yIHdoaWNoIHRoZSBpbXBsZW1lbnRhdGlvbg0KICAgICAg cGVyZm9ybXMgdmFsaWRhdGlvbiBvZiBzdWJ0YWdzLg0KDQogICBvICBDaGVjayB0aGF0IGVpdGhl ciB0aGUgdGFnIGlzIGEgZ3JhbmRmYXRoZXJlZCB0YWcsIG9yIHRoYXQgYWxsDQogICAgICBsYW5n dWFnZSwgc2NyaXB0LCByZWdpb24sIGFuZCB2YXJpYW50IHN1YnRhZ3MgY29uc2lzdCBvZiB2YWxp ZA0KICAgICAgY29kZXMgZm9yIHVzZSBpbiBsYW5ndWFnZSB0YWdzIGFjY29yZGluZyB0byB0aGUg SUFOQSByZWdpc3RyeSBhcw0KICAgICAgb2YgdGhlIHBhcnRpY3VsYXIgZGF0ZSBzcGVjaWZpZWQg YnkgdGhlIGltcGxlbWVudGF0aW9uLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAxNl0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg IEp1bHkgMjAwNQ0KDQoNCiAgIG8gIFNwZWNpZnkgd2hpY2gsIGlmIGFueSwgZXh0ZW5zaW9uIFJG Q3MgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDMuNg0KICAgICAgYXJlIHN1cHBvcnRlZCwgaW5jbHVk aW5nIHZlcnNpb24sIHJldmlzaW9uLCBhbmQgZGF0ZS4NCg0KICAgbyAgRm9yIGFueSBzdWNoIGV4 dGVuc2lvbnMgc3VwcG9ydGVkLCBjaGVjayB0aGF0IGFsbCBzdWJ0YWdzIHVzZWQgaW4NCiAgICAg IHRoYXQgZXh0ZW5zaW9uIGFyZSB2YWxpZC4NCg0KICAgbyAgRm9yIHZhcmlhbnQgYW5kIGV4dGVu ZGVkIGxhbmd1YWdlIHN1YnRhZ3MsIGlmIHRoZSByZWdpc3RyeQ0KICAgICAgY29udGFpbnMgb25l IG9yIG1vcmUgJ1ByZWZpeCcgZmllbGRzIGZvciB0aGF0IHN1YnRhZywgY2hlY2sgdGhhdA0KICAg ICAgdGhlIHRhZyBtYXRjaGVzIGF0IGxlYXN0IG9uZSBwcmVmaXguICBUaGUgdGFnIG1hdGNoZXMg aWYgYWxsIHRoZQ0KICAgICAgc3VidGFncyBpbiB0aGUgJ1ByZWZpeCcgYWxzbyBhcHBlYXIgaW4g dGhlIHRhZy4gIEZvciBleGFtcGxlLCB0aGUNCiAgICAgIHByZWZpeCAiZXMtQ08iIG1hdGNoZXMg dGhlIHRhZyAiZXMtTGF0bi1DTy14LXByaXZhdGUiIGJlY2F1c2UgYm90aA0KICAgICAgdGhlICdl cycgbGFuZ3VhZ2Ugc3VidGFnIGFuZCAnQ08nIHJlZ2lvbiBzdWJ0YWcgYXBwZWFyIGluIHRoZSB0 YWcuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVz IEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkg MjAwNQ0KDQoNCjMuICBSZWdpc3RyeSBGb3JtYXQgYW5kIE1haW50ZW5hbmNlDQoNCiAgIFRoaXMg c2VjdGlvbiBkZWZpbmVzIHRoZSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkgYW5kIHRoZSBtYWlu dGVuYW5jZQ0KICAgYW5kIHVwZGF0ZSBwcm9jZWR1cmVzIGFzc29jaWF0ZWQgd2l0aCBpdC4NCg0K ICAgVGhlIGxhbmd1YWdlIHN1YnRhZyByZWdpc3RyeSB3aWxsIGJlIG1haW50YWluZWQgc28gdGhh dCwgZXhjZXB0IGZvcg0KICAgZXh0ZW5zaW9uIHN1YnRhZ3MsIGl0IGlzIHBvc3NpYmxlIHRvIHZh bGlkYXRlIGFsbCBvZiB0aGUgc3VidGFncyB0aGF0DQogICBhcHBlYXIgaW4gYSBsYW5ndWFnZSB0 YWcgdW5kZXIgdGhlIHByb3Zpc2lvbnMgb2YgdGhpcyBkb2N1bWVudCBvciBpdHMNCiAgIHJldmlz aW9ucyBvciBzdWNjZXNzb3JzLiAgSW4gYWRkaXRpb24sIHRoZSBtZWFuaW5nIG9mIHRoZSB2YXJp b3VzDQogICBzdWJ0YWdzIHdpbGwgYmUgdW5hbWJpZ3VvdXMgYW5kIHN0YWJsZSBvdmVyIHRpbWUu ICAoVGhlIG1lYW5pbmcgb2YNCiAgIHByaXZhdGUgdXNlIHN1YnRhZ3MsIG9mIGNvdXJzZSwgaXMg bm90IGRlZmluZWQgYnkgdGhlIElBTkEgcmVnaXN0cnkuKQ0KDQogICBUaGUgcmVnaXN0cnkgZGVm aW5lZCB1bmRlciB0aGlzIGRvY3VtZW50IGNvbnRhaW5zIGEgY29tcHJlaGVuc2l2ZQ0KICAgbGlz dCBvZiBhbGwgb2YgdGhlIHN1YnRhZ3MgdmFsaWQgaW4gbGFuZ3VhZ2UgdGFncy4gIFRoaXMgYWxs b3dzDQogICBpbXBsZW1lbnRlcnMgYSBzdHJhaWdodGZvcndhcmQgYW5kIHJlbGlhYmxlIHdheSB0 byB2YWxpZGF0ZSBsYW5ndWFnZQ0KICAgdGFncy4NCg0KMy4xICBGb3JtYXQgb2YgdGhlIElBTkEg TGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5DQoNCiAgIFRoZSBJQU5BIExhbmd1YWdlIFN1YnRhZyBS ZWdpc3RyeSAoInRoZSByZWdpc3RyeSIpIHdpbGwgY29uc2lzdCBvZiBhDQogICB0ZXh0IGZpbGUg dGhhdCBpcyBtYWNoaW5lIHJlYWRhYmxlIGluIHRoZSBmb3JtYXQgZGVzY3JpYmVkIGluIHRoaXMN CiAgIHNlY3Rpb24sIHBsdXMgY29waWVzIG9mIHRoZSByZWdpc3RyYXRpb24gZm9ybXMgYXBwcm92 ZWQgYnkgdGhlDQogICBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIgaW4gYWNjb3JkYW5jZSB3aXRo IHRoZSBwcm9jZXNzIGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjQuICBXaXRoIHRoZSBleGNl cHRpb24gb2YgdGhlIHJlZ2lzdHJhdGlvbiBmb3JtcyBmb3INCiAgIGdyYW5kZmF0aGVyZWQgYW5k IHJlZHVuZGFudCB0YWdzLCBubyByZWdpc3RyYXRpb24gcmVjb3JkcyB3aWxsIGJlDQogICBtYWlu dGFpbmVkIGZvciB0aGUgaW5pdGlhbCBzZXQgb2Ygc3VidGFncy4NCg0KICAgVGhlIHJlZ2lzdHJ5 IHdpbGwgYmUgaW4gYSBtb2RpZmllZCByZWNvcmQtamFyIGZvcm1hdCB0ZXh0IGZpbGUNCiAgIFty ZWNvcmQtamFyXS4gIExpbmVzIGFyZSBsaW1pdGVkIHRvIDcyIGNoYXJhY3RlcnMsIGluY2x1ZGlu ZyBhbGwNCiAgIHdoaXRlc3BhY2UuDQoNCiAgIFJlY29yZHMgYXJlIHNlcGFyYXRlZCBieSBsaW5l cyBjb250YWluaW5nIG9ubHkgdGhlIHNlcXVlbmNlICIlJSINCiAgICgleDI1LjI1KS4NCg0KICAg RWFjaCBmaWVsZCBjYW4gYmUgdmlld2VkIGFzIGEgc2luZ2xlLCBsb2dpY2FsIGxpbmUgIG9mIEFT Q0lJDQogICBjaGFyYWN0ZXJzLCAgY29tcHJpc2luZyBhIGZpZWxkLW5hbWUgYW5kIGEgZmllbGQt Ym9keSBzZXBhcmF0ZWQgYnkgYQ0KICAgQ09MT04gY2hhcmFjdGVyICgleDNBKS4gIEZvciBjb252 ZW5pZW5jZSwgdGhlIGZpZWxkLWJvZHkgcG9ydGlvbiAgb2YNCiAgIHRoaXMgIGNvbmNlcHR1YWwg ZW50aXR5ICBjYW4gYmUgc3BsaXQgaW50byBhIG11bHRpcGxlLWxpbmUNCiAgIHJlcHJlc2VudGF0 aW9uOyB0aGlzIGlzIGNhbGxlZCAiZm9sZGluZyIuICBUaGUgZm9ybWF0IG9mIHRoZSByZWdpc3Ry eQ0KICAgaXMgZGVzY3JpYmVkIGJ5IHRoZSBmb2xsb3dpbmcgQUJORiAocGVyIFtSRkMyMjM0Ymlz XSk6DQoNCiAgIHJlZ2lzdHJ5ICAgPSByZWNvcmQgKigiJSUiIENSTEYgcmVjb3JkKQ0KICAgcmVj b3JkICAgICA9IDEqKCBmaWVsZC1uYW1lICpTUCAiOiIgKlNQIGZpZWxkLWJvZHkgQ1JMRiApDQog ICBmaWVsZC1uYW1lID0gKihBTFBIQSAvIERJR0lUIC8gIi0iKQ0KICAgZmllbGQtYm9keSA9ICoo QVNDQ0hBUi9MV1NQKQ0KICAgQVNDQ0hBUiAgICA9ICV4MjEtMjUgLyAleDI3LTdFIC8gVU5JQ0hB UiA7IE5vdGU6IEFNUEVSU0FORCBpcyAleDI2DQogICBVTklDSEFSICAgID0gIiYjeCIgMio2SEVY RElHICI7Ig0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkg MTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAxOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoN CiAgIFRoZSBzZXF1ZW5jZSAnLi4nICgleDJFLjJFKSBpbiBhIGZpZWxkLWJvZHkgZGVub3RlcyBh IHJhbmdlIG9mDQogICB2YWx1ZXMuICBTdWNoIGEgcmFuZ2UgcmVwcmVzZW50cyBhbGwgc3VidGFn cyBvZiB0aGUgc2FtZSBsZW5ndGggdGhhdA0KICAgYXJlIGFscGhhYmV0aWNhbGx5IHdpdGhpbiB0 aGF0IHJhbmdlLCBpbmNsdWRpbmcgdGhlIHZhbHVlcyBleHBsaWNpdGx5DQogICBtZW50aW9uZWQu ICBGb3IgZXhhbXBsZSAnYS4uYycgZGVub3RlcyB0aGUgdmFsdWVzICdhJywgJ2InLCBhbmQgJ2Mn Lg0KDQogICBDaGFyYWN0ZXJzIGZyb20gb3V0c2lkZSB0aGUgVVMtQVNDSUkgcmVwZXJ0b2lyZSwg YXMgd2VsbCBhcyB0aGUNCiAgIEFNUEVSU0FORCBjaGFyYWN0ZXIgKCImIiwgJXgyNikgd2hlbiBp dCBvY2N1cnMgaW4gYSBmaWVsZC1ib2R5IGFyZQ0KICAgcmVwcmVzZW50ZWQgYnkgYSAiTnVtZXJp YyBDaGFyYWN0ZXIgUmVmZXJlbmNlIiB1c2luZyBoZXhhZGVjaW1hbA0KICAgbm90YXRpb24gaW4g dGhlIHN0eWxlIHVzZWQgYnkgW1hNTDEwXSAoc2VlDQogICA8aHR0cDovL3d3dy53My5vcmcvVFIv UkVDLXhtbC8jZHQtY2hhcnJlZj4pLiAgVGhpcyBjb25zaXN0cyBvZiB0aGUNCiAgIHNlcXVlbmNl ICImI3giICgleDI2LjIzLjc4KSBmb2xsb3dlZCBieSBhIGhleGFkZWNpbWFsIHJlcHJlc2VudGF0 aW9uDQogICBvZiB0aGUgY2hhcmFjdGVyJ3MgY29kZSBwb2ludCBpbiBbSVNPMTA2NDZdIGZvbGxv d2VkIGJ5IGEgY2xvc2luZw0KICAgc2VtaWNvbG9uICgleDNCKS4gIEZvciBleGFtcGxlLCB0aGUg RVVSTyBTSUdOLCBVKzIwQUMsIHdvdWxkIGJlDQogICByZXByZXNlbnRlZCBieSB0aGUgc2VxdWVu Y2UgIiYjeDIwQUM7Ii4gIE5vdGUgdGhhdCB0aGUgaGV4YWRlY2ltYWwNCiAgIG5vdGF0aW9uIE1B WSBoYXZlIGJldHdlZW4gdHdvIGFuZCBzaXggZGlnaXRzLg0KDQogICBBbGwgZmllbGRzIHdob3Nl IGZpZWxkLWJvZHkgY29udGFpbnMgYSBkYXRlIHZhbHVlIHVzZSB0aGUgImZ1bGwtZGF0ZSINCiAg IGZvcm1hdCBzcGVjaWZpZWQgaW4gW1JGQzMzMzldLiAgRm9yIGV4YW1wbGU6ICIyMDA0LTA2LTI4 IiByZXByZXNlbnRzDQogICBKdW5lIDI4LCAyMDA0IGluIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIu DQoNCiAgIFRoZSBmaXJzdCByZWNvcmQgaW4gdGhlIGZpbGUgY29udGFpbnMgdGhlIHNpbmdsZSBm aWVsZCB3aG9zZSBmaWVsZC0NCiAgIG5hbWUgaXMgIkZpbGUtRGF0ZSIuICBUaGUgZmllbGQtYm9k eSBvZiB0aGlzIHJlY29yZCBjb250YWlucyB0aGUgbGFzdA0KICAgbW9kaWZpY2F0aW9uIGRhdGUg b2YgdGhpcyBjb3B5IG9mIHRoZSByZWdpc3RyeSwgbWFraW5nIGl0IHBvc3NpYmxlIHRvDQogICBj b21wYXJlIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiB0aGUgcmVnaXN0cnkuICBUaGUgcmVnaXN0cnkg b24gdGhlIElBTkENCiAgIHdlYnNpdGUgaXMgdGhlIG1vc3QgY3VycmVudC4gIFZlcnNpb25zIHdp dGggYW4gb2xkZXIgZGF0ZSB0aGFuIHRoYXQNCiAgIG9uZSBhcmUgbm90IHVwLXRvLWRhdGUuDQoN CiAgIEZpbGUtRGF0ZTogMjAwNC0wNi0yOA0KICAgJSUNCg0KICAgU3Vic2VxdWVudCByZWNvcmRz IHJlcHJlc2VudCBzdWJ0YWdzIGluIHRoZSByZWdpc3RyeS4gIEVhY2ggb2YgdGhlDQogICBmaWVs ZHMgaW4gZWFjaCByZWNvcmQgTVVTVCBvY2N1ciBubyBtb3JlIHRoYW4gb25jZSwgdW5sZXNzIG90 aGVyd2lzZQ0KICAgbm90ZWQgYmVsb3cuICBFYWNoIHJlY29yZCBNVVNUIGNvbnRhaW4gdGhlIGZv bGxvd2luZyBmaWVsZHM6DQoNCiAgIG8gICdUeXBlJw0KDQogICAgICAqICBUeXBlJ3MgZmllbGQt dmFsdWUgTVVTVCBjb25zaXN0IG9mIG9uZSBvZiB0aGUgZm9sbG93aW5nDQogICAgICAgICBzdHJp bmdzOiAibGFuZ3VhZ2UiLCAiZXh0bGFuZyIsICJzY3JpcHQiLCAicmVnaW9uIiwgInZhcmlhbnQi LA0KICAgICAgICAgImdyYW5kZmF0aGVyZWQiLCBhbmQgInJlZHVuZGFudCIgYW5kIGRlbm90ZXMg dGhlIHR5cGUgb2YgdGFnIG9yDQogICAgICAgICBzdWJ0YWcuDQoNCiAgIG8gIEVpdGhlciAnU3Vi dGFnJyBvciAnVGFnJw0KDQogICAgICAqICBTdWJ0YWcncyBmaWVsZC12YWx1ZSBjb250YWlucyB0 aGUgc3VidGFnIGJlaW5nIGRlZmluZWQuICBUaGlzDQogICAgICAgICBmaWVsZCBNVVNUIG9ubHkg YXBwZWFyIGluIHJlY29yZHMgb2Ygd2hvc2UgVHlwZSBoYXMgb25lIG9mDQogICAgICAgICB0aGVz ZSB2YWx1ZXM6ICJsYW5ndWFnZSIsICJleHRsYW5nIiwgInNjcmlwdCIsICJyZWdpb24iLCBvcg0K ICAgICAgICAgInZhcmlhbnQiLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBp cmVzIEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAxOV0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1 bHkgMjAwNQ0KDQoNCiAgICAgICogIFRhZydzIGZpZWxkLXZhbHVlIGNvbnRhaW5zIGEgY29tcGxl dGUgbGFuZ3VhZ2UgdGFnLiAgVGhpcyBmaWVsZA0KICAgICAgICAgTVVTVCBvbmx5IGFwcGVhciBp biByZWNvcmRzIHdob3NlIFR5cGUgaGFzIG9uZSBvZiB0aGVzZSB2YWx1ZXM6DQogICAgICAgICAi Z3JhbmRmYXRoZXJlZCIgb3IgInJlZHVuZGFudCIuDQoNCiAgIG8gIERlc2NyaXB0aW9uDQoNCiAg ICAgICogIERlc2NyaXB0aW9uJ3MgZmllbGQtdmFsdWUgY29udGFpbnMgYSBub24tbm9ybWF0aXZl IGRlc2NyaXB0aW9uDQogICAgICAgICBvZiB0aGUgc3VidGFnIG9yIHRhZy4NCg0KICAgbyAgQWRk ZWQNCg0KICAgICAgKiAgQWRkZWQncyBmaWVsZC12YWx1ZSBjb250YWlucyB0aGUgZGF0ZSB0aGUg cmVjb3JkIHdhcyBhZGRlZCB0bw0KICAgICAgICAgdGhlIHJlZ2lzdHJ5Lg0KDQogICBUaGUgJ1N1 YnRhZycgb3IgJ1RhZycgZmllbGQgTVVTVCB1c2UgbG93ZXJjYXNlIGxldHRlcnMgdG8gZm9ybSB0 aGUNCiAgIHN1YnRhZyBvciB0YWcsIHdpdGggdHdvIGV4Y2VwdGlvbnMuICBTdWJ0YWdzIHdob3Nl ICdUeXBlJyBmaWVsZCBpcw0KICAgJ3NjcmlwdCcgKGluIG90aGVyIHdvcmRzLCBzdWJ0YWdzIGRl ZmluZWQgYnkgSVNPIDE1OTI0KSBNVVNUIHVzZQ0KICAgdGl0bGVjYXNlLiAgU3VidGFncyB3aG9z ZSAnVHlwZScgZmllbGQgaXMgJ3JlZ2lvbicgKGluIG90aGVyIHdvcmRzLA0KICAgc3VidGFncyBk ZWZpbmVkIGJ5IElTTyAzMTY2KSBNVVNUIHVzZSB1cHBlcmNhc2UuICBUaGVzZSBleGNlcHRpb25z DQogICBtaXJyb3IgdGhlIHVzZSBvZiBjYXNlIGluIHRoZSB1bmRlcmx5aW5nIHN0YW5kYXJkcy4N Cg0KICAgVGhlIGZpZWxkICdEZXNjcmlwdGlvbicgTUFZIGFwcGVhciBtb3JlIHRoYW4gb25lIHRp bWUuICBBdCBsZWFzdCBvbmUNCiAgIG9mIHRoZSAgJ0Rlc2NyaXB0aW9uJyBmaWVsZHMgTVVTVCBj b250YWluIGEgZGVzY3JpcHRpb24gb2YgdGhlIHRhZw0KICAgYmVpbmcgcmVnaXN0ZXJlZCB3cml0 dGVuIG9yIHRyYW5zY3JpYmVkIGludG8gdGhlIExhdGluIHNjcmlwdDsgdGhlDQogICBzYW1lIG9y IGFkZGl0aW9uYWwgZmllbGRzIE1BWSBhbHNvIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBpbiBhIG5v bi0NCiAgIExhdGluIHNjcmlwdC4gIFRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIGlzIHVzZWQgZm9y IGlkZW50aWZpY2F0aW9uDQogICBwdXJwb3NlcyBhbmQgU0hPVUxEIE5PVCBiZSB0YWtlbiB0byBy ZXByZXNlbnQgdGhlIGFjdHVhbCBuYXRpdmUgbmFtZQ0KICAgb2YgdGhlIGxhbmd1YWdlIG9yIHZh cmlhdGlvbiBvciB0byBiZSBpbiBhbnkgcGFydGljdWxhciBsYW5ndWFnZS4NCiAgIE1vc3QgZGVz Y3JpcHRpb25zIGFyZSB0YWtlbiBkaXJlY3RseSBmcm9tIHNvdXJjZSBzdGFuZGFyZHMgc3VjaCBh cw0KICAgSVNPIDYzOSBvciBJU08gMzE2Ni4NCg0KICAgTm90ZTogRGVzY3JpcHRpb25zIGluIHJl Z2lzdHJ5IGVudHJpZXMgdGhhdCBjb3JyZXNwb25kIHRvIElTTyA2MzksDQogICBJU08gMTU5MjQs ICBJU08gMzE2NiBvciBVTiBNLjQ5IGNvZGVzIGFyZSBpbnRlbmRlZCBvbmx5IHRvIGluZGljYXRl DQogICB0aGUgbWVhbmluZyBvZiB0aGF0IGlkZW50aWZpZXIgYXMgZGVmaW5lZCBpbiB0aGUgc291 cmNlIHN0YW5kYXJkIGF0DQogICB0aGUgdGltZSBpdCB3YXMgYWRkZWQgdG8gdGhlIHJlZ2lzdHJ5 LiAgVGhlIGRlc2NyaXB0aW9uIGRvZXMgbm90DQogICByZXBsYWNlIHRoZSBjb250ZW50IG9mIHRo ZSBzb3VyY2Ugc3RhbmRhcmQgaXRzZWxmLiAgVGhlIGRlc2NyaXB0aW9ucw0KICAgYXJlIG5vdCBp bnRlbmRlZCB0byBiZSB0aGUgRW5nbGlzaCBsb2NhbGl6ZWQgbmFtZXMgZm9yIHRoZSBzdWJ0YWdz Lg0KICAgTG9jYWxpemF0aW9uIG9yIHRyYW5zbGF0aW9uIG9mIGxhbmd1YWdlIHRhZyBhbmQgc3Vi dGFnIGRlc2NyaXB0aW9ucw0KICAgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoN CiAgIEVhY2ggcmVjb3JkIE1BWSBhbHNvIGNvbnRhaW4gdGhlIGZvbGxvd2luZyBmaWVsZHM6DQoN CiAgIG8gIFByZWZlcnJlZC1WYWx1ZQ0KDQogICAgICAqICBGb3IgZmllbGRzIG9mIHR5cGUgJ2xh bmd1YWdlJywgJ2V4dGxhbmcnLCAnc2NyaXB0JywgJ3JlZ2lvbicsDQogICAgICAgICBhbmQgJ3Zh cmlhbnQnLCAnUHJlZmVycmVkLVZhbHVlJyBjb250YWlucyBhIHN1YnRhZyBvZiB0aGUgc2FtZQ0K ICAgICAgICAgJ1R5cGUnIHdoaWNoIGlzIHByZWZlcnJlZCBmb3IgZm9ybWluZyB0aGUgbGFuZ3Vh Z2UgdGFnLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkg MTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAyMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoN CiAgICAgICogIEZvciBmaWVsZHMgb2YgdHlwZSAnZ3JhbmRmYXRoZXJlZCcgYW5kICdyZWR1bmRh bnQnLCBhIGNhbm9uaWNhbA0KICAgICAgICAgbWFwcGluZyB0byBhIGNvbXBsZXRlIGxhbmd1YWdl IHRhZy4NCg0KICAgbyAgRGVwcmVjYXRlZA0KDQogICAgICAqICBEZXByZWNhdGVkJ3MgZmllbGQt dmFsdWUgY29udGFpbnMgdGhlIGRhdGUgdGhlIHJlY29yZCB3YXMNCiAgICAgICAgIGRlcHJlY2F0 ZWQuDQoNCiAgIG8gIFByZWZpeA0KDQogICAgICAqICBQcmVmaXgncyBmaWVsZC12YWx1ZSBjb250 YWlucyBhIGxhbmd1YWdlIHRhZyB3aXRoIHdoaWNoIHRoaXMNCiAgICAgICAgIHN1YnRhZyBNQVkg YmUgdXNlZCB0byBmb3JtIGEgbmV3IGxhbmd1YWdlIHRhZywgcGVyaGFwcyB3aXRoDQogICAgICAg ICBvdGhlciBzdWJ0YWdzIGFzIHdlbGwuICBUaGlzIGZpZWxkIE1VU1Qgb25seSBhcHBlYXIgaW4g cmVjb3Jkcw0KICAgICAgICAgd2hvc2UgJ1R5cGUnIGZpZWxkLXZhbHVlIGlzICd2YXJpYW50JyBv ciAnZXh0bGFuZycuICBGb3INCiAgICAgICAgIGV4YW1wbGUsIHRoZSAnUHJlZml4JyBmb3IgdGhl IHZhcmlhbnQgJ25lZGlzJyBpcyAnc2wnLCBtZWFuaW5nDQogICAgICAgICB0aGF0IHRoZSB0YWdz ICJzbC1uZWRpcyIgYW5kICJzbC1JVC1uZWRpcyIgbWlnaHQgYmUgYXBwcm9wcmlhdGUNCiAgICAg ICAgIHdoaWxlIHRoZSB0YWcgImlzLW5lZGlzIiBpcyBub3QuDQoNCiAgIG8gIENvbW1lbnRzDQoN CiAgICAgICogIENvbW1lbnRzIGNvbnRhaW5zIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQg dGhlIHN1YnRhZywgYXMNCiAgICAgICAgIGRlZW1lZCBhcHByb3ByaWF0ZSBmb3IgdW5kZXJzdGFu ZGluZyB0aGUgcmVnaXN0cnkgYW5kDQogICAgICAgICBpbXBsZW1lbnRpbmcgbGFuZ3VhZ2UgdGFn cyB1c2luZyB0aGUgc3VidGFnIG9yIHRhZy4NCg0KICAgbyAgU3VwcHJlc3MtU2NyaXB0DQoNCiAg ICAgICogIFN1cHByZXNzLVNjcmlwdCBjb250YWlucyBhIHNjcmlwdCBzdWJ0YWcgdGhhdCBTSE9V TEQgTk9UIGJlDQogICAgICAgICB1c2VkIHRvIGZvcm0gbGFuZ3VhZ2UgdGFncyB3aXRoIHRoZSBh c3NvY2lhdGVkIHByaW1hcnkgbGFuZ3VhZ2UNCiAgICAgICAgIHN1YnRhZy4gIFRoaXMgZmllbGQg TVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBlJw0KICAgICAgICAgZmllbGQt dmFsdWUgaXMgJ2xhbmd1YWdlJy4gIFNlZSBTZWN0aW9uIDQuMS4NCg0KICAgVGhlIGZpZWxkICdE ZXByZWNhdGVkJyBNQVkgYmUgYWRkZWQgdG8gYW55IHJlY29yZCB2aWEgdGhlIG1haW50ZW5hbmNl DQogICBwcm9jZXNzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMiBvciB2aWEgdGhlIHJlZ2lzdHJh dGlvbiBwcm9jZXNzDQogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjQuICBVc3VhbGx5IHRoZSBh ZGRpdGlvbiBvZiBhICdEZXByZWNhdGVkJw0KICAgZmllbGQgaXMgZHVlIHRvIHRoZSBhY3Rpb24g b2Ygb25lIG9mIHRoZSBzdGFuZGFyZHMgYm9kaWVzLCBzdWNoIGFzDQogICBJU08gMzE2Niwgd2l0 aGRyYXdpbmcgYSBjb2RlLiAgSW4gc29tZSBoaXN0b3JpY2FsIGNhc2VzIGl0IG1pZ2h0IG5vdA0K ICAgaGF2ZSBiZWVuIHBvc3NpYmxlIHRvIHJlY29uc3RydWN0IHRoZSBvcmlnaW5hbCBkZXByZWNh dGlvbiBkYXRlLiAgRm9yDQogICB0aGVzZSBjYXNlcywgYW4gYXBwcm94aW1hdGUgZGF0ZSBhcHBl YXJzIGluIHRoZSByZWdpc3RyeS4gIEFsdGhvdWdoDQogICB2YWxpZCBpbiBsYW5ndWFnZSB0YWdz LCBzdWJ0YWdzIGFuZCB0YWdzIHdpdGggYSAnRGVwcmVjYXRlZCcgZmllbGQNCiAgIGFyZSBkZXBy ZWNhdGVkIGFuZCB2YWxpZGF0aW5nIHByb2Nlc3NvcnMgU0hPVUxEIE5PVCBnZW5lcmF0ZSB0aGVz ZQ0KICAgc3VidGFncy4gIE5vdGUgdGhhdCBhIHJlY29yZCB0aGF0IGNvbnRhaW5zIGEgJ0RlcHJl Y2F0ZWQnIGZpZWxkIGFuZA0KICAgbm8gY29ycmVzcG9uZGluZyAnUHJlZmVycmVkLVZhbHVlJyBm aWVsZCBoYXMgbm8gcmVwbGFjZW1lbnQgbWFwcGluZy4NCg0KICAgVGhlIGZpZWxkICdQcmVmZXJy ZWQtVmFsdWUnIGNvbnRhaW5zIGEgbWFwcGluZyBiZXR3ZWVuIHRoZSByZWNvcmQgaW4NCiAgIHdo aWNoIGl0IGFwcGVhcnMgYW5kIGEgdGFnIG9yIHN1YnRhZyB3aGljaCBTSE9VTEQgYmUgcHJlZmVy cmVkIHdoZW4NCiAgIHNlbGVjdGVkIGxhbmd1YWdlIHRhZ3MuICBUaGVzZSB2YWx1ZXMgZm9ybSB0 aHJlZSBncm91cHM6DQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBK YW51YXJ5IDEyLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjFdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICBKdWx5IDIw MDUNCg0KDQogICAgICBJU08gNjM5IGxhbmd1YWdlIGNvZGVzIHdoaWNoIHdlcmUgbGF0ZXIgd2l0 aGRyYXduIGluIGZhdm9yIG9mDQogICAgICBvdGhlciBjb2Rlcy4gIFRoZXNlIHZhbHVlcyBhcmUg bW9zdGx5IGEgaGlzdG9yaWNhbCBjdXJpb3NpdHkuDQoNCiAgICAgIElTTyAzMTY2IHJlZ2lvbiBj b2RlcyB3aGljaCBoYXZlIGJlZW4gd2l0aGRyYXduIGluIGZhdm9yIG9mIGEgbmV3DQogICAgICBj b2RlLiAgVGhpcyBzb21ldGltZXMgaGFwcGVucyB3aGVuIGEgY291bnRyeSBjaGFuZ2VzIGl0cyBu YW1lIG9yDQogICAgICBhZG1pbmlzdHJhdGlvbiBpbiBzdWNoIGEgd2F5IHRoYXQgd2FycmFudHMg YSBuZXcgcmVnaW9uIGNvZGUuDQoNCiAgICAgIFRhZ3MgZ3JhbmRmYXRoZXJlZCBmcm9tIFJGQyAz MDY2LiAgSW4gbWFueSBjYXNlcyB0aGVzZSB0YWdzIGhhdmUNCiAgICAgIGJlY29tZSBvYnNvbGV0 ZSBiZWNhdXNlIHRoZSB2YWx1ZXMgdGhleSByZXByZXNlbnQgd2VyZSBsYXRlcg0KICAgICAgZW5j b2RlZCBieSBJU08gNjM5Lg0KDQogICBSZWNvcmRzIHRoYXQgY29udGFpbiBhICdQcmVmZXJyZWQt VmFsdWUnIGZpZWxkIE1VU1QgYWxzbyBoYXZlIGENCiAgICdEZXByZWNhdGVkJyBmaWVsZC4gIFRo aXMgZmllbGQgY29udGFpbnMgYSBkYXRlIG9mIGRlcHJlY2F0aW9uLiAgVGh1cw0KICAgYSBsYW5n dWFnZSB0YWcgcHJvY2Vzc29yIGNhbiB1c2UgdGhlIHJlZ2lzdHJ5IHRvIGNvbnN0cnVjdCB0aGUg dmFsaWQsDQogICBub24tZGVwcmVjYXRlZCBzZXQgb2Ygc3VidGFncyBmb3IgYSBnaXZlbiBkYXRl LiAgSW4gYWRkaXRpb24sIGZvciBhbnkNCiAgIGdpdmVuIHRhZywgYSBwcm9jZXNzb3IgY2FuIGNv bnN0cnVjdCB0aGUgc2V0IG9mIHZhbGlkIGxhbmd1YWdlIHRhZ3MNCiAgIHRoYXQgY29ycmVzcG9u ZCB0byB0aGF0IHRhZyBmb3IgYWxsIGRhdGVzIHVwIHRvIHRoZSBkYXRlIG9mIHRoZQ0KICAgcmVn aXN0cnkuICBUaGUgYWJpbGl0eSB0byBkbyB0aGVzZSBtYXBwaW5ncyBNQVkgYmUgYmVuZWZpY2lh bCB0bw0KICAgYXBwbGljYXRpb25zIHRoYXQgYXJlIG1hdGNoaW5nLCBzZWxlY3RpbmcsIGZvciBm aWx0ZXJpbmcgY29udGVudA0KICAgYmFzZWQgb24gaXRzIGxhbmd1YWdlIHRhZ3MuDQoNCiAgIE5v dGUgdGhhdCAnUHJlZmVycmVkLVZhbHVlJyBtYXBwaW5ncyBpbiByZWNvcmRzIG9mIHR5cGUgJ3Jl Z2lvbicgTUFZDQogICBOT1QgcmVwcmVzZW50IGV4YWN0bHkgdGhlIHNhbWUgbWVhbmluZyBhcyB0 aGUgb3JpZ2luYWwgdmFsdWUuICBUaGVyZQ0KICAgYXJlIG1hbnkgcmVhc29ucyBmb3IgYSBjb3Vu dHJ5IGNvZGUgdG8gYmUgY2hhbmdlZCBhbmQgdGhlIGVmZmVjdCB0aGlzDQogICBoYXMgb24gdGhl IGZvcm1hdGlvbiBvZiBsYW5ndWFnZSB0YWdzIHdpbGwgZGVwZW5kIG9uIHRoZSBuYXR1cmUgb2YN CiAgIHRoZSBjaGFuZ2UgaW4gcXVlc3Rpb24uDQoNCiAgIEluIHBhcnRpY3VsYXIsIHRoZSAnUHJl ZmVycmVkLVZhbHVlJyBmaWVsZCBkb2VzIG5vdCBpbXBseSByZXRhZ2dpbmcNCiAgIGNvbnRlbnQg dGhhdCB1c2VzIHRoZSBhZmZlY3RlZCBzdWJ0YWcuDQoNCiAgIFRoZSBmaWVsZCAnUHJlZmVycmVk LVZhbHVlJyBNVVNUIE5PVCBiZSBtb2RpZmllZCBvbmNlIGNyZWF0ZWQgaW4gdGhlDQogICByZWdp c3RyeS4gIFRoZSBmaWVsZCBNQVkgYmUgYWRkZWQgdG8gcmVjb3JkcyBvZiB0eXBlICJncmFuZGZh dGhlcmVkIg0KICAgYW5kICJyZWdpb24iIGFjY29yZGluZyB0byB0aGUgcnVsZXMgaW4gU2VjdGlv biAzLjIuICBPdGhlcndpc2UgdGhlDQogICBmaWVsZCBNVVNUIE5PVCBiZSBhZGRlZCB0byBhbnkg cmVjb3JkIGFscmVhZHkgaW4gdGhlIHJlZ2lzdHJ5Lg0KDQogICBUaGUgJ1ByZWZlcnJlZC1WYWx1 ZScgZmllbGQgaW4gcmVjb3JkcyBvZiB0eXBlICJncmFuZGZhdGhlcmVkIiBhbmQNCiAgICJyZWR1 bmRhbnQiIGNvbnRhaW5zIHdob2xlIGxhbmd1YWdlIHRhZ3MgdGhhdCBhcmUgc3Ryb25nbHkNCiAg IFJFQ09NTUVOREVEIGZvciB1c2UgaW4gcGxhY2Ugb2YgdGhlIHJlY29yZCdzIHZhbHVlLiAgSW4g bWFueSBjYXNlcw0KICAgdGhlIG1hcHBpbmdzIHdlcmUgY3JlYXRlZCBieSBkZXByZWNhdGlvbiBv ZiB0aGUgdGFncyBkdXJpbmcgdGhlDQogICBwZXJpb2QgYmVmb3JlIHRoaXMgZG9jdW1lbnQgd2Fz IGFkb3B0ZWQuICBGb3IgZXhhbXBsZSwgdGhlIHRhZyAibm8tDQogICBueW4iIHdhcyBkZXByZWNh dGVkIGluIGZhdm9yIG9mIHRoZSBJU08gNjM5LTEgZGVmaW5lZCBsYW5ndWFnZSBjb2RlDQogICAn bm4nLg0KDQogICBSZWNvcmRzIG9mIHR5cGUgJ3ZhcmlhbnQnIE1BWSBoYXZlIG1vcmUgdGhhbiBv bmUgZmllbGQgb2YgdHlwZQ0KICAgJ1ByZWZpeCcuICBBZGRpdGlvbmFsIGZpZWxkcyBvZiB0aGlz IHR5cGUgTUFZIGJlIGFkZGVkIHRvIGEgJ3ZhcmlhbnQnDQogICByZWNvcmQgdmlhIHRoZSByZWdp c3RyYXRpb24gcHJvY2Vzcy4NCg0KICAgUmVjb3JkcyBvZiB0eXBlICdleHRsYW5nJyBNVVNUIGhh dmUgX2V4YWN0bHlfIG9uZSAnUHJlZml4JyBmaWVsZC4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDIyXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAg ICAgICAgICAgSnVseSAyMDA1DQoNCg0KICAgVGhlIGZpZWxkLXZhbHVlIG9mIHRoZSAnUHJlZml4 JyBmaWVsZCBjb25zaXN0cyBvZiBhIGxhbmd1YWdlIHRhZw0KICAgd2hvc2Ugc3VidGFncyBhcmUg YXBwcm9wcmlhdGUgdG8gdXNlIHdpdGggdGhpcyBzdWJ0YWcuICBGb3IgZXhhbXBsZSwNCiAgIHRo ZSB2YXJpYW50IHN1YnRhZyAnMTk5NicgaGFzIGEgUHJlZml4IGZpZWxkIG9mICJkZSIuICBUaGlz IG1lYW5zDQogICB0aGF0IHRhZ3Mgc3RhcnRpbmcgd2l0aCB0aGUgc2VxdWVuY2UgImRlLSIgYXJl IGFwcHJvcHJpYXRlIHdpdGggdGhpcw0KICAgc3VidGFnLCBzbyAiZGUtTGF0Zy0xOTk2IiBhbmQg ImRlLUNILTE5OTYiIGFyZSBib3RoIGFjY2VwdGFibGUsIHdoaWxlDQogICB0aGUgdGFnICJmci0x OTk2IiBpcyBhbiBpbmFwcHJvcHJpYXRlIGNob2ljZS4NCg0KICAgVGhlIGZpZWxkIG9mIHR5cGUg J1ByZWZpeCcgTVVTVCBOT1QgYmUgcmVtb3ZlZCBmcm9tIGFueSByZWNvcmQuICBUaGUNCiAgIGZp ZWxkLXZhbHVlIGZvciB0aGlzIHR5cGUgb2YgZmllbGQgTVVTVCBOT1QgYmUgbW9kaWZpZWQuDQoN CiAgIFRoZSBmaWVsZCAnQ29tbWVudHMnIE1BWSBhcHBlYXIgbW9yZSB0aGFuIG9uY2UgcGVyIHJl Y29yZC4gIFRoaXMNCiAgIGZpZWxkIE1BWSBiZSBpbnNlcnRlZCBvciBjaGFuZ2VkIHZpYSB0aGUg cmVnaXN0cmF0aW9uIHByb2Nlc3MgYW5kIG5vDQogICBndWFyYW50ZWUgb2Ygc3RhYmlsaXR5IGlz IHByb3ZpZGVkLiAgVGhlIGNvbnRlbnQgb2YgdGhpcyBmaWVsZCBpcyBub3QNCiAgIHJlc3RyaWN0 ZWQsIGV4Y2VwdCBieSB0aGUgbmVlZCB0byByZWdpc3RlciB0aGUgaW5mb3JtYXRpb24sIHRoZQ0K ICAgc3VpdGFiaWxpdHkgb2YgdGhlIHJlcXVlc3QsIGFuZCBieSByZWFzb25hYmxlIHByYWN0aWNh bCBzaXplDQogICBsaW1pdGF0aW9ucy4gIExvbmcgc2NyZWVkcyBhYm91dCBhIHBhcnRpY3VsYXIg c3VidGFnIGFyZSBmcm93bmVkDQogICB1cG9uLg0KDQogICBUaGUgZmllbGQgJ1N1cHByZXNzLVNj cmlwdCcgTVVTVCBvbmx5IGFwcGVhciBpbiByZWNvcmRzIHdob3NlICdUeXBlJw0KICAgZmllbGQt dmFsdWUgaXMgJ2xhbmd1YWdlJy4gIFRoaXMgZmllbGQgTUFZIGFwcGVhciBhdCBtb3N0IG9uZSB0 aW1lIGluDQogICBhIHJlY29yZC4gIFRoaXMgZmllbGQgaW5kaWNhdGVzIGEgc2NyaXB0IHVzZWQg dG8gd3JpdGUgdGhlDQogICBvdmVyd2hlbG1pbmcgbWFqb3JpdHkgb2YgZG9jdW1lbnRzIGZvciB0 aGUgZ2l2ZW4gbGFuZ3VhZ2UgYW5kIHdoaWNoDQogICB0aGVyZWZvcmUgYWRkcyBubyBkaXN0aW5n dWlzaGluZyBpbmZvcm1hdGlvbiB0byBhIGxhbmd1YWdlIHRhZy4gIEl0DQogICBoZWxwcyBlbnN1 cmUgZ3JlYXRlciBjb21wYXRpYmlsaXR5IGJldHdlZW4gdGhlIGxhbmd1YWdlIHRhZ3MNCiAgIGdl bmVyYXRlZCBhY2NvcmRpbmcgdG8gdGhlIHJ1bGVzIGluIHRoaXMgZG9jdW1lbnQgYW5kIGxhbmd1 YWdlIHRhZ3MNCiAgIGFuZCB0YWcgcHJvY2Vzc29ycyBvciBjb25zdW1lcnMgYmFzZWQgb24gUkZD IDMwNjYuICBGb3IgZXhhbXBsZSwNCiAgIHZpcnR1YWxseSBhbGwgSWNlbGFuZGljIGRvY3VtZW50 cyBhcmUgd3JpdHRlbiBpbiB0aGUgTGF0aW4gc2NyaXB0LA0KICAgbWFraW5nIHRoZSBzdWJ0YWcg J0xhdG4nIHJlZHVuZGFudCBpbiB0aGUgdGFnICJpcy1MYXRuIi4NCg0KMy4yICBNYWludGVuYW5j ZSBvZiB0aGUgUmVnaXN0cnkNCg0KICAgTWFpbnRlbmFuY2Ugb2YgdGhlIHJlZ2lzdHJ5IHJlcXVp cmVzIHRoYXQgYXMgY29kZXMgYXJlIGFzc2lnbmVkIG9yDQogICB3aXRoZHJhd24gYnkgSVNPIDYz OSwgSVNPIDE1OTI0LCBJU08gMzE2NiwgYW5kIFVOIE0uNDksIHRoZSBMYW5ndWFnZQ0KICAgU3Vi dGFnIFJldmlld2VyIHdpbGwgZXZhbHVhdGUgZWFjaCBjaGFuZ2UsIGRldGVybWluZSB3aGV0aGVy IGl0DQogICBjb25mbGljdHMgd2l0aCBleGlzdGluZyByZWdpc3RyeSBlbnRyaWVzLCBhbmQgc3Vi bWl0IHRoZSBpbmZvcm1hdGlvbg0KICAgdG8gSUFOQSBmb3IgaW5jbHVzaW9uIGluIHRoZSByZWdp c3RyeS4gIElmIGFuIGNoYW5nZSB0YWtlcyBwbGFjZSBhbmQNCiAgIHRoZSBMYW5ndWFnZSBTdWJ0 YWcgUmV2aWV3ZXIgZG9lcyBub3QgZG8gdGhpcyBpbiBhIHRpbWVseSBtYW5uZXIsDQogICB0aGVu IGFueSBpbnRlcmVzdGVkIHBhcnR5IE1BWSB1c2UgdGhlIHByb2NlZHVyZSBpbiBTZWN0aW9uIDMu NCB0bw0KICAgcmVnaXN0ZXIgdGhlIGFwcHJvcHJpYXRlIHVwZGF0ZS4NCg0KICAgTm90ZTogVGhl IHJlZHVuZGFudCBhbmQgZ3JhbmRmYXRoZXJlZCBlbnRyaWVzIHRvZ2V0aGVyIGFyZSB0aGUNCiAg IGNvbXBsZXRlIGxpc3Qgb2YgdGFncyByZWdpc3RlcmVkIHVuZGVyIFtSRkMzMDY2XS4gIFRoZSBy ZWR1bmRhbnQgdGFncw0KICAgYXJlIHRob3NlIHRoYXQgY2FuIG5vdyBiZSBmb3JtZWQgdXNpbmcg dGhlIHN1YnRhZ3MgZGVmaW5lZCBpbiB0aGUNCiAgIHJlZ2lzdHJ5IHRvZ2V0aGVyIHdpdGggdGhl IHJ1bGVzIG9mICBTZWN0aW9uIDIuMi4gIFRoZSBncmFuZGZhdGhlcmVkDQogICBlbnRyaWVzIGFy ZSB0aG9zZSB0aGF0IGNhbiBuZXZlciBiZSBsZWdhbCB1bmRlciB0aG9zZSBzYW1lDQogICBwcm92 aXNpb25zLg0KDQogICBUaGUgc2V0IG9mIHJlZHVuZGFudCBhbmQgZ3JhbmRmYXRoZXJlZCB0YWdz IGlzIHBlcm1hbmVudCBhbmQgc3RhYmxlOg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAg RXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMjNdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAg ICBKdWx5IDIwMDUNCg0KDQogICBubyBuZXcgZW50cmllcyB3aWxsIGJlIGFkZGVkIGFuZCBub25l IG9mIHRoZSBlbnRyaWVzIHdpbGwgYmUgcmVtb3ZlZC4NCiAgIFJlY29yZHMgb2YgdHlwZSAnZ3Jh bmRmYXRoZXJlZCcgTUFZIGhhdmUgdGhlaXIgdHlwZSBjb252ZXJ0ZWQgdG8NCiAgICdyZWR1bmRh bnQnOiBzZWUgIFNlY3Rpb24gMy43IGZvciBtb3JlIGluZm9ybWF0aW9uLg0KDQogICBSRkMgMzA2 NiB0YWdzIHRoYXQgd2VyZSBkZXByZWNhdGVkIHByaW9yIHRvIHRoZSBhZG9wdGlvbiBvZiB0aGlz DQogICBkb2N1bWVudCBhcmUgcGFydCBvZiB0aGUgbGlzdCBvZiBncmFuZGZhdGhlcmVkIHRhZ3Mg YW5kIHRoZWlyDQogICBjb21wb25lbnQgc3VidGFncyB3ZXJlIG5vdCBpbmNsdWRlZCBhcyByZWdp c3RlcmVkIHZhcmlhbnRzIChhbHRob3VnaA0KICAgdGhleSByZW1haW4gZWxpZ2libGUgZm9yIHJl Z2lzdHJhdGlvbikuICBGb3IgZXhhbXBsZSwgdGhlIHRhZyAiYXJ0LQ0KICAgbG9qYmFuIiB3YXMg ZGVwcmVjYXRlZCBpbiBmYXZvciBvZiB0aGUgbGFuZ3VhZ2Ugc3VidGFnICdqYm8nLg0KDQogICBU aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIE1VU1QgZW5zdXJlIHRoYXQgbmV3IHN1YnRhZ3Mg bWVldCB0aGUNCiAgIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDQuMSBvciBzdWJtaXQgYW4gYXBw cm9wcmlhdGUgYWx0ZXJuYXRlIHN1YnRhZw0KICAgYXMgZGVzY3JpYmVkIGluIHRoYXQgc2VjdGlv bi4gIFdoZW4gZWl0aGVyIGEgY2hhbmdlIG9yIGFkZGl0aW9uIHRvDQogICB0aGUgcmVnaXN0cnkg aXMgbmVlZGVkLCB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJldmlld2VyIE1VU1QgcHJlcGFyZSB0aGUN CiAgIGNvbXBsZXRlIHJlY29yZCwgaW5jbHVkaW5nIGFsbCBmaWVsZHMsIGFuZCBmb3J3YXJkIGl0 IHRvIElBTkEgZm9yDQogICBpbnNlcnRpb24gaW50byB0aGUgcmVnaXN0cnkuDQoNCiAgIElmIHJl Y29yZCByZXByZXNlbnRzIGEgbmV3IHN1YnRhZyB0aGF0IGRvZXMgbm90IGN1cnJlbnRseSBleGlz dCBpbg0KICAgdGhlIHJlZ2lzdHJ5LCB0aGVuIHRoZSBtZXNzYWdlJ3Mgc3ViamVjdCBsaW5lIE1V U1QgaW5jbHVkZSB0aGUgd29yZA0KICAgIklOU0VSVCIuICBJZiB0aGUgcmVjb3JkIHJlcHJlc2Vu dHMgYSBjaGFuZ2UgdG8gYW4gZXhpc3Rpbmcgc3VidGFnLA0KICAgdGhlbiB0aGUgc3ViamVjdCBs aW5lIG9mIHRoZSBtZXNzYWdlIE1VU1QgaW5jbHVkZSB0aGUgd29yZCAiTU9ESUZZIi4NCiAgIFRo ZSBtZXNzYWdlIE1VU1QgY29udGFpbiBib3RoIHRoZSByZWNvcmQgZm9yIHRoZSBzdWJ0YWcgYmVp bmcNCiAgIGluc2VydGVkIG9yIG1vZGlmaWVkIGFuZCB0aGUgbmV3IEZpbGUtRGF0ZSByZWNvcmQu ICBIZXJlIGlzIGFuDQogICBleGFtcGxlIG9mIHdoYXQgdGhlIGJvZHkgb2YgdGhlIG1lc3NhZ2Ug bWlnaHQgY29udGFpbjoNCg0KICAgTEFOR1VBR0UgU1VCVEFHIE1PRElGSUNBVElPTg0KICAgRmls ZS1EYXRlOiAyMDA1LTAxLTAyDQogICAlJQ0KICAgVHlwZTogdmFyaWFudA0KICAgU3VidGFnOiBu ZWRpcw0KICAgRGVzY3JpcHRpb246IE5hdGlzb25lIGRpYWxlY3QNCiAgIERlc2NyaXB0aW9uOiBO YWRpemEgZGlhbGVjdA0KICAgQWRkZWQ6IDIwMDMtMTAtMDkNCiAgIFByZWZpeDogc2wNCiAgIENv bW1lbnRzOiBUaGlzIGlzIGEgY29tbWVudCBzaG93bg0KICAgICBhcyBhbiBleGFtcGxlLg0KICAg JSUNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDQNCg0KICAgV2hl bmV2ZXIgYW4gZW50cnkgaXMgY3JlYXRlZCBvciBtb2RpZmllZCBpbiB0aGUgcmVnaXN0cnksIHRo ZSAnRmlsZS0NCiAgIERhdGUnIHJlY29yZCBhdCB0aGUgc3RhcnQgb2YgdGhlIHJlZ2lzdHJ5IGlz IHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGUNCiAgIG1vc3QgcmVjZW50IG1vZGlmaWNhdGlvbiBkYXRl IGluIHRoZSBbUkZDMzMzOV0gImZ1bGwtZGF0ZSIgZm9ybWF0Lg0KDQogICBWYWx1ZXMgaW4gdGhl ICdTdWJ0YWcnIGZpZWxkIE1VU1QgYmUgbG93ZXJjYXNlIGV4Y2VwdCBhcyBwcm92aWRlZCBmb3IN CiAgIGluIFNlY3Rpb24gMy4xLg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4 cGlyZXMgSmFudWFyeSAxMiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDI0XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAg SnVseSAyMDA1DQoNCg0KMy4zICBTdGFiaWxpdHkgb2YgSUFOQSBSZWdpc3RyeSBFbnRyaWVzDQoN CiAgIFRoZSBzdGFiaWxpdHkgb2YgZW50cmllcyBhbmQgdGhlaXIgbWVhbmluZyBpbiB0aGUgcmVn aXN0cnkgaXMNCiAgIGNyaXRpY2FsIHRvIHRoZSBsb25nIHRlcm0gc3RhYmlsaXR5IG9mIGxhbmd1 YWdlIHRhZ3MuICBUaGUgcnVsZXMgaW4NCiAgIHRoaXMgc2VjdGlvbiBndWFyYW50ZWUgdGhhdCBh IHNwZWNpZmljIGxhbmd1YWdlIHRhZydzIG1lYW5pbmcgaXMNCiAgIHN0YWJsZSBvdmVyIHRpbWUg YW5kIHdpbGwgbm90IGNoYW5nZS4NCg0KICAgVGhlc2UgcnVsZXMgc3BlY2lmaWNhbGx5IGRlYWwg d2l0aCBob3cgY2hhbmdlcyB0byBjb2RlcyAoaW5jbHVkaW5nDQogICB3aXRoZHJhd2FsIGFuZCBk ZXByZWNhdGlvbiBvZiBjb2RlcykgbWFpbnRhaW5lZCBieSBJU08gNjM5LCBJU08NCiAgIDE1OTI0 LCBJU08gMzE2NiwgYW5kIFVOIE0uNDkgYXJlIHJlZmxlY3RlZCBpbiB0aGUgSUFOQSBMYW5ndWFn ZQ0KICAgU3VidGFnIFJlZ2lzdHJ5LiAgQXNzaWdubWVudHMgdG8gdGhlIElBTkEgTGFuZ3VhZ2Ug U3VidGFnIFJlZ2lzdHJ5DQogICBNVVNUIGZvbGxvdyB0aGUgZm9sbG93aW5nIHN0YWJpbGl0eSBy dWxlczoNCg0KICAgMS4gICBWYWx1ZXMgaW4gdGhlIGZpZWxkcyAnVHlwZScsICdTdWJ0YWcnLCAn VGFnJywgJ0FkZGVkJywNCiAgICAgICAgJ0RlcHJlY2F0ZWQnIGFuZCAnUHJlZmVycmVkLVZhbHVl JyBNVVNUIE5PVCBiZSBjaGFuZ2VkIGFuZCBhcmUNCiAgICAgICAgZ3VhcmFudGVlZCB0byBiZSBz dGFibGUgb3ZlciB0aW1lLg0KDQogICAyLiAgIFZhbHVlcyBpbiB0aGUgJ0Rlc2NyaXB0aW9uJyBm aWVsZCBNVVNUIE5PVCBiZSBjaGFuZ2VkIGluIGEgd2F5DQogICAgICAgIHRoYXQgd291bGQgaW52 YWxpZGF0ZSBwcmV2aW91c2x5LWV4aXN0aW5nIHRhZ3MuICBUaGV5IE1BWSBiZQ0KICAgICAgICBi cm9hZGVuZWQgc29tZXdoYXQgaW4gc2NvcGUsIGNoYW5nZWQgdG8gYWRkIGluZm9ybWF0aW9uLCBv cg0KICAgICAgICBhZGFwdGVkIHRvIHRoZSBtb3N0IGNvbW1vbiBtb2Rlcm4gdXNhZ2UuICBGb3Ig ZXhhbXBsZSwgY291bnRyaWVzDQogICAgICAgIG9jY2FzaW9uYWxseSBjaGFuZ2UgdGhlaXIgb2Zm aWNpYWwgbmFtZXM6IGFuIGhpc3RvcmljYWwgZXhhbXBsZQ0KICAgICAgICBvZiB0aGlzIHdvdWxk IGJlICJVcHBlciBWb2x0YSIgY2hhbmdpbmcgdG8gIkJ1cmtpbmEgRmFzbyIuDQoNCiAgIDMuICAg VmFsdWVzIGluIHRoZSBmaWVsZCAnUHJlZml4JyBNQVkgYmUgYWRkZWQgdG8gcmVjb3JkcyBvZiB0 eXBlDQogICAgICAgICd2YXJpYW50JyB2aWEgdGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLg0KDQog ICA0LiAgIFZhbHVlcyBpbiB0aGUgZmllbGQgJ1ByZWZpeCcgTUFZIGJlIG1vZGlmaWVkLCBzbyBs b25nIGFzIHRoZQ0KICAgICAgICBtb2RpZmljYXRpb25zIGJyb2FkZW4gdGhlIHNldCBvZiBwcmVm aXhlcy4gIFRoYXQgaXMsIGEgcHJlZml4DQogICAgICAgIE1BWSBiZSByZXBsYWNlZCBieSBvbmUg b2YgaXRzIG93biBwcmVmaXhlcy4gIEZvciBleGFtcGxlLCB0aGUNCiAgICAgICAgcHJlZml4ICJl bi1VUyIgY291bGQgYmUgcmVwbGFjZWQgYnkgImVuIiwgYnV0IG5vdCBieSB0aGUNCiAgICAgICAg cHJlZml4ZXMgImVuLUxhdG4iLCAiZnIiLCBvciAiZW4tVVMtYm9vbnQiLiAgSWYgb25lIG9mIHRo b3NlDQogICAgICAgIHByZWZpeGVzIHdlcmUgbmVlZGVkLCBhIG5ldyBQcmVmaXggU0hPVUxEIGJl IHJlZ2lzdGVyZWQuDQoNCiAgIDUuICAgVmFsdWVzIGluIHRoZSBmaWVsZCAnUHJlZml4JyBNVVNU IE5PVCBiZSByZW1vdmVkLg0KDQogICA2LiAgIFRoZSBmaWVsZCAnQ29tbWVudHMnIE1BWSBiZSBh ZGRlZCwgY2hhbmdlZCwgbW9kaWZpZWQsIG9yIHJlbW92ZWQNCiAgICAgICAgdmlhIHRoZSByZWdp c3RyYXRpb24gcHJvY2VzcyBvciBhbnkgb2YgdGhlIHByb2Nlc3NlcyBvcg0KICAgICAgICBjb25z aWRlcmF0aW9ucyBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uLg0KDQogICA3LiAgIFRoZSBmaWVs ZCAnU3VwcHJlc3MtU2NyaXB0JyBNQVkgYmUgYWRkZWQgb3IgcmVtb3ZlZCB2aWEgdGhlDQogICAg ICAgIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLg0KDQogICA4LiAgIENvZGVzIGFzc2lnbmVkIGJ5IElT TyA2MzksIElTTyAxNTkyNCwgYW5kIElTTyAzMTY2IHRoYXQgZG8gbm90DQogICAgICAgIGNvbmZs aWN0IHdpdGggZXhpc3Rpbmcgc3VidGFncyBvZiB0aGUgYXNzb2NpYXRlZCB0eXBlIGFuZCB3aG9z ZQ0KICAgICAgICBtZWFuaW5nIGlzIG5vdCB0aGUgc2FtZSBhcyBhbiBleGlzdGluZyBzdWJ0YWcg b2YgdGhlIHNhbWUgdHlwZQ0KICAgICAgICBhcmUgZW50ZXJlZCBpbnRvIHRoZSBJQU5BIHJlZ2lz dHJ5IGFzIG5ldyByZWNvcmRzLg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBp cmVzIEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAyNV0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1 bHkgMjAwNQ0KDQoNCiAgIDkuICAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDYzOSwgSVNPIDE1OTI0 LCBvciBJU08gMzE2NiB0aGF0IGFyZQ0KICAgICAgICB3aXRoZHJhd24gYnkgdGhlaXIgcmVzcGVj dGl2ZSBtYWludGVuYW5jZSBvciByZWdpc3RyYXRpb24NCiAgICAgICAgYXV0aG9yaXR5IHJlbWFp biB2YWxpZCBpbiBsYW5ndWFnZSB0YWdzLiAgQSAnRGVwcmVjYXRlZCcgZmllbGQNCiAgICAgICAg Y29udGFpbmluZyB0aGUgZGF0ZSBvZiB3aXRoZHJhd2FsIGlzIGFkZGVkIHRvIHRoZSByZWNvcmQu ICBJZiBhDQogICAgICAgIG5ldyByZWNvcmQgb2YgdGhlIHNhbWUgdHlwZSBpcyBhZGRlZCB0aGF0 IHJlcHJlc2VudHMgYQ0KICAgICAgICByZXBsYWNlbWVudCB2YWx1ZSwgdGhlbiBhICdQcmVmZXJy ZWQtVmFsdWUnIGZpZWxkIE1BWSBhbHNvIGJlDQogICAgICAgIGFkZGVkLiAgVGhlIHJlZ2lzdHJh dGlvbiBwcm9jZXNzIE1BWSBiZSB1c2VkIHRvIGFkZCBjb21tZW50cw0KICAgICAgICBhYm91dCB0 aGUgd2l0aGRyYXdhbCBvZiB0aGUgY29kZSBieSB0aGUgcmVzcGVjdGl2ZSBzdGFuZGFyZC4NCg0K ICAgICAgICAxLiAgVGhlIHJlZ2lvbiBjb2RlICdUTCcgd2FzIGFzc2lnbmVkIHRvIHRoZSBjb3Vu dHJ5ICdUaW1vci0NCiAgICAgICAgICAgIExlc3RlJywgcmVwbGFjaW5nIHRoZSBjb2RlICdUUCcg KHdoaWNoIHdhcyBhc3NpZ25lZCB0byAnRWFzdA0KICAgICAgICAgICAgVGltb3InIHdoZW4gaXQg d2FzIHVuZGVyIGFkbWluaXN0cmF0aW9uIGJ5IFBvcnR1Z2FsKS4gIFRoZQ0KICAgICAgICAgICAg c3VidGFnICdUUCcgcmVtYWlucyB2YWxpZCBpbiBsYW5ndWFnZSB0YWdzLCBidXQgaXRzIHJlY29y ZA0KICAgICAgICAgICAgY29udGFpbnMgdGhlIGEgJ1ByZWZlcnJlZC1WYWx1ZScgb2YgJ1RMJyBh bmQgaXRzIGZpZWxkDQogICAgICAgICAgICAnRGVwcmVjYXRlZCcgY29udGFpbnMgdGhlIGRhdGUg dGhlIG5ldyBjb2RlIHdhcyBhc3NpZ25lZA0KICAgICAgICAgICAgKCcyMDA0LTA3LTA2JykuDQoN CiAgIDEwLiAgQ29kZXMgYXNzaWduZWQgYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBvciBJU08gMzE2 NiB0aGF0IGNvbmZsaWN0DQogICAgICAgIHdpdGggZXhpc3Rpbmcgc3VidGFncyBvZiB0aGUgYXNz b2NpYXRlZCB0eXBlLCBpbmNsdWRpbmcgc3VidGFncw0KICAgICAgICB0aGF0IGFyZSBkZXByZWNh dGVkLCBNVVNUIE5PVCBiZSBlbnRlcmVkIGludG8gdGhlIHJlZ2lzdHJ5LiAgVGhlDQogICAgICAg IGZvbGxvd2luZyBhZGRpdGlvbmFsIGNvbnNpZGVyYXRpb25zIGFwcGx5IHRvIHN1YnRhZyB2YWx1 ZXMgdGhhdA0KICAgICAgICBhcmUgcmVhc3NpZ25lZDoNCg0KICAgICAgICBBLiAgRm9yIElTTyA2 MzkgY29kZXMsIGlmIHRoZSBuZXdseSBhc3NpZ25lZCBjb2RlJ3MgbWVhbmluZyBpcw0KICAgICAg ICAgICAgbm90IHJlcHJlc2VudGVkIGJ5IGEgc3VidGFnIGluIHRoZSBJQU5BIHJlZ2lzdHJ5LCB0 aGUNCiAgICAgICAgICAgIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciwgYXMgZGVzY3JpYmVkIGlu IFNlY3Rpb24gMy40LCBTSEFMTA0KICAgICAgICAgICAgcHJlcGFyZSBhIHByb3Bvc2FsIGZvciBl bnRlcmluZyBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcyBzb29uDQogICAgICAgICAgICBhcyBwcmFj dGljYWwgYSByZWdpc3RlcmVkIGxhbmd1YWdlIHN1YnRhZyBhcyBhbiBhbHRlcm5hdGUNCiAgICAg ICAgICAgIHZhbHVlIGZvciB0aGUgbmV3IGNvZGUuICBUaGUgZm9ybSBvZiB0aGUgcmVnaXN0ZXJl ZCBsYW5ndWFnZQ0KICAgICAgICAgICAgc3VidGFnIHdpbGwgYmUgYXQgdGhlIGRpc2NyZXRpb24g b2YgdGhlIExhbmd1YWdlIFN1YnRhZw0KICAgICAgICAgICAgUmV2aWV3ZXIgYW5kIE1VU1QgY29u Zm9ybSB0byBvdGhlciByZXN0cmljdGlvbnMgb24gbGFuZ3VhZ2UNCiAgICAgICAgICAgIHN1YnRh Z3MgaW4gdGhpcyBkb2N1bWVudC4NCg0KICAgICAgICBCLiAgRm9yIGFsbCBzdWJ0YWdzIHdob3Nl IG1lYW5pbmcgaXMgZGVyaXZlZCBmcm9tIGFuIGV4dGVybmFsDQogICAgICAgICAgICBzdGFuZGFy ZCAoaS5lLiAgSVNPIDYzOSwgSVNPIDE1OTI0LCBJU08gMzE2Niwgb3IgVU4gTS40OSksDQogICAg ICAgICAgICBpZiBhIG5ldyBtZWFuaW5nIGlzIGFzc2lnbmVkIHRvIGFuIGV4aXN0aW5nIGNvZGUg YW5kIHRoZSBuZXcNCiAgICAgICAgICAgIG1lYW5pbmcgYnJvYWRlbnMgdGhlIG1lYW5pbmcgb2Yg dGhhdCBjb2RlLCB0aGVuIHRoZSBtZWFuaW5nDQogICAgICAgICAgICBmb3IgdGhlIGFzc29jaWF0 ZWQgc3VidGFnIE1BWSBiZSBjaGFuZ2VkIHRvIG1hdGNoLiAgVGhlDQogICAgICAgICAgICBtZWFu aW5nIG9mIGEgc3VidGFnIE1VU1QgTk9UIGJlIG5hcnJvd2VkLCBob3dldmVyLCBhcyB0aGlzDQog ICAgICAgICAgICBjYW4gcmVzdWx0IGluIGFuIHVua25vd24gcHJvcG9ydGlvbiBvZiB0aGUgZXhp c3RpbmcgdXNlcyBvZg0KICAgICAgICAgICAgYSBzdWJ0YWcgYmVjb21pbmcgaW52YWxpZC4gIE5v dGU6IElTTyA2MzkgTUEvUkEgaGFzIGFkb3B0ZWQNCiAgICAgICAgICAgIGEgc2ltaWxhciBzdGFi aWxpdHkgcG9saWN5Lg0KDQogICAgICAgIEMuICBGb3IgSVNPIDE1OTI0IGNvZGVzLCBpZiB0aGUg bmV3bHkgYXNzaWduZWQgY29kZSdzIG1lYW5pbmcgaXMNCiAgICAgICAgICAgIG5vdCByZXByZXNl bnRlZCBieSBhIHN1YnRhZyBpbiB0aGUgSUFOQSByZWdpc3RyeSwgdGhlDQogICAgICAgICAgICBM YW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXIsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNCwgU0hB TEwNCiAgICAgICAgICAgIHByZXBhcmUgYSBwcm9wb3NhbCBmb3IgZW50ZXJpbmcgaW4gdGhlIElB TkEgcmVnaXN0cnkgYXMgc29vbg0KICAgICAgICAgICAgYXMgcHJhY3RpY2FsIGEgcmVnaXN0ZXJl ZCB2YXJpYW50IHN1YnRhZyBhcyBhbiBhbHRlcm5hdGUNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMg ICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDI2XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAg ICAgICAgICAgSnVseSAyMDA1DQoNCg0KICAgICAgICAgICAgdmFsdWUgZm9yIHRoZSBuZXcgY29k ZS4gIFRoZSBmb3JtIG9mIHRoZSByZWdpc3RlcmVkIHZhcmlhbnQNCiAgICAgICAgICAgIHN1YnRh ZyB3aWxsIGJlIGF0IHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBMYW5ndWFnZSBTdWJ0YWcNCiAgICAg ICAgICAgIFJldmlld2VyIGFuZCBNVVNUIGNvbmZvcm0gdG8gb3RoZXIgcmVzdHJpY3Rpb25zIG9u IHZhcmlhbnQNCiAgICAgICAgICAgIHN1YnRhZ3MgaW4gdGhpcyBkb2N1bWVudC4NCg0KICAgICAg ICBELiAgRm9yIElTTyAzMTY2IGNvZGVzLCBpZiB0aGUgbmV3bHkgYXNzaWduZWQgY29kZSdzIG1l YW5pbmcgaXMNCiAgICAgICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2FtZSBVTiBNLjQ5IGNv ZGUgYXMgYW5vdGhlciAncmVnaW9uJw0KICAgICAgICAgICAgc3VidGFnLCB0aGVuIHRoZSBleGlz dGluZyByZWdpb24gc3VidGFnIHJlbWFpbnMgYXMgdGhlDQogICAgICAgICAgICBwcmVmZXJyZWQg dmFsdWUgZm9yIHRoYXQgcmVnaW9uIGFuZCBubyBuZXcgZW50cnkgaXMgY3JlYXRlZC4NCiAgICAg ICAgICAgIEEgY29tbWVudCBNQVkgYmUgYWRkZWQgdG8gdGhlIGV4aXN0aW5nIHJlZ2lvbiBzdWJ0 YWcNCiAgICAgICAgICAgIGluZGljYXRpbmcgdGhlIHJlbGF0aW9uc2hpcCB0byB0aGUgbmV3IElT TyAzMTY2IGNvZGUuDQoNCiAgICAgICAgRS4gIEZvciBJU08gMzE2NiBjb2RlcywgaWYgdGhlIG5l d2x5IGFzc2lnbmVkIGNvZGUncyBtZWFuaW5nIGlzDQogICAgICAgICAgICBhc3NvY2lhdGVkIHdp dGggYSBVTiBNLjQ5IGNvZGUgdGhhdCBpcyBub3QgcmVwcmVzZW50ZWQgYnkgYW4NCiAgICAgICAg ICAgIGV4aXN0aW5nIHJlZ2lvbiBzdWJ0YWcsIHRoZW4gdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZp ZXdlciwNCiAgICAgICAgICAgIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuNCwgU0hBTEwgcHJl cGFyZSBhIHByb3Bvc2FsIGZvcg0KICAgICAgICAgICAgZW50ZXJpbmcgdGhlIGFwcHJvcHJpYXRl IFVOIE0uNDkgY291bnRyeSBjb2RlIGFzIGFuIGVudHJ5IGluDQogICAgICAgICAgICB0aGUgSUFO QSByZWdpc3RyeS4NCg0KICAgICAgICBGLiAgRm9yIElTTyAzMTY2IGNvZGVzLCBpZiB0aGVyZSBp cyBubyBhc3NvY2lhdGVkIFVOIG51bWVyaWMNCiAgICAgICAgICAgIGNvZGUsIHRoZW4gdGhlIExh bmd1YWdlIFN1YnRhZyBSZXZpZXdlciBTSEFMTCBwZXRpdGlvbiB0aGUNCiAgICAgICAgICAgIFVO IHRvIGNyZWF0ZSBvbmUuICBJZiB0aGVyZSBpcyBubyByZXNwb25zZSBmcm9tIHRoZSBVTg0KICAg ICAgICAgICAgd2l0aGluIG5pbmV0eSBkYXlzIG9mIHRoZSByZXF1ZXN0IGJlaW5nIHNlbnQsIHRo ZSBMYW5ndWFnZQ0KICAgICAgICAgICAgU3VidGFnIFJldmlld2VyIFNIQUxMIHByZXBhcmUgYSBw cm9wb3NhbCBmb3IgZW50ZXJpbmcgaW4gdGhlDQogICAgICAgICAgICBJQU5BIHJlZ2lzdHJ5IGFz IHNvb24gYXMgcHJhY3RpY2FsIGEgcmVnaXN0ZXJlZCB2YXJpYW50DQogICAgICAgICAgICBzdWJ0 YWcgYXMgYW4gYWx0ZXJuYXRlIHZhbHVlIGZvciB0aGUgbmV3IGNvZGUuICBUaGUgZm9ybSBvZg0K ICAgICAgICAgICAgdGhlIHJlZ2lzdGVyZWQgdmFyaWFudCBzdWJ0YWcgd2lsbCBiZSBhdCB0aGUg ZGlzY3JldGlvbiBvZg0KICAgICAgICAgICAgdGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBh bmQgTVVTVCBjb25mb3JtIHRvIG90aGVyDQogICAgICAgICAgICByZXN0cmljdGlvbnMgb24gdmFy aWFudCBzdWJ0YWdzIGluIHRoaXMgZG9jdW1lbnQuICBUaGlzDQogICAgICAgICAgICBzaXR1YXRp b24gaXMgdmVyeSB1bmxpa2VseSB0byBldmVyIG9jY3VyLg0KDQogICAxMS4gIFVOIE0uNDkgaGFz IGNvZGVzIGZvciBib3RoIGNvdW50cmllcyBhbmQgYXJlYXMgKHN1Y2ggYXMgJzI3NicNCiAgICAg ICAgZm9yIEdlcm1hbnkpIGFuZCBnZW9ncmFwaGljYWwgcmVnaW9ucyBhbmQgc3ViLXJlZ2lvbnMg KHN1Y2ggYXMNCiAgICAgICAgJzE1MCcgZm9yIEV1cm9wZSkuICBVTiBNLjQ5IGNvdW50cnkgb3Ig YXJlYSBjb2RlcyBmb3Igd2hpY2gNCiAgICAgICAgdGhlcmUgaXMgbm8gY29ycmVzcG9uZGluZyBJ U08gMzE2NiBjb2RlIFNIT1VMRCBOT1QgYmUNCiAgICAgICAgcmVnaXN0ZXJlZCwgZXhjZXB0IGFz IGEgc3Vycm9nYXRlIGZvciBhbiBJU08gMzE2NiBjb2RlIHRoYXQgaXMNCiAgICAgICAgYmxvY2tl ZCBmcm9tIHJlZ2lzdHJhdGlvbiBieSBhbiBleGlzdGluZyBzdWJ0YWcuICBJZiBzdWNoIGEgY29k ZQ0KICAgICAgICBiZWNvbWVzIG5lY2Vzc2FyeSwgdGhlbiB0aGUgcmVnaXN0cmF0aW9uIGF1dGhv cml0eSBmb3IgSVNPIDMxNjYNCiAgICAgICAgU0hPVUxEIGZpcnN0IGJlIHBldGl0aW9uZWQgdG8g YXNzaWduIGEgY29kZSB0byB0aGUgcmVnaW9uLiAgSWYNCiAgICAgICAgdGhlIHBldGl0aW9uIGZv ciBhIGNvZGUgYXNzaWdubWVudCBieSBJU08gMzE2NiBpcyByZWZ1c2VkIG9yIG5vdA0KICAgICAg ICBhY3RlZCBvbiBpbiBhIHRpbWVseSBtYW5uZXIsIHRoZSByZWdpc3RyYXRpb24gcHJvY2VzcyBk ZXNjcmliZWQNCiAgICAgICAgaW4gU2VjdGlvbiAzLjQgTUFZIHRoZW4gYmUgdXNlZCB0byByZWdp c3RlciB0aGUgY29ycmVzcG9uZGluZyBVTg0KICAgICAgICBNLjQ5IGNvZGUuICBBdCB0aGUgdGlt ZSB0aGlzIGRvY3VtZW50IHdhcyB3cml0dGVuLCB0aGVyZSB3ZXJlDQogICAgICAgIG9ubHkgZm91 ciBzdWNoIGNvZGVzOiA4MzAgKENoYW5uZWwgSXNsYW5kcyksIDgzMSAoR3Vlcm5zZXkpLCA4MzIN CiAgICAgICAgKEplcnNleSksIGFuZCA4MzMgKElzbGUgb2YgTWFuKS4gIFRoaXMgd2F5IFVOIE0u NDkgY29kZXMgcmVtYWluDQogICAgICAgIGF2YWlsYWJsZSBhcyB0aGUgdmFsdWUgb2YgbGFzdCBy ZXNvcnQgaW4gY2FzZXMgd2hlcmUgSVNPIDMxNjYNCiAgICAgICAgcmVhc3NpZ25zIGEgZGVwcmVj YXRlZCB2YWx1ZSBpbiB0aGUgcmVnaXN0cnkuDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDI3XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICAgICAgSnVseSAyMDA1DQoNCg0KICAgMTIuICBTdGFiaWxpdHkgcHJvdmlzaW9ucyBhcHBseSB0 byBncmFuZGZhdGhlcmVkIHRhZ3Mgd2l0aCB0aGlzDQogICAgICAgIGV4Y2VwdGlvbjogc2hvdWxk IGFsbCBvZiB0aGUgc3VidGFncyBpbiBhIGdyYW5kZmF0aGVyZWQgdGFnDQogICAgICAgIGJlY29t ZSB2YWxpZCBzdWJ0YWdzIGluIHRoZSBJQU5BIHJlZ2lzdHJ5LCB0aGVuIHRoZSBmaWVsZCAnVHlw ZScNCiAgICAgICAgaW4gdGhhdCByZWNvcmQgaXMgY2hhbmdlZCBmcm9tICdncmFuZGZhdGhlcmVk JyB0byAncmVkdW5kYW50Jy4NCiAgICAgICAgTm90ZSB0aGF0IHRoaXMgd2lsbCBub3QgYWZmZWN0 IGxhbmd1YWdlIHRhZ3MgdGhhdCBtYXRjaCB0aGUNCiAgICAgICAgZ3JhbmRmYXRoZXJlZCB0YWcs IHNpbmNlIHRoZXNlIHRhZ3Mgd2lsbCBub3cgbWF0Y2ggdmFsaWQNCiAgICAgICAgZ2VuZXJhdGl2 ZSBzdWJ0YWcgc2VxdWVuY2VzLiAgRm9yIGV4YW1wbGUsIGlmIHRoZSBzdWJ0YWcgJ2dhbicNCiAg ICAgICAgaW4gdGhlIGxhbmd1YWdlIHRhZyAiemgtZ2FuIiB3ZXJlIHRvIGJlIHJlZ2lzdGVyZWQg YXMgYW4NCiAgICAgICAgZXh0ZW5kZWQgbGFuZ3VhZ2Ugc3VidGFnLCB0aGVuIHRoZSBncmFuZGZh dGhlcmVkIHRhZyAiemgtZ2FuIg0KICAgICAgICB3b3VsZCBiZSBkZXByZWNhdGVkIChidXQgZXhp c3RpbmcgY29udGVudCBvciBpbXBsZW1lbnRhdGlvbnMNCiAgICAgICAgdGhhdCB1c2UgInpoLWdh biIgd291bGQgcmVtYWluIHZhbGlkKS4NCg0KDQozLjQgIFJlZ2lzdHJhdGlvbiBQcm9jZWR1cmUg Zm9yIFN1YnRhZ3MNCg0KICAgVGhlIHByb2NlZHVyZSBnaXZlbiBoZXJlIE1VU1QgYmUgdXNlZCBi eSBhbnlvbmUgd2hvIHdhbnRzIHRvIHVzZSBhDQogICBzdWJ0YWcgbm90IGN1cnJlbnRseSBpbiB0 aGUgSUFOQSBMYW5ndWFnZSBTdWJ0YWcgUmVnaXN0cnkuDQoNCiAgIE9ubHkgc3VidGFncyAgb2Yg dHlwZSAnbGFuZ3VhZ2UnIGFuZCAndmFyaWFudCcgd2lsbCBiZSBjb25zaWRlcmVkIGZvcg0KICAg aW5kZXBlbmRlbnQgcmVnaXN0cmF0aW9uIG9mIG5ldyBzdWJ0YWdzLiAgSGFuZGxpbmcgb2Ygc3Vi dGFncyBuZWVkZWQNCiAgIGZvciBzdGFiaWxpdHkgYW5kIHN1YnRhZ3MgbmVjZXNzYXJ5IHRvIGtl ZXAgdGhlIHJlZ2lzdHJ5IHN5bmNocm9uaXplZA0KICAgd2l0aCBJU08gNjM5LCBJU08gMTU5MjQs IElTTyAzMTY2LCBhbmQgVU4gTS40OSB3aXRoaW4gdGhlIGxpbWl0cw0KICAgZGVmaW5lZCBieSB0 aGlzIGRvY3VtZW50IGFyZSBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjIuICBTdGFiaWxpdHkNCiAg IHByb3Zpc2lvbnMgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMy4NCg0KICAgVGhpcyBwcm9j ZWR1cmUgTUFZIGFsc28gYmUgdXNlZCB0byByZWdpc3RlciBvciBhbHRlciB0aGUgaW5mb3JtYXRp b24NCiAgIGZvciB0aGUgIkRlc2NyaXB0aW9uIiwgIkNvbW1lbnRzIiwgIkRlcHJlY2F0ZWQiLCBv ciAiUHJlZml4IiBmaWVsZHMNCiAgIGluIGEgc3VidGFnJ3MgcmVjb3JkIGFzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDMuMy4gIENoYW5nZXMgdG8gYWxsDQogICBvdGhlciBmaWVsZHMgaW4gdGhlIElB TkEgcmVnaXN0cnkgYXJlIE5PVCBwZXJtaXR0ZWQuDQoNCiAgIFJlZ2lzdGVyaW5nIGEgbmV3IHN1 YnRhZyBvciByZXF1ZXN0aW5nIG1vZGlmaWNhdGlvbnMgdG8gYW4gZXhpc3RpbmcNCiAgIHRhZyBv ciBzdWJ0YWcgc3RhcnRzIHdpdGggdGhlIHJlcXVlc3RlciBmaWxsaW5nIG91dCB0aGUgcmVnaXN0 cmF0aW9uDQogICBmb3JtIHJlcHJvZHVjZWQgYmVsb3cuICBOb3RlIHRoYXQgZWFjaCByZXNwb25z ZSBpcyBub3QgbGltaXRlZCBpbg0KICAgc2l6ZSBzbyB0aGF0IHRoZSByZXF1ZXN0IGNhbiBhZGVx dWF0ZWx5IGRlc2NyaWJlIHRoZSByZWdpc3RyYXRpb24uDQogICBUaGUgZmllbGRzIGluIHRoZSAi UmVjb3JkIFJlcXVlc3RlZCIgc2VjdGlvbiBTSE9VTEQgZm9sbG93IHRoZQ0KICAgcmVxdWlyZW1l bnRzIGluIFNlY3Rpb24gMy4xLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxp cHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAgICAgICAgICAg W1BhZ2UgMjhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0 cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQogICBMQU5HVUFHRSBTVUJUQUcgUkVH SVNUUkFUSU9OIEZPUk0NCiAgIDEuIE5hbWUgb2YgcmVxdWVzdGVyOg0KICAgMi4gRS1tYWlsIGFk ZHJlc3Mgb2YgcmVxdWVzdGVyOg0KICAgMy4gUmVjb3JkIFJlcXVlc3RlZDoNCg0KICAgVHlwZToN CiAgIFN1YnRhZzoNCiAgIERlc2NyaXB0aW9uOg0KICAgUHJlZml4Og0KICAgUHJlZmVycmVkLVZh bHVlOg0KICAgRGVwcmVjYXRlZDoNCiAgIFN1cHByZXNzLVNjcmlwdDoNCiAgIENvbW1lbnRzOg0K DQogICA0LiBJbnRlbmRlZCBtZWFuaW5nIG9mIHRoZSBzdWJ0YWc6DQogICA1LiBSZWZlcmVuY2Ug dG8gcHVibGlzaGVkIGRlc2NyaXB0aW9uDQogICBvZiB0aGUgbGFuZ3VhZ2UgKGJvb2sgb3IgYXJ0 aWNsZSk6DQogICA2LiBBbnkgb3RoZXIgcmVsZXZhbnQgaW5mb3JtYXRpb246DQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA1DQoNCiAgIFRoZSBzdWJ0YWcgcmVnaXN0 cmF0aW9uIGZvcm0gTVVTVCBiZSBzZW50IHRvDQogICA8aWV0Zi1sYW5ndWFnZXNAaWFuYS5vcmc+ IGZvciBhIHR3byB3ZWVrIHJldmlldyBwZXJpb2QgYmVmb3JlIGl0IGNhbg0KICAgYmUgc3VibWl0 dGVkIHRvIElBTkEuICAoVGhpcyBpcyBhbiBvcGVuIGxpc3QgYW5kIGNhbiBiZSBqb2luZWQgYnkN CiAgIHNlbmRpbmcgYSByZXF1ZXN0IHRvIDxpZXRmLWxhbmd1YWdlcy1yZXF1ZXN0QGlhbmEub3Jn Pi4pDQoNCiAgIFZhcmlhbnQgYW5kIGV4dGxhbmcgc3VidGFncyBhcmUgYWx3YXlzIHJlZ2lzdGVy ZWQgZm9yIHVzZSB3aXRoIGENCiAgIHBhcnRpY3VsYXIgcmFuZ2Ugb2YgbGFuZ3VhZ2UgdGFncy4g IEZvciBleGFtcGxlLCB0aGUgc3VidGFnICdyb3phaicNCiAgIGlzIGludGVuZGVkIGZvciB1c2Ug d2l0aCBsYW5ndWFnZSB0YWdzIHRoYXQgc3RhcnQgd2l0aCB0aGUgcHJpbWFyeQ0KICAgbGFuZ3Vh Z2Ugc3VidGFnICJzbCIsIHNpbmNlIFJlc2lhbiBpcyBhIGRpYWxlY3Qgb2YgU2xvdmVuaWFuLiAg VGh1cw0KICAgdGhlIHN1YnRhZyAncm96YWonIGNvdWxkIGJlIGluY2x1ZGVkIGluIHRhZ3Mgc3Vj aCBhcyAic2wtTGF0bi1yb3phaiINCiAgIG9yICJzbC1JVC1yb3phaiIuICBUaGlzIGluZm9ybWF0 aW9uIGlzIHN0b3JlZCBpbiB0aGUgIlByZWZpeCIgZmllbGQNCiAgIGluIHRoZSByZWdpc3RyeS4g IFZhcmlhbnQgcmVnaXN0cmF0aW9uIHJlcXVlc3RzIGFyZSBSRVFVSVJFRCB0bw0KICAgaW5jbHVk ZSBhdCBsZWFzdCBvbmUgIlByZWZpeCIgZmllbGQgaW4gdGhlIHJlZ2lzdHJhdGlvbiBmb3JtLg0K DQogICBUaGUgJ1ByZWZpeCcgZmllbGQgZm9yIGEgZ2l2ZW4gcmVnaXN0ZXJlZCBzdWJ0YWcgd2ls bCBiZSBtYWludGFpbmVkDQogICBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcyBhIGd1aWRlIHRvIHVz YWdlLiAgQWRkaXRpb25hbCBwcmVmaXhlcyBNQVkgYmUNCiAgIGFkZGVkIGJ5IGZpbGluZyBhbiBh ZGRpdGlvbmFsIHJlZ2lzdHJhdGlvbiBmb3JtLiAgSW4gdGhhdCBmb3JtLCB0aGUNCiAgICJBbnkg b3RoZXIgcmVsZXZhbnQgaW5mb3JtYXRpb246IiBmaWVsZCBNVVNUIGluZGljYXRlIHRoYXQgaXQg aXMgdGhlDQogICBhZGRpdGlvbiBvZiBhIHByZWZpeC4NCg0KICAgUmVxdWVzdHMgdG8gYWRkIGEg cHJlZml4IHRvIGEgdmFyaWFudCBzdWJ0YWcgdGhhdCBpbXBseSBhIGRpZmZlcmVudA0KICAgc2Vt YW50aWMgbWVhbmluZyB3aWxsIHByb2JhYmx5IGJlIHJlamVjdGVkLiAgRm9yIGV4YW1wbGUsIGEg cmVxdWVzdA0KICAgdG8gYWRkIHRoZSBwcmVmaXggImRlIiB0byB0aGUgc3VidGFnICduZWRpcycg c28gdGhhdCB0aGUgdGFnICJkZS0NCiAgIG5lZGlzIiByZXByZXNlbnRlZCBzb21lIEdlcm1hbiBk aWFsZWN0IHdvdWxkIGJlIHJlamVjdGVkLiAgVGhlDQogICAnbmVkaXMnIHN1YnRhZyByZXByZXNl bnRzIGEgcGFydGljdWxhciBTbG92ZW5pYW4gZGlhbGVjdCBhbmQgdGhlDQogICBhZGRpdGlvbmFs IHJlZ2lzdHJhdGlvbiB3b3VsZCBjaGFuZ2UgdGhlIHNlbWFudGljIG1lYW5pbmcgYXNzaWduZWQg dG8NCiAgIHRoZSBzdWJ0YWcuICBBIHNlcGFyYXRlIHN1YnRhZyBTSE9VTEQgYmUgcHJvcG9zZWQg aW5zdGVhZC4NCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgSmFudWFyeSAx MiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDI5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgSnVseSAyMDA1DQoNCg0K ICAgVGhlICdEZXNjcmlwdGlvbicgZmllbGQgTVVTVCBjb250YWluIGEgZGVzY3JpcHRpb24gb2Yg dGhlIHRhZyBiZWluZw0KICAgcmVnaXN0ZXJlZCB3cml0dGVuIG9yIHRyYW5zY3JpYmVkIGludG8g dGhlIExhdGluIHNjcmlwdDsgaXQgTUFZIGFsc28NCiAgIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBp biBhIG5vbi1MYXRpbiBzY3JpcHQuICBOb24tQVNDSUkgY2hhcmFjdGVycw0KICAgTVVTVCBiZSBl c2NhcGVkIHVzaW5nIHRoZSBzeW50YXggZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xLiAgVGhlDQog ICAnRGVzY3JpcHRpb24nIGZpZWxkIGlzIHVzZWQgZm9yIGlkZW50aWZpY2F0aW9uIHB1cnBvc2Vz IGFuZCBkb2Vzbid0DQogICBuZWNlc3NhcmlseSAgcmVwcmVzZW50IHRoZSBhY3R1YWwgbmF0aXZl IG5hbWUgb2YgdGhlIGxhbmd1YWdlIG9yDQogICB2YXJpYXRpb24gb3IgdG8gYmUgaW4gYW55IHBh cnRpY3VsYXIgbGFuZ3VhZ2UuDQoNCiAgIFdoaWxlIHRoZSAnRGVzY3JpcHRpb24nIGZpZWxkIGl0 c2VsZiBpcyBub3QgZ3VhcmFudGVlZCB0byBiZSBzdGFibGUNCiAgIGFuZCBlcnJhdGEgY29ycmVj dGlvbnMgTUFZIGJlIHVuZGVydGFrZW4gZnJvbSB0aW1lIHRvIHRpbWUsIGF0dGVtcHRzDQogICB0 byBwcm92aWRlIHRyYW5zbGF0aW9ucyBvciB0cmFuc2NyaXB0aW9ucyBvZiBlbnRyaWVzIGluIHRo ZSByZWdpc3RyeQ0KICAgaXRzZWxmIHdpbGwgcHJvYmFibHkgYmUgZnJvd25lZCB1cG9uIGJ5IHRo ZSBjb21tdW5pdHkgb3IgcmVqZWN0ZWQNCiAgIG91dHJpZ2h0LCBhcyBjaGFuZ2VzIG9mIHRoaXMg bmF0dXJlIGhhdmUgYW4gaW1wYWN0IG9uIHRoZSBwcm92aXNpb25zDQogICBpbiBTZWN0aW9uIDMu My4NCg0KICAgVGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBpcyByZXNwb25zaWJsZSBmb3Ig cmVzcG9uZGluZyB0bw0KICAgcmVxdWVzdHMgZm9yIHRoZSByZWdpc3RyYXRpb24gb2Ygc3VidGFn cyB0aHJvdWdoIHRoZSByZWdpc3RyYXRpb24NCiAgIHByb2Nlc3MgIGFuZCBpcyBhcHBvaW50ZWQg YnkgdGhlIElFU0cuDQoNCiAgIFdoZW4gdGhlIHR3byB3ZWVrIHBlcmlvZCBoYXMgcGFzc2VkIHRo ZSBMYW5ndWFnZSBTdWJ0YWcgUmV2aWV3ZXINCiAgIGVpdGhlciBmb3J3YXJkcyB0aGUgcmVjb3Jk IHRvIGJlIGluc2VydGVkIG9yIG1vZGlmaWVkIHRvDQogICBpYW5hQGlhbmEub3JnIGFjY29yZGlu ZyB0byB0aGUgcHJvY2VkdXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMiwgb3INCiAgIHJlamVj dHMgdGhlIHJlcXVlc3QgYmVjYXVzZSBvZiBzaWduaWZpY2FudCBvYmplY3Rpb25zIHJhaXNlZCBv biB0aGUNCiAgIGxpc3Qgb3IgZHVlIHRvIHByb2JsZW1zIHdpdGggY29uc3RyYWludHMgaW4gdGhp cyBkb2N1bWVudCAod2hpY2ggTVVTVA0KICAgYmUgZXhwbGljaXRseSBjaXRlZCkuICBUaGUgcmV2 aWV3ZXIgTUFZIGFsc28gZXh0ZW5kIHRoZSByZXZpZXcgcGVyaW9kDQogICBpbiB0d28gd2VlayBp bmNyZW1lbnRzIHRvIHBlcm1pdCBmdXJ0aGVyIGRpc2N1c3Npb24uICBUaGUgcmV2aWV3ZXINCiAg IE1VU1QgaW5kaWNhdGUgb24gdGhlIGxpc3Qgd2hldGhlciB0aGUgcmVnaXN0cmF0aW9uIGhhcyBi ZWVuIGFjY2VwdGVkLA0KICAgcmVqZWN0ZWQsIG9yIGV4dGVuZGVkIGZvbGxvd2luZyBlYWNoIHR3 byB3ZWVrIHBlcmlvZC4NCg0KICAgTm90ZSB0aGF0IHRoZSByZXZpZXdlciBjYW4gcmFpc2Ugb2Jq ZWN0aW9ucyBvbiB0aGUgbGlzdCBpZiBoZSBvciBzaGUNCiAgIHNvIGRlc2lyZXMuICBUaGUgaW1w b3J0YW50IHRoaW5nIGlzIHRoYXQgdGhlIG9iamVjdGlvbiBNVVNUIGJlIG1hZGUNCiAgIHB1Ymxp Y2x5Lg0KDQogICBUaGUgYXBwbGljYW50IGlzIGZyZWUgdG8gbW9kaWZ5IGEgcmVqZWN0ZWQgYXBw bGljYXRpb24gd2l0aA0KICAgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhbmQgc3VibWl0IGl0IGFn YWluOyB0aGlzIHJlc3RhcnRzIHRoZSB0d28NCiAgIHdlZWsgY29tbWVudCBwZXJpb2QuDQoNCiAg IERlY2lzaW9ucyBtYWRlIGJ5IHRoZSByZXZpZXdlciBNQVkgYmUgYXBwZWFsZWQgdG8gdGhlIElF U0cgW1JGQzIwMjhdDQogICB1bmRlciB0aGUgc2FtZSBydWxlcyBhcyBvdGhlciBJRVRGIGRlY2lz aW9ucyBbUkZDMjAyNl0uDQoNCiAgIEFsbCBhcHByb3ZlZCByZWdpc3RyYXRpb24gZm9ybXMgYXJl IGF2YWlsYWJsZSBvbmxpbmUgaW4gdGhlIGRpcmVjdG9yeQ0KICAgaHR0cDovL3d3dy5pYW5hLm9y Zy9udW1iZXJzLmh0bWwgdW5kZXIgImxhbmd1YWdlcyIuDQoNCiAgIFVwZGF0ZXMgb3IgY2hhbmdl cyB0byBleGlzdGluZyByZWNvcmRzIGZvbGxvdyB0aGUgc2FtZSBwcm9jZWR1cmUgYXMNCiAgIG5l dyByZWdpc3RyYXRpb25zLiAgVGhlIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBkZWNpZGVzIHdo ZXRoZXINCiAgIHRoZXJlIGlzIGNvbnNlbnN1cyB0byB1cGRhdGUgdGhlIHJlZ2lzdHJhdGlvbiBm b2xsb3dpbmcgdGhlIHR3byB3ZWVrDQogICByZXZpZXcgcGVyaW9kOyBub3JtYWxseSBvYmplY3Rp b25zIGJ5IHRoZSBvcmlnaW5hbCByZWdpc3RyYW50IHdpbGwNCiAgIGNhcnJ5IGV4dHJhIHdlaWdo dCBpbiBmb3JtaW5nIHN1Y2ggYSBjb25zZW5zdXMuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAg ICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAzMF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAg ICAgICAgIEp1bHkgMjAwNQ0KDQoNCiAgIFJlZ2lzdHJhdGlvbnMgYXJlIHBlcm1hbmVudCBhbmQg c3RhYmxlLiAgT25jZSByZWdpc3RlcmVkLCBzdWJ0YWdzDQogICB3aWxsIG5vdCBiZSByZW1vdmVk IGZyb20gdGhlIHJlZ2lzdHJ5IGFuZCB3aWxsIHJlbWFpbiBhIHZhbGlkIHdheSBpbg0KICAgd2hp Y2ggdG8gc3BlY2lmeSBhIHNwZWNpZmljIGxhbmd1YWdlIG9yIHZhcmlhbnQuDQoNCiAgIE5vdGU6 IFRoZSBwdXJwb3NlIG9mIHRoZSAiRGVzY3JpcHRpb24iIGluIHRoZSByZWdpc3RyYXRpb24gZm9y bSBpcw0KICAgaW50ZW5kZWQgYXMgYW4gYWlkIHRvIHBlb3BsZSB0cnlpbmcgdG8gdmVyaWZ5IHdo ZXRoZXIgYSBsYW5ndWFnZSBpcw0KICAgcmVnaXN0ZXJlZCBvciB3aGF0IGxhbmd1YWdlIG9yIGxh bmd1YWdlIHZhcmlhdGlvbiBhIHBhcnRpY3VsYXIgc3VidGFnDQogICByZWZlcnMgdG8uICBJbiBt b3N0IGNhc2VzLCByZWZlcmVuY2UgdG8gYW4gYXV0aG9yaXRhdGl2ZSBncmFtbWFyIG9yDQogICBk aWN0aW9uYXJ5IG9mIHRoYXQgbGFuZ3VhZ2Ugd2lsbCBiZSB1c2VmdWw7IGluIGNhc2VzIHdoZXJl IG5vIHN1Y2gNCiAgIHdvcmsgZXhpc3RzLCBvdGhlciB3ZWxsIGtub3duIHdvcmtzIGRlc2NyaWJp bmcgdGhhdCBsYW5ndWFnZSBvciBpbg0KICAgdGhhdCBsYW5ndWFnZSBNQVkgYmUgYXBwcm9wcmlh dGUuICBUaGUgc3VidGFnIHJldmlld2VyIGRlY2lkZXMgd2hhdA0KICAgY29uc3RpdHV0ZXMgImdv b2QgZW5vdWdoIiByZWZlcmVuY2UgbWF0ZXJpYWwuICBUaGlzIHJlcXVpcmVtZW50IGlzDQogICBu b3QgaW50ZW5kZWQgdG8gZXhjbHVkZSBwYXJ0aWN1bGFyIGxhbmd1YWdlcyBvciBkaWFsZWN0cyBk dWUgdG8gdGhlDQogICBzaXplIG9mIHRoZSBzcGVha2VyIHBvcHVsYXRpb24gb3IgbGFjayBvZiBh IHN0YW5kYXJkaXplZCBvcnRob2dyYXBoeS4NCiAgIE1pbm9yaXR5IGxhbmd1YWdlcyB3aWxsIGJl IGNvbnNpZGVyZWQgZXF1YWxseSBvbiB0aGVpciBvd24gbWVyaXRzLg0KDQozLjUgIFBvc3NpYmls aXRpZXMgZm9yIFJlZ2lzdHJhdGlvbg0KDQogICBQb3NzaWJpbGl0aWVzIGZvciByZWdpc3RyYXRp b24gb2Ygc3VidGFncyBvciBpbmZvcm1hdGlvbiBhYm91dA0KICAgc3VidGFncyBpbmNsdWRlOg0K DQogICBvICBQcmltYXJ5IGxhbmd1YWdlIHN1YnRhZ3MgZm9yIGxhbmd1YWdlcyBub3QgbGlzdGVk IGluIElTTyA2MzkgdGhhdA0KICAgICAgYXJlIG5vdCB2YXJpYW50cyBvZiBhbnkgbGlzdGVkIG9y IHJlZ2lzdGVyZWQgbGFuZ3VhZ2UgY2FuIGJlDQogICAgICByZWdpc3RlcmVkLiAgQXQgdGhlIHRp bWUgdGhpcyBkb2N1bWVudCB3YXMgY3JlYXRlZCB0aGVyZSB3ZXJlIG5vDQogICAgICBleGFtcGxl cyBvZiB0aGlzIGZvcm0gb2Ygc3VidGFnLiAgQmVmb3JlIGF0dGVtcHRpbmcgdG8gcmVnaXN0ZXIg YQ0KICAgICAgbGFuZ3VhZ2Ugc3VidGFnLCB0aGVyZSBNVVNUIGJlIGFuIGF0dGVtcHQgdG8gcmVn aXN0ZXIgdGhlIGxhbmd1YWdlDQogICAgICB3aXRoIElTTyA2MzkuICBObyBsYW5ndWFnZSBzdWJ0 YWdzIHdpbGwgYmUgcmVnaXN0ZXJlZCBmb3IgY29kZXMNCiAgICAgIHRoYXQgZXhpc3QgaW4gSVNP IDYzOS0xIG9yIElTTyA2MzktMiwgd2hpY2ggYXJlIHVuZGVyDQogICAgICBjb25zaWRlcmF0aW9u IGJ5IHRoZSBJU08gNjM5IG1haW50ZW5hbmNlIG9yIHJlZ2lzdHJhdGlvbg0KICAgICAgYXV0aG9y aXRpZXMsIG9yIHdoaWNoIGhhdmUgbmV2ZXIgYmVlbiBhdHRlbXB0ZWQgZm9yIHJlZ2lzdHJhdGlv bg0KICAgICAgd2l0aCB0aG9zZSBhdXRob3JpdGllcy4gIElmIElTTyA2MzkgaGFzIHByZXZpb3Vz bHkgcmVqZWN0ZWQgYQ0KICAgICAgbGFuZ3VhZ2UgZm9yIHJlZ2lzdHJhdGlvbiwgaXQgaXMgcmVh c29uYWJsZSB0byBhc3N1bWUgdGhhdCB0aGVyZQ0KICAgICAgbXVzdCBiZSBhZGRpdGlvbmFsIHZl cnkgY29tcGVsbGluZyBldmlkZW5jZSBvZiBuZWVkIGJlZm9yZSBpdCB3aWxsDQogICAgICBiZSBy ZWdpc3RlcmVkIGluIHRoZSBJQU5BIHJlZ2lzdHJ5ICh0byB0aGUgZXh0ZW50IHRoYXQgaXQgaXMg dmVyeQ0KICAgICAgdW5saWtlbHkgdGhhdCBhbnkgc3VidGFncyB3aWxsIGJlIHJlZ2lzdGVyZWQg b2YgdGhpcyB0eXBlKS4NCg0KICAgbyAgRGlhbGVjdCBvciBvdGhlciBkaXZpc2lvbnMgb3IgdmFy aWF0aW9ucyB3aXRoaW4gYSBsYW5ndWFnZSwgaXRzDQogICAgICBvcnRob2dyYXBoeSwgd3JpdGlu ZyBzeXN0ZW0sIHJlZ2lvbmFsIG9yIGhpc3RvcmljYWwgdXNhZ2UsDQogICAgICB0cmFuc2xpdGVy YXRpb24gb3Igb3RoZXIgdHJhbnNmb3JtYXRpb24sIG9yIGRpc3Rpbmd1aXNoaW5nDQogICAgICB2 YXJpYXRpb24gTUFZIGJlIHJlZ2lzdGVyZWQgYXMgdmFyaWFudCBzdWJ0YWdzLiAgQW4gZXhhbXBs ZSBpcyB0aGUNCiAgICAgICdyb3phaicgc3VidGFnICh0aGUgUmVzaWFuIGRpYWxlY3Qgb2YgU2xv dmVuaWFuKS4NCg0KICAgbyAgVGhlIGFkZGl0aW9uIG9yIG1haW50ZW5hbmNlIG9mIGZpZWxkcyAo Z2VuZXJhbGx5IG9mIGFuDQogICAgICBpbmZvcm1hdGlvbmFsIG5hdHVyZSkgaW4gVGFnIG9yIFN1 YnRhZyByZWNvcmRzIGFzIGRlc2NyaWJlZCBpbg0KICAgICAgU2VjdGlvbiAzLjEgYW5kIHN1Ympl Y3QgdG8gdGhlIHN0YWJpbGl0eSBwcm92aXNpb25zIGluDQogICAgICBTZWN0aW9uIDMuMy4gIFRo aXMgaW5jbHVkZXMgIGRlc2NyaXB0aW9uczsgY29tbWVudHM7IGRlcHJlY2F0aW9uDQogICAgICBh bmQgcHJlZmVycmVkIHZhbHVlcyBmb3Igb2Jzb2xldGUgb3Igd2l0aGRyYXduIGNvZGVzOyBvciB0 aGUNCiAgICAgIGFkZGl0aW9uIG9mIHNjcmlwdCBvciBleHRsYW5nIGluZm9ybWF0aW9uIHRvIHBy aW1hcnkgbGFuZ3VhZ2UNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgSmFu dWFyeSAxMiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDMxXQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgSnVseSAyMDA1 DQoNCg0KICAgICAgc3VidGFncy4NCg0KICAgbyAgVGhlIGFkZGl0aW9uIG9mIHJlY29yZHMgYW5k IHJlbGF0ZWQgZmllbGQgdmFsdWUgY2hhbmdlcyBuZWNlc3NhcnkNCiAgICAgIHRvIHJlZmxlY3Qg YXNzaWdubWVudHMgbWFkZSBieSBJU08gNjM5LCBJU08gMTU5MjQsIElTTyAzMTY2LCBhbmQNCiAg ICAgIFVOICBNLjQ5IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDMuMy4NCg0KICAgVGhpcyBkb2N1 bWVudCBsZWF2ZXMgdGhlIGRlY2lzaW9uIG9uIHdoYXQgc3VidGFncyAgb3IgY2hhbmdlcyB0bw0K ICAgc3VidGFncyBhcmUgYXBwcm9wcmlhdGUgKG9yIG5vdCkgdG8gdGhlIHJlZ2lzdHJhdGlvbiBw cm9jZXNzDQogICBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjQuDQoNCiAgIE5vdGU6IGZvdXIgY2hh cmFjdGVyIHByaW1hcnkgbGFuZ3VhZ2Ugc3VidGFncyBhcmUgcmVzZXJ2ZWQgdG8gYWxsb3cNCiAg IGZvciB0aGUgcG9zc2liaWxpdHkgb2YgIGFscGhhNCBjb2RlcyBpbiBzb21lIGZ1dHVyZSBhZGRp dGlvbiB0byB0aGUNCiAgIElTTyA2MzkgZmFtaWx5IG9mIHN0YW5kYXJkcy4NCg0KICAgSVNPIDYz OSBkZWZpbmVzIGEgbWFpbnRlbmFuY2UgYWdlbmN5IGZvciBhZGRpdGlvbnMgdG8gYW5kIGNoYW5n ZXMgaW4NCiAgIHRoZSBsaXN0IG9mIGxhbmd1YWdlcyBpbiBJU08gNjM5LiAgVGhpcyBhZ2VuY3kg aXM6DQoNCiAgIEludGVybmF0aW9uYWwgSW5mb3JtYXRpb24gQ2VudHJlIGZvciBUZXJtaW5vbG9n eSAoSW5mb3Rlcm0pDQogICBBaWNoaG9semdhc3NlIDYvMTIsIEFULTExMjANCiAgIFdpZW4sIEF1 c3RyaWENCiAgIFBob25lOiArNDMgMSAyNiA3NSAzNSBFeHQuIDMxMiBGYXg6ICs0MyAxIDIxNiAz MiA3Mg0KDQogICBJU08gNjM5LTIgZGVmaW5lcyBhIG1haW50ZW5hbmNlIGFnZW5jeSBmb3IgYWRk aXRpb25zIHRvIGFuZCBjaGFuZ2VzDQogICBpbiB0aGUgbGlzdCBvZiBsYW5ndWFnZXMgaW4gSVNP IDYzOS0yLiAgVGhpcyBhZ2VuY3kgaXM6DQoNCiAgIExpYnJhcnkgb2YgQ29uZ3Jlc3MNCiAgIE5l dHdvcmsgRGV2ZWxvcG1lbnQgYW5kIE1BUkMgU3RhbmRhcmRzIE9mZmljZQ0KICAgV2FzaGluZ3Rv biwgRC5DLiAyMDU0MCBVU0ENCiAgIFBob25lOiArMSAyMDIgNzA3IDYyMzcgIEZheDogKzEgMjAy IDcwNyAwMTE1DQogICBVUkw6IGh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMvaXNvNjM5DQoN CiAgIFRoZSBtYWludGVuYW5jZSBhZ2VuY3kgZm9yIElTTyAzMTY2IChjb3VudHJ5IGNvZGVzKSBp czoNCg0KICAgSVNPIDMxNjYgTWFpbnRlbmFuY2UgQWdlbmN5DQogICBjL28gSW50ZXJuYXRpb25h bCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbg0KICAgQ2FzZSBwb3N0YWxlIDU2DQog ICBDSC0xMjExIEdlbmV2YSAyMCBTd2l0emVybGFuZA0KICAgUGhvbmU6ICs0MSAyMiA3NDkgNzIg MzMgIEZheDogKzQxIDIyIDc0OSA3MyA0OQ0KICAgVVJMOiBodHRwOi8vd3d3Lmlzby5vcmcvaXNv L2VuL3Byb2RzLXNlcnZpY2VzL2lzbzMxNjZtYS9pbmRleC5odG1sDQoNCiAgIFRoZSByZWdpc3Ry YXRpb24gYXV0aG9yaXR5IGZvciBJU08gMTU5MjQgKHNjcmlwdCBjb2RlcykgaXM6DQoNCiAgIFVu aWNvZGUgQ29uc29ydGl1bSBCb3ggMzkxNDc2DQogICBNb3VudGFpbiBWaWV3LCBDQSA5NDAzOS0x NDc2LCBVU0ENCiAgIFVSTDogaHR0cDovL3d3dy51bmljb2RlLm9yZy9pc28xNTkyNA0KDQogICBU aGUgU3RhdGlzdGljcyBEaXZpc2lvbiBvZiB0aGUgVW5pdGVkIE5hdGlvbnMgU2VjcmV0YXJpYXQg bWFpbnRhaW5zDQogICB0aGUgU3RhbmRhcmQgQ291bnRyeSBvciBBcmVhIENvZGVzIGZvciBTdGF0 aXN0aWNhbCBVc2UgYW5kIGNhbiBiZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhw aXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMzJdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICBK dWx5IDIwMDUNCg0KDQogICByZWFjaGVkIGF0Og0KDQogICBTdGF0aXN0aWNhbCBTZXJ2aWNlcyBC cmFuY2gNCiAgIFN0YXRpc3RpY3MgRGl2aXNpb24NCiAgIFVuaXRlZCBOYXRpb25zLCBSb29tIERD Mi0xNjIwDQogICBOZXcgWW9yaywgTlkgMTAwMTcsIFVTQQ0KDQogICBGYXg6ICsxLTIxMi05NjMt MDYyMw0KICAgRS1tYWlsOiBzdGF0aXN0aWNzQHVuLm9yZw0KICAgVVJMOiBodHRwOi8vdW5zdGF0 cy51bi5vcmcvdW5zZC9tZXRob2RzL200OS9tNDlhbHBoYS5odG0NCg0KMy42ICBFeHRlbnNpb25z IGFuZCBFeHRlbnNpb25zIE5hbWVzcGFjZQ0KDQogICBFeHRlbnNpb24gc3VidGFncyBhcmUgdGhv c2UgaW50cm9kdWNlZCBieSBzaW5nbGUtbGV0dGVyIHN1YnRhZ3Mgb3RoZXINCiAgIHRoYW4gJ3gn LiAgVGhleSBhcmUgcmVzZXJ2ZWQgZm9yIHRoZSBnZW5lcmF0aW9uIG9mIGlkZW50aWZpZXJzIHdo aWNoDQogICBjb250YWluIGEgbGFuZ3VhZ2UgY29tcG9uZW50LCBhbmQgYXJlIGNvbXBhdGlibGUg d2l0aCBhcHBsaWNhdGlvbnMNCiAgIHRoYXQgdW5kZXJzdGFuZCBsYW5ndWFnZSB0YWdzLiAgRm9y IGV4YW1wbGUsIHRoZXkgbWlnaHQgYmUgdXNlZCB0bw0KICAgZGVmaW5lIGxvY2FsZSBpZGVudGlm aWVycywgd2hpY2ggYXJlIGdlbmVyYWxseSBiYXNlZCBvbiBsYW5ndWFnZS4NCg0KICAgVGhlIHN0 cnVjdHVyZSBhbmQgZm9ybSBvZiBleHRlbnNpb25zIGFyZSBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1l bnQgc28NCiAgIHRoYXQgaW1wbGVtZW50YXRpb25zIGNhbiBiZSBjcmVhdGVkIHRoYXQgYXJlIGZv cndhcmQgY29tcGF0aWJsZSB3aXRoDQogICBhcHBsaWNhdGlvbnMgdGhhdCBtaWdodCBiZSBjcmVh dGVkIHVzaW5nIHNpbmdsZS1sZXR0ZXIgc3VidGFncyBpbiB0aGUNCiAgIGZ1dHVyZS4gIEluIGFk ZGl0aW9uLCBkZWZpbmluZyBhIG1lY2hhbmlzbSBmb3IgbWFpbnRhaW5pbmcgc2luZ2xlLQ0KICAg bGV0dGVyIHN1YnRhZ3Mgd2lsbCBsZW5kIHRvIHRoZSBzdGFiaWxpdHkgb2YgdGhpcyBkb2N1bWVu dCBieQ0KICAgcmVkdWNpbmcgdGhlIGxpa2VseSBuZWVkIGZvciBmdXR1cmUgcmV2aXNpb25zIG9y IHVwZGF0ZXMuDQoNCiAgIEFsbG9jYXRpb24gb2YgYSBzaW5nbGUtbGV0dGVyIHN1YnRhZyBTSEFM TCB0YWtlIHRoZSBmb3JtIG9mIGFuIFJGQw0KICAgZGVmaW5pbmcgdGhlIG5hbWUsIHB1cnBvc2Us IHByb2Nlc3NlcywgYW5kIHByb2NlZHVyZXMgZm9yIG1haW50YWluaW5nDQogICB0aGUgc3VidGFn cy4gIFRoZSBtYWludGFpbmluZyBvciByZWdpc3RlcmluZyBhdXRob3JpdHksIGluY2x1ZGluZw0K ICAgbmFtZSwgY29udGFjdCBlbWFpbCwgZGlzY3Vzc2lvbiBsaXN0IGVtYWlsLCBhbmQgVVJMIGxv Y2F0aW9uIG9mIHRoZQ0KICAgcmVnaXN0cnkgTVVTVCBiZSBpbmRpY2F0ZWQgY2xlYXJseSBpbiB0 aGUgUkZDLiAgVGhlIFJGQyBNVVNUIHNwZWNpZnkNCiAgIG9yIGluY2x1ZGUgZWFjaCBvZiB0aGUg Zm9sbG93aW5nOg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNUIHJlZmVyZW5jZSB0aGUg c3BlY2lmaWMgdmVyc2lvbiBvciByZXZpc2lvbg0KICAgICAgb2YgdGhpcyBkb2N1bWVudCB0aGF0 IGdvdmVybnMgaXRzIGNyZWF0aW9uIGFuZCBNVVNUIHJlZmVyZW5jZSB0aGlzDQogICAgICBzZWN0 aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIGFuZCBhbGwg c3VidGFncyBkZWZpbmVkIGJ5IHRoZSBzcGVjaWZpY2F0aW9uDQogICAgICBNVVNUIGZvbGxvdyB0 aGUgQUJORiBhbmQgb3RoZXIgcnVsZXMgZm9yIHRoZSBmb3JtYXRpb24gb2YgdGFncyBhbmQNCiAg ICAgIHN1YnRhZ3MgYXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LiAgSW4gcGFydGljdWxhciBp dCBNVVNUDQogICAgICBzcGVjaWZ5IHRoYXQgY2FzZSBpcyBub3Qgc2lnbmlmaWNhbnQgYW5kIHRo YXQgc3VidGFncyBNVVNUIE5PVA0KICAgICAgZXhjZWVkIGVpZ2h0IGNoYXJhY3RlcnMgaW4gbGVu Z3RoLg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNUIHNwZWNpZnkgYSBjYW5vbmljYWwg cmVwcmVzZW50YXRpb24uDQoNCiAgIG8gIFRoZSBzcGVjaWZpY2F0aW9uIG9mIHZhbGlkIHN1YnRh Z3MgTVVTVCBiZSBhdmFpbGFibGUgb3ZlciB0aGUNCiAgICAgIEludGVybmV0IGFuZCBhdCBubyBj b3N0Lg0KDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIs IDIwMDYgICAgICAgICAgICAgICBbUGFnZSAzM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNCiAg IG8gIFRoZSBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgaW4gdGhlIHB1YmxpYyBkb21haW4gb3IgYXZh aWxhYmxlIHZpYSBhDQogICAgICByb3lhbHR5LWZyZWUgbGljZW5zZSBhY2NlcHRhYmxlIHRvIHRo ZSBJRVRGIGFuZCBzcGVjaWZpZWQgaW4gdGhlDQogICAgICBSRkMuDQoNCiAgIG8gIFRoZSBzcGVj aWZpY2F0aW9uIE1VU1QgYmUgdmVyc2lvbmVkIGFuZCBlYWNoIHZlcnNpb24gb2YgdGhlDQogICAg ICBzcGVjaWZpY2F0aW9uIE1VU1QgYmUgbnVtYmVyZWQsIGRhdGVkLCBhbmQgc3RhYmxlLg0KDQog ICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIHN0YWJsZS4gIFRoYXQgaXMsIGV4dGVuc2lv biBzdWJ0YWdzLA0KICAgICAgb25jZSBkZWZpbmVkIGJ5IGEgc3BlY2lmaWNhdGlvbiwgTVVTVCBO T1QgYmUgcmV0cmFjdGVkIG9yIGNoYW5nZQ0KICAgICAgaW4gbWVhbmluZyBpbiBhbnkgc3Vic3Rh bnRpYWwgd2F5Lg0KDQogICBvICBUaGUgc3BlY2lmaWNhdGlvbiBNVVNUIGluY2x1ZGUgaW4gYSBz ZXBhcmF0ZSBzZWN0aW9uIHRoZQ0KICAgICAgcmVnaXN0cmF0aW9uIGZvcm0gcmVwcm9kdWNlZCBp biB0aGlzIHNlY3Rpb24gKGJlbG93KSB0byBiZSB1c2VkIGluDQogICAgICByZWdpc3RlcmluZyB0 aGUgZXh0ZW5zaW9uIHVwb24gcHVibGljYXRpb24gYXMgYW4gUkZDLg0KDQogICBvICBJQU5BIE1V U1QgYmUgaW5mb3JtZWQgb2YgY2hhbmdlcyB0byB0aGUgY29udGFjdCBpbmZvcm1hdGlvbiBhbmQN CiAgICAgIFVSTCBmb3IgdGhlIHNwZWNpZmljYXRpb24uDQoNCiAgIElBTkEgd2lsbCBtYWludGFp biBhIHJlZ2lzdHJ5IG9mIGFsbG9jYXRlZCBzaW5nbGUtbGV0dGVyIChzaW5nbGV0b24pDQogICBz dWJ0YWdzLiAgVGhpcyByZWdpc3RyeSB3aWxsIHVzZSB0aGUgcmVjb3JkLWphciBmb3JtYXQgZGVz Y3JpYmVkIGJ5DQogICB0aGUgQUJORiBpbiBTZWN0aW9uIDMuMS4gIFVwb24gcHVibGljYXRpb24g b2YgYW4gZXh0ZW5zaW9uIGFzIGFuIFJGQywNCiAgIHRoZSBtYWludGFpbmluZyBhdXRob3JpdHkg ZGVmaW5lZCBpbiB0aGUgUkZDIE1VU1QgZm9yd2FyZCB0aGlzDQogICByZWdpc3RyYXRpb24gZm9y bSB0byBpZXNnQGlldGYub3JnLCB3aG8gd2lsbCBmb3J3YXJkIHRoZSByZXF1ZXN0IHRvDQogICBp YW5hQGlhbmEub3JnLiAgVGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBvZiB0aGUgZXh0ZW5zaW9u IE1VU1QNCiAgIG1haW50YWluIHRoZSBhY2N1cmFjeSBvZiB0aGUgcmVjb3JkIGJ5IHNlbmRpbmcg YW4gdXBkYXRlZCBmdWxsIGNvcHkNCiAgIG9mIHRoZSByZWNvcmQgdG8gaWFuYUBpYW5hLm9yZyB3 aXRoIHRoZSBzdWJqZWN0IGxpbmUgIkxBTkdVQUdFIFRBRw0KICAgRVhURU5TSU9OIFVQREFURSIg d2hlbmV2ZXIgY29udGVudCBjaGFuZ2VzLiAgT25seSB0aGUgJ0NvbW1lbnRzJywNCiAgICdDb250 YWN0X0VtYWlsJywgJ01haWxpbmdfTGlzdCcsIGFuZCAnVVJMJyBmaWVsZHMgTUFZIGJlIG1vZGlm aWVkIGluDQogICB0aGVzZSB1cGRhdGVzLg0KDQogICBGYWlsdXJlIHRvIG1haW50YWluIHRoaXMg cmVjb3JkLCB0aGUgY29ycmVzcG9uZGluZyByZWdpc3RyeSwgb3IgbWVldA0KICAgb3RoZXIgY29u ZGl0aW9ucyBpbXBvc2VkIGJ5IHRoaXMgc2VjdGlvbiBvZiB0aGlzIGRvY3VtZW50IE1BWSBiZQ0K ICAgYXBwZWFsZWQgdG8gdGhlIElFU0cgW1JGQzIwMjhdIHVuZGVyIHRoZSBzYW1lIHJ1bGVzIGFz IG90aGVyIElFVEYNCiAgIGRlY2lzaW9ucyAoc2VlIFtSRkMyMDI2XSkgYW5kIE1BWSByZXN1bHQg aW4gdGhlIGF1dGhvcml0eSB0byBtYWludGFpbg0KICAgdGhlIGV4dGVuc2lvbiBiZWluZyB3aXRo ZHJhd24gb3IgcmVhc3NpZ25lZCBieSB0aGUgSUVTRy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2 ICAgICAgICAgICAgICAgW1BhZ2UgMzRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg bGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQogICAlJQ0K ICAgSWRlbnRpZmllcjoNCiAgIERlc2NyaXB0aW9uOg0KICAgQ29tbWVudHM6DQogICBBZGRlZDoN CiAgIFJGQzoNCiAgIEF1dGhvcml0eToNCiAgIENvbnRhY3RfRW1haWw6DQogICBNYWlsaW5nX0xp c3Q6DQogICBVUkw6DQogICAlJQ0KDQogICAgRmlndXJlIDY6IEZvcm1hdCBvZiBSZWNvcmRzIGlu IHRoZSBMYW5ndWFnZSBUYWcgRXh0ZW5zaW9ucyBSZWdpc3RyeQ0KDQogICAnSWRlbnRpZmllcicg Y29udGFpbnMgdGhlIHNpbmdsZSBsZXR0ZXIgc3VidGFnIChzaW5nbGV0b24pIGFzc2lnbmVkDQog ICB0byB0aGUgZXh0ZW5zaW9uLiAgVGhlIEludGVybmV0LURyYWZ0IHN1Ym1pdHRlZCB0byBkZWZp bmUgdGhlDQogICBleHRlbnNpb24gU0hPVUxEIHNwZWNpZnkgd2hpY2ggbGV0dGVyIHRvIHVzZSwg YWx0aG91Z2ggdGhlIElFU0cgTUFZDQogICBjaGFuZ2UgdGhlIGFzc2lnbm1lbnQgd2hlbiBhcHBy b3ZpbmcgdGhlIFJGQy4NCg0KICAgJ0Rlc2NyaXB0aW9uJyBjb250YWlucyB0aGUgbmFtZSBhbmQg ZGVzY3JpcHRpb24gb2YgdGhlIGV4dGVuc2lvbi4NCg0KICAgJ0NvbW1lbnRzJyBpcyBhbiBPUFRJ T05BTCBmaWVsZCBhbmQgTUFZIGNvbnRhaW4gYSBicm9hZGVyIGRlc2NyaXB0aW9uDQogICBvZiB0 aGUgZXh0ZW5zaW9uLg0KDQogICAnQWRkZWQnIGNvbnRhaW5zIHRoZSBkYXRlIHRoZSBSRkMgd2Fz IHB1Ymxpc2hlZCBpbiB0aGUgImZ1bGwtZGF0ZSINCiAgIGZvcm1hdCBzcGVjaWZpZWQgaW4gW1JG QzMzMzldLiAgRm9yIGV4YW1wbGU6IDIwMDQtMDYtMjggcmVwcmVzZW50cw0KICAgSnVuZSAyOCwg MjAwNCwgaW4gdGhlIEdyZWdvcmlhbiBjYWxlbmRhci4NCg0KICAgJ1JGQycgY29udGFpbnMgdGhl IFJGQyBudW1iZXIgYXNzaWduZWQgdG8gdGhlIGV4dGVuc2lvbi4NCg0KICAgJ0F1dGhvcml0eScg Y29udGFpbnMgdGhlIG5hbWUgb2YgdGhlIG1haW50YWluaW5nIGF1dGhvcml0eSBmb3IgdGhlDQog ICBleHRlbnNpb24uDQoNCiAgICdDb250YWN0X0VtYWlsJyBjb250YWlucyB0aGUgZW1haWwgYWRk cmVzcyB1c2VkIHRvIGNvbnRhY3QgdGhlDQogICBtYWludGFpbmluZyBhdXRob3JpdHkuDQoNCiAg ICdNYWlsaW5nX0xpc3QnIGNvbnRhaW5zIHRoZSBVUkwgb3Igc3Vic2NyaXB0aW9uIGVtYWlsIGFk ZHJlc3Mgb2YgdGhlDQogICBtYWlsaW5nIGxpc3QgdXNlZCBieSB0aGUgbWFpbnRhaW5pbmcgYXV0 aG9yaXR5Lg0KDQogICAnVVJMJyBjb250YWlucyB0aGUgVVJMIG9mIHRoZSByZWdpc3RyeSBmb3Ig dGhpcyBleHRlbnNpb24uDQoNCiAgIFRoZSBkZXRlcm1pbmF0aW9uIG9mIHdoZXRoZXIgYW4gSW50 ZXJuZXQtRHJhZnQgbWVldHMgdGhlIGFib3ZlDQogICBjb25kaXRpb25zIGFuZCB0aGUgZGVjaXNp b24gdG8gZ3JhbnQgb3Igd2l0aGhvbGQgc3VjaCBhdXRob3JpdHkgcmVzdHMNCiAgIHNvbGVseSB3 aXRoIHRoZSBJRVNHLCBhbmQgaXMgc3ViamVjdCB0byB0aGUgbm9ybWFsIHJldmlldyBhbmQgYXBw ZWFscw0KICAgcHJvY2VzcyBhc3NvY2lhdGVkIHdpdGggdGhlIFJGQyBwcm9jZXNzLg0KDQogICBF eHRlbnNpb24gYXV0aG9ycyBhcmUgc3Ryb25nbHkgY2F1dGlvbmVkIHRoYXQgbWFueSAoaW5jbHVk aW5nIG1vc3QNCiAgIHdlbGwtZm9ybWVkKSBwcm9jZXNzb3JzIHdpbGwgYmUgdW5hd2FyZSBvZiBh bnkgc3BlY2lhbCByZWxhdGlvbnNoaXBzDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAzNV0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg IEp1bHkgMjAwNQ0KDQoNCiAgIG9yIG1lYW5pbmcgaW5oZXJlbnQgaW4gdGhlIG9yZGVyIG9mIGV4 dGVuc2lvbiBzdWJ0YWdzLiAgRXh0ZW5zaW9uDQogICBhdXRob3JzIFNIT1VMRCBhdm9pZCBzdWJ0 YWcgcmVsYXRpb25zaGlwcyBvciBjYW5vbmljYWxpemF0aW9uDQogICBtZWNoYW5pc21zIHRoYXQg aW50ZXJmZXJlIHdpdGggbWF0Y2hpbmcgb3Igd2l0aCBsZW5ndGggcmVzdHJpY3Rpb25zDQogICB0 aGF0IHNvbWV0aW1lcyBleGlzdCBpbiBjb21tb24gcHJvdG9jb2xzIHdoZXJlIHRoZSBleHRlbnNp b24gaXMgdXNlZC4NCiAgIEluIHBhcnRpY3VsYXIsIGFwcGxpY2F0aW9ucyBNQVkgdHJ1bmNhdGUg dGhlIHN1YnRhZ3MgaW4gZG9pbmcNCiAgIG1hdGNoaW5nIG9yIGluIGZpdHRpbmcgaW50byBsaW1p dGVkIGxlbmd0aHMsIHNvIGl0IGlzIFJFQ09NTUVOREVEDQogICB0aGF0IHRoZSBtb3N0IHNpZ25p ZmljYW50IGluZm9ybWF0aW9uIGJlIGluIHRoZSBtb3N0IHNpZ25pZmljYW50DQogICAobGVmdC1t b3N0KSBzdWJ0YWdzLCBhbmQgdGhhdCB0aGUgc3BlY2lmaWNhdGlvbiBncmFjZWZ1bGx5IGhhbmRs ZQ0KICAgdHJ1bmNhdGVkIHN1YnRhZ3MuDQoNCiAgIFdoZW4gYSBsYW5ndWFnZSB0YWcgaXMgdG8g YmUgdXNlZCBpbiBhIHNwZWNpZmljLCBrbm93biwgcHJvdG9jb2wsIGl0DQogICBpcyBSRUNPTU1F TkRFRCB0aGF0IHRoYXQgdGhlIGxhbmd1YWdlIHRhZyBub3QgY29udGFpbiBleHRlbnNpb25zIG5v dA0KICAgc3VwcG9ydGVkIGJ5IHRoYXQgcHJvdG9jb2wuICBJbiBhZGRpdGlvbiwgbm90ZSB0aGF0 IHNvbWUgcHJvdG9jb2xzDQogICBNQVkgaW1wb3NlIHVwcGVyIGxpbWl0cyBvbiB0aGUgbGVuZ3Ro IG9mIHRoZSBzdHJpbmdzIHVzZWQgdG8gc3RvcmUgb3INCiAgIHRyYW5zcG9ydCB0aGUgbGFuZ3Vh Z2UgdGFnLg0KDQozLjcgIEluaXRpYWxpemF0aW9uIG9mIHRoZSBSZWdpc3RyeQ0KDQogICBBZG9w dGlvbiBvZiB0aGlzIGRvY3VtZW50IHdpbGwgUkVRVUlSRSBhbiBpbml0aWFsIHZlcnNpb24gb2Yg dGhlDQogICByZWdpc3RyeSBjb250YWluaW5nIHRoZSB2YXJpb3VzIHN1YnRhZ3MgaW5pdGlhbGx5 IHZhbGlkIGluIGEgbGFuZ3VhZ2UNCiAgIHRhZy4gIFRoaXMgY29sbGVjdGlvbiBvZiBzdWJ0YWdz LCBhbG9uZyB3aXRoIGEgZGVzY3JpcHRpb24gb2YgdGhlDQogICBwcm9jZXNzIHVzZWQgdG8gY3Jl YXRlIGl0LCBpcyBkZXNjcmliZWQgYnkgW2luaXRpYWwtcmVnaXN0cnldLg0KDQogICBSZWdpc3Ry YXRpb25zIHRoYXQgYXJlIGluIHByb2Nlc3MgdW5kZXIgdGhlIHJ1bGVzIGRlZmluZWQgaW4NCiAg IFtSRkMzMDY2XSB3aGVuIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBNQVkgYmUgY29tcGxldGVk IHVuZGVyIHRoZQ0KICAgZm9ybWVyIHJ1bGVzLCBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUgbGFu Z3VhZ2UgdGFnIHJldmlld2VyLiAgQW55DQogICBuZXcgcmVnaXN0cmF0aW9ucyBzdWJtaXR0ZWQg YWZ0ZXIgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgTVVTVA0KICAgYmUgcmVqZWN0ZWQu DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMg JiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAgICAgICAgICAgW1Bh Z2UgMzZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkg ICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQo0LiAgRm9ybWF0aW9uIGFuZCBQcm9jZXNz aW5nIG9mIExhbmd1YWdlIFRhZ3MNCg0KICAgVGhpcyBzZWN0aW9uIGFkZHJlc3NlcyBob3cgdG8g dXNlIHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgcmVnaXN0cnkNCiAgIHdpdGggdGhlIHRhZyBzeW50 YXggdG8gY2hvb3NlLCBmb3JtIGFuZCBwcm9jZXNzIGxhbmd1YWdlIHRhZ3MuDQoNCjQuMSAgQ2hv aWNlIG9mIExhbmd1YWdlIFRhZw0KDQogICBPbmUgaXMgc29tZXRpbWVzIGZhY2VkIHdpdGggdGhl IGNob2ljZSBiZXR3ZWVuIHNldmVyYWwgcG9zc2libGUgdGFncw0KICAgZm9yIHRoZSBzYW1lIGJv ZHkgb2YgdGV4dC4NCg0KICAgSW50ZXJvcGVyYWJpbGl0eSBpcyBiZXN0IHNlcnZlZCB3aGVuIGFs bCB1c2VycyB1c2UgdGhlIHNhbWUgbGFuZ3VhZ2UNCiAgIHRhZyBpbiBvcmRlciB0byByZXByZXNl bnQgdGhlIHNhbWUgbGFuZ3VhZ2UuICBJZiBhbiBhcHBsaWNhdGlvbiBoYXMNCiAgIHJlcXVpcmVt ZW50cyB0aGF0IG1ha2UgdGhlIHJ1bGVzIGhlcmUgaW5hcHBsaWNhYmxlLCB0aGVuIHRoYXQNCiAg IGFwcGxpY2F0aW9uIHJpc2tzIGRhbWFnaW5nIGludGVyb3BlcmFiaWxpdHkuICBJdCBpcyBzdHJv bmdseQ0KICAgUkVDT01NRU5ERUQgdGhhdCB1c2VycyBub3QgZGVmaW5lIHRoZWlyIG93biBydWxl cyBmb3IgbGFuZ3VhZ2UgdGFnDQogICBjaG9pY2UuDQoNCiAgIFN1YnRhZ3MgU0hPVUxEIG9ubHkg YmUgdXNlZCAgd2hlcmUgdGhleSBhZGQgdXNlZnVsIGRpc3Rpbmd1aXNoaW5nDQogICBpbmZvcm1h dGlvbjsgZXh0cmFuZW91cyBzdWJ0YWdzIGludGVyZmVyZSB3aXRoIHRoZSBtZWFuaW5nLA0KICAg dW5kZXJzdGFuZGluZywgYW5kIHByb2Nlc3Npbmcgb2YgbGFuZ3VhZ2UgdGFncy4gIEluIHBhcnRp Y3VsYXIsIHVzZXJzDQogICBhbmQgaW1wbGVtZW50YXRpb25zIFNIT1VMRCBmb2xsb3cgdGhlICdQ cmVmaXgnIGFuZCAnU3VwcHJlc3MtU2NyaXB0Jw0KICAgZmllbGRzIGluIHRoZSByZWdpc3RyeSAo ZGVmaW5lZCBpbiBTZWN0aW9uIDMuMSk6IHRoZXNlIGZpZWxkcyBwcm92aWRlDQogICBndWlkYW5j ZSBvbiB3aGVuIHNwZWNpZmljIGFkZGl0aW9uYWwgc3VidGFncyBTSE9VTEQgKGFuZCBTSE9VTEQg Tk9UKQ0KICAgYmUgdXNlZCBpbiBhIGxhbmd1YWdlIHRhZy4NCg0KICAgT2YgcGFydGljdWxhciBu b3RlLCBtYW55IGFwcGxpY2F0aW9ucyBjYW4gYmVuZWZpdCBmcm9tIHRoZSB1c2Ugb2YNCiAgIHNj cmlwdCBzdWJ0YWdzIGluIGxhbmd1YWdlIHRhZ3MsIGFzIGxvbmcgYXMgdGhlIHVzZSBpcyBjb25z aXN0ZW50IGZvcg0KICAgYSBnaXZlbiBjb250ZXh0LiAgU2NyaXB0IHN1YnRhZ3Mgd2VyZSBub3Qg Zm9ybWFsbHkgZGVmaW5lZCBpbiBSRkMNCiAgIDMwNjYgYW5kIHRoZWlyIHVzZSBjYW4gYWZmZWN0 IG1hdGNoaW5nIGFuZCBzdWJ0YWcgaWRlbnRpZmljYXRpb24gYnkNCiAgIGltcGxlbWVudGF0aW9u cyBvZiBSRkMgMzA2NiwgYXMgdGhlc2Ugc3VidGFncyBhcHBlYXIgYmV0d2VlbiB0aGUNCiAgIHBy aW1hcnkgbGFuZ3VhZ2UgYW5kIHJlZ2lvbiBzdWJ0YWdzLiAgRm9yIGV4YW1wbGUsIGlmIGEgdXNl ciByZXF1ZXN0cw0KICAgY29udGVudCBpbiBhbiBpbXBsZW1lbnRhdGlvbiBvZiBTZWN0aW9uIDIu NSBvZiBbUkZDMzA2Nl0gdXNpbmcgdGhlDQogICBsYW5ndWFnZSByYW5nZSAiZW4tVVMiLCBjb250 ZW50IGxhYmVsZWQgImVuLUxhdG4tVVMiIHdpbGwgbm90IG1hdGNoDQogICB0aGUgcmVxdWVzdC4g IFRoZXJlZm9yZSBpdCBpcyBpbXBvcnRhbnQgdG8ga25vdyB3aGVuIHNjcmlwdCBzdWJ0YWdzDQog ICB3aWxsIGN1c3RvbWFyaWx5IGJlIHVzZWQgYW5kIHdoZW4gdGhleSBvdWdodCBub3QgYmUgdXNl ZC4gIEluIHRoZQ0KICAgcmVnaXN0cnksIHRoZSBTdXBwcmVzcy1TY3JpcHQgZmllbGQgaGVscHMg ZW5zdXJlIGdyZWF0ZXINCiAgIGNvbXBhdGliaWxpdHkgYmV0d2VlbiB0aGUgbGFuZ3VhZ2UgdGFn cyBnZW5lcmF0ZWQgYWNjb3JkaW5nIHRvIHRoZQ0KICAgcnVsZXMgaW4gdGhpcyBkb2N1bWVudCBh bmQgbGFuZ3VhZ2UgdGFncyBhbmQgdGFnIHByb2Nlc3NvcnMgb3INCiAgIGNvbnN1bWVycyBiYXNl ZCBvbiBSRkMgMzA2NiBieSBkZWZpbmluZyB3aGVuIHVzZXJzIFNIT1VMRCBOT1QgaW5jbHVkZQ0K ICAgYSBzY3JpcHQgc3VidGFnIHdpdGggYSBwYXJ0aWN1bGFyIHByaW1hcnkgbGFuZ3VhZ2Ugc3Vi dGFnLg0KDQogICBFeHRlbmRlZCBsYW5ndWFnZSBzdWJ0YWdzICh0eXBlICdleHRsYW5nJyBpbiB0 aGUgcmVnaXN0cnksIHNlZQ0KICAgU2VjdGlvbiAzLjEpIGFsc28gYXBwZWFyIGJldHdlZW4gdGhl IHByaW1hcnkgbGFuZ3VhZ2UgYW5kIHJlZ2lvbg0KICAgc3VidGFncyBhbmQgYXJlIHJlc2VydmVk IGZvciBmdXR1cmUgc3RhbmRhcmRpemF0aW9uLiAgQXBwbGljYXRpb25zDQogICBtaWdodCBiZW5l Zml0IGZyb20gdGhlaXIganVkaWNpb3VzIHVzZSBpbiBmb3JtaW5nIGxhbmd1YWdlIHRhZ3MgaW4N CiAgIHRoZSBmdXR1cmUuICBTaW1pbGFyIHJlY29tbWVuZGF0aW9ucyBhcmUgZXhwZWN0ZWQgdG8g YXBwbHkgdG8gdGhlaXINCiAgIHVzZSBhcyBhcHBseSB0byBzY3JpcHQgc3VidGFncy4NCg0KDQoN Cg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAg ICAgICAgICAgW1BhZ2UgMzddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQogICBTdGFuZGFyZHMs IHByb3RvY29scyBhbmQgYXBwbGljYXRpb25zIHRoYXQgcmVmZXJlbmNlIHRoaXMgZG9jdW1lbnQN CiAgIG5vcm1hdGl2ZWx5IGJ1dCBhcHBseSBkaWZmZXJlbnQgcnVsZXMgdG8gdGhlIG9uZXMgZ2l2 ZW4gaW4gdGhpcw0KICAgc2VjdGlvbiBNVVNUIHNwZWNpZnkgaG93IHRoZSBwcm9jZWR1cmUgdmFy aWVzIGZyb20gdGhlIG9uZSBnaXZlbg0KICAgaGVyZS4NCg0KICAgVGhlIGNob2ljZSBvZiBzdWJ0 YWdzIHVzZWQgdG8gZm9ybSBhIGxhbmd1YWdlIHRhZyBTSE9VTEQgYmUgZ3VpZGVkIGJ5DQogICB0 aGUgZm9sbG93aW5nIHJ1bGVzOg0KDQogICAxLiAgVXNlIGFzIHByZWNpc2UgYSB0YWcgYXMgcG9z c2libGUsIGJ1dCBubyBtb3JlIHNwZWNpZmljIHRoYW4gaXMNCiAgICAgICBqdXN0aWZpZWQuICBB dm9pZCB1c2luZyBzdWJ0YWdzIHRoYXQgYXJlIG5vdCBpbXBvcnRhbnQgZm9yDQogICAgICAgZGlz dGluZ3Vpc2hpbmcgY29udGVudCBpbiBhbiBhcHBsaWNhdGlvbi4NCg0KICAgICAgICogIEZvciBl eGFtcGxlLCAnZGUnIG1pZ2h0IHN1ZmZpY2UgZm9yIHRhZ2dpbmcgYW4gZW1haWwgd3JpdHRlbg0K ICAgICAgICAgIGluIEdlcm1hbiwgd2hpbGUgImRlLUNILTE5OTYiIGlzIHByb2JhYmx5IHVubmVj ZXNzYXJpbHkNCiAgICAgICAgICBwcmVjaXNlIGZvciBzdWNoIGEgdGFzay4NCg0KICAgMi4gIFRo ZSBzY3JpcHQgc3VidGFnIFNIT1VMRCBOT1QgYmUgdXNlZCB0byBmb3JtIGxhbmd1YWdlIHRhZ3Mg dW5sZXNzDQogICAgICAgdGhlIHNjcmlwdCBhZGRzIHNvbWUgZGlzdGluZ3Vpc2hpbmcgaW5mb3Jt YXRpb24gdG8gdGhlIHRhZy4gIFRoZQ0KICAgICAgIGZpZWxkICdTdXBwcmVzcy1TY3JpcHQnIGlu IHRoZSBwcmltYXJ5IGxhbmd1YWdlIHJlY29yZCBpbiB0aGUNCiAgICAgICByZWdpc3RyeSBpbmRp Y2F0ZXMgd2hpY2ggc2NyaXB0IHN1YnRhZ3MgZG8gbm90IGFkZCBkaXN0aW5ndWlzaGluZw0KICAg ICAgIGluZm9ybWF0aW9uIGZvciBtb3N0IGFwcGxpY2F0aW9ucy4NCg0KICAgICAgICogIEZvciBl eGFtcGxlLCB0aGUgc3VidGFnICdMYXRuJyBzaG91bGQgbm90IGJlIHVzZWQgd2l0aCB0aGUNCiAg ICAgICAgICBwcmltYXJ5IGxhbmd1YWdlICdlbicgYmVjYXVzZSBuZWFybHkgYWxsIEVuZ2xpc2gg ZG9jdW1lbnRzIGFyZQ0KICAgICAgICAgIHdyaXR0ZW4gaW4gdGhlIExhdGluIHNjcmlwdCBhbmQg aXQgYWRkcyBubyBkaXN0aW5ndWlzaGluZw0KICAgICAgICAgIGluZm9ybWF0aW9uLiAgSG93ZXZl ciwgaWYgYSBkb2N1bWVudCB3ZXJlIHdyaXR0ZW4gaW4gRW5nbGlzaA0KICAgICAgICAgIG1peGlu ZyBMYXRpbiBzY3JpcHQgd2l0aCBhbm90aGVyIHNjcmlwdCBzdWNoIGFzIEJyYWlsbGUNCiAgICAg ICAgICAoJ0JyYWknKSwgdGhlbiBpdCBtaWdodCBiZSBhcHByb3ByaWF0ZSB0byBjaG9vc2UgdG8g aW5kaWNhdGUNCiAgICAgICAgICBib3RoIHNjcmlwdHMgdG8gYWlkIGluIGNvbnRlbnQgc2VsZWN0 aW9uLCBzdWNoIGFzIHRoZQ0KICAgICAgICAgIGFwcGxpY2F0aW9uIG9mIGEgc3R5bGUgc2hlZXQu DQoNCiAgIDMuICBJZiBhIHRhZyBvciBzdWJ0YWcgaGFzIGEgJ1ByZWZlcnJlZC1WYWx1ZScgZmll bGQgaW4gaXRzIHJlZ2lzdHJ5DQogICAgICAgZW50cnksIHRoZW4gdGhlICB2YWx1ZSBvZiB0aGF0 IGZpZWxkIFNIT1VMRCBiZSB1c2VkIHRvIGZvcm0gdGhlDQogICAgICAgbGFuZ3VhZ2UgdGFnIGlu IHByZWZlcmVuY2UgdG8gdGhlIHRhZyBvciBzdWJ0YWcgaW4gd2hpY2ggdGhlDQogICAgICAgcHJl ZmVycmVkIHZhbHVlIGFwcGVhcnMuDQoNCiAgICAgICAqICBGb3IgZXhhbXBsZSwgdXNlICdoZScg Zm9yIEhlYnJldyBpbiBwcmVmZXJlbmNlIHRvICdpdycuDQoNCiAgIDQuICBUaGUgJ3VuZCcgKFVu ZGV0ZXJtaW5lZCkgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcgU0hPVUxEIE5PVCBiZQ0KICAgICAg IHVzZWQgdG8gbGFiZWwgY29udGVudCwgZXZlbiBpZiB0aGUgbGFuZ3VhZ2UgaXMgdW5rbm93bi4g IE9taXR0aW5nDQogICAgICAgdGhlIGxhbmd1YWdlIHRhZyBhbHRvZ2V0aGVyIGlzIHByZWZlcnJl ZCB0byB1c2luZyBhIHRhZyB3aXRoIGENCiAgICAgICBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBv ZiAndW5kJy4gIFRoZSAndW5kJyBzdWJ0YWcgTUFZIGJlIHVzZWZ1bA0KICAgICAgIGZvciBwcm90 b2NvbHMgdGhhdCByZXF1aXJlIGEgbGFuZ3VhZ2UgdGFnIHRvIGJlIHByb3ZpZGVkLiAgVGhlDQog ICAgICAgJ3VuZCcgc3VidGFnIE1BWSBhbHNvIGJlIHVzZWZ1bCB3aGVuIG1hdGNoaW5nIGxhbmd1 YWdlIHRhZ3MgaW4NCiAgICAgICBjZXJ0YWluIHNpdHVhdGlvbnMuDQoNCiAgIDUuICBUaGUgJ211 bCcgKE11bHRpcGxlKSBwcmltYXJ5IGxhbmd1YWdlIHN1YnRhZyBTSE9VTEQgTk9UIGJlIHVzZWQN CiAgICAgICB3aGVuZXZlciB0aGUgcHJvdG9jb2wgYWxsb3dzIHRoZSBzZXBhcmF0ZSB0YWdzIGZv ciBtdWx0aXBsZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5 IDEyLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMzhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0K DQogICAgICAgbGFuZ3VhZ2VzLCBhcyBpcyB0aGUgY2FzZSBmb3IgdGhlIENvbnRlbnQtTGFuZ3Vh Z2UgaGVhZGVyIGluDQogICAgICAgSFRUUC4gIFRoZSAnbXVsJyBzdWJ0YWcgY29udmV5cyBsaXR0 bGUgdXNlZnVsIGluZm9ybWF0aW9uOg0KICAgICAgIGNvbnRlbnQgaW4gbXVsdGlwbGUgbGFuZ3Vh Z2VzIFNIT1VMRCBpbmRpdmlkdWFsbHkgdGFnIHRoZQ0KICAgICAgIGxhbmd1YWdlcyB3aGVyZSB0 aGV5IGFwcGVhciBvciBvdGhlcndpc2UgaW5kaWNhdGUgdGhlIGFjdHVhbA0KICAgICAgIGxhbmd1 YWdlIGluIHByZWZlcmVuY2UgdG8gdGhlICdtdWwnIHN1YnRhZy4NCg0KICAgNi4gIFRoZSBzYW1l IHZhcmlhbnQgc3VidGFnIFNIT1VMRCBOT1QgYmUgdXNlZCBtb3JlIHRoYW4gb25jZSB3aXRoaW4N CiAgICAgICBhIGxhbmd1YWdlIHRhZy4NCg0KICAgICAgICogIEZvciBleGFtcGxlLCBkbyBub3Qg dXNlICJkZS1ERS0xOTAxLTE5MDEiLg0KDQogICBUbyBlbnN1cmUgY29uc2lzdGVudCBiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5LCB0aGlzIGRvY3VtZW50IGNvbnRhaW5zDQogICBzZXZlcmFsIHByb3Zp c2lvbnMgdG8gYWNjb3VudCBmb3IgcG90ZW50aWFsIGluc3RhYmlsaXR5IGluIHRoZQ0KICAgc3Rh bmRhcmRzIHVzZWQgdG8gZGVmaW5lIHRoZSBzdWJ0YWdzIHRoYXQgbWFrZSB1cCBsYW5ndWFnZSB0 YWdzLg0KICAgVGhlc2UgcHJvdmlzaW9ucyBtZWFuIHRoYXQgbm8gbGFuZ3VhZ2UgdGFnIGNyZWF0 ZWQgdW5kZXIgdGhlIHJ1bGVzIGluDQogICB0aGlzIGRvY3VtZW50IHdpbGwgYmVjb21lIG9ic29s ZXRlLg0KDQo0LjIgIE1lYW5pbmcgb2YgdGhlIExhbmd1YWdlIFRhZw0KDQogICBUaGUgcmVsYXRp b25zaGlwIGJldHdlZW4gdGhlIHRhZyBhbmQgdGhlIGluZm9ybWF0aW9uIGl0IHJlbGF0ZXMgdG8g aXMNCiAgIGRlZmluZWQgYnkgdGhlIGNvbnRleHQgaW4gd2hpY2ggdGhlIHRhZyBhcHBlYXJzLiAg QWNjb3JkaW5nbHksIHRoaXMNCiAgIHNlY3Rpb24gY2FuIG9ubHkgZ2l2ZSBwb3NzaWJsZSBleGFt cGxlcyBvZiBpdHMgdXNhZ2UuDQoNCiAgIG8gIEZvciBhIHNpbmdsZSBpbmZvcm1hdGlvbiBvYmpl Y3QsIHRoZSBhc3NvY2lhdGVkIGxhbmd1YWdlIHRhZ3MNCiAgICAgIG1pZ2h0IGJlIGludGVycHJl dGVkIGFzIHRoZSBzZXQgb2YgbGFuZ3VhZ2VzIHRoYXQgaXMgbmVjZXNzYXJ5IGZvcg0KICAgICAg YSBjb21wbGV0ZSBjb21wcmVoZW5zaW9uIG9mIHRoZSBjb21wbGV0ZSBvYmplY3QuICBFeGFtcGxl OiBQbGFpbg0KICAgICAgdGV4dCBkb2N1bWVudHMuDQoNCiAgIG8gIEZvciBhbiBhZ2dyZWdhdGlv biBvZiBpbmZvcm1hdGlvbiBvYmplY3RzLCB0aGUgYXNzb2NpYXRlZCBsYW5ndWFnZQ0KICAgICAg dGFncyBjb3VsZCBiZSB0YWtlbiBhcyB0aGUgc2V0IG9mIGxhbmd1YWdlcyB1c2VkIGluc2lkZSBj b21wb25lbnRzDQogICAgICBvZiB0aGF0IGFnZ3JlZ2F0aW9uLiAgRXhhbXBsZXM6IERvY3VtZW50 IHN0b3JlcyBhbmQgbGlicmFyaWVzLg0KDQogICBvICBGb3IgaW5mb3JtYXRpb24gb2JqZWN0cyB3 aG9zZSBwdXJwb3NlIGlzIHRvIHByb3ZpZGUgYWx0ZXJuYXRpdmVzLA0KICAgICAgdGhlIGFzc29j aWF0ZWQgbGFuZ3VhZ2UgdGFncyBjb3VsZCBiZSByZWdhcmRlZCBhcyBhIGhpbnQgdGhhdCB0aGUN CiAgICAgIGNvbnRlbnQgaXMgcHJvdmlkZWQgaW4gc2V2ZXJhbCBsYW5ndWFnZXMsIGFuZCB0aGF0 IG9uZSBoYXMgdG8NCiAgICAgIGluc3BlY3QgZWFjaCBvZiB0aGUgYWx0ZXJuYXRpdmVzIGluIG9y ZGVyIHRvIGZpbmQgaXRzIGxhbmd1YWdlIG9yDQogICAgICBsYW5ndWFnZXMuICBJbiB0aGlzIGNh c2UsIHRoZSBwcmVzZW5jZSBvZiBtdWx0aXBsZSB0YWdzIG1pZ2h0IG5vdA0KICAgICAgbWVhbiB0 aGF0IG9uZSBuZWVkcyB0byBiZSBtdWx0aS1saW5ndWFsIHRvIGdldCBjb21wbGV0ZQ0KICAgICAg dW5kZXJzdGFuZGluZyBvZiB0aGUgZG9jdW1lbnQuICBFeGFtcGxlOiBNSU1FIG11bHRpcGFydC8N CiAgICAgIGFsdGVybmF0aXZlLg0KDQogICBvICBJbiBtYXJrdXAgbGFuZ3VhZ2VzLCBzdWNoIGFz IEhUTUwgYW5kIFhNTCwgbGFuZ3VhZ2UgaW5mb3JtYXRpb24NCiAgICAgIGNhbiBiZSBhZGRlZCB0 byBlYWNoIHBhcnQgb2YgdGhlIGRvY3VtZW50IGlkZW50aWZpZWQgYnkgdGhlIG1hcmt1cA0KICAg ICAgc3RydWN0dXJlIChpbmNsdWRpbmcgdGhlIHdob2xlIGRvY3VtZW50IGl0c2VsZikuICBGb3Ig ZXhhbXBsZSwgb25lDQogICAgICBjb3VsZCB3cml0ZSA8c3BhbiBsYW5nPSJmciI+Qydlc3QgbGEg dmllLjwvc3Bhbj4gaW5zaWRlIGENCiAgICAgIE5vcndlZ2lhbiBkb2N1bWVudDsgdGhlIE5vcndl Z2lhbi1zcGVha2luZyB1c2VyIGNvdWxkIHRoZW4gYWNjZXNzDQogICAgICBhIEZyZW5jaC1Ob3J3 ZWdpYW4gZGljdGlvbmFyeSB0byBmaW5kIG91dCB3aGF0IHRoZSBtYXJrZWQgc2VjdGlvbg0KICAg ICAgbWVhbnQuICBJZiB0aGUgdXNlciB3ZXJlIGxpc3RlbmluZyB0byB0aGF0IGRvY3VtZW50IHRo cm91Z2ggYQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEy LCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgMzldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQog ICAgICBzcGVlY2ggc3ludGhlc2lzIGludGVyZmFjZSwgdGhpcyBmb3JtYXRpb24gY291bGQgYmUg dXNlZCB0byBzaWduYWwNCiAgICAgIHRoZSBzeW50aGVzaXplciB0byBhcHByb3ByaWF0ZWx5IGFw cGx5IEZyZW5jaCB0ZXh0LXRvLXNwZWVjaA0KICAgICAgcHJvbnVuY2lhdGlvbiBydWxlcyB0byB0 aGF0IHNwYW4gb2YgdGV4dCwgaW5zdGVhZCBvZiBhcHBseWluZyB0aGUNCiAgICAgIGluYXBwcm9w cmlhdGUgTm9yd2VnaWFuIHJ1bGVzLg0KDQogICBMYW5ndWFnZSB0YWdzIGFyZSByZWxhdGVkIHdo ZW4gdGhleSBjb250YWluIGEgc2ltaWxhciBzZXF1ZW5jZSBvZg0KICAgc3VidGFncy4gIEZvciBl eGFtcGxlLCBpZiBhIGxhbmd1YWdlIHRhZyBCIGNvbnRhaW5zIGxhbmd1YWdlIHRhZyBBIGFzDQog ICBhIHByZWZpeCwgdGhlbiBCIGlzIHR5cGljYWxseSAibmFycm93ZXIiIG9yICJtb3JlIHNwZWNp ZmljIiB0aGFuIEEuDQogICBUaHVzICJ6aC1IYW50LVRXIiBpcyBtb3JlIHNwZWNpZmljIHRoYW4g InpoLUhhbnQiLg0KDQogICBUaGlzIHJlbGF0aW9uc2hpcCBpcyBub3QgZ3VhcmFudGVlZCBpbiBh bGwgY2FzZXM6IHNwZWNpZmljYWxseSwNCiAgIGxhbmd1YWdlcyB0aGF0IGJlZ2luIHdpdGggdGhl IHNhbWUgc2VxdWVuY2Ugb2Ygc3VidGFncyBhcmUgTk9UDQogICBndWFyYW50ZWVkIHRvIGJlIG11 dHVhbGx5IGludGVsbGlnaWJsZSwgYWx0aG91Z2ggdGhleSBtaWdodCBiZS4gIEZvcg0KICAgZXhh bXBsZSwgdGhlIHRhZyAiYXoiIHNoYXJlcyBhIHByZWZpeCB3aXRoIGJvdGggImF6LUxhdG4iDQog ICAoQXplcmJhaWphbmkgd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0KSBhbmQgImF6LUN5 cmwiDQogICAoQXplcmJhaWphbmkgd3JpdHRlbiB1c2luZyB0aGUgQ3lyaWxsaWMgc2NyaXB0KS4g IEEgcGVyc29uIGZsdWVudCBpbg0KICAgb25lIHNjcmlwdCBtaWdodCBub3QgYmUgYWJsZSB0byBy ZWFkIHRoZSBvdGhlciwgZXZlbiB0aG91Z2ggdGhlIHRleHQNCiAgIG1pZ2h0IGJlIGlkZW50aWNh bC4gIENvbnRlbnQgdGFnZ2VkIGFzICJheiIgbW9zdCBwcm9iYWJseSBpcyB3cml0dGVuDQogICBp biBqdXN0IG9uZSBzY3JpcHQgYW5kIHRodXMgbWlnaHQgbm90IGJlIGludGVsbGlnaWJsZSB0byBh IHJlYWRlcg0KICAgZmFtaWxpYXIgd2l0aCB0aGUgb3RoZXIgc2NyaXB0Lg0KDQo0LjMgIExlbmd0 aCBDb25zaWRlcmF0aW9ucw0KDQogICBbUkZDMzA2Nl0gZGlkIG5vdCBwcm92aWRlIGFuIHVwcGVy IGxpbWl0IG9uIHRoZSBzaXplIG9mIGxhbmd1YWdlDQogICB0YWdzLiAgV2hpbGUgUkZDIDMwNjYg ZGlkIGRlZmluZSB0aGUgc2VtYW50aWNzIG9mIHBhcnRpY3VsYXIgc3VidGFncw0KICAgaW4gc3Vj aCBhIHdheSB0aGF0IG1vc3QgbGFuZ3VhZ2UgdGFncyBjb25zaXN0ZWQgb2YgbGFuZ3VhZ2UgYW5k DQogICByZWdpb24gc3VidGFncyB3aXRoIGEgY29tYmluZWQgdG90YWwgbGVuZ3RoIG9mIHVwIHRv IHNpeCBjaGFyYWN0ZXJzLA0KICAgbGFyZ2VyIHJlZ2lzdGVyZWQgdGFncyB3ZXJlIG5vdCBvbmx5 IHBvc3NpYmxlIGJ1dCB3ZXJlIGFjdHVhbGx5DQogICByZWdpc3RlcmVkLg0KDQogICBOZWl0aGVy IHRoZSBsYW5ndWFnZSB0YWcgc3ludGF4IG5vciBvdGhlciByZXF1aXJlbWVudHMgaW4gdGhpcw0K ICAgZG9jdW1lbnQgIGltcG9zZSBhIGZpeGVkIHVwcGVyIGxpbWl0IG9uIHRoZSBudW1iZXIgb2Yg c3VidGFncyBpbiBhDQogICBsYW5ndWFnZSB0YWcgKGFuZCB0aHVzIGFuIHVwcGVyIGJvdW5kIG9u IHRoZSBzaXplIG9mIGEgdGFnKS4gIFRoZQ0KICAgbGFuZ3VhZ2UgdGFnIHN5bnRheCBzdWdnZXN0 cyB0aGF0LCBkZXBlbmRpbmcgb24gdGhlIHNwZWNpZmljDQogICBsYW5ndWFnZSwgbW9yZSBzdWJ0 YWdzIChhbmQgdGh1cyBhIGxvbmdlciB0YWcpIGFyZSBzb21ldGltZXMNCiAgIG5lY2Vzc2FyeSB0 byBjb21wbGV0ZWx5IGlkZW50aWZ5IHRoZSBsYW5ndWFnZSBmb3IgY2VydGFpbg0KICAgYXBwbGlj YXRpb25zOyB0aHVzIGl0IGlzIHBvc3NpYmxlIHRvIGVudmlzaW9uIGxvbmcgb3IgY29tcGxleCBz dWJ0YWcNCiAgIHNlcXVlbmNlcy4NCg0KNC4zLjEgIFdvcmtpbmcgd2l0aCBMaW1pdGVkIEJ1ZmZl ciBTaXplcw0KDQogICBTb21lIGFwcGxpY2F0aW9ucyBhbmQgcHJvdG9jb2xzIGFyZSBmb3JjZWQg dG8gYWxsb2NhdGUgZml4ZWQgYnVmZmVyDQogICBzaXplcyBvciBvdGhlcndpc2UgbGltaXQgdGhl IGxlbmd0aCBvZiBhIGxhbmd1YWdlIHRhZy4gIEEgY29uZm9ybWFudA0KICAgaW1wbGVtZW50YXRp b24gb3Igc3BlY2lmaWNhdGlvbiBNQVkgcmVmdXNlIHRvIHN1cHBvcnQgdGhlIHN0b3JhZ2Ugb2YN CiAgIGxhbmd1YWdlIHRhZ3Mgd2hpY2ggZXhjZWVkIGEgc3BlY2lmaWVkIGxlbmd0aC4gIEFueSBz dWNoIGxpbWl0YXRpb24NCiAgIFNIT1VMRCBiZSBjbGVhcmx5IGRvY3VtZW50ZWQsIGFuZCBzdWNo IGRvY3VtZW50YXRpb24gU0hPVUxEIGluY2x1ZGUNCiAgIHdoYXQgaGFwcGVucyB0byBsb25nZXIg dGFncyAoZm9yIGV4YW1wbGUsIHdoZXRoZXIgYW4gZXJyb3IgdmFsdWUgaXMNCiAgIGdlbmVyYXRl ZCBvciB0aGUgbGFuZ3VhZ2UgdGFnIGlzIHRydW5jYXRlZCkuICBBIHByb3RvY29sIHRoYXQgYWxs b3dzDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIw MDYgICAgICAgICAgICAgICBbUGFnZSA0MF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNCiAgIHRh Z3MgdG8gYmUgdHJ1bmNhdGVkIGF0IGFuIGFyYml0cmFyeSBsaW1pdCwgd2l0aG91dCBnaXZpbmcg YW55DQogICBpbmRpY2F0aW9uIG9mIHdoYXQgdGhhdCBsaW1pdCBpcywgaGFzIHRoZSBwb3RlbnRp YWwgZm9yIGNhdXNpbmcgaGFybQ0KICAgYnkgY2hhbmdpbmcgdGhlIG1lYW5pbmcgb2YgdGFncyBp biBzdWJzdGFudGlhbCB3YXlzLg0KDQogICBJbiBwcmFjdGljZSwgbW9zdCBsYW5ndWFnZSB0YWdz IGRvIG5vdCByZXF1aXJlIG1vcmUgdGhhbiBhIGZldw0KICAgc3VidGFncyBhbmQgd2lsbCBub3Qg YXBwcm9hY2ggcmVhc29uYWJseSBzaXplZCBidWZmZXIgbGltaXRhdGlvbnM6DQogICBzZWUgU2Vj dGlvbiA0LjEuDQoNCiAgIFNvbWUgc3BlY2lmaWNhdGlvbnMgb3IgcHJvdG9jb2xzIGhhdmUgbGlt aXRzIG9uIHRhZyBsZW5ndGggYnV0IGRvIG5vdA0KICAgaGF2ZSBhIGZpeGVkIGxlbmd0aCBsaW1p dGF0aW9uLiAgRm9yIGV4YW1wbGUsIFtSRkMyMjMxXSAgaGFzIG5vDQogICBleHBsaWNpdCBsZW5n dGggbGltaXRhdGlvbjogdGhlIGxlbmd0aCBhdmFpbGFibGUgZm9yIHRoZSBsYW5ndWFnZSB0YWcN CiAgIGlzIGNvbnN0cmFpbmVkIGJ5IHRoZSBsZW5ndGggb2Ygb3RoZXIgaGVhZGVyIGNvbXBvbmVu dHMgKHN1Y2ggYXMgdGhlDQogICBjaGFyc2V0J3MgbmFtZSkgY291cGxlZCB3aXRoIHRoZSA3NiBj aGFyYWN0ZXIgbGltaXQgaW4gW1JGQzIwNDddLg0KICAgVGh1cyB0aGUgImxpbWl0IiBtaWdodCBi ZSA1MCBvciBtb3JlIGNoYXJhY3RlcnMsIGJ1dCBpdCBjb3VsZA0KICAgcG90ZW50aWFsbHkgYmUg cXVpdGUgc21hbGwuDQoNCiAgIFRoZSBjb25zaWRlcmF0aW9ucyBmb3IgYXNzaWduaW5nIGEgYnVm ZmVyIGxpbWl0IGFyZToNCg0KICAgICAgSW1wbGVtZW50YXRpb25zIFNIT1VMRCBOT1QgdHJ1bmNh dGUgbGFuZ3VhZ2UgdGFncyB1bmxlc3MgdGhlDQogICAgICBtZWFuaW5nIG9mIHRoZSB0YWcgaXMg cHVycG9zZWZ1bGx5IGJlaW5nIGNoYW5nZWQsIG9yIHVubGVzcyB0aGUNCiAgICAgIHRhZyBkb2Vz IG5vdCBmaXQgaW50byBhIGxpbWl0ZWQgYnVmZmVyIHNpemUgc3BlY2lmaWVkIGJ5IGENCiAgICAg IHByb3RvY29sIGZvciBzdG9yYWdlIG9yIHRyYW5zbWlzc2lvbi4NCg0KICAgICAgSW1wbGVtZW50 YXRpb25zIFNIT1VMRCB3YXJuIHRoZSB1c2VyIHdoZW4gYSB0YWcgaXMgdHJ1bmNhdGVkIHNpbmNl DQogICAgICB0cnVuY2F0aW9uIGNoYW5nZXMgdGhlIHNlbWFudGljIG1lYW5pbmcgb2YgdGhlIHRh Zy4NCg0KICAgICAgSW1wbGVtZW50YXRpb25zIG9mIHByb3RvY29scyBvciBzcGVjaWZpY2F0aW9u cyB0aGF0IGFyZSBzcGFjZQ0KICAgICAgY29uc3RyYWluZWQgYnV0IGRvIG5vdCBoYXZlIGEgZml4 ZWQgbGltaXQgU0hPVUxEIHVzZSB0aGUgbG9uZ2VzdA0KICAgICAgcG9zc2libGUgdGFnIGluIHBy ZWZlcmVuY2UgdG8gdHJ1bmNhdGlvbi4NCg0KICAgICAgUHJvdG9jb2xzIG9yIHNwZWNpZmljYXRp b25zIHRoYXQgc3BlY2lmeSBsaW1pdGVkIGJ1ZmZlciBzaXplcyBmb3INCiAgICAgIGxhbmd1YWdl IHRhZ3MgTVVTVCBhbGxvdyBmb3IgbGFuZ3VhZ2UgdGFncyBvZiB1cCB0byAzMyBjaGFyYWN0ZXJz Lg0KDQogICAgICBQcm90b2NvbHMgb3Igc3BlY2lmaWNhdGlvbnMgdGhhdCBzcGVjaWZ5IGxpbWl0 ZWQgYnVmZmVyIHNpemVzIGZvcg0KICAgICAgbGFuZ3VhZ2UgdGFncyBTSE9VTEQgYWxsb3cgZm9y IGxhbmd1YWdlIHRhZ3Mgb2YgYXQgbGVhc3QgNDINCiAgICAgIGNoYXJhY3RlcnMuDQoNCiAgIFRo ZSBmb2xsb3dpbmcgaWxsdXN0cmF0aW9uIHNob3dzIGhvdyB0aGUgNDItY2hhcmFjdGVyIHJlY29t bWVuZGF0aW9uDQogICB3YXMgZGVyaXZlZC4gIFRoZSBjb21iaW5hdGlvbiBvZiBsYW5ndWFnZSBh bmQgZXh0ZW5kZWQgbGFuZ3VhZ2UNCiAgIHN1YnRhZ3Mgd2FzIGNob3NlbiBmb3IgZnV0dXJlIGNv bXBhdGliaWxpdHkuICBBdCB1cCB0byAxNSBjaGFyYWN0ZXJzLA0KICAgdGhpcyBjb21iaW5hdGlv biBpcyBsb25nZXIgdGhhbiB0aGUgbG9uZ2VzdCBwb3NzaWJsZSBwcmltYXJ5IGxhbmd1YWdlDQog ICBzdWJ0YWcgKDggY2hhcmFjdGVycyk6DQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA0 MV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNCiAgIGxhbmd1YWdlICAgICAgPSAgMyAoSVNPIDYz OS0yOyBJU08gNjM5LTEgcmVxdWlyZXMgMikNCiAgIGV4dGxhbmcxICAgICAgPSAgNCAoZWFjaCBz dWJzZXF1ZW50IHN1YnRhZyBpbmNsdWRlcyAnLScpDQogICBleHRsYW5nMiAgICAgID0gIDQgKHVu bGlrZWx5OiBuZWVkcyBwcmVmaXg9Imxhbmd1YWdlLWV4dGxhbmcxIikNCiAgIGV4dGxhbmczICAg ICAgPSAgNCAoZXh0cmVtZWx5IHVubGlrZWx5KQ0KICAgc2NyaXB0ICAgICAgICA9ICA1IChpZiBu b3Qgc3VwcHJlc3NlZDogc2VlIFNlY3Rpb24gNC4xKQ0KICAgcmVnaW9uICAgICAgICA9ICA0IChV TiBNLjQ5OyBJU08gMzE2NiByZXF1aXJlcyAzKQ0KICAgdmFyaWFudDEgICAgICA9ICA5IChNVVNU IGhhdmUgbGFuZ3VhZ2UgYXMgYSBwcmVmaXgpDQogICB2YXJpYW50MiAgICAgID0gIDkgKE1VU1Qg aGF2ZSBsYW5ndWFnZS12YXJpYW50MSBhcyBhIHByZWZpeCkNCg0KICAgdG90YWwgICAgICAgICA9 IDQyIGNoYXJhY3RlcnMNCg0KICAgICAgICAgICAgICBGaWd1cmUgNzogRGVyaXZhdGlvbiBvZiB0 aGUgTGltaXQgb24gVGFnIExlbmd0aA0KDQoNCjQuMy4yICBUcnVuY2F0aW9uIG9mIExhbmd1YWdl IFRhZ3MNCg0KICAgVHJ1bmNhdGlvbiBvZiBhIGxhbmd1YWdlIHRhZyBhbHRlcnMgdGhlIG1lYW5p bmcgb2YgdGhlIHRhZywgYW5kIHRodXMNCiAgIFNIT1VMRCBiZSBhdm9pZGVkLiAgSG93ZXZlciwg dHJ1bmNhdGlvbiBvZiBsYW5ndWFnZSB0YWdzIGlzIHNvbWV0aW1lcw0KICAgbmVjZXNzYXJ5IGR1 ZSB0byBsaW1pdGVkIGJ1ZmZlciBzaXplcy4gIFN1Y2ggdHJ1bmNhdGlvbiBNVVNUIE5PVA0KICAg cGVybWl0IGEgc3VidGFnIHRvIGJlIGNob3BwZWQgb2ZmIGluIHRoZSBtaWRkbGUgb3IgdGhlIGZv cm1hdGlvbiBvZg0KICAgaW52YWxpZCB0YWdzIChmb3IgZXhhbXBsZSwgb25lIGVuZGluZyB3aXRo IHRoZSAiLSIgY2hhcmFjdGVyKS4NCg0KICAgVGhpcyBtZWFucyB0aGF0IGFwcGxpY2F0aW9ucyBv ciBwcm90b2NvbHMgd2hpY2ggdHJ1bmNhdGUgdGFncyBNVVNUIGRvDQogICBzbyBieSBwcm9ncmVz c2l2ZWx5IHJlbW92aW5nIHN1YnRhZ3MgYWxvbmcgd2l0aCB0aGVpciBwcmVjZWRpbmcgIi0iDQog ICBmcm9tIHRoZSByaWdodCBzaWRlIG9mIHRoZSBsYW5ndWFnZSB0YWcgdW50aWwgdGhlIHRhZyBp cyBzaG9ydCBlbm91Z2gNCiAgIGZvciB0aGUgZ2l2ZW4gYnVmZmVyLiAgSWYgdGhlIHJlc3VsdGlu ZyB0YWcgZW5kcyB3aXRoIGEgc2luZ2xlLQ0KICAgY2hhcmFjdGVyIHN1YnRhZywgdGhhdCBzdWJ0 YWcgYW5kIGl0cyBwcmVjZWRpbmcgIi0iIE1VU1QgYWxzbyBiZQ0KICAgcmVtb3ZlZC4gIEZvciBl eGFtcGxlOg0KDQogICBUYWcgdG8gdHJ1bmNhdGU6IHpoLUhhbnQtQ04tdmFyaWFudDEtYS1leHRl bmQxLXgtd2FkZWdpbGUtcHJpdmF0ZTENCiAgIDEuIHpoLUxhdG4tQ04tdmFyaWFudDEtYS1leHRl bmQxLXgtd2FkZWdpbGUNCiAgIDIuIHpoLUxhdG4tQ04tdmFyaWFudDEtYS1leHRlbmQxDQogICAz LiB6aC1MYXRuLUNOLXZhcmlhbnQxDQogICA0LiB6aC1MYXRuLUNODQogICA1LiB6aC1MYXRuDQog ICA2LiB6aA0KDQogICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA4OiBFeGFtcGxlIG9mIFRhZyBU cnVuY2F0aW9uDQoNCg0KNC40ICBDYW5vbmljYWxpemF0aW9uIG9mIExhbmd1YWdlIFRhZ3MNCg0K ICAgU2luY2UgYSBwYXJ0aWN1bGFyIGxhbmd1YWdlIHRhZyBpcyBzb21ldGltZXMgdXNlZCBieSBt YW55IHByb2Nlc3NlcywNCiAgIGxhbmd1YWdlIHRhZ3MgU0hPVUxEIGFsd2F5cyBiZSBjcmVhdGVk IG9yIGdlbmVyYXRlZCBpbiBhIGNhbm9uaWNhbA0KICAgZm9ybS4NCg0KICAgQSBsYW5ndWFnZSB0 YWcgaXMgaW4gY2Fub25pY2FsIGZvcm0gd2hlbjoNCg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAg ICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgNDJdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAg ICAgICAgICBKdWx5IDIwMDUNCg0KDQogICAxLiAgVGhlIHRhZyBpcyB3ZWxsLWZvcm1lZCBhY2Nv cmRpbmcgdGhlIHJ1bGVzIGluIFNlY3Rpb24gMi4xIGFuZA0KICAgICAgIFNlY3Rpb24gMi4yLg0K DQogICAyLiAgU3VidGFncyBvZiB0eXBlICdSZWdpb24nIHRoYXQgaGF2ZSBhIFByZWZlcnJlZC1W YWx1ZSBtYXBwaW5nIGluDQogICAgICAgdGhlIElBTkEgcmVnaXN0cnkgKHNlZSBTZWN0aW9uIDMu MSkgU0hPVUxEIGJlIHJlcGxhY2VkIHdpdGggdGhlaXINCiAgICAgICBtYXBwZWQgdmFsdWUuDQoN CiAgIDMuICBSZWR1bmRhbnQgb3IgZ3JhbmRmYXRoZXJlZCB0YWdzIHRoYXQgaGF2ZSBhIFByZWZl cnJlZC1WYWx1ZQ0KICAgICAgIG1hcHBpbmcgaW4gdGhlIElBTkEgcmVnaXN0cnkgKHNlZSBTZWN0 aW9uIDMuMSkgTVVTVCBiZSByZXBsYWNlZA0KICAgICAgIHdpdGggdGhlaXIgbWFwcGVkIHZhbHVl LiAgVGhlc2UgaXRlbXMgYXJlIGVpdGhlciBkZXByZWNhdGVkDQogICAgICAgbWFwcGluZ3MgY3Jl YXRlZCBiZWZvcmUgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgKHN1Y2ggYXMNCiAgICAg ICB0aGUgbWFwcGluZyBvZiAibm8tbnluIiB0byAibm4iIG9yICJpLWtsaW5nb24iIHRvICJ0bGgi KSBvciBhcmUNCiAgICAgICB0aGUgcmVzdWx0IG9mIGxhdGVyIHJlZ2lzdHJhdGlvbnMgb3IgYWRk aXRpb25zIHRvIHRoaXMgZG9jdW1lbnQNCiAgICAgICAoZm9yIGV4YW1wbGUsICJ6aC1ndW95dSIg bWlnaHQgYmUgbWFwcGVkIHRvIGEgbGFuZ3VhZ2UtZXh0bGFuZw0KICAgICAgIGNvbWJpbmF0aW9u IHN1Y2ggYXMgInpoLWNtbiIgYnkgc29tZSBmdXR1cmUgdXBkYXRlIG9mIHRoaXMNCiAgICAgICBk b2N1bWVudCkuDQoNCiAgIDQuICBPdGhlciBzdWJ0YWdzIHRoYXQgaGF2ZSBhIFByZWZlcnJlZC1W YWx1ZSBtYXBwaW5nIGluIHRoZSBJQU5BDQogICAgICAgcmVnaXN0cnkgKHNlZSBTZWN0aW9uIDMu MSkgTVVTVCBiZSByZXBsYWNlZCB3aXRoIHRoZWlyIG1hcHBlZA0KICAgICAgIHZhbHVlLiAgVGhl c2UgaXRlbXMgY29uc2lzdCBlbnRpcmVseSBvZiBjbGVyaWNhbCBjb3JyZWN0aW9ucyB0bw0KICAg ICAgIElTTyA2MzktMSBpbiB3aGljaCB0aGUgZGVwcmVjYXRlZCBzdWJ0YWdzIGhhdmUgYmVlbiBt YWludGFpbmVkDQogICAgICAgZm9yIGNvbXBhdGliaWxpdHkgcHVycG9zZXMuDQoNCiAgIDUuICBJ ZiBtb3JlIHRoYW4gb25lIGV4dGVuc2lvbiBzdWJ0YWcgc2VxdWVuY2UgZXhpc3RzLCB0aGUgZXh0 ZW5zaW9uDQogICAgICAgc2VxdWVuY2VzIGFyZSBvcmRlcmVkIGludG8gY2FzZS1pbnNlbnNpdGl2 ZSBBU0NJSSBvcmRlciBieQ0KICAgICAgIHNpbmdsZXRvbiBzdWJ0YWcuDQoNCiAgIEV4YW1wbGU6 IFRoZSBsYW5ndWFnZSB0YWcgImVuLUEtYWFhLUItY2NjLWJiYi14LXh5eiIgaXMgaW4gY2Fub25p Y2FsDQogICBmb3JtLCB3aGlsZSAiZW4tQi1jY2MtYmJiLUEtYWFhLVgteHl6IiBpcyB3ZWxsLWZv cm1lZCBidXQgbm90IGluDQogICBjYW5vbmljYWwgZm9ybS4NCg0KICAgRXhhbXBsZTogVGhlIGxh bmd1YWdlIHRhZyAiZW4tTkgiIChFbmdsaXNoIGFzIHVzZWQgaW4gdGhlIE5ldw0KICAgSGVicmlk ZXMpIGlzIG5vdCBjYW5vbmljYWwgYmVjYXVzZSB0aGUgJ05IJyBzdWJ0YWcgaGFzIGEgY2Fub25p Y2FsDQogICBtYXBwaW5nIHRvICdWVScgKFZhbnVhdHUpLCBhbHRob3VnaCB0aGUgdGFnICJlbi1O SCIgbWFpbnRhaW5zIGl0cw0KICAgdmFsaWRpdHkuDQoNCiAgIENhbm9uaWNhbGl6YXRpb24gb2Yg bGFuZ3VhZ2UgdGFncyBkb2VzIG5vdCBpbXBseSBhbnl0aGluZyBhYm91dCB0aGUNCiAgIHVzZSBv ZiB1cHBlciBvciBsb3dlcmNhc2UgbGV0dGVycyB3aGVuIHByb2Nlc3Npbmcgb3IgY29tcGFyaW5n DQogICBzdWJ0YWdzIChhbmQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4xKS4gIEFsbCBjb21w YXJpc29ucyBNVVNUIGJlDQogICBwZXJmb3JtZWQgaW4gYSBjYXNlLWluc2Vuc2l0aXZlIG1hbm5l ci4NCg0KICAgV2hlbiBwZXJmb3JtaW5nIGNhbm9uaWNhbGl6YXRpb24gb2YgbGFuZ3VhZ2UgdGFn cywgcHJvY2Vzc29ycyBNQVkNCiAgIHJlZ3VsYXJpemUgdGhlIGNhc2Ugb2YgdGhlIHN1YnRhZ3Mg KHRoYXQgaXMsIHRoaXMgcHJvY2VzcyBpcw0KICAgT1BUSU9OQUwpLCBmb2xsb3dpbmcgdGhlIGNh c2UgdXNlZCBpbiB0aGUgcmVnaXN0cnkuICBOb3RlIHRoYXQgdGhpcw0KICAgY29ycmVzcG9uZHMg dG8gdGhlIGZvbGxvd2luZyBjYXNpbmcgcnVsZXM6IHVwcGVyY2FzZSBhbGwgbm9uLWluaXRpYWwN CiAgIHR3by1sZXR0ZXIgc3VidGFnczsgdGl0bGVjYXNlIGFsbCBub24taW5pdGlhbCBmb3VyLWxl dHRlciBzdWJ0YWdzOw0KICAgbG93ZXJjYXNlIGV2ZXJ5dGhpbmcgZWxzZS4NCg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAgICAgICAg ICAgW1BhZ2UgNDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQogICBOb3RlOiBDYXNlIGZvbGRp bmcgb2YgQVNDSUkgbGV0dGVycyBpbiBjZXJ0YWluIGxvY2FsZXMsIHVubGVzcw0KICAgY2FyZWZ1 bGx5IGhhbmRsZWQsIHNvbWV0aW1lcyBwcm9kdWNlcyBub24tQVNDSUkgY2hhcmFjdGVyIHZhbHVl cy4NCiAgIFRoZSBVbmljb2RlIENoYXJhY3RlciBEYXRhYmFzZSBmaWxlICJTcGVjaWFsQ2FzaW5n LnR4dCIgZGVmaW5lcyB0aGUNCiAgIHNwZWNpZmljIGNhc2VzIHRoYXQgYXJlIGtub3duIHRvIGNh dXNlIHByb2JsZW1zIHdpdGggdGhpcy4gIEluDQogICBwYXJ0aWN1bGFyLCB0aGUgbGV0dGVyICdp JyAoVSswMDY5KSBpbiBUdXJraXNoIGFuZCBBemVyYmFpamFuaSBpcw0KICAgdXBwZXJjYXNlZCB0 byBVKzAxMzAgKExBVElOIENBUElUQUwgTEVUVEVSIEkgV0lUSCBET1QgQUJPVkUpLg0KICAgSW1w bGVtZW50ZXJzIFNIT1VMRCBzcGVjaWZ5IGEgbG9jYWxlLW5ldXRyYWwgY2FzaW5nIG9wZXJhdGlv biB0bw0KICAgZW5zdXJlIHRoYXQgY2FzZSBmb2xkaW5nIG9mIHN1YnRhZ3MgZG9lcyBub3QgcHJv ZHVjZSB0aGlzIHZhbHVlLA0KICAgd2hpY2ggaXMgaWxsZWdhbCBpbiBsYW5ndWFnZSB0YWdzLiAg Rm9yIGV4YW1wbGUsIGlmIG9uZSB3ZXJlIHRvDQogICB1cHBlcmNhc2UgdGhlIHJlZ2lvbiBzdWJ0 YWcgJ2luJyB1c2luZyBUdXJraXNoIGxvY2FsZSBydWxlcywgdGhlDQogICBzZXF1ZW5jZSBVKzAx MzAgVSswMDRFIHdvdWxkIHJlc3VsdCBpbnN0ZWFkIG9mIHRoZSBleHBlY3RlZCAnSU4nLg0KDQog ICBOb3RlOiBpZiB0aGUgZmllbGQgJ0RlcHJlY2F0ZWQnIGFwcGVhcnMgaW4gYSByZWdpc3RyeSBy ZWNvcmQgd2l0aG91dA0KICAgYW4gYWNjb21wYW55aW5nICdQcmVmZXJyZWQtVmFsdWUnIGZpZWxk LCB0aGVuIHRoYXQgdGFnIG9yIHN1YnRhZyBpcw0KICAgZGVwcmVjYXRlZCB3aXRob3V0IGEgcmVw bGFjZW1lbnQuICBWYWxpZGF0aW5nIHByb2Nlc3NvcnMgU0hPVUxEIE5PVA0KICAgZ2VuZXJhdGUg dGFncyB0aGF0IGluY2x1ZGUgdGhlc2UgdmFsdWVzLCBhbHRob3VnaCB0aGUgdmFsdWVzIGFyZQ0K ICAgY2Fub25pY2FsIHdoZW4gdGhleSBhcHBlYXIgaW4gYSBsYW5ndWFnZSB0YWcuDQoNCiAgIEFu IGV4dGVuc2lvbiBNVVNUIGRlZmluZSBhbnkgcmVsYXRpb25zaGlwcyB0aGF0IGV4aXN0IGJldHdl ZW4gdGhlDQogICB2YXJpb3VzIHN1YnRhZ3MgaW4gdGhlIGV4dGVuc2lvbiBhbmQgdGh1cyBNQVkg ZGVmaW5lIGFuIGFsdGVybmF0ZQ0KICAgY2Fub25pY2FsaXphdGlvbiBzY2hlbWUgZm9yIHRoZSBl eHRlbnNpb24ncyBzdWJ0YWdzLiAgRXh0ZW5zaW9ucyBNQVkNCiAgIGRlZmluZSBob3cgdGhlIG9y ZGVyIG9mIHRoZSBleHRlbnNpb24ncyBzdWJ0YWdzIGFyZSBpbnRlcnByZXRlZC4gIEZvcg0KICAg ZXhhbXBsZSwgYW4gZXh0ZW5zaW9uIGNvdWxkIGRlZmluZSB0aGF0IGl0cyBzdWJ0YWdzIGFyZSBp biBjYW5vbmljYWwNCiAgIG9yZGVyIHdoZW4gdGhlIHN1YnRhZ3MgYXJlIHBsYWNlZCBpbnRvIEFT Q0lJIG9yZGVyOiB0aGF0IGlzLCAiZW4tYS0NCiAgIGFhYS1iYmItY2NjIiBpbnN0ZWFkIG9mICJl bi1hLWNjYy1iYmItYWFhIi4gIEFub3RoZXIgZXh0ZW5zaW9uIG1pZ2h0DQogICBkZWZpbmUgdGhh dCB0aGUgb3JkZXIgb2YgdGhlIHN1YnRhZ3MgaW5mbHVlbmNlcyB0aGVpciBzZW1hbnRpYw0KICAg bWVhbmluZyAoc28gdGhhdCAiZW4tYi1jY2MtYmJiLWFhYSIgaGFzIGEgZGlmZmVyZW50IHZhbHVl IGZyb20gImVuLWItDQogICBhYWEtYmJiLWNjYyIpLiAgSG93ZXZlciwgZXh0ZW5zaW9uIHNwZWNp ZmljYXRpb25zIFNIT1VMRCBiZSBkZXNpZ25lZA0KICAgc28gdGhhdCB0aGV5IGFyZSB0b2xlcmFu dCBvZiB0aGUgdHlwaWNhbCBwcm9jZXNzZXMgZGVzY3JpYmVkIGluDQogICBTZWN0aW9uIDMuNi4N Cg0KNC41ICBDb25zaWRlcmF0aW9ucyBmb3IgUHJpdmF0ZSBVc2UgU3VidGFncw0KDQogICBQcml2 YXRlIHVzZSBzdWJ0YWdzLCBsaWtlIGFsbCBvdGhlciBzdWJ0YWdzLCBNVVNUIGNvbmZvcm0gdG8g dGhlDQogICBmb3JtYXQgYW5kIGNvbnRlbnQgY29uc3RyYWludHMgaW4gdGhlIEFCTkYuICBQcml2 YXRlIHVzZSBzdWJ0YWdzIGhhdmUNCiAgIG5vIG1lYW5pbmcgb3V0c2lkZSB0aGUgcHJpdmF0ZSBh Z3JlZW1lbnQgYmV0d2VlbiB0aGUgcGFydGllcyB0aGF0DQogICBpbnRlbmQgdG8gdXNlIG9yIGV4 Y2hhbmdlIGxhbmd1YWdlIHRhZ3MgdGhhdCBlbXBsb3kgdGhlbS4gIFRoZSBzYW1lDQogICBzdWJ0 YWdzIGNvdWxkIGJlIHVzZWQgd2l0aCBhIGRpZmZlcmVudCBtZWFuaW5nIHVuZGVyIGEgc2VwYXJh dGUNCiAgIHByaXZhdGUgYWdyZWVtZW50LiAgVGhleSBTSE9VTEQgTk9UIGJlIHVzZWQgd2hlcmUg YWx0ZXJuYXRpdmVzIGV4aXN0DQogICBhbmQgU0hPVUxEIE5PVCBiZSB1c2VkIGluIGNvbnRlbnQg b3IgcHJvdG9jb2xzIGludGVuZGVkIGZvciBnZW5lcmFsDQogICB1c2UuDQoNCiAgIFByaXZhdGUg dXNlIHN1YnRhZ3MgYXJlIHNpbXBseSB1c2VsZXNzIGZvciBpbmZvcm1hdGlvbiBleGNoYW5nZQ0K ICAgd2l0aG91dCBwcmlvciBhcnJhbmdlbWVudC4gIFRoZSB2YWx1ZSBhbmQgc2VtYW50aWMgbWVh bmluZyBvZiBwcml2YXRlDQogICB1c2UgdGFncyBhbmQgb2YgdGhlIHN1YnRhZ3MgdXNlZCB3aXRo aW4gc3VjaCBhIGxhbmd1YWdlIHRhZyBhcmUgbm90DQogICBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1l bnQuDQoNCiAgIFN1YnRhZ3MgZGVmaW5lZCBpbiB0aGUgSUFOQSByZWdpc3RyeSBhcyBoYXZpbmcg YSBzcGVjaWZpYyBwcml2YXRlIHVzZQ0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhw aXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2UgNDRdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICBK dWx5IDIwMDUNCg0KDQogICBtZWFuaW5nIGNvbnZleSBtb3JlIGluZm9ybWF0aW9uIHRoYXQgYSBw dXJlbHkgcHJpdmF0ZSB1c2UgdGFnDQogICBwcmVmaXhlZCBieSB0aGUgc2luZ2xldG9uIHN1YnRh ZyAneCcuICBGb3IgYXBwbGljYXRpb25zIHRoaXMNCiAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24g TUFZIGJlIHVzZWZ1bC4NCg0KICAgRm9yIGV4YW1wbGUsIHRoZSByZWdpb24gc3VidGFncyAnQUEn LCAnWlonIGFuZCBpbiB0aGUgcmFuZ2VzDQogICAnUU0nLSdRWicgYW5kICdYQSctJ1haJyAoZGVy aXZlZCBmcm9tIElTTyAzMTY2IHByaXZhdGUgdXNlIGNvZGVzKSBNQVkNCiAgIGJlIHVzZWQgdG8g Zm9ybSBhIGxhbmd1YWdlIHRhZy4gIEEgdGFnIHN1Y2ggYXMgInpoLUhhbnMtWFEiIGNvbnZleXMg YQ0KICAgZ3JlYXQgZGVhbCBvZiBwdWJsaWMsIGludGVyY2hhbmdlYWJsZSBpbmZvcm1hdGlvbiBh Ym91dCB0aGUgbGFuZ3VhZ2UNCiAgIG1hdGVyaWFsICh0aGF0IGl0IGlzIENoaW5lc2UgaW4gdGhl IHNpbXBsaWZpZWQgQ2hpbmVzZSBzY3JpcHQgYW5kIGlzDQogICBzdWl0YWJsZSBmb3Igc29tZSBn ZW9ncmFwaGljIHJlZ2lvbiAnWFEnKS4gIFdoaWxlIHRoZSBwcmVjaXNlDQogICBnZW9ncmFwaGlj IHJlZ2lvbiBpcyBub3Qga25vd24gb3V0c2lkZSBvZiBwcml2YXRlIGFncmVlbWVudCwgdGhlIHRh Zw0KICAgY29udmV5cyBmYXIgbW9yZSBpbmZvcm1hdGlvbiB0aGFuIGFuIG9wYXF1ZSB0YWcgc3Vj aCBhcyAieC1zb21lTGFuZyIsDQogICB3aGljaCBjb250YWlucyBubyBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgbGFuZ3VhZ2Ugc3VidGFnIG9yIHNjcmlwdA0KICAgc3VidGFnIG91dHNpZGUgb2YgdGhl IHByaXZhdGUgYWdyZWVtZW50Lg0KDQogICBIb3dldmVyLCBpbiBzb21lIGNhc2VzIGNvbnRlbnQg dGFnZ2VkIHdpdGggcHJpdmF0ZSB1c2Ugc3VidGFncyBNQVkNCiAgIGludGVyYWN0IHdpdGggb3Ro ZXIgc3lzdGVtcyBpbiBhIGRpZmZlcmVudCBhbmQgcG9zc2libHkgdW5zdWl0YWJsZQ0KICAgbWFu bmVyIGNvbXBhcmVkIHRvIHRhZ3MgdGhhdCB1c2Ugb3BhcXVlLCBwcml2YXRlbHkgZGVmaW5lZCBz dWJ0YWdzLA0KICAgc28gdGhlIGNob2ljZSBvZiB0aGUgYmVzdCBhcHByb2FjaCBzb21ldGltZXMg ZGVwZW5kcyBvbiB0aGUNCiAgIHBhcnRpY3VsYXIgZG9tYWluIGluIHF1ZXN0aW9uLg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQ aGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAg ICAgICBbUGFnZSA0NV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1y ZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNCjUuICBJQU5BIENvbnNpZGVy YXRpb25zDQoNCiAgIFRoaXMgc2VjdGlvbiBkZWFscyB3aXRoIHRoZSBwcm9jZXNzZXMgYW5kIHJl cXVpcmVtZW50cyBuZWNlc3NhcnkgZm9yDQogICBJQU5BIHRvIHVuZGVydGFrZSB0byBtYWludGFp biB0aGUgc3VidGFnIGFuZCBleHRlbnNpb24gcmVnaXN0cmllcyBhcw0KICAgZGVmaW5lZCBieSB0 aGlzIGRvY3VtZW50IGFuZCBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIHJlcXVpcmVtZW50cyBvZg0K ICAgW1JGQzI0MzRdLg0KDQogICBUaGUgaW1wYWN0IG9uIHRoZSBJQU5BIG1haW50YWluZXJzIG9m IHRoZSB0d28gcmVnaXN0cmllcyBkZWZpbmVkIGJ5DQogICB0aGlzIGRvY3VtZW50IHdpbGwgYmUg YSBzbWFsbCBpbmNyZWFzZSBpbiB0aGUgZnJlcXVlbmN5IG9mIG5ldw0KICAgZW50cmllcyBvciB1 cGRhdGVzLg0KDQo1LjEgIExhbmd1YWdlIFN1YnRhZyBSZWdpc3RyeQ0KDQogICBVcG9uIGFkb3B0 aW9uIG9mIHRoaXMgZG9jdW1lbnQsIHRoZSByZWdpc3RyeSB3aWxsIGJlIGluaXRpYWxpemVkIGJ5 IGENCiAgIGNvbXBhbmlvbiBkb2N1bWVudDogW2luaXRpYWwtcmVnaXN0cnldLiAgVGhlIGNyaXRl cmlhIGFuZCBwcm9jZXNzIGZvcg0KICAgc2VsZWN0aW5nIHRoZSBpbml0aWFsIHNldCBvZiByZWNv cmRzIGlzIGRlc2NyaWJlZCBpbiB0aGF0IGRvY3VtZW50Lg0KICAgVGhlIGluaXRpYWwgc2V0IG9m IHJlY29yZHMgcmVwcmVzZW50cyBubyBpbXBhY3Qgb24gSUFOQSwgc2luY2UgdGhlDQogICB3b3Jr IHRvIGNyZWF0ZSBpdCB3aWxsIGJlIHBlcmZvcm1lZCBleHRlcm5hbGx5Lg0KDQogICBUaGUgbmV3 IHJlZ2lzdHJ5IE1VU1QgYmUgbGlzdGVkIHVuZGVyICJMYW5ndWFnZSBUYWdzIiBhdA0KICAgPGh0 dHA6Ly93d3cuaWFuYS5vcmcvbnVtYmVycy5odG1sPiwgcmVwbGFjaW5nIHRoZSBleGlzdGluZw0K ICAgcmVnaXN0cmF0aW9ucyBkZWZpbmVkIGJ5IFtSRkMzMDY2XS4gIFRoZSBleGlzdGluZyBzZXQg b2YgcmVnaXN0cmF0aW9uDQogICBmb3JtcyBhbmQgUkZDIDMwNjYgcmVnaXN0cmF0aW9ucyB3aWxs IGJlIHJlbGFiZWxlZCBhcyAiTGFuZ3VhZ2UgVGFncw0KICAgKE9ic29sZXRlKSIgYW5kIG1haW50 YWluZWQgKGJ1dCBub3QgYWRkZWQgdG8gb3IgbW9kaWZpZWQpLg0KDQogICBGdXR1cmUgd29yayBv biB0aGUgTGFuZ3VhZ2UgU3VidGFnIFJlZ2lzdHJ5IHdpbGwgYmUgbGltaXRlZCB0bw0KICAgaW5z ZXJ0aW5nIG9yIHJlcGxhY2luZyB3aG9sZSByZWNvcmRzIHByZWZvcm1hdHRlZCBmb3IgSUFOQSBi eSB0aGUNCiAgIExhbmd1YWdlIFN1YnRhZyBSZXZpZXdlciBhcyBkZXNjcmliZWQgaW4gU2VjdGlv biAzLjIgb2YgdGhpcw0KICAgZG9jdW1lbnQuICBUaGlzIHNpbXBsaWZpZXMgSUFOQSdzIHdvcmsg YnkgbGltaXRpbmcgaXQgdG8gcGxhY2luZyB0aGUNCiAgIHRleHQgaW4gdGhlIGFwcHJvcHJpYXRl IGxvY2F0aW9uIGluIHRoZSByZWdpc3RyeS4NCg0KICAgRWFjaCByZWNvcmQgd2lsbCBiZSBzZW50 IHRvIGlhbmFAaWFuYS5vcmcgd2l0aCBhIHN1YmplY3QgbGluZQ0KICAgaW5kaWNhdGluZyB3aGV0 aGVyIHRoZSBlbmNsb3NlZCByZWNvcmQgaXMgYW4gaW5zZXJ0aW9uIG9mIGEgbmV3DQogICByZWNv cmQgKGluZGljYXRlZCBieSB0aGUgd29yZCAiSU5TRVJUIiBpbiB0aGUgc3ViamVjdCBsaW5lKSBv ciBhDQogICByZXBsYWNlbWVudCBvZiBhbiBleGlzdGluZyByZWNvcmQgKGluZGljYXRlZCBieSB0 aGUgd29yZCAiTU9ESUZZIiBpbg0KICAgdGhlIHN1YmplY3QgbGluZSkuICBSZWNvcmRzIE1VU1Qg Tk9UIGJlIGRlbGV0ZWQgZnJvbSB0aGUgcmVnaXN0cnkuDQogICBJQU5BIE1VU1QgcGxhY2UgYW55 IGluc2VydGVkIG9yIG1vZGlmaWVkIHJlY29yZHMgaW50byB0aGUgYXBwcm9wcmlhdGUNCiAgIHNl Y3Rpb24gb2YgdGhlIGxhbmd1YWdlIHN1YnRhZyByZWdpc3RyeSwgZ3JvdXBpbmcgdGhlIHJlY29y ZHMgYnkNCiAgIHRoZWlyICJUeXBlIiBmaWVsZC4gIEluc2VydGVkIHJlY29yZHMgTUFZIGJlIHBs YWNlZCBhbnl3aGVyZSBpbiB0aGUNCiAgIGFwcHJvcHJpYXRlIHNlY3Rpb247IHRoZXJlIGlzIG5v IGd1YXJhbnRlZSBvZiB0aGUgb3JkZXIgb2YgdGhlDQogICByZWNvcmRzIGJleW9uZCBncm91cGlu ZyB0aGVtIHRvZ2V0aGVyIGJ5ICdUeXBlJy4gIE1vZGlmaWVkIHJlY29yZHMNCiAgIE1VU1Qgb3Zl cndyaXRlIHRoZSByZWNvcmQgdGhleSByZXBsYWNlLg0KDQogICBJbmNsdWRlZCBpbiBhbnkgcmVx dWVzdCB0byBpbnNlcnQgb3IgbW9kaWZ5IHJlY29yZHMgTVVTVCBiZSBhIG5ldw0KICAgRmlsZS1E YXRlIHJlY29yZC4gIFRoaXMgcmVjb3JkIE1VU1QgYmUgcGxhY2VkIGZpcnN0IGluIHRoZSByZWdp c3RyeS4NCiAgIEluIHRoZSBldmVudCB0aGF0IHRoZSBGaWxlLURhdGUgcmVjb3JkIHByZXNlbnQg aW4gdGhlIHJlZ2lzdHJ5IGhhcyBhDQogICBsYXRlciBkYXRlIHRoZW4gdGhlIHJlY29yZCBiZWlu ZyBpbnNlcnRlZCBvciBtb2RpZmllZCwgdGhlIGV4aXN0aW5nDQogICByZWNvcmQgTVVTVCBiZSBw cmVzZXJ2ZWQuDQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkg MTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA0Nl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoN CjUuMiAgRXh0ZW5zaW9ucyBSZWdpc3RyeQ0KDQogICBUaGUgTGFuZ3VhZ2UgVGFnIEV4dGVuc2lv bnMgcmVnaXN0cnkgd2lsbCBhbHNvIGJlIGdlbmVyYXRlZCBhbmQgc2VudA0KICAgdG8gSUFOQSBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjYuICBUaGlzIHJlZ2lzdHJ5IGNhbiBjb250YWluIGF0 DQogICBtb3N0IDM1IHJlY29yZHMgYW5kIHRodXMgY2hhbmdlcyB0byB0aGlzIHJlZ2lzdHJ5IGFy ZSBleHBlY3RlZCB0byBiZQ0KICAgdmVyeSBpbmZyZXF1ZW50Lg0KDQogICBGdXR1cmUgd29yayBi eSBJQU5BIG9uIHRoZSBMYW5ndWFnZSBUYWcgRXh0ZW5zaW9ucyBSZWdpc3RyeSBpcw0KICAgbGlt aXRlZCB0byB0d28gY2FzZXMuICBGaXJzdCwgdGhlIElFU0cgTUFZIHJlcXVlc3QgdGhhdCBuZXcg cmVjb3Jkcw0KICAgYmUgaW5zZXJ0ZWQgaW50byB0aGlzIHJlZ2lzdHJ5IGZyb20gdGltZSB0byB0 aW1lLiAgVGhlc2UgcmVxdWVzdHMNCiAgIHdpbGwgaW5jbHVkZSB0aGUgcmVjb3JkIHRvIGluc2Vy dCBpbiB0aGUgZXhhY3QgZm9ybWF0IGRlc2NyaWJlZCBpbg0KICAgU2VjdGlvbiAzLjYuICBJbiBh ZGRpdGlvbiwgdGhlcmUgTUFZIGJlIG9jY2FzaW9uYWwgcmVxdWVzdHMgZnJvbSB0aGUNCiAgIG1h aW50YWluaW5nIGF1dGhvcml0eSBmb3IgYSBzcGVjaWZpYyBleHRlbnNpb24gdG8gdXBkYXRlIHRo ZSBjb250YWN0DQogICBpbmZvcm1hdGlvbiBvciBVUkxzIGluIHRoZSByZWNvcmQuICBUaGVzZSBy ZXF1ZXN0cyBNVVNUIGluY2x1ZGUgdGhlDQogICBjb21wbGV0ZSwgdXBkYXRlZCByZWNvcmQuICBJ QU5BIGlzIG5vdCByZXNwb25zaWJsZSBmb3IgdmFsaWRhdGluZyB0aGUNCiAgIGluZm9ybWF0aW9u IHByb3ZpZGVkLCBvbmx5IHRoYXQgaXQgaXMgcHJvcGVybHkgZm9ybWF0dGVkLiAgSXQgc2hvdWxk DQogICByZWFzb25hYmx5IGJlIHNlZW4gdG8gY29tZSBmcm9tIHRoZSBtYWludGFpbmluZyBhdXRo b3JpdHkgbmFtZWQgaW4NCiAgIHRoZSByZWNvcmQgcHJlc2VudCBpbiB0aGUgcmVnaXN0cnkuDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDYg ICAgICAgICAgICAgICBbUGFnZSA0N10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNCjYuICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBMYW5ndWFnZSB0YWdzIHVzZWQgaW4gY29udGVudCBu ZWdvdGlhdGlvbiwgbGlrZSBhbnkgb3RoZXIgaW5mb3JtYXRpb24NCiAgIGV4Y2hhbmdlZCBvbiB0 aGUgSW50ZXJuZXQsIG1pZ2h0IGJlIGEgc291cmNlIG9mIGNvbmNlcm4gYmVjYXVzZSB0aGV5DQog ICBtaWdodCBiZSB1c2VkIHRvIGluZmVyIHRoZSBuYXRpb25hbGl0eSBvZiB0aGUgc2VuZGVyLCBh bmQgdGh1cw0KICAgaWRlbnRpZnkgcG90ZW50aWFsIHRhcmdldHMgZm9yIHN1cnZlaWxsYW5jZS4N Cg0KICAgVGhpcyBpcyBhIHNwZWNpYWwgY2FzZSBvZiB0aGUgZ2VuZXJhbCBwcm9ibGVtIHRoYXQg YW55dGhpbmcgc2VudCBpcw0KICAgdmlzaWJsZSB0byB0aGUgcmVjZWl2aW5nIHBhcnR5IGFuZCBw b3NzaWJseSB0byB0aGlyZCBwYXJ0aWVzIGFzIHdlbGwuDQogICBJdCBpcyB1c2VmdWwgdG8gYmUg YXdhcmUgdGhhdCBzdWNoIGNvbmNlcm5zIGNhbiBleGlzdCBpbiBzb21lIGNhc2VzLg0KDQogICBU aGUgZXZhbHVhdGlvbiBvZiB0aGUgZXhhY3QgbWFnbml0dWRlIG9mIHRoZSB0aHJlYXQsIGFuZCBh bnkgcG9zc2libGUNCiAgIGNvdW50ZXJtZWFzdXJlcywgaXMgbGVmdCB0byBlYWNoIGFwcGxpY2F0 aW9uIHByb3RvY29sIChzZWUgQkNQIDcyDQogICBbUkZDMzU1Ml0gZm9yIGJlc3QgY3VycmVudCBw cmFjdGljZSBndWlkYW5jZSBvbiBzZWN1cml0eSB0aHJlYXRzIGFuZA0KICAgZGVmZW5zZXMpLg0K DQogICBUaGUgbGFuZ3VhZ2UgdGFnIGFzc29jaWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIgaW5mb3Jt YXRpb24gaXRlbSBpcyBvZg0KICAgbm8gY29uc2VxdWVuY2Ugd2hhdHNvZXZlciBpbiBkZXRlcm1p bmluZyB3aGV0aGVyIHRoYXQgY29udGVudCBtaWdodA0KICAgY29udGFpbiBwb3NzaWJsZSBob21v Z3JhcGhzLiAgVGhlIGZhY3QgdGhhdCBhIHRleHQgaXMgdGFnZ2VkIGFzIGJlaW5nDQogICBpbiBv bmUgbGFuZ3VhZ2Ugb3IgdXNpbmcgYSBwYXJ0aWN1bGFyIHNjcmlwdCBzdWJ0YWcgcHJvdmlkZXMg bm8NCiAgIGFzc3VyYW5jZSB3aGF0c29ldmVyIHRoYXQgaXQgZG9lcyBub3QgY29udGFpbiBjaGFy YWN0ZXJzIGZyb20gc2NyaXB0cw0KICAgb3RoZXIgdGhhbiB0aGUgb25lKHMpIGFzc29jaWF0ZWQg d2l0aCBvciBzcGVjaWZpZWQgYnkgdGhhdCBsYW5ndWFnZQ0KICAgdGFnLg0KDQogICBTaW5jZSB0 aGVyZSBpcyBubyBsaW1pdCB0byB0aGUgbnVtYmVyIG9mIHZhcmlhbnQsIHByaXZhdGUgdXNlLCBh bmQNCiAgIGV4dGVuc2lvbiBzdWJ0YWdzLCBhbmQgY29uc2VxdWVudGx5IG5vIGxpbWl0IG9uIHRo ZSBwb3NzaWJsZSBsZW5ndGgNCiAgIG9mIGEgdGFnLCBpbXBsZW1lbnRhdGlvbnMgbmVlZCB0byBn dWFyZCBhZ2FpbnN0IGJ1ZmZlciBvdmVyZmxvdw0KICAgYXR0YWNrcy4gIFNlZSBTZWN0aW9uIDQu MyBmb3IgZGV0YWlscyBvbiBsYW5ndWFnZSB0YWcgdHJ1bmNhdGlvbiwNCiAgIHdoaWNoIGNhbiBv Y2N1ciBhcyBhIGNvbnNlcXVlbmNlIG9mIGRlZmVuc2VzIGFnYWluc3QgYnVmZmVyIG92ZXJmbG93 Lg0KDQogICBBbHRob3VnaCB0aGUgc3BlY2lmaWNhdGlvbiBvZiB2YWxpZCBzdWJ0YWdzIGZvciBh biBleHRlbnNpb24gKHNlZToNCiAgIFNlY3Rpb24gMy42KSBNVVNUIGJlIGF2YWlsYWJsZSBvdmVy IHRoZSBJbnRlcm5ldCwgaW1wbGVtZW50YXRpb25zDQogICBTSE9VTEQgTk9UIG1lY2hhbmljYWxs eSBkZXBlbmQgb24gaXQgYmVpbmcgYWx3YXlzIGFjY2Vzc2libGUsIHRvDQogICBwcmV2ZW50IGRl bmlhbC1vZi1zZXJ2aWNlIGF0dGFja3MuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAg ICAgICAgICAgW1BhZ2UgNDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3Rh Z3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQo3LiAgQ2hhcmFjdGVy IFNldCBDb25zaWRlcmF0aW9ucw0KDQogICBUaGUgc3ludGF4IGluIHRoaXMgZG9jdW1lbnQgcmVx dWlyZXMgdGhhdCBsYW5ndWFnZSB0YWdzIHVzZSBvbmx5IHRoZQ0KICAgY2hhcmFjdGVycyBBLVos IGEteiwgMC05LCBhbmQgSFlQSEVOLU1JTlVTLCB3aGljaCBhcmUgcHJlc2VudCBpbiBtb3N0DQog ICBjaGFyYWN0ZXIgc2V0cywgc28gdGhlIGNvbXBvc2l0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mgc2hv dWxkIG5vdCBoYXZlDQogICBhbnkgY2hhcmFjdGVyIHNldCBpc3N1ZXMuDQoNCiAgIFJlbmRlcmlu ZyBvZiBjaGFyYWN0ZXJzIGJhc2VkIG9uIHRoZSBjb250ZW50IG9mIGEgbGFuZ3VhZ2UgdGFnIGlz IG5vdA0KICAgYWRkcmVzc2VkIGluIHRoaXMgbWVtby4gIEhpc3RvcmljYWxseSwgc29tZSBsYW5n dWFnZXMgaGF2ZSByZWxpZWQgb24NCiAgIHRoZSB1c2Ugb2Ygc3BlY2lmaWMgY2hhcmFjdGVyIHNl dHMgb3Igb3RoZXIgaW5mb3JtYXRpb24gaW4gb3JkZXIgdG8NCiAgIGluZmVyIGhvdyBhIHNwZWNp ZmljIGNoYXJhY3RlciBzaG91bGQgYmUgcmVuZGVyZWQgKG5vdGFibHkgdGhpcw0KICAgYXBwbGll cyB0byBsYW5ndWFnZSBhbmQgY3VsdHVyZSBzcGVjaWZpYyB2YXJpYXRpb25zIG9mIEhhbiBpZGVv Z3JhcGhzDQogICBhcyB1c2VkIGluIEphcGFuZXNlLCBDaGluZXNlLCBhbmQgS29yZWFuKS4gIFdo ZW4gbGFuZ3VhZ2UgdGFncyBhcmUNCiAgIGFwcGxpZWQgdG8gc3BhbnMgb2YgdGV4dCwgcmVuZGVy aW5nIGVuZ2luZXMgY2FuIHVzZSB0aGF0IGluZm9ybWF0aW9uDQogICBpbiBkZWNpZGluZyB3aGlj aCBmb250IHRvIHVzZSBpbiB0aGUgYWJzZW5jZSBvZiBvdGhlciBpbmZvcm1hdGlvbiwNCiAgIHBh cnRpY3VsYXJseSB3aGVyZSBsYW5ndWFnZXMgd2l0aCBkaXN0aW5jdCB3cml0aW5nIHRyYWRpdGlv bnMgdXNlIHRoZQ0KICAgc2FtZSBjaGFyYWN0ZXJzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAmIERh dmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA0 OV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAg ICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNCjguICBDaGFuZ2VzIGZyb20gUkZDIDMwNjYNCg0K ICAgVGhlIG1haW4gZ29hbHMgZm9yIHRoaXMgcmV2aXNpb24gb2YgbGFuZ3VhZ2UgdGFncyB3ZXJl IHRoZSBmb2xsb3dpbmc6DQoNCiAgICpDb21wYXRpYmlsaXR5LiogQWxsIFJGQyAzMDY2IGxhbmd1 YWdlIHRhZ3MgIChpbmNsdWRpbmcgdGhvc2UgaW4gdGhlDQogICBJQU5BIHJlZ2lzdHJ5KSAgcmVt YWluIHZhbGlkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRoZSBjaGFuZ2VzIGluDQogICB0aGlz IGRvY3VtZW50IHJlcHJlc2VudCBhZGRpdGlvbmFsIGNvbnN0cmFpbnRzIG9uIGxhbmd1YWdlIHRh Z3MuDQogICBUaGF0IGlzLCBpbiBubyBjYXNlIGlzIHRoZSBzeW50YXggbW9yZSBwZXJtaXNzaXZl IGFuZCBwcm9jZXNzb3JzDQogICBiYXNlZCBvbiB0aGUgUkZDIDMwNjYgQUJORiAoc3VjaCBhcyB0 aG9zZSBkZXNjcmliZWQgaW4gW1hNTFNjaGVtYV0pDQogICB3aWxsIGJlIGFibGUgdG8gcHJvY2Vz cyB0aGUgdGFncyBkZXNjcmliZWQgYnkgdGhpcyBkb2N1bWVudC4gIEluDQogICBhZGRpdGlvbiwg dGhpcyBkb2N1bWVudCBkZWZpbmVzIGxhbmd1YWdlIHRhZ3MgaW4gc3VjaCBhcyB3YXkgYXMgdG8N CiAgIGVuc3VyZSBmdXR1cmUgY29tcGF0aWJpbGl0eS4NCg0KICAgKlN0YWJpbGl0eS4qIEJlY2F1 c2Ugb2YgY2hhbmdlcyBpbiB0aGUgcGFzdCBpbiB0aGUgdW5kZXJseWluZyBJU08NCiAgIHN0YW5k YXJkcywgYSB2YWxpZCBSRkMgMzA2NiBsYW5ndWFnZSB0YWcgY291bGQgYmVjb21lIGludmFsaWQg b3IgaGF2ZQ0KICAgaXRzIG1lYW5pbmcgY2hhbmdlLiAgVGhpcyBoYXMgdGhlIHBvdGVudGlhbCBv ZiBpbnZhbGlkYXRpbmcgY29udGVudA0KICAgdGhhdCBtYXkgaGF2ZSBhbiBleHRlbnNpdmUgc2hl bGYtbGlmZS4gIEluIHRoaXMgc3BlY2lmaWNhdGlvbiwgb25jZSBhDQogICBsYW5ndWFnZSB0YWcg aXMgdmFsaWQsIGl0IHJlbWFpbnMgdmFsaWQgZm9yZXZlci4NCg0KICAgKlZhbGlkaXR5LiogIFRo ZSBzdHJ1Y3R1cmUgb2YgbGFuZ3VhZ2UgdGFncyBkZWZpbmVkIGJ5IHRoaXMgZG9jdW1lbnQNCiAg IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGRldGVybWluZSBpZiBhIHBhcnRpY3VsYXIgdGFnIGlzIHdl bGwtZm9ybWVkDQogICB3aXRob3V0IHJlZ2FyZCBmb3IgdGhlIGFjdHVhbCBjb250ZW50IG9yICJt ZWFuaW5nIiBvZiB0aGUgdGFnIGFzIGENCiAgIHdob2xlLiAgVGhpcyBpcyBpbXBvcnRhbnQgYmVj YXVzZSB0aGUgcmVnaXN0cnkgZ3Jvd3MgYW5kIHVuZGVybHlpbmcNCiAgIHN0YW5kYXJkcyAgY2hh bmdlIG92ZXIgdGltZS4gIEluIGFkZGl0aW9uLCBpdCBtdXN0IGJlIHBvc3NpYmxlIHRvDQogICBk ZXRlcm1pbmUgaWYgYSB0YWcgaXMgdmFsaWQgKG9yIG5vdCkgZm9yIGEgZ2l2ZW4gcG9pbnQgaW4g dGltZSBpbg0KICAgb3JkZXIgIHRvIHByb3ZpZGUgcmVwcm9kdWNpYmxlLCB0ZXN0YWJsZSByZXN1 bHRzLiAgVGhpcyBwcm9jZXNzIG11c3QNCiAgIG5vdCBiZSBlcnJvci1wcm9uZTsgb3RoZXJ3aXNl IGltcGxlbWVudGF0aW9ucyBtaWdodCBnaXZlIGRpZmZlcmVudA0KICAgcmVzdWx0cy4gIEJ5IGhh dmluZyBhbiBhdXRob3JpdGF0aXZlIHJlZ2lzdHJ5IHdpdGggc3BlY2lmaWMNCiAgIHZlcnNpb25p bmcgaW5mb3JtYXRpb24sIHRoZSB2YWxpZGl0eSBvZiBsYW5ndWFnZSB0YWdzIGF0IGFueSBwb2lu dCBpbg0KICAgdGltZSBjYW4gYmUgcHJlY2lzZWx5IGRldGVybWluZWQgKGluc3RlYWQgb2YgaW50 ZXJwb2xhdGluZyB2YWx1ZXMNCiAgIGZyb20gbWFueSBzZXBhcmF0ZSBzb3VyY2VzKS4NCg0KICAg KlV0aWxpdHkuKiBJdCBpcyBzb21ldGltZXMgaW1wb3J0YW50IHRvIGJlIGFibGUgdG8gZGlmZmVy ZW50aWF0ZQ0KICAgYmV0d2VlbiB3cml0dGVuIGZvcm1zIG9mIGEgbGFuZ3VhZ2UgLS0gZm9yIG1h bnkgaW1wbGVtZW50YXRpb25zIHRoaXMNCiAgIGlzIG1vcmUgaW1wb3J0YW50IHRoYW4gZGlzdGlu Z3Vpc2hpbmcgYmV0d2VlbiB0aGUgc3Bva2VuIHZhcmlhbnRzIG9mDQogICBhIGxhbmd1YWdlLiAg TGFuZ3VhZ2VzIGFyZSB3cml0dGVuIGluIGEgd2lkZSB2YXJpZXR5IG9mIGRpZmZlcmVudA0KICAg c2NyaXB0cywgc28gdGhpcyBkb2N1bWVudCBwcm92aWRlcyBmb3IgdGhlIGdlbmVyYXRpdmUgdXNl IG9mIElTTw0KICAgMTU5MjQgc2NyaXB0IGNvZGVzLiAgTGlrZSB0aGUgZ2VuZXJhdGl2ZSB1c2Ug b2YgSVNPIGxhbmd1YWdlIGFuZA0KICAgY291bnRyeSBjb2RlcyBpbiBSRkMgMzA2NiwgdGhpcyBh bGxvd3MgY29tYmluYXRpb25zIHRvIGJlIHByb2R1Y2VkDQogICB3aXRob3V0IHJlc29ydGluZyB0 byB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MuICBUaGUgYWRkaXRpb24gb2YgVU4NCiAgIE0uNDkg Y29kZXMgcHJvdmlkZXMgZm9yIHRoZSBnZW5lcmF0aW9uIG9mIGxhbmd1YWdlIHRhZ3Mgd2l0aCBy ZWdpb25hbA0KICAgc2NvcGUsIHdoaWNoIGlzIGFsc28gcmVxdWlyZWQgYnkgc29tZSBhcHBsaWNh dGlvbnMuDQoNCiAgIFRoZSByZWNhc3Qgb2YgdGhlIHJlZ2lzdHJ5IGZyb20gY29udGFpbmluZyB3 aG9sZSBsYW5ndWFnZSB0YWdzIHRvDQogICBzdWJ0YWdzIGlzIGEga2V5IHBhcnQgb2YgdGhpcy4g IEFuIGltcG9ydGFudCBmZWF0dXJlIG9mIFJGQyAzMDY2IHdhcw0KICAgdGhhdCBpdCBhbGxvd2Vk IGdlbmVyYXRpdmUgdXNlIG9mIHN1YnRhZ3MuICBUaGlzIGFsbG93cyBwZW9wbGUgdG8NCiAgIG1l YW5pbmdmdWxseSB1c2UgZ2VuZXJhdGVkIHRhZ3MsIHdpdGhvdXQgdGhlIGRlbGF5cyBpbiByZWdp c3RlcmluZw0KICAgd2hvbGUgdGFncyBvciB0aGUgbmVlZCB0byByZWdpc3RlciBhbGwgb2YgdGhl IGNvbWJpbmF0aW9ucyB0aGF0IG1pZ2h0DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBF eHBpcmVzIEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAgICAgICBbUGFnZSA1MF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAg IEp1bHkgMjAwNQ0KDQoNCiAgIGJlIHVzZWZ1bC4NCg0KICAgVGhlIGNob2ljZSBvZiBwbGFjaW5n IHRoZSBleHRlbmRlZCBsYW5ndWFnZSBhbmQgc2NyaXB0IHN1YnRhZ3MNCiAgIGJldHdlZW4gdGhl IHByaW1hcnkgbGFuZ3VhZ2UgYW5kIHJlZ2lvbiBzdWJ0YWdzIHdhcyB3aWRlbHkgZGViYXRlZC4N CiAgIFRoaXMgZGVzaWduIHdhcyBjaG9zZW4gYmVjYXVzZSB0aGUgcHJldmFsZW50IG1hdGNoaW5n IGFuZCBjb250ZW50DQogICBuZWdvdGlhdGlvbiBzY2hlbWVzIHJlbHkgb24gdGhlIHN1YnRhZ3Mg YmVpbmcgYXJyYW5nZWQgaW4gb3JkZXIgb2YNCiAgIGluY3JlYXNpbmcgc3BlY2lmaWNpdHkuICBU aGF0IGlzLCB0aGUgc3VidGFncyB0aGF0IG1hcmsgYSBncmVhdGVyDQogICBiYXJyaWVyIHRvIG11 dHVhbCBpbnRlbGxpZ2liaWxpdHkgYXBwZWFyIGxlZnQtbW9zdCBpbiBhIHRhZy4gIEZvcg0KICAg ZXhhbXBsZSwgd2hlbiBzZWxlY3RpbmcgY29udGVudCB3cml0dGVuIGluIEF6ZXJiYWlqYW5pLCB0 aGUgc2NyaXB0DQogICAoQXJhYmljLCBDeXJpbGxpYywgb3IgTGF0aW4pIHJlcHJlc2VudHMgYSBn cmVhdGVyIGJhcnJpZXIgdG8NCiAgIHVuZGVyc3RhbmRpbmcgdGhhbiBhbnkgcmVnaW9uYWwgdmFy aWF0aW9ucyAodGhvc2UgYXNzb2NpYXRlZCB3aXRoDQogICBBemVyYmFpamFuIG9yIElyYW4sIGZv ciBleGFtcGxlKS4gIEluZGl2aWR1YWxzIHdobyBwcmVmZXIgZG9jdW1lbnRzDQogICBpbiBhIHBh cnRpY3VsYXIgc2NyaXB0LCBidXQgY2FuIGRlYWwgd2l0aCB0aGUgbWlub3IgcmVnaW9uYWwNCiAg IGRpZmZlcmVuY2VzLCBjYW4gdGhlcmVmb3JlIHNlbGVjdCBhcHByb3ByaWF0ZSBjb250ZW50LiAg QXBwbGljYXRpb25zDQogICB0aGF0IGRvIG5vdCBkZWFsIHdpdGggd3JpdHRlbiBjb250ZW50IHdp bGwgY29udGludWUgdG8gb21pdCB0aGVzZQ0KICAgc3VidGFncy4NCg0KICAgKkV4dGVuc2liaWxp dHkuKiBCZWNhdXNlIG9mIHRoZSB3aWRlc3ByZWFkIHVzZSBvZiBsYW5ndWFnZSB0YWdzLCBpdA0K ICAgaXMgZGlzcnVwdGl2ZSB0byBoYXZlIHBlcmlvZGljIHJldmlzaW9ucyBvZiB0aGUgY29yZSBz cGVjaWZpY2F0aW9uLA0KICAgZXZlbiBpbiB0aGUgZmFjZSBvZiBkZW1vbnN0cmF0ZWQgbmVlZC4g IFRoZSBleHRlbnNpb24gbWVjaGFuaXNtDQogICBwcm92aWRlcyBmb3IgYSB3YXkgZm9yIGluZGVw ZW5kZW50IFJGQ3MgdG8gZGVmaW5lIGV4dGVuc2lvbnMgdG8NCiAgIGxhbmd1YWdlIHRhZ3MuICBU aGVzZSBleHRlbnNpb25zIGhhdmUgYSB2ZXJ5IGNvbnN0cmFpbmVkLCB3ZWxsLQ0KICAgZGVmaW5l ZCBzdHJ1Y3R1cmUgdGhhdCBwcmV2ZW50IGV4dGVuc2lvbnMgZnJvbSBpbnRlcmZlcmluZyB3aXRo DQogICBpbXBsZW1lbnRhdGlvbnMgb2YgbGFuZ3VhZ2UgdGFncyBkZWZpbmVkIGluIHRoaXMgZG9j dW1lbnQuDQoNCiAgIFRoZSBkb2N1bWVudCBhbHNvIGFudGljaXBhdGVzIGZlYXR1cmVzIG9mIElT TyA2MzktMyB3aXRoIHRoZSBhZGRpdGlvbg0KICAgb2YgdGhlIGV4dGVuZGVkIGxhbmd1YWdlIHN1 YnRhZ3MsIGFzIHdlbGwgYXMgdGhlIHBvc3NpYmlsaXR5IG9mIG90aGVyDQogICBJU08gNjM5IHBh cnRzIGJlY29taW5nIHVzZWZ1bCBmb3IgdGhlIGZvcm1hdGlvbiBvZiBsYW5ndWFnZSB0YWdzIGlu DQogICB0aGUgZnV0dXJlLg0KDQogICBUaGUgdXNlIGFuZCBkZWZpbml0aW9uIG9mIHByaXZhdGUg dXNlIHRhZ3MgaGFzIGFsc28gYmVlbiBtb2RpZmllZCwgdG8NCiAgIGFsbG93IHBlb3BsZSB0byB1 c2UgcHJpdmF0ZSB1c2Ugc3VidGFncyB0byBleHRlbmQgb3IgbW9kaWZ5IGRlZmluZWQNCiAgIHRh Z3MgYW5kIHRvIG1vdmUgYXMgbXVjaCBpbmZvcm1hdGlvbiBhcyBwb3NzaWJsZSBvdXQgb2YgcHJp dmF0ZSB1c2UNCiAgIGFuZCBpbnRvIHRoZSByZWd1bGFyIHN0cnVjdHVyZS4NCg0KICAgVGhlIGdv YWwgZm9yIGVhY2ggb2YgdGhlc2UgbW9kaWZpY2F0aW9ucyBpcyB0byByZWR1Y2Ugb3IgZWxpbWlu YXRlDQogICB0aGUgbmVlZCBmb3IgZnV0dXJlIHJldmlzaW9ucyBvZiB0aGlzIGRvY3VtZW50Lg0K DQogICBUaGUgc3BlY2lmaWMgY2hhbmdlcyBpbiB0aGlzIGRvY3VtZW50IHRvIG1lZXQgdGhlc2Ug Z29hbHMgYXJlOg0KDQogICBvICBEZWZpbmVzIHRoZSBBQk5GIGFuZCBydWxlcyBmb3Igc3VidGFn cyBzbyB0aGF0IHRoZSBjYXRlZ29yeSBvZiBhbGwNCiAgICAgIHN1YnRhZ3MgY2FuIGJlIGRldGVy bWluZWQgd2l0aG91dCByZWZlcmVuY2UgdG8gdGhlIHJlZ2lzdHJ5Lg0KDQogICBvICBBZGRzIHRo ZSBjb25jZXB0IG9mIHdlbGwtZm9ybWVkIHZzLiB2YWxpZGF0aW5nIHByb2Nlc3NvcnMsDQogICAg ICBkZWZpbmluZyB0aGUgcnVsZXMgYnkgd2hpY2ggYW4gaW1wbGVtZW50YXRpb24gY2FuIGNsYWlt IHRvIGJlIG9uZQ0KICAgICAgb3IgdGhlIG90aGVyLg0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2 aXMgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDUx XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAg ICAgICAgICAgICAgSnVseSAyMDA1DQoNCg0KICAgbyAgUmVwbGFjZXMgdGhlIElBTkEgbGFuZ3Vh Z2UgdGFnIHJlZ2lzdHJ5IHdpdGggYSBsYW5ndWFnZSBzdWJ0YWcNCiAgICAgIHJlZ2lzdHJ5IHRo YXQgcHJvdmlkZXMgYSBjb21wbGV0ZSBsaXN0IG9mIHZhbGlkIHN1YnRhZ3MgaW4gdGhlDQogICAg ICBJQU5BIHJlZ2lzdHJ5LiAgVGhpcyBhbGxvd3MgZm9yIHJvYnVzdCBpbXBsZW1lbnRhdGlvbiBh bmQgZWFzZSBvZg0KICAgICAgbWFpbnRlbmFuY2UuICBUaGUgbGFuZ3VhZ2Ugc3VidGFnIHJlZ2lz dHJ5IGJlY29tZXMgdGhlIGNhbm9uaWNhbA0KICAgICAgc291cmNlIGZvciBmb3JtaW5nIGxhbmd1 YWdlIHRhZ3MuDQoNCiAgIG8gIFByb3ZpZGVzIGEgcHJvY2VzcyB0aGF0IGd1YXJhbnRlZXMgc3Rh YmlsaXR5IG9mIGxhbmd1YWdlIHRhZ3MsIGJ5DQogICAgICBoYW5kbGluZyByZXVzZSBvZiB2YWx1 ZXMgYnkgSVNPIDYzOSwgSVNPIDE1OTI0LCBhbmQgSVNPIDMxNjYgaW4NCiAgICAgIHRoZSBldmVu dCB0aGF0IHRoZXkgcmVnaXN0ZXIgYSBwcmV2aW91c2x5IHVzZWQgdmFsdWUgZm9yIGEgbmV3DQog ICAgICBwdXJwb3NlLg0KDQogICBvICBBbGxvd3MgSVNPIDE1OTI0IHNjcmlwdCBjb2RlIHN1YnRh Z3MgYW5kIGFsbG93cyB0aGVtIHRvIGJlIHVzZWQNCiAgICAgIGdlbmVyYXRpdmVseS4gIERlZmlu ZXMgYSBtZXRob2QgZm9yIGluZGljYXRpbmcgaW4gdGhlIHJlZ2lzdHJ5DQogICAgICB3aGVuIHNj cmlwdCBzdWJ0YWdzIGFyZSBuZWNlc3NhcnkgZm9yIGEgZ2l2ZW4gbGFuZ3VhZ2UgdGFnLg0KDQog ICBvICBBZGRzIHRoZSBjb25jZXB0IG9mIGEgdmFyaWFudCBzdWJ0YWcgYW5kIGFsbG93cyB2YXJp YW50cyB0byBiZQ0KICAgICAgdXNlZCBnZW5lcmF0aXZlbHkuDQoNCiAgIG8gIEFkZHMgdGhlIGFi aWxpdHkgdG8gdXNlIGEgY2xhc3Mgb2YgVU4gTS40OSB0YWdzIGZvciAgc3VwcmEtDQogICAgICBu YXRpb25hbCByZWdpb25zIGFuZCB0byByZXNvbHZlIGNvbmZsaWN0cyBpbiB0aGUgYXNzaWdubWVu dCBvZiBJU08NCiAgICAgIDMxNjYgY29kZXMuDQoNCiAgIG8gIERlZmluZXMgdGhlIHByaXZhdGUg dXNlIHRhZ3MgaW4gSVNPIDYzOSwgSVNPIDE1OTI0LCBhbmQgSVNPIDMxNjYNCiAgICAgIGFzIHRo ZSBtZWNoYW5pc20gZm9yIGNyZWF0aW5nIHByaXZhdGUgdXNlIGxhbmd1YWdlLCBzY3JpcHQsIGFu ZA0KICAgICAgcmVnaW9uIHN1YnRhZ3MgcmVzcGVjdGl2ZWx5Lg0KDQogICBvICBBZGRzIGEgd2Vs bC1kZWZpbmVkIGV4dGVuc2lvbiBtZWNoYW5pc20uDQoNCiAgIG8gIERlZmluZXMgYW4gZXh0ZW5k ZWQgbGFuZ3VhZ2Ugc3VidGFnLCBwb3NzaWJseSBmb3IgdXNlIHdpdGggY2VydGFpbg0KICAgICAg YW50aWNpcGF0ZWQgZmVhdHVyZXMgb2YgSVNPIDYzOS0zLg0KDQogICBFZCBOb3RlOiBUaGUgZm9s bG93aW5nIGl0ZW1zIGFyZSBwcm92aWRlZCBmb3IgdGhlIGNvbnZlbmllbmNlIG9mDQogICByZXZp ZXdlcnMgYW5kIHdpbGwgYmUgcmVtb3ZlZCBmcm9tIHRoZSBmaW5hbCBkb2N1bWVudC4NCg0KICAg Q2hhbmdlcyBiZXR3ZWVuIGRyYWZ0LWlldGYtbHRydS1yZWdpc3RyeS0wOCBhbmQgdGhpcyB2ZXJz aW9uIGFyZToNCg0KICAgbyAgQWRkZWQgYSByZWZlcmVuY2UgVVJJIHRvIHRoZSBlZGl0b3IncyBh ZGRyZXNzLiAgKEYuRWxsZXJtYW5uKQ0KDQogICBvICBWYXJpb3VzIG5pdCBmaXhpbmdzLg0KDQog ICBvICBGaXhlZCBydWxlICMxMSBpbiBTZWN0aW9uIDMuMyB0byBhbGxvdyBVTiBNLjQ5IGNvZGVz IHRvIGJlDQogICAgICByZWdpc3RlcmVkIGluIGV4dHJlbWUgc2l0dWF0aW9ucyAoIzEwMjYpIChG LkVsbGVybWFubiwgUi5QcmVzdWhuLA0KICAgICAgZXRjLikNCg0KICAgbyAgQWRkZWQgbW9yZSBj YXV0aW9uYXJ5IHRleHQgYWJvdXQgcHJpdmF0ZSB1c2Ugc3VidGFncyB0bw0KICAgICAgU2VjdGlv biA0LjUuICgjMTA2MSkgKEQuUGllcmNlKQ0KDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAg ICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDUyXQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdzLXJlZ2lzdHJ5ICAgICAgICAgICAg ICAgICAgSnVseSAyMDA1DQoNCg0KICAgbyAgUmVndWxhcml6ZWQgInByaXZhdGUtdXNlIiB0byBh bHdheXMgdXNlIHRoZSBmb3JtICJwcml2YXRlIHVzZSIuDQogICAgICAoQS5QaGlsbGlwcykNCg0K ICAgbyAgQWRkaXRpb25hbCB3b3Jkc21pdGhpbmcgb24gcnVsZSAjMTEgaW4gU2VjdGlvbiAzLjMu ICAoRi5FbGxlcm1hbm4pDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhp bGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAgICAgICAg ICAgW1BhZ2UgNTNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVn aXN0cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQo5LiAgUmVmZXJlbmNlcw0KDQo5 LjEgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtJU082MzktMV0NCiAgICAgICAgICAgICAg SW50ZXJuYXRpb25hbCBPcmdhbml6YXRpb24gZm9yIFN0YW5kYXJkaXphdGlvbiwgIklTTyA2Mzkt DQogICAgICAgICAgICAgIDE6MjAwMiwgQ29kZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBu YW1lcyBvZiBsYW5ndWFnZXMNCiAgICAgICAgICAgICAgLS0gUGFydCAxOiBBbHBoYS0yIGNvZGUi LCBJU08gU3RhbmRhcmQgNjM5LCAyMDAyLCA8SVNPDQogICAgICAgICAgICAgIDYzOS0xPi4NCg0K ICAgW0lTTzYzOS0yXQ0KICAgICAgICAgICAgICBJbnRlcm5hdGlvbmFsIE9yZ2FuaXphdGlvbiBm b3IgU3RhbmRhcmRpemF0aW9uLCAiSVNPIDYzOS0NCiAgICAgICAgICAgICAgMjoxOTk4IC0gQ29k ZXMgZm9yIHRoZSByZXByZXNlbnRhdGlvbiBvZiBuYW1lcyBvZg0KICAgICAgICAgICAgICBsYW5n dWFnZXMgLS0gUGFydCAyOiBBbHBoYS0zIGNvZGUgLSBlZGl0aW9uIDEiLA0KICAgICAgICAgICAg ICBBdWd1c3QgMTk4OCwgPElTTyA2MzktMj4uDQoNCiAgIFtJU08xNTkyNF0NCiAgICAgICAgICAg ICAgSVNPIFRDNDYvV0czLCAiSVNPIDE1OTI0OjIwMDMgKEUvRikgLSBDb2RlcyBmb3IgdGhlDQog ICAgICAgICAgICAgIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIHNjcmlwdHMiLCBKYW51YXJ5 IDIwMDQsIDxJU08NCiAgICAgICAgICAgICAgMTU5MjQ+Lg0KDQogICBbSVNPMzE2Nl0gIEludGVy bmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJDb2RlcyBmb3INCiAg ICAgICAgICAgICAgdGhlIHJlcHJlc2VudGF0aW9uIG9mIG5hbWVzIG9mIGNvdW50cmllcywgM3Jk IGVkaXRpb24iLA0KICAgICAgICAgICAgICBJU08gU3RhbmRhcmQgMzE2NiwgQXVndXN0IDE5ODgs IDxJU08gMzE2Nj4uDQoNCiAgIFtVTl9NLjQ5XSAgU3RhdGlzdGljYWwgRGl2aXNpb24sIFVuaXRl ZCBOYXRpb25zLCAiU3RhbmRhcmQgQ291bnRyeSBvcg0KICAgICAgICAgICAgICBBcmVhIENvZGVz IGZvciBTdGF0aXN0aWNhbCBVc2UiLCBVTiBTdGFuZGFyZCBDb3VudHJ5IG9yDQogICAgICAgICAg ICAgIEFyZWEgQ29kZXMgZm9yIFN0YXRpc3RpY2FsIFVzZSwgUmV2aXNpb24gNCAoVW5pdGVkIE5h dGlvbnMNCiAgICAgICAgICAgICAgcHVibGljYXRpb24sIFNhbGVzIE5vLiA5OC5YVklJLjksIEp1 bmUgMTk5OSwgPFVOIE0uNDk+Lg0KDQogICBbSVNPMTA2NDZdDQogICAgICAgICAgICAgIEludGVy bmF0aW9uYWwgT3JnYW5pemF0aW9uIGZvciBTdGFuZGFyZGl6YXRpb24sICJJU08vSUVDDQogICAg ICAgICAgICAgIDEwNjQ2LTE6MjAwMC4gSW5mb3JtYXRpb24gdGVjaG5vbG9neSAtLSBVbml2ZXJz YWwNCiAgICAgICAgICAgICAgTXVsdGlwbGUtT2N0ZXQgQ29kZWQgQ2hhcmFjdGVyIFNldCAoVUNT KSAtLSBQYXJ0IDE6DQogICAgICAgICAgICAgIEFyY2hpdGVjdHVyZSBhbmQgQmFzaWMgTXVsdGls aW5ndWFsIFBsYW5lIGFuZCBJU08vSUVDDQogICAgICAgICAgICAgIDEwNjQ2LTI6MjAwMS4gSW5m b3JtYXRpb24gdGVjaG5vbG9neSAtLSBVbml2ZXJzYWwNCiAgICAgICAgICAgICAgTXVsdGlwbGUt T2N0ZXQgQ29kZWQgQ2hhcmFjdGVyIFNldCAoVUNTKSAtLSBQYXJ0IDI6DQogICAgICAgICAgICAg IFN1cHBsZW1lbnRhcnkgUGxhbmVzLCBhcywgZnJvbSB0aW1lIHRvIHRpbWUsIGFtZW5kZWQsDQog ICAgICAgICAgICAgIHJlcGxhY2VkIGJ5IGEgbmV3IGVkaXRpb24gb3IgZXhwYW5kZWQgYnkgdGhl IGFkZGl0aW9uIG9mDQogICAgICAgICAgICAgIG5ldyBwYXJ0cyIsIDIwMDAsIDxJU08vSUVDIDEw NjQ2Pi4NCg0KICAgW1JGQzIyMzRiaXNdDQogICAgICAgICAgICAgIENyb2NrZXIsIEQuIGFuZCBQ LiBPdmVyZWxsLCAiQXVnbWVudGVkIEJORiBmb3IgU3ludGF4DQogICAgICAgICAgICAgIFNwZWNp ZmljYXRpb25zOiBBQk5GIiwgZHJhZnQtY3JvY2tlci1hYm5mLXJmYzIyMzRiaXMtMDANCiAgICAg ICAgICAgICAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXJjaCAyMDA1Lg0KDQogICBbUkZDMjAyNl0g IEJyYWRuZXIsIFMuLCAiVGhlIEludGVybmV0IFN0YW5kYXJkcyBQcm9jZXNzIC0tIFJldmlzaW9u DQogICAgICAgICAgICAgIDMiLCBCQ1AgOSwgUkZDIDIwMjYsIE9jdG9iZXIgMTk5Ni4NCg0KDQoN ClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNiAgICAgICAg ICAgICAgIFtQYWdlIDU0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgIGxhbmd0YWdz LXJlZ2lzdHJ5ICAgICAgICAgICAgICAgICAgSnVseSAyMDA1DQoNCg0KICAgW1JGQzIwMjhdICBI b3ZleSwgUi4gYW5kIFMuIEJyYWRuZXIsICJUaGUgT3JnYW5pemF0aW9ucyBJbnZvbHZlZCBpbg0K ICAgICAgICAgICAgICB0aGUgSUVURiBTdGFuZGFyZHMgUHJvY2VzcyIsIEJDUCAxMSwgUkZDIDIw MjgsDQogICAgICAgICAgICAgIE9jdG9iZXIgMTk5Ni4NCg0KICAgW1JGQzIwNDddICBNb29yZSwg Sy4sICJNSU1FIChNdWx0aXB1cnBvc2UgSW50ZXJuZXQgTWFpbCBFeHRlbnNpb25zKQ0KICAgICAg ICAgICAgICBQYXJ0IFRocmVlOiBNZXNzYWdlIEhlYWRlciBFeHRlbnNpb25zIGZvciBOb24tQVND SUkgVGV4dCIsDQogICAgICAgICAgICAgIFJGQyAyMDQ3LCBOb3ZlbWJlciAxOTk2Lg0KDQogICBb UkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRp Y2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5 LCBNYXJjaCAxOTk3Lg0KDQogICBbUkZDMjQzNF0gIE5hcnRlbiwgVC4gYW5kIEguIEFsdmVzdHJh bmQsICJHdWlkZWxpbmVzIGZvciBXcml0aW5nIGFuDQogICAgICAgICAgICAgIElBTkEgQ29uc2lk ZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzIiwgQkNQIDI2LCBSRkMgMjQzNCwNCiAgICAgICAgICAg ICAgT2N0b2JlciAxOTk4Lg0KDQogICBbUkZDMjc4MV0gIEhvZmZtYW4sIFAuIGFuZCBGLiBZZXJn ZWF1LCAiVVRGLTE2LCBhbiBlbmNvZGluZyBvZiBJU08NCiAgICAgICAgICAgICAgMTA2NDYiLCBS RkMgMjc4MSwgRmVicnVhcnkgMjAwMC4NCg0KICAgW1JGQzI4NjBdICBDYXJwZW50ZXIsIEIuLCBC YWtlciwgRi4sIGFuZCBNLiBSb2JlcnRzLCAiTWVtb3JhbmR1bSBvZg0KICAgICAgICAgICAgICBV bmRlcnN0YW5kaW5nIENvbmNlcm5pbmcgdGhlIFRlY2huaWNhbCBXb3JrIG9mIHRoZQ0KICAgICAg ICAgICAgICBJbnRlcm5ldCBBc3NpZ25lZCBOdW1iZXJzIEF1dGhvcml0eSIsIFJGQyAyODYwLCBK dW5lIDIwMDAuDQoNCiAgIFtSRkMzMzM5XSAgS2x5bmUsIEcuIGFuZCBDLiBOZXdtYW4sICJEYXRl IGFuZCBUaW1lIG9uIHRoZSBJbnRlcm5ldDoNCiAgICAgICAgICAgICAgVGltZXN0YW1wcyIsIFJG QyAzMzM5LCBKdWx5IDIwMDIuDQoNCiAgIFtSRkMzNTUyXSAgUmVzY29ybGEsIEUuIGFuZCBCLiBL b3J2ZXIsICJHdWlkZWxpbmVzIGZvciBXcml0aW5nIFJGQw0KICAgICAgICAgICAgICBUZXh0IG9u IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIiwgQkNQIDcyLCBSRkMgMzU1MiwNCiAgICAgICAgICAg ICAgSnVseSAyMDAzLg0KDQo5LjIgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW2luaXRp YWwtcmVnaXN0cnldDQogICAgICAgICAgICAgIEV3ZWxsLCBELiwgRWQuLCAiSW5pdGlhbCBMYW5n dWFnZSBTdWJ0YWcgUmVnaXN0cnkiLA0KICAgICAgICAgICAgICBKdW5lIDIwMDUsIDxodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1s dHJ1LWluaXRpYWwtcmVnaXN0cnktMDAudHh0Pi4NCg0KICAgW2lzbzYzOS5wcmluY2lwbGVzXQ0K ICAgICAgICAgICAgICBJU08gNjM5IEpvaW50IEFkdmlzb3J5IENvbW1pdHRlZSwgIklTTyA2Mzkg Sm9pbnQgQWR2aXNvcnkNCiAgICAgICAgICAgICAgQ29tbWl0dGVlOiAgV29ya2luZyBwcmluY2lw bGVzIGZvciBJU08gNjM5IG1haW50ZW5hbmNlIiwNCiAgICAgICAgICAgICAgTWFyY2ggMjAwMCwN CiAgICAgICAgICAgICAgPGh0dHA6Ly93d3cubG9jLmdvdi9zdGFuZGFyZHMvaXNvNjM5LTIvDQog ICAgICAgICAgICAgIGlzbzYzOWphY19uM3IuaHRtbD4uDQoNCiAgIFtyZWNvcmQtamFyXQ0KICAg ICAgICAgICAgICBSYXltb25kLCBFLiwgIlRoZSBBcnQgb2YgVW5peCBQcm9ncmFtbWluZyIsIDIw MDMuDQoNCiAgIFtYTUwxMF0gICAgQnJheSAoZXQgYWwpLCBULiwgIkV4dGVuc2libGUgTWFya3Vw IExhbmd1YWdlIChYTUwpIDEuMCIsDQogICAgICAgICAgICAgIDAyIDIwMDQuDQoNCg0KDQpQaGls bGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAgICAg ICBbUGFnZSA1NV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdp c3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNCiAgIFtYTUxTY2hlbWFdDQogICAg ICAgICAgICAgIEJpcm9uLCBQLiwgRWQuIGFuZCBBLiBNYWxob3RyYSwgRWQuLCAiWE1MIFNjaGVt YSBQYXJ0IDI6DQogICAgICAgICAgICAgIERhdGF0eXBlcyBTZWNvbmQgRWRpdGlvbiIsIDEwIDIw MDQsIDwNCiAgICAgICAgICAgICAgaHR0cDovL3d3dy53My5vcmcvVFIveG1sc2NoZW1hLTIvPi4N Cg0KICAgW1VuaWNvZGVdICBVbmljb2RlIENvbnNvcnRpdW0sICJUaGUgVW5pY29kZSBDb25zb3J0 aXVtLiBUaGUgVW5pY29kZQ0KICAgICAgICAgICAgICBTdGFuZGFyZCwgVmVyc2lvbiA0LjEuMCwg ZGVmaW5lZCBieTogVGhlIFVuaWNvZGUgU3RhbmRhcmQsDQogICAgICAgICAgICAgIFZlcnNpb24g NC4wIChCb3N0b24sIE1BLCBBZGRpc29uLVdlc2xleSwgMjAwMy4gSVNCTiAwLTMyMS0NCiAgICAg ICAgICAgICAgMTg1NzgtMSksIGFzIGFtZW5kZWQgYnkgVW5pY29kZSA0LjAuMQ0KICAgICAgICAg ICAgICAoaHR0cDovL3d3dy51bmljb2RlLm9yZy92ZXJzaW9ucy9Vbmljb2RlNC4wLjEpIGFuZCBi eQ0KICAgICAgICAgICAgICBVbmljb2RlIDQuMS4wDQogICAgICAgICAgICAgIChodHRwOi8vd3d3 LnVuaWNvZGUub3JnL3ZlcnNpb25zL1VuaWNvZGU0LjEuMCkuIiwNCiAgICAgICAgICAgICAgTWFy Y2ggMjAwNS4NCg0KICAgW1JGQzE3NjZdICBBbHZlc3RyYW5kLCBILiwgIlRhZ3MgZm9yIHRoZSBJ ZGVudGlmaWNhdGlvbiBvZg0KICAgICAgICAgICAgICBMYW5ndWFnZXMiLCBSRkMgMTc2NiwgTWFy Y2ggMTk5NS4NCg0KICAgW1JGQzIyMzFdICBGcmVlZCwgTi4gYW5kIEsuIE1vb3JlLCAiTUlNRSBQ YXJhbWV0ZXIgVmFsdWUgYW5kIEVuY29kZWQNCiAgICAgICAgICAgICAgV29yZCBFeHRlbnNpb25z OiBDaGFyYWN0ZXIgU2V0cywgTGFuZ3VhZ2VzLCBhbmQNCiAgICAgICAgICAgICAgQ29udGludWF0 aW9ucyIsIFJGQyAyMjMxLCBOb3ZlbWJlciAxOTk3Lg0KDQogICBbUkZDMzA2Nl0gIEFsdmVzdHJh bmQsIEguLCAiVGFncyBmb3IgdGhlIElkZW50aWZpY2F0aW9uIG9mDQogICAgICAgICAgICAgIExh bmd1YWdlcyIsIEJDUCA0NywgUkZDIDMwNjYsIEphbnVhcnkgMjAwMS4NCg0KDQpBdXRob3JzJyBB ZGRyZXNzZXMNCg0KICAgQWRkaXNvbiBQaGlsbGlwcyAoZWRpdG9yKQ0KICAgUXVlc3QgU29mdHdh cmUNCg0KICAgRW1haWw6IGFkZGlzb24ucGhpbGxpcHNAcXVlc3QuY29tDQogICBVUkk6ICAgaHR0 cDovL3d3dy5pbnRlci1sb2NhbGUuY29tDQoNCg0KICAgTWFyayBEYXZpcyAoZWRpdG9yKQ0KICAg SUJNDQoNCiAgIEVtYWlsOiBtYXJrLmRhdmlzQHVzLmlibS5jb20NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KUGhpbGxpcHMgJiBEYXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2 ICAgICAgICAgICAgICAgW1BhZ2UgNTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg bGFuZ3RhZ3MtcmVnaXN0cnkgICAgICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQpBcHBlbmRp eCBBLiAgQWNrbm93bGVkZ2VtZW50cw0KDQogICBBbnkgbGlzdCBvZiBjb250cmlidXRvcnMgaXMg Ym91bmQgdG8gYmUgaW5jb21wbGV0ZTsgcGxlYXNlIHJlZ2FyZCB0aGUNCiAgIGZvbGxvd2luZyBh cyBvbmx5IGEgc2VsZWN0aW9uIGZyb20gdGhlIGdyb3VwIG9mIHBlb3BsZSB3aG8gaGF2ZQ0KICAg Y29udHJpYnV0ZWQgdG8gbWFrZSB0aGlzIGRvY3VtZW50IHdoYXQgaXQgaXMgdG9kYXkuDQoNCiAg IFRoZSBjb250cmlidXRvcnMgdG8gUkZDIDMwNjYgYW5kIFJGQyAxNzY2LCB0aGUgcHJlY3Vyc29y cyBvZiB0aGlzDQogICBkb2N1bWVudCwgbWFkZSBlbm9ybW91cyBjb250cmlidXRpb25zIGRpcmVj dGx5IG9yIGluZGlyZWN0bHkgdG8gdGhpcw0KICAgZG9jdW1lbnQgYW5kIGFyZSBnZW5lcmFsbHkg cmVzcG9uc2libGUgZm9yIHRoZSBzdWNjZXNzIG9mIGxhbmd1YWdlDQogICB0YWdzLg0KDQogICBU aGUgZm9sbG93aW5nIHBlb3BsZSAoaW4gYWxwaGFiZXRpY2FsIG9yZGVyKSBjb250cmlidXRlZCB0 byB0aGlzDQogICBkb2N1bWVudCBvciB0byBSRkNzIDE3NjYgYW5kIDMwNjY6DQoNCiAgIEdsZW5u IEFkYW1zLCBIYXJhbGQgVHZlaXQgQWx2ZXN0cmFuZCwgVGltIEJlcm5lcnMtTGVlLCBNYXJjIEJs YW5jaGV0LA0KICAgTmF0aGFuaWVsIEJvcmVuc3RlaW4sIEthcmVuIEJyb29tZSwgRXJpYyBCcnVu bmVyLCBTZWFuIE0uIEJ1cmtlLCBNLlQuDQogICBDYXJyYXNjbyBCZW5pdGV6LCBKZXJlbXkgQ2Fy cm9sbCwgSm9obiBDbGV3cywgSmltIENvbmtsaW4sIFBldGVyDQogICBDb25zdGFibGUsIEpvaG4g Q293YW4sIE1hcmsgQ3Jpc3BpbiwgRGF2ZSBDcm9ja2VyLCBNYXJ0aW4gRHVlcnN0LA0KICAgRnJh bmsgRWxsZXJtYW4sIE1pY2hhZWwgRXZlcnNvbiwgRG91ZyBFd2VsbCwgTmVkIEZyZWVkLCBUaW0g R29vZHdpbiwNCiAgIERpcmstV2lsbGVtIHZhbiBHdWxpaywgTWFyaW9uIEd1bm4sIEpvZWwgSGFs cHJlbiwgRWxsaW90dGUgUnVzdHkNCiAgIEhhcm9sZCwgUGF1bCBIb2ZmbWFuLCBTY290dCBIb2xs ZW5iZWNrLCBSaWNoYXJkIElzaGlkYSwgT2xsZQ0KICAgSmFybmVmb3JzLCBLZW50IEthcmxzc29u LCBKb2huIEtsZW5zaW4sIEFsYWluIExhQm9udGUsIEVyaWMgTWFkZXIsDQogICBJcmEgTWNEb25h bGQsIEtlaXRoIE1vb3JlLCBDaHJpcyBOZXdtYW4sIE1hc2F0YWthIE9odGEsIER5bGFuIFBpZXJj ZSwNCiAgIFJhbmR5IFByZXN1aG4sIEdlb3JnZSBSaG90ZW4sIE1hcmt1cyBTY2hlcmVyLCBLZWxk IEpvcm4gU2ltb25zZW4sDQogICBUaGllcnJ5IFNvdXJiaWVyLCBPdHRvIFN0b2x6LCBUZXggVGV4 aW4sIEFuZHJlYSBWaW5lLCBSaHlzDQogICBXZWF0aGVybGV5LCBNaXNoYSBXb2xmLCBGcmFuY29p cyBZZXJnZWF1IGFuZCBtYW55LCBtYW55IG90aGVycy4NCg0KICAgVmVyeSBzcGVjaWFsIHRoYW5r cyBtdXN0IGdvIHRvIEhhcmFsZCBUdmVpdCBBbHZlc3RyYW5kLCB3aG8NCiAgIG9yaWdpbmF0ZWQg UkZDcyAxNzY2IGFuZCAzMDY2LCBhbmQgd2l0aG91dCB3aG9tIHRoaXMgZG9jdW1lbnQgd291bGQN CiAgIG5vdCBoYXZlIGJlZW4gcG9zc2libGUuICBTcGVjaWFsIHRoYW5rcyBtdXN0IGdvIHRvIE1p Y2hhZWwgRXZlcnNvbiwNCiAgIHdobyBoYXMgc2VydmVkIGFzIGxhbmd1YWdlIHRhZyByZXZpZXdl ciBmb3IgYWxtb3N0IHRoZSBjb21wbGV0ZQ0KICAgcGVyaW9kIHNpbmNlIHRoZSBwdWJsaWNhdGlv biBvZiBSRkMgMTc2Ni4gIFNwZWNpYWwgdGhhbmtzIHRvIERvdWcNCiAgIEV3ZWxsLCBmb3IgaGlz IHByb2R1Y3Rpb24gb2YgdGhlIGZpcnN0IGNvbXBsZXRlIHN1YnRhZyByZWdpc3RyeSwgYW5kDQog ICBoaXMgd29yayBpbiBwcm9kdWNpbmcgYSB0ZXN0IHBhcnNlciBmb3IgdmVyaWZ5aW5nIGxhbmd1 YWdlIHRhZ3MuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGhpbGxpcHMgJiBE YXZpcyAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA2ICAgICAgICAgICAgICAgW1BhZ2Ug NTddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgbGFuZ3RhZ3MtcmVnaXN0cnkgICAg ICAgICAgICAgICAgICBKdWx5IDIwMDUNCg0KDQpBcHBlbmRpeCBCLiAgRXhhbXBsZXMgb2YgTGFu Z3VhZ2UgVGFncyAoSW5mb3JtYXRpdmUpDQoNCiAgIFNpbXBsZSBsYW5ndWFnZSBzdWJ0YWc6DQoN CiAgICAgIGRlIChHZXJtYW4pDQoNCiAgICAgIGZyIChGcmVuY2gpDQoNCiAgICAgIGphIChKYXBh bmVzZSkNCg0KICAgICAgaS1lbm9jaGlhbiAoZXhhbXBsZSBvZiBhIGdyYW5kZmF0aGVyZWQgdGFn KQ0KDQogICBMYW5ndWFnZSBzdWJ0YWcgcGx1cyBTY3JpcHQgc3VidGFnOg0KDQogICAgICB6aC1I YW50IChDaGluZXNlIHdyaXR0ZW4gdXNpbmcgdGhlIFRyYWRpdGlvbmFsIENoaW5lc2Ugc2NyaXB0 KQ0KDQogICAgICB6aC1IYW5zIChDaGluZXNlIHdyaXR0ZW4gdXNpbmcgdGhlIFNpbXBsaWZpZWQg Q2hpbmVzZSBzY3JpcHQpDQoNCiAgICAgIHNyLUN5cmwgKFNlcmJpYW4gd3JpdHRlbiB1c2luZyB0 aGUgIEN5cmlsbGljIHNjcmlwdCkNCg0KICAgICAgc3ItTGF0biAoU2VyYmlhbiB3cml0dGVuIHVz aW5nIHRoZSBMYXRpbiBzY3JpcHQpDQoNCiAgIExhbmd1YWdlLVNjcmlwdC1SZWdpb246DQoNCiAg ICAgIHpoLUhhbnMtQ04gKENoaW5lc2Ugd3JpdHRlbiB1c2luZyB0aGUgU2ltcGxpZmllZCBzY3Jp cHQgYXMgdXNlZCBpbg0KICAgICAgbWFpbmxhbmQgQ2hpbmEpDQoNCiAgICAgIHNyLUxhdG4tQ1Mg KFNlcmJpYW4gd3JpdHRlbiB1c2luZyB0aGUgTGF0aW4gc2NyaXB0IGFzIHVzZWQgaW4NCiAgICAg IFNlcmJpYSBhbmQgTW9udGVuZWdybykNCg0KICAgTGFuZ3VhZ2UtVmFyaWFudDoNCg0KICAgICAg c2wtcm96YWogKFJlc2lhbiBkaWFsZWN0IG9mIFNsb3Zlbmlhbg0KDQogICAgICBzbC1uZWRpcyAo TmFkaXphIGRpYWxlY3Qgb2YgU2xvdmVuaWFuKQ0KDQogICBMYW5ndWFnZS1SZWdpb24tVmFyaWFu dDoNCg0KICAgICAgZGUtQ0gtMTkwMSAoR2VybWFuIGFzIHVzZWQgaW4gU3dpdHplcmxhbmQgdXNp bmcgdGhlIDE5MDEgdmFyaWFudA0KICAgICAgW29ydGhvZ3JhcGh5XSkNCg0KICAgICAgc2wtSVQt bmVkaXMgKFNsb3ZlbmlhbiBhcyB1c2VkIGluIEl0YWx5LCBOYWRpemEgZGlhbGVjdCkNCg0KICAg TGFuZ3VhZ2UtU2NyaXB0LVJlZ2lvbi1WYXJpYW50Og0KDQoNCg0KDQoNCg0KDQpQaGlsbGlwcyAm IERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDYgICAgICAgICAgICAgICBbUGFn ZSA1OF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5ndGFncy1yZWdpc3RyeSAg ICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNCiAgICAgIHNsLUxhdG4tSVQtbmVkaXMgKE5h ZGl6YSBkaWFsZWN0IG9mIFNsb3ZlbmlhbiB3cml0dGVuIHVzaW5nIHRoZQ0KICAgICAgTGF0aW4g c2NyaXB0IGFzIHVzZWQgaW4gSXRhbHkuICBOb3RlIHRoYXQgdGhpcyB0YWcgaXMgTk9UDQogICAg ICBSRUNPTU1FTkRFRCBiZWNhdXNlIHN1YnRhZyAnc2wnIGhhcyBhIFN1cHByZXNzLVNjcmlwdCB2 YWx1ZSBvZg0KICAgICAgJ0xhdG4nKQ0KDQogICBMYW5ndWFnZS1SZWdpb246DQoNCiAgICAgIGRl LURFIChHZXJtYW4gZm9yIEdlcm1hbnkpDQoNCiAgICAgIGVuLVVTIChFbmdsaXNoIGFzIHVzZWQg aW4gdGhlIFVuaXRlZCBTdGF0ZXMpDQoNCiAgICAgIGVzLTQxOSAoU3BhbmlzaCBhcHByb3ByaWF0 ZSBmb3IgdGhlIExhdGluIEFtZXJpY2EgYW5kIENhcmliYmVhbg0KICAgICAgcmVnaW9uIHVzaW5n IHRoZSBVTiByZWdpb24gY29kZSkNCg0KICAgUHJpdmF0ZSB1c2Ugc3VidGFnczoNCg0KICAgICAg ZGUtQ0gteC1waG9uZWJrDQoNCiAgICAgIGF6LUFyYWIteC1BWkUtZGVyYmVuZA0KDQogICBFeHRl bmRlZCBsYW5ndWFnZSBzdWJ0YWdzIChleGFtcGxlcyBPTkxZOiBleHRlbmRlZCBsYW5ndWFnZXMg TVVTVCBiZQ0KICAgZGVmaW5lZCBieSByZXZpc2lvbiBvciB1cGRhdGUgdG8gdGhpcyBkb2N1bWVu dCk6DQoNCiAgICAgIHpoLW1pbg0KDQogICAgICB6aC1taW4tbmFuLUhhbnQtQ04NCg0KICAgUHJp dmF0ZSB1c2UgcmVnaXN0cnkgdmFsdWVzOg0KDQogICAgICB4LXdoYXRldmVyIChwcml2YXRlIHVz ZSB1c2luZyB0aGUgc2luZ2xldG9uICd4JykNCg0KICAgICAgcWFhLVFhYWEtUU0teC1zb3V0aGVy biAoYWxsIHByaXZhdGUgdGFncykNCg0KICAgICAgZGUtUWFhYSAoR2VybWFuLCB3aXRoIGEgcHJp dmF0ZSBzY3JpcHQpDQoNCiAgICAgIHNyLUxhdG4tUU0gKFNlcmJpYW4sIExhdGluLXNjcmlwdCwg cHJpdmF0ZSByZWdpb24pDQoNCiAgICAgIHNyLVFhYWEtQ1MgKFNlcmJpYW4sIHByaXZhdGUgc2Ny aXB0LCBmb3IgU2VyYmlhIGFuZCBNb250ZW5lZ3JvKQ0KDQogICBUYWdzIHRoYXQgdXNlIGV4dGVu c2lvbnMgKGV4YW1wbGVzIE9OTFk6IGV4dGVuc2lvbnMgTVVTVCBiZSBkZWZpbmVkDQogICBieSBy ZXZpc2lvbiBvciB1cGRhdGUgdG8gdGhpcyBkb2N1bWVudCBvciBieSBSRkMpOg0KDQogICAgICBl bi1VUy11LWlzbGFtQ2FsDQoNCiAgICAgIHpoLUNOLWEtbXlFeHQteC1wcml2YXRlDQoNCg0KDQoN Cg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDYgICAg ICAgICAgICAgICBbUGFnZSA1OV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBsYW5n dGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNCiAgICAgIGVuLWEt bXlFeHQtYi1hbm90aGVyDQoNCiAgIFNvbWUgSW52YWxpZCBUYWdzOg0KDQogICAgICBkZS00MTkt REUgKHR3byByZWdpb24gdGFncykNCg0KICAgICAgYS1ERSAodXNlIG9mIGEgc2luZ2xlIGNoYXJh Y3RlciBzdWJ0YWcgaW4gcHJpbWFyeSBwb3NpdGlvbjsgbm90ZQ0KICAgICAgdGhhdCB0aGVyZSBh cmUgYSBmZXcgZ3JhbmRmYXRoZXJlZCB0YWdzIHRoYXQgc3RhcnQgd2l0aCAiaS0iIHRoYXQNCiAg ICAgIGFyZSB2YWxpZCkNCg0KICAgICAgYXItYS1hYWEtYi1iYmItYS1jY2MgKHR3byBleHRlbnNp b25zIHdpdGggc2FtZSBzaW5nbGUgbGV0dGVyDQogICAgICBwcmVmaXgpDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpQaGlsbGlwcyAmIERhdmlzICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDYg ICAgICAgICAgICAgICBbUGFnZSA2MF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICBs YW5ndGFncy1yZWdpc3RyeSAgICAgICAgICAgICAgICAgIEp1bHkgMjAwNQ0KDQoNCkludGVsbGVj dHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24g cmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQ cm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0K ICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5 IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFu eSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZh aWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGlu ZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlv bg0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9j dW1lbnRzIGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGll cyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55 DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUg cmVzdWx0IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNl IG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRz IGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbiBi ZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVz dGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBw YXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICBy aWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBp bXBsZW1lbnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRp b24gdG8gdGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0KDQoNCkRpc2NsYWltZXIg b2YgVmFsaWRpdHkNCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUg Q09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElT IFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRF Uk5FVA0KICAgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywg RVhQUkVTUyBPUiBJTVBMSUVELA0KICAgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkg V0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRQ0KICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwg Tk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNCiAgIFdBUlJBTlRJRVMgT0Yg TUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQoN CkNvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29j aWV0eSAoMjAwNSkuICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QNCiAgIHRvIHRoZSByaWdodHMs IGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kDQogICBl eGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIg cmlnaHRzLg0KDQoNCkFja25vd2xlZGdtZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRp dG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUNCiAgIEludGVybmV0IFNv Y2lldHkuDQoNCg0KDQoNClBoaWxsaXBzICYgRGF2aXMgICAgICAgIEV4cGlyZXMgSmFudWFyeSAx MiwgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDYxXQ0KDA0K ------_=_NextPart_001_01C58641.B135400C 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_01C58641.B135400C-- From ltru-bounces@lists.ietf.org Mon Jul 11 14:57:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3TO-0000uq-Dh; Mon, 11 Jul 2005 14:57:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3TM-0000qq-Cz for ltru@megatron.ietf.org; Mon, 11 Jul 2005 14:57:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10926 for ; Mon, 11 Jul 2005 14:57:42 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds3vO-0004bL-Tr for ltru@ietf.org; Mon, 11 Jul 2005 15:26:44 -0400 Received: from h-68-166-37-248.snvacaid.dynamic.covad.net ([68.166.37.248] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Ds3TF-0007Wv-00 for ltru@ietf.org; Mon, 11 Jul 2005 14:57:37 -0400 Message-ID: <001201c5864a$ffeab180$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C108BE8@irvmbxw01.quest.com><000601c58584$90ca9520$030aa8c0@DEWELL> <6.0.0.20.2.20050711101532.06f9ab50@itmail.it.aoyama.ac.jp> Date: Mon, 11 Jul 2005 12: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: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Ltru] issue #878 resolution (was: editorial nits in initial 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 Hi - > From: "Martin Duerst" > To: "Doug Ewell" ; "LTRU Working Group" > Sent: Sunday, July 10, 2005 6:17 PM > Subject: Re: [Ltru] Re: editorial nits in initial registry draft -01 > > Are we actually going to publish the -initial draft as an RFC? > I seem to remember that at one point, the idea was to not do > that, because by the time the RFC would be published, it would > already be out of date. In that scenario, we planned to move > -initial through (WG and IETF) last call and IESG approval, > but then go directly to IANA and no further in the RFC process. > If I'm out of sync here, I'm sorry. ... Well, that was quite some time ago. :-) :-) Way back on May 28, Scott Hollenbeck, our AD, responded (of-list) to the co-chairs: | The last option (information RFC) is the one most commonly used. It can | contain both the initial contents and text to let people know that they | should refer to the registry at a specific location for the most current | values. This would be my preference. On May 31, I posted to the WG mailing list the resolution of issue #878: | The WG discussion of this issue was inconclusive, so the co-chairs consulted | with our responsible AD to determine what in his opinion would work best | logistically with IANA and the IESG to deliver the initial registry contents. | The conclusion: the registry contents should indeed be put into an internet-draft, | for publication as an *informational* RFC. It would contain both the initial registry | contents and text to let people know that they should refer to the registry at a | specific location for the most current values. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 11 15:10:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3g7-0004K5-61; Mon, 11 Jul 2005 15: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 1Ds3g5-0004K0-8I for ltru@megatron.ietf.org; Mon, 11 Jul 2005 15:10:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12386 for ; Mon, 11 Jul 2005 15:10:49 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds486-00054c-Rz for ltru@ietf.org; Mon, 11 Jul 2005 15:39:51 -0400 Received: from h-68-166-37-248.snvacaid.dynamic.covad.net ([68.166.37.248] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Ds3g1-00042E-00 for ltru@ietf.org; Mon, 11 Jul 2005 15:10:49 -0400 Message-ID: <003901c5864c$d936a240$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <003c01c585ec$1c1d8580$030aa8c0@DEWELL> <42D23B74.4233@xyzzy.claranet.de> Date: Mon, 11 Jul 2005 12:15:06 -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: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Subject: [Ltru] Frank's editorial comments on initial registry (Re: Submission: LTRU initial-registry draft-02) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - Are there any objections to accepting Frank's editorial comments on the initial registry draft -02? None of these would require extending the last call. Randy, ltru co-chair > From: "Frank Ellermann" > To: > Sent: Monday, July 11, 2005 2:27 AM > Subject: [Ltru] Re: Submission: LTRU initial-registry draft-02 > > Doug Ewell wrote: > > > "draft-ietf-ltru-initial-02", in text format. > > | 3. UN numeric code elements assigned to "macro-geographical > | (continental)" as of the date of adoption of > [...] > > Just to prove that I've read it, maybe s/as of/regions as of/ > > In point six you say "These code elements are listed in Section > 4, indicating that they are valid for registration" etc. This > part belongs to your point five. > > Section 4 does not contain any "withdrawn, vacated, deprecated, > or otherwise judged by the LTRU working group as questionable" > items. Actually there were no items "judged as questionable" - > you just followed the rules skipping all deprecated items. New > wording: > > 5. The UN numeric code elements for countries or areas not > associated with an assigned [ISO3166-1] alpha-2 code > element were not added to the ILSR. These values > + are listed in Section 4 and > may be requested for registration by individuals using the > process defined in [I-D.ietf-ltru-registry] and according > to the rules described therein. > + Listing of these code elements in this section is not a > + guarantee of future registration. > > > 6. Items withdrawn, vacated, deprecated, > + or modified > - modified, or otherwise judged by the LTRU working group > - to be questionable > were not added to the ILSR. > - These code elements are listed in Section 4, indicating > - that they are valid for registration using the process in > - [I-D.ietf-ltru-registry] but were not included initially. > - Listing of these code elements in this section is not a > - guarantee of future registration. > > Otherwise that I-D should be ready - I didn't check all tags > again assuming that you'd tell us if you did something more > interesting than replacing some dates by 2005-07-10. > > All references are in fact referenced. No copyright > problems, "not a mirror" is nice . No 2119 keywords. > Longest line length 72. Exactly two folded lines, both okay: > > Description: Interlingua (International Auxiliary Language > Association) > Description: Minnan, Hokkien, Amoy, Taiwanese, Southern Min, Southern > Fujian, Hoklo, Southern Fukien, Ho-lo > > No problems found, and now I don't want to hear 830, 831, 832, > or 833 again for the rest of this year (sorry GG, IM, JE, we > really did our best, please talk with your Duke). 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 Jul 11 15:19:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3og-0006mo-Tq; Mon, 11 Jul 2005 15:19:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds3of-0006mj-Li for ltru@megatron.ietf.org; Mon, 11 Jul 2005 15:19:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13497 for ; Mon, 11 Jul 2005 15:19:43 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds4Gf-0005N5-PW for ltru@ietf.org; Mon, 11 Jul 2005 15:48:45 -0400 Received: from h-68-166-37-248.snvacaid.dynamic.covad.net ([68.166.37.248] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Ds3oa-0006Yr-00 for ltru@ietf.org; Mon, 11 Jul 2005 15:19:40 -0400 Message-ID: <004e01c5864e$15878060$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <4A7C6FA2AB31194E80E13FE585F6A2121A59CD@EVS-EC1-NODE1.surrey.ac.uk> Date: Mon, 11 Jul 2005 12:23: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.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Subject: [Ltru] issue #1061 discussion continued (Was: Private Use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - While these are interesting observations, I must ask that you be clear whether you're voicing an objection to any text present in the i-d, or requesting that any any specific text be added to address your concerns. We're in working group last call on the registry-related drafts, so I'd like to focus on any specific changes necessary to reflect WG consensus, rather than open-ended discussion. If you have specific text to suggest, particularly if it will help avoid confusion, please post it. Randy, ltru co-chair ----- Original Message ----- From: "L.Gillam" To: "petercon" ; "ltru" Sent: Monday, July 11, 2005 2:42 AM Subject: RE: [Ltru] Private Use Tags Peter, In the neutral corner, if there is such a thing, the distinction may not be so clear for people whose reasoning goes that both use language codes and country codes, and excluding differences in separator use they look identical. As you identify, it is the intention of the combination that differs. Some, who might process such metadata items into their components may wonder how there can be a difference between "en" in one context and "en" in another context. And this is something that a certain section, I can't recall which, in WD 639-4, doesn't cover - it just shows that various combinations are valid. Something to be looked at in August no doubt. In addition, I may have interpreted something from another contributor to this list that may appear obvious to those involved, but may be less than crystal clear to some new users - that currently the "registry" uses codes for the representation of the "names" of languages, combines them with codes for the "names" of countries, and creates a new semantic around these such that the names can now used as identifiers for (some fragment of) linguistic content. Nothing unusual in human activity, but these differences in expectation for some as alluded to in the previous paragraph, may be the cause of some misunderstandings as seen on this list. I don't claim to know what Sun do, but they may be combining a currency value with a locale to identify "common" items that can be associated to some locales but not generally others. It's a guess, but again you'd need to know what their intention was in making such combinations. Such discussions, perhaps, help to draw these "shared" understandings out into the open. Pointers to prior discussions of this nature may also be of some use. ________________________________ ... _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 11 17:15:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5cR-00020K-UW; Mon, 11 Jul 2005 17: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 1Ds5cQ-000208-5w for ltru@megatron.ietf.org; Mon, 11 Jul 2005 17:15:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17017 for ; Mon, 11 Jul 2005 17:15:09 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-red.bigfish.com ([216.148.222.61] helo=mail82-red-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds64Q-0001Qa-Cd for ltru@ietf.org; Mon, 11 Jul 2005 17:44:12 -0400 Received: from mail82-red.bigfish.com (localhost.localdomain [127.0.0.1]) by mail82-red-R.bigfish.com (Postfix) with ESMTP id EE8FF324FD2 for ; Mon, 11 Jul 2005 21:14:50 +0000 (UTC) X-BigFish: VP Received: by mail82-red.bigfish.com (MessageSwitch) id 1121116490917067_19313; Mon, 11 Jul 2005 21:14:50 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail82-red.bigfish.com (Postfix) with ESMTP id D89B4324994 for ; Mon, 11 Jul 2005 21:14:50 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005071114222829:41605 ; Mon, 11 Jul 2005 14:22:28 -0700 To: ltru@ietf.org Subject: [ltru] Initial language registry draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Mon, 11 Jul 2005 14:11:53 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/11/2005 14:11:54, Serialize complete at 07/11/2005 14:11:54, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/11/2005 02:22:28 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/11/2005 02:22:29 PM, Serialize complete at 07/11/2005 02:22:29 PM Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 See issue below... forwarded to the list for comment. The registration of language name synonyms would definitely be useful to me when I reference the RFC 3066 work. Persian/Farsi, Bangla/Bengali, Irish/Gaelic/Scots Gaelic, and Catalan/Valencian cause a lot of headaches on the language lists I review. I do realize synonym registration could be controversial. For my purposes, Catalan, Balear, and Valencian are synonyms, but I'm sure there's a linguist out there who would disagree. I think Ethnologue and SIL are working on language synonyms. Could these synonyms be incorporated for the languages found in 639-1 and 2? Do you have any thoughts on this Peter? Karen Broome Metadata Systems Designer Sony Pictures Entertainment "Doug Ewell" 07/09/2005 12:31 AM To: cc: Subject: Re: [Ltru] Re: I-D ACTION:draft-ietf-ltru-initial-01.txt Hi Karen, > Are you looking for comments on your draft of the registry entries? I > think I may have a few additions based on some of my research, though > this is my first look at this doc and I don't have much background on > it. > > For example: Would it be appropriate to add "Bangla" as a description > under the "Bengali" entry? > > I see these as two separate entries on a lot of the lists I've > reviewed. This is a good question. I copied the descriptions directly from the relevant ISO and UN standards as much as possible. This was to avoid charges of bias or personal whimsy. For example, for the region subtag KP, I dutifully used the ISO 3166 description "Korea, Democratic People's Republic of" even though I, and probably you and everyone else either of us knows, would call this country "North Korea." Because the official ISO 639-2 code list did not include the name "Bangla" along with "Bengali," I did not include it. That said, it is true that the name "Bangla" is also common, particularly among native speakers when writing in English and referring to their language. It might be reasonable to entertain requests for additional description fields in the initial registry, but if you want to pursue that, I think we should move this question onto the WG list. It's their registry, after all, not just mine. :-) Remember that additional descriptions can always be proposed for registration (Section 3.3, item 2) and that description are not normative in any case. Thanks for the feedback. -- 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 Jul 11 17:29:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5qA-0006yd-Cp; Mon, 11 Jul 2005 17:29:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5q9-0006yY-Rr for ltru@megatron.ietf.org; Mon, 11 Jul 2005 17:29:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17899 for ; Mon, 11 Jul 2005 17:29: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.43) id 1Ds6IE-0001uS-KR for ltru@ietf.org; Mon, 11 Jul 2005 17:58:26 -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 Jul 2005 14:29:08 -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] Initial language registry draft Date: Mon, 11 Jul 2005 14:29:06 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C10904E@irvmbxw01.quest.com> Thread-Topic: [ltru] Initial language registry draft Thread-Index: AcWGXjh9mz4jgAqvRKm8oGaso4qXyAAAGRPw From: "Addison Phillips" To: , X-OriginalArrivalTime: 11 Jul 2005 21:29:08.0140 (UTC) FILETIME=[921E46C0:01C5865F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 This is what the registration process exists for. For the initial registry, IMO, we should stick to *exactly* what the = underlying standard has. Cleanup such as breaking lists of names up into = separate items (Low Saxon and friends, for example) is fine, but other = changes should be avoided. If controversy exists, let it play out using the established process of = registration. Controversial or potentially controversial items should = not be incorporated by the actions of this WG. It is the whole point of = having a registration process to allow this kind of issue a way to = surface and be resolved. Protracted discussion of all the potential = subtag synonyms is a waste of time for this process. 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 Karen_Broome@spe.sony.com > Sent: 2005?7?11? 14:12 > To: ltru@ietf.org > Subject: [ltru] Initial language registry draft >=20 > See issue below... forwarded to the list for comment. >=20 > The registration of language name synonyms would definitely be useful = to > me when I reference the RFC 3066 work. Persian/Farsi, Bangla/Bengali, > Irish/Gaelic/Scots Gaelic, and Catalan/Valencian cause a lot of = headaches > on the language lists I review. >=20 > I do realize synonym registration could be controversial. For my = purposes, > Catalan, Balear, and Valencian are synonyms, but I'm sure there's a > linguist out there who would disagree. I think Ethnologue and SIL are > working on language synonyms. Could these synonyms be incorporated for = the > languages found in 639-1 and 2? Do you have any thoughts on this = Peter? >=20 > Karen Broome > Metadata Systems Designer > Sony Pictures Entertainment >=20 >=20 >=20 >=20 > "Doug Ewell" > 07/09/2005 12:31 AM >=20 >=20 > To: > cc: > Subject: Re: [Ltru] Re: I-D = ACTION:draft-ietf-ltru-initial- > 01.txt >=20 >=20 > Hi Karen, >=20 > > Are you looking for comments on your draft of the registry entries? = I > > think I may have a few additions based on some of my research, = though > > this is my first look at this doc and I don't have much background = on > > it. > > > > For example: Would it be appropriate to add "Bangla" as a = description > > under the "Bengali" entry? > > > > I see these as two separate entries on a lot of the lists I've > > reviewed. >=20 > This is a good question. I copied the descriptions directly from the > relevant ISO and UN standards as much as possible. This was to avoid > charges of bias or personal whimsy. For example, for the region = subtag > KP, I dutifully used the ISO 3166 description "Korea, Democratic > People's Republic of" even though I, and probably you and everyone = else > either of us knows, would call this country "North Korea." >=20 > Because the official ISO 639-2 code list did not include the name > "Bangla" along with "Bengali," I did not include it. >=20 > That said, it is true that the name "Bangla" is also common, > particularly among native speakers when writing in English and = referring > to their language. It might be reasonable to entertain requests for > additional description fields in the initial registry, but if you want > to pursue that, I think we should move this question onto the WG list. > It's their registry, after all, not just mine. :-) Remember that > additional descriptions can always be proposed for registration = (Section > 3.3, item 2) and that description are not normative in any case. >=20 > Thanks for the feedback. >=20 > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ >=20 >=20 >=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@lists.ietf.org Mon Jul 11 17:43:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds63r-0002y4-Hn; Mon, 11 Jul 2005 17:43:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds63q-0002xu-GN for ltru@megatron.ietf.org; Mon, 11 Jul 2005 17:43:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18904 for ; Mon, 11 Jul 2005 17:43:31 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds6Vt-0002TD-Dx for ltru@ietf.org; Mon, 11 Jul 2005 18:12:35 -0400 Received: from h-68-166-37-248.snvacaid.dynamic.covad.net ([68.166.37.248] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Ds63i-0006nY-00 for ltru@ietf.org; Mon, 11 Jul 2005 17:43:27 -0400 Message-ID: <001101c58662$2b26b080$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Additional descriptions not found in ISO (was: Re: [ltru] Initial language registry draft) Date: Mon, 11 Jul 2005 14:47: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: 21c69d3cfc2dd19218717dbe1d974352 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: > To: > Sent: Monday, July 11, 2005 2:11 PM > Subject: [ltru] Initial language registry draft > > See issue below... forwarded to the list for comment. > > The registration of language name synonyms would definitely be useful to > me when I reference the RFC 3066 work. Persian/Farsi, Bangla/Bengali, > Irish/Gaelic/Scots Gaelic, and Catalan/Valencian cause a lot of headaches > on the language lists I review. > > I do realize synonym registration could be controversial. For my purposes, > Catalan, Balear, and Valencian are synonyms, but I'm sure there's a > linguist out there who would disagree. I think Ethnologue and SIL are > working on language synonyms. Could these synonyms be incorporated for the > languages found in 639-1 and 2? Do you have any thoughts on this Peter? ... As a co-chair, I need to ask whether you're asking, in the form of a last call comment, (1) for the addition of a new field to record this information, or (2) for the addition of this information to the initial registry i-d. If you are asking for either or both, I'd like to request that you provide the specific textual changes you'd like to see in the drafts. --- As a technical contributor, I agree with Doug's assessment in http://www1.ietf.org/mail-archive/web/ltru/current/msg02663.html These can be handled by adding "Description" entries as needed once the registry is "live". I think discussion (if any should be necessary) of any specific cases would belong on the ietf-languages@iana.org mailing list rather than here. Trying to complete that task here would introduce delay, and would not offer any more value to users than doing it incrementally on the ietf-languages@iana.org list. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 11 17: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 1Ds67J-0005CP-JR; Mon, 11 Jul 2005 17: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 1Ds67H-00051b-L3 for ltru@megatron.ietf.org; Mon, 11 Jul 2005 17:47:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19635 for ; Mon, 11 Jul 2005 17:47:04 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-res.bigfish.com ([63.161.60.61] helo=mail1-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds6ZL-0002kL-J6 for ltru@ietf.org; Mon, 11 Jul 2005 18:16:08 -0400 Received: from mail1-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail1-res-R.bigfish.com (Postfix) with ESMTP id 81F7F56F9E2; Mon, 11 Jul 2005 21:46:57 +0000 (UTC) X-BigFish: VP Received: by mail1-res.bigfish.com (MessageSwitch) id 1121118417421685_29525; Mon, 11 Jul 2005 21:46:57 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail1-res.bigfish.com (Postfix) with ESMTP id 503F256F9EA; Mon, 11 Jul 2005 21:46:57 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005071114543452:43110 ; Mon, 11 Jul 2005 14:54:34 -0700 To: "Addison Phillips" Subject: RE: [ltru] Initial language registry draft MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Mon, 11 Jul 2005 14:43:59 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/11/2005 14:44:00, Serialize complete at 07/11/2005 14:44:00, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/11/2005 02:54:34 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/11/2005 02:54:35 PM, Serialize complete at 07/11/2005 02:54:35 PM Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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 I think we basically agree. I think registering *some* common troublesome synonyms would be useful, but I think it should be done with the same sort of oversight and review as found in the language name/code process. I was just wondering if Ethnologue had already "validated" some synonyms. This is certainly not a time-critical issue for me (or you). But it would be useful to me, so I figure this might be useful to others. It seemed like synonyms were listed for some languages and not others and I wasn't sure why so I asked Doug privately about "Bangla". I don't think I suggested a protracted discussion of all language synonyms. Ouch! Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 "Addison Phillips" 07/11/2005 02:29 PM To: , cc: Subject: RE: [ltru] Initial language registry draft This is what the registration process exists for. For the initial registry, IMO, we should stick to *exactly* what the underlying standard has. Cleanup such as breaking lists of names up into separate items (Low Saxon and friends, for example) is fine, but other changes should be avoided. If controversy exists, let it play out using the established process of registration. Controversial or potentially controversial items should not be incorporated by the actions of this WG. It is the whole point of having a registration process to allow this kind of issue a way to surface and be resolved. Protracted discussion of all the potential subtag synonyms is a waste of time for this process. 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 Karen_Broome@spe.sony.com > Sent: 2005?7?11? 14:12 > To: ltru@ietf.org > Subject: [ltru] Initial language registry draft > > See issue below... forwarded to the list for comment. > > The registration of language name synonyms would definitely be useful to > me when I reference the RFC 3066 work. Persian/Farsi, Bangla/Bengali, > Irish/Gaelic/Scots Gaelic, and Catalan/Valencian cause a lot of headaches > on the language lists I review. > > I do realize synonym registration could be controversial. For my purposes, > Catalan, Balear, and Valencian are synonyms, but I'm sure there's a > linguist out there who would disagree. I think Ethnologue and SIL are > working on language synonyms. Could these synonyms be incorporated for the > languages found in 639-1 and 2? Do you have any thoughts on this Peter? > > Karen Broome > Metadata Systems Designer > Sony Pictures Entertainment > > > > > "Doug Ewell" > 07/09/2005 12:31 AM > > > To: > cc: > Subject: Re: [Ltru] Re: I-D ACTION:draft-ietf-ltru-initial- > 01.txt > > > Hi Karen, > > > Are you looking for comments on your draft of the registry entries? I > > think I may have a few additions based on some of my research, though > > this is my first look at this doc and I don't have much background on > > it. > > > > For example: Would it be appropriate to add "Bangla" as a description > > under the "Bengali" entry? > > > > I see these as two separate entries on a lot of the lists I've > > reviewed. > > This is a good question. I copied the descriptions directly from the > relevant ISO and UN standards as much as possible. This was to avoid > charges of bias or personal whimsy. For example, for the region subtag > KP, I dutifully used the ISO 3166 description "Korea, Democratic > People's Republic of" even though I, and probably you and everyone else > either of us knows, would call this country "North Korea." > > Because the official ISO 639-2 code list did not include the name > "Bangla" along with "Bengali," I did not include it. > > That said, it is true that the name "Bangla" is also common, > particularly among native speakers when writing in English and referring > to their language. It might be reasonable to entertain requests for > additional description fields in the initial registry, but if you want > to pursue that, I think we should move this question onto the WG list. > It's their registry, after all, not just mine. :-) Remember that > additional descriptions can always be proposed for registration (Section > 3.3, item 2) and that description are not normative in any case. > > Thanks for the feedback. > > -- > 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 Jul 11 18:01:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6LO-0004YM-MX; Mon, 11 Jul 2005 18:01:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6LN-0004Y7-3r for ltru@megatron.ietf.org; Mon, 11 Jul 2005 18:01:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21398 for ; Mon, 11 Jul 2005 18:01:38 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-ash.bigfish.com ([206.16.192.253] helo=mail79-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds6nS-0003VY-9O for ltru@ietf.org; Mon, 11 Jul 2005 18:30:42 -0400 Received: from mail79-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail79-ash-R.bigfish.com (Postfix) with ESMTP id 3020E3E8C9A; Mon, 11 Jul 2005 22:01:28 +0000 (UTC) X-BigFish: VP Received: by mail79-ash (MessageSwitch) id 1121119288139038_27032; Mon, 11 Jul 2005 22:01:28 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail79-ash.bigfish.com (Postfix) with ESMTP id F3CEF3E84DA; Mon, 11 Jul 2005 22:01:27 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005071115090532:43908 ; Mon, 11 Jul 2005 15:09:05 -0700 To: "Randy Presuhn" Subject: Re: Additional descriptions not found in ISO (was: Re: [ltru] Initial language registry draft) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Mon, 11 Jul 2005 14:58:30 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/11/2005 14:58:31, Serialize complete at 07/11/2005 14:58:31, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/11/2005 03:09:05 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/11/2005 03:09:06 PM, Serialize complete at 07/11/2005 03:09:06 PM Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Not a last call request. Thank you. - Karen "Randy Presuhn" Sent by: ltru-bounces@lists.ietf.org 07/11/2005 02:47 PM To: cc: Subject: Additional descriptions not found in ISO (was: Re: [ltru] Initial language registry draft) Hi - > From: > To: > Sent: Monday, July 11, 2005 2:11 PM > Subject: [ltru] Initial language registry draft > > See issue below... forwarded to the list for comment. > > The registration of language name synonyms would definitely be useful to > me when I reference the RFC 3066 work. Persian/Farsi, Bangla/Bengali, > Irish/Gaelic/Scots Gaelic, and Catalan/Valencian cause a lot of headaches > on the language lists I review. > > I do realize synonym registration could be controversial. For my purposes, > Catalan, Balear, and Valencian are synonyms, but I'm sure there's a > linguist out there who would disagree. I think Ethnologue and SIL are > working on language synonyms. Could these synonyms be incorporated for the > languages found in 639-1 and 2? Do you have any thoughts on this Peter? ... As a co-chair, I need to ask whether you're asking, in the form of a last call comment, (1) for the addition of a new field to record this information, or (2) for the addition of this information to the initial registry i-d. If you are asking for either or both, I'd like to request that you provide the specific textual changes you'd like to see in the drafts. --- As a technical contributor, I agree with Doug's assessment in http://www1.ietf.org/mail-archive/web/ltru/current/msg02663.html These can be handled by adding "Description" entries as needed once the registry is "live". I think discussion (if any should be necessary) of any specific cases would belong on the ietf-languages@iana.org mailing list rather than here. Trying to complete that task here would introduce delay, and would not offer any more value to users than doing it incrementally on the ietf-languages@iana.org list. 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 Jul 11 19:01:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds7HI-0003UO-GR; Mon, 11 Jul 2005 19:01:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds7HH-0003UE-7G for ltru@megatron.ietf.org; Mon, 11 Jul 2005 19:01:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29629 for ; Mon, 11 Jul 2005 19:01:27 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds7jK-0006Uh-JI for ltru@ietf.org; Mon, 11 Jul 2005 19:30:32 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jul 2005 16:01: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.1830); Mon, 11 Jul 2005 16:01:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [ltru] Initial language registry draft Date: Mon, 11 Jul 2005 16:01:23 -0700 Message-ID: Thread-Topic: [ltru] Initial language registry draft Thread-Index: AcWGXjnCghrz2fO/TBOyji4BkvCX3AADQfLA From: "Peter Constable" To: X-OriginalArrivalTime: 11 Jul 2005 23:01:19.0342 (UTC) FILETIME=[72F8B8E0:01C5866C] 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 > Karen_Broome@spe.sony.com > The registration of language name synonyms would definitely be useful = to > me when I reference the RFC 3066 work. Persian/Farsi, Bangla/Bengali, > Irish/Gaelic/Scots Gaelic, and Catalan/Valencian cause a lot of = headaches > on the language lists I review. >=20 > I do realize synonym registration could be controversial. For my = purposes, > Catalan, Balear, and Valencian are synonyms, but I'm sure there's a > linguist out there who would disagree. I think Ethnologue and SIL are > working on language synonyms. Could these synonyms be incorporated for = the > languages found in 639-1 and 2? Do you have any thoughts on this = Peter? I think there are several cases in which it would be useful to include = alternate names for a given language in the registry. (By that, I don't = me names in additional languages.) Ethnologue tries to document = alternates. (There is room for some improvement; e.g. I think it could = do a little better job at how it tracks names used in different = countries, and it could perhaps distinguish truly alternate names from = mere alternate spellings=FD.) ISO 639 also does this to some extent (it = is possible to add alternate names where not already listed).=20 For purposes of this registry, I think the initial registry should stick = with what is published in ISO 639-1/-2, and that any additions people = may desire should be handled by the ietf-languages registration process. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 11 22:04:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsA86-0002OT-1a; Mon, 11 Jul 2005 22: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 1DsA84-0002O5-MX for ltru@megatron.ietf.org; Mon, 11 Jul 2005 22:04:12 -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 WAA15580 for ; Mon, 11 Jul 2005 22:04:10 -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 <20050712020340.VUZ19267.mta10.adelphia.net@DEWELL> for ; Mon, 11 Jul 2005 22:03:40 -0400 Message-ID: <001201c58685$e75e0c80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: Date: Mon, 11 Jul 2005 19:03: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 Cc: Subject: [Ltru] Re: Frank's editorial comments 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 I am fine with Frank's proposed changes, except for the following: > 6. Items withdrawn, vacated, deprecated, > + or modified > - modified, or otherwise judged by the LTRU working group > - to be questionable > were not added to the ILSR. This works out to "Items withdrawn, vacated, deprecated, or modified were not added to the ILSR." I don't like the feel of this sentence, and to be honest, I don't know what the word "modified" is doing there. If the numeric code has been modified, that means the code element has been withdrawn and is not in the registry; if it's just the name that has been modified, the item is in the registry under the new name. I would prefer: "Code elements that were withdrawn, vacated, or deprecated from [UN-M.49] as of the date of adoption of [I-D.ietf-ltru-registry] were not added to the ILSR." > I didn't check all tags > again assuming that you'd tell us if you did something more > interesting than replacing some dates by 2005-07-10. No content changes other than the one's we've discussed on the list, and advancing "Date B" with each draft. > All references are in fact referenced. The tools make it difficult to do otherwise. Thanks for your comments. -- 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 Jul 11 23:29:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsBSu-0005gq-Th; Mon, 11 Jul 2005 23:29:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsBSs-0005gg-UB for ltru@megatron.ietf.org; Mon, 11 Jul 2005 23:29: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 XAA20964 for ; Mon, 11 Jul 2005 23:29:43 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DsBSc-0002dI-1y for ltru@lists.ietf.org; Tue, 12 Jul 2005 05:29:30 +0200 Received: from 212.82.251.111 ([212.82.251.111]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Jul 2005 05:29:30 +0200 Received: from nobody by 212.82.251.111 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Jul 2005 05:29:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 12 Jul 2005 05:28:07 +0200 Organization: Lines: 18 Message-ID: <42D338C7.39B8@xyzzy.claranet.de> References: <001201c58685$e75e0c80$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.111 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] editorial comments 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 Doug Ewell wrote: > to be honest, I don't know what the word "modified" is doing > there. Nor do I, I just copied it from draft -02, if it's unnecessary let's get rid of it: > I would prefer: "Code elements that were withdrawn, vacated, > or deprecated from [UN-M.49] as of the date of adoption of > [I-D.ietf-ltru-registry] were not added to the ILSR." That's okay. It's one of our axioms that the UN numbers are never "modified" - unless "the same piece of uknow" picks a new name, then that name can be modified. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 10:00:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsLIr-0006fQ-Je; Tue, 12 Jul 2005 10:00:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsLIo-0006eT-Sl for ltru@megatron.ietf.org; Tue, 12 Jul 2005 10:00:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23059 for ; Tue, 12 Jul 2005 10:00:00 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsLl0-0005MW-AA for ltru@ietf.org; Tue, 12 Jul 2005 10:29: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 j6CDxjWG002341; Tue, 12 Jul 2005 09:59:46 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 12 Jul 2005 09:59:45 -0400 Date: Tue, 12 Jul 2005 09:59:44 -0400 From: "John.Cowan" To: Addison Phillips Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Message-ID: <20050712135944.GA3752@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0C108BE4@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C108BE4@irvmbxw01.quest.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: > If it becomes necessary to > identify a region for which only a UN M.49 code exists in language tags, > then the registration authority for ISO 3166 SHOULD be petitioned to > assign a code: such a code could then be registered for use in language > tags. I think this "could" ==> SHOULD, or at the very least MAY. While I'm at it, in the 2005-7-11 draft: "could be included" in 3.4 ==> MAY; "might be interpreted", "could be taken", "could be regarded", "one could write", "could be used" ==> MAY; "could be used" in 4.5 ==> MAY; "cannot" in 2.2.3 ==> MUST NOT; "can" in 2.2.4 ==> MAY; "cannot" in 2.2.6 items 1 and 3 ==> MUST NOT; "can be split" and "can use the registry" in 3.1 ==> MAY; "can raise objections" in 3.4 ==> MAY; "can be registered" in 3.5 ==> MAY; "can only give possible examples" in 4.2 needs no modal, and ==> "gives only possible examples"; "can use" in 7 ==> MAY; "ought not" in 4.1 ==> SHOULD NOT; "will" in 2.2.1 item 5 ==> SHOULD or perhaps MUST; "will not be added" in 2.2.1 ==> MUST NOT; "will maintain" in 2.2.8 ==> MUST; "will be maintained" in 3 ==> MUST; "will consist" in 3.1 ==> MUST; "no registration records will be maintained" in 3.1 ==> "registration records MUST NOT be maintained"; "will be in a modified" in 3.1 ==> MUST; "will evaluate" in 3.2 ==> MUST; "no new entries will be added and none of the entries will be removed" in 3.2 ==> "new entries MUST NOT be added or removed"; "will be maintained" in 3.4 ==> MUST; "No subtags will be registered" in 3.5 ==> "Subtags MUST NOT be registered"; TYPO: "will lend" in 3.6 ==> "will tend"; "will use" and "will forward" in 3.6 ==> MUST; "will be initialized", "will be relabeled", "will be limited", and "will be sent" in 5.1 ==> MUST; "will include" in 5.2 ==> MUST; "will continue" in 8 ==> SHOULD; Some of these changes may be inappropriate because of the broader context; I haven't fully investigated. -- 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@lists.ietf.org Tue Jul 12 12:46:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsNtT-0002Iy-7s; Tue, 12 Jul 2005 12:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsNtQ-0002Dz-Ob for ltru@megatron.ietf.org; Tue, 12 Jul 2005 12:46:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14964 for ; Tue, 12 Jul 2005 12:45: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.43) id 1DsOLe-00061Z-DU for ltru@ietf.org; Tue, 12 Jul 2005 13:15:11 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 09: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: Finishing off #1026 (Was: Re: status? last call?) Date: Tue, 12 Jul 2005 09:45:42 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C1092A4@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Thread-Index: AcWG6gGcEZDg04EOREaNAGRzdJ73EQAASMSA From: "Addison Phillips" To: "John.Cowan" X-OriginalArrivalTime: 12 Jul 2005 16:45:43.0288 (UTC) FILETIME=[24D98780:01C58701] X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d 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 Notes below. Broadly, use of normative language represents a substantive change. Some = of these were specifically changed from normative to non-normative = language previously. The other items I have gone through methodically, results interlinear = below. The first item is moot. That paragraph was rewritten to address Frank's = comments and I spent a good bit of editorial attention on making it very = clear and more rule-like. It now reads: UN M.49 has codes for both countries and areas (such as '276' for = Germany) and geographical regions and sub-regions (such as '150' for = Europe). UN M.49 country or area codes for which there is no = corresponding ISO 3166 code SHOULD NOT be registered, except as a = surrogate for an ISO 3166 code that is blocked from registration by an = existing subtag. If such a code becomes necessary, then the registration = authority for ISO 3166 SHOULD first be petitioned to assign a code to = the region. If the petition for a code assignment by ISO 3166 is refused or not acted on in a timely manner, the registration process described = in MAY then be used to = register the corresponding UN M.49 code. At the time this document was = written, there were only four such codes: 830 (Channel Islands), 831 = (Guernsey), 832 (Jersey), and 833 (Isle of Man). This way UN M.49 codes = remain available as the value of last resort in cases where ISO 3166 = reassigns a deprecated value in the registry. 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: 2005?7?12? 7:00 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last = call?) >=20 > Addison Phillips scripsit: >=20 > > If it becomes necessary to > > identify a region for which only a UN M.49 code exists in language = tags, > > then the registration authority for ISO 3166 SHOULD be petitioned to > > assign a code: such a code could then be registered for use in = language > > tags. >=20 > I think this "could" =3D=3D> SHOULD, or at the very least MAY. >=20 > While I'm at it, in the 2005-7-11 draft: >=20 > "could be included" in 3.4 =3D=3D> MAY; [Addison Phillips]=20 -not a normative statement; it's an example > "might be interpreted", "could be taken", "could be regarded", "one > could write", "could be used" =3D=3D> MAY; [Addison Phillips]=20 -examples all > "could be used" in 4.5 =3D=3D> MAY; [Addison Phillips]=20 +marginal case. (In case it isn't clear, my comments with - are rejects = and + are where I made the change.) > "cannot" in 2.2.3 =3D=3D> MUST NOT; [Addison Phillips]=20 -another example =20 > "can" in 2.2.4 =3D=3D> MAY; [Addison Phillips]=20 -explanatory text which should not be normative. Here's what it says: Their syntax is described here so that implementations can be compatible = with any future revision of this document which does provide for their = registration. > "cannot" in 2.2.6 items 1 and 3 =3D=3D> MUST NOT; [Addison Phillips]=20 +the first one -the second one: it is in a sentence that explains the sentence before = it (which is normative) > "can be split" and "can use the registry" in 3.1 =3D=3D> MAY; [Addison Phillips]=20 -the first one: too pedantic -the second one: this is explaining something that is possible, not a = normative restriction. > "can raise objections" in 3.4 =3D=3D> MAY; [Addison Phillips]=20 +this should be normative > "can be registered" in 3.5 =3D=3D> MAY; [Addison Phillips]=20 +this should be normative > "can only give possible examples" in 4.2 needs no modal, and > =3D=3D> "gives only possible examples"; [Addison Phillips]=20 +although this is the original RFC 3066 text > "can use" in 7 =3D=3D> MAY; [Addison Phillips]=20 -not really normative; could change this to "sometimes use" > "ought not" in 4.1 =3D=3D> SHOULD NOT; [Addison Phillips]=20 -explanatory text > "will" in 2.2.1 item 5 =3D=3D> SHOULD or perhaps MUST; [Addison Phillips]=20 -unnecessary: this is discussing the likely attitude of ietf-languages = towards primary language subtag registrations. > "will not be added" in 2.2.1 =3D=3D> MUST NOT; [Addison Phillips]=20 +this should be normative > "will maintain" in 2.2.8 =3D=3D> MUST; [Addison Phillips]=20 +/-Hmm... this sentence is a bit mushy, since it implies that IANA will = be actively maintaining these particular registry entries, which is not = actually correct. Changed from: -- IANA=20 will maintain these tags in the registry under either the = "grandfathered"=20 or "redundant" type. -- To: -- These tags will be maintained in the registry in records of either the = "grandfathered" or "redundant" type. -- > "will be maintained" in 3 =3D=3D> MUST; [Addison Phillips]=20 -shouldn't be normative, although the sentence isn't very elegant > "will consist" in 3.1 =3D=3D> MUST; [Addison Phillips]=20 -shouldn't be normative. Did change tense to 'consists' > "no registration records will be maintained" in 3.1 =3D=3D> > "registration records MUST NOT be maintained"; [Addison Phillips]=20 -shouldn't be normative. > "will be in a modified" in 3.1 =3D=3D> MUST; [Addison Phillips]=20 +/-changed from future to present tense, but not turned into a MUST. = This section describes the registry and its format. All of the = initialization and maintenance instructions use normative language that = references this section. Littering this section with MUSTs will make it = difficult to read and not add to the clarity of it. > "will evaluate" in 3.2 =3D=3D> MUST; [Addison Phillips]=20 +changed > "no new entries will be added and none of the entries will be > removed" > in 3.2 =3D=3D> "new entries MUST NOT be added or removed"; [Addison Phillips]=20 +changed to: new entries in this section MUST NOT be added and existing = entries MUST NOT be removed > "will be maintained" in 3.4 =3D=3D> MUST; [Addison Phillips]=20 -/+ changed to "exists" > "No subtags will be registered" in 3.5 =3D=3D> "Subtags MUST NOT > be registered"; [Addison Phillips]=20 +changed > TYPO: "will lend" in 3.6 =3D=3D> "will tend"; [Addison Phillips]=20 Not a typo. Here's the sentence: In addition,=20 defining a mechanism for maintaining single-letter subtags will lend = to the stability of this document by reducing the likely need for future = revisions or updates. > "will use" and "will forward" in 3.6 =3D=3D> MUST; [Addison Phillips]=20 +first one +second one > "will be initialized", "will be relabeled", "will be limited", and > "will be sent" in 5.1 =3D=3D> MUST; [Addison Phillips]=20 -first one +second one +third one > "will include" in 5.2 =3D=3D> MUST; [Addison Phillips]=20 +changed > "will continue" in 8 =3D=3D> SHOULD; [Addison Phillips]=20 -not necessary (describes user's or application's choice of language = tags) >=20 > Some of these changes may be inappropriate because of the broader = context; > I haven't fully investigated. >=20 > -- > 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@lists.ietf.org Tue Jul 12 12:48:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsNvz-0002pz-5D; Tue, 12 Jul 2005 12:48:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsNvx-0002pU-NJ for ltru@megatron.ietf.org; Tue, 12 Jul 2005 12:48:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15145 for ; Tue, 12 Jul 2005 12:48:35 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsOO4-00066f-Oj for ltru@ietf.org; Tue, 12 Jul 2005 13:17:49 -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 RELAYIN4-542d3f444286; Tue, 12 Jul 2005 12:48:05 -0500 Received: from DEBHOME (ACD7B38E.ipt.aol.com [172.215.179.142]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j6CGlpqw006242 for ; Tue, 12 Jul 2005 12:47:52 -0400 Message-Id: <200507121647.j6CGlpqw006242@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: Date: Tue, 12 Jul 2005 17:48:08 +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: AcWHAXdNDNA5oUjvRQCYkUiS5TvExw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 2.6 (++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Jersey JE and Guernsey GG Country Codes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 FYI There is an official proposal, endorsed by UK government to adopt these codes and it should be available on Friday for submission to DIN via BSI. Kind regards Debbie Garside _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 15:11:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQ9p-00027d-LP; Tue, 12 Jul 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 1DsQ9n-00027Y-4c for ltru@megatron.ietf.org; Tue, 12 Jul 2005 15:11:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25290 for ; Tue, 12 Jul 2005 15:11:01 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsQc2-0002YR-Ss for ltru@ietf.org; Tue, 12 Jul 2005 15:40:15 -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 Jul 2005 15:10:53 -0400 id 005A41E9.42D415BD.0000773B From: "Scott Hollenbeck" To: randy_presuhn@mindspring.com, "'Martin Duerst'" Date: Tue, 12 Jul 2005 15:11:04 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <6.2.1.2.2.20050704225848.05409eb0@mail.afrac.org> Thread-Index: AcWBE11S8CowA2qcSUa5Lyez/TpK9wF0u5Jw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08582f3b796126054df71137d5cb69f8 Content-Transfer-Encoding: quoted-printable Cc: ltru@ietf.org Subject: [Ltru] RE: Appeal of the suspending J.F.C. Morfin - RFC 3934 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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, Martin: I have completed my review of the situation that resulted in the = announced suspension of posting rights [1] for Mr. J.F.C. Morfin and his appeal of that decision as described below. Though the appeal was not made on the working group mailing list, I am replying to the appeal with a cc to the list to document this action "for the record". The suspension was enacted under terms described in RFC 3934. RFC 3934 updates RFC 2418. Section 3.4 of RFC 2418 describes the appeal process, citing RFC 2026. Section 6.5 of RFC 2026 describes the appeal = procedures and requirements. I believe that the requirements described in section 6.5.4 of RFC 2026 = have been met. The appeal is valid. Section 2 of RFC 3934 describes the requirements that must be met to = suspend the mailing list posting rights of a working group member. Here are the relevant paragraphs: "If the behavior persists, the WG chair should send at least one public warning on the WG mailing list. As a last resort and typically after = one or more explicit warnings and consultation with the responsible Area = Director, the WG chair may suspend the mailing list posting privileges of the disruptive individual for a period of not more than 30 days." and "However, further disruptive behavior by the same individual will be considered separately and may result in further warnings or = suspensions." A public warning was delivered to Mr. Morfin on 5 April 2005 [2]. The = LTRU working group chairs consulted with me on 12 and 13 May, 2005, after = working group members complained that the behavior that prompted the warning was continuing. A 10-day suspension was announced on 13 May 2005 [3]. A second, 30-day suspension was announced on 4 July 2005 [1]. This suspension was based on a note sent on 26 May 2005 [4]. I find that the note of 26 May is not explicit enough to be considered a warning as described in RFC 3934. While it says that "your posting privileges may again be suspended", there is reasonable ambiguity in understanding if this is a formal warning as described in RFC 3934 or if this is a note explaining that a formal warning and the suspension = process may be invoked yet again. I must therefore uphold the appeal and request that Mr. Morfin's posting rights be restored. [I note that Mr. Morfin's posting privileges were actually restored = ahead of this decision as a result of working group chair review of Mr. Morfin's appeal. Posting privileges were restored on 5 July 2005. I also note = that the message announcing restoration of posting privileges [5] includes a formal warning as described in RFC 3934.] Scott Hollenbeck LTRU Area Advisor [1] http://www1.ietf.org/mail-archive/web/ltru/current/msg02532.html [2] http://www1.ietf.org/mail-archive/web/ltru/current/msg00564.html [3] http://www1.ietf.org/mail-archive/web/ltru/current/msg01737.html [4] http://www1.ietf.org/mail-archive/web/ltru/current/msg01897.html [5] http://www1.ietf.org/mail-archive/web/ltru/current/msg02548.html > -----Original Message----- > From: r&d afrac [mailto:rd@afrac.org]=20 > Sent: Monday, July 04, 2005 10:48 PM > To: hardie@qualcomm.com; sah@428cobrajet.net;=20 > randy_presuhn@mindspring.com; Martin Duerst > Subject: Appeal of the suspending J.F.C. Morfin - RFC 3934 >=20 > Dear ADs and co-Chairs, > I formally appeal of the following decision documented by an=20 > uncomplete=20 > mail exchange with Mr. Doug Ewell. >=20 > At 21:56 04/07/2005, Randy Presuhn wrote: > >Hi - > >Jefsey has once again become too disruptive, engaging > >in personal attacks, misrepresenting the positions of others, > >revisiting long-resolved issues, and generally impeding timely > >completion of our assigned task by causing other WG members > >to waste time. > > > >Pursuant to RFC 3934, I am suspending the posting > >privileges of his subscribed addresses to the ltru WG > >mailing list, for a period of up to 30 days. His posting > >privileges will be restored no later than August third, 2005. > > > >Randy, ltru co-chair >=20 >=20 > The reasons of this appeal are: >=20 > 1. to acknowledge the decision motivated by an exchange with=20 > Mr. Doug Ewell=20 > and to include in the appeal file the entirety of the=20 > exchange, as it was=20 > three hours before Mr. Presuhn quoted it. > 2. to permit both ADs and both co-Chairs to confirm that all=20 > the RFC 3934=20 > procedures have been timely respected. > 3. for them to kindly explain what is wrong in the positions=20 > I expressed in=20 > the exchanged attached to the decision. > 4. to make publicly noted that I was expelled from the WG for=20 > the Last Call=20 > period and that I appealed from that decision. >=20 > I wish to comment this appeal. >=20 >=20 > A. I share into the WG-ltru as part of my responsibilities of=20 > R&D of AFRAC=20 > (http://afrac.org) and I represent various organisations, government=20 > agencies and ccTLDs as part of my NICSO membership=20 > (http://nicso.org/3869.htm). As such I certainly match the=20 > criteria and I=20 > face for months the difficulties identified by RFC 3969: "In=20 > addition to=20 > issues about which projects are funded, the [commercial]=20 > funding source can=20 > also affect the content of the research, for example, towards=20 > or against=20 > the development of open standards, or taking varying degrees=20 > of care about=20 > the effect of the developed protocols on the other traffic on=20 > the Internet". >=20 > I am interested in this WG due to its target to modify the=20 > purpose of the=20 > RFC 3066 Registry and the general usage of its langtags, what=20 > we firmly=20 > oppose as hurting our own R&D and conflicting with our ISO positions,=20 > detrimental to our national and cultural interests and opposed to the=20 > subsidiarity of the internet architecture. The recent change=20 > in the nature=20 > of the IANA control adds to our opposition to these changes=20 > on a general=20 > basis. The lack of description of the resulting load on the=20 > IANA servers=20 > and costs of our contributions as ccTLDs adds to our objections. >=20 > These obections are summarised in a single demand over and=20 > over presented=20 > and never discussed: to remove the sentence "This memo=20 > replaces RFC 3066",=20 > so we may live in peace, while the affinity group promoting the new=20 > proposition may od what they want (what they can do without=20 > conflict) since=20 > they preserve a retro-compatibility with RFC 3066. >=20 >=20 > B. My suspension is documented by an exchange with Mr. Ewell.=20 > Mr. Ewell in=20 > his response ignored by Mr. Presuhn documents the three=20 > points I oppose.=20 > Quoting him will protect against "misrepresentations": >=20 > 1. consideration and understanding of the Internet standard process >=20 > Mr. Ewell: "We are supposed to be moving forward, not=20 > obsessing on last=20 > December. But since you mention it, most of the criticism of=20 > the previous=20 > Last Call that I heard, as a member of ietf-languages (where=20 > most of those=20 > concerns were being aired), had to do with the fact that the document=20 > wasn't created by a WG, and as such had no charter or chair=20 > or AD, and thus=20 > no accountability and format review process. Now we have all=20 > of those things." >=20 > I tend to think that considering a WG, Chairs and ADs as=20 > "things" only=20 > necessary to get a positive Last Call is hurting for the WG=20 > Members and for=20 > the ADs and through them for the IETF. I feel it also denotes=20 > a lack of=20 > understanding of the purpose of the Internet standard=20 > process. The mere=20 > fact that this WG has not proceeded on a clean sheet basis,=20 > starting from=20 > the Charter, but simply continued accumulating Drafts over the failed=20 > proposition, may explain what are the "long-resolved issue" I am=20 > revisiting. Also show that the WG would need guidance about=20 > the Internet=20 > standard process. >=20 > 2. misrepresentation of others positions. >=20 > Mr. Ewell: "Criticizing and opposing our project is perfectly=20 > fine, and a=20 > normal part of the process. Accusing individuals of trying=20 > to take over=20 > the world is absolutely uncalled for." >=20 > It is significant that Mr. Ewell says "our" project. Engaging=20 > in personal=20 > attacks, accusing individuals, consists in quoting the name=20 > of the author.=20 > I say authors wants to do two contradictory things many=20 > explained them many=20 > times - and the reason why the Last Call failed: to=20 > progressively narrow a=20 > semantic, grammar, etc. of a currently general protocol, and=20 > at the same=20 > time to keep using its global scope BCP. "to take over the=20 > world" consists=20 > in ... introducing a standard draft... >=20 > 3. decision >=20 > "I am sure that there is some perfectly good reason why the=20 > co-chairs are=20 > allowing this personal sniping and misrepresentation to=20 > continue unchecked,=20 > but for the life of me I don't understand it. It will=20 > certainly make me=20 > think twice about volunteering to participate in another IETF=20 > WG, and it=20 > may cause me to leave this one." >=20 > I note that - after scores of exchanges where I opposed in=20 > various forms=20 > the two points above - it is only three hours after this Mr.=20 > Ewell's email=20 > that Mr. Presuhn sent his decision, without even copying his=20 > co-Chair and=20 > the ADs. >=20 >=20 > C. I am co-ordinating with searchers, organisations and government=20 > officials and international agencies I keep informed. They=20 > perfectly know=20 > the harassment I am subject to protect the stability and the=20 > person to=20 > person interintelligibility against the consequences of a proposition=20 > motivated by commercial interests. Mr. Ewell describes them=20 > as "hijack the=20 > Internet, trample on the national rights of governments, take=20 > over control=20 > of ISO standards, and manipulate cultures". We do not know if=20 > this could go=20 > to such extremities, but we certainly agree with RFC 3968=20 > when it says they=20 > "can also affect the content of the research, for example, towards or=20 > against the development of open standards, or taking varying =20 > degrees of=20 > care about the effect of the developed protocols on the other=20 > traffic on=20 > the Internet." >=20 > This is something we do not want. >=20 > We certainly consider that this decision and the need to=20 > appeal are part of=20 > a process of consensus by exhaustion. Most of the people I=20 > keep informed=20 > have now lost interest in IETF and decided to push for alternative=20 > solutions I documented in the hope this WG-ltru would listen.=20 > Due to who=20 > some are, this is damageable to the whole process, should the=20 > Draft be=20 > accepted by the IETF and know some usage. We still hope that=20 > with the delay=20 > we obtained, reason will prevail and a consensus will be=20 > formed around the=20 > ISO 639 series, 3166 and 11179, in line with the WG-ltru Charter. >=20 > Jean-Fran=E7ois C. (Jefsey) Morfin > http://afrac.org > http://nicso.org >=20 > ---- Original Message ----- > > > From: "r&d afrac" > > > To: "Doug Ewell" ; "LTRU Working Group"=20 > > > > > Sent: Monday, July 04, 2005 1:15 AM > > > Subject: Re: [Ltru] Re: IANA ISO 3166 related Registries > > > > > > At 07:11 04/07/2005, Doug Ewell wrote: > > > >r&d afrac wrote: > > > > > > > > > Addison describes his intent to rule the future. No=20 > objection to that, > > > > > except he also wants to rule the net.(BCP 47) > > > > > > > >I am amazed and bewildered that this sort of personal=20 > abuse is allowed > > > >to continue, month after month. It makes me not want to=20 > participate any > > > >more. > > > > > > Which abuse ???? Your mail is either hurting without=20 > reason or a troll? Or > > > it may also be that you are not familiar with the=20 > Internet architecture and > > > with the Internet standard process? In that case: > > > > > > - Addison describes his plan which is to make what he=20 > calls RFC 3066 > > > bis/ter to more and more define a grammar, semantic, etc.=20 > So every version > > > stays compatible with the previous one (but not the=20 > previous one with the > > > new one). This has the advantage to get at the end of the=20 > day a very > > > strict, may be clear (if there are not too many=20 > complexity to address the > > > legacy of the previous RFCs), an probably stable system.=20 > I have no problem > > > with this, except that I do not understand its use. But=20 > Addison says he > > > needs it. > > > > > > - the problem is that he also wants to make his draft to=20 > replace RFC 3066, > > > what will make it ipso-facto the new BCP 47. BCP 47 is=20 > the current rule of > > > the net in matter of languages. > > > > > > I do not see what can be abusive and personal in this???=20 > This problem is > > > the _only_ real problem of this Draft. It was documented=20 > at length by John > > > Klensin, Dave Crocker and others during the last Last=20 > Call and will make > > > the next Last Call fail. > > > > > > This lack of understanding of the Internet standard=20 > process by W3C people > > > can be easily shown. You go on Google and look for "W3C=20 > RFC 3066" (and > > > RFC3066): there are 14,950 responses. If you enter the=20 > same "W3C BCP 47", > > > you get 675 responses (0.5%). This means that people refer to the > > > non-canonical version of what they want to say, and that=20 > they will have to > > > update all of them if the Draft is approved. Would they=20 > have understood the > > > Internet standard process document management system,=20 > they would have most > > > probably used BCP as a BCP can be updated, not an RFC,=20 > and is therefore > > > canonical. > > > > > > jfc > > > >=20 >=20 > At 18:47 04/07/2005, Doug Ewell wrote: > >r&d afrac wrote: > > > > >>> Addison describes his intent to rule the future. No objection to > > >>> that, except he also wants to rule the net.(BCP 47) > > >> > > >> I am amazed and bewildered that this sort of personal abuse is > > >> allowed to continue, month after month. It makes me not want to > > >> participate any more. > > > > > > Which abuse ???? Your mail is either hurting without reason or a > > > troll? > > > >This is not the first time you have claimed that either this=20 > WG or its > >members are trying to "rule the future" or "take over the=20 > world." This > >WG is trying to expand the existing mechanism for specifying the > >language of content on the Internet and elsewhere. You greatly > >overestimate the global importance of this project, and badly > >misunderstand the intentions of its participants. > > > >Making demonstrably false accusations that WG participants=20 > are trying to > >hijack the Internet, trample on the national rights of=20 > governments, take > >over control of ISO standards, and manipulate cultures is what is > >hurtful. > > > >Why don't you quote the e-mail in which Addison "describes=20 > his intent to > >rule the future"? Go ahead, I'll wait. > > > > > - Addison describes his plan > > > >Not just his. > > > > > which is to make what he calls RFC 3066 bis/ter to more and more > > > define a grammar, semantic, etc. So every version stays compatible > > > with the previous one (but not the previous one with the new one). > > > This has the advantage to get at the end of the day a=20 > very strict, may > > > be clear (if there are not too many complexity to address=20 > the legacy > > > of the previous RFCs), an probably stable system. I have=20 > no problem > > > with this, except that I do not understand its use. But=20 > Addison says > > > he needs it. > > > >RFC 1766 and 3066 already defined a grammar and semantic. =20 > The current > >draft expands on this. > > > >Lots of people need this, not just Addison personally, and=20 > not just the > >W3C. People have been saying this for over a year; you have=20 > chosen not > >to listen or believe. > > > > > - the problem is that he also wants to make his draft to=20 > replace RFC > > > 3066, what will make it ipso-facto the new BCP 47. BCP 47 is the > > > current rule of the net in matter of languages. > > > >In the matter of assigning short text strings to *represent*=20 > languages. > >This is an important distinction. None of this "tagging"=20 > activity has > >anything to do with defining, authorizing, sanctioning,=20 > supporting, or > >suppressing the languages themselves. They are just symbols. > > > >Why don't you go pick on Harald Alvestrand for trying to "rule the > >future" back in 2001, when RFC 3066 was published and made a BCP? > > > > > I do not see what can be abusive and personal in this??? > > > >Accusing Addison of trying to "rule the future" is abusive=20 > and personal. > >He is doing his job as WG participant and co-editor of a WG document. > > > > > This problem is the _only_ real problem of this Draft. It was > > > documented at length by John Klensin, Dave Crocker and=20 > others during > > > the last Last Call and will make the next Last Call fail. > > > >We are supposed to be moving forward, not obsessing on last December. > >But since you mention it, most of the criticism of the previous Last > >Call that I heard, as a member of ietf-languages (where most of those > >concerns were being aired), had to do with the fact that the document > >wasn't created by a WG, and as such had no charter or chair=20 > or AD, and > >thus no accountability and format review process. Now we have all of > >those things. > > > > > This lack of understanding of the Internet standard process by W3C > > > people can be easily shown. You go on Google and look for "W3C RFC > > > 3066" (and RFC3066): there are 14,950 responses. If you=20 > enter the same > > > "W3C BCP 47", you get 675 responses (0.5%). This means that people > > > refer to the non-canonical version of what they want to=20 > say, and that > > > they will have to update all of them if the Draft is=20 > approved. Would > > > they have understood the Internet standard process=20 > document management > > > system, they would have most probably used BCP as a BCP can be > > > updated, not an RFC, and is therefore canonical. > > > >It means that many more people on the Internet refer to RFC=20 > numbers than > >to BCP numbers. > > > >Criticizing and opposing our project is perfectly fine, and a normal > >part of the process. Accusing individuals of trying to take over the > >world is absolutely uncalled for. > > > >I am sure that there is some perfectly good reason why the=20 > co-chairs are > >allowing this personal sniping and misrepresentation to continue > >unchecked, but for the life of me I don't understand it. It will > >certainly make me think twice about volunteering to participate in > >another IETF WG, and it may cause me to leave this one. >=20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 15:59:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQuI-0002pj-Uh; Tue, 12 Jul 2005 15:59:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsQuI-0002mX-3g for ltru@megatron.ietf.org; Tue, 12 Jul 2005 15:59:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00502 for ; Tue, 12 Jul 2005 15:59:03 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsRMW-0004lp-IX for ltru@ietf.org; Tue, 12 Jul 2005 16:28:17 -0400 Received: from h-68-166-189-110.snvacaid.dynamic.covad.net ([68.166.189.110] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DsQuC-0006WQ-00 for ltru@ietf.org; Tue, 12 Jul 2005 15:59:00 -0400 Message-ID: <006c01c5871c$c00ae260$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C1092A4@irvmbxw01.quest.com> Date: Tue, 12 Jul 2005 13:03: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: 681e62a2ce9b0804b459fe780d892beb Cc: Subject: [Ltru] Adding more 2119 keywords (was: Re: Finishing off #1026) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - Both as an individual contributor and as a co-chair, I'd like to remind everyone of the guidance RFC 2119 gives in the use of these keywords: Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) Since we are in working group last call, I'd like all concerned to consider carefully whether each proposed change of this type is actually *necessary*. If it is, fine. Necessary fixes should be taken care of. If the proposed keyword addition is not *necessary*, I suggest considering whether the value of making the change is worth the risk of the changes cumulatively necessitating a second last call. Randy ----- Original Message ----- From: "Addison Phillips" To: "John.Cowan" Cc: Sent: Tuesday, July 12, 2005 9:45 AM Subject: RE: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Notes below. Broadly, use of normative language represents a substantive change. Some of these were specifically changed from normative to non-normative language previously. The other items I have gone through methodically, results interlinear below. The first item is moot. That paragraph was rewritten to address Frank's comments and I spent a good bit of editorial attention on making it very clear and more rule-like. It now reads: UN M.49 has codes for both countries and areas (such as '276' for Germany) and geographical regions and sub-regions (such as '150' for Europe). UN M.49 country or area codes for which there is no corresponding ISO 3166 code SHOULD NOT be registered, except as a surrogate for an ISO 3166 code that is blocked from registration by an existing subtag. If such a code becomes necessary, then the registration authority for ISO 3166 SHOULD first be petitioned to assign a code to the region. If the petition for a code assignment by ISO 3166 is refused or not acted on in a timely manner, the registration process described in MAY then be used to register the corresponding UN M.49 code. At the time this document was written, there were only four such codes: 830 (Channel Islands), 831 (Guernsey), 832 (Jersey), and 833 (Isle of Man). This way UN M.49 codes remain available as the value of last resort in cases where ISO 3166 reassigns a deprecated value in the registry. 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: 2005?7?12? 7:00 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) > > Addison Phillips scripsit: > > > If it becomes necessary to > > identify a region for which only a UN M.49 code exists in language tags, > > then the registration authority for ISO 3166 SHOULD be petitioned to > > assign a code: such a code could then be registered for use in language > > tags. > > I think this "could" ==> SHOULD, or at the very least MAY. > > While I'm at it, in the 2005-7-11 draft: > > "could be included" in 3.4 ==> MAY; [Addison Phillips] -not a normative statement; it's an example > "might be interpreted", "could be taken", "could be regarded", "one > could write", "could be used" ==> MAY; [Addison Phillips] -examples all > "could be used" in 4.5 ==> MAY; [Addison Phillips] +marginal case. (In case it isn't clear, my comments with - are rejects and + are where I made the change.) > "cannot" in 2.2.3 ==> MUST NOT; [Addison Phillips] -another example > "can" in 2.2.4 ==> MAY; [Addison Phillips] -explanatory text which should not be normative. Here's what it says: Their syntax is described here so that implementations can be compatible with any future revision of this document which does provide for their registration. > "cannot" in 2.2.6 items 1 and 3 ==> MUST NOT; [Addison Phillips] +the first one -the second one: it is in a sentence that explains the sentence before it (which is normative) > "can be split" and "can use the registry" in 3.1 ==> MAY; [Addison Phillips] -the first one: too pedantic -the second one: this is explaining something that is possible, not a normative restriction. > "can raise objections" in 3.4 ==> MAY; [Addison Phillips] +this should be normative > "can be registered" in 3.5 ==> MAY; [Addison Phillips] +this should be normative > "can only give possible examples" in 4.2 needs no modal, and > ==> "gives only possible examples"; [Addison Phillips] +although this is the original RFC 3066 text > "can use" in 7 ==> MAY; [Addison Phillips] -not really normative; could change this to "sometimes use" > "ought not" in 4.1 ==> SHOULD NOT; [Addison Phillips] -explanatory text > "will" in 2.2.1 item 5 ==> SHOULD or perhaps MUST; [Addison Phillips] -unnecessary: this is discussing the likely attitude of ietf-languages towards primary language subtag registrations. > "will not be added" in 2.2.1 ==> MUST NOT; [Addison Phillips] +this should be normative > "will maintain" in 2.2.8 ==> MUST; [Addison Phillips] +/-Hmm... this sentence is a bit mushy, since it implies that IANA will be actively maintaining these particular registry entries, which is not actually correct. Changed from: -- IANA will maintain these tags in the registry under either the "grandfathered" or "redundant" type. -- To: -- These tags will be maintained in the registry in records of either the "grandfathered" or "redundant" type. -- > "will be maintained" in 3 ==> MUST; [Addison Phillips] -shouldn't be normative, although the sentence isn't very elegant > "will consist" in 3.1 ==> MUST; [Addison Phillips] -shouldn't be normative. Did change tense to 'consists' > "no registration records will be maintained" in 3.1 ==> > "registration records MUST NOT be maintained"; [Addison Phillips] -shouldn't be normative. > "will be in a modified" in 3.1 ==> MUST; [Addison Phillips] +/-changed from future to present tense, but not turned into a MUST. This section describes the registry and its format. All of the initialization and maintenance instructions use normative language that references this section. Littering this section with MUSTs will make it difficult to read and not add to the clarity of it. > "will evaluate" in 3.2 ==> MUST; [Addison Phillips] +changed > "no new entries will be added and none of the entries will be > removed" > in 3.2 ==> "new entries MUST NOT be added or removed"; [Addison Phillips] +changed to: new entries in this section MUST NOT be added and existing entries MUST NOT be removed > "will be maintained" in 3.4 ==> MUST; [Addison Phillips] -/+ changed to "exists" > "No subtags will be registered" in 3.5 ==> "Subtags MUST NOT > be registered"; [Addison Phillips] +changed > TYPO: "will lend" in 3.6 ==> "will tend"; [Addison Phillips] Not a typo. Here's the sentence: In addition, defining a mechanism for maintaining single-letter subtags will lend to the stability of this document by reducing the likely need for future revisions or updates. > "will use" and "will forward" in 3.6 ==> MUST; [Addison Phillips] +first one +second one > "will be initialized", "will be relabeled", "will be limited", and > "will be sent" in 5.1 ==> MUST; [Addison Phillips] -first one +second one +third one > "will include" in 5.2 ==> MUST; [Addison Phillips] +changed > "will continue" in 8 ==> SHOULD; [Addison Phillips] -not necessary (describes user's or application's choice of language tags) > > Some of these changes may be inappropriate because of the broader context; > I haven't fully investigated. > > -- > 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 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 17:08:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsRzY-0005af-4e; Tue, 12 Jul 2005 17: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 1DsRzW-0005aN-8N for ltru@megatron.ietf.org; Tue, 12 Jul 2005 17:08:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02537 for ; Tue, 12 Jul 2005 17:08:31 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsSRl-00085T-LI for ltru@ietf.org; Tue, 12 Jul 2005 17:37:47 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 14:08:22 -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, 12 Jul 2005 14:08:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes Date: Tue, 12 Jul 2005 14:08:21 -0700 Message-ID: Thread-Topic: [Ltru] Jersey JE and Guernsey GG Country Codes Thread-Index: AcWHAXdNDNA5oUjvRQCYkUiS5TvExwAI9AGA From: "Peter Constable" To: "Debbie Garside" , X-OriginalArrivalTime: 12 Jul 2005 21:08:21.0678 (UTC) FILETIME=[D59504E0:01C58725] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 DIN is no longer the Maintenance Agency for ISO 3166; the MA is ISO Central Secretariat. FYI, from their FAQ: 02: What is the procedure for adding new country names and codes to ISO 3166-1? A: New names and codes are added when the United Nations publish new names in either their Terminology Bulletin Country Names or in the Country and Region Codes for Statistical Use maintained by the United Nations Statistics Division. There is no other way of having new country names included in ISO 3166-1. So if a name is not on these lists it will not get into ISO 3166-1.=20 Cf. http://www.iso.ch/iso/en/prods-services/iso3166ma/index.html=20 Peter Constable > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Debbie Garside > Sent: Tuesday, July 12, 2005 9:48 AM > To: ltru@ietf.org > Subject: [Ltru] Jersey JE and Guernsey GG Country Codes >=20 > FYI >=20 > There is an official proposal, endorsed by UK government to adopt these > codes and it should be available on Friday for submission to DIN via BSI. >=20 > Kind regards >=20 > Debbie Garside >=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 Jul 12 17:23:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSDz-0008Ng-VE; Tue, 12 Jul 2005 17: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 1DsSDy-0008KR-7y for ltru@megatron.ietf.org; Tue, 12 Jul 2005 17:23:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10202 for ; Tue, 12 Jul 2005 17:23:27 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsSgB-0002TC-9V for ltru@ietf.org; Tue, 12 Jul 2005 17:52:40 -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 j6CLN7M7451616 for ; Tue, 12 Jul 2005 17:23:07 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j6CLN7vb217266 for ; Tue, 12 Jul 2005 15:23:07 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j6CLN78m007598 for ; Tue, 12 Jul 2005 15:23:07 -0600 Received: from markdavis (sig-9-48-113-155.mts.ibm.com [9.48.113.155]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j6CLN5jD007523; Tue, 12 Jul 2005 15:23:07 -0600 Message-ID: <028101c58727$e3a346d0$6501a8c0@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , References: <634978A7DF025A40BFEF33EB191E13BC0C1092A4@irvmbxw01.quest.com> <006c01c5871c$c00ae260$7f1afea9@oemcomputer> Subject: Re: [Ltru] Adding more 2119 keywords (was: Re: Finishing off #1026) Date: Tue, 12 Jul 2005 14:23:03 -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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j6CLN7M7451616 X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 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've looked them over, and I don't think any rise to the level that there will be a misunderstanding in what is required for interoperation or limi= ted harmful behavior. So my vote would be to belay these to the next version (and ask John to do his next review before last call ;-) =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: Sent: Tuesday, July 12, 2005 13:03 Subject: [Ltru] Adding more 2119 keywords (was: Re: Finishing off #1026) > Hi - > > Both as an individual contributor and as a co-chair, I'd like to remind everyone > of the guidance RFC 2119 gives in the use of these keywords: > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) > > Since we are in working group last call, I'd like all concerned to consider > carefully whether each proposed change of this type is actually > *necessary*. If it is, fine. Necessary fixes should be taken care of. > If the proposed keyword addition is not *necessary*, I suggest consider= ing > whether the value of making the change is worth the risk of the changes > cumulatively necessitating a second last call. > > Randy > > ----- Original Message -----=20 > From: "Addison Phillips" > To: "John.Cowan" > Cc: > Sent: Tuesday, July 12, 2005 9:45 AM > Subject: RE: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call= ?) > > > Notes below. > > Broadly, use of normative language represents a substantive change. Som= e of these were specifically changed from normative to > non-normative language previously. > > The other items I have gone through methodically, results interlinear below. > > The first item is moot. That paragraph was rewritten to address Frank's comments and I spent a good bit of editorial attention on > making it very clear and more rule-like. It now reads: > > UN M.49 has codes for both countries and areas (such as '276' for Germany) and geographical regions and sub-regions (such as > '150' for Europe). UN M.49 country or area codes for which there is no corresponding ISO 3166 code SHOULD NOT be registered, except > as a surrogate for an ISO 3166 code that is blocked from registration b= y an existing subtag. If such a code becomes necessary, then > the registration authority for ISO 3166 SHOULD first be petitioned to assign a code to the region. If the petition for a code > assignment by ISO 3166 is refused > or not acted on in a timely manner, the registration process described = in MAY then be used > to register the corresponding UN M.49 code. At the time this document w= as written, there were only four such codes: 830 (Channel > Islands), 831 (Guernsey), 832 (Jersey), and 833 (Isle of Man). This way= UN M.49 codes remain available as the value of last resort > in cases where ISO 3166 reassigns a deprecated value in the registry. > > 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: 2005?7?12? 7:00 > > To: Addison Phillips > > Cc: ltru@ietf.org > > Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) > > > > Addison Phillips scripsit: > > > > > If it becomes necessary to > > > identify a region for which only a UN M.49 code exists in language tags, > > > then the registration authority for ISO 3166 SHOULD be petitioned t= o > > > assign a code: such a code could then be registered for use in language > > > tags. > > > > I think this "could" =3D=3D> SHOULD, or at the very least MAY. > > > > While I'm at it, in the 2005-7-11 draft: > > > > "could be included" in 3.4 =3D=3D> MAY; > [Addison Phillips] > -not a normative statement; it's an example > > > "might be interpreted", "could be taken", "could be regarded", "one > > could write", "could be used" =3D=3D> MAY; > [Addison Phillips] > -examples all > > > "could be used" in 4.5 =3D=3D> MAY; > [Addison Phillips] > +marginal case. (In case it isn't clear, my comments with - are rejects and + are where I made the change.) > > > "cannot" in 2.2.3 =3D=3D> MUST NOT; > [Addison Phillips] > -another example > > > "can" in 2.2.4 =3D=3D> MAY; > [Addison Phillips] > > -explanatory text which should not be normative. Here's what it says: > > Their syntax is described here so that implementations can be compatibl= e with any future revision of this document which does > provide for their registration. > > > "cannot" in 2.2.6 items 1 and 3 =3D=3D> MUST NOT; > [Addison Phillips] > > +the first one > -the second one: it is in a sentence that explains the sentence before = it (which is normative) > > > "can be split" and "can use the registry" in 3.1 =3D=3D> MAY; > [Addison Phillips] > > -the first one: too pedantic > -the second one: this is explaining something that is possible, not a normative restriction. > > > "can raise objections" in 3.4 =3D=3D> MAY; > [Addison Phillips] > > +this should be normative > > > "can be registered" in 3.5 =3D=3D> MAY; > [Addison Phillips] > > +this should be normative > > > "can only give possible examples" in 4.2 needs no modal, and > > =3D=3D> "gives only possible examples"; > [Addison Phillips] > > +although this is the original RFC 3066 text > > > "can use" in 7 =3D=3D> MAY; > [Addison Phillips] > > -not really normative; could change this to "sometimes use" > > > "ought not" in 4.1 =3D=3D> SHOULD NOT; > [Addison Phillips] > > -explanatory text > > > "will" in 2.2.1 item 5 =3D=3D> SHOULD or perhaps MUST; > [Addison Phillips] > > -unnecessary: this is discussing the likely attitude of ietf-languages towards primary language subtag registrations. > > > "will not be added" in 2.2.1 =3D=3D> MUST NOT; > [Addison Phillips] > > +this should be normative > > > "will maintain" in 2.2.8 =3D=3D> MUST; > [Addison Phillips] > > +/-Hmm... this sentence is a bit mushy, since it implies that IANA will= be actively maintaining these particular registry entries, > which is not actually correct. Changed from: > > -- > IANA > will maintain these tags in the registry under either the "grandfathere= d" > or "redundant" type. > -- > > To: > > -- > These tags will be maintained in the registry in records of either the "grandfathered" or "redundant" type. > -- > > > "will be maintained" in 3 =3D=3D> MUST; > [Addison Phillips] > > -shouldn't be normative, although the sentence isn't very elegant > > > "will consist" in 3.1 =3D=3D> MUST; > [Addison Phillips] > > -shouldn't be normative. Did change tense to 'consists' > > > "no registration records will be maintained" in 3.1 =3D=3D> > > "registration records MUST NOT be maintained"; > [Addison Phillips] > > -shouldn't be normative. > > > "will be in a modified" in 3.1 =3D=3D> MUST; > [Addison Phillips] > > +/-changed from future to present tense, but not turned into a MUST. Th= is section describes the registry and its format. All of the > initialization and maintenance instructions use normative language that references this section. Littering this section with MUSTs > will make it difficult to read and not add to the clarity of it. > > > "will evaluate" in 3.2 =3D=3D> MUST; > [Addison Phillips] > > +changed > > > "no new entries will be added and none of the entries will be > > removed" > > in 3.2 =3D=3D> "new entries MUST NOT be added or removed"; > [Addison Phillips] > > +changed to: new entries in this section MUST NOT be added and existing entries MUST NOT be removed > > > "will be maintained" in 3.4 =3D=3D> MUST; > [Addison Phillips] > > -/+ changed to "exists" > > > "No subtags will be registered" in 3.5 =3D=3D> "Subtags MUST NOT > > be registered"; > [Addison Phillips] > > +changed > > > TYPO: "will lend" in 3.6 =3D=3D> "will tend"; > [Addison Phillips] > > Not a typo. Here's the sentence: > > In addition, > defining a mechanism for maintaining single-letter subtags will len= d to the > stability of this document by reducing the likely need for future revisions > or updates. > > > "will use" and "will forward" in 3.6 =3D=3D> MUST; > [Addison Phillips] > > +first one > +second one > > > "will be initialized", "will be relabeled", "will be limited", and > > "will be sent" in 5.1 =3D=3D> MUST; > [Addison Phillips] > > -first one > > +second one > > +third one > > > "will include" in 5.2 =3D=3D> MUST; > [Addison Phillips] > > +changed > > > "will continue" in 8 =3D=3D> SHOULD; > [Addison Phillips] > > -not necessary (describes user's or application's choice of language ta= gs) > > > > Some of these changes may be inappropriate because of the broader context; > > I haven't fully investigated. > > > > -- > > 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 extend= ed > > haiku) > > > _______________________________________________ > 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 Tue Jul 12 17:28:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSIU-0003SR-Uh; Tue, 12 Jul 2005 17:28:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSIT-0003RO-7u for ltru@megatron.ietf.org; Tue, 12 Jul 2005 17:28:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12657 for ; Tue, 12 Jul 2005 17:28:06 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsSkd-0003LZ-RU for ltru@ietf.org; Tue, 12 Jul 2005 17:57:21 -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 RELAYIN1-242d435cd1f; Tue, 12 Jul 2005 17:27:41 -0500 Received: from DEBHOME (ACD7B38E.ipt.aol.com [172.215.179.142]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j6CLRQ7O000601; Tue, 12 Jul 2005 17:27:31 -0400 Message-Id: <200507122127.j6CLRQ7O000601@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'Peter Constable'" , Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes Date: Tue, 12 Jul 2005 22:27: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 Thread-Index: AcWHAXdNDNA5oUjvRQCYkUiS5TvExwAI9AGAAACcNGA= 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: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Hmmmm.... I got this from the W3C site... "Excerpt from "How to get a country name into ISO 3166-1" http://www.din.de/gremien/nas/nabd/iso3166ma/get_name.html: III. A request for the inclusion of a country name (or the name of a dependent area) in ISO 3166-1 must originate from the national government of the country or from the national standards body of that country. The ISO 3166/MA rejects any request which is not accompanied by a written statement from the national goverment explicitly agreeing to and supporting the request." Can you give me a link to a registration application page? Cheers Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 12 July 2005 22:08 > To: Debbie Garside; ltru@ietf.org > Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes > > DIN is no longer the Maintenance Agency for ISO 3166; the MA is ISO > Central Secretariat. > > FYI, from their FAQ: > > 02: What is the procedure for adding new country names and codes to ISO > 3166-1? > A: New names and codes are added when the United Nations publish new > names in either their Terminology Bulletin Country Names or in the > Country and Region Codes for Statistical Use maintained by the United > Nations Statistics Division. There is no other way of having new country > names included in ISO 3166-1. So if a name is not on these lists it will > not get into ISO 3166-1. > > Cf. http://www.iso.ch/iso/en/prods-services/iso3166ma/index.html > > > > Peter Constable > > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > On Behalf Of > > Debbie Garside > > Sent: Tuesday, July 12, 2005 9:48 AM > > To: ltru@ietf.org > > Subject: [Ltru] Jersey JE and Guernsey GG Country Codes > > > > FYI > > > > There is an official proposal, endorsed by UK government to adopt > these > > codes and it should be available on Friday for submission to DIN via > BSI. > > > > Kind regards > > > > Debbie Garside > > > > > > _______________________________________________ > > 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 Jul 12 17:44:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSYZ-0002gy-Fz; Tue, 12 Jul 2005 17:44:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSYY-0002ge-5T for ltru@megatron.ietf.org; Tue, 12 Jul 2005 17:44:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20334 for ; Tue, 12 Jul 2005 17:44:43 -0400 (EDT) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsT0o-0006Dk-56 for ltru@ietf.org; Tue, 12 Jul 2005 18:14:00 -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 RELAYIN1-242d439bc306; Tue, 12 Jul 2005 17:44:28 -0500 Received: from DEBHOME (ACD7B38E.ipt.aol.com [172.215.179.142]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j6CLiPv9018403; Tue, 12 Jul 2005 17:44:25 -0400 Message-Id: <200507122144.j6CLiPv9018403@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Debbie Garside'" , "'Peter Constable'" , Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes Date: Tue, 12 Jul 2005 22:44:43 +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: AcWHAXdNDNA5oUjvRQCYkUiS5TvExwAI9AGAAACcNGAAALlt0A== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200507122127.j6CLRQ7O000601@smtp-los04.proxy.aol.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 So... are you telling me that I have to go back to Tony (Blair) and tell him his letter won't be necessary...? ;-) > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Debbie Garside > Sent: 12 July 2005 22:28 > To: 'Peter Constable'; ltru@ietf.org > Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes > > Hmmmm.... > > I got this from the W3C site... > > "Excerpt from "How to get a country name into ISO 3166-1" > http://www.din.de/gremien/nas/nabd/iso3166ma/get_name.html: > > III. A request for the inclusion of a country name (or the name of > a dependent area) in ISO 3166-1 must originate from the national > government of the country or from the national standards body > of that country. The ISO 3166/MA rejects any request which is > not accompanied by a written statement from the national goverment > explicitly agreeing to and supporting the request." > > Can you give me a link to a registration application page? > > Cheers > > Debbie > > > -----Original Message----- > > From: Peter Constable [mailto:petercon@microsoft.com] > > Sent: 12 July 2005 22:08 > > To: Debbie Garside; ltru@ietf.org > > Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes > > > > DIN is no longer the Maintenance Agency for ISO 3166; the MA is ISO > > Central Secretariat. > > > > FYI, from their FAQ: > > > > 02: What is the procedure for adding new country names and codes to ISO > > 3166-1? > > A: New names and codes are added when the United Nations publish new > > names in either their Terminology Bulletin Country Names or in the > > Country and Region Codes for Statistical Use maintained by the United > > Nations Statistics Division. There is no other way of having new country > > names included in ISO 3166-1. So if a name is not on these lists it will > > not get into ISO 3166-1. > > > > Cf. http://www.iso.ch/iso/en/prods-services/iso3166ma/index.html > > > > > > > > Peter Constable > > > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > > On Behalf Of > > > Debbie Garside > > > Sent: Tuesday, July 12, 2005 9:48 AM > > > To: ltru@ietf.org > > > Subject: [Ltru] Jersey JE and Guernsey GG Country Codes > > > > > > FYI > > > > > > There is an official proposal, endorsed by UK government to adopt > > these > > > codes and it should be available on Friday for submission to DIN via > > BSI. > > > > > > Kind regards > > > > > > Debbie Garside > > > > > > > > > _______________________________________________ > > > 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 Tue Jul 12 17:55:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSiq-00008z-8L; Tue, 12 Jul 2005 17:55:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSip-00008r-Ct for ltru@megatron.ietf.org; Tue, 12 Jul 2005 17:55: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 RAA21974 for ; Tue, 12 Jul 2005 17:55:18 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DsSiH-0001MX-DS for ltru@lists.ietf.org; Tue, 12 Jul 2005 23:54:49 +0200 Received: from 62.80.58.200 ([62.80.58.200]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Jul 2005 23:54:49 +0200 Received: from nobody by 62.80.58.200 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Jul 2005 23:54:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 12 Jul 2005 23:52:27 +0200 Organization: Lines: 12 Message-ID: <42D43B9B.2059@xyzzy.claranet.de> References: <200507121647.j6CGlpqw006242@smtp-los03.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: 62.80.58.200 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Jersey JE and Guernsey GG Country Codes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Debbie Garside wrote: > There is an official proposal, endorsed by UK government to > adopt these codes and it should be available on Friday for > submission [...] > via BSI. Great, let's hope that they don't forget IM while they're at it. Thanks for info, bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 18:00:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSo4-0005Kf-Gi; Tue, 12 Jul 2005 18:00:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSo2-0005Gx-U9 for ltru@megatron.ietf.org; Tue, 12 Jul 2005 18:00:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22457 for ; Tue, 12 Jul 2005 18:00: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.43) id 1DsTGK-00076k-3v for ltru@ietf.org; Tue, 12 Jul 2005 18:30:00 -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 Jul 2005 15:00:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Adding more 2119 keywords (was: Re: Finishing off #1026) Date: Tue, 12 Jul 2005 15:00:27 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C10950F@irvmbxw01.quest.com> Thread-Topic: [Ltru] Adding more 2119 keywords (was: Re: Finishing off #1026) Thread-Index: AcWHKTpR9ud5iKD4QuSvLjwhPuQeYwAA9ANA From: "Addison Phillips" To: "Mark Davis" , "Randy Presuhn" , X-OriginalArrivalTime: 12 Jul 2005 22:00:29.0831 (UTC) FILETIME=[1E1B4970:01C5872D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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="===============0720712810==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0720712810== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 KzENCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXphdGlvbiBBcmNoaXRlY3QsIFF1ZXN0 IFNvZnR3YXJlDQpDaGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBH cm91cA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KSXQgaXMgYW4g YXJjaGl0ZWN0dXJlLiANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBs dHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmcgW21haWx0bzpsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0 Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBNYXJrIERhdmlzDQo+IFNlbnQ6IDIwMDXlubQ35pyIMTLm l6UgMTQ6MjMNCj4gVG86IFJhbmR5IFByZXN1aG47IGx0cnVAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFtMdHJ1XSBBZGRpbmcgbW9yZSAyMTE5IGtleXdvcmRzICh3YXM6IFJlOiBGaW5pc2hpbmcg b2ZmDQo+ICMxMDI2KQ0KPiANCj4gSSd2ZSBsb29rZWQgdGhlbSBvdmVyLCBhbmQgSSBkb24ndCB0 aGluayBhbnkgcmlzZSB0byB0aGUgbGV2ZWwgdGhhdCB0aGVyZQ0KPiB3aWxsIGJlIGEgbWlzdW5k ZXJzdGFuZGluZyBpbiB3aGF0IGlzIHJlcXVpcmVkIGZvciBpbnRlcm9wZXJhdGlvbiBvcg0KPiBs aW1pdGVkDQo+IGhhcm1mdWwgYmVoYXZpb3IuIFNvIG15IHZvdGUgd291bGQgYmUgdG8gYmVsYXkg dGhlc2UgdG8gdGhlIG5leHQgdmVyc2lvbg0KPiAoYW5kIGFzayBKb2huIHRvIGRvIGhpcyBuZXh0 IHJldmlldyBiZWZvcmUgbGFzdCBjYWxsIDstKQ0KPiANCj4g4oCOTWFyaw0KPiANCj4gLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiUmFuZHkgUHJlc3VobiIgPHJhbmR5X3By ZXN1aG5AbWluZHNwcmluZy5jb20+DQo+IFRvOiA8bHRydUBpZXRmLm9yZz4NCj4gU2VudDogVHVl c2RheSwgSnVseSAxMiwgMjAwNSAxMzowMw0KPiBTdWJqZWN0OiBbTHRydV0gQWRkaW5nIG1vcmUg MjExOSBrZXl3b3JkcyAod2FzOiBSZTogRmluaXNoaW5nIG9mZiAjMTAyNikNCj4gDQo+IA0KPiA+ IEhpIC0NCj4gPg0KPiA+IEJvdGggYXMgYW4gaW5kaXZpZHVhbCBjb250cmlidXRvciBhbmQgYXMg YSBjby1jaGFpciwgSSdkIGxpa2UgdG8gcmVtaW5kDQo+IGV2ZXJ5b25lDQo+ID4gb2YgdGhlIGd1 aWRhbmNlIFJGQyAyMTE5IGdpdmVzIGluIHRoZSB1c2Ugb2YgdGhlc2Uga2V5d29yZHM6DQo+ID4N Cj4gPiAgICBJbXBlcmF0aXZlcyBvZiB0aGUgdHlwZSBkZWZpbmVkIGluIHRoaXMgbWVtbyBtdXN0 IGJlIHVzZWQgd2l0aCBjYXJlDQo+ID4gICAgYW5kIHNwYXJpbmdseS4gIEluIHBhcnRpY3VsYXIs IHRoZXkgTVVTVCBvbmx5IGJlIHVzZWQgd2hlcmUgaXQgaXMNCj4gPiAgICBhY3R1YWxseSByZXF1 aXJlZCBmb3IgaW50ZXJvcGVyYXRpb24gb3IgdG8gbGltaXQgYmVoYXZpb3Igd2hpY2ggaGFzDQo+ ID4gICAgcG90ZW50aWFsIGZvciBjYXVzaW5nIGhhcm0gKGUuZy4sIGxpbWl0aW5nIHJldHJhbnNt aXNzc2lvbnMpDQo+ID4NCj4gPiBTaW5jZSB3ZSBhcmUgaW4gd29ya2luZyBncm91cCBsYXN0IGNh bGwsIEknZCBsaWtlIGFsbCBjb25jZXJuZWQgdG8NCj4gY29uc2lkZXINCj4gPiBjYXJlZnVsbHkg d2hldGhlciBlYWNoIHByb3Bvc2VkIGNoYW5nZSBvZiB0aGlzIHR5cGUgaXMgYWN0dWFsbHkNCj4g PiAqbmVjZXNzYXJ5Ki4gIElmIGl0IGlzLCBmaW5lLiAgTmVjZXNzYXJ5IGZpeGVzIHNob3VsZCBi ZSB0YWtlbiBjYXJlIG9mLg0KPiA+IElmIHRoZSBwcm9wb3NlZCBrZXl3b3JkIGFkZGl0aW9uIGlz IG5vdCAqbmVjZXNzYXJ5KiwgSSBzdWdnZXN0DQo+IGNvbnNpZGVyaW5nDQo+ID4gd2hldGhlciB0 aGUgdmFsdWUgb2YgbWFraW5nIHRoZSBjaGFuZ2UgaXMgd29ydGggdGhlIHJpc2sgb2YgdGhlIGNo YW5nZXMNCj4gPiBjdW11bGF0aXZlbHkgbmVjZXNzaXRhdGluZyBhIHNlY29uZCBsYXN0IGNhbGwu DQo+ID4NCj4gPiBSYW5keQ0KPiA+DQo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0K PiA+IEZyb206ICJBZGRpc29uIFBoaWxsaXBzIiA8YWRkaXNvbi5waGlsbGlwc0BxdWVzdC5jb20+ DQo+ID4gVG86ICJKb2huLkNvd2FuIiA8amNvd2FuQHJldXRlcnNoZWFsdGguY29tPg0KPiA+IENj OiA8bHRydUBpZXRmLm9yZz4NCj4gPiBTZW50OiBUdWVzZGF5LCBKdWx5IDEyLCAyMDA1IDk6NDUg QU0NCj4gPiBTdWJqZWN0OiBSRTogW0x0cnVdIFJlOiBGaW5pc2hpbmcgb2ZmICMxMDI2IChXYXM6 IFJlOiBzdGF0dXM/IGxhc3QgY2FsbD8pDQo+ID4NCj4gPg0KPiA+IE5vdGVzIGJlbG93Lg0KPiA+ DQo+ID4gQnJvYWRseSwgdXNlIG9mIG5vcm1hdGl2ZSBsYW5ndWFnZSByZXByZXNlbnRzIGEgc3Vi c3RhbnRpdmUgY2hhbmdlLiBTb21lDQo+IG9mIHRoZXNlIHdlcmUgc3BlY2lmaWNhbGx5IGNoYW5n ZWQgZnJvbSBub3JtYXRpdmUgdG8NCj4gPiBub24tbm9ybWF0aXZlIGxhbmd1YWdlIHByZXZpb3Vz bHkuDQo+ID4NCj4gPiBUaGUgb3RoZXIgaXRlbXMgSSBoYXZlIGdvbmUgdGhyb3VnaCBtZXRob2Rp Y2FsbHksIHJlc3VsdHMgaW50ZXJsaW5lYXINCj4gYmVsb3cuDQo+ID4NCj4gPiBUaGUgZmlyc3Qg aXRlbSBpcyBtb290LiBUaGF0IHBhcmFncmFwaCB3YXMgcmV3cml0dGVuIHRvIGFkZHJlc3MgRnJh bmsncw0KPiBjb21tZW50cyBhbmQgSSBzcGVudCBhIGdvb2QgYml0IG9mIGVkaXRvcmlhbCBhdHRl bnRpb24gb24NCj4gPiBtYWtpbmcgaXQgdmVyeSBjbGVhciBhbmQgbW9yZSBydWxlLWxpa2UuIEl0 IG5vdyByZWFkczoNCj4gPg0KPiA+IDx0PlVOIE0uNDkgaGFzIGNvZGVzIGZvciBib3RoIGNvdW50 cmllcyBhbmQgYXJlYXMgKHN1Y2ggYXMgJzI3NicgZm9yDQo+IEdlcm1hbnkpIGFuZCBnZW9ncmFw aGljYWwgcmVnaW9ucyBhbmQgc3ViLXJlZ2lvbnMgKHN1Y2ggYXMNCj4gPiAnMTUwJyBmb3IgRXVy b3BlKS4gVU4gTS40OSBjb3VudHJ5IG9yIGFyZWEgY29kZXMgZm9yIHdoaWNoIHRoZXJlIGlzIG5v DQo+IGNvcnJlc3BvbmRpbmcgSVNPIDMxNjYgY29kZSBTSE9VTEQgTk9UIGJlIHJlZ2lzdGVyZWQs IGV4Y2VwdA0KPiA+IGFzIGEgc3Vycm9nYXRlIGZvciBhbiBJU08gMzE2NiBjb2RlIHRoYXQgaXMg YmxvY2tlZCBmcm9tIHJlZ2lzdHJhdGlvbiBieQ0KPiBhbiBleGlzdGluZyBzdWJ0YWcuIElmIHN1 Y2ggYSBjb2RlIGJlY29tZXMgbmVjZXNzYXJ5LCB0aGVuDQo+ID4gdGhlIHJlZ2lzdHJhdGlvbiBh dXRob3JpdHkgZm9yIElTTyAzMTY2IFNIT1VMRCBmaXJzdCBiZSBwZXRpdGlvbmVkIHRvDQo+IGFz c2lnbiBhIGNvZGUgdG8gdGhlIHJlZ2lvbi4gSWYgdGhlIHBldGl0aW9uIGZvciBhIGNvZGUNCj4g PiBhc3NpZ25tZW50IGJ5IElTTyAzMTY2IGlzIHJlZnVzZWQNCj4gPiBvciBub3QgYWN0ZWQgb24g aW4gYSB0aW1lbHkgbWFubmVyLCB0aGUgcmVnaXN0cmF0aW9uIHByb2Nlc3MgZGVzY3JpYmVkDQo+ IGluDQo+IDx4cmVmIHRhcmdldD0icmVnaXN0cmF0aW9uUHJvYyI+PC94cmVmPiBNQVkgdGhlbiBi ZSB1c2VkDQo+ID4gdG8gcmVnaXN0ZXIgdGhlIGNvcnJlc3BvbmRpbmcgVU4gTS40OSBjb2RlLiBB dCB0aGUgdGltZSB0aGlzIGRvY3VtZW50DQo+IHdhcw0KPiB3cml0dGVuLCB0aGVyZSB3ZXJlIG9u bHkgZm91ciBzdWNoIGNvZGVzOiA4MzAgKENoYW5uZWwNCj4gPiBJc2xhbmRzKSwgODMxIChHdWVy bnNleSksIDgzMiAoSmVyc2V5KSwgYW5kIDgzMyAoSXNsZSBvZiBNYW4pLiBUaGlzIHdheQ0KPiBV Tg0KPiBNLjQ5IGNvZGVzIHJlbWFpbiBhdmFpbGFibGUgYXMgdGhlIHZhbHVlIG9mIGxhc3QgcmVz b3J0DQo+ID4gaW4gY2FzZXMgd2hlcmUgSVNPIDMxNjYgcmVhc3NpZ25zIGEgZGVwcmVjYXRlZCB2 YWx1ZSBpbiB0aGUNCj4gcmVnaXN0cnkuPC90Pg0KPiA+DQo+ID4gQWRkaXNvbiBQLiBQaGlsbGlw cw0KPiA+IEdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KPiA+IENoYWly LCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQo+ID4NCj4gPiBJ bnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3QgYSBmZWF0dXJlLg0KPiA+IEl0IGlzIGFuIGFyY2hp dGVjdHVyZS4NCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZy b206IEpvaG4uQ293YW4gW21haWx0bzpqY293YW5AcmV1dGVyc2hlYWx0aC5jb21dDQo+ID4gPiBT ZW50OiAyMDA1Pzc/MTI/IDc6MDANCj4gPiA+IFRvOiBBZGRpc29uIFBoaWxsaXBzDQo+ID4gPiBD YzogbHRydUBpZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtMdHJ1XSBSZTogRmluaXNoaW5n IG9mZiAjMTAyNiAoV2FzOiBSZTogc3RhdHVzPyBsYXN0DQo+IGNhbGw/KQ0KPiA+ID4NCj4gPiA+ IEFkZGlzb24gUGhpbGxpcHMgc2NyaXBzaXQ6DQo+ID4gPg0KPiA+ID4gPiBJZiBpdCBiZWNvbWVz IG5lY2Vzc2FyeSB0bw0KPiA+ID4gPiBpZGVudGlmeSBhIHJlZ2lvbiBmb3Igd2hpY2ggb25seSBh IFVOIE0uNDkgY29kZSBleGlzdHMgaW4gbGFuZ3VhZ2UNCj4gdGFncywNCj4gPiA+ID4gdGhlbiB0 aGUgcmVnaXN0cmF0aW9uIGF1dGhvcml0eSBmb3IgSVNPIDMxNjYgU0hPVUxEIGJlIHBldGl0aW9u ZWQgdG8NCj4gPiA+ID4gYXNzaWduIGEgY29kZTogc3VjaCBhIGNvZGUgY291bGQgdGhlbiBiZSBy ZWdpc3RlcmVkIGZvciB1c2UgaW4NCj4gbGFuZ3VhZ2UNCj4gPiA+ID4gdGFncy4NCj4gPiA+DQo+ ID4gPiBJIHRoaW5rIHRoaXMgImNvdWxkIiA9PT4gU0hPVUxELCBvciBhdCB0aGUgdmVyeSBsZWFz dCBNQVkuDQo+ID4gPg0KPiA+ID4gV2hpbGUgSSdtIGF0IGl0LCBpbiB0aGUgMjAwNS03LTExIGRy YWZ0Og0KPiA+ID4NCj4gPiA+ICJjb3VsZCBiZSBpbmNsdWRlZCIgaW4gMy40ID09PiBNQVk7DQo+ ID4gW0FkZGlzb24gUGhpbGxpcHNdDQo+ID4gLW5vdCBhIG5vcm1hdGl2ZSBzdGF0ZW1lbnQ7IGl0 J3MgYW4gZXhhbXBsZQ0KPiA+DQo+ID4gPiAibWlnaHQgYmUgaW50ZXJwcmV0ZWQiLCAiY291bGQg YmUgdGFrZW4iLCAiY291bGQgYmUgcmVnYXJkZWQiLCAib25lDQo+ID4gPiBjb3VsZCB3cml0ZSIs ICJjb3VsZCBiZSB1c2VkIiA9PT4gTUFZOw0KPiA+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiA+IC1l eGFtcGxlcyBhbGwNCj4gPg0KPiA+ID4gImNvdWxkIGJlIHVzZWQiIGluIDQuNSA9PT4gTUFZOw0K PiA+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiA+ICttYXJnaW5hbCBjYXNlLiAoSW4gY2FzZSBpdCBp c24ndCBjbGVhciwgbXkgY29tbWVudHMgd2l0aCAtIGFyZSByZWplY3RzDQo+IGFuZCArIGFyZSB3 aGVyZSBJIG1hZGUgdGhlIGNoYW5nZS4pDQo+ID4NCj4gPiA+ICJjYW5ub3QiIGluIDIuMi4zID09 PiBNVVNUIE5PVDsNCj4gPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gPiAtYW5vdGhlciBleGFtcGxl DQo+ID4NCj4gPiA+ICJjYW4iIGluIDIuMi40ID09PiBNQVk7DQo+ID4gW0FkZGlzb24gUGhpbGxp cHNdDQo+ID4NCj4gPiAtZXhwbGFuYXRvcnkgdGV4dCB3aGljaCBzaG91bGQgbm90IGJlIG5vcm1h dGl2ZS4gSGVyZSdzIHdoYXQgaXQgc2F5czoNCj4gPg0KPiA+IFRoZWlyIHN5bnRheCBpcyBkZXNj cmliZWQgaGVyZSBzbyB0aGF0IGltcGxlbWVudGF0aW9ucyBjYW4gYmUgY29tcGF0aWJsZQ0KPiB3 aXRoIGFueSBmdXR1cmUgcmV2aXNpb24gb2YgdGhpcyBkb2N1bWVudCB3aGljaCBkb2VzDQo+ID4g cHJvdmlkZSBmb3IgdGhlaXIgcmVnaXN0cmF0aW9uLg0KPiA+DQo+ID4gPiAiY2Fubm90IiBpbiAy LjIuNiBpdGVtcyAxIGFuZCAzID09PiBNVVNUIE5PVDsNCj4gPiBbQWRkaXNvbiBQaGlsbGlwc10N Cj4gPg0KPiA+ICt0aGUgZmlyc3Qgb25lDQo+ID4gLXRoZSBzZWNvbmQgb25lOiBpdCBpcyBpbiBh IHNlbnRlbmNlIHRoYXQgZXhwbGFpbnMgdGhlIHNlbnRlbmNlIGJlZm9yZQ0KPiBpdA0KPiAod2hp Y2ggaXMgbm9ybWF0aXZlKQ0KPiA+DQo+ID4gPiAiY2FuIGJlIHNwbGl0IiBhbmQgImNhbiB1c2Ug dGhlIHJlZ2lzdHJ5IiBpbiAzLjEgPT0+IE1BWTsNCj4gPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4g Pg0KPiA+IC10aGUgZmlyc3Qgb25lOiB0b28gcGVkYW50aWMNCj4gPiAtdGhlIHNlY29uZCBvbmU6 IHRoaXMgaXMgZXhwbGFpbmluZyBzb21ldGhpbmcgdGhhdCBpcyBwb3NzaWJsZSwgbm90IGENCj4g bm9ybWF0aXZlIHJlc3RyaWN0aW9uLg0KPiA+DQo+ID4gPiAiY2FuIHJhaXNlIG9iamVjdGlvbnMi IGluIDMuNCA9PT4gTUFZOw0KPiA+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID4gK3RoaXMg c2hvdWxkIGJlIG5vcm1hdGl2ZQ0KPiA+DQo+ID4gPiAiY2FuIGJlIHJlZ2lzdGVyZWQiIGluIDMu NSA9PT4gTUFZOw0KPiA+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID4gK3RoaXMgc2hvdWxk IGJlIG5vcm1hdGl2ZQ0KPiA+DQo+ID4gPiAiY2FuIG9ubHkgZ2l2ZSBwb3NzaWJsZSBleGFtcGxl cyIgaW4gNC4yIG5lZWRzIG5vIG1vZGFsLCBhbmQNCj4gPiA+ID09PiAiZ2l2ZXMgb25seSBwb3Nz aWJsZSBleGFtcGxlcyI7DQo+ID4gW0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPiArYWx0aG91 Z2ggdGhpcyBpcyB0aGUgb3JpZ2luYWwgUkZDIDMwNjYgdGV4dA0KPiA+DQo+ID4gPiAiY2FuIHVz ZSIgaW4gNyA9PT4gTUFZOw0KPiA+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID4gLW5vdCBy ZWFsbHkgbm9ybWF0aXZlOyBjb3VsZCBjaGFuZ2UgdGhpcyB0byAic29tZXRpbWVzIHVzZSINCj4g Pg0KPiA+ID4gIm91Z2h0IG5vdCIgaW4gNC4xID09PiBTSE9VTEQgTk9UOw0KPiA+IFtBZGRpc29u IFBoaWxsaXBzXQ0KPiA+DQo+ID4gLWV4cGxhbmF0b3J5IHRleHQNCj4gPg0KPiA+ID4gIndpbGwi IGluIDIuMi4xIGl0ZW0gNSA9PT4gU0hPVUxEIG9yIHBlcmhhcHMgTVVTVDsNCj4gPiBbQWRkaXNv biBQaGlsbGlwc10NCj4gPg0KPiA+IC11bm5lY2Vzc2FyeTogdGhpcyBpcyBkaXNjdXNzaW5nIHRo ZSBsaWtlbHkgYXR0aXR1ZGUgb2YgaWV0Zi1sYW5ndWFnZXMNCj4gdG93YXJkcyBwcmltYXJ5IGxh bmd1YWdlIHN1YnRhZyByZWdpc3RyYXRpb25zLg0KPiA+DQo+ID4gPiAid2lsbCBub3QgYmUgYWRk ZWQiIGluIDIuMi4xID09PiBNVVNUIE5PVDsNCj4gPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0K PiA+ICt0aGlzIHNob3VsZCBiZSBub3JtYXRpdmUNCj4gPg0KPiA+ID4gIndpbGwgbWFpbnRhaW4i IGluIDIuMi44ID09PiBNVVNUOw0KPiA+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID4gKy8t SG1tLi4uIHRoaXMgc2VudGVuY2UgaXMgYSBiaXQgbXVzaHksIHNpbmNlIGl0IGltcGxpZXMgdGhh dCBJQU5BIHdpbGwNCj4gYmUNCj4gYWN0aXZlbHkgbWFpbnRhaW5pbmcgdGhlc2UgcGFydGljdWxh ciByZWdpc3RyeSBlbnRyaWVzLA0KPiA+IHdoaWNoIGlzIG5vdCBhY3R1YWxseSBjb3JyZWN0LiBD aGFuZ2VkIGZyb206DQo+ID4NCj4gPiAtLQ0KPiA+IElBTkENCj4gPiB3aWxsIG1haW50YWluIHRo ZXNlIHRhZ3MgaW4gdGhlIHJlZ2lzdHJ5IHVuZGVyIGVpdGhlciB0aGUNCj4gImdyYW5kZmF0aGVy ZWQiDQo+ID4gb3IgInJlZHVuZGFudCIgdHlwZS4NCj4gPiAtLQ0KPiA+DQo+ID4gVG86DQo+ID4N Cj4gPiAtLQ0KPiA+IFRoZXNlIHRhZ3Mgd2lsbCBiZSBtYWludGFpbmVkIGluIHRoZSByZWdpc3Ry eSBpbiByZWNvcmRzIG9mIGVpdGhlciB0aGUNCj4gImdyYW5kZmF0aGVyZWQiIG9yICJyZWR1bmRh bnQiIHR5cGUuDQo+ID4gLS0NCj4gPg0KPiA+ID4gIndpbGwgYmUgbWFpbnRhaW5lZCIgaW4gMyA9 PT4gTVVTVDsNCj4gPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+IC1zaG91bGRuJ3QgYmUg bm9ybWF0aXZlLCBhbHRob3VnaCB0aGUgc2VudGVuY2UgaXNuJ3QgdmVyeSBlbGVnYW50DQo+ID4N Cj4gPiA+ICJ3aWxsIGNvbnNpc3QiIGluIDMuMSA9PT4gTVVTVDsNCj4gPiBbQWRkaXNvbiBQaGls bGlwc10NCj4gPg0KPiA+IC1zaG91bGRuJ3QgYmUgbm9ybWF0aXZlLiBEaWQgY2hhbmdlIHRlbnNl IHRvICdjb25zaXN0cycNCj4gPg0KPiA+ID4gIm5vIHJlZ2lzdHJhdGlvbiByZWNvcmRzIHdpbGwg YmUgbWFpbnRhaW5lZCIgaW4gMy4xID09Pg0KPiA+ID4gInJlZ2lzdHJhdGlvbiByZWNvcmRzIE1V U1QgTk9UIGJlIG1haW50YWluZWQiOw0KPiA+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID4g LXNob3VsZG4ndCBiZSBub3JtYXRpdmUuDQo+ID4NCj4gPiA+ICJ3aWxsIGJlIGluIGEgbW9kaWZp ZWQiIGluIDMuMSA9PT4gTVVTVDsNCj4gPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+ICsv LWNoYW5nZWQgZnJvbSBmdXR1cmUgdG8gcHJlc2VudCB0ZW5zZSwgYnV0IG5vdCB0dXJuZWQgaW50 byBhIE1VU1QuDQo+IFRoaXMNCj4gc2VjdGlvbiBkZXNjcmliZXMgdGhlIHJlZ2lzdHJ5IGFuZCBp dHMgZm9ybWF0LiBBbGwgb2YgdGhlDQo+ID4gaW5pdGlhbGl6YXRpb24gYW5kIG1haW50ZW5hbmNl IGluc3RydWN0aW9ucyB1c2Ugbm9ybWF0aXZlIGxhbmd1YWdlIHRoYXQNCj4gcmVmZXJlbmNlcyB0 aGlzIHNlY3Rpb24uIExpdHRlcmluZyB0aGlzIHNlY3Rpb24gd2l0aCBNVVNUcw0KPiA+IHdpbGwg bWFrZSBpdCBkaWZmaWN1bHQgdG8gcmVhZCBhbmQgbm90IGFkZCB0byB0aGUgY2xhcml0eSBvZiBp dC4NCj4gPg0KPiA+ID4gIndpbGwgZXZhbHVhdGUiIGluIDMuMiA9PT4gTVVTVDsNCj4gPiBbQWRk aXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+ICtjaGFuZ2VkDQo+ID4NCj4gPiA+ICJubyBuZXcgZW50 cmllcyB3aWxsIGJlIGFkZGVkIGFuZCBub25lIG9mIHRoZSBlbnRyaWVzIHdpbGwgYmUNCj4gPiA+ IHJlbW92ZWQiDQo+ID4gPiBpbiAzLjIgPT0+ICJuZXcgZW50cmllcyBNVVNUIE5PVCBiZSBhZGRl ZCBvciByZW1vdmVkIjsNCj4gPiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+ICtjaGFuZ2Vk IHRvOiBuZXcgZW50cmllcyBpbiB0aGlzIHNlY3Rpb24gTVVTVCBOT1QgYmUgYWRkZWQgYW5kIGV4 aXN0aW5nDQo+IGVudHJpZXMgTVVTVCBOT1QgYmUgcmVtb3ZlZA0KPiA+DQo+ID4gPiAid2lsbCBi ZSBtYWludGFpbmVkIiBpbiAzLjQgPT0+IE1VU1Q7DQo+ID4gW0FkZGlzb24gUGhpbGxpcHNdDQo+ ID4NCj4gPiAtLysgY2hhbmdlZCB0byAiZXhpc3RzIg0KPiA+DQo+ID4gPiAiTm8gc3VidGFncyB3 aWxsIGJlIHJlZ2lzdGVyZWQiIGluIDMuNSA9PT4gIlN1YnRhZ3MgTVVTVCBOT1QNCj4gPiA+IGJl IHJlZ2lzdGVyZWQiOw0KPiA+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID4gK2NoYW5nZWQN Cj4gPg0KPiA+ID4gVFlQTzogIndpbGwgbGVuZCIgaW4gMy42ID09PiAid2lsbCB0ZW5kIjsNCj4g PiBbQWRkaXNvbiBQaGlsbGlwc10NCj4gPg0KPiA+IE5vdCBhIHR5cG8uIEhlcmUncyB0aGUgc2Vu dGVuY2U6DQo+ID4NCj4gPiBJbiBhZGRpdGlvbiwNCj4gPiAgICAgZGVmaW5pbmcgYSBtZWNoYW5p c20gZm9yIG1haW50YWluaW5nIHNpbmdsZS1sZXR0ZXIgc3VidGFncyB3aWxsIGxlbmQNCj4gdG8g dGhlDQo+ID4gICAgIHN0YWJpbGl0eSBvZiB0aGlzIGRvY3VtZW50IGJ5IHJlZHVjaW5nIHRoZSBs aWtlbHkgbmVlZCBmb3IgZnV0dXJlDQo+IHJldmlzaW9ucw0KPiA+ICAgICBvciB1cGRhdGVzLg0K PiA+DQo+ID4gPiAid2lsbCB1c2UiIGFuZCAid2lsbCBmb3J3YXJkIiBpbiAzLjYgPT0+IE1VU1Q7 DQo+ID4gW0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPiArZmlyc3Qgb25lDQo+ID4gK3NlY29u ZCBvbmUNCj4gPg0KPiA+ID4gIndpbGwgYmUgaW5pdGlhbGl6ZWQiLCAid2lsbCBiZSByZWxhYmVs ZWQiLCAid2lsbCBiZSBsaW1pdGVkIiwgYW5kDQo+ID4gPiAid2lsbCBiZSBzZW50IiBpbiA1LjEg PT0+IE1VU1Q7DQo+ID4gW0FkZGlzb24gUGhpbGxpcHNdDQo+ID4NCj4gPiAtZmlyc3Qgb25lDQo+ ID4NCj4gPiArc2Vjb25kIG9uZQ0KPiA+DQo+ID4gK3RoaXJkIG9uZQ0KPiA+DQo+ID4gPiAid2ls bCBpbmNsdWRlIiBpbiA1LjIgPT0+IE1VU1Q7DQo+ID4gW0FkZGlzb24gUGhpbGxpcHNdDQo+ID4N Cj4gPiArY2hhbmdlZA0KPiA+DQo+ID4gPiAid2lsbCBjb250aW51ZSIgaW4gOCA9PT4gU0hPVUxE Ow0KPiA+IFtBZGRpc29uIFBoaWxsaXBzXQ0KPiA+DQo+ID4gLW5vdCBuZWNlc3NhcnkgKGRlc2Ny aWJlcyB1c2VyJ3Mgb3IgYXBwbGljYXRpb24ncyBjaG9pY2Ugb2YgbGFuZ3VhZ2UNCj4gdGFncykN Cj4gPiA+DQo+ID4gPiBTb21lIG9mIHRoZXNlIGNoYW5nZXMgbWF5IGJlIGluYXBwcm9wcmlhdGUg YmVjYXVzZSBvZiB0aGUgYnJvYWRlcg0KPiBjb250ZXh0Ow0KPiA+ID4gSSBoYXZlbid0IGZ1bGx5 IGludmVzdGlnYXRlZC4NCj4gPiA+DQo+ID4gPiAtLQ0KPiA+ID4gV2ludGVyOiAgTUlULCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSm9obiBDb3dhbg0KPiA+ID4gS2VpbywgSU5S SUEsDQo+IGpjb3dhbkByZXV0ZXJzaGVhbHRoLmNvbQ0KPiA+ID4gSXNzdWUgbG90cyBvZiBEcmFm dHMuDQo+IGh0dHA6Ly93d3cuY2NpbC5vcmcvfmNvd2FuDQo+ID4gPiBTbyBtdWNoIG1vcmUgdG8g dW5kZXJzdGFuZCENCj4gPiA+IGh0dHA6Ly93d3cucmV1dGVyc2hlYWx0aC5jb20NCj4gPiA+IE1p Z2h0IHNpbXBsaWNpdHkgcmV0dXJuPyAgICAgICAgICAgICAgICAgICAgICAgIChBICJ0YW5rYSIs IG9yDQo+IGV4dGVuZGVkDQo+ID4gPiBoYWlrdSkNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBMdHJ1IG1haWxpbmcgbGlz dA0KPiA+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sdHJ1DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEx0cnUgbWFpbGluZyBsaXN0 DQo+ID4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2x0cnUNCj4gPg0KPiA+DQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+ IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbHRydQ0KDQo= --===============0720712810== 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 --===============0720712810==-- From ltru-bounces@lists.ietf.org Tue Jul 12 18:02:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsSpw-0006sF-Kf; Tue, 12 Jul 2005 18: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 1DsSpv-0006no-1U for ltru@megatron.ietf.org; Tue, 12 Jul 2005 18:02:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22599 for ; Tue, 12 Jul 2005 18:02:40 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsTIC-0007AB-RM for ltru@ietf.org; Tue, 12 Jul 2005 18:31:57 -0400 Received: from smtp-los01.proxy.aol.com (smtp-los01.proxy.aol.com [195.93.24.40]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN3-442d43df52f7; Tue, 12 Jul 2005 18:02:29 -0500 Received: from DEBHOME (ACD7B38E.ipt.aol.com [172.215.179.142]) by smtp-los01.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j6CM2Hmt023011; Tue, 12 Jul 2005 18:02:23 -0400 Message-Id: <200507122202.j6CM2Hmt023011@smtp-los01.proxy.aol.com> From: "Debbie Garside" To: "'Frank Ellermann'" , Subject: RE: [Ltru] Re: Jersey JE and Guernsey GG Country Codes Date: Tue, 12 Jul 2005 23:02: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 Thread-Index: AcWHLNmpaFfspkfzQ0aJDwI721lVAQAABgYA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <42D43B9B.2059@xyzzy.claranet.de> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.40 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Yes... I am checking on that first thing in the morning! > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Frank Ellermann > Sent: 12 July 2005 22:52 > To: ltru@ietf.org > Subject: [Ltru] Re: Jersey JE and Guernsey GG Country Codes > > Debbie Garside wrote: > > > There is an official proposal, endorsed by UK government to > > adopt these codes and it should be available on Friday for > > submission > [...] > > via BSI. > > Great, let's hope that they don't forget IM while they're at it. > > Thanks for info, 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 Jul 12 18:49:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsTYl-0002sk-AY; Tue, 12 Jul 2005 18:49:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsTYj-0002oc-GE for ltru@megatron.ietf.org; Tue, 12 Jul 2005 18:49: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 SAA27304 for ; Tue, 12 Jul 2005 18:48:58 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DsTXk-0001LA-5c for ltru@lists.ietf.org; Wed, 13 Jul 2005 00:48:00 +0200 Received: from 62.80.58.200 ([62.80.58.200]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Jul 2005 00:48:00 +0200 Received: from nobody by 62.80.58.200 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Jul 2005 00:48:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 13 Jul 2005 00:31:58 +0200 Organization: Lines: 37 Message-ID: <42D444DE.64CC@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C1092A4@irvmbxw01.quest.com> <006c01c5871c$c00ae260$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: 62.80.58.200 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Adding more 2119 keywords X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: >| Imperatives of the type defined in this memo must be used >| with care and sparingly. In particular, they MUST only be >| used where it is actually required for interoperation or to >| limit behavior which has potential for causing harm ACK, can't say this often enough. If a standard says "xyz are letters", then it's unnecessary to replace it by "xyz NUST be letters" for some imaginary normative effect. The standard is normative without any 2119-keywords, unless it explicitly says "informative" (examples etc.). > I suggest considering whether the value of making the change > is worth the risk of the changes cumulatively necessitating > a second last call. So far I thought that an "internal last call" is something like a dress rehearsal, it's not really required, and it's also not necessary to repeat it. Mark wrote in his reply: | ask John to do his next review before last call ;-) Better we find any "bugs" now than somebody else later in the real "last call". But IMO using _no_ 2119-keywords where they are _not_ needed is no "bug", quite the contrary. BTW, in Brian mentioned the case of a draft standard (3596) obsoleting BCP 49 (3152), apparently that's possible: + Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 19:24:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsU7V-0006Oe-HE; Tue, 12 Jul 2005 19:24:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsU7U-0006Nb-Qe for ltru@megatron.ietf.org; Tue, 12 Jul 2005 19:24:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07447 for ; Tue, 12 Jul 2005 19:24:53 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsUZm-0004Aw-2J for ltru@ietf.org; Tue, 12 Jul 2005 19:54:11 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 16:24:45 -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, 12 Jul 2005 16:24:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes Date: Tue, 12 Jul 2005 16:24:44 -0700 Message-ID: Thread-Topic: [Ltru] Jersey JE and Guernsey GG Country Codes Thread-Index: AcWHAXdNDNA5oUjvRQCYkUiS5TvExwAI9AGAAACcNGAABBWUUA== From: "Peter Constable" To: "Debbie Garside" , X-OriginalArrivalTime: 12 Jul 2005 23:24:45.0581 (UTC) FILETIME=[E39183D0:01C58738] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > Hmmmm.... >=20 > I got this from the W3C site... Would you consult the French government to find out about traffic regulations in Wales? ISO 3166 is not maintained by W3C. I'm sure this was provided with good intentions to be helpful to users, but it's clearly a couple of years out of date -- it's been a while now since DIN gave up the role of MA. > Can you give me a link to a registration application page? I suggest you use the contact link on the page I pointed you to to find out what process BSI should pursue: > > Cf. http://www.iso.ch/iso/en/prods-services/iso3166ma/index.html=20 Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 19:42:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsUOU-0001rr-4r; Tue, 12 Jul 2005 19:42:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsUOS-0001rg-Vz for ltru@megatron.ietf.org; Tue, 12 Jul 2005 19:42:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08395 for ; Tue, 12 Jul 2005 19:42:26 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsUqd-0004ej-KD for ltru@ietf.org; Tue, 12 Jul 2005 20:11:43 -0400 Received: from smtp-los01.proxy.aol.com (smtp-los01.proxy.aol.com [195.93.24.40]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN9-a42d4555027a; Tue, 12 Jul 2005 19:42:08 -0500 Received: from DEBHOME (ACD7B38E.ipt.aol.com [172.215.179.142]) by smtp-los01.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j6CNg3R2005615; Tue, 12 Jul 2005 19:42:03 -0400 Message-Id: <200507122342.j6CNg3R2005615@smtp-los01.proxy.aol.com> From: "Debbie Garside" To: "'Peter Constable'" , Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes Date: Wed, 13 Jul 2005 00:42:22 +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: AcWHAXdNDNA5oUjvRQCYkUiS5TvExwAI9AGAAACcNGAABBWUUAAAotXA 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.40 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Thanks... I have already emailed ISO... I couldn't see any links to request forms/regsitration on their site. In the meantime if anyone knows registration procedures (and would like to direct me) it would greatly help as I am not a 3166 expert and am only actioning this as (unofficial) BSI liaison to this WG. Regards Debbie > -----Original Message----- > From: Peter Constable [mailto:petercon@microsoft.com] > Sent: 13 July 2005 00:25 > To: Debbie Garside; ltru@ietf.org > Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes > > > From: Debbie Garside [mailto:debbie@ictmarketing.co.uk] > > > > Hmmmm.... > > > > I got this from the W3C site... > > Would you consult the French government to find out about traffic > regulations in Wales? ISO 3166 is not maintained by W3C. I'm sure this > was provided with good intentions to be helpful to users, but it's > clearly a couple of years out of date -- it's been a while now since DIN > gave up the role of MA. > > > > Can you give me a link to a registration application page? > > I suggest you use the contact link on the page I pointed you to to find > out what process BSI should pursue: > > > > Cf. http://www.iso.ch/iso/en/prods-services/iso3166ma/index.html > > > > Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 19:50:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsUW0-00063w-Vi; Tue, 12 Jul 2005 19:50:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsUVz-0005xb-Ef for ltru@megatron.ietf.org; Tue, 12 Jul 2005 19:50:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08801 for ; Tue, 12 Jul 2005 19:50: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.43) id 1DsUyI-0004qq-1u for ltru@ietf.org; Tue, 12 Jul 2005 20:19:30 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 16:49: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] Re: Adding more 2119 keywords Date: Tue, 12 Jul 2005 16:49:58 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C10956D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Adding more 2119 keywords Thread-Index: AcWHNAMfO801AYBEQfKmlNuq268aVQACAJKw From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 12 Jul 2005 23:49:59.0125 (UTC) FILETIME=[69B60050:01C5873C] 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 Yeah, so look at the list I sent back of John's notes and somebody opine = whether I chose correctly. Reverting the semi-substantive changes is = still easy at this point (I tend to agree that none of the changes are = earth shattering, but do note that some of the items that I changed in = the editor's copy represent normative looking text that might be better = in a normative form, e.g. instructions to IANA in Section 5.1. 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?7?12? 15:32 > To: ltru@ietf.org > Subject: [Ltru] Re: Adding more 2119 keywords >=20 > Randy Presuhn wrote: >=20 > >| Imperatives of the type defined in this memo must be used > >| with care and sparingly. In particular, they MUST only be > >| used where it is actually required for interoperation or to > >| limit behavior which has potential for causing harm >=20 > ACK, can't say this often enough. If a standard says "xyz are > letters", then it's unnecessary to replace it by "xyz NUST be > letters" for some imaginary normative effect. The standard is > normative without any 2119-keywords, unless it explicitly says > "informative" (examples etc.). >=20 > > I suggest considering whether the value of making the change > > is worth the risk of the changes cumulatively necessitating > > a second last call. >=20 > So far I thought that an "internal last call" is something like > a dress rehearsal, it's not really required, and it's also not > necessary to repeat it. >=20 > Mark wrote in his reply: > | ask John to do his next review before last call ;-) >=20 > Better we find any "bugs" now than somebody else later in the > real "last call". But IMO using _no_ 2119-keywords where they > are _not_ needed is no "bug", quite the contrary. >=20 > BTW, in > Brian mentioned the case of a draft standard (3596) obsoleting > BCP 49 (3152), apparently that's possible: >=20 > + >=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 Jul 12 22:15:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsWmt-0005SL-0l; Tue, 12 Jul 2005 22:15:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsWmr-0005SG-FU for ltru@megatron.ietf.org; Tue, 12 Jul 2005 22:15:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17378 for ; Tue, 12 Jul 2005 22:15:47 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsXFA-0000cG-HI for ltru@ietf.org; Tue, 12 Jul 2005 22:45: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 j6D2FXjh005686; Tue, 12 Jul 2005 22:15:34 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 12 Jul 2005 22:15:33 -0400 Date: Tue, 12 Jul 2005 22:15:32 -0400 From: "John.Cowan" To: Frank Ellermann Subject: Re: [Ltru] Re: Adding more 2119 keywords Message-ID: <20050713021532.GA3180@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0C1092A4@irvmbxw01.quest.com> <006c01c5871c$c00ae260$7f1afea9@oemcomputer> <42D444DE.64CC@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42D444DE.64CC@xyzzy.claranet.de> User-Agent: Mutt/1.4.2.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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > Mark wrote in his reply: > | ask John to do his next review before last call ;-) > > Better we find any "bugs" now than somebody else later in the > real "last call". Exactly. For the record, when I posted that, I didn't yet know we were in last-call status. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan If a soldier is asked why he kills people who have done him no harm, or a terrorist why he kills innocent people with his bombs, they can always reply that war has been declared, and there are no innocent people in an enemy country in wartime. The answer is psychotic, but it is the answer that humanity has given to every act of aggression in history. --Northrop Frye _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 22:30:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsX0d-0006p8-9E; Tue, 12 Jul 2005 22: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 1DsX0b-0006oS-U9 for ltru@megatron.ietf.org; Tue, 12 Jul 2005 22:30:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18017 for ; Tue, 12 Jul 2005 22:30:00 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsXSw-00011c-4h for ltru@ietf.org; Tue, 12 Jul 2005 22:59: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 j6D2TlMX005733; Tue, 12 Jul 2005 22:29:50 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 12 Jul 2005 22:29:47 -0400 Date: Tue, 12 Jul 2005 22:29:47 -0400 From: "John.Cowan" To: Addison Phillips Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Message-ID: <20050713022947.GC3180@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0C1092A4@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C1092A4@irvmbxw01.quest.com> User-Agent: Mutt/1.4.2.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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips scripsit: > Notes below. These all look fine to me, except: > > TYPO: "will lend" in 3.6 ==> "will tend"; > [Addison Phillips] > > Not a typo. Here's the sentence: > > In addition, > defining a mechanism for maintaining single-letter subtags will lend to the > stability of this document by reducing the likely need for future revisions > or updates. "Lend" without a direct object is unidiomatic. I think you want "will lend stability to this document". -- 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/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 22:48:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXI0-0007mX-Mt; Tue, 12 Jul 2005 22: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 1DsXHy-0007ii-ND for ltru@megatron.ietf.org; Tue, 12 Jul 2005 22:47: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 WAA18886 for ; Tue, 12 Jul 2005 22:47:56 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DsXHp-0001wL-NB for ltru@lists.ietf.org; Wed, 13 Jul 2005 04:47:49 +0200 Received: from 62.80.58.200 ([62.80.58.200]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Jul 2005 04:47:49 +0200 Received: from nobody by 62.80.58.200 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 13 Jul 2005 04:47:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 13 Jul 2005 04:46:05 +0200 Organization: Lines: 22 Message-ID: <42D4806D.C44@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C1092A4@irvmbxw01.quest.com> <006c01c5871c$c00ae260$7f1afea9@oemcomputer> <42D444DE.64CC@xyzzy.claranet.de> <20050713021532.GA3180@NYCMJCOWA2> 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.200 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Adding more 2119 keywords X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > when I posted that, I didn't yet know we were in last-call > status. Randy posted it in I just found the "secret script" for this part of the process: MUST and SHOULD: ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld32.htm ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld33.htm WG Last Call ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld35.htm ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld36.htm So we are at step 35 of 50, that's only 70% ;-) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 23:43:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsY9Z-0003Pc-O4; Tue, 12 Jul 2005 23:43:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsY9Y-0003PT-DP for ltru@megatron.ietf.org; Tue, 12 Jul 2005 23:43:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22457 for ; Tue, 12 Jul 2005 23:43:15 -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.43) id 1DsYbq-0003Lp-SZ for ltru@ietf.org; Wed, 13 Jul 2005 00:12:35 -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 Jul 2005 20:43:01 -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: Finishing off #1026 (Was: Re: status? last call?) Date: Tue, 12 Jul 2005 20:43:00 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C1095AB@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Finishing off #1026 (Was: Re: status? last call?) Thread-Index: AcWHUsZI2p6SV7cDSlSFl2gkr0qPTAACfTkQ From: "Addison Phillips" To: "John.Cowan" X-OriginalArrivalTime: 13 Jul 2005 03:43:01.0150 (UTC) FILETIME=[F7A5B3E0:01C5875C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 That's a better form for the sentence, and, as it is editorial in the = extreme, 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: John.Cowan [mailto:jcowan@reutershealth.com] > Sent: 2005?7?12? 19:30 > To: Addison Phillips > Cc: ltru@ietf.org > Subject: Re: [Ltru] Re: Finishing off #1026 (Was: Re: status? last = call?) >=20 > Addison Phillips scripsit: >=20 > > Notes below. >=20 > These all look fine to me, except: >=20 > > > TYPO: "will lend" in 3.6 =3D=3D> "will tend"; > > [Addison Phillips] > > > > Not a typo. Here's the sentence: > > > > In addition, > > defining a mechanism for maintaining single-letter subtags will = lend > to the > > stability of this document by reducing the likely need for = future > revisions > > or updates. >=20 > "Lend" without a direct object is unidiomatic. I think you want "will > lend stability to this document". >=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/~cowan _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 23:58:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYOJ-0003si-H2; Tue, 12 Jul 2005 23:58:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYOH-0003ry-GD for ltru@megatron.ietf.org; Tue, 12 Jul 2005 23:58:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23291 for ; Tue, 12 Jul 2005 23:58:31 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsYqb-0003lS-Dt for ltru@ietf.org; Wed, 13 Jul 2005 00:27:50 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DsYO7-0003MT-4M; Tue, 12 Jul 2005 20:58:23 -0700 Message-Id: <6.2.1.2.2.20050713021700.03fd1b80@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 13 Jul 2005 05:58:14 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags In-Reply-To: <003001c584c0$dd04e540$030aa8c0@DEWELL> References: <20050709160302.YPWK4366.mta6.adelphia.net@megatron.ietf.org> <003001c584c0$dd04e540$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 22:00 09/07/2005, Doug Ewell wrote: >In the interest of achieving consensus, I won't argue further about the >exact wording of this section. I do insist that private-use tags and >subtags in "x-" not be removed from the grammar, or proscribed entirely. >It MUST be legal for consenting adults to generate and interpret >"x-this" and "en-x-that" in the privacy of their homes. I think confusion exists here. No one has ever considered that x-tags were to be associated to adult extentions of a language. To the countrary one of the applications of the x-tags in the "en" context you quote is precisely to be able to use tags of the form of "en-x-kids" that could be made mandatory for partental protection on "kid.us" namespace for example. If there is a confusion by a common US reader here, I recommand that some examples are provided for further user guidance. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 23:58:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYOM-0003tI-Nr; Tue, 12 Jul 2005 23:58:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYOJ-0003sv-Mm for ltru@megatron.ietf.org; Tue, 12 Jul 2005 23:58:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23300 for ; Tue, 12 Jul 2005 23:58:33 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsYqe-0003lr-IT for ltru@ietf.org; Wed, 13 Jul 2005 00:27:52 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DsYOI-0003MT-2K; Tue, 12 Jul 2005 20:58:34 -0700 Message-Id: <6.2.1.2.2.20050713022329.0360b1b0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 13 Jul 2005 02:28:09 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags In-Reply-To: <000601c584c4$d0658de0$7f1afea9@oemcomputer> References: <20050709160302.YPWK4366.mta6.adelphia.net@megatron.ietf.org> <003001c584c0$dd04e540$030aa8c0@DEWELL> <000601c584c4$d0658de0$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 - afrac.org X-Spam-Score: 0.7 (/) 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 At 22:28 09/07/2005, Randy Presuhn wrote: >Hi - > > From: "Doug Ewell" > > To: "LTRU Working Group" > > Sent: Saturday, July 09, 2005 1:00 PM > > Subject: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private > Use Tags > > > > > In the interest of achieving consensus, I won't argue further about the > > exact wording of this section. I do insist that private-use tags and > > subtags in "x-" not be removed from the grammar, or proscribed entirely. > > It MUST be legal for consenting adults to generate and interpret > > "x-this" and "en-x-that" in the privacy of their homes. >... > >I think we're all agreed on that. Based on the discussion, I'll leave it to >the editors to pick appropriate words to reflect our rough consensus that >private use tags and subtags should remain in the document, but there should >be a "health warning" regarding the risks associated with using them. Several >alternative wordings have been offered, and I think the feedback on the >mailing >list will provide sufficient guidance to the editors to form text we can live >with. I am obliged to come back on this. If the editors are to form a text we can live with, I think we also could. And if cannot, we should make clear in a note, or through a consensus of this group, that it has never been considered that "x-" tags could ever have to do with pornography (or exclusion as some of comments I received during the ICANN meeting). >With that, I'll mark this issue resolved. If someone finds the words they >choose unacceptable, we can re-open the issue. I reopen the issue, not necessarily on the text itself but about the guidance given to the editor. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 23:58:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYOQ-0003vg-U9; Tue, 12 Jul 2005 23:58:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYON-0003uf-AM for ltru@megatron.ietf.org; Tue, 12 Jul 2005 23:58:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23308 for ; Tue, 12 Jul 2005 23:58:36 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsYqh-0003m2-BP for ltru@ietf.org; Wed, 13 Jul 2005 00:27:56 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DsYOJ-0003MT-JG; Tue, 12 Jul 2005 20:58:35 -0700 Message-Id: <6.2.1.2.2.20050713041029.03fca540@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 13 Jul 2005 04:11:43 +0200 To: "Addison Phillips" , "Frank Ellermann" , From: r&d afrac Subject: RE: [Ltru] Re: Finishing off #1026 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C108E6D@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C108E6D@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 - afrac.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 19:36 11/07/2005, Addison Phillips wrote: >I don't like the suggested edit. Instead I wordsmithed the paragraph thusly: > >UN M.49 has codes for both countries and areas (such as '276' for >Germany) and geographical regions and sub-regions (such as '150' for >Europe). UN M.49 country or area codes for which there is no corresponding >ISO 3166 code SHOULD NOT be registered, Sorry, but ISO 3166 are codes for names of countries. You cannot associate them with codes for countries. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 12 23:58:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYOR-0003w4-4U; Tue, 12 Jul 2005 23:58:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYOO-0003vR-I2 for ltru@megatron.ietf.org; Tue, 12 Jul 2005 23:58:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23312 for ; Tue, 12 Jul 2005 23:58:38 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsYqj-0003mA-2F for ltru@ietf.org; Wed, 13 Jul 2005 00:27:57 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DsYOM-0003MT-1W; Tue, 12 Jul 2005 20:58:38 -0700 Message-Id: <6.2.1.2.2.20050713043215.048b4eb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 13 Jul 2005 05:14:01 +0200 To: "Debbie Garside" , "'Debbie Garside'" , "'Peter Constable'" , From: r&d afrac Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes In-Reply-To: <200507122144.j6CLiPv9018403@smtp-los02.proxy.aol.com> References: <200507122127.j6CLRQ7O000601@smtp-los04.proxy.aol.com> <200507122144.j6CLiPv9018403@smtp-los02.proxy.aol.com> 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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 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="===============0843395266==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0843395266== Content-Type: multipart/alternative; boundary="=====================_19756628==.ALT" --=====================_19756628==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 23:44 12/07/2005, Debbie Garside wrote: >So... are you telling me that I have to go back to Tony (Blair) and tell him >his letter won't be necessary...? ;-) Debbie, ad-hominem! If Tony wants to discuss his position on the Jersey and Gernesey langtags, please have him joining this list. This may look as a troll. But it is not. It is a perfect example of the inadequation of IETF to address issues which are beyond its scope. Sometime, a langtag user will have a conflict between an IETF Internet defined conception and legal definition of Her Gacious Majesty Government. And will lose time, money, credibility, etc. due to that. The Draft will lose credibility. Hardly what the authors want. The Draft should start with the following warning (just after the Introduction): "The IANA is not in the business of deciding what is and what is not an appropriate correlation between a language, a script, a country and other cultural or human language elements as they may appear necessary. The selection of ISO 639 to obtain a language/script/country correlating table and rules was made with the knowldge that ISO has procedures to determine which resulting language tags should be and should not be on such a list. It happens that ISO 639 does not provide yet such a list. So, however the IANA is not in the business of deciding if this is a lack ISO still has to address or if it is a deliberated authoritative decision, the IANA intends to extend the possibilities offered to Internet protocols and applications users by RFC 3066. This Memo describes under which technical terms this may be done, notwithstanding the national or international legal limitations which may be imposed elsewhere to the users." "The IANA adheres to the language equal opportunity declaration: "The purpose of technology isn't to insure that everybody should have an equal opportunity whatever his language, its purpose is to allow this goal. "This document's aim is to allow everyone to freely share the cultural life of the Internet community, to enjoy using its solutions on an equal linguistic, cultural, technical, economical and commercial basis, and to share into the benefits of the technology and its advancements without distinction of any kind, such as race, colour, sex, language, religion, political or other opinion, national or social origin, property, birth or other status and education. Therefore the goal is to build a common technical standard for all people and all nations to be used or embedded in any technical solution, without any limitation resulting from the script, the language, the referent or the context of their technical environment. "Taking into account the granular nature and the diversity of the world's digital ecosystem as well as the requirements of its technical convergence, the authors of this technical memorandum strongly advocate its free, secure and stable implementation to serve the rights and freedoms of its users at an international, national and personal level, in the respect of sovereign laws and jurisdiction of each State, of the empowerment of local cultures, and of its intergovernance by subsidiarity in any of the public or private, community or individual contexts. " (text to be revised along with its review by the members of the global on-line community in preparation of the Tunis declaration) jfc > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > > Behalf Of Debbie Garside > > Sent: 12 July 2005 22:28 > > To: 'Peter Constable'; ltru@ietf.org > > Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes > > > > Hmmmm.... > > > > I got this from the W3C site... > > > > "Excerpt from "How to get a country name into ISO 3166-1" > > http://www.din.de/gremien/nas/nabd/iso3166ma/get_name.html: > > > > III. A request for the inclusion of a country name (or the name of > > a dependent area) in ISO 3166-1 must originate from the national > > government of the country or from the national standards body > > of that country. The ISO 3166/MA rejects any request which is > > not accompanied by a written statement from the national goverment > > explicitly agreeing to and supporting the request." > > > > Can you give me a link to a registration application page? > > > > Cheers > > > > Debbie > > > > > -----Original Message----- > > > From: Peter Constable [mailto:petercon@microsoft.com] > > > Sent: 12 July 2005 22:08 > > > To: Debbie Garside; ltru@ietf.org > > > Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes > > > > > > DIN is no longer the Maintenance Agency for ISO 3166; the MA is ISO > > > Central Secretariat. > > > > > > FYI, from their FAQ: > > > > > > 02: What is the procedure for adding new country names and codes to ISO > > > 3166-1? > > > A: New names and codes are added when the United Nations publish new > > > names in either their Terminology Bulletin Country Names or in the > > > Country and Region Codes for Statistical Use maintained by the United > > > Nations Statistics Division. There is no other way of having new country > > > names included in ISO 3166-1. So if a name is not on these lists it will > > > not get into ISO 3166-1. > > > > > > Cf. http://www.iso.ch/iso/en/prods-services/iso3166ma/index.html > > > > > > > > > > > > Peter Constable > > > > > > > > > > -----Original Message----- > > > > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] > > > On Behalf Of > > > > Debbie Garside > > > > Sent: Tuesday, July 12, 2005 9:48 AM > > > > To: ltru@ietf.org > > > > Subject: [Ltru] Jersey JE and Guernsey GG Country Codes > > > > > > > > FYI > > > > > > > > There is an official proposal, endorsed by UK government to adopt > > > these > > > > codes and it should be available on Friday for submission to DIN via > > > BSI. > > > > > > > > Kind regards > > > > > > > > Debbie Garside > > > > > > > > > > > > _______________________________________________ > > > > 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 --=====================_19756628==.ALT Content-Type: text/html; charset="us-ascii" At 23:44 12/07/2005, Debbie Garside wrote:
So... are you telling me that I have to go back to Tony (Blair) and tell him
his letter won't be necessary...?  ;-)

Debbie,
ad-hominem! If Tony wants to discuss his position on the Jersey and Gernesey langtags, please have him joining this list.

This may look as a troll. But it is not. It is a perfect example of the inadequation of IETF to address issues which are beyond its scope. Sometime, a langtag user will have a conflict between an IETF Internet defined conception and legal definition of Her Gacious Majesty Government. And will lose time, money, credibility, etc. due to that. The Draft will lose credibility. Hardly what the authors want.

The Draft should start with the following warning (just after the Introduction):

"The IANA is not in the business of deciding what is and what is not an appropriate correlation between a language, a script, a country and other cultural or human language elements as they may appear necessary. The selection of ISO 639 to obtain a language/script/country correlating table and rules was made with the knowldge that ISO has procedures to determine which resulting language tags should be and should not be on such a list. It happens that ISO 639 does not provide yet such a list. So, however the IANA is not in the business of deciding if this is a lack ISO still has to address or if it is a deliberated authoritative decision, the IANA intends to extend the possibilities offered to Internet protocols and applications users by RFC 3066. This Memo describes under which technical terms this may be done, notwithstanding the national or international legal limitations which may be imposed elsewhere to the users."

"The IANA adheres to the language equal opportunity declaration:

"The purpose of technology isn't to insure that everybody should have an equal opportunity whatever his language, its purpose is to allow this goal.

"This document's aim is to allow everyone to freely share the cultural life of the Internet community, to enjoy using its solutions on an equal linguistic, cultural, technical, economical and commercial basis, and to share into the benefits of the technology and its advancements without distinction of any kind, such as race, colour, sex, language, religion, political or other opinion, national or social origin, property, birth or other status and education. Therefore the goal is to build a common technical standard for all people and all nations to be used or embedded in any technical solution, without any limitation resulting from the script, the language, the referent or the context of their technical environment.

"Taking into account the granular nature and the diversity of the world's digital ecosystem as well as the requirements of its technical convergence, the authors of this technical memorandum strongly advocate its free, secure and stable implementation to serve the rights and freedoms of its users at an international, national and personal level, in the respect of sovereign laws and jurisdiction of each State, of the empowerment of local cultures, and of its intergovernance by subsidiarity in any of the public or private, community or individual contexts. "

(text to be revised along with its review by the members of the global on-line community in preparation of the Tunis declaration)

jfc


> -----Original Message-----
> From: ltru-bounces@lists.ietf.org [ mailto:ltru-bounces@lists.ietf.org] On
> Behalf Of Debbie Garside
> Sent: 12 July 2005 22:28
> To: 'Peter Constable'; ltru@ietf.org
> Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes
>
> Hmmmm....
>
> I got this from the W3C site...
>
> "Excerpt from "How to get a country name into ISO 3166-1"
> http://www.din.de/gremien/nas/nabd/iso3166ma/get_name.html:
>
> III. A request for the inclusion of a country name (or the name of
>      a dependent area) in ISO 3166-1 must originate from the national
>      government of the country or from the national standards body
>      of that country. The ISO 3166/MA rejects any request which is
>      not accompanied by a written statement from the national goverment
>      explicitly agreeing to and supporting the request."
>
> Can you give me a link to a registration application page?
>
> Cheers
>
> Debbie
>
> > -----Original Message-----
> > From: Peter Constable [ mailto:petercon@microsoft.com]
> > Sent: 12 July 2005 22:08
> > To: Debbie Garside; ltru@ietf.org
> > Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes
> >
> > DIN is no longer the Maintenance Agency for ISO 3166; the MA is ISO
> > Central Secretariat.
> >
> > FYI, from their FAQ:
> >
> > 02: What is the procedure for adding new country names and codes to ISO
> > 3166-1?
> > A: New names and codes are added when the United Nations publish new
> > names in either their Terminology Bulletin Country Names or in the
> > Country and Region Codes for Statistical Use maintained by the United
> > Nations Statistics Division. There is no other way of having new country
> > names included in ISO 3166-1. So if a name is not on these lists it will
> > not get into ISO 3166-1.
> >
> > Cf. http://www.iso.ch/iso/en/prods-services/iso3166ma/index.html
> >
> >
> >
> > Peter Constable
> >
> >
> > > -----Original Message-----
> > > From: ltru-bounces@lists.ietf.org [ mailto:ltru-bounces@lists.ietf.org]
> > On Behalf Of
> > > Debbie Garside
> > > Sent: Tuesday, July 12, 2005 9:48 AM
> > > To: ltru@ietf.org
> > > Subject: [Ltru] Jersey JE and Guernsey GG Country Codes
> > >
> > > FYI
> > >
> > > There is an official proposal, endorsed by UK government to adopt
> > these
> > > codes and it should be available on Friday for submission to DIN via
> > BSI.
> > >
> > > Kind regards
> > >
> > > Debbie Garside
> > >
> > >
> > > _______________________________________________
> > > 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
--=====================_19756628==.ALT-- --===============0843395266== 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 --===============0843395266==-- From ltru-bounces@lists.ietf.org Tue Jul 12 23:58:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYOR-0003wS-BG; Tue, 12 Jul 2005 23:58:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYOQ-0003vb-3k for ltru@megatron.ietf.org; Tue, 12 Jul 2005 23:58:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23315 for ; Tue, 12 Jul 2005 23:58:39 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsYql-0003mI-4N for ltru@ietf.org; Wed, 13 Jul 2005 00:27:59 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DsYOO-0003MT-Gz; Tue, 12 Jul 2005 20:58:40 -0700 Message-Id: <6.2.1.2.2.20050713051820.048b3680@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 13 Jul 2005 05:19:11 +0200 To: "Debbie Garside" , "'Peter Constable'" , From: r&d afrac Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes In-Reply-To: <200507122342.j6CNg3R2005615@smtp-los01.proxy.aol.com> References: <200507122342.j6CNg3R2005615@smtp-los01.proxy.aol.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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id XAA23315 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 01:42 13/07/2005, Debbie Garside wrote: >Thanks... I have already emailed ISO... I couldn't see any links to requ= est >forms/regsitration on their site. > >In the meantime if anyone knows registration procedures (and would like = to >direct me) it would greatly help as I am not a 3166 expert and am only >actioning this as (unofficial) BSI liaison to this WG. I suggest you mail to G=E9rard. He is the ultimate reference. However not= =20 involved in your update. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 00:24:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYna-0001ih-6A; Wed, 13 Jul 2005 00:24:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsYnY-0001ic-Pl for ltru@megatron.ietf.org; Wed, 13 Jul 2005 00:24:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24835 for ; Wed, 13 Jul 2005 00:24:38 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsZFt-0004Ux-W1 for ltru@ietf.org; Wed, 13 Jul 2005 00:53:58 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DsYnX-00011i-CW; Tue, 12 Jul 2005 21:24:39 -0700 Message-Id: <6.2.1.2.2.20050713052111.048e2ac0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 13 Jul 2005 06:24:30 +0200 To: Frank Ellermann From: r&d afrac Subject: Re: [Ltru] Re: Adding more 2119 keywords In-Reply-To: <42D4806D.C44@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C1092A4@irvmbxw01.quest.com> <006c01c5871c$c00ae260$7f1afea9@oemcomputer> <42D444DE.64CC@xyzzy.claranet.de> <20050713021532.GA3180@NYCMJCOWA2> <42D4806D.C44@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 - afrac.org 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 04:46 13/07/2005, Frank Ellermann said: >John.Cowan wrote: > > when I posted that, I didn't yet know we were in last-call > > status. > >Randy posted it in > > >I just found the "secret script" for this part of the process: > >MUST and SHOULD: > >ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld32.htm >ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld33.htm > >WG Last Call > >ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld35.htm >ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld36.htm > >So we are at step 35 of 50, that's only 70% ;-) Bye, Frank Frank, as you may note: "Document must be reviewed and actively supported by a significant number of people, including experts in all applicable areas ... or it should not be sent to the IESG. Silent does not mean consent during this phase". I do not think this is fully matched up to now. I accept there are experts in this WG on various applicable parts, and that I am one of them, focusing on OPES, DNS, IDN, ccTLDs, Common of Reference Centers, but there are certainly many other areas. A list would be useful. And I do not support the Document in its present form as a replacement of RFC 3066 but I accept it with comments as a complement of RFC 3066. Otherwise the we are to do is to review all the RFC quoting RFC 3066 and proactively making sure they are not adversely affected. Both is in theory and in the way they are used. "Document should be extensively reviewed both within the WG and across other areas". Due to the difference of point of view and the lack of common evaluation of the Charter, I consider myself as one of the "other areas". I will try as indicated before to provide a review before having to go on vacations. But I am certainly disappointed by the lack of Charter clean sheet study (cf. ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld24.htm ) I strongly recommand to consider this: ftp://ftp.ietf.org/ietf-online-proceedings/05mar/proceedings/slides/wgchair-0/sld23.htm jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 00:38:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsZ0t-0000ok-Jm; Wed, 13 Jul 2005 00:38:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsZ0s-0000oa-At for ltru@megatron.ietf.org; Wed, 13 Jul 2005 00:38:26 -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 AAA25522 for ; Wed, 13 Jul 2005 00:38:23 -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 <20050713043754.UIE29002.mta9.adelphia.net@DEWELL> for ; Wed, 13 Jul 2005 00:37:54 -0400 Message-ID: <006a01c58764$1ba98120$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050712213240.FGZY7505.edge5.adelphia.net@megatron.ietf.org> Date: Tue, 12 Jul 2005 21:34: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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Jersey JE and Guernsey GG Country Codes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > FYI, from their FAQ: > > 02: What is the procedure for adding new country names and codes to > ISO 3166-1? > A: New names and codes are added when the United Nations publish new > names in either their Terminology Bulletin Country Names or in the > Country and Region Codes for Statistical Use maintained by the United > Nations Statistics Division. There is no other way of having new > country names included in ISO 3166-1. So if a name is not on these > lists it will not get into ISO 3166-1. Having an entry in the UN list is necessary, but apparently not sufficient, since the MA reports that these codes must be requested through BSI. -- 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 Jul 13 00:51:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsZDv-0007TI-0q; Wed, 13 Jul 2005 00:51:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsZDr-0007Rt-2h for ltru@megatron.ietf.org; Wed, 13 Jul 2005 00:51:53 -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 AAA26155 for ; Wed, 13 Jul 2005 00:51:48 -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 <20050713045119.BEYL29002.mta9.adelphia.net@DEWELL> for ; Wed, 13 Jul 2005 00:51:19 -0400 Message-ID: <007c01c58765$eaf99900$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050712231536.YIWL32242.edge4.adelphia.net@megatron.ietf.org> Date: Tue, 12 Jul 2005 21:47: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 Cc: Subject: [Ltru] Re: Jersey JE and Guernsey GG Country Codes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Debbie Garside wrote: > So... are you telling me that I have to go back to Tony (Blair) and tell him > his letter won't be necessary...? ;-) Joseph Martinez from ISO 3166/MA told me these requests "would have to be coordinated with the British Standards Institution (BSI) and the relevant Government Departments in London." So if I were you, I'd have Tony go ahead and write his letter. I agree with Frank that IM should also be requested for Isle of Man as long as you are at 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 Jul 13 01:03:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsZPO-0003AS-Op; Wed, 13 Jul 2005 01:03:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsZPN-0003AH-C6 for ltru@megatron.ietf.org; Wed, 13 Jul 2005 01:03:45 -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 BAA26624 for ; Wed, 13 Jul 2005 01:03:44 -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 <20050713050313.NYCV24042.mta11.adelphia.net@DEWELL> for ; Wed, 13 Jul 2005 01:03:13 -0400 Message-ID: <008e01c58767$842ab5e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050713040219.NQXV23564.edge3.adelphia.net@megatron.ietf.org> Date: Tue, 12 Jul 2005 21:58: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 Cc: Subject: [Ltru] Re: Jersey JE and Guernsey GG Country Codes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: >> Hmmmm.... >> >> I got this from the W3C site... > > Would you consult the French government to find out about traffic > regulations in Wales? ISO 3166 is not maintained by W3C. I'm sure this > was provided with good intentions to be helpful to users, but it's > clearly a couple of years out of date -- it's been a while now since > DIN gave up the role of MA. In fairness, as much use as W3C makes of ISO standards, and as rigorously as they keep their pages up to date, it seems reasonable to assume that their pointer to ISO 3166/MA would be current. -- 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 Jul 13 01:23:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsZil-0003uA-JM; Wed, 13 Jul 2005 01:23:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsZij-0003u2-Q4 for ltru@megatron.ietf.org; Wed, 13 Jul 2005 01:23:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27704 for ; Wed, 13 Jul 2005 01:23:45 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsaB4-00069a-6U for ltru@ietf.org; Wed, 13 Jul 2005 01:53:03 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 22:20:16 -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, 12 Jul 2005 22:20:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: Jersey JE and Guernsey GG Country Codes Date: Tue, 12 Jul 2005 22:20:18 -0700 Message-ID: Thread-Topic: [Ltru] Re: Jersey JE and Guernsey GG Country Codes Thread-Index: AcWHaHeRqb76sIqgQlWgjU5XjcVSswAAedGg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 13 Jul 2005 05:20:15.0863 (UTC) FILETIME=[8D684070:01C5876A] 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 Doug Ewell > In fairness, as much use as W3C makes of ISO standards, and as > rigorously as they keep their pages up to date, it seems reasonable to > assume that their pointer to ISO 3166/MA would be current. Whatever might *seem* reasonable, it is clear that their pointer is at least a couple of years out of date. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 02:48:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsb2L-0003PT-5D; Wed, 13 Jul 2005 02:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsb2I-0003Nd-L9 for ltru@megatron.ietf.org; Wed, 13 Jul 2005 02:48:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07193 for ; Wed, 13 Jul 2005 02:48:01 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsbUd-0000Kx-I8 for ltru@ietf.org; Wed, 13 Jul 2005 03:17:20 -0400 Received: from h-68-166-189-211.snvacaid.dynamic.covad.net ([68.166.189.211] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dsb2D-0007Sh-00 for ltru@ietf.org; Wed, 13 Jul 2005 02:47:57 -0400 Message-ID: <007601c58777$695ba980$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050709160302.YPWK4366.mta6.adelphia.net@megatron.ietf.org><003001c584c0$dd04e540$030aa8c0@DEWELL> <6.2.1.2.2.20050713021700.03fd1b80@mail.afrac.org> Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe)Private Use Tags Date: Tue, 12 Jul 2005 23:51:26 -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: "r&d afrac" > To: "Doug Ewell" ; "LTRU Working Group" > Sent: Tuesday, July 12, 2005 8:58 PM > Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe)Private Use Tags > > At 22:00 09/07/2005, Doug Ewell wrote: > >In the interest of achieving consensus, I won't argue further about the > >exact wording of this section. I do insist that private-use tags and > >subtags in "x-" not be removed from the grammar, or proscribed entirely. > >It MUST be legal for consenting adults to generate and interpret > >"x-this" and "en-x-that" in the privacy of their homes. > > I think confusion exists here. No one has ever considered that x-tags were > to be associated to adult extentions of a language. To the countrary one of > the applications of the x-tags in the "en" context you quote is precisely > to be able to use tags of the form of "en-x-kids" that could be made > mandatory for partental protection on "kid.us" namespace for example. > > If there is a confusion by a common US reader here, I recommand that some > examples are provided for further user guidance. > jfc I trust that your response is as tongue-in-cheek as Doug's. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 02:56:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsbAj-0007t4-ID; Wed, 13 Jul 2005 02: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 1DsbAg-0007oc-Ts for ltru@megatron.ietf.org; Wed, 13 Jul 2005 02:56:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07724 for ; Wed, 13 Jul 2005 02:56:41 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsbd2-0000ch-VZ for ltru@ietf.org; Wed, 13 Jul 2005 03:26:01 -0400 Received: from h-68-166-189-211.snvacaid.dynamic.covad.net ([68.166.189.211] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DsbAf-0000wj-00 for ltru@ietf.org; Wed, 13 Jul 2005 02:56:41 -0400 Message-ID: <007701c58778$a25609a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050709160302.YPWK4366.mta6.adelphia.net@megatron.ietf.org> <003001c584c0$dd04e540$030aa8c0@DEWELL> <000601c584c4$d0658de0$7f1afea9@oemcomputer> <6.2.1.2.2.20050713022329.0360b1b0@mail.afrac.org> Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags Date: Wed, 13 Jul 2005 00:01:03 -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: 538aad3a3c4f01d8b6a6477ca4248793 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: "r&d afrac" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Tuesday, July 12, 2005 5:28 PM > Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags > > At 22:28 09/07/2005, Randy Presuhn wrote: > >Hi - > > > From: "Doug Ewell" > > > To: "LTRU Working Group" > > > Sent: Saturday, July 09, 2005 1:00 PM > > > Subject: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private > > Use Tags > > > > > > > > In the interest of achieving consensus, I won't argue further about the > > > exact wording of this section. I do insist that private-use tags and > > > subtags in "x-" not be removed from the grammar, or proscribed entirely. > > > It MUST be legal for consenting adults to generate and interpret > > > "x-this" and "en-x-that" in the privacy of their homes. > >... > > > >I think we're all agreed on that. Based on the discussion, I'll leave it to > >the editors to pick appropriate words to reflect our rough consensus that > >private use tags and subtags should remain in the document, but there should > >be a "health warning" regarding the risks associated with using them. Several > >alternative wordings have been offered, and I think the feedback on the > >mailing > >list will provide sufficient guidance to the editors to form text we can live > >with. > > I am obliged to come back on this. If the editors are to form a text we can > live with, I think we also could. And if cannot, we should make clear in a > note, or through a consensus of this group, that it has never been > considered that "x-" tags could ever have to do with pornography (or > exclusion as some of comments I received during the ICANN meeting). > > >With that, I'll mark this issue resolved. If someone finds the words they > >choose unacceptable, we can re-open the issue. > > I reopen the issue, not necessarily on the text itself but about the > guidance given to the editor. > jfc If you really believe issue #1061 needs to be re-opened, please identify the specific text in the draft you object to and the text you would propose in its place. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 03:06:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsbJv-0003tI-P5; Wed, 13 Jul 2005 03:06:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsbJs-0003tD-OL for ltru@megatron.ietf.org; Wed, 13 Jul 2005 03:06:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08288 for ; Wed, 13 Jul 2005 03:06:11 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsbmF-0000ym-6O for ltru@ietf.org; Wed, 13 Jul 2005 03:35:31 -0400 Received: from h-68-166-189-211.snvacaid.dynamic.covad.net ([68.166.189.211] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DsbJr-0002F0-00 for ltru@ietf.org; Wed, 13 Jul 2005 03:06:11 -0400 Message-ID: <008d01c58779$f5fe3f40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200507122127.j6CLRQ7O000601@smtp-los04.proxy.aol.com><200507122144.j6CLiPv9018403@smtp-los02.proxy.aol.com> <6.2.1.2.2.20050713043215.048b4eb0@mail.afrac.org> Date: Wed, 13 Jul 2005 00:10:25 -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: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: [Ltru] Proposed addition after introduction (was: Jersey JE and Guernsey GG Country Codes) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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'd like to get a hum on this proposed addition. Obviously it would need some work on spelling, grammar, punctuation, and other editorial details. I'm just interested in finding out whether the WG supports adding something that conveys the sense of the proposal. Please post to the ltru list whether you support or oppose the addition. Randy, ltru co-chair ----- Original Message ----- > From: "r&d afrac" > To: "Debbie Garside" ; "'Debbie Garside'" ; "'Peter Constable'" ; > Sent: Tuesday, July 12, 2005 8:14 PM > Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes > > At 23:44 12/07/2005, Debbie Garside wrote: > >So... are you telling me that I have to go back to Tony (Blair) and tell him > >his letter won't be necessary...? ;-) > > Debbie, > ad-hominem! If Tony wants to discuss his position on the Jersey and > Gernesey langtags, please have him joining this list. > > This may look as a troll. But it is not. It is a perfect example of the > inadequation of IETF to address issues which are beyond its scope. > Sometime, a langtag user will have a conflict between an IETF Internet > defined conception and legal definition of Her Gacious Majesty Government. > And will lose time, money, credibility, etc. due to that. The Draft will > lose credibility. Hardly what the authors want. > > The Draft should start with the following warning (just after the > Introduction): > > "The IANA is not in the business of deciding what is and what is not an > appropriate correlation between a language, a script, a country and other > cultural or human language elements as they may appear necessary. The > selection of ISO 639 to obtain a language/script/country correlating table > and rules was made with the knowldge that ISO has procedures to determine > which resulting language tags should be and should not be on such a list. > It happens that ISO 639 does not provide yet such a list. So, however the > IANA is not in the business of deciding if this is a lack ISO still has to > address or if it is a deliberated authoritative decision, the IANA intends > to extend the possibilities offered to Internet protocols and applications > users by RFC 3066. This Memo describes under which technical terms this may > be done, notwithstanding the national or international legal limitations > which may be imposed elsewhere to the users." > > "The IANA adheres to the language equal opportunity declaration: > > "The purpose of technology isn't to insure that everybody should have an > equal opportunity whatever his language, its purpose is to allow this goal. > > "This document's aim is to allow everyone to freely share the cultural life > of the Internet community, to enjoy using its solutions on an equal > linguistic, cultural, technical, economical and commercial basis, and to > share into the benefits of the technology and its advancements without > distinction of any kind, such as race, colour, sex, language, religion, > political or other opinion, national or social origin, property, birth or > other status and education. Therefore the goal is to build a common > technical standard for all people and all nations to be used or embedded in > any technical solution, without any limitation resulting from the script, > the language, the referent or the context of their technical environment. > > "Taking into account the granular nature and the diversity of the world's > digital ecosystem as well as the requirements of its technical convergence, > the authors of this technical memorandum strongly advocate its free, secure > and stable implementation to serve the rights and freedoms of its users at > an international, national and personal level, in the respect of sovereign > laws and jurisdiction of each State, of the empowerment of local cultures, > and of its intergovernance by subsidiarity in any of the public or private, > community or individual contexts. " > > (text to be revised along with its review by the members of the global > on-line community in preparation of the Tunis declaration) > > jfc ... _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 05:30:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsdZ8-0002DU-Kc; Wed, 13 Jul 2005 05:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsdZ7-0002Cq-3i for ltru@megatron.ietf.org; Wed, 13 Jul 2005 05:30:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19289 for ; Wed, 13 Jul 2005 05:30:03 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dse1R-0007gq-Bj for ltru@ietf.org; Wed, 13 Jul 2005 05:59:25 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Wed, 13 Jul 2005 02:29:34 -0700 Message-ID: <039601c5878d$6c832640$6501a8c0@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <200507122127.j6CLRQ7O000601@smtp-los04.proxy.aol.com><200507122144.j6CLiPv9018403@smtp-los02.proxy.aol.com><6.2.1.2.2.20050713043215.048b4eb0@mail.afrac.org> <008d01c58779$f5fe3f40$7f1afea9@oemcomputer> Subject: Re: [Ltru] Proposed addition after introduction (was: Jersey JE andGuernsey GG Country Codes) Date: Wed, 13 Jul 2005 02:29: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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA19289 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 Oppose. It would be bizarre for IANA to have a proclamation of its approa= ch to "sharing the cultural life of the Internet community" in an RFC. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: Sent: Wednesday, July 13, 2005 00:10 Subject: [Ltru] Proposed addition after introduction (was: Jersey JE andGuernsey GG Country Codes) > Hi - > > I'd like to get a hum on this proposed addition. Obviously it would ne= ed some > work on spelling, grammar, punctuation, and other editorial details. I= 'm just > interested in finding out whether the WG supports adding something that conveys > the sense of the proposal. > > Please post to the ltru list whether you support or oppose the addition. > > Randy, ltru co-chair > > ----- Original Message -----=20 > > From: "r&d afrac" > > To: "Debbie Garside" ; "'Debbie Garside'" ; "'Peter Constable'" > ; > > Sent: Tuesday, July 12, 2005 8:14 PM > > Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes > > > > > At 23:44 12/07/2005, Debbie Garside wrote: > > >So... are you telling me that I have to go back to Tony (Blair) and tell him > > >his letter won't be necessary...? ;-) > > > > Debbie, > > ad-hominem! If Tony wants to discuss his position on the Jersey and > > Gernesey langtags, please have him joining this list. > > > > This may look as a troll. But it is not. It is a perfect example of t= he > > inadequation of IETF to address issues which are beyond its scope. > > Sometime, a langtag user will have a conflict between an IETF Interne= t > > defined conception and legal definition of Her Gacious Majesty Government. > > And will lose time, money, credibility, etc. due to that. The Draft w= ill > > lose credibility. Hardly what the authors want. > > > > The Draft should start with the following warning (just after the > > Introduction): > > > > "The IANA is not in the business of deciding what is and what is not = an > > appropriate correlation between a language, a script, a country and other > > cultural or human language elements as they may appear necessary. The > > selection of ISO 639 to obtain a language/script/country correlating table > > and rules was made with the knowldge that ISO has procedures to determine > > which resulting language tags should be and should not be on such a list. > > It happens that ISO 639 does not provide yet such a list. So, however the > > IANA is not in the business of deciding if this is a lack ISO still h= as to > > address or if it is a deliberated authoritative decision, the IANA intends > > to extend the possibilities offered to Internet protocols and applications > > users by RFC 3066. This Memo describes under which technical terms th= is may > > be done, notwithstanding the national or international legal limitati= ons > > which may be imposed elsewhere to the users." > > > > "The IANA adheres to the language equal opportunity declaration: > > > > "The purpose of technology isn't to insure that everybody should have= an > > equal opportunity whatever his language, its purpose is to allow this goal. > > > > "This document's aim is to allow everyone to freely share the cultura= l life > > of the Internet community, to enjoy using its solutions on an equal > > linguistic, cultural, technical, economical and commercial basis, and= to > > share into the benefits of the technology and its advancements withou= t > > distinction of any kind, such as race, colour, sex, language, religio= n, > > political or other opinion, national or social origin, property, birt= h or > > other status and education. Therefore the goal is to build a common > > technical standard for all people and all nations to be used or embed= ded in > > any technical solution, without any limitation resulting from the script, > > the language, the referent or the context of their technical environment. > > > > "Taking into account the granular nature and the diversity of the world's > > digital ecosystem as well as the requirements of its technical convergence, > > the authors of this technical memorandum strongly advocate its free, secure > > and stable implementation to serve the rights and freedoms of its use= rs at > > an international, national and personal level, in the respect of sovereign > > laws and jurisdiction of each State, of the empowerment of local cultures, > > and of its intergovernance by subsidiarity in any of the public or private, > > community or individual contexts. " > > > > (text to be revised along with its review by the members of the globa= l > > on-line community in preparation of the Tunis declaration) > > > > 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 Wed Jul 13 05:42:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsdl6-00065F-TM; Wed, 13 Jul 2005 05:42:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsdl5-000657-8K for ltru@megatron.ietf.org; Wed, 13 Jul 2005 05:42:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21321 for ; Wed, 13 Jul 2005 05:42:25 -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.43) id 1DseDR-0000Ar-0k for ltru@ietf.org; Wed, 13 Jul 2005 06:11:47 -0400 Received: from eupig1 (unverified) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Wed, 13 Jul 2005 09:43:31 +0000 Message-ID: Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IJK005QK8A0T7@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Wed, 13 Jul 2005 09:42:00 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Wed, 13 Jul 2005 10:41:59 +0100 Date: Wed, 13 Jul 2005 10:41:57 +0100 From: Misha Wolf Subject: RE: [Ltru] Proposed addition after introduction (was: Jersey JEandGuernsey GG Country Codes) To: LTRU Working Group MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset=windows-1255 Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Proposed addition after introduction (was: Jersey JEandGuernsey GG Country Codes) thread-index: AcWHjeAx/17cxODiQQ+bN50gMRUICwAAHQ4g Content-Class: urn:content-classes:message X-OriginalArrivalTime: 13 Jul 2005 09:41:59.0797 (UTC) FILETIME=[1DAE6A50:01C5878F] X-Spam-Score: 0.8 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 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 oppose too. Someone else can write an RFC about IANA "sharing the cultural=20 life of the Internet community", but it shouldn't be an RFC=20 being worked on by this WG. Misha -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On B= ehalf Of Mark Davis Sent: 13 July 2005 10:30 To: Randy Presuhn; LTRU Working Group Subject: Re: [Ltru] Proposed addition after introduction (was: Jersey JEand= Guernsey GG Country Codes) Oppose. It would be bizarre for IANA to have a proclamation of its approach to "sharing the cultural life of the Internet community" in an RFC. =FDMark ----- Original Message -----=20 From: "Randy Presuhn" To: Sent: Wednesday, July 13, 2005 00:10 Subject: [Ltru] Proposed addition after introduction (was: Jersey JE andGuernsey GG Country Codes) > Hi - > > I'd like to get a hum on this proposed addition. Obviously it would need some > work on spelling, grammar, punctuation, and other editorial details. I'm just > interested in finding out whether the WG supports adding something that conveys > the sense of the proposal. > > Please post to the ltru list whether you support or oppose the addition. > > Randy, ltru co-chair > > ----- Original Message -----=20 > > From: "r&d afrac" > > To: "Debbie Garside" ; "'Debbie Garside'" ; "'Peter Constable'" > ; > > Sent: Tuesday, July 12, 2005 8:14 PM > > Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes > > > > > At 23:44 12/07/2005, Debbie Garside wrote: > > >So... are you telling me that I have to go back to Tony (Blair) and tell him > > >his letter won't be necessary...? ;-) > > > > Debbie, > > ad-hominem! If Tony wants to discuss his position on the Jersey and > > Gernesey langtags, please have him joining this list. > > > > This may look as a troll. But it is not. It is a perfect example of the > > inadequation of IETF to address issues which are beyond its scope. > > Sometime, a langtag user will have a conflict between an IETF Internet > > defined conception and legal definition of Her Gacious Majesty Government. > > And will lose time, money, credibility, etc. due to that. The Draft will > > lose credibility. Hardly what the authors want. > > > > The Draft should start with the following warning (just after the > > Introduction): > > > > "The IANA is not in the business of deciding what is and what is not an > > appropriate correlation between a language, a script, a country and other > > cultural or human language elements as they may appear necessary. The > > selection of ISO 639 to obtain a language/script/country correlating table > > and rules was made with the knowldge that ISO has procedures to determine > > which resulting language tags should be and should not be on such a list. > > It happens that ISO 639 does not provide yet such a list. So, however the > > IANA is not in the business of deciding if this is a lack ISO still has to > > address or if it is a deliberated authoritative decision, the IANA intends > > to extend the possibilities offered to Internet protocols and applications > > users by RFC 3066. This Memo describes under which technical terms this may > > be done, notwithstanding the national or international legal limitations > > which may be imposed elsewhere to the users." > > > > "The IANA adheres to the language equal opportunity declaration: > > > > "The purpose of technology isn't to insure that everybody should have an > > equal opportunity whatever his language, its purpose is to allow this goal. > > > > "This document's aim is to allow everyone to freely share the cultural life > > of the Internet community, to enjoy using its solutions on an equal > > linguistic, cultural, technical, economical and commercial basis, and to > > share into the benefits of the technology and its advancements without > > distinction of any kind, such as race, colour, sex, language, religion, > > political or other opinion, national or social origin, property, birth or > > other status and education. Therefore the goal is to build a common > > technical standard for all people and all nations to be used or embedded in > > any technical solution, without any limitation resulting from the script, > > the language, the referent or the context of their technical environment. > > > > "Taking into account the granular nature and the diversity of the world's > > digital ecosystem as well as the requirements of its technical convergence, > > the authors of this technical memorandum strongly advocate its free, secure > > and stable implementation to serve the rights and freedoms of its users at > > an international, national and personal level, in the respect of sovereign > > laws and jurisdiction of each State, of the empowerment of local cultures, > > and of its intergovernance by subsidiarity in any of the public or private, > > community or individual contexts. " > > > > (text to be revised along with its review by the members of the global > > on-line community in preparation of the Tunis declaration) > > > > 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 ----------------------------------------------------------------- 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 Wed Jul 13 05:45:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsdoC-0007D5-85; Wed, 13 Jul 2005 05:45:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsdoA-0007Cy-Cy for ltru@megatron.ietf.org; Wed, 13 Jul 2005 05:45:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21540 for ; Wed, 13 Jul 2005 05:45:34 -0400 (EDT) Received: from smtp.nildram.co.uk ([195.112.4.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DseGU-0000JD-UG for ltru@ietf.org; Wed, 13 Jul 2005 06:14:57 -0400 Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) by smtp.nildram.co.uk (Postfix) with ESMTP id B8F4525264E; Wed, 13 Jul 2005 10:45:15 +0100 (BST) From: "Debbie Garside" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: Jersey JE and Guernsey GG Country Codes AND IM Isle of Man Date: Wed, 13 Jul 2005 10:44:34 +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 thread-index: AcWHZpcEYHTvr37qS3uZoD1YqajW3AAJfTDQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <007c01c58765$eaf99900$030aa8c0@DEWELL> Message-Id: <20050713094515.B8F4525264E@smtp.nildram.co.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 FYI The position at the moment is that codes for Jersey (JE) Guernsey (GG) and Isle of Man (IM) have been approved by both BS Committee members and UK Government. There is a stumbling block in that the BSI Sec for the 3166 shadow committee has just left (1st July). I am endeavouring to get another BSI sec to take it over in the interim just for the submission to ISO 3166. Having spoken to Joseph Martinez at the ISO 3166 MA, I am reliably informed that the process will most probably take 2 months to complete (normally 1 month but delayed due to summer holidays). I am also reliably informed that, on the face of it, given that there are UN codes and on receipt of a request made via BSI and supported by UK government (which should be in place by Friday), there should be no problem with the request. Will keep you informed! Kind regards Debbie -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Doug Ewell Sent: 13 July 2005 05:47 To: LTRU Working Group Subject: [Ltru] Re: Jersey JE and Guernsey GG Country Codes Debbie Garside wrote: > So... are you telling me that I have to go back to Tony (Blair) and tell him > his letter won't be necessary...? ;-) Joseph Martinez from ISO 3166/MA told me these requests "would have to be coordinated with the British Standards Institution (BSI) and the relevant Government Departments in London." So if I were you, I'd have Tony go ahead and write his letter. I agree with Frank that IM should also be requested for Isle of Man as long as you are at 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 Wed Jul 13 05:52:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsdvD-0002rl-Sd; Wed, 13 Jul 2005 05: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 1DsdvC-0002rS-07 for ltru@megatron.ietf.org; Wed, 13 Jul 2005 05:52:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22052 for ; Wed, 13 Jul 2005 05:52:51 -0400 (EDT) Received: from [83.70.80.115] (helo=zeus.COMMUNICRAFT) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DseNV-0000cv-9P for ltru@ietf.org; Wed, 13 Jul 2005 06:22:14 -0400 Received: From [192.168.100.14] (unverified [192.168.100.14]) by SMTP Server [192.168.100.110] (WinGate SMTP Receiver v5.2.3 (Build 901)) with SMTP id <0000007185@zeus>; Wed, 13 Jul 2005 10:53:21 +0100 Message-ID: <42D4E490.9020308@hackcraft.net> Date: Wed, 13 Jul 2005 10:53:20 +0100 From: Jon Hanna User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: LTRU Working Group Subject: Re: [Ltru] Re: Jersey JE and Guernsey GG Country Codes References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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 fairness, as much use as W3C makes of ISO standards, and as >>rigorously as they keep their pages up to date, it seems reasonable to >>assume that their pointer to ISO 3166/MA would be current. Eh, where was this on the site? Some sections of the W3C site are kept current better than others. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 06:08:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DseAY-0001p1-Uw; Wed, 13 Jul 2005 06:08:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DseAX-0001ot-Lr for ltru@megatron.ietf.org; Wed, 13 Jul 2005 06:08:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23006 for ; Wed, 13 Jul 2005 06:08:43 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsecu-0001LJ-Ex for ltru@ietf.org; Wed, 13 Jul 2005 06:38:06 -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 j6DA8ZZm019692; Wed, 13 Jul 2005 13:08:35 +0300 (EEST) Message-ID: <42D4E824.4040102@kotus.fi> Date: Wed, 13 Jul 2005 13:08:36 +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] Proposed addition after introduction (was: Jersey JE andGuernsey GG Country Codes) References: <200507122127.j6CLRQ7O000601@smtp-los04.proxy.aol.com><200507122144.j6CLiPv9018403@smtp-los02.proxy.aol.com><6.2.1.2.2.20050713043215.048b4eb0@mail.afrac.org> <008d01c58779$f5fe3f40$7f1afea9@oemcomputer> <039601c5878d$6c832640$6501a8c0@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 j6DA8ZZm019692 X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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 So do I. - Erkki I. Kolehmainen Mark Davis wrote: > Oppose. It would be bizarre for IANA to have a proclamation of its appr= oach > to "sharing the cultural life of the Internet community" in an RFC. >=20 > =E2=80=8EMark >=20 > ----- Original Message -----=20 > From: "Randy Presuhn" > To: > Sent: Wednesday, July 13, 2005 00:10 > Subject: [Ltru] Proposed addition after introduction (was: Jersey JE > andGuernsey GG Country Codes) >=20 >=20 >=20 >>Hi - >> >>I'd like to get a hum on this proposed addition. Obviously it would ne= ed >> > some >=20 >>work on spelling, grammar, punctuation, and other editorial details. I= 'm >> > just >=20 >>interested in finding out whether the WG supports adding something that >> > conveys >=20 >>the sense of the proposal. >> >>Please post to the ltru list whether you support or oppose the addition. >> >>Randy, ltru co-chair >> >>----- Original Message -----=20 >> >>>From: "r&d afrac" >>>To: "Debbie Garside" ; "'Debbie Garside'" >>> > ; "'Peter Constable'" >=20 >>; >> >>>Sent: Tuesday, July 12, 2005 8:14 PM >>>Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes >>> >>> >>>At 23:44 12/07/2005, Debbie Garside wrote: >>> >>>>So... are you telling me that I have to go back to Tony (Blair) and >>>> > tell him >=20 >>>>his letter won't be necessary...? ;-) >>>> >>>Debbie, >>>ad-hominem! If Tony wants to discuss his position on the Jersey and >>>Gernesey langtags, please have him joining this list. >>> >>>This may look as a troll. But it is not. It is a perfect example of th= e >>>inadequation of IETF to address issues which are beyond its scope. >>>Sometime, a langtag user will have a conflict between an IETF Internet >>>defined conception and legal definition of Her Gacious Majesty >>> > Government. >=20 >>>And will lose time, money, credibility, etc. due to that. The Draft wi= ll >>>lose credibility. Hardly what the authors want. >>> >>>The Draft should start with the following warning (just after the >>>Introduction): >>> >>>"The IANA is not in the business of deciding what is and what is not a= n >>>appropriate correlation between a language, a script, a country and >>> > other >=20 >>>cultural or human language elements as they may appear necessary. The >>>selection of ISO 639 to obtain a language/script/country correlating >>> > table >=20 >>>and rules was made with the knowldge that ISO has procedures to >>> > determine >=20 >>>which resulting language tags should be and should not be on such a >>> > list. >=20 >>>It happens that ISO 639 does not provide yet such a list. So, however >>> > the >=20 >>>IANA is not in the business of deciding if this is a lack ISO still ha= s >>> > to >=20 >>>address or if it is a deliberated authoritative decision, the IANA >>> > intends >=20 >>>to extend the possibilities offered to Internet protocols and >>> > applications >=20 >>>users by RFC 3066. This Memo describes under which technical terms thi= s >>> > may >=20 >>>be done, notwithstanding the national or international legal limitatio= ns >>>which may be imposed elsewhere to the users." >>> >>>"The IANA adheres to the language equal opportunity declaration: >>> >>>"The purpose of technology isn't to insure that everybody should have = an >>>equal opportunity whatever his language, its purpose is to allow this >>> > goal. >=20 >>>"This document's aim is to allow everyone to freely share the cultural >>> > life >=20 >>>of the Internet community, to enjoy using its solutions on an equal >>>linguistic, cultural, technical, economical and commercial basis, and = to >>>share into the benefits of the technology and its advancements without >>>distinction of any kind, such as race, colour, sex, language, religion= , >>>political or other opinion, national or social origin, property, birth >>> > or >=20 >>>other status and education. Therefore the goal is to build a common >>>technical standard for all people and all nations to be used or embedd= ed >>> > in >=20 >>>any technical solution, without any limitation resulting from the >>> > script, >=20 >>>the language, the referent or the context of their technical >>> > environment. >=20 >>>"Taking into account the granular nature and the diversity of the >>> > world's >=20 >>>digital ecosystem as well as the requirements of its technical >>> > convergence, >=20 >>>the authors of this technical memorandum strongly advocate its free, >>> > secure >=20 >>>and stable implementation to serve the rights and freedoms of its user= s >>> > at >=20 >>>an international, national and personal level, in the respect of >>> > sovereign >=20 >>>laws and jurisdiction of each State, of the empowerment of local >>> > cultures, >=20 >>>and of its intergovernance by subsidiarity in any of the public or >>> > private, >=20 >>>community or individual contexts. " >>> >>>(text to be revised along with its review by the members of the global >>>on-line community in preparation of the Tunis declaration) >>> >>>jfc >>> >>... >> >> >> >> >>_______________________________________________ >>Ltru mailing list >>Ltru@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/ltru >> >> >> >=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@lists.ietf.org Wed Jul 13 06:29:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DseUk-0003hs-76; Wed, 13 Jul 2005 06:29:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DseUi-0003hn-9V for ltru@megatron.ietf.org; Wed, 13 Jul 2005 06:29:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24115 for ; Wed, 13 Jul 2005 06:29:32 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsex4-00025F-JB for ltru@ietf.org; Wed, 13 Jul 2005 06:58:55 -0400 Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6DAT5I29845; Wed, 13 Jul 2005 19:29:05 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id 9d76f30e_f389_11d9_9a44_0030482533a1_2738; Wed, 13 Jul 2005 19:33:56 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0081B3; 13 Jul 05 19:34:41 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 13 Jul 05 19:34:30 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0081AF; 13 Jul 05 19:34:28 +0900 Message-Id: <6.0.0.20.2.20050713190651.08e69620@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Wed, 13 Jul 2005 19:28:24 +0900 To: "Randy Presuhn" , From: Martin Duerst Subject: Re: [Ltru] Proposed addition after introduction (was: Jersey JE andGuernsey GG Country Codes) In-Reply-To: <008d01c58779$f5fe3f40$7f1afea9@oemcomputer> References: <200507122127.j6CLRQ7O000601@smtp-los04.proxy.aol.com> <200507122144.j6CLiPv9018403@smtp-los02.proxy.aol.com> <6.2.1.2.2.20050713043215.048b4eb0@mail.afrac.org> <008d01c58779$f5fe3f40$7f1afea9@oemcomputer> 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: 6640e3bbe8a4d70c4469bcdcbbf0921d 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 [with my co-chair hat on] I'd like to thank JFC on actually submitting real text. As both chairs have said repeatedly, this is the best way to move things forward. For everybody: If you make an actual proposal (rather than just discuss a proposal), please use a new subject. Also, please indicate clearly that you want this change to happen as part of WG Last Call. Otherwise, we're never sure whether that's what you want, or whether your proposal is just "as an idea". [with my co-chair hat off] I quite a bit agree with the sentiment in some of the text. (I have worked on Internationalization of the WWW and the Internet for a long time, so I hope this doesn't come as a surprise.) However, as an engineer, I think that what counts is the actual spec. As a technical project, the only thing we can do is to try to produce good technology, and hope it gets used the right way. Engineers in general, and the IETF in particular, is rather bad at marketing and politics, and I think we should stay away from it. Declarations like those in JFC's proposed text are very important in political fora, but in my opinion don't belong in a technical spec (like ours). Also, some of the wording proposed sounds a bit too much like "Life, Liberty, and the Pursuit of Happiness" (or "Liberte', Egalite', Fraternite'", or whatever your local version), or seen from the negative side, like "motherhood and applepie" (sorry, don't know what the French equivalent would be). The only bit where I'd like a bit more time to check the current draft text is JFCs first paragraph. If we are not clear enough that the draft and the registry don't define languages, but only provide identifiers, then I think may be a problem. But if this is the case, then this should be fixed mostly by word tweaking, rather than by grandiose declarations. As an example, looking at the first sentence of section @, it currently starts "The language tag always defines a language...". I think this should be changed to say "The language tag always identifies a language..." Regards, Martin. At 16:10 05/07/13, Randy Presuhn wrote: >Hi - > >I'd like to get a hum on this proposed addition. Obviously it would need some >work on spelling, grammar, punctuation, and other editorial details. I'm just >interested in finding out whether the WG supports adding something that conveys >the sense of the proposal. > >Please post to the ltru list whether you support or oppose the addition. > >Randy, ltru co-chair > >----- Original Message ----- >> From: "r&d afrac" >> To: "Debbie Garside" ; "'Debbie Garside'" >; "'Peter Constable'" >; >> Sent: Tuesday, July 12, 2005 8:14 PM >> Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes >> > >> At 23:44 12/07/2005, Debbie Garside wrote: >> >So... are you telling me that I have to go back to Tony (Blair) and tell him >> >his letter won't be necessary...? ;-) >> >> Debbie, >> ad-hominem! If Tony wants to discuss his position on the Jersey and >> Gernesey langtags, please have him joining this list. >> >> This may look as a troll. But it is not. It is a perfect example of the >> inadequation of IETF to address issues which are beyond its scope. >> Sometime, a langtag user will have a conflict between an IETF Internet >> defined conception and legal definition of Her Gacious Majesty Government. >> And will lose time, money, credibility, etc. due to that. The Draft will >> lose credibility. Hardly what the authors want. >> >> The Draft should start with the following warning (just after the >> Introduction): >> >> "The IANA is not in the business of deciding what is and what is not an >> appropriate correlation between a language, a script, a country and other >> cultural or human language elements as they may appear necessary. The >> selection of ISO 639 to obtain a language/script/country correlating table >> and rules was made with the knowldge that ISO has procedures to determine >> which resulting language tags should be and should not be on such a list. >> It happens that ISO 639 does not provide yet such a list. So, however the >> IANA is not in the business of deciding if this is a lack ISO still has to >> address or if it is a deliberated authoritative decision, the IANA intends >> to extend the possibilities offered to Internet protocols and applications >> users by RFC 3066. This Memo describes under which technical terms this may >> be done, notwithstanding the national or international legal limitations >> which may be imposed elsewhere to the users." >> >> "The IANA adheres to the language equal opportunity declaration: >> >> "The purpose of technology isn't to insure that everybody should have an >> equal opportunity whatever his language, its purpose is to allow this goal. >> >> "This document's aim is to allow everyone to freely share the cultural life >> of the Internet community, to enjoy using its solutions on an equal >> linguistic, cultural, technical, economical and commercial basis, and to >> share into the benefits of the technology and its advancements without >> distinction of any kind, such as race, colour, sex, language, religion, >> political or other opinion, national or social origin, property, birth or >> other status and education. Therefore the goal is to build a common >> technical standard for all people and all nations to be used or embedded in >> any technical solution, without any limitation resulting from the script, >> the language, the referent or the context of their technical environment. >> >> "Taking into account the granular nature and the diversity of the world's >> digital ecosystem as well as the requirements of its technical convergence, >> the authors of this technical memorandum strongly advocate its free, secure >> and stable implementation to serve the rights and freedoms of its users at >> an international, national and personal level, in the respect of sovereign >> laws and jurisdiction of each State, of the empowerment of local cultures, >> and of its intergovernance by subsidiarity in any of the public or private, >> community or individual contexts. " >> >> (text to be revised along with its review by the members of the global >> on-line community in preparation of the Tunis declaration) >> >> 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 Wed Jul 13 07:33:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsfUh-00081c-8Y; Wed, 13 Jul 2005 07:33:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsfUf-00081X-PA for ltru@megatron.ietf.org; Wed, 13 Jul 2005 07:33:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27617 for ; Wed, 13 Jul 2005 07:33:37 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsfx3-0004QD-LU for ltru@ietf.org; Wed, 13 Jul 2005 08:02:58 -0400 Received: from skunk.reutershealth.com (mail [65.246.141.36]) by mail.reutershealth.com (8.13.1/8.13.1) with SMTP id j6DBXJHX007614; Wed, 13 Jul 2005 07:33:20 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 13 Jul 2005 07:33:19 -0400 Date: Wed, 13 Jul 2005 07:33:18 -0400 From: "John.Cowan" To: Debbie Garside Subject: Re: [Ltru] Re: Jersey JE and Guernsey GG Country Codes AND IM Isle of Man Message-ID: <20050713113318.GA3572@NYCMJCOWA2> References: <007c01c58765$eaf99900$030aa8c0@DEWELL> <20050713094515.B8F4525264E@smtp.nildram.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050713094515.B8F4525264E@smtp.nildram.co.uk> User-Agent: Mutt/1.4.2.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 Debbie Garside scripsit: > Having spoken to Joseph Martinez at the ISO 3166 MA, I am reliably informed > [...] there should be no problem with the request. Hurrah! Thanks. -- John Cowan http://www.ccil.org/~cowan jcowan@reutershealth.com Be yourself. Especially do not feign a working knowledge of RDF where no such knowledge exists. Neither be cynical about RELAX NG; for in the face of all aridity and disenchantment in the world of markup, James Clark is as perennial as the grass. --DeXiderata, Sean McGrath _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 07: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 1Dsfah-00031r-Pn; Wed, 13 Jul 2005 07: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 1Dsfag-00031h-G1 for ltru@megatron.ietf.org; Wed, 13 Jul 2005 07:39:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28096 for ; Wed, 13 Jul 2005 07:39:49 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsg34-0004ee-Gr for ltru@ietf.org; Wed, 13 Jul 2005 08:09: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 j6DBdcrs007650; Wed, 13 Jul 2005 07:39:40 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Wed, 13 Jul 2005 07:39:38 -0400 Date: Wed, 13 Jul 2005 07:39:38 -0400 From: "John.Cowan" To: Martin Duerst Subject: Re: [Ltru] Proposed addition after introduction (was: Jersey JE andGuernsey GG Country Codes) Message-ID: <20050713113938.GB3572@NYCMJCOWA2> References: <200507122127.j6CLRQ7O000601@smtp-los04.proxy.aol.com> <200507122144.j6CLiPv9018403@smtp-los02.proxy.aol.com> <6.2.1.2.2.20050713043215.048b4eb0@mail.afrac.org> <008d01c58779$f5fe3f40$7f1afea9@oemcomputer> <6.0.0.20.2.20050713190651.08e69620@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.0.20.2.20050713190651.08e69620@itmail.it.aoyama.ac.jp> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Martin Duerst scripsit: > [with my co-chair hat off] I strongly agree with all of Martin's points. -- And it was said that ever after, if any John Cowan man looked in that Stone, unless he had a jcowan@reutershealth.com great strength of will to turn it to other www.ccil.org/~cowan purpose, he saw only two aged hands withering www.reutershealth.com in flame. --"The Pyre of Denethor" _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 07:52:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsfnJ-0000np-1v; Wed, 13 Jul 2005 07:52:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsfnH-0000lm-O7 for ltru@megatron.ietf.org; Wed, 13 Jul 2005 07:52:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28999 for ; Wed, 13 Jul 2005 07:52:50 -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.43) id 1DsgFe-00055j-P2 for ltru@ietf.org; Wed, 13 Jul 2005 08:22:13 -0400 Received: (qmail 9009 invoked by uid 500); 13 Jul 2005 12:46:19 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Jul 2005 12:46:19 -0000 Date: Wed, 13 Jul 2005 08:46:19 -0400 (EDT) From: Robin Cover X-X-Sender: robin@localhost.localdomain To: Doug Ewell Subject: Re: [Ltru] Re: Jersey JE and Guernsey GG Country Codes In-Reply-To: <008e01c58767$842ab5e0$030aa8c0@DEWELL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Tue, 12 Jul 2005, Doug Ewell wrote: [...] about W3C's not-current pointer to the ISO 3166/MA [meta-level off topic comment] As a website maintainer, I have a different perspective on what's "reasonable." I create lots of pointers (links), sometimes a hundred a day. The half-life of a URL is about 40 days. The economic loss on a global scale from highly-paid persons searching for resources occasioned by now-broken links is incalculable. What's reasonable is NOT that Party A fails to support link persistence (by any number of standard HTTP-based mechanisms) -- expecting a million other users to stay vigilant and correct the broken links or AWOL resources for which Party A is/was custodian. What's reasonable is that ONE party fixes the URI with a URI alias so that a million other users don't have to edit all their documents. In this case [ISO 3166/MA], the resource has moved, so DIN should be redirecting all traffic to the resource at its new location. Requiring all others, thousands of them, to detect and repair the intentional link damage is unreasonable. The MA has sufficient identity that obsolete URLs can be mapped to current ones, if the agencies responsible for their resources (past and present) do the right thing. - Robin Cover *PS Peter, you should be proud of SIL. My SGML/XML resource has not been there for about 8 years. Watch this: http://www.sil.org/sgml/yuriMemColl.html OR this: http://www.sil.org/sgml/sgmlnew.html Dozens of such URLs printed in hundreds of books still work; such pointers in the books cannot be maintained/fixed, but URI owners can take responsibility for resources committed into their charge. "Cool URIs don't change" http://www.w3.org/Provider/Style/URI.html ------------------- > Peter Constable wrote: > > >> Hmmmm.... > >> > >> I got this from the W3C site... > > > > Would you consult the French government to find out about traffic > > regulations in Wales? ISO 3166 is not maintained by W3C. I'm sure this > > was provided with good intentions to be helpful to users, but it's > > clearly a couple of years out of date -- it's been a while now since > > DIN gave up the role of MA. > > In fairness, as much use as W3C makes of ISO standards, and as > rigorously as they keep their pages up to date, it seems reasonable to > assume that their pointer to ISO 3166/MA would be current. and Peter said: Whatever might *seem* reasonable, it is clear that their pointer is at least a couple of years out of date. > > -- > 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 Jul 13 09:03:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsgtQ-0000rH-TP; Wed, 13 Jul 2005 09:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsgtM-0000le-5L for ltru@megatron.ietf.org; Wed, 13 Jul 2005 09:03:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04238 for ; Wed, 13 Jul 2005 09:03:10 -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.43) id 1DshLj-0007gY-92 for ltru@ietf.org; Wed, 13 Jul 2005 09:32:33 -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 Jul 2005 06:02:54 -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] Proposed addition after introduction (was: Jersey JE andGuernsey GG Country Codes) Date: Wed, 13 Jul 2005 06:02:54 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C1095EB@irvmbxw01.quest.com> Thread-Topic: [Ltru] Proposed addition after introduction (was: Jersey JE andGuernsey GG Country Codes) Thread-Index: AcWHeY2w3tL+quvwT4WcDtyWRUuY5wAMYepA From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 13 Jul 2005 13:02:54.0027 (UTC) FILETIME=[2E8FF1B0:01C587AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 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 -1 on JFC's text. 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: 2005?7?13? 0:10 > To: ltru@ietf.org > Subject: [Ltru] Proposed addition after introduction (was: Jersey JE > andGuernsey GG Country Codes) >=20 > Hi - >=20 > I'd like to get a hum on this proposed addition. Obviously it would = need > some > work on spelling, grammar, punctuation, and other editorial details. = I'm > just > interested in finding out whether the WG supports adding something = that > conveys > the sense of the proposal. >=20 > Please post to the ltru list whether you support or oppose the = addition. >=20 > Randy, ltru co-chair >=20 > ----- Original Message ----- > > From: "r&d afrac" > > To: "Debbie Garside" ; "'Debbie Garside'" > ; "'Peter Constable'" > ; > > Sent: Tuesday, July 12, 2005 8:14 PM > > Subject: RE: [Ltru] Jersey JE and Guernsey GG Country Codes > > >=20 > > At 23:44 12/07/2005, Debbie Garside wrote: > > >So... are you telling me that I have to go back to Tony (Blair) and > tell him > > >his letter won't be necessary...? ;-) > > > > Debbie, > > ad-hominem! If Tony wants to discuss his position on the Jersey and > > Gernesey langtags, please have him joining this list. > > > > This may look as a troll. But it is not. It is a perfect example of = the > > inadequation of IETF to address issues which are beyond its scope. > > Sometime, a langtag user will have a conflict between an IETF = Internet > > defined conception and legal definition of Her Gacious Majesty > Government. > > And will lose time, money, credibility, etc. due to that. The Draft = will > > lose credibility. Hardly what the authors want. > > > > The Draft should start with the following warning (just after the > > Introduction): > > > > "The IANA is not in the business of deciding what is and what is not = an > > appropriate correlation between a language, a script, a country and > other > > cultural or human language elements as they may appear necessary. = The > > selection of ISO 639 to obtain a language/script/country correlating > table > > and rules was made with the knowldge that ISO has procedures to > determine > > which resulting language tags should be and should not be on such a = list. > > It happens that ISO 639 does not provide yet such a list. So, = however > the > > IANA is not in the business of deciding if this is a lack ISO still = has > to > > address or if it is a deliberated authoritative decision, the IANA > intends > > to extend the possibilities offered to Internet protocols and > applications > > users by RFC 3066. This Memo describes under which technical terms = this > may > > be done, notwithstanding the national or international legal = limitations > > which may be imposed elsewhere to the users." > > > > "The IANA adheres to the language equal opportunity declaration: > > > > "The purpose of technology isn't to insure that everybody should = have an > > equal opportunity whatever his language, its purpose is to allow = this > goal. > > > > "This document's aim is to allow everyone to freely share the = cultural > life > > of the Internet community, to enjoy using its solutions on an equal > > linguistic, cultural, technical, economical and commercial basis, = and to > > share into the benefits of the technology and its advancements = without > > distinction of any kind, such as race, colour, sex, language, = religion, > > political or other opinion, national or social origin, property, = birth > or > > other status and education. Therefore the goal is to build a common > > technical standard for all people and all nations to be used or = embedded > in > > any technical solution, without any limitation resulting from the = script, > > the language, the referent or the context of their technical = environment. > > > > "Taking into account the granular nature and the diversity of the > world's > > digital ecosystem as well as the requirements of its technical > convergence, > > the authors of this technical memorandum strongly advocate its free, > secure > > and stable implementation to serve the rights and freedoms of its = users > at > > an international, national and personal level, in the respect of > sovereign > > laws and jurisdiction of each State, of the empowerment of local > cultures, > > and of its intergovernance by subsidiarity in any of the public or > private, > > community or individual contexts. " > > > > (text to be revised along with its review by the members of the = global > > on-line community in preparation of the Tunis declaration) > > > > jfc > ... >=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 Wed Jul 13 10:16:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsi0E-0004rE-V4; Wed, 13 Jul 2005 10:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsi0D-0004pH-34 for ltru@megatron.ietf.org; Wed, 13 Jul 2005 10:14:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10275 for ; Wed, 13 Jul 2005 10:14:19 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsiSc-0001xd-Al for ltru@ietf.org; Wed, 13 Jul 2005 10:43:43 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 07:14:09 -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, 13 Jul 2005 07:14:09 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Proposed addition after introduction (was: Jersey JE andGuernsey GG Country Codes) Date: Wed, 13 Jul 2005 07:14:12 -0700 Message-ID: Thread-Topic: [Ltru] Proposed addition after introduction (was: Jersey JE andGuernsey GG Country Codes) Thread-Index: AcWHeZMuyBDN+u7qTJSkqWVTEnJWdwAOS9zQ From: "Peter Constable" To: X-OriginalArrivalTime: 13 Jul 2005 14:14:09.0425 (UTC) FILETIME=[22E5E810:01C587B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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'd like to get a hum on this proposed addition. I oppose.=20 Like Martin, I agree with the sentiment about equal opportunity, but see that kind of statement belonging somewhere else than this technical specification. Also, I consider some of the statements wrt ISO to be factually wrong. I might accept some wording to the effect of "This spec provides for creation of language tags, but makes no claims as to what language variations should be distinguished by such tags or what non-technical policies should be applied to their usage." But I'm not hereby proposing specific text or asking anyone else to provide it. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 10:16:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dshy9-0004Ni-SK; Wed, 13 Jul 2005 10:12:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dshy5-0004NY-Cw for ltru@megatron.ietf.org; Wed, 13 Jul 2005 10:12:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10038 for ; Wed, 13 Jul 2005 10:12:07 -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.43) id 1DsiQU-0001tx-DR for ltru@ietf.org; Wed, 13 Jul 2005 10:41:31 -0400 Received: from eupig1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id ; Wed, 13 Jul 2005 14:11:46 +0000 Message-ID: Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IJK00H2BKRMFI@eupig1.dtc.lon.ime.reuters.com>; Wed, 13 Jul 2005 14:11:46 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Wed, 13 Jul 2005 15:11:45 +0100 Date: Wed, 13 Jul 2005 15:11:45 +0100 From: Misha Wolf To: Debbie Garside MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Thread-Topic: OT: ISO 4217 MA messing with ISO 3166 codes thread-index: AcV67ehfV39k6Xg4S1q4zp4HU3AeXQMqpTgQAAZ6gkAAAFL+MA== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 13 Jul 2005 14:11:45.0904 (UTC) FILETIME=[CD5A5700:01C587B4] X-Spam-Score: 1.3 (+) X-Scan-Signature: 8db6b1eef878f11b7d6324adee263d0c Cc: iptc-metadata@yahoogroups.com, LTRU Working Group , semantic-web@w3.org Subject: [Ltru] OT: ISO 4217 MA messing with ISO 3166 codes X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============0516708087==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0516708087== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C587B4.CD1D5658" Content-Class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C587B4.CD1D5658 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Debbie, =20 As you seem to have friends in high places, please could you draw to the attention of the BSI shadow committee for ISO 3166 that the ISO 4217 MA (which just happens to be the BSI) is playing fast and loose with ISO 3166 codes. The MA announced recently that the code for the currency of Azerbaijan is changing from "AZM" to "AYM". I protested to the MA and to the World Bank, saying that the country code for Azerbaijan shows no sign of changing from "AZ" to "AY" (currency codes for national currencies are constructed from the ISO 3166 code plus an extra character). Despite this, SWIFT has today made the official announcement below. There appears to be no obvious way for users of these codes to protest at seemingly arbitrary decisions (cf the "CS" mess). =20 Thanks, Misha _____ =20 From: Christine OLoughlin [mailto:Christine.O'Loughlin@BSI-GLOBAL.COM]=20 Sent: 13 July 2005 14:56 To: Misha Wolf Subject: RE: Re Amendment 127 Dear Mr Wolf =20 The following is a broadcast from SWIFT to the World Bank, dated today =20 "MT: 094F Broadcast Sender: MLMLXXXXXXX Send Ref: 000000/784771/05-07-13 08:58:00 Receiver: IBRDUS33XXX INTERNATIONAL BANK FOR RECONSTRUCTI WASHINGTON, DC Owner: XXX IBRD Internal Priority: S Stage: Inb-Cmpl Next Activity: Micro-F Input: FIN /FINIBR /4854 /873031/2005-07-13 04:58:34 =20 =20 ------------------------------------------------------------------------ -------- :135:Broadcast: N :136:Broadcast Num to all Users: S 05569 :129:Section Number: 01 /01 :130:Code Word(s): /30 /CURRENCY /01/CODE CHANGE :134:BIC, Name, City Broadcast Requester: SWHQBEBBBCT SWIFT HEADQUARTERS LA HULPE SWIFT HEADQUARTERS (BROADCAST REQUESTS ONLY) :312:Broadcast Text: NEW CURRENCY CODE IN AZERBAIJAN . PLEASE BE INFORMED THAT IN AZERBAIJAN, THE CURRENCY CODE 'AZM' WILL BE REPLACED BY 'AYM' EFFECTIVE 1 JANUARY 2006. . DETAILS OF THIS NEW CURRENCY CODE ARE AS FOLLOWS: . ALPHA CODE: AYM CURRENCY NAME: AZERBAIJANIAN MANAT FRACTIONAL DIGIT: 2 NUMERIC CODE: 945 . THE CURRENCY TABLE ON THE SWIFT NETWORK WILL BE UPDATED WITH THE NEW CURRENCY CODE 'AYM' ON 8 OCTOBER 2005. . THE FORMER CURRENCY CODE 'AZM' WILL REMAIN ON THE SWIFT NETWORK UNTIL DECEMBER 2006. YOU WILL BE INFORMED OF ITS DELETION VIA A FUTURE BROADCAST. . THE BIC DIRECTORY OF 3 DECEMBER 2005 WILL REFLECT THIS CHANGE. . BEST REGARDS, SWIFT CUSTOMER OPERATIONS" =20 Regards =20 _____ =20 From: Misha Wolf [mailto:Misha.Wolf@reuters.com]=20 Sent: 13 July 2005 11:51 To: Christine OLoughlin Subject: RE: Re Amendment 127 =20 Dear Ms O'Loughlin, =20 Kindly let me know what progress if any there has been regarding the matter I raised by email and phone. =20 Many thanks, =20 Misha Wolf Standards Manager Reuters =20 _____ =20 From: Christine OLoughlin [mailto:Christine.O'Loughlin@BSI-GLOBAL.COM]=20 Sent: 27 June 2005 08:58 To: Misha Wolf Subject: Re Amendment 127 Thank you for your telephone call, 24 June. I confirm that Azerbaijan will change its currency code on 1 January 2006 to AYM 945 (minor unit 2). This change of code is at the request of the National Bank of Azerbaijan. =20 The currency will on 1 January 2006 be redenominated on the following terms - 1 new Manat is equal to 5000 old Manats. =20 Regards =20 ISO 4217 MA/Secretariat =20 Email: currency@bsi-global.com Fax: 020 8996 7187 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Visit the BSI website at www.bsi-global.com This email may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. Any unauthorised use may be unlawful. If you receive this email by mistake, please advise the sender immediately by using the reply facility in your email software. Thank you for your cooperation. ________________________________________________________________________ This e-mail has been scanned for all known viruses. ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Visit the BSI website at www.bsi-global.com This email may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. Any unauthorised use may be unlawful. If you receive this email by mistake, please advise the sender immediately by using the reply facility in your email software. Thank you for your cooperation. ________________________________________________________________________ This e-mail has been scanned for all known viruses. ----------------------------------------------------------------- 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_01C587B4.CD1D5658 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Debbie,
 
As you seem to have friends in= high=20 places, please could you draw to the attention of the BSI shadow committee= for ISO 3166 that the ISO 4217 MA = (which=20 just happens to be the BSI) is playing fast and loose with ISO 3166 codes.<= SPAN=20 class=3D642520314-13072005>  The MA announced recently that the code for the currency of Azerb= aijan=20 is changing from "AZM" to "AYM".  I protested to the MA and to the Wor= ld=20 Bank, saying that the country code for Azerbaijan shows no sign=20 of changing from "AZ" to "AY" (currency codes for national currencies = are=20 constructed from the ISO 3166 code plus an extra character).  Despite t= his, SWIFT=20 has today made the official announcement below.  There appears to be n= o=20 obvious way for users of these codes to protest at seemingly arbitrary deci= sions=20 (cf the "CS" mess).
 
Thanks,
Misha

From: Christine OLoughlin=20 [mailto:Christine.O'Loughlin@BSI-GLOBAL.COM]
Sent: 13 July 2005= 14:56
To: Misha Wolf
Subject: RE: Re Amendment=20 127

   Dear Mr= Wolf

 

The following is a br= oadcast=20 from SWIFT to the World Bank, dated today

 

“MT: 094F=20 Broadcast

  Sender:=20 MLMLXXXXXXX

Send Ref:=20 000000/784771/05-07-13 08:58:00

Receiver:=20 IBRDUS33XXX

   &nb= sp;     =20 INTERNATIONAL BANK FOR RECONSTRUCTI

   &nb= sp;     =20 WASHINGTON, DC

   Owner: X= XX=20 IBRD            = ;            &n= bsp;  =20 Internal Priority: S

   Stage:= Inb-Cmpl           =             &nb= sp;       =20 Next Activity: Micro-F

   Input:= FIN     /FINIBR /4854  /873031/2005-07-13=20 04:58:34

 

 

---------------------= -----------------------------------------------------------

:135:Broadcast: =             &nb= sp;       =20 N

:136:Broadcast Num to= all=20 Users:     S 05569

:129:Section=20 Number:           &n= bsp;    =20 01 /01

:130:Code=20 Word(s):           &= nbsp;      =20 /30 /CURRENCY

/01/CODE=20 CHANGE

:134:BIC, Name, City= Broadcast Requester:

   &nb= sp;            =             &nb= sp;       =20 SWHQBEBBBCT

   &nb= sp;            =             &nb= sp;       =20 SWIFT HEADQUARTERS

   &nb= sp;  =20             &nb= sp;            =      LA=20 HULPE

   &nb= sp;            =             &nb= sp;       =20 SWIFT HEADQUARTERS

   &nb= sp;            =             &nb= sp;       =20 (BROADCAST REQUESTS ONLY) :312:Broadcast Text:

NEW CURRENCY CODE IN= AZERBAIJAN

.

PLEASE BE INFORMED TH= AT IN=20 AZERBAIJAN, THE CURRENCY CODE= 'AZM'

WILL BE REPLACED BY '= AYM'=20 EFFECTIVE 1 JANUARY 2006.

.

DETAILS OF THIS NEW C= URRENCY=20 CODE ARE AS FOLLOWS:

.

ALPHA CODE:=20 AYM

CURRENCY NAME: AZERBA= IJANIAN=20 MANAT

FRACTIONAL DIGIT:=20 2

NUMERIC CODE:=20 945

.

THE CURRENCY TABLE ON= THE=20 SWIFT NETWORK WILL BE UPDATED WITH THE NEW CURRENCY CODE 'AYM' ON 8 OCTOBER= 2005.

.

THE FORMER CURRENCY C= ODE=20 'AZM' WILL REMAIN ON THE SWIFT NETWORK UNTIL DECEMBER 2006. YOU WILL BE INF= ORMED=20 OF ITS DELETION VIA A FUTURE BROADCAST.

.

THE BIC DIRECTORY OF = 3=20 DECEMBER 2005 WILL REFLECT THIS CHANGE.

.

BEST=20 REGARDS,

SWIFT CUSTOMER=20 OPERATIONS”

 

Regards=

 

From: Misha Wolf [mailto:Misha.Wolf@reuters.com]
Sent: 13 July 2005 11:51
To: Christine OLoughlin
Subject: RE: Re Amendment=20 127

 

Dear Ms=20 O'Loughlin,

 =

Kindly let me know what pro= gress=20 if any there has been regarding the matter I raised by email and=20 phone.

 =

Many thanks,<= FONT=20 face=3D"Times New Roman">

 =

Misha Wolf

Standards=20 Manager
Reuters

 =

From: Christine OLoughlin=20 [mailto:Christine.O'Loughlin@BSI-GLOBAL.COM]
Sent: 27 June 2005 08:58
To: Misha Wolf
Subject: Re Amendment=20 127

Thank=20 you for your telephone call, 24 June.  I confirm that Azerbaijan will change its cur= rency=20 code on 1 January 2006 to AYM 945  (minor unit 2).  This change o= f=20 code is at the request of the National Bank of Azerbaijan.<= /FONT>

 

The=20 currency will on 1 January 2006 be redenominated on the following terms = 211; 1 new=20 Manat is equal to 5000 old Manats.

 

Regards

 

ISO=20 4217 MA/Secretariat

 

Email:=20 currency@bsi-global.com<= /FONT>

Fax:=20 020 8996 7187

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

= Visit the=20 BSI website at www.bsi-global.com=

= This email=20 may contain confidential information and/or copyright
material.  Th= is=20 email is intended for the use of the addressee only.
Any unauthorised us= e may=20 be unlawful.  If you receive this email
by mistake, please advise t= he=20 sender immediately by using the
reply facility in your email=20 software.

= Thank you=20 for your cooperation.


_____________= ___________________________________________________________
This=20 e-mail has been scanned for all known=20 viruses.


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

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=20 individual
sender, except where the sender specifically states them to= be
the views of Reuters Ltd.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Visit the BSI website at www.bsi-global.com

This email may contain confidential information and/or=20 copyright
material.  This email is intended for the use of the addr= essee=20 only.
Any unauthorised use may be unlawful.  If you receive this=20 email
by mistake, please advise the sender immediately by using the
r= eply=20 facility in your email software.

Thank you for your=20 cooperation.


_______________________________________________________= _________________
This=20 e-mail has been scanned for all known viruses.


-----------------------------------------------------------------
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_01C587B4.CD1D5658-- --===============0516708087== 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 --===============0516708087==-- From ltru-bounces@lists.ietf.org Wed Jul 13 10:43:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsiSE-0003HU-3f; Wed, 13 Jul 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 1DsiSC-0003HM-HN for ltru@megatron.ietf.org; Wed, 13 Jul 2005 10:43:16 -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 KAA12615 for ; Wed, 13 Jul 2005 10:43: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 <20050713144244.ITZC14360.mta13.adelphia.net@DEWELL> for ; Wed, 13 Jul 2005 10:42:44 -0400 Message-ID: <001201c587b9$1bec55e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050713095404.ROZT13539.edge6.adelphia.net@megatron.ietf.org> Date: Wed, 13 Jul 2005 07:42:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Proposed addition after introduction X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 These comments are intended for the co-chairs only. Randy Presuhn wrote: > Please post to the ltru list whether you support or oppose the > addition. I oppose the addition. >> "This document's aim is to allow everyone to freely share the >> cultural life of the Internet community, to enjoy using its solutions >> on an equal linguistic, cultural, technical, economical and >> commercial basis, and to share into the benefits of the technology >> and its advancements without distinction of any kind, such as race, >> colour, sex, language, religion, political or other opinion, national >> or social origin, property, birth or other status and education. The document doesn't do any of that. It defines a method for constructing short text strings to represent languages and language variants, for use in identifying or requesting content. Any societal benefits that derive from that are outside the scope of the document. >> Therefore the goal is to build a common technical standard for all >> people and all nations to be used or embedded in any technical >> solution, without any limitation resulting from the script, the >> language, the referent or the context of their technical environment. The "referent" and "context" attributes have not been agreed to by any other member of this WG. -- 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 Jul 13 10:50:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsiZ0-0007VO-NC; Wed, 13 Jul 2005 10:50:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsiYl-0007D8-83; Wed, 13 Jul 2005 10:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13114; Wed, 13 Jul 2005 10:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsj1B-0003Jh-AG; Wed, 13 Jul 2005 11:19:25 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DsiYk-0000za-02; Wed, 13 Jul 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 13 Jul 2005 10:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-initial-02.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 : Initial Language Subtag Registry Author(s) : D. Ewell Filename : draft-ietf-ltru-initial-02.txt Pages : 117 Date : 2005-7-13 This memo defines the initial contents of the Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieu of the registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.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-initial-02.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-initial-02.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-7-13100830.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-initial-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-initial-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-13100830.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 Wed Jul 13 11:33:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjEt-000883-Ac; Wed, 13 Jul 2005 11:33:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjEr-00087K-Vs for ltru@megatron.ietf.org; Wed, 13 Jul 2005 11:33:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24300 for ; Wed, 13 Jul 2005 11:33:31 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsjhI-0007mx-On for ltru@ietf.org; Wed, 13 Jul 2005 12:02:57 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DsjEm-0001uI-C1 for ltru@ietf.org; Wed, 13 Jul 2005 08:33:28 -0700 Message-Id: <6.2.1.2.2.20050713161843.04b74340@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 13 Jul 2005 16:46:20 +0200 To: From: r&d afrac In-Reply-To: <6.0.0.20.2.20050713190651.08e69620@itmail.it.aoyama.ac.jp> References: <200507122127.j6CLRQ7O000601@smtp-los04.proxy.aol.com> <200507122144.j6CLiPv9018403@smtp-los02.proxy.aol.com> <6.2.1.2.2.20050713043215.048b4eb0@mail.afrac.org> <008d01c58779$f5fe3f40$7f1afea9@oemcomputer> <6.0.0.20.2.20050713190651.08e69620@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [Ltru] Last call - the Draft must not be a political proposition X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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:28 13/07/2005, Martin Duerst wrote: >[with my co-chair hat on] >I'd like to thank JFC on actually submitting real text. >As both chairs have said repeatedly, this is the best way >to move things forward. > >For everybody: If you make an actual proposal (rather than just >discuss a proposal), please use a new subject. Also, please >indicate clearly that you want this change to happen as part >of WG Last Call. Otherwise, we're never sure whether that's >what you want, or whether your proposal is just "as an idea". Dear Martin, I make this proposition two technical propositions. There is no worst politics than to involve oneself in polical issues in not defining the boarder and whi is responsible of what. Unless this Draft wants to be a UN declaration. So, in believing one does not make policy one makes be error a political act. This Draft is not opposed for its technical aspects most ignores. It is strongly and w ill increasingly be opposed on political grounds. Silence is confusion. >[with my co-chair hat off] >I quite a bit agree with the sentiment in some of the text. >(I have worked on Internationalization of the WWW and the >Internet for a long time, so I hope this doesn't come as a >surprise.) However, as an engineer, I think that what counts >is the actual spec. As a technical project, the only thing >we can do is to try to produce good technology, and hope >it gets used the right way. You cannot use technology to impose political choices in political fields, what the Draft does. The first part of my text I keep in this part is an exact equivalent (and therefore necessary) of RFC 1591 which covers ISO 3166. This Draft otherwise is in contradiction with Jon Postel wise separation. Jon Postel commented ISO 3166, ISO 15924, ISO 639-X and UN.49 are no IETF documents and their exact authoritativeness is to be documented. The idea of correlating languages and countries is a very controverted political issue. It is not the role of IETF to take side. The argument to say this is not to be in an RFC it is like saying copyright mentions should not be in an RFC because these are lagalities. >Engineers in general, and the >IETF in particular, is rather bad at marketing and politics, >and I think we should stay away from it. True. And this is why it must be said. And politics to be left to politics. > Declarations like >those in JFC's proposed text are very important in political >fora, but in my opinion don't belong in a technical spec >(like ours). No. RFC 3066 was not really used and politics are not really aware of it. But RFC is a major political position. I do not think this political position belong to the ISO thao (the fact to permit a technical censoring on a political tag [I remind that ISO 3166 provide a code for a country name:Jon Postel associates it for IETF with the ccTLD Manager, here it is obviously linked to non Internet issues like Govs, Admin, Commerce]). If Govs through ISO Members have not ventured into that area I think (this is a pesonal point of view, but quite shared) it is a decision, not a lack. >The only bit where I'd like a bit more time to check the current >draft text is JFCs first paragraph. If we are not clear enough >that the draft and the registry don't define languages, but >only provide identifiers, then I think may be a problem. This is a major (also political and commercial issue). The problem is the same as ISO 3166 and creates a consistency problem. >But if this is the case, then this should be fixed mostly >by word tweaking, rather than by grandiose declarations. See next post. >As an example, looking at the first sentence of section @, >it currently starts "The language tag always defines a language...". >I think this should be changed to say >"The language tag always identifies a language..." This is not enough, because there are not enough information in the langtag to differentiate two languages elligible to the same langtag. This leads to the need to define the used words (this point was discussed after a proposition of yours). What is a language, what is its granularity? Again, I underline that we are here IETF not ISO. This means that we are not in a static description of language items, but dynamic exchanges qualifications. I repeat here the proposition of a leading paragraph. 1. it should include a definition of what are a language, a script and a region (country?) 2. it should include the following paragraph. "The IANA is not in the business of deciding what is and what is not an appropriate correlation between a language, a script, a country and other cultural or human language elements as they may appear necessary [RFC 1591] The selection of ISO 639 to obtain a language/script/country correlating table and rules was made with the knowldge that ISO has procedures to determine which resulting language tags should be and should not be on such a list. It happens that ISO 639 does not provide yet such a list. So, however the IANA is not in the business of deciding if this is a lack ISO still has to address or if it is a deliberated authoritative decision, the IANA intends to extend the possibilities offered to Internet protocols and applications users by RFC 3066. This Memo describes under which technical terms this may be done, notwithstanding the national or international legal limitations which may be imposed elsewhere to the users." jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 11:33:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsjEw-00088k-Kj; Wed, 13 Jul 2005 11: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 1DsjEr-00087J-V7 for ltru@megatron.ietf.org; Wed, 13 Jul 2005 11:33:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24299 for ; Wed, 13 Jul 2005 11:33:31 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsjhI-0007n6-Or for ltru@ietf.org; Wed, 13 Jul 2005 12:02:57 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DsjEp-0001uI-5W for ltru@ietf.org; Wed, 13 Jul 2005 08:33:31 -0700 Message-Id: <6.2.1.2.2.20050713164930.04adf8e0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 13 Jul 2005 17:26:42 +0200 To: From: r&d afrac In-Reply-To: <6.0.0.20.2.20050713190651.08e69620@itmail.it.aoyama.ac.jp> References: <200507122127.j6CLRQ7O000601@smtp-los04.proxy.aol.com> <200507122144.j6CLiPv9018403@smtp-los02.proxy.aol.com> <6.2.1.2.2.20050713043215.048b4eb0@mail.afrac.org> <008d01c58779$f5fe3f40$7f1afea9@oemcomputer> <6.0.0.20.2.20050713190651.08e69620@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: [Ltru] Last Call - Draft complying with equal ligusitic opportunity obligations X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 main reason why I and many will oppose this Draft is the abilty of use it and not to fully respect the obligations of equal linguistic opportunity obligations. A standard cannot force this, the same as it cannot force to respect IPRs which may be involved in applications, this is why it includes legal wording to show that infringements to IPRs in using the standard was not the intend of its authors and that its authors wanted the users of the standard would respect IPRs. The "equal lingustic opportunity declaration" is a general declaration which is proposed to address this problem. The text has been already review by members of most of the involved organisations in the Intergovernance. To refuse to adhere to this declaration or to its equivalent will be understood as a deliberate political position "not to". This shows how supposedly "not making policy" in not telling it approiprietly is the worst way to make politics. At 12:28 13/07/2005, Martin Duerst wrote: >Also, some of the wording proposed sounds a bit >too much like "Life, Liberty, and the Pursuit of Happiness" >(or "Liberte', Egalite', Fraternite'", or whatever your local >version), or seen from the negative side, like "motherhood and >applepie" (sorry, don't know what the French equivalent would >be). This wording is exactly derived from the Universal Declaration of Human Rights. I do not know your apple stuff meaning, but would it be good if some press used your remark as a way for an IETF WG Chair to qualify HRs? (just to show the risk not to document the intended boarder between technical and political issues when they correlate). Now, let understand that this wording as a "political protection" as other wording is mandatory "legal protection". There are two ways to introduce this text: 1. either in the Draft which wants to deal with language, as a declaration of intent to best respect HRs as they think it feasible (see below) 2. or through a specialised BCP imposing the wording to all the RFCs. This may be too much and create a debate which may be detimental to the image of the IETF (consider the remarks received here, being made and published on the main IETF list and their international impact). I want to defend the network and the people, not to damage IETF. Why is this technical? Because, the Draft does not support all the languages in the same way as English. It does not permit everyone from every language to equally share in R&D with the political, industrial, human impact this may have. Leading to a difference between people on the base of their knowledge or not of English, or their keyboard where HRs forbide them (becoming WG-ltru Members, or simply users or simply end-users). I can answer to the question of Martin on why they are not here (I am not sure we need such a debate, here and now). What becomes highly political in this Draft is when technical solutions (as the ones I work on) are not considered as they should. I therefore call for the following paragraph to be introduced to show the authors are bona fide persons. To show they tried their best to match the technical ethical challenges. Since I contest they tried it: it would seem very odd they refuse. "The IANA adheres to the language equal opportunity declaration, The purpose of technology isn't to insure that everybody should have an equal opportunity whatever his language, its purpose is to allow this goal. This document's aim is to allow everyone to freely share the cultural life of the Internet community, to enjoy using its solutions on an equal linguistic, cultural, technical, economical and commercial basis, and to share into the benefits of the technology and its advancements without distinction of any kind, such as race, colour, sex, language, religion, political or other opinion, national or social origin, property, birth or other status and education. Therefore the goal is to build a common technical standard for all people and all nations to be used or embedded in any technical solution, without any limitation resulting from the script, the language, the referent or the context of the technical environment. Taking into account the granular nature and the diversity of the world's digital ecosystem as well as the requirements of its technical convergence, the authors of this technical memorandum strongly advocate its free, secure and stable implementation to serve the rights and freedoms of its users at an international, national and personal level, in the respect of sovereign laws and jurisdiction of each State, of the empowerment of local cultures, and of its intergovernance by subsidiarity in any of the public or private, community or individual contexts. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 12:42:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DskJY-00014O-PG; Wed, 13 Jul 2005 12:42:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DskJW-00014G-RV for ltru@megatron.ietf.org; Wed, 13 Jul 2005 12:42:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01987 for ; Wed, 13 Jul 2005 12:42: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.43) id 1Dskly-0002Wg-Ai for ltru@ietf.org; Wed, 13 Jul 2005 13:11: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, 13 Jul 2005 09:42: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] Introduction change: suggested text Date: Wed, 13 Jul 2005 09:42:09 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C10972B@irvmbxw01.quest.com> Thread-Topic: [Ltru] Introduction change: suggested text Thread-Index: AcWHlfbk/REjsK+6THm/c97wicsAUgAMYyQg From: "Addison Phillips" To: "Martin Duerst" , "Randy Presuhn" , X-OriginalArrivalTime: 13 Jul 2005 16:42:07.0936 (UTC) FILETIME=[CEE72C00:01C587C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 think that the following sentiments are a good summary of my position = as well. In response to the particular suggestion of Martin's below, as well as a = previous thread concerning artificial languages and whether those were = excluded and so forth, I would like to propose that we change the text = at the start of Section 2 from: The language tag always defines a language as used (which includes = being spoken, written, signed, or otherwise signaled) by human beings = for communication of information to other human beings. Computer = languages such as programming languages are explicitly excluded. to read: The language tag is used to identify a language as used (which = includes being spoken, written, signed, or otherwise signaled) by human = beings for communication of information to other human beings. A = language of this type is sometimes called a 'natural language', and this = includes constructed or artificially designed languages, such as = Esperanto. Languages not intended primarily for human communication, = such as programming and other computer languages, are explicitly = excluded. 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 Martin Duerst > Sent: 2005?7?13? 3:28 > To: Randy Presuhn; ltru@ietf.org > Subject: Re: [Ltru] Proposed addition after introduction (was: = JerseyJE > andGuernsey GG Country Codes) >=20 >=20 > [with my co-chair hat off] > I quite a bit agree with the sentiment in some of the text. > (I have worked on Internationalization of the WWW and the > Internet for a long time, so I hope this doesn't come as a > surprise.)=20 [Addison Phillips]=20 Amen. However, as an engineer, I think that what counts > is the actual spec. As a technical project, the only thing > we can do is to try to produce good technology, and hope > it gets used the right way. Engineers in general, and the > IETF in particular, is rather bad at marketing and politics, > and I think we should stay away from it.=20 [Addison Phillips]=20 +1 >=20 > The only bit where I'd like a bit more time to check the current > draft text is JFCs first paragraph. If we are not clear enough > that the draft and the registry don't define languages, but > only provide identifiers, then I think may be a problem. > But if this is the case, then this should be fixed mostly > by word tweaking, rather than by grandiose declarations. > As an example, looking at the first sentence of section @, > it currently starts "The language tag always defines a language...". > I think this should be changed to say > "The language tag always identifies a language..." >=20 I agree: this text leads away from the intentions of the document and = from the spirit of RFC 1766 and RFC 3066 in general. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 16:41:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dso36-000055-MS; Wed, 13 Jul 2005 16:41:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dso34-0008Uc-IK for ltru@megatron.ietf.org; Wed, 13 Jul 2005 16:41:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07026 for ; Wed, 13 Jul 2005 16:41:30 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-res.bigfish.com ([63.161.60.61] helo=mail41-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsoVM-0008OA-0t for ltru@ietf.org; Wed, 13 Jul 2005 17:10:58 -0400 Received: from mail41-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail41-res-R.bigfish.com (Postfix) with ESMTP id 680A9A39A0B; Wed, 13 Jul 2005 20:41:19 +0000 (UTC) X-BigFish: VP Received: by mail41-res.bigfish.com (MessageSwitch) id 1121287279362070_8510; Wed, 13 Jul 2005 20:41:19 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail41-res.bigfish.com (Postfix) with ESMTP id 43719A3905E; Wed, 13 Jul 2005 20:41:19 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005071313485614:127198 ; Wed, 13 Jul 2005 13:48:56 -0700 To: "Doug Ewell" Subject: Re: [Ltru] Re: Jersey JE [NOTa last call issue] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Wed, 13 Jul 2005 13:38:19 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/13/2005 13:38:19, Serialize complete at 07/13/2005 13:38:19, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/13/2005 01:48:56 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/13/2005 01:48:59 PM, Serialize complete at 07/13/2005 01:48:59 PM Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Have you seen the W3C's ISO 639 reference pages? I've thrown them out. They contain many errors (very subtle ones in some cases that I'm sure have been implemented all over the world). Wikipedia's code list is better than W3C though I use the LoC list exclusively now. I'm not sure I'd call the W3C's update process rigorous from what I've seen. - KB "Doug Ewell" Sent by: ltru-bounces@lists.ietf.org 07/12/2005 09:58 PM To: "LTRU Working Group" cc: Subject: [Ltru] Re: Jersey JE and Guernsey GG Country Codes Peter Constable wrote: >> Hmmmm.... >> >> I got this from the W3C site... > > Would you consult the French government to find out about traffic > regulations in Wales? ISO 3166 is not maintained by W3C. I'm sure this > was provided with good intentions to be helpful to users, but it's > clearly a couple of years out of date -- it's been a while now since > DIN gave up the role of MA. In fairness, as much use as W3C makes of ISO standards, and as rigorously as they keep their pages up to date, it seems reasonable to assume that their pointer to ISO 3166/MA would be current. -- 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 Jul 13 18:45:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DspyV-00058j-6G; Wed, 13 Jul 2005 18:45:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DspyU-000575-6u for ltru@megatron.ietf.org; Wed, 13 Jul 2005 18:45:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22296 for ; Wed, 13 Jul 2005 18:45:03 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsqQm-0005k1-Jo for ltru@ietf.org; Wed, 13 Jul 2005 19:14:33 -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 RELAYIN10-b42d59953180; Wed, 13 Jul 2005 18:44:36 -0500 Received: from DEBHOME (ACD7B38E.ipt.aol.com [172.215.179.142]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j6DMiXjm007223; Wed, 13 Jul 2005 18:44:33 -0400 Message-Id: <200507132244.j6DMiXjm007223@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: , "'Doug Ewell'" Subject: RE: [Ltru] Re: Jersey JE [NOTa last call issue] Date: Wed, 13 Jul 2005 23:44:59 +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: AcWH6+Wo3xU7FhkzQl+0IIldyIJ90AADloAg 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: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org This is the difficulty with standards that are copied; the data integrity suffers and this makes a nonsense of standardization. I have had a few conversations with industry regarding this. IMHO (and remember this is just MHO), it would be far better for companies/government to pay a small annual maintenance/subscription fee to the Maintenance Agency in control of the standard, and be sure of the data whilst contributing to further development. In the interest of true standardization this is something that seriously needs looking at, in particular, when 7000+ languages come on board; not to mention 25,000+! (please don't all shout at me at once... I agree, in an ideal world, the data should be made freely available... but it still needs maintaining and financing somewhere... nothing in this life comes for free!) Best wishes Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Karen_Broome@spe.sony.com > Sent: 13 July 2005 21:38 > To: Doug Ewell > Cc: LTRU Working Group > Subject: Re: [Ltru] Re: Jersey JE [NOTa last call issue] > > Have you seen the W3C's ISO 639 reference pages? I've thrown them out. > They contain many errors (very subtle ones in some cases that I'm sure > have been implemented all over the world). Wikipedia's code list is > better than W3C though I use the LoC list exclusively now. I'm not sure > I'd call the W3C's update process rigorous from what I've seen. - KB > > > > > > > "Doug Ewell" > Sent by: ltru-bounces@lists.ietf.org > 07/12/2005 09:58 PM > > > To: "LTRU Working Group" > cc: > Subject: [Ltru] Re: Jersey JE and Guernsey GG Country Codes > > > Peter Constable wrote: > > >> Hmmmm.... > >> > >> I got this from the W3C site... > > > > Would you consult the French government to find out about traffic > > regulations in Wales? ISO 3166 is not maintained by W3C. I'm sure this > > was provided with good intentions to be helpful to users, but it's > > clearly a couple of years out of date -- it's been a while now since > > DIN gave up the role of MA. > > In fairness, as much use as W3C makes of ISO standards, and as > rigorously as they keep their pages up to date, it seems reasonable to > assume that their pointer to ISO 3166/MA would be current. > > -- > 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@lists.ietf.org Wed Jul 13 19:23:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsqZo-0002tO-2R; Wed, 13 Jul 2005 19:23:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsqZn-0002tJ-EH for ltru@megatron.ietf.org; Wed, 13 Jul 2005 19:23:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24513 for ; Wed, 13 Jul 2005 19:23:36 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsr2H-0006qk-L5 for ltru@ietf.org; Wed, 13 Jul 2005 19:53:06 -0400 Received: from h-68-166-189-219.snvacaid.dynamic.covad.net ([68.166.189.219] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DsqZl-00058f-00 for ltru@ietf.org; Wed, 13 Jul 2005 19:23:37 -0400 Message-ID: <004501c58801$ed946f40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Proposed addition after introduction Date: Wed, 13 Jul 2005 16:23: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.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 Hi - As Co-chair: Ok, I think we have a rough consensus to not make the full-blown addition. I think there is broad agreement that language tags do not "define" languages in any prescriptive sense, so editorial changes that make this clearer would be ok. As a technical contributor: I think the following passges merit purely editorial fixes to reduce the likelihood of misreading: Section 2: - The language tag always defines a language as used (which includes + The language tag always refers to a language as used (which includes Section 2.2.5: - variations that define a language or its dialects which are not + variations that characterize a language or its dialects which are not ("-" marks current wording; "+" marks proposed replacement.) Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 19:35:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsql5-0002Bk-O7; Wed, 13 Jul 2005 19:35:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsql4-0002Bf-46 for ltru@megatron.ietf.org; Wed, 13 Jul 2005 19:35:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24965 for ; Wed, 13 Jul 2005 19:35:14 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsrDZ-000772-2G for ltru@ietf.org; Wed, 13 Jul 2005 20:04:45 -0400 Received: from h-68-166-189-219.snvacaid.dynamic.covad.net ([68.166.189.219] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dsql2-0000IB-00 for ltru@ietf.org; Wed, 13 Jul 2005 19:35:16 -0400 Message-ID: <006701c58803$8f393e60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Subject: Fw: [Ltru] Re: [psg.com #1061] eliminate (or proscribe)Private Use Tags Date: Wed, 13 Jul 2005 16:35: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: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 - A message from Jefsey clearly intended for the ltru mailing list. Randy ----- Original Message ----- > From: "r&d afrac" > To: "Randy Presuhn" > Sent: Wednesday, July 13, 2005 7:03 AM > Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe)Private Use Tags > > On 08:51 13/07/2005, Randy Presuhn said: > >Hi - > > > > > From: "r&d afrac" > > > To: "Doug Ewell" ; "LTRU Working Group" > > > > > Sent: Tuesday, July 12, 2005 8:58 PM > > > Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe)Private > > Use Tags > > > > > > > > At 22:00 09/07/2005, Doug Ewell wrote: > > > >In the interest of achieving consensus, I won't argue further about the > > > >exact wording of this section. I do insist that private-use tags and > > > >subtags in "x-" not be removed from the grammar, or proscribed entirely. > > > >It MUST be legal for consenting adults to generate and interpret > > > >"x-this" and "en-x-that" in the privacy of their homes. > > > > > > I think confusion exists here. No one has ever considered that x-tags were > > > to be associated to adult extentions of a language. To the countrary one of > > > the applications of the x-tags in the "en" context you quote is precisely > > > to be able to use tags of the form of "en-x-kids" that could be made > > > mandatory for partental protection on "kid.us" namespace for example. > > > > > > If there is a confusion by a common US reader here, I recommand that some > > > examples are provided for further user guidance. > > > jfc > > > >I trust that your response is as tongue-in-cheek as Doug's. > > No. I am not to juge Doug's intents. But truely if Doug may say that, other > may think it. We now have the ".xxx" TLDs. The confusion is to be avoided. > > > >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 Wed Jul 13 19:36:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsqmG-0002WW-T7; Wed, 13 Jul 2005 19: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 1DsqmE-0002WR-O2 for ltru@megatron.ietf.org; Wed, 13 Jul 2005 19:36:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25017 for ; Wed, 13 Jul 2005 19:36:27 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsrEj-00078V-TV for ltru@ietf.org; Wed, 13 Jul 2005 20:05:58 -0400 Received: from h-68-166-189-219.snvacaid.dynamic.covad.net ([68.166.189.219] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DsqmD-0000gV-00 for ltru@ietf.org; Wed, 13 Jul 2005 19:36:29 -0400 Message-ID: <006c01c58803$bb394820$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Subject: Fw: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags Date: Wed, 13 Jul 2005 16:36: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.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 - Another message from Jefsey clearly intended for the WG mailing list. Randy ----- Original Message ----- > From: "r&d afrac" > To: "Randy Presuhn" > Sent: Wednesday, July 13, 2005 7:08 AM > Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags > > On 09:01 13/07/2005, Randy Presuhn said: > >Hi - > > > > > From: "r&d afrac" > > > To: "Randy Presuhn" ; "LTRU Working > > Group" > > > Sent: Tuesday, July 12, 2005 5:28 PM > > > Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) > > Private Use Tags > > > > > > At 22:28 09/07/2005, Randy Presuhn wrote: > > > >Hi - > > > > > From: "Doug Ewell" > > > > > To: "LTRU Working Group" > > > > > Sent: Saturday, July 09, 2005 1:00 PM > > > > > Subject: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private > > > > Use Tags > > > > > > > > > > > > > > In the interest of achieving consensus, I won't argue further about the > > > > > exact wording of this section. I do insist that private-use tags and > > > > > subtags in "x-" not be removed from the grammar, or proscribed > > entirely. > > > > > It MUST be legal for consenting adults to generate and interpret > > > > > "x-this" and "en-x-that" in the privacy of their homes. > > > >... > > > > > > > >I think we're all agreed on that. Based on the discussion, I'll leave > > it to > > > >the editors to pick appropriate words to reflect our rough consensus that > > > >private use tags and subtags should remain in the document, but there > > should > > > >be a "health warning" regarding the risks associated with using > > them. Several > > > >alternative wordings have been offered, and I think the feedback on the > > > >mailing > > > >list will provide sufficient guidance to the editors to form text we > > can live > > > >with. > > > > > > I am obliged to come back on this. If the editors are to form a text we can > > > live with, I think we also could. And if cannot, we should make clear in a > > > note, or through a consensus of this group, that it has never been > > > considered that "x-" tags could ever have to do with pornography (or > > > exclusion as some of comments I received during the ICANN meeting). > > > > > > >With that, I'll mark this issue resolved. If someone finds the words they > > > >choose unacceptable, we can re-open the issue. > > > > > > I reopen the issue, not necessarily on the text itself but about the > > > guidance given to the editor. > > > jfc > > > >If you really believe issue #1061 needs to be re-opened, > >please identify the specific text in the draft you object to and > >the text you would propose in its place. > > "The use of "x-" has no particular meaning regarding the nature of the > private subtags." > or > "The use of "x-" is to introduce the private extension of the format. It > may in particular be used for multilingual or punycoded subtags." > > The Alpha8 is discreminatory against internationalised subtags, as punycode > can imply punycoded string of different length for internationalised > strings of similar length. > jfc > > > >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@lists.ietf.org Wed Jul 13 19:54:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsr3D-00048k-Dd; Wed, 13 Jul 2005 19:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsr3B-00043B-QQ for ltru@megatron.ietf.org; Wed, 13 Jul 2005 19:54:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25742 for ; Wed, 13 Jul 2005 19:53:58 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsrVg-0007ZL-VU for ltru@ietf.org; Wed, 13 Jul 2005 20:23:29 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 16:53: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.1830); Wed, 13 Jul 2005 16:53:51 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private UseTags Date: Wed, 13 Jul 2005 16:53:50 -0700 Message-ID: Thread-Topic: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private UseTags Thread-Index: AcWIA/BVTcRlTlVzRAKNCNM373I/8AAAJNqA From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 13 Jul 2005 23:53:51.0244 (UTC) FILETIME=[1E7A4CC0:01C58806] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 > Another message from Jefsey clearly intended for the WG mailing list. > > >If you really believe issue #1061 needs to be re-opened, > > >please identify the specific text in the draft you object to and > > >the text you would propose in its place. > > > > "The use of "x-" has no particular meaning regarding the nature of the > > private subtags." -1. The interpretation of this is unclear, and even if it were clarified it doesn't appear to add anything significant. > > or > > "The use of "x-" is to introduce the private extension of the format. It > > may in particular be used for multilingual or punycoded subtags." > > > > The Alpha8 is discreminatory against internationalised subtags, as punycode > > can imply punycoded string of different length for internationalised > > strings of similar length. The use of Alpha and AlphaNum, which JFC considers a discriminatory limitation, is nothing of the sort, and cannot be changed unless backward compatibility is to be abandoned. Since there was consensus from the outset that backward compatibility must be maintained, and since it was clear from the last call back in December that backward compatibility with protocols that consume RFC 3066 is essential, then I think this is not open to reconsideration, and therefore this proposed text cannot be accepted. Thus, I think this issue can remain closed. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 19:58:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsr7G-0007LS-L8; Wed, 13 Jul 2005 19: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 1Dsr7F-0007Jo-8z for ltru@megatron.ietf.org; Wed, 13 Jul 2005 19:58:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25867 for ; Wed, 13 Jul 2005 19:58:10 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsrZk-0007eS-QJ for ltru@ietf.org; Wed, 13 Jul 2005 20:27:41 -0400 Received: from h-68-166-189-219.snvacaid.dynamic.covad.net ([68.166.189.219] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dsr7D-0006B6-00 for ltru@ietf.org; Wed, 13 Jul 2005 19:58:11 -0400 Message-ID: <008101c58806$c264e2a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <006c01c58803$bb394820$7f1afea9@oemcomputer> Date: Wed, 13 Jul 2005 16:58:25 -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: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Ltru] "x" doesn't "mean" anything (was: [psg.com #1061] eliminate (or proscribe) Private UseTags) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - Can I get a hum on whether to add the proposed text? Randy, ltru co-chair > From: "r&d afrac" > To: "Randy Presuhn" > Sent: Wednesday, July 13, 2005 7:08 AM > Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private Use Tags ... > "The use of "x-" has no particular meaning regarding the nature of the > private subtags." > or > "The use of "x-" is to introduce the private extension of the format. It > may in particular be used for multilingual or punycoded subtags." > > The Alpha8 is discreminatory against internationalised subtags, as punycode > can imply punycoded string of different length for internationalised > strings of similar length. ... Presumably this would go in 2.2 where it currently says: o The single letter subtag 'x' is reserved to introduce a sequence of private-use subtags. The interpretation of any private-use subtags is defined solely by private agreement and is not defined by the rules in this section or in any standard or registry defined in this document. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 20:33:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsrev-00016F-4g; Wed, 13 Jul 2005 20: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 1Dsret-00015F-PK for ltru@megatron.ietf.org; Wed, 13 Jul 2005 20:32:59 -0400 Received: from gundel.de.clara.net (gundel.de.clara.net [212.82.225.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27257 for ; Wed, 13 Jul 2005 20:32:47 -0400 (EDT) Received: from [62.80.58.146] (helo=xyzzy) by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD) id 1Dsrru-000MdQ-3x for ltru@lists.ietf.org; Thu, 14 Jul 2005 02:46:26 +0200 Message-ID: <42D5B276.253C@xyzzy.claranet.de> Date: Thu, 14 Jul 2005 02:31:50 +0200 From: Frank Ellermann Organization: X-Mailer: Mozilla 3.0 (OS/2; U) MIME-Version: 1.0 To: ltru@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re:Proposed addition after introduction X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Martin Duerst wrote: > I quite a bit agree with the sentiment in some of the text. [...] > However, as an engineer, I think that what counts is the > actual spec. [...] > Engineers in general, and the IETF in particular, is rather > bad at marketing and politics, and I think we should stay > away from it. Declarations like those in JFC's proposed text > are very important in political fora, but in my opinion don't > belong in a technical spec (like ours). Also, some of the > wording proposed sounds a bit too much like "Life, Liberty, > and the Pursuit of Happiness" [...] +1 And we're not in the position to define what IANA "adheres to", that's determined by VeriSign or whoever governs ICANN at the moment. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 20: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 1Dsruk-0002xJ-S6; Wed, 13 Jul 2005 20: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 1Dsrui-0002wz-Q7 for ltru@megatron.ietf.org; Wed, 13 Jul 2005 20:49:21 -0400 Received: from gundel.de.clara.net (gundel.de.clara.net [212.82.225.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28133 for ; Wed, 13 Jul 2005 20:49:19 -0400 (EDT) Received: from [62.80.58.146] (helo=xyzzy) by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD) id 1Dss7u-000NYU-2Y for ltru@lists.ietf.org; Thu, 14 Jul 2005 03:02:58 +0200 Message-ID: <42D5B629.171A@xyzzy.claranet.de> Date: Thu, 14 Jul 2005 02:47:37 +0200 From: Frank Ellermann Organization: X-Mailer: Mozilla 3.0 (OS/2; U) MIME-Version: 1.0 To: ltru@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Introduction change: suggested 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: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips proposed: | The language tag is used to identify a language as used | (which includes being spoken, written, signed, or otherwise | signaled) by human beings for communication of information to | other human beings. A language of this type is sometimes | called a 'natural language', and this includes constructed or | artificially designed languages, such as Esperanto. Languages | not intended primarily for human communication, such as | programming and other computer languages, are explicitly | excluded. (= result after s/define/identify/ and some beautifications) FWIW, I like it, bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 21:00:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dss5Y-0001LA-AD; Wed, 13 Jul 2005 21: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 1Dss5W-0001Kz-OK for ltru@megatron.ietf.org; Wed, 13 Jul 2005 21:00:30 -0400 Received: from gundel.de.clara.net (gundel.de.clara.net [212.82.225.86]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28759 for ; Wed, 13 Jul 2005 21:00:28 -0400 (EDT) Received: from [62.80.58.146] (helo=xyzzy) by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD) id 1DssIi-000O3u-5G for ltru@lists.ietf.org; Thu, 14 Jul 2005 03:14:08 +0200 Message-ID: <42D5B906.4A2B@xyzzy.claranet.de> Date: Thu, 14 Jul 2005 02:59:50 +0200 From: Frank Ellermann Organization: X-Mailer: Mozilla 3.0 (OS/2; U) MIME-Version: 1.0 To: ltru@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: "x" doesn't "mean" anything X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > Can I get a hum on whether to add the proposed text? What's the opposite of "hum" ? Whatever it might be, please assume that I've done it. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 21:08:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DssD4-000623-TV; Wed, 13 Jul 2005 21: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 1DssD3-00061m-RG for ltru@megatron.ietf.org; Wed, 13 Jul 2005 21:08:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29572 for ; Wed, 13 Jul 2005 21:08:16 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DssfZ-00014p-A1 for ltru@ietf.org; Wed, 13 Jul 2005 21:37:46 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6E184I26621; Thu, 14 Jul 2005 10:08:04 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 62678d88_f405_11d9_9d1e_0030482532aa_12514; Thu, 14 Jul 2005 10:19:54 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0082D6; 14 Jul 05 10:13:42 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 14 Jul 05 10:13:21 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0082D5; 14 Jul 05 10:13:15 +0900 Message-Id: <6.0.0.20.2.20050714100144.08e6f4d0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 14 Jul 2005 10:07:29 +0900 To: "Randy Presuhn" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] "x" doesn't "mean" anything (was: [psg.com #1061] eliminate(or proscribe) Private UseTags) In-Reply-To: <008101c58806$c264e2a0$7f1afea9@oemcomputer> References: <006c01c58803$bb394820$7f1afea9@oemcomputer> <008101c58806$c264e2a0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 I'm clearly against it, for several reasons: - I don't like punycode, and I don't think it should get any mention or use in any context other than internationalized domain names (where it should be strictly limited to use within the protocol, and the necessary application stubs, but not be exposed to the user). - I think that of all things, language tags should stay ASCII only. I have worked, and am still working, to get more and more of the Web and the Internet internationalized. This includes Web addresses and domain names. The reason for the difference between language tags and domain names and so is that language tags are on a lower level. I.e. it doesn't make sense to have language tags in multiple languages or scripts, because this would create difficult bootstrap issues. - Please note that alpha-8 is discriminatory for languages that use the Latin script, too. Many words are longer than 8 letters. Regards, Martin. At 08:58 05/07/14, Randy Presuhn wrote: >Hi - > >Can I get a hum on whether to add the proposed text? > >Randy, ltru co-chair > > >> From: "r&d afrac" >> To: "Randy Presuhn" >> Sent: Wednesday, July 13, 2005 7:08 AM >> Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) Private >Use Tags >... >> "The use of "x-" has no particular meaning regarding the nature of the >> private subtags." >> or >> "The use of "x-" is to introduce the private extension of the format. It >> may in particular be used for multilingual or punycoded subtags." >> >> The Alpha8 is discreminatory against internationalised subtags, as punycode >> can imply punycoded string of different length for internationalised >> strings of similar length. >... > >Presumably this would go in 2.2 where it currently says: > o The single letter subtag 'x' is reserved to introduce a sequence > of private-use subtags. The interpretation of any private-use > subtags is defined solely by private agreement and is not defined > by the rules in this section or in any standard or registry > defined in 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@lists.ietf.org Wed Jul 13 21: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 1DssJZ-0000mN-AY; Wed, 13 Jul 2005 21:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DssJX-0000kV-6B for ltru@megatron.ietf.org; Wed, 13 Jul 2005 21:14:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00069 for ; Wed, 13 Jul 2005 21:14:57 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dssm2-0001Hs-UC for ltru@ietf.org; Wed, 13 Jul 2005 21:44:27 -0400 Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6E1EmI26960; Thu, 14 Jul 2005 10:14:48 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id 5ac2a6da_f405_11d9_9cce_0030482533a1_4519; Thu, 14 Jul 2005 10:19:41 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0082DD; 14 Jul 05 10:20:26 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 14 Jul 05 10:20:20 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0082DB; 14 Jul 05 10:20:19 +0900 Message-Id: <6.0.0.20.2.20050714101054.08e7d070@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 14 Jul 2005 10:14:14 +0900 To: Frank Ellermann , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] Re:Proposed addition after introduction In-Reply-To: <42D5B276.253C@xyzzy.claranet.de> References: <42D5B276.253C@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: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 09:31 05/07/14, Frank Ellermann wrote: >+1 And we're not in the position to define what IANA "adheres >to", that's determined by VeriSign or whoever governs ICANN at >the moment. While we cannot, by writing a document, be absolutely sure that IANA isn't going to do something different, we are definitely supposed to write our document so that IANA can "adhere to" it, i.e. follow its instructions. IANA is a secretarial or clerical function; they prefer to have exact and easy-to-follow instructions for what to do. That of course means that they'd probably get scared by any politically colored instructions. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 21: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 1DssJZ-0000ml-Go; Wed, 13 Jul 2005 21:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DssJX-0000kz-VM for ltru@megatron.ietf.org; Wed, 13 Jul 2005 21:15:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00072 for ; Wed, 13 Jul 2005 21:14:58 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dssm2-0001Hr-MI for ltru@ietf.org; Wed, 13 Jul 2005 21:44:28 -0400 Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6E1ElC17940; Thu, 14 Jul 2005 10:14:48 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id 5a432a90_f405_11d9_9cce_0030482533a1_4519; Thu, 14 Jul 2005 10:19:41 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0082DC; 14 Jul 05 10:20:26 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 14 Jul 05 10:20:20 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0082DA; 14 Jul 05 10:20:19 +0900 Message-Id: <6.0.0.20.2.20050714100949.08e78180@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 14 Jul 2005 10:10:39 +0900 To: Frank Ellermann , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: "x" doesn't "mean" anything In-Reply-To: <42D5B906.4A2B@xyzzy.claranet.de> References: <42D5B906.4A2B@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: 1ac7cc0a4cd376402b85bc1961a86ac2 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 At 09:59 05/07/14, Frank Ellermann wrote: >Randy Presuhn wrote: > >> Can I get a hum on whether to add the proposed text? > >What's the opposite of "hum" ? Whatever it might be, >please assume that I've done it. Bye, Frank At IETF meetings, there are usually two or more hums, e.g. a hum for and a hum against a proposal. So I'm assuming that you hummed against. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 21:25:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DssTf-0007BO-K7; Wed, 13 Jul 2005 21:25:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DssTe-0007BG-0c for ltru@megatron.ietf.org; Wed, 13 Jul 2005 21:25:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00569 for ; Wed, 13 Jul 2005 21:25:24 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dssw8-0001ZV-Qf for ltru@ietf.org; Wed, 13 Jul 2005 21:54:54 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6E1PDC18751; Thu, 14 Jul 2005 10:25:13 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id c81b96ea_f407_11d9_8c88_0030482532aa_12521; Thu, 14 Jul 2005 10:37:04 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0082EA; 14 Jul 05 10:30:51 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 14 Jul 05 10:30:26 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0082E8; 14 Jul 05 10:30:16 +0900 Message-Id: <6.0.0.20.2.20050714102202.08e74b00@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 14 Jul 2005 10:24:24 +0900 To: Karen_Broome@spe.sony.com, "Doug Ewell" From: Martin Duerst Subject: Re: [Ltru] Re: Jersey JE [NOTa last call issue] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I have asked the relevant people at W3C to fix the page. (I.e. remove the data and point to the authoritative source) The page was put up at a time when the Web was very young, but wasn't actively maintained for years. The LOC list is as authoritative as it gets. Regards, Martin. At 05:38 05/07/14, Karen_Broome@spe.sony.com wrote: >Have you seen the W3C's ISO 639 reference pages? I've thrown them out. >They contain many errors (very subtle ones in some cases that I'm sure >have been implemented all over the world). Wikipedia's code list is >better than W3C though I use the LoC list exclusively now. I'm not sure >I'd call the W3C's update process rigorous from what I've seen. - KB > > > > > > >"Doug Ewell" >Sent by: ltru-bounces@lists.ietf.org >07/12/2005 09:58 PM > > > To: "LTRU Working Group" > cc: > Subject: [Ltru] Re: Jersey JE and Guernsey GG Country Codes > > >Peter Constable wrote: > >>> Hmmmm.... >>> >>> I got this from the W3C site... >> >> Would you consult the French government to find out about traffic >> regulations in Wales? ISO 3166 is not maintained by W3C. I'm sure this >> was provided with good intentions to be helpful to users, but it's >> clearly a couple of years out of date -- it's been a while now since >> DIN gave up the role of MA. > >In fairness, as much use as W3C makes of ISO standards, and as >rigorously as they keep their pages up to date, it seems reasonable to >assume that their pointer to ISO 3166/MA would be current. > >-- >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@lists.ietf.org Wed Jul 13 21:39:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dssha-0007Js-5S; Wed, 13 Jul 2005 21:39:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsshX-0007CV-Fe for ltru@megatron.ietf.org; Wed, 13 Jul 2005 21:39:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01217 for ; Wed, 13 Jul 2005 21:39:45 -0400 (EDT) Received: from gundel.de.clara.net ([212.82.225.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DstA2-0001vI-Np for ltru@ietf.org; Wed, 13 Jul 2005 22:09:16 -0400 Received: from [62.80.58.146] (helo=xyzzy) by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD) id 1Dssua-0000hg-TM; Thu, 14 Jul 2005 03:53:17 +0200 Message-ID: <42D5C1D4.1897@xyzzy.claranet.de> Date: Thu, 14 Jul 2005 03:37:24 +0200 From: Frank Ellermann Organization: X-Mailer: Mozilla 3.0 (OS/2; U) MIME-Version: 1.0 To: ltru@ietf.org References: <42D5B906.4A2B@xyzzy.claranet.de> <6.0.0.20.2.20050714100949.08e78180@itmail.it.aoyama.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: "x" doesn't "mean" anything X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Martin Duerst wrote: > I'm assuming that you hummed against. Yes, I didn't know that that's possible, it's dangerously near to "voting". ;-) So just to be sure that this was no "vote", there are numerous places where an "X" stands for very different things like "eXtended", and many kinds of "U" like "undefined" or "unknown", e.g. MIME or mail X-header fields. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 13 21:59:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dst10-000261-5e; Wed, 13 Jul 2005 21: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 1Dst0y-00025t-E5 for ltru@megatron.ietf.org; Wed, 13 Jul 2005 21:59:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02095 for ; Wed, 13 Jul 2005 21:59:48 -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.43) id 1DstTR-0002OM-Nz for ltru@ietf.org; Wed, 13 Jul 2005 22:29: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, 13 Jul 2005 18:59: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] "x" doesn't "mean" anything (was: [psg.com #1061] eliminate(or proscribe) Private UseTags) Date: Wed, 13 Jul 2005 18:59:31 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D062@irvmbxw01.quest.com> Thread-Topic: [Ltru] "x" doesn't "mean" anything (was: [psg.com #1061] eliminate(or proscribe) Private UseTags) Thread-Index: AcWIBvDdsQXQQzmeQVeIjN8O5hjcAwADoxGg From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 14 Jul 2005 01:59:32.0367 (UTC) FILETIME=[AD5659F0:01C58817] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 -1 on the proposal. The use of 'x-' introduces private use subtags, which are defined at = length. If someone wishes to create a private agreement to use these for = some kind of extension, it is none of our business. The restriction to lengths of up to eight characters is for = compatibility purposes, a restriction I agree with. Punycode of up to eight characters in length (i.e. not very useful) in a = private use tag is not our concern. Non-ASCII values break long standing = compatibility, especially since a well-known use of language tags is in = MIME headers, which are explicitly ASCII-only. Language tags are identifiers, not the thing itself. 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: 2005?7?13? 16:58 > To: LTRU Working Group > Subject: [Ltru] "x" doesn't "mean" anything (was: [psg.com #1061] > eliminate(or proscribe) Private UseTags) >=20 > Hi - >=20 > Can I get a hum on whether to add the proposed text? >=20 > Randy, ltru co-chair >=20 >=20 > > From: "r&d afrac" > > To: "Randy Presuhn" > > Sent: Wednesday, July 13, 2005 7:08 AM > > Subject: Re: [Ltru] Re: [psg.com #1061] eliminate (or proscribe) = Private > Use Tags > ... > > "The use of "x-" has no particular meaning regarding the nature of = the > > private subtags." > > or > > "The use of "x-" is to introduce the private extension of the = format. It > > may in particular be used for multilingual or punycoded subtags." > > > > The Alpha8 is discreminatory against internationalised subtags, as > punycode > > can imply punycoded string of different length for internationalised > > strings of similar length. > ... >=20 > Presumably this would go in 2.2 where it currently says: > o The single letter subtag 'x' is reserved to introduce a sequence > of private-use subtags. The interpretation of any private-use > subtags is defined solely by private agreement and is not = defined > by the rules in this section or in any standard or registry > defined in this document. >=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 Thu Jul 14 01:05:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsvud-000358-WC; Thu, 14 Jul 2005 01:05:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsvuY-00034c-Lu for ltru@megatron.ietf.org; Thu, 14 Jul 2005 01:05:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10729 for ; Thu, 14 Jul 2005 01:05:24 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DswN2-0006z3-0i for ltru@ietf.org; Thu, 14 Jul 2005 01:34:55 -0400 Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6E54xI12392; Thu, 14 Jul 2005 14:04:59 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id 82c113b8_f425_11d9_8eae_0030482533a1_4539; Thu, 14 Jul 2005 14:09:52 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO008383; 14 Jul 05 14:10:37 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 14 Jul 05 14:10:17 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG008382; 14 Jul 05 14:10:09 +0900 Message-Id: <6.0.0.20.2.20050714103409.05325940@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 14 Jul 2005 10:36:31 +0900 To: "Addison Phillips" , "Randy Presuhn" , From: Martin Duerst Subject: RE: [Ltru] Introduction change: suggested text In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C10972B@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C10972B@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 While we are at it, I propose that we change: The language tag is used to identify a language as used (which includes being spoken, written, signed, or otherwise signaled) by human beings for communication of information to other human beings. to: The language tag is used to identify a language as used by human beings for communication of information to other human beings. This includes language being spoken, written, signed, or otherwise signaled. [I'm not totally happy yet with the second sentence, but I'm happy that the parentheses, which were difficult to parse, are gone.] Regards, Martin. At 01:42 05/07/14, Addison Phillips wrote: >I think that the following sentiments are a good summary of my position as well. > >In response to the particular suggestion of Martin's below, as well as a >previous thread concerning artificial languages and whether those were >excluded and so forth, I would like to propose that we change the text at >the start of Section 2 from: > >The language tag always defines a language as used (which includes being >spoken, written, signed, or otherwise signaled) by human beings for >communication of information to other human beings. Computer languages such >as programming languages are explicitly excluded. > >to read: > >The language tag is used to identify a language as used (which includes >being spoken, written, signed, or otherwise signaled) by human beings for >communication of information to other human beings. A language of this type >is sometimes called a 'natural language', and this includes constructed or >artificially designed languages, such as Esperanto. Languages not intended >primarily for human communication, such as programming and other computer >languages, are explicitly excluded. > >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 Martin Duerst >> Sent: 2005?7?13? 3:28 >> To: Randy Presuhn; ltru@ietf.org >> Subject: Re: [Ltru] Proposed addition after introduction (was: JerseyJE >> andGuernsey GG Country Codes) >> >> >> [with my co-chair hat off] >> I quite a bit agree with the sentiment in some of the text. >> (I have worked on Internationalization of the WWW and the >> Internet for a long time, so I hope this doesn't come as a >> surprise.) >[Addison Phillips] > >Amen. > >However, as an engineer, I think that what counts >> is the actual spec. As a technical project, the only thing >> we can do is to try to produce good technology, and hope >> it gets used the right way. Engineers in general, and the >> IETF in particular, is rather bad at marketing and politics, >> and I think we should stay away from it. >[Addison Phillips] > >+1 >> >> The only bit where I'd like a bit more time to check the current >> draft text is JFCs first paragraph. If we are not clear enough >> that the draft and the registry don't define languages, but >> only provide identifiers, then I think may be a problem. >> But if this is the case, then this should be fixed mostly >> by word tweaking, rather than by grandiose declarations. >> As an example, looking at the first sentence of section @, >> it currently starts "The language tag always defines a language...". >> I think this should be changed to say >> "The language tag always identifies a language..." >> >I agree: this text leads away from the intentions of the document and from >the spirit of RFC 1766 and RFC 3066 in general. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 02:07:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dswsu-00066G-Ow; Thu, 14 Jul 2005 02:07:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dswst-00066B-Gk for ltru@megatron.ietf.org; Thu, 14 Jul 2005 02:07:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23696 for ; Thu, 14 Jul 2005 02:07:46 -0400 (EDT) Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsxLN-0000xd-S7 for ltru@ietf.org; Thu, 14 Jul 2005 02:37:15 -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 6929DD05 for ; Thu, 14 Jul 2005 09:07:30 +0300 (EEST) Date: Thu, 14 Jul 2005 09:07:29 +0300 (EEST) From: "Jukka K. Korpela" To: ltru@ietf.org Subject: RE: [Ltru] Introduction change: suggested text In-Reply-To: <6.0.0.20.2.20050714103409.05325940@itmail.it.aoyama.ac.jp> Message-ID: References: <634978A7DF025A40BFEF33EB191E13BC0C10972B@irvmbxw01.quest.com> <6.0.0.20.2.20050714103409.05325940@itmail.it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Thu, 14 Jul 2005, Martin Duerst wrote: > While we are at it, I propose that we change: > > The language tag is used to identify a language as used (which includes > being spoken, written, signed, or otherwise signaled) by human beings for > communication of information to other human beings. > > to: > > The language tag is used to identify a language as used by human beings > for communication of information to other human beings. This includes > language being spoken, written, signed, or otherwise signaled. The change looks like an improvement to me. Anything that removes parentheses without introducing ambiguity is usually an improvement. I'm afraid it still isn't restrictive enough. People have created all kinds of communication conventions that might be called languages by some but really aren't languages in the ordinary sense, or in the sense intended here. For example, textbooks on bridge, the card game, often describe a bidding system as being a language, used to communicate information on player's hands. Or consider private conventions by two persons on the use of a few gestures to communicate information. Though "languages" in a sense, they really aren't general means of communication; a human language proper can be used to express anything, in principle, since it contains some mechanism of defining new words, among other things. Although a really satisfactory definition probably cannot be given here, I'd suggest a simple change that tries to improve it as regards to the nature of language: removal of the words "of information". That is: The language tag is used to identify a language as used by human beings for communication to other human beings. This includes language being spoken, written, signed, or otherwise signaled. Human language is not limited to communicating information. We can say "What a lovely evening!", which is an expression of feelings and impressions, or "I will", which is a promise, or "Please give me the sugar", which is a request. (It would be artificial to call an expression of emotions or a request acts of communicating information. The clearest of all is a promise: it does not simply express an intention but actually makes a promise and commits to something, at least morally.) -- 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@lists.ietf.org Thu Jul 14 02:48:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsxWF-00015r-JL; Thu, 14 Jul 2005 02:48:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsxWE-00015m-BS for ltru@megatron.ietf.org; Thu, 14 Jul 2005 02:48:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10526 for ; Thu, 14 Jul 2005 02:48:25 -0400 (EDT) Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsxyk-0002RV-1o for ltru@ietf.org; Thu, 14 Jul 2005 03:17:57 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id B6D5B4444; Thu, 14 Jul 2005 15:47:56 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09444-06; Thu, 14 Jul 2005 15:47:56 +0900 (JST) Received: from ibm-60d333fc0ec.w3.mag.keio.ac.jp (tea13.w3.mag.keio.ac.jp [133.27.228.243]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 72BA64059; Thu, 14 Jul 2005 15:47:56 +0900 (JST) To: "Jukka K. Korpela" , ltru@ietf.org Subject: Re: [Ltru] Introduction change: suggested text References: <634978A7DF025A40BFEF33EB191E13BC0C10972B@irvmbxw01.quest.com> <6.0.0.20.2.20050714103409.05325940@itmail.it.aoyama.ac.jp> Message-ID: Date: Thu, 14 Jul 2005 15:47:50 +0900 From: "Felix Sasaki" Organization: W3C Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 In-Reply-To: User-Agent: Opera M2/8.0 (Win32, build 7561) X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 In various fields of linguistics, there are various definitions what a =20 "language" is. It seems to me that Jukka refers to are various types of =20 speech acts in the sense of Searle, John. 1969. Speech acts: An essay in the philosophy of language. = =20 Cambridge, England: Cambridge University. There are many different opinions on how speech acts can be defined. But = I =20 have never seen anybody defining various types of speech acts as differen= t =20 languages. So I would vote for keeping "of information". -- Felix On Thu, 14 Jul 2005 15:07:29 +0900, Jukka K. Korpela = =20 wrote: > On Thu, 14 Jul 2005, Martin Duerst wrote: > >> While we are at it, I propose that we change: >> >> The language tag is used to identify a language as used (which include= s >> being spoken, written, signed, or otherwise signaled) by human beings = =20 >> for >> communication of information to other human beings. >> >> to: >> >> The language tag is used to identify a language as used by human being= s >> for communication of information to other human beings. This includes >> language being spoken, written, signed, or otherwise signaled. > > The change looks like an improvement to me. Anything that removes =20 > parentheses without introducing ambiguity is usually an improvement. > > I'm afraid it still isn't restrictive enough. People have created all =20 > kinds of communication conventions that might be called languages by =20 > some but really aren't languages in the ordinary sense, or in the sense= =20 > intended here. For example, textbooks on bridge, the card game, often =20 > describe a bidding system as being a language, used to communicate =20 > information on player's hands. Or consider private conventions by two =20 > persons on the use of a few gestures to communicate information. > Though "languages" in a sense, they really aren't general means of =20 > communication; a human language proper can be used to express anything,= =20 > in principle, since it contains some mechanism of defining new words, > among other things. > > Although a really satisfactory definition probably cannot be given here= , =20 > I'd suggest a simple change that tries to improve it as regards to the = =20 > nature of language: removal of the words "of information". That is: > > The language tag is used to identify a language as used by human =20 > beings > for communication to other human beings. This includes > language being spoken, written, signed, or otherwise signaled. > > Human language is not limited to communicating information. > We can say "What a lovely evening!", which is an expression of feelings= =20 > and impressions, or "I will", which is a promise, or "Please give me th= e =20 > sugar", which is a request. (It would be artificial to call an =20 > expression of emotions or a request acts of communicating information. = =20 > The clearest of all is a promise: it does not simply express an =20 > intention but actually makes a promise and commits to something, at =20 > least morally.) > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 03:04:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsxlY-0008QN-Kg; Thu, 14 Jul 2005 03:04:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsxlW-0008P0-Sd for ltru@megatron.ietf.org; Thu, 14 Jul 2005 03:04:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11428 for ; Thu, 14 Jul 2005 03:04:13 -0400 (EDT) Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsyE4-00030F-Tl for ltru@ietf.org; Thu, 14 Jul 2005 03:33:46 -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 76D86CC3 for ; Thu, 14 Jul 2005 10:04:04 +0300 (EEST) Date: Thu, 14 Jul 2005 10:04:03 +0300 (EEST) From: "Jukka K. Korpela" To: ltru@ietf.org Subject: Re: [Ltru] Introduction change: suggested text In-Reply-To: Message-ID: References: <634978A7DF025A40BFEF33EB191E13BC0C10972B@irvmbxw01.quest.com> <6.0.0.20.2.20050714103409.05325940@itmail.it.aoyama.ac.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Thu, 14 Jul 2005, Felix Sasaki wrote: > In various fields of linguistics, there are various definitions what a > "language" is. Surely, but that's not the point. The point is that language is, in reality, used for much more than communication of information. Our everyday use of language is mostly something else, though with occasional pieces of information thrown in. We keep forgetting this in technical and scientific discussions, where the information density is much higher. > It seems to me that Jukka refers to are various types of > speech acts - - Well, my argument is indeed based on such things, but it did not mean classifying each speech act as a separate language. Instead, what I wrote was about defining language as something used for communication, not just communication of information. > There are many different opinions on how speech acts can be defined. But I > have never seen anybody defining various types of speech acts as different > languages. And neither did you see that now. I did nothing of the kind. > So I would vote for keeping "of information". But that would mean just the opposite of what you wrote: you would count only such speech acts as belonging to a language that communicate information. -- 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@lists.ietf.org Thu Jul 14 03:57:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsyb3-0000oZ-Cp; Thu, 14 Jul 2005 03:57:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsyb1-0000oT-Q4 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 03:57:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14844 for ; Thu, 14 Jul 2005 03:57: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.43) id 1Dsz3b-0005Go-49 for ltru@ietf.org; Thu, 14 Jul 2005 04:26: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, 14 Jul 2005 00:57: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] Introduction change: suggested text Date: Thu, 14 Jul 2005 00:57:11 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> Thread-Topic: [Ltru] Introduction change: suggested text Thread-Index: AcWIMabz0GKTN6pkTqyrSegS4pbGlQAFOdYg From: "Addison Phillips" To: "Martin Duerst" , "Randy Presuhn" , X-OriginalArrivalTime: 14 Jul 2005 07:57:12.0366 (UTC) FILETIME=[A47E54E0:01C58849] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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, we're far out in the weeds now. How about: -- The language tag is used to identify a language used for communication = by human beings. Such a language may take a variety of forms: it can be = spoken, written, signed, or otherwise signaled; the primary requirement = is that it be what is sometimes called a 'natural language'. That is, it = must be a language in the ordinary sense of the word, which can include = constructed or artificially designed languages, such as Esperanto. It = excludes languages not intended primarily for human communication, such = as programming or computer languages as well as various notation systems = created for specialized purposes and which could not serve as a person's = native tongue. -- If *that* doesn't slay the Wittgenstein in all of you, then we should = probably give up trying to define what a language is so precisely, allow = a certain parsimony to reign, and say far less: -- The language tag is used to identify a language as may be spoken, = written, signed or otherwise signaled and whose primary purpose is = communication between people. -- 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: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 2005?7?13? 18:37 > To: Addison Phillips; Randy Presuhn; ltru@ietf.org > Subject: RE: [Ltru] Introduction change: suggested text >=20 > While we are at it, I propose that we change: >=20 > The language tag is used to identify a language as used (which = includes > being spoken, written, signed, or otherwise signaled) by human beings = for > communication of information to other human beings. >=20 > to: >=20 > The language tag is used to identify a language as used by human = beings > for communication of information to other human beings. This includes > language being spoken, written, signed, or otherwise signaled. >=20 > [I'm not totally happy yet with the second sentence, but I'm happy = that > the parentheses, which were difficult to parse, are gone.] >=20 > Regards, Martin. >=20 >=20 > At 01:42 05/07/14, Addison Phillips wrote: > >I think that the following sentiments are a good summary of my = position > as well. > > > >In response to the particular suggestion of Martin's below, as well = as a > >previous thread concerning artificial languages and whether those = were > >excluded and so forth, I would like to propose that we change the = text > at > >the start of Section 2 from: > > > >The language tag always defines a language as used (which = includes > being > >spoken, written, signed, or otherwise signaled) by human beings for > >communication of information to other human beings. Computer = languages > such > >as programming languages are explicitly excluded. > > > >to read: > > > >The language tag is used to identify a language as used (which > includes > >being spoken, written, signed, or otherwise signaled) by human = beings > for > >communication of information to other human beings. A language of = this > type > >is sometimes called a 'natural language', and this includes = constructed > or > >artificially designed languages, such as Esperanto. Languages not > intended > >primarily for human communication, such as programming and other > computer > >languages, are explicitly excluded. > > > >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 Martin Duerst > >> Sent: 2005?7?13? 3:28 > >> To: Randy Presuhn; ltru@ietf.org > >> Subject: Re: [Ltru] Proposed addition after introduction (was: > JerseyJE > >> andGuernsey GG Country Codes) > >> > >> > >> [with my co-chair hat off] > >> I quite a bit agree with the sentiment in some of the text. > >> (I have worked on Internationalization of the WWW and the > >> Internet for a long time, so I hope this doesn't come as a > >> surprise.) > >[Addison Phillips] > > > >Amen. > > > >However, as an engineer, I think that what counts > >> is the actual spec. As a technical project, the only thing > >> we can do is to try to produce good technology, and hope > >> it gets used the right way. Engineers in general, and the > >> IETF in particular, is rather bad at marketing and politics, > >> and I think we should stay away from it. > >[Addison Phillips] > > > >+1 > >> > >> The only bit where I'd like a bit more time to check the current > >> draft text is JFCs first paragraph. If we are not clear enough > >> that the draft and the registry don't define languages, but > >> only provide identifiers, then I think may be a problem. > >> But if this is the case, then this should be fixed mostly > >> by word tweaking, rather than by grandiose declarations. > >> As an example, looking at the first sentence of section @, > >> it currently starts "The language tag always defines a = language...". > >> I think this should be changed to say > >> "The language tag always identifies a language..." > >> > >I agree: this text leads away from the intentions of the document = and > from > >the spirit of RFC 1766 and RFC 3066 in general. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 03:57:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsyb9-0000sP-Uh; Thu, 14 Jul 2005 03:57:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsyb9-0000rD-0d for ltru@megatron.ietf.org; Thu, 14 Jul 2005 03:57:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14858 for ; Thu, 14 Jul 2005 03:57:33 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dsz3h-0005HY-My for ltru@ietf.org; Thu, 14 Jul 2005 04:27:06 -0400 Received: from h-68-165-5-144.snvacaid.dynamic.covad.net ([68.165.5.144] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dsyb6-00046C-00 for ltru@ietf.org; Thu, 14 Jul 2005 03:57:32 -0400 Message-ID: <000601c58849$b848dc20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C10972B@irvmbxw01.quest.com><6.0.0.20.2.20050714103409.05325940@itmail.it.aoyama.ac.jp> Subject: Re: [Ltru] Introduction change: suggested text Date: Thu, 14 Jul 2005 00:57: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.1 (/) 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 Hi - > From: "Jukka K. Korpela" > To: > Sent: Thursday, July 14, 2005 12:04 AM > Subject: Re: [Ltru] Introduction change: suggested text ... > But that would mean just the opposite of what you wrote: you would count > only such speech acts as belonging to a language that communicate > information. ... Perhaps it would move this discussion along if you gave an example of a speech act (or of language in general) that communicated no information. I'm personally having difficulting understanding how communication can exist without information; my only problem with the phrase "communicate information" is that I find the word "information" redundant, not that I find that it restricts the word "communicate" in any meaningful way. Consequently, I'm interested in your perspective. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 04:06:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsyji-0006Qw-GQ; Thu, 14 Jul 2005 04:06:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsyjh-0006Qp-Do for ltru@megatron.ietf.org; Thu, 14 Jul 2005 04:06:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15734 for ; Thu, 14 Jul 2005 04:06:23 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DszCH-0005fC-0w for ltru@ietf.org; Thu, 14 Jul 2005 04:35:57 -0400 Received: from h-68-165-5-144.snvacaid.dynamic.covad.net ([68.165.5.144] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dsyjf-0005Qd-00 for ltru@ietf.org; Thu, 14 Jul 2005 04:06:23 -0400 Message-ID: <001901c5884a$f60afd80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> Subject: Re: [Ltru] Introduction change: suggested text Date: Thu, 14 Jul 2005 01:06:13 -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 - As a technical contributor, I could live with either of the proposed versions. I prefer the second, shorter one, but would not object to the long one. Randy ----- Original Message ----- From: "Addison Phillips" To: "Martin Duerst" ; "Randy Presuhn" ; Sent: Thursday, July 14, 2005 12:57 AM Subject: RE: [Ltru] Introduction change: suggested text Okay, we're far out in the weeds now. How about: -- The language tag is used to identify a language used for communication by human beings. Such a language may take a variety of forms: it can be spoken, written, signed, or otherwise signaled; the primary requirement is that it be what is sometimes called a 'natural language'. That is, it must be a language in the ordinary sense of the word, which can include constructed or artificially designed languages, such as Esperanto. It excludes languages not intended primarily for human communication, such as programming or computer languages as well as various notation systems created for specialized purposes and which could not serve as a person's native tongue. -- If *that* doesn't slay the Wittgenstein in all of you, then we should probably give up trying to define what a language is so precisely, allow a certain parsimony to reign, and say far less: -- The language tag is used to identify a language as may be spoken, written, signed or otherwise signaled and whose primary purpose is communication between people. -- ... _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 04:18:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsynK-0008MA-FR; Thu, 14 Jul 2005 04:10:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsynI-0008K8-AO for ltru@megatron.ietf.org; Thu, 14 Jul 2005 04:10:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15931 for ; Thu, 14 Jul 2005 04:10:06 -0400 (EDT) Received: from mail12.svc.cra.dublin.eircom.net ([159.134.118.28]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DszFr-0005nn-2N for ltru@ietf.org; Thu, 14 Jul 2005 04:39:40 -0400 Received: (qmail 65957 messnum 5760516 invoked from network[159.134.169.226/159-134-169-226.as1.prp.dublin.eircom.net]); 14 Jul 2005 08:09:52 -0000 Received: from 159-134-169-226.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.169.226) by mail12.svc.cra.dublin.eircom.net (qp 65957) with SMTP; 14 Jul 2005 08:09:52 -0000 Message-ID: <42D61D13.8DC5A6A2@egt.ie> Date: Thu, 14 Jul 2005 09:06:43 +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] Introduction change: suggested text References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA15931 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 Addison Phillips: > ... > The language tag is used to identify a language as may be spoken, writt= en, signed or otherwise signaled and whose primary purpose is communicati= on between people. > -- Perhaps 'The language tag is used to identify WHICH language is being spoken, written, signed or otherwise signalled for the purpose of communication.' =20 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 Thu Jul 14 04:18:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsysn-0001JY-H0; Thu, 14 Jul 2005 04:15:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsysl-0001IQ-7y for ltru@megatron.ietf.org; Thu, 14 Jul 2005 04:15:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16198 for ; Thu, 14 Jul 2005 04:15:45 -0400 (EDT) Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DszLJ-00060i-M3 for ltru@ietf.org; Thu, 14 Jul 2005 04:45:19 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id E6E114444; Thu, 14 Jul 2005 17:15:40 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10314-09; Thu, 14 Jul 2005 17:15:40 +0900 (JST) Received: from ibm-60d333fc0ec.w3.mag.keio.ac.jp (tea13.w3.mag.keio.ac.jp [133.27.228.243]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id AC413405B; Thu, 14 Jul 2005 17:15:40 +0900 (JST) Date: Thu, 14 Jul 2005 17:15:34 +0900 To: "Randy Presuhn" , ltru@ietf.org Subject: Re: [Ltru] Introduction change: suggested text References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> <001901c5884a$f60afd80$7f1afea9@oemcomputer> From: "Felix Sasaki" Organization: W3C Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: In-Reply-To: <001901c5884a$f60afd80$7f1afea9@oemcomputer> User-Agent: Opera M2/8.0 (Win32, build 7561) X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Hi - I would prefer the shorter version, because the long one *does* slay the = =20 Wittgenstein in me :) And it might let think the linguistics out there =20 that we want to make a contribute something to the question what language= =20 is. I wouldn't dare too .... -- Felix On Thu, 14 Jul 2005 17:06:13 +0900, Randy Presuhn =20 wrote: > Hi - > > As a technical contributor, I could live with either of the proposed =20 > versions. > I prefer the second, shorter one, but would not object to the long one. > > Randy > > ----- Original Message ----- > From: "Addison Phillips" > To: "Martin Duerst" ; "Randy Presuhn" =20 > ; > Sent: Thursday, July 14, 2005 12:57 AM > Subject: RE: [Ltru] Introduction change: suggested text > > > Okay, we're far out in the weeds now. How about: > > -- > The language tag is used to identify a language used for communication = =20 > by human beings. Such a language may take a variety of forms: > it can be spoken, written, signed, or otherwise signaled; the primary =20 > requirement is that it be what is sometimes called a 'natural > language'. That is, it must be a language in the ordinary sense of the = =20 > word, which can include constructed or artificially designed > languages, such as Esperanto. It excludes languages not intended =20 > primarily for human communication, such as programming or computer > languages as well as various notation systems created for specialized =20 > purposes and which could not serve as a person's native > tongue. > -- > > If *that* doesn't slay the Wittgenstein in all of you, then we should =20 > probably give up trying to define what a language is so > precisely, allow a certain parsimony to reign, and say far less: > > -- > The language tag is used to identify a language as may be spoken, =20 > written, signed or otherwise signaled and whose primary purpose is > communication between people. > -- > ... > > > > > _______________________________________________ > 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 Jul 14 05:09:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsziR-0008OP-4X; Thu, 14 Jul 2005 05: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 1DsziP-0008Mi-P4 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 05:09:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22037 for ; Thu, 14 Jul 2005 05:09:06 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt0At-0000Nb-FX for ltru@ietf.org; Thu, 14 Jul 2005 05:38:40 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6E98fC17254; Thu, 14 Jul 2005 18:08:41 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 8762e59a_f448_11d9_848a_0030482532aa_12532; Thu, 14 Jul 2005 18:20:33 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO008410; 14 Jul 05 18:14:20 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 14 Jul 05 18:13:57 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.227.17) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG00840E; 14 Jul 05 18:13:54 +0900 Message-Id: <6.0.0.20.2.20050714171357.05329ec0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 14 Jul 2005 17:20:29 +0900 To: "Randy Presuhn" , From: Martin Duerst Subject: Re: [Ltru] Introduction change: suggested text In-Reply-To: <000601c58849$b848dc20$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C10972B@irvmbxw01.quest.com> <6.0.0.20.2.20050714103409.05325940@itmail.it.aoyama.ac.jp> <000601c58849$b848dc20$7f1afea9@oemcomputer> 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: 21c69d3cfc2dd19218717dbe1d974352 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 At 16:57 05/07/14, Randy Presuhn wrote: >> From: "Jukka K. Korpela" >> But that would mean just the opposite of what you wrote: you would count >> only such speech acts as belonging to a language that communicate >> information. >... > >Perhaps it would move this discussion along if you gave an example of >a speech act (or of language in general) that communicated no information. > >I'm personally having difficulting understanding how communication can >exist without information; my only problem with the phrase "communicate >information" is that I find the word "information" redundant, not that I >find that it restricts the word "communicate" in any meaningful way. >Consequently, I'm interested in your perspective. Not speaking for Jukka, of course, but he wrote (in an ealier mail): Human language is not limited to communicating information. We can say "What a lovely evening!", which is an expression of feelings and impressions, or "I will", which is a promise, or "Please give me the sugar", which is a request. (It would be artificial to call an expression of emotions or a request acts of communicating information. The clearest of all is a promise: it does not simply express an intention but actually makes a promise and commits to something, at least morally.) I think I'd see things a bit different. "What a lovely evening!" indeed contains information. It contains information about the feelings of the speaker. Same for the other cases: "Please give me the sugar" contains information about the fact that I'm out of sugar, or that I'd really prefer my oponent to hand me the sugar rather than to get up and walk around the table, and so on. "I will" usually is rather low in information, because the propbability of it getting uttered at the right time is very high. But a low information content, and no information at all, are not the same. The additional 'moral commitment' or 'feeling' or 'request' doesn't take out the information. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 05:09:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsziR-0008P1-Em; Thu, 14 Jul 2005 05: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 1DsziP-0008Mj-P5 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 05:09:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22039 for ; Thu, 14 Jul 2005 05:09:06 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt0At-0000Nd-FW for ltru@ietf.org; Thu, 14 Jul 2005 05:38:40 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6E98gC17258; Thu, 14 Jul 2005 18:08:42 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 87a793de_f448_11d9_848a_0030482532aa_12532; Thu, 14 Jul 2005 18:20:33 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO008411; 14 Jul 05 18:14:21 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 14 Jul 05 18:13:57 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.227.17) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG00840F; 14 Jul 05 18:13:54 +0900 Message-Id: <6.0.0.20.2.20050714172333.05361490@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 14 Jul 2005 17:23:47 +0900 To: "Addison Phillips" , "Randy Presuhn" , From: Martin Duerst Subject: RE: [Ltru] Introduction change: suggested text In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@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: 42e3ed3f10a1d8bef690f09da16f507a 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 I like that text. Regards, Martin. At 16:57 05/07/14, Addison Phillips wrote: >Okay, we're far out in the weeds now. How about: > >-- >The language tag is used to identify a language used for communication by >human beings. Such a language may take a variety of forms: it can be >spoken, written, signed, or otherwise signaled; the primary requirement is >that it be what is sometimes called a 'natural language'. That is, it must >be a language in the ordinary sense of the word, which can include >constructed or artificially designed languages, such as Esperanto. It >excludes languages not intended primarily for human communication, such as >programming or computer languages as well as various notation systems >created for specialized purposes and which could not serve as a person's >native tongue. >-- > >If *that* doesn't slay the Wittgenstein in all of you, then we should >probably give up trying to define what a language is so precisely, allow a >certain parsimony to reign, and say far less: > >-- >The language tag is used to identify a language as may be spoken, written, >signed or otherwise signaled and whose primary purpose is communication >between people. >-- > >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: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] >> Sent: 2005?7?13? 18:37 >> To: Addison Phillips; Randy Presuhn; ltru@ietf.org >> Subject: RE: [Ltru] Introduction change: suggested text >> >> While we are at it, I propose that we change: >> >> The language tag is used to identify a language as used (which includes >> being spoken, written, signed, or otherwise signaled) by human beings for >> communication of information to other human beings. >> >> to: >> >> The language tag is used to identify a language as used by human beings >> for communication of information to other human beings. This includes >> language being spoken, written, signed, or otherwise signaled. >> >> [I'm not totally happy yet with the second sentence, but I'm happy that >> the parentheses, which were difficult to parse, are gone.] >> >> Regards, Martin. >> >> >> At 01:42 05/07/14, Addison Phillips wrote: >> >I think that the following sentiments are a good summary of my position >> as well. >> > >> >In response to the particular suggestion of Martin's below, as well as a >> >previous thread concerning artificial languages and whether those were >> >excluded and so forth, I would like to propose that we change the text >> at >> >the start of Section 2 from: >> > >> >The language tag always defines a language as used (which includes >> being >> >spoken, written, signed, or otherwise signaled) by human beings for >> >communication of information to other human beings. Computer languages >> such >> >as programming languages are explicitly excluded. >> > >> >to read: >> > >> >The language tag is used to identify a language as used (which >> includes >> >being spoken, written, signed, or otherwise signaled) by human beings >> for >> >communication of information to other human beings. A language of this >> type >> >is sometimes called a 'natural language', and this includes constructed >> or >> >artificially designed languages, such as Esperanto. Languages not >> intended >> >primarily for human communication, such as programming and other >> computer >> >languages, are explicitly excluded. >> > >> >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 Martin Duerst >> >> Sent: 2005?7?13? 3:28 >> >> To: Randy Presuhn; ltru@ietf.org >> >> Subject: Re: [Ltru] Proposed addition after introduction (was: >> JerseyJE >> >> andGuernsey GG Country Codes) >> >> >> >> >> >> [with my co-chair hat off] >> >> I quite a bit agree with the sentiment in some of the text. >> >> (I have worked on Internationalization of the WWW and the >> >> Internet for a long time, so I hope this doesn't come as a >> >> surprise.) >> >[Addison Phillips] >> > >> >Amen. >> > >> >However, as an engineer, I think that what counts >> >> is the actual spec. As a technical project, the only thing >> >> we can do is to try to produce good technology, and hope >> >> it gets used the right way. Engineers in general, and the >> >> IETF in particular, is rather bad at marketing and politics, >> >> and I think we should stay away from it. >> >[Addison Phillips] >> > >> >+1 >> >> >> >> The only bit where I'd like a bit more time to check the current >> >> draft text is JFCs first paragraph. If we are not clear enough >> >> that the draft and the registry don't define languages, but >> >> only provide identifiers, then I think may be a problem. >> >> But if this is the case, then this should be fixed mostly >> >> by word tweaking, rather than by grandiose declarations. >> >> As an example, looking at the first sentence of section @, >> >> it currently starts "The language tag always defines a language...". >> >> I think this should be changed to say >> >> "The language tag always identifies a language..." >> >> >> >I agree: this text leads away from the intentions of the document and >> from >> >the spirit of RFC 1766 and RFC 3066 in general. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 05:26:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dszz5-0000Mv-5o; Thu, 14 Jul 2005 05:26:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dszz2-0000JZ-Vx for ltru@megatron.ietf.org; Thu, 14 Jul 2005 05:26:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23154 for ; Thu, 14 Jul 2005 05:26:18 -0400 (EDT) Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt0Rc-00017l-1G for ltru@ietf.org; Thu, 14 Jul 2005 05:55:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 30C6E4444; Thu, 14 Jul 2005 18:26:11 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11095-03; Thu, 14 Jul 2005 18:26:10 +0900 (JST) Received: from ibm-60d333fc0ec.w3.mag.keio.ac.jp (tea13.w3.mag.keio.ac.jp [133.27.228.243]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id D7FB9403A; Thu, 14 Jul 2005 18:26:10 +0900 (JST) Date: Thu, 14 Jul 2005 18:26:05 +0900 To: "Martin Duerst" , "Randy Presuhn" , ltru@ietf.org Subject: Re: [Ltru] Introduction change: suggested text References: <634978A7DF025A40BFEF33EB191E13BC0C10972B@irvmbxw01.quest.com> <6.0.0.20.2.20050714103409.05325940@itmail.it.aoyama.ac.jp> <000601c58849$b848dc20$7f1afea9@oemcomputer> <6.0.0.20.2.20050714171357.05329ec0@itmail.it.aoyama.ac.jp> From: "Felix Sasaki" Organization: W3C Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: In-Reply-To: <6.0.0.20.2.20050714171357.05329ec0@itmail.it.aoyama.ac.jp> User-Agent: Opera M2/8.0 (Win32, build 7561) X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Searle would say it is hard to descripe the proposition of "What a lovely= =20 evening!". The proposition can be evaluated with regards to its =20 thruthfulness, e.g. you can evaluate whether the utterance "The King of =20 France has no hair" is true. (This is in our world not true because there= =20 is no King of France). But how can you say that "What a lovely evening!" = =20 is true? Again, this is dangerous ground, because a too detailed description of ou= r =20 notion of language might raise the attention of linguistis. I know what =20 I'm speaking about - they are very hard to be satisfied. So again I would= =20 vote for the short version Addison proposed. -- Felix On Thu, 14 Jul 2005 17:20:29 +0900, Martin Duerst =20 wrote: > At 16:57 05/07/14, Randy Presuhn wrote: > > >> From: "Jukka K. Korpela" > > >> But that would mean just the opposite of what you wrote: you would = =20 > count > >> only such speech acts as belonging to a language that communicate > >> information. > >... > > > >Perhaps it would move this discussion along if you gave an example of > >a speech act (or of language in general) that communicated no =20 > information. > > > >I'm personally having difficulting understanding how communication ca= n > >exist without information; my only problem with the phrase "communica= te > >information" is that I find the word "information" redundant, not tha= t =20 > I > >find that it restricts the word "communicate" in any meaningful way. > >Consequently, I'm interested in your perspective. > > Not speaking for Jukka, of course, but he wrote (in an ealier mail): > > Human language is not limited to communicating information. > We can say "What a lovely evening!", which is an expression of feelings= =20 > and impressions, or "I will", which is a promise, or "Please give me th= e =20 > sugar", which is a request. (It would be artificial to call an =20 > expression of emotions or a request acts of communicating information. = =20 > The clearest of all is a promise: it does not simply express an =20 > intention but actually makes a promise and commits to something, at =20 > least morally.) > > I think I'd see things a bit different. "What a lovely evening!" indeed= =20 > contains information. > It contains information about the feelings of the speaker. Same for the= =20 > other cases: > "Please give me the sugar" contains information about the fact that I'm= =20 > out of sugar, > or that I'd really prefer my oponent to hand me the sugar rather than t= o =20 > get up and > walk around the table, and so on. "I will" usually is rather low in =20 > information, because > the propbability of it getting uttered at the right time is very high. = =20 > But a low > information content, and no information at all, are not the same. The =20 > additional > 'moral commitment' or 'feeling' or 'request' doesn't take out the =20 > information. > > Regards, Martin. > > > _______________________________________________ > 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 Jul 14 05:37:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt09v-0005qy-Fb; Thu, 14 Jul 2005 05: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 1Dt09u-0005qt-H5 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 05:37:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23899 for ; Thu, 14 Jul 2005 05:37:32 -0400 (EDT) Received: from smtp.nildram.co.uk ([195.112.4.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt0cT-0001f0-LC for ltru@ietf.org; Thu, 14 Jul 2005 06:07:07 -0400 Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) by smtp.nildram.co.uk (Postfix) with ESMTP id 7E3DB253FAB; Thu, 14 Jul 2005 10:37:26 +0100 (BST) From: "Debbie Garside" To: "'Felix Sasaki'" , "'Martin Duerst'" , "'Randy Presuhn'" , Subject: RE: [Ltru] Introduction change: suggested text Date: Thu, 14 Jul 2005 10:36:30 +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 thread-index: AcWIVkqYYJS11hmtQZapICvY7KFpYAAAR/QQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Message-Id: <20050714093726.7E3DB253FAB@smtp.nildram.co.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 +1 -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Felix Sasaki Sent: 14 July 2005 10:26 To: Martin Duerst; Randy Presuhn; ltru@ietf.org Subject: Re: [Ltru] Introduction change: suggested text Searle would say it is hard to descripe the proposition of "What a lovely evening!". The proposition can be evaluated with regards to its thruthfulness, e.g. you can evaluate whether the utterance "The King of France has no hair" is true. (This is in our world not true because there is no King of France). But how can you say that "What a lovely evening!" is true? Again, this is dangerous ground, because a too detailed description of our notion of language might raise the attention of linguistis. I know what I'm speaking about - they are very hard to be satisfied. So again I would vote for the short version Addison proposed. -- Felix On Thu, 14 Jul 2005 17:20:29 +0900, Martin Duerst wrote: > At 16:57 05/07/14, Randy Presuhn wrote: > > >> From: "Jukka K. Korpela" > > >> But that would mean just the opposite of what you wrote: you would > count >> only such speech acts as belonging to a language that > communicate >> information. > >... > > > >Perhaps it would move this discussion along if you gave an example > of >a speech act (or of language in general) that communicated no > information. > > > >I'm personally having difficulting understanding how communication > can >exist without information; my only problem with the phrase > "communicate >information" is that I find the word "information" > redundant, not that I >find that it restricts the word "communicate" > in any meaningful way. > >Consequently, I'm interested in your perspective. > > Not speaking for Jukka, of course, but he wrote (in an ealier mail): > > Human language is not limited to communicating information. > We can say "What a lovely evening!", which is an expression of > feelings and impressions, or "I will", which is a promise, or "Please > give me the sugar", which is a request. (It would be artificial to > call an expression of emotions or a request acts of communicating information. > The clearest of all is a promise: it does not simply express an > intention but actually makes a promise and commits to something, at > least morally.) > > I think I'd see things a bit different. "What a lovely evening!" > indeed contains information. > It contains information about the feelings of the speaker. Same for > the other cases: > "Please give me the sugar" contains information about the fact that > I'm out of sugar, or that I'd really prefer my oponent to hand me the > sugar rather than to get up and walk around the table, and so on. "I > will" usually is rather low in information, because the propbability > of it getting uttered at the right time is very high. > But a low > information content, and no information at all, are not the same. The > additional 'moral commitment' or 'feeling' or 'request' doesn't take > out the information. > > Regards, Martin. > > > _______________________________________________ > 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 Thu Jul 14 07:38:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt230-0005YX-4H; Thu, 14 Jul 2005 07: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 1Dt22y-0005YO-Tx for ltru@megatron.ietf.org; Thu, 14 Jul 2005 07:38:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01182 for ; Thu, 14 Jul 2005 07:38:31 -0400 (EDT) Received: from mail.cs.tut.fi ([130.230.4.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt2VY-0005yg-6f for ltru@ietf.org; Thu, 14 Jul 2005 08:08:06 -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 479D8C82 for ; Thu, 14 Jul 2005 14:38:16 +0300 (EEST) Date: Thu, 14 Jul 2005 14:38:15 +0300 (EEST) From: "Jukka K. Korpela" To: ltru@ietf.org Subject: Re: [Ltru] Introduction change: suggested text In-Reply-To: Message-ID: References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> <001901c5884a$f60afd80$7f1afea9@oemcomputer> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On Thu, 14 Jul 2005, Felix Sasaki wrote: > I would prefer the shorter version, because the long one *does* slay the > Wittgenstein in me :) And it might let think the linguistics out there that > we want to make a contribute something to the question what language is. I > wouldn't dare too .... I find both versions acceptable in this context, but I like the longer version very much, and I think it would be more useful here. After all, the definition _needs_ to address the question what language is, in order to tell what kind of things may have a language code and therefore to exclude things that might be regarded as languages by some. This is a limited and technical scope and it need not be construed as a scientific or philosophical definition or even a definition for "language" as a common word - only for "language" as a term used in the context of codes for languages. -- 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@lists.ietf.org Thu Jul 14 08:21:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt2ii-0002Qd-Lj; Thu, 14 Jul 2005 08:21:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt2ig-0002QP-Tf for ltru@megatron.ietf.org; Thu, 14 Jul 2005 08:21:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03842 for ; Thu, 14 Jul 2005 08:21:37 -0400 (EDT) Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt3BH-0007L0-FS for ltru@ietf.org; Thu, 14 Jul 2005 08:51:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 04B5E445F for ; Thu, 14 Jul 2005 21:21:29 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13927-03 for ; Thu, 14 Jul 2005 21:21:28 +0900 (JST) Received: from ibm-60d333fc0ec (p3211-ipad94marunouchi.tokyo.ocn.ne.jp [219.160.111.211]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id A9B784059 for ; Thu, 14 Jul 2005 21:21:28 +0900 (JST) Date: Thu, 14 Jul 2005 21:21:21 +0900 To: ltru@ietf.org Subject: Re: [Ltru] Introduction change: suggested text References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> <001901c5884a$f60afd80$7f1afea9@oemcomputer> From: "Felix Sasaki" Organization: W3C Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: In-Reply-To: User-Agent: Opera M2/8.0 (Win32, build 7561) X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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 On Thu, 14 Jul 2005 20:38:15 +0900, Jukka K. Korpela = =20 wrote: > On Thu, 14 Jul 2005, Felix Sasaki wrote: > >> I would prefer the shorter version, because the long one *does* slay =20 >> the Wittgenstein in me :) And it might let think the linguistics out =20 >> there that we want to make a contribute something to the question what= =20 >> language is. I wouldn't dare too .... > > I find both versions acceptable in this context, but I like the longer = =20 > version very much, and I think it would be more useful here. I also can life with both versions, but may preference is the other way =20 around. > > After all, the definition _needs_ to address the question what language= =20 > is, in order to tell what kind of things may have a language code and =20 > therefore to exclude things that might be regarded as languages by some= . I agree with the purpose of the defintion: excluding what might be =20 regarded as languages. If we use this definition: -- The language tag is used to identify a language used for communication by= =20 human beings. Such a language may take a variety of forms: it can be spoken, =20 written, signed, or otherwise signaled; the primary requirement is that it be what= =20 is sometimes called a 'natural language'. That is, it must be a language in = =20 the ordinary sense of the word, which can include constructed or artificially designed= =20 languages, such as Esperanto. It excludes languages not intended primarily for human communication, such as programming or computer languages as well as =20 various notation systems created for specialized purposes and which could not serve as a =20 person's native tongue. -- I just see the danger that with a detailed definition, we encourage to =20 include more than we want. A linguist who does not read this carefuly =20 might think "Great, this is the tag I waited for for years!" and abuse it= =20 for - language which is specific to a context, i.e. a speech situation - language which is related to a development phase, e.g. first or second = =20 language acquisition - language for specific purposes - formal versus informal languages (closely related to the speech =20 situation) - gender- or sociolinguistic variants - and so on ... The problem with these beasts is that it will be hard to find two =20 linguists / people who agree on the actual values of the categories. So I= =20 guess they are not good canidates for a reprosity. To summarize my idea: keep the definition simple, and you will avoid =20 misunderstanding. -- Felix > This is a limited and technical scope and it need not be construed as a= =20 > scientific or philosophical definition or even a definition for =20 > "language" as a common word - only for "language" as a term used in the= =20 > context of codes for languages. > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 08:53:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3DP-0000ib-PW; Thu, 14 Jul 2005 08:53:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3DJ-0000iW-OB for ltru@megatron.ietf.org; Thu, 14 Jul 2005 08:53:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05885 for ; Thu, 14 Jul 2005 08:53:16 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt3fu-0008Pu-Hm for ltru@ietf.org; Thu, 14 Jul 2005 09:22:52 -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 j6ECqwZm009704; Thu, 14 Jul 2005 15:52:58 +0300 (EEST) Message-ID: <42D6602C.4080106@kotus.fi> Date: Thu, 14 Jul 2005 15:53:00 +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: Felix Sasaki Subject: Re: [Ltru] Introduction change: suggested text References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> <001901c5884a$f60afd80$7f1afea9@oemcomputer> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I apologise for being so late in introducing a new aspect to the game. However, I think that the statement "The language tag is used to identify a language..." is, in fact, somewhat contentious. I'd rather say something along the following lines: "The language tag is used to associate the material at some level of available granularity with a language...". This would make it clear that there's a lot of imperfection in both the definition of the language codes &al. and in the use of them. Erkki I. Kolehmainen Felix Sasaki wrote: > On Thu, 14 Jul 2005 20:38:15 +0900, Jukka K. Korpela > wrote: > >> On Thu, 14 Jul 2005, Felix Sasaki wrote: >> >>> I would prefer the shorter version, because the long one *does* slay >>> the Wittgenstein in me :) And it might let think the linguistics out >>> there that we want to make a contribute something to the question >>> what language is. I wouldn't dare too .... >> >> >> I find both versions acceptable in this context, but I like the >> longer version very much, and I think it would be more useful here. > > > > I also can life with both versions, but may preference is the other way > around. > >> >> After all, the definition _needs_ to address the question what >> language is, in order to tell what kind of things may have a language >> code and therefore to exclude things that might be regarded as >> languages by some. > > > I agree with the purpose of the defintion: excluding what might be > regarded as languages. If we use this definition: > > -- > The language tag is used to identify a language used for communication > by human > beings. Such a language may take a variety of forms: it can be spoken, > written, > signed, or otherwise signaled; the primary requirement is that it be > what is > sometimes called a 'natural language'. That is, it must be a language > in the ordinary > sense of the word, which can include constructed or artificially > designed languages, > such as Esperanto. It excludes languages not intended primarily for human > communication, such as programming or computer languages as well as > various notation > systems created for specialized purposes and which could not serve as a > person's > native tongue. > -- > > I just see the danger that with a detailed definition, we encourage to > include more than we want. A linguist who does not read this carefuly > might think "Great, this is the tag I waited for for years!" and abuse > it for > - language which is specific to a context, i.e. a speech situation > - language which is related to a development phase, e.g. first or > second language acquisition > - language for specific purposes > - formal versus informal languages (closely related to the speech > situation) > - gender- or sociolinguistic variants > - and so on ... > The problem with these beasts is that it will be hard to find two > linguists / people who agree on the actual values of the categories. So > I guess they are not good canidates for a reprosity. > > To summarize my idea: keep the definition simple, and you will avoid > misunderstanding. > > -- Felix > >> This is a limited and technical scope and it need not be construed as >> a scientific or philosophical definition or even a definition for >> "language" as a common word - only for "language" as a term used in >> the context of codes for languages. >> > > > > _______________________________________________ > 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 Jul 14 09:01:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3LZ-00040m-Vo; Thu, 14 Jul 2005 09:01:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3LW-00040h-TE for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:01:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06509 for ; Thu, 14 Jul 2005 09:01:45 -0400 (EDT) Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt3o6-0000HU-2n for ltru@ietf.org; Thu, 14 Jul 2005 09:31:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 5C329445F; Thu, 14 Jul 2005 22:01:46 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13957-18; Thu, 14 Jul 2005 22:01:46 +0900 (JST) Received: from ibm-60d333fc0ec (p3211-ipad94marunouchi.tokyo.ocn.ne.jp [219.160.111.211]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id E59FC4059; Thu, 14 Jul 2005 22:01:45 +0900 (JST) Date: Thu, 14 Jul 2005 22:01:38 +0900 To: "Erkki Kolehmainen" Subject: Re: [Ltru] Introduction change: suggested text References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> <001901c5884a$f60afd80$7f1afea9@oemcomputer> <42D6602C.4080106@kotus.fi> From: "Felix Sasaki" Organization: W3C Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: In-Reply-To: <42D6602C.4080106@kotus.fi> User-Agent: Opera M2/8.0 (Win32, build 7561) X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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 As I said before: I would keep the definitions in this area simple to =20 avoid misunderstanding, but I could also live with the longer version fro= m =20 Addison. And I think, both Erkki and me are aiming at the same goal, only= =20 with different methods. -- Felix On Thu, 14 Jul 2005 21:53:00 +0900, Erkki Kolehmainen =20 wrote: > I apologise for being so late in introducing a new aspect to the game. > > However, I think that the statement "The language tag is used to =20 > identify a language..." is, in fact, somewhat contentious. > > I'd rather say something along the following lines: "The language tag i= s =20 > used to associate the material at some level of available granularity =20 > with a language...". > > This would make it clear that there's a lot of imperfection in both the= =20 > definition of the language codes &al. and in the use of them. > > Erkki I. Kolehmainen > > Felix Sasaki wrote: > >> On Thu, 14 Jul 2005 20:38:15 +0900, Jukka K. Korpela =20 >> wrote: >> >>> On Thu, 14 Jul 2005, Felix Sasaki wrote: >>> >>>> I would prefer the shorter version, because the long one *does* slay= =20 >>>> the Wittgenstein in me :) And it might let think the linguistics out= =20 >>>> there that we want to make a contribute something to the question =20 >>>> what language is. I wouldn't dare too .... >>> >>> >>> I find both versions acceptable in this context, but I like the =20 >>> longer version very much, and I think it would be more useful here. >> I also can life with both versions, but may preference is the other= =20 >> way around. >> >>> >>> After all, the definition _needs_ to address the question what =20 >>> language is, in order to tell what kind of things may have a languag= e =20 >>> code and therefore to exclude things that might be regarded as =20 >>> languages by some. >> I agree with the purpose of the defintion: excluding what might be = =20 >> regarded as languages. If we use this definition: >> -- The language tag is used to identify a language used for =20 >> communication by human >> beings. Such a language may take a variety of forms: it can be spoken,= =20 >> written, >> signed, or otherwise signaled; the primary requirement is that it be =20 >> what is >> sometimes called a 'natural language'. That is, it must be a language = =20 >> in the ordinary >> sense of the word, which can include constructed or artificially =20 >> designed languages, >> such as Esperanto. It excludes languages not intended primarily for =20 >> human >> communication, such as programming or computer languages as well as =20 >> various notation >> systems created for specialized purposes and which could not serve as = =20 >> a person's >> native tongue. >> -- I just see the danger that with a detailed definition, we encourag= e =20 >> to include more than we want. A linguist who does not read this =20 >> carefuly might think "Great, this is the tag I waited for for years!"= =20 >> and abuse it for >> - language which is specific to a context, i.e. a speech situation >> - language which is related to a development phase, e.g. first or =20 >> second language acquisition >> - language for specific purposes >> - formal versus informal languages (closely related to the speech =20 >> situation) >> - gender- or sociolinguistic variants >> - and so on ... >> The problem with these beasts is that it will be hard to find two =20 >> linguists / people who agree on the actual values of the categories. S= o =20 >> I guess they are not good canidates for a reprosity. >> To summarize my idea: keep the definition simple, and you will avoid = =20 >> misunderstanding. >> -- Felix >> >>> This is a limited and technical scope and it need not be construed as= =20 >>> a scientific or philosophical definition or even a definition for =20 >>> "language" as a common word - only for "language" as a term used in =20 >>> the context of codes for languages. >>> >> _______________________________________________ >> 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 Jul 14 09:06:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3Q8-0005sf-5C; Thu, 14 Jul 2005 09:06:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3Q5-0005j1-NW for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:06:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06954 for ; Thu, 14 Jul 2005 09:06:27 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt3sc-0000VZ-BJ for ltru@ietf.org; Thu, 14 Jul 2005 09:36:03 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN6-742d6634a32d; Thu, 14 Jul 2005 09:06:18 -0500 Received: from DEBHOME (ACCBADFA.ipt.aol.com [172.203.173.250]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j6ED6BMj014981; Thu, 14 Jul 2005 09:06:11 -0400 Message-Id: <200507141306.j6ED6BMj014981@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Erkki Kolehmainen'" , "'Felix Sasaki'" Subject: RE: [Ltru] Introduction change: suggested text Date: Thu, 14 Jul 2005 14:06:20 +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: AcWIcyJrf/cIxY5NRxG65Ppw3Cr35AAARzcQ In-Reply-To: <42D6602C.4080106@kotus.fi> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org How about: "The language tag is used to identify a linguistic entity to the level of granularity either required or available." Regards Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Erkki Kolehmainen > Sent: 14 July 2005 13:53 > To: Felix Sasaki > Cc: ltru@ietf.org > Subject: Re: [Ltru] Introduction change: suggested text > > I apologise for being so late in introducing a new aspect to the game. > > However, I think that the statement "The language tag is used to > identify a language..." is, in fact, somewhat contentious. > > I'd rather say something along the following lines: "The language tag is > used to associate the material at some level of available granularity > with a language...". > > This would make it clear that there's a lot of imperfection in both the > definition of the language codes &al. and in the use of them. > > Erkki I. Kolehmainen > > Felix Sasaki wrote: > > > On Thu, 14 Jul 2005 20:38:15 +0900, Jukka K. Korpela > > wrote: > > > >> On Thu, 14 Jul 2005, Felix Sasaki wrote: > >> > >>> I would prefer the shorter version, because the long one *does* slay > >>> the Wittgenstein in me :) And it might let think the linguistics out > >>> there that we want to make a contribute something to the question > >>> what language is. I wouldn't dare too .... > >> > >> > >> I find both versions acceptable in this context, but I like the > >> longer version very much, and I think it would be more useful here. > > > > > > > > I also can life with both versions, but may preference is the other way > > around. > > > >> > >> After all, the definition _needs_ to address the question what > >> language is, in order to tell what kind of things may have a language > >> code and therefore to exclude things that might be regarded as > >> languages by some. > > > > > > I agree with the purpose of the defintion: excluding what might be > > regarded as languages. If we use this definition: > > > > -- > > The language tag is used to identify a language used for communication > > by human > > beings. Such a language may take a variety of forms: it can be spoken, > > written, > > signed, or otherwise signaled; the primary requirement is that it be > > what is > > sometimes called a 'natural language'. That is, it must be a language > > in the ordinary > > sense of the word, which can include constructed or artificially > > designed languages, > > such as Esperanto. It excludes languages not intended primarily for > human > > communication, such as programming or computer languages as well as > > various notation > > systems created for specialized purposes and which could not serve as a > > person's > > native tongue. > > -- > > > > I just see the danger that with a detailed definition, we encourage to > > include more than we want. A linguist who does not read this carefuly > > might think "Great, this is the tag I waited for for years!" and abuse > > it for > > - language which is specific to a context, i.e. a speech situation > > - language which is related to a development phase, e.g. first or > > second language acquisition > > - language for specific purposes > > - formal versus informal languages (closely related to the speech > > situation) > > - gender- or sociolinguistic variants > > - and so on ... > > The problem with these beasts is that it will be hard to find two > > linguists / people who agree on the actual values of the categories. So > > I guess they are not good canidates for a reprosity. > > > > To summarize my idea: keep the definition simple, and you will avoid > > misunderstanding. > > > > -- Felix > > > >> This is a limited and technical scope and it need not be construed as > >> a scientific or philosophical definition or even a definition for > >> "language" as a common word - only for "language" as a term used in > >> the context of codes for languages. > >> > > > > > > > > _______________________________________________ > > 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 Thu Jul 14 09:07:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3Qk-0006qf-36; Thu, 14 Jul 2005 09: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 1Dt3Qh-0006qG-ID for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:07:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06999 for ; Thu, 14 Jul 2005 09:07:05 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt3tI-0000Xw-Fb for ltru@ietf.org; Thu, 14 Jul 2005 09:36:41 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dt3QY-00036V-Gw; Thu, 14 Jul 2005 06:06:58 -0700 Message-Id: <6.2.1.2.2.20050714143508.044df1c0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 14 Jul 2005 14:35:52 +0200 To: Marion Gunn From: r&d afrac Subject: Re: [Ltru] Introduction change: suggested text In-Reply-To: <42D61D13.8DC5A6A2@egt.ie> References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> <42D61D13.8DC5A6A2@egt.ie> 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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA06999 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 10:06 14/07/2005, Marion Gunn wrote: >Scr=EDobh Addison Phillips: > > ... > > The language tag is used to identify a language as may be spoken,=20 > written, signed or otherwise signaled and whose primary purpose is=20 > communication between people. > > -- > >Perhaps 'The language tag is used to identify WHICH language is being >spoken, written, signed or otherwise signalled for the purpose of >communication.' Purchased. Except that I would write "to help indentifying" which language". jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 09:07:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3Qk-0006r3-E8; Thu, 14 Jul 2005 09: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 1Dt3Qh-0006qH-Pf for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:07:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07003 for ; Thu, 14 Jul 2005 09:07:06 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt3tI-0000YC-Ff for ltru@ietf.org; Thu, 14 Jul 2005 09:36:41 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dt3Qc-00036V-Go; Thu, 14 Jul 2005 06:07:02 -0700 Message-Id: <6.2.1.2.2.20050714145027.044d9b60@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 14 Jul 2005 14:51:32 +0200 To: Martin Duerst , Frank Ellermann , ltru@ietf.org From: r&d afrac In-Reply-To: <6.0.0.20.2.20050714101054.08e7d070@itmail.it.aoyama.ac.jp> References: <42D5B276.253C@xyzzy.claranet.de> <6.0.0.20.2.20050714101054.08e7d070@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] Political disclaimer X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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:14 14/07/2005, Martin Duerst wrote: >That of course means that they'd probably get scared by any politically >colored instructions. This is why the political implications and suspected roots of this draft are to be disclaimed. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 09:07:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3Qk-0006rS-ME; Thu, 14 Jul 2005 09: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 1Dt3Qh-0006qI-RE for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:07:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07008 for ; Thu, 14 Jul 2005 09:07:06 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt3tI-0000Xq-Fj for ltru@ietf.org; Thu, 14 Jul 2005 09:36:42 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dt3QV-00036V-OW; Thu, 14 Jul 2005 06:06:56 -0700 Message-Id: <6.2.1.2.2.20050714140510.04536780@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 14 Jul 2005 14:28:20 +0200 To: "Peter Constable" , "LTRU Working Group" From: r&d afrac 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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Ltru] Last call: Private UseTags X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 01:53 14/07/2005, Peter Constable wrote: >The use of Alpha and AlphaNum, which JFC considers a discriminatory >limitation, I think there may be a confusion here in my typing. I consider what is discriminatory (and also absurd) the limitation of Alphanums to 8 bytes in x-tags. >is nothing of the sort, and cannot be changed unless >backward compatibility is to be abandoned. I fully support the logic presented by F. Charles that this backward compatibility with something which never existed (since future x-tags are by nature ... future) is absurd. This is a good documentation of the religious opposition of this Draft to future and innovation. >Since there was consensus >from the outset that backward compatibility must be maintained, Please reference the URL of this consensus. I make it a last call issue that such a backward "compatiblity" when non necessary is not to be introduced. >and >since it was clear from the last call back in December that backward >compatibility with protocols that consume RFC 3066 is essential, 1. as someone put it against me: December Last Call is over. 2. I was I think one of the most active during that Xmas Call.... >then I >think this is not open to reconsideration, and therefore this proposed >text cannot be accepted. "I think" is not a consensus. "I think myself" is not either. Only "we think" makes one. I do not know if a text cannot be accepted due to your opinion. But I know that no one will think there a consensus against running code.... >Thus, I think this issue can remain closed. If you mean the whole Draft, I think it could. But this would not change that the current work in many areas need a framework. I do not oppose a grasroots one, but I think that an adherence of IETF to that process would be of interest. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 09:07:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3Qn-0006rq-Ld; Thu, 14 Jul 2005 09:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3Qi-0006qK-37 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:07:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07007 for ; Thu, 14 Jul 2005 09:07:06 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt3tI-0000Xr-HX for ltru@ietf.org; Thu, 14 Jul 2005 09:36:42 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dt3QX-00036V-2d; Thu, 14 Jul 2005 06:06:57 -0700 Message-Id: <6.2.1.2.2.20050714142938.04530eb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 14 Jul 2005 14:34:53 +0200 To: "Felix Sasaki" , "Randy Presuhn" , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Introduction change: suggested text In-Reply-To: References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> <001901c5884a$f60afd80$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 10:15 14/07/2005, Felix Sasaki wrote: >Hi - >I would prefer the shorter version, because the long one *does* slay the >Wittgenstein in me :) And it might let think the linguistics out there >that we want to make a contribute something to the question what language >is. I wouldn't dare too .... We are IETF here. We are not interested in what linguists are interested in: we trust they know their job. Our role is their networking aspects. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 09:07:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3Qn-0006sE-Qi; Thu, 14 Jul 2005 09:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3Qi-0006qJ-00 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:07:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07005 for ; Thu, 14 Jul 2005 09:07:06 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt3tI-0000Y3-Fn for ltru@ietf.org; Thu, 14 Jul 2005 09:36:42 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dt3Qa-00036V-IU; Thu, 14 Jul 2005 06:07:00 -0700 Message-Id: <6.2.1.2.2.20050714144843.044d9eb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 14 Jul 2005 14:49:13 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re:Proposed addition after introduction In-Reply-To: <42D5B276.253C@xyzzy.claranet.de> References: <42D5B276.253C@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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 02:31 14/07/2005, Frank Ellermann wrote: >+1 And we're not in the position to define what IANA "adheres >to", that's determined by VeriSign or whoever governs ICANN at >the moment. > Bye, Frank oh!!!! _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 09:08:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3Rg-0007kK-0O; Thu, 14 Jul 2005 09:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3Rd-0007hp-SE for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:08:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07093 for ; Thu, 14 Jul 2005 09:08:04 -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.43) id 1Dt3uC-0000Za-UF for ltru@ietf.org; Thu, 14 Jul 2005 09:37:40 -0400 Received: from uknsprd1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 14 Jul 2005 13:07:33 +0000 Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IJM004XSCGLUU@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Thu, 14 Jul 2005 14:07:33 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Thu, 14 Jul 2005 14:07:32 +0100 Date: Thu, 14 Jul 2005 14:07:32 +0100 From: Misha Wolf Subject: RE: [Ltru] Introduction change: suggested text To: ltru@ietf.org Message-id: <1987416CA83AC7499AC772F92E2DBF7804200506@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Introduction change: suggested text thread-index: AcWIdIctRa/zaN4eQTKg4rM/5lbRYwAAGQJQ Content-Class: urn:content-classes:message X-OriginalArrivalTime: 14 Jul 2005 13:07:32.0919 (UTC) FILETIME=[FF353C70:01C58874] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 suggest that we declare victory and go home. Misha -----Original Message----- From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of Erkki Kolehmainen Sent: 14 July 2005 13:53 To: Felix Sasaki Cc: ltru@ietf.org Subject: Re: [Ltru] Introduction change: suggested text I apologise for being so late in introducing a new aspect to the game. [...] ----------------------------------------------------------------- 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 Jul 14 09:35:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3ri-0003sa-8m; Thu, 14 Jul 2005 09: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 1Dt3rg-0003px-3H for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:35:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08541 for ; Thu, 14 Jul 2005 09:34:58 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt4KH-0001QC-Cw for ltru@ietf.org; Thu, 14 Jul 2005 10:04:34 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 06:34: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.1830); Thu, 14 Jul 2005 06:34:47 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Introduction change: suggested text Date: Thu, 14 Jul 2005 06:34:46 -0700 Message-ID: Thread-Topic: [Ltru] Introduction change: suggested text Thread-Index: AcWIQFLK23iGGPtXQ8CXV7IRSBA/CgANhi6Q From: "Peter Constable" To: X-OriginalArrivalTime: 14 Jul 2005 13:34:47.0817 (UTC) FILETIME=[CDAEDF90:01C58878] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Felix Sasaki > In various fields of linguistics, there are various definitions what a > "language" is. It seems to me that Jukka refers to are various types = of > speech acts in the sense of > Searle, John. 1969. Speech acts: An essay in the philosophy of = language. > Cambridge, England: Cambridge University. > There are many different opinions on how speech acts can be defined. = But I > have never seen anybody defining various types of speech acts as = different > languages. So I would vote for keeping "of information". Indeed, he was describing speech acts =E1 la Searle. And certainly tags = are not limited to use for speech acts of only certain types.=20 On the one hand, "communication of information" gives at least one = reader, Jukka, the wrong impression, though I rather think his reaction = would not be typical of readers in general.=20 On the other hand, every utterance has information content, regardless = of how a student of pragmatics would classify it. It's for *that* reason = I think "communication of information" is a bit redundant and that the = wording without "of information" is better. But I don't feel strongly = about the need to make the change. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 09:35:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3rq-00044N-19; Thu, 14 Jul 2005 09: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 1Dt3ro-0003wm-9S for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:35:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08549 for ; Thu, 14 Jul 2005 09:35:06 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt4KP-0001QU-M7 for ltru@ietf.org; Thu, 14 Jul 2005 10:04:43 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 06:34: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.1830); Thu, 14 Jul 2005 06:34:56 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Introduction change: suggested text Date: Thu, 14 Jul 2005 06:34:55 -0700 Message-ID: Thread-Topic: [Ltru] Introduction change: suggested text Thread-Index: AcWIQl0pB2Dr2nVaSWWN1KGxWxcexwANbDRg From: "Peter Constable" To: X-OriginalArrivalTime: 14 Jul 2005 13:34:56.0424 (UTC) FILETIME=[D2D03280:01C58878] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Jukka K. Korpela > Well, my argument is indeed based on such things, but it did not mean > classifying each speech act as a separate language. Instead, what I wrote > was about defining language as something used for communication, not just > communication of information. I like the suggested change, but not for the reasons you give. I think it's rather a stretch to suggest that "communication of information" implies a particular speech act. *All* communication has information content, regardless of speech act type. If the wording has said "for making declarations", then your reasons would apply; but it does not say that. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 09:45:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt41V-0007iG-MY; Thu, 14 Jul 2005 09:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt41U-0007gu-DI for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:45:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09243 for ; Thu, 14 Jul 2005 09:45:06 -0400 (EDT) Received: from mail08.svc.cra.dublin.eircom.net ([159.134.118.24]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dt4U5-0001ku-P4 for ltru@ietf.org; Thu, 14 Jul 2005 10:14:43 -0400 Received: (qmail 38157 messnum 5379539 invoked from network[159.134.169.122/159-134-169-122.as1.prp.dublin.eircom.net]); 14 Jul 2005 13:44:56 -0000 Received: from 159-134-169-122.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.169.122) by mail08.svc.cra.dublin.eircom.net (qp 38157) with SMTP; 14 Jul 2005 13:44:56 -0000 Message-ID: <42D66B9B.B8EF102@egt.ie> Date: Thu, 14 Jul 2005 14:41: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] Introduction change: suggested text References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> <42D61D13.8DC5A6A2@egt.ie> <6.2.1.2.2.20050714143508.044df1c0@mail.afrac.org> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA09243 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 Yes. Thanks.=20 'The language tag is used to HELP identify WHICH language is being spoken, written, signed or otherwise signalled for the purpose of communication.'=20 (ALLCAPS to be lowercased, obviously.) mg Scr=EDobh r&d afrac: >=20 > Purchased. > Except that I would write "to help indentifying" which language". > jfc --=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 Jul 14 09:47:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt43x-0001wL-8Y; Thu, 14 Jul 2005 09: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 1Dt43v-0001wG-I6 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:47:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09431 for ; Thu, 14 Jul 2005 09:47:37 -0400 (EDT) Received: from mail03.svc.cra.dublin.eircom.net ([159.134.118.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dt4WX-0001q8-7n for ltru@ietf.org; Thu, 14 Jul 2005 10:17:14 -0400 Received: (qmail 28734 messnum 274097 invoked from network[159.134.169.122/159-134-169-122.as1.prp.dublin.eircom.net]); 14 Jul 2005 13:47:28 -0000 Received: from 159-134-169-122.as1.prp.dublin.eircom.net (HELO egt.ie) (159.134.169.122) by mail03.svc.cra.dublin.eircom.net (qp 28734) with SMTP; 14 Jul 2005 13:47:28 -0000 Message-ID: <42D66C32.9544B5DA@egt.ie> Date: Thu, 14 Jul 2005 14:44:18 +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] Introduction change: suggested text References: <200507141306.j6ED6BMj014981@smtp-los02.proxy.aol.com> Content-Type: text/plain; charset=iso-8859-1 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA09431 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 Way too wordy for most (tired) users, techie or otherwise.:-) mg Scr=EDobh Debbie Garside: >=20 > How about: >=20 > "The language tag is used to identify a linguistic entity to the level = of > granularity either required or available." >=20 > Regards >=20 > Debbie --=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 Jul 14 09:53:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt49H-0003Z3-Vq; Thu, 14 Jul 2005 09:53:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt49F-0003Yv-V1 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:53:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09752 for ; Thu, 14 Jul 2005 09:53:08 -0400 (EDT) Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt4br-000202-IB for ltru@ietf.org; Thu, 14 Jul 2005 10:22:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 618FF445F for ; Thu, 14 Jul 2005 22:53:09 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14289-20 for ; Thu, 14 Jul 2005 22:53:09 +0900 (JST) Received: from ibm-60d333fc0ec (p3211-ipad94marunouchi.tokyo.ocn.ne.jp [219.160.111.211]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 221FA4059 for ; Thu, 14 Jul 2005 22:53:09 +0900 (JST) Date: Thu, 14 Jul 2005 22:53:01 +0900 To: "ltru@ietf.org" Subject: Re: [Ltru] Introduction change: suggested text References: From: "Felix Sasaki" Organization: W3C Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: In-Reply-To: User-Agent: Opera M2/8.0 (Win32, build 7561) X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 > > On the other hand, every utterance has information content, regardless = =20 > of how a student of pragmatics would classify it. It's for *that* reaso= n =20 > I think "communication of information" is a bit redundant and that the = =20 > wording without "of information" is better. But I don't feel strongly =20 > about the need to make the change. Me neither. -- Felix _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 09:53:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt49r-0003qw-4g; Thu, 14 Jul 2005 09:53:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt49p-0003nH-9H for ltru@megatron.ietf.org; Thu, 14 Jul 2005 09:53:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09814 for ; Thu, 14 Jul 2005 09:53:43 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt4cP-00021N-HH for ltru@ietf.org; Thu, 14 Jul 2005 10:23:20 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 06:53:32 -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); Thu, 14 Jul 2005 06:53:32 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Introduction change: suggested text Date: Thu, 14 Jul 2005 06:53:31 -0700 Message-ID: Thread-Topic: [Ltru] Introduction change: suggested text Thread-Index: AcWIdIctRa/zaN4eQTKg4rM/5lbRYwAAGQJQAAFPIdA= From: "Peter Constable" To: X-OriginalArrivalTime: 14 Jul 2005 13:53:32.0757 (UTC) FILETIME=[6C331850:01C5887B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Misha Wolf > Sent: Thursday, July 14, 2005 6:08 AM > To: ltru@ietf.org > Subject: RE: [Ltru] Introduction change: suggested text >=20 > I suggest that we declare victory and go home. I agree. Word-smithing by committee can always continue to fill whatever time is available, and I don't think we're making any really significant changes. Rather, we're examining a level of subtlety in our readings of the text that will not be noticed by readers in general.=20 If we make it clear that programming languages are excluded, I doubt the registration process will have difficulty rejecting a tag that treated bridge signaling and terminology as a separate language. (Last I knew, "three spades", "ruff" etc. were English expressions.) Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 10:18:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4Y0-00080M-Jr; Thu, 14 Jul 2005 10:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt4Xz-0007wO-0P for ltru@megatron.ietf.org; Thu, 14 Jul 2005 10:18:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12363 for ; Thu, 14 Jul 2005 10:18:41 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt50b-0002wH-0x for ltru@ietf.org; Thu, 14 Jul 2005 10:48:18 -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, 14 Jul 2005 10:18:33 -0400 id 005A8038.42D67439.000069C8 From: "Scott Hollenbeck" To: "'LTRU Working Group'" Date: Thu, 14 Jul 2005 10:18:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <001001c585ed$5b049ee0$7f1afea9@oemcomputer> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcWF7NmiEPvY3xiIS126uvNWiaVM/wCkUmvg Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Last Call Comment: draft-ietf-ltru-initial-02.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 Section 2 of draft-ietf-ltru-initial-02.txt describes the criteria used to populate the registry. Section 4 describes omitted code elements. I don't see any text to explain *why* the code elements in section 4 were omitted. Which criteria were not met?. It might be helpful to provide a few sentences to summarize the rationale for the WG's omission decision for the benefit of readers who weren't part of the on-list discussion. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 11:50:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5yj-0001Yb-Fs; Thu, 14 Jul 2005 11:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt5yg-0001Vn-3p for ltru@megatron.ietf.org; Thu, 14 Jul 2005 11:50:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23852 for ; Thu, 14 Jul 2005 11:50:18 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt6R5-0007fH-01 for ltru@ietf.org; Thu, 14 Jul 2005 12:19: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 j6EFnmD1018861; Thu, 14 Jul 2005 08:49:48 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 14 Jul 2005 08:50:40 -0700 Message-ID: From: "McDonald, Ira" To: "'Addison Phillips'" , Martin Duerst , Randy Presuhn , ltru@ietf.org Subject: RE: [Ltru] Introduction change: suggested text Date: Thu, 14 Jul 2005 08:50:39 -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: ec7c6dab5a62df223002ae71b5179d41 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, Frankly, I don't care if the linguists dislike or disagree with our definition. Our definition is for use only with the IANA Language Subtag Registry. And I much prefer the long version because it makes that restriction much clearer to the non-linguists (I think). 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: Thursday, July 14, 2005 3:57 AM > To: Martin Duerst; Randy Presuhn; ltru@ietf.org > Subject: RE: [Ltru] Introduction change: suggested text > > > Okay, we're far out in the weeds now. How about: > > -- > The language tag is used to identify a language used for > communication by human beings. Such a language may take a > variety of forms: it can be spoken, written, signed, or > otherwise signaled; the primary requirement is that it be > what is sometimes called a 'natural language'. That is, it > must be a language in the ordinary sense of the word, which > can include constructed or artificially designed languages, > such as Esperanto. It excludes languages not intended > primarily for human communication, such as programming or > computer languages as well as various notation systems > created for specialized purposes and which could not serve as > a person's native tongue. > -- > > If *that* doesn't slay the Wittgenstein in all of you, then > we should probably give up trying to define what a language > is so precisely, allow a certain parsimony to reign, and say far less: > > -- > The language tag is used to identify a language as may be > spoken, written, signed or otherwise signaled and whose > primary purpose is communication between people. > -- > > 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: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > > Sent: 2005?7?13? 18:37 > > To: Addison Phillips; Randy Presuhn; ltru@ietf.org > > Subject: RE: [Ltru] Introduction change: suggested text > > > > While we are at it, I propose that we change: > > > > The language tag is used to identify a language as used > (which includes > > being spoken, written, signed, or otherwise signaled) by > human beings for > > communication of information to other human beings. > > > > to: > > > > The language tag is used to identify a language as used by > human beings > > for communication of information to other human beings. > This includes > > language being spoken, written, signed, or otherwise signaled. > > > > [I'm not totally happy yet with the second sentence, but > I'm happy that > > the parentheses, which were difficult to parse, are gone.] > > > > Regards, Martin. > > > > > > At 01:42 05/07/14, Addison Phillips wrote: > > >I think that the following sentiments are a good summary > of my position > > as well. > > > > > >In response to the particular suggestion of Martin's > below, as well as a > > >previous thread concerning artificial languages and > whether those were > > >excluded and so forth, I would like to propose that we > change the text > > at > > >the start of Section 2 from: > > > > > >The language tag always defines a language as used > (which includes > > being > > >spoken, written, signed, or otherwise signaled) by human > beings for > > >communication of information to other human beings. > Computer languages > > such > > >as programming languages are explicitly excluded. > > > > > >to read: > > > > > >The language tag is used to identify a language as used (which > > includes > > >being spoken, written, signed, or otherwise signaled) by > human beings > > for > > >communication of information to other human beings. A > language of this > > type > > >is sometimes called a 'natural language', and this > includes constructed > > or > > >artificially designed languages, such as Esperanto. Languages not > > intended > > >primarily for human communication, such as programming and other > > computer > > >languages, are explicitly excluded. > > > > > >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 Martin Duerst > > >> Sent: 2005?7?13? 3:28 > > >> To: Randy Presuhn; ltru@ietf.org > > >> Subject: Re: [Ltru] Proposed addition after introduction (was: > > JerseyJE > > >> andGuernsey GG Country Codes) > > >> > > >> > > >> [with my co-chair hat off] > > >> I quite a bit agree with the sentiment in some of the text. > > >> (I have worked on Internationalization of the WWW and the > > >> Internet for a long time, so I hope this doesn't come as a > > >> surprise.) > > >[Addison Phillips] > > > > > >Amen. > > > > > >However, as an engineer, I think that what counts > > >> is the actual spec. As a technical project, the only thing > > >> we can do is to try to produce good technology, and hope > > >> it gets used the right way. Engineers in general, and the > > >> IETF in particular, is rather bad at marketing and politics, > > >> and I think we should stay away from it. > > >[Addison Phillips] > > > > > >+1 > > >> > > >> The only bit where I'd like a bit more time to check the current > > >> draft text is JFCs first paragraph. If we are not clear enough > > >> that the draft and the registry don't define languages, but > > >> only provide identifiers, then I think may be a problem. > > >> But if this is the case, then this should be fixed mostly > > >> by word tweaking, rather than by grandiose declarations. > > >> As an example, looking at the first sentence of section @, > > >> it currently starts "The language tag always defines a > language...". > > >> I think this should be changed to say > > >> "The language tag always identifies a language..." > > >> > > >I agree: this text leads away from the intentions of the > document and > > from > > >the spirit of RFC 1766 and RFC 3066 in general. > > > > _______________________________________________ > 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 Jul 14 12:56:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt70P-0007B4-UN; Thu, 14 Jul 2005 12:56:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt70P-0007Au-6z for ltru@megatron.ietf.org; Thu, 14 Jul 2005 12:56:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28757 for ; Thu, 14 Jul 2005 12:56:10 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt7T2-0001m9-Gz for ltru@ietf.org; Thu, 14 Jul 2005 13:25:49 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dt70M-0000Jd-LH; Thu, 14 Jul 2005 09:56:11 -0700 Message-Id: <6.2.1.2.2.20050714181103.0400bb30@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 14 Jul 2005 18:56:01 +0200 To: ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] last call: language tag usage In-Reply-To: <42D66B9B.B8EF102@egt.ie> References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> <42D61D13.8DC5A6A2@egt.ie> <6.2.1.2.2.20050714143508.044df1c0@mail.afrac.org> <42D66B9B.B8EF102@egt.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 15:41 14/07/2005, Marion Gunn wrote: >'The language tag is used to help identify which language is being >spoken, written, signed or otherwise signalled for the purpose of >communication.' +1 jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 14:41:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8e1-0006Hu-3L; Thu, 14 Jul 2005 14:41:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8dz-0006FY-N4 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 14:41:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07963 for ; Thu, 14 Jul 2005 14:41:09 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt96d-00065P-8h for ltru@ietf.org; Thu, 14 Jul 2005 15:10:48 -0400 Received: from h-64-105-136-117.snvacaid.dynamic.covad.net ([64.105.136.117] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dt8do-0000WW-00 for ltru@ietf.org; Thu, 14 Jul 2005 14:41:00 -0400 Message-ID: <009101c588a3$9d031980$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "'LTRU Working Group'" References: Subject: Re: [Ltru] Last Call Comment: draft-ietf-ltru-initial-02.txt Date: Thu, 14 Jul 2005 11:41:12 -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: "Scott Hollenbeck" > To: "'LTRU Working Group'" > Sent: Thursday, July 14, 2005 7:18 AM > Subject: [Ltru] Last Call Comment: draft-ietf-ltru-initial-02.txt > > Section 2 of draft-ietf-ltru-initial-02.txt describes the criteria used to > populate the registry. Section 4 describes omitted code elements. I don't > see any text to explain *why* the code elements in section 4 were omitted. > Which criteria were not met?. It might be helpful to provide a few > sentences to summarize the rationale for the WG's omission decision for the > benefit of readers who weren't part of the on-list discussion. ... Currently, section 4 starts out with: The following code elements from [UN-M.49] were not assigned as subtags in the initial Language Subtag Registry, but are valid candidates for registration as region subtags, using the process in [I-D.ietf-ltru-registry]: Here are some suggested replacement words: The following code elements from [UN-M.49] were not associated with [ISO3166-1] alpha-2 code elements. Consequently, they were not assigned as subtags in the initial Language Subtag Registry, but are valid candidates for registration as region subtags, using the process in [I-D.ietf-ltru-registry]: Would this address your concern? Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 14:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8mx-0001kD-1e; Thu, 14 Jul 2005 14:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8mv-0001gr-6X for ltru@megatron.ietf.org; Thu, 14 Jul 2005 14:50:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08912 for ; Thu, 14 Jul 2005 14:50:23 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt9FZ-0006Sk-I8 for ltru@ietf.org; Thu, 14 Jul 2005 15:20:02 -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, 14 Jul 2005 14:50:09 -0400 id 005A8112.42D6B3E1.00002558 From: "Scott Hollenbeck" To: "'Randy Presuhn'" , "'LTRU Working Group'" Subject: RE: [Ltru] Last Call Comment: draft-ietf-ltru-initial-02.txt Date: Thu, 14 Jul 2005 14:50:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <009101c588a3$9d031980$7f1afea9@oemcomputer> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcWIpCzyiJGLZBXNRsO0+uPopiXMKQAAJLlg Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Thursday, July 14, 2005 2:41 PM > To: 'LTRU Working Group' > Subject: Re: [Ltru] Last Call Comment: draft-ietf-ltru-initial-02.txt > > Hi - > > > From: "Scott Hollenbeck" > > To: "'LTRU Working Group'" > > Sent: Thursday, July 14, 2005 7:18 AM > > Subject: [Ltru] Last Call Comment: draft-ietf-ltru-initial-02.txt > > > > > Section 2 of draft-ietf-ltru-initial-02.txt describes the > criteria used to > > populate the registry. Section 4 describes omitted code > elements. I don't > > see any text to explain *why* the code elements in section > 4 were omitted. > > Which criteria were not met?. It might be helpful to provide a few > > sentences to summarize the rationale for the WG's omission > decision for the > > benefit of readers who weren't part of the on-list discussion. > ... > > Currently, section 4 starts out with: > The following code elements from [UN-M.49] were not assigned as > subtags in the initial Language Subtag Registry, but are valid > candidates for registration as region subtags, using the process in > [I-D.ietf-ltru-registry]: > > Here are some suggested replacement words: > The following code elements from [UN-M.49] were not associated > with [ISO3166-1] alpha-2 code elements. Consequently, they were > not assigned as > subtags in the initial Language Subtag Registry, but are valid > candidates for registration as region subtags, using the process in > [I-D.ietf-ltru-registry]: > > Would this address your concern? Yes, it would. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 15:07:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt936-00022Z-Hi; Thu, 14 Jul 2005 15:07:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt934-000222-OK for ltru@megatron.ietf.org; Thu, 14 Jul 2005 15:07:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10158 for ; Thu, 14 Jul 2005 15:07:05 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt9Vk-0006zG-2n for ltru@ietf.org; Thu, 14 Jul 2005 15:36:44 -0400 Received: from h-64-105-136-117.snvacaid.dynamic.covad.net ([64.105.136.117] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dt932-0000RD-00 for ltru@ietf.org; Thu, 14 Jul 2005 15:07:04 -0400 Message-ID: <00a501c588a7$425f8780$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.1.2.2.20050714140510.04536780@mail.afrac.org> Date: Thu, 14 Jul 2005 12:07: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: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: [Ltru] Compatibility (Was: Last call: Private UseTags) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - Jefsey (see below) writes "I make it a last call issue that such a backward "compatiblity" when non necessary is not to be introduced". In the context of this discussion, and of previous discussions on this list, the issue appears to be one of what is permitted by the ABNF. In particular, I believe the question is whether the WG wants the ABNF to permit the generation of tags which would not have been permitted by the ABNF in RFC 3066. The resolution of issues like #945 and #949 indicates that the WG places at least some value on compatibility, and the comments indicate that there is strong interest in ensuring that existing code will be able to syntactically cope with new tags. However, just to remove all doubt, I'd like a hum on the following paragraph from the registry draft's material on "goals": *Compatibility.* All RFC 3066 language tags (including those in the IANA registry) remain valid in this specification. The changes in this document represent additional constraints on language tags. That is, in no case is the syntax more permissive and processors based on the RFC 3066 ABNF (such as those described in [XMLSchema]) will be able to process the tags described by this document. In addition, this document defines language tags in such as way as to ensure future compatibility. Please indicate whether you agree or disagree with this goal. A check with http://tools.ietf.org/wg/ltru/draft-ietf-ltru-registry/ shows that this material has been around for a while, modulo wordsmithing. Randy, ltru co-chair > From: "r&d afrac" > To: "Peter Constable" ; "LTRU Working Group" > Sent: Thursday, July 14, 2005 5:28 AM > Subject: [Ltru] Last call: Private UseTags > > At 01:53 14/07/2005, Peter Constable wrote: > >The use of Alpha and AlphaNum, which JFC considers a discriminatory > >limitation, > > I think there may be a confusion here in my typing. I consider what is > discriminatory (and also absurd) the limitation of Alphanums to 8 bytes in > x-tags. > > >is nothing of the sort, and cannot be changed unless > >backward compatibility is to be abandoned. > > I fully support the logic presented by F. Charles that this backward > compatibility with something which never existed (since future x-tags are > by nature ... future) is absurd. This is a good documentation of the > religious opposition of this Draft to future and innovation. > > >Since there was consensus > >from the outset that backward compatibility must be maintained, > > Please reference the URL of this consensus. I make it a last call issue > that such a backward "compatiblity" when non necessary is not to be introduced. > > >and > >since it was clear from the last call back in December that backward > >compatibility with protocols that consume RFC 3066 is essential, > > 1. as someone put it against me: December Last Call is over. > 2. I was I think one of the most active during that Xmas Call.... > > >then I > >think this is not open to reconsideration, and therefore this proposed > >text cannot be accepted. > > "I think" is not a consensus. "I think myself" is not either. Only "we > think" makes one. > I do not know if a text cannot be accepted due to your opinion. But I know > that no one will think there a consensus against running code.... > > >Thus, I think this issue can remain closed. > > If you mean the whole Draft, I think it could. But this would not change > that the current work in many areas need a framework. I do not oppose a > grasroots one, but I think that an adherence of IETF to that process would > be of interest. > jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 15:52:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9kg-0008SE-QF; Thu, 14 Jul 2005 15:52:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9ir-0007hS-2P; Thu, 14 Jul 2005 15:50:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13740; Thu, 14 Jul 2005 15:50:14 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtABI-0008Pt-Pq; Thu, 14 Jul 2005 16:19:42 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dt9ic-0006Au-3D; Thu, 14 Jul 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ltru@ietf.org Subject: [Ltru] I-D ACTION:draft-ietf-ltru-registry-09.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-09.txt Pages : 61 Date : 2005-7-14 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.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-09.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-09.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-7-14104018.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ltru-registry-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ltru-registry-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-14104018.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 Jul 14 16:07:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9zL-0005PZ-9d; Thu, 14 Jul 2005 16:07:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9zI-0005M1-CK for ltru@megatron.ietf.org; Thu, 14 Jul 2005 16:07:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17751 for ; Thu, 14 Jul 2005 16:07:10 -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.43) id 1DtARt-0001Zr-K7 for ltru@ietf.org; Thu, 14 Jul 2005 16:36: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, 14 Jul 2005 13:06: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] Compatibility (Was: Last call: Private UseTags) Date: Thu, 14 Jul 2005 13:06:56 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D35F@irvmbxw01.quest.com> Thread-Topic: [Ltru] Compatibility (Was: Last call: Private UseTags) Thread-Index: AcWIp/2Jd+sPDjRCQjaFdDLSgdHmYAAB5R7w From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 14 Jul 2005 20:06:57.0014 (UTC) FILETIME=[962D6960:01C588AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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 +1 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: 2005?7?14? 12:07 > To: LTRU Working Group > Subject: [Ltru] Compatibility (Was: Last call: Private UseTags) >=20 > Hi - >=20 > Jefsey (see below) writes "I make it a last call issue that such a > backward > "compatiblity" when non necessary is not to be introduced". In the > context > of this discussion, and of previous discussions on this list, the = issue > appears > to be one of what is permitted by the ABNF. In particular, I believe = the > question > is whether the WG wants the ABNF to permit the generation of tags = which > would > not have been permitted by the ABNF in RFC 3066. >=20 > The resolution of issues like #945 and #949 indicates that the WG = places > at least > some value on compatibility, and the comments indicate that there is > strong interest > in ensuring that existing code will be able to syntactically cope with = new > tags. >=20 > However, just to remove all doubt, I'd like a hum on the following > paragraph from > the registry draft's material on "goals": >=20 > *Compatibility.* All RFC 3066 language tags (including those in = the > IANA registry) remain valid in this specification. The changes in > this document represent additional constraints on language tags. > That is, in no case is the syntax more permissive and processors > based on the RFC 3066 ABNF (such as those described in [XMLSchema]) > will be able to process the tags described by this document. In > addition, this document defines language tags in such as way as to > ensure future compatibility. >=20 > Please indicate whether you agree or disagree with this goal. A check > with http://tools.ietf.org/wg/ltru/draft-ietf-ltru-registry/ shows = that > this > material has been around for a while, modulo wordsmithing. >=20 > Randy, ltru co-chair >=20 > > From: "r&d afrac" > > To: "Peter Constable" ; "LTRU Working Group" > > > Sent: Thursday, July 14, 2005 5:28 AM > > Subject: [Ltru] Last call: Private UseTags > > >=20 > > At 01:53 14/07/2005, Peter Constable wrote: > > >The use of Alpha and AlphaNum, which JFC considers a discriminatory > > >limitation, > > > > I think there may be a confusion here in my typing. I consider what = is > > discriminatory (and also absurd) the limitation of Alphanums to 8 = bytes > in > > x-tags. > > > > >is nothing of the sort, and cannot be changed unless > > >backward compatibility is to be abandoned. > > > > I fully support the logic presented by F. Charles that this backward > > compatibility with something which never existed (since future = x-tags > are > > by nature ... future) is absurd. This is a good documentation of the > > religious opposition of this Draft to future and innovation. > > > > >Since there was consensus > > >from the outset that backward compatibility must be maintained, > > > > Please reference the URL of this consensus. I make it a last call = issue > > that such a backward "compatiblity" when non necessary is not to be > introduced. > > > > >and > > >since it was clear from the last call back in December that = backward > > >compatibility with protocols that consume RFC 3066 is essential, > > > > 1. as someone put it against me: December Last Call is over. > > 2. I was I think one of the most active during that Xmas Call.... > > > > >then I > > >think this is not open to reconsideration, and therefore this = proposed > > >text cannot be accepted. > > > > "I think" is not a consensus. "I think myself" is not either. Only = "we > > think" makes one. > > I do not know if a text cannot be accepted due to your opinion. But = I > know > > that no one will think there a consensus against running code.... > > > > >Thus, I think this issue can remain closed. > > > > If you mean the whole Draft, I think it could. But this would not = change > > that the current work in many areas need a framework. I do not = oppose a > > grasroots one, but I think that an adherence of IETF to that process > would > > be of interest. > > jfc >=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 Thu Jul 14 16:44:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtAZh-0004xN-NZ; Thu, 14 Jul 2005 16:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtAZe-0004wc-AA for ltru@megatron.ietf.org; Thu, 14 Jul 2005 16:44:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05785 for ; Thu, 14 Jul 2005 16:44:47 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtB2J-00084v-Ac for ltru@ietf.org; Thu, 14 Jul 2005 17:14:28 -0400 Received: from h-64-105-136-117.snvacaid.dynamic.covad.net ([64.105.136.117] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtAZY-0007Sv-00 for ltru@ietf.org; Thu, 14 Jul 2005 16:44:44 -0400 Message-ID: <000901c588b4$e695e080$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Thu, 14 Jul 2005 13:44: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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] Working group last call closing date X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - Archive message http://www1.ietf.org/mail-archive/web/ltru/current/msg02817.html has the announcement of the availability of http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.txt Archive message http://www1.ietf.org/mail-archive/web/ltru/current/msg02761.html has the avilability announcement of http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt As I announced earlier, the working group last call on these will end two weeks from the appearance of the availability announcements for the i-ds. So, the last call will end on July 28, 2005. Please make every effort to submit your comments before then. We also need to hear from those who have read the drafts and have no comments. Please let anyone you know of who would be interested in this work that we are in working group last call and that we would welcome their feedback. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 16:55:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtAkI-0003f4-HY; Thu, 14 Jul 2005 16:55:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtAkC-0003Ya-2x for ltru@megatron.ietf.org; Thu, 14 Jul 2005 16:55:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10914 for ; Thu, 14 Jul 2005 16:55:40 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-kan.bigfish.com ([63.161.60.29] helo=mail40-kan-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtBCo-0001VA-Uz for ltru@ietf.org; Thu, 14 Jul 2005 17:25:21 -0400 Received: from mail40-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail40-kan-R.bigfish.com (Postfix) with ESMTP id D538226E93C; Thu, 14 Jul 2005 20:55:25 +0000 (UTC) X-BigFish: VP Received: by mail40-kan (MessageSwitch) id 1121374525765749_23935; Thu, 14 Jul 2005 20:55:25 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail40-kan.bigfish.com (Postfix) with ESMTP id 98A6126E9B5; Thu, 14 Jul 2005 20:55:25 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005071414030602:181079 ; Thu, 14 Jul 2005 14:03:06 -0700 To: "Addison Phillips" Subject: RE: [Ltru] Introduction change: suggested text MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Thu, 14 Jul 2005 13:52:28 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/14/2005 13:52:28, Serialize complete at 07/14/2005 13:52:28, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/14/2005 02:03:06 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/14/2005 02:03:07 PM, Serialize complete at 07/14/2005 02:03:07 PM Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c 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 I think the "native tongue" text could be perceived to preclude languages such as Esperanto, Latin American Spanish, and (forgive me for mentioning it, but ISO recognizes it) Klingon. Karen Broome Metadata Systems Designer Sony Pictures Entertainment 310.244.4384 "Addison Phillips" Sent by: ltru-bounces@lists.ietf.org 07/14/2005 12:57 AM To: "Martin Duerst" , "Randy Presuhn" , cc: Subject: RE: [Ltru] Introduction change: suggested text Okay, we're far out in the weeds now. How about: -- The language tag is used to identify a language used for communication by human beings. Such a language may take a variety of forms: it can be spoken, written, signed, or otherwise signaled; the primary requirement is that it be what is sometimes called a 'natural language'. That is, it must be a language in the ordinary sense of the word, which can include constructed or artificially designed languages, such as Esperanto. It excludes languages not intended primarily for human communication, such as programming or computer languages as well as various notation systems created for specialized purposes and which could not serve as a person's native tongue. -- If *that* doesn't slay the Wittgenstein in all of you, then we should probably give up trying to define what a language is so precisely, allow a certain parsimony to reign, and say far less: -- The language tag is used to identify a language as may be spoken, written, signed or otherwise signaled and whose primary purpose is communication between people. -- 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: Martin Duerst [mailto:duerst@it.aoyama.ac.jp] > Sent: 2005?7?13? 18:37 > To: Addison Phillips; Randy Presuhn; ltru@ietf.org > Subject: RE: [Ltru] Introduction change: suggested text > > While we are at it, I propose that we change: > > The language tag is used to identify a language as used (which includes > being spoken, written, signed, or otherwise signaled) by human beings for > communication of information to other human beings. > > to: > > The language tag is used to identify a language as used by human beings > for communication of information to other human beings. This includes > language being spoken, written, signed, or otherwise signaled. > > [I'm not totally happy yet with the second sentence, but I'm happy that > the parentheses, which were difficult to parse, are gone.] > > Regards, Martin. > > > At 01:42 05/07/14, Addison Phillips wrote: > >I think that the following sentiments are a good summary of my position > as well. > > > >In response to the particular suggestion of Martin's below, as well as a > >previous thread concerning artificial languages and whether those were > >excluded and so forth, I would like to propose that we change the text > at > >the start of Section 2 from: > > > >The language tag always defines a language as used (which includes > being > >spoken, written, signed, or otherwise signaled) by human beings for > >communication of information to other human beings. Computer languages > such > >as programming languages are explicitly excluded. > > > >to read: > > > >The language tag is used to identify a language as used (which > includes > >being spoken, written, signed, or otherwise signaled) by human beings > for > >communication of information to other human beings. A language of this > type > >is sometimes called a 'natural language', and this includes constructed > or > >artificially designed languages, such as Esperanto. Languages not > intended > >primarily for human communication, such as programming and other > computer > >languages, are explicitly excluded. > > > >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 Martin Duerst > >> Sent: 2005?7?13? 3:28 > >> To: Randy Presuhn; ltru@ietf.org > >> Subject: Re: [Ltru] Proposed addition after introduction (was: > JerseyJE > >> andGuernsey GG Country Codes) > >> > >> > >> [with my co-chair hat off] > >> I quite a bit agree with the sentiment in some of the text. > >> (I have worked on Internationalization of the WWW and the > >> Internet for a long time, so I hope this doesn't come as a > >> surprise.) > >[Addison Phillips] > > > >Amen. > > > >However, as an engineer, I think that what counts > >> is the actual spec. As a technical project, the only thing > >> we can do is to try to produce good technology, and hope > >> it gets used the right way. Engineers in general, and the > >> IETF in particular, is rather bad at marketing and politics, > >> and I think we should stay away from it. > >[Addison Phillips] > > > >+1 > >> > >> The only bit where I'd like a bit more time to check the current > >> draft text is JFCs first paragraph. If we are not clear enough > >> that the draft and the registry don't define languages, but > >> only provide identifiers, then I think may be a problem. > >> But if this is the case, then this should be fixed mostly > >> by word tweaking, rather than by grandiose declarations. > >> As an example, looking at the first sentence of section @, > >> it currently starts "The language tag always defines a language...". > >> I think this should be changed to say > >> "The language tag always identifies a language..." > >> > >I agree: this text leads away from the intentions of the document and > from > >the spirit of RFC 1766 and RFC 3066 in general. _______________________________________________ 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 Jul 14 17:40:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBRu-0006aK-HD; Thu, 14 Jul 2005 17:40:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBRt-0006Zm-7m for ltru@megatron.ietf.org; Thu, 14 Jul 2005 17:40:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00826 for ; Thu, 14 Jul 2005 17:40:50 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtBuU-0000AM-TA for ltru@ietf.org; Thu, 14 Jul 2005 18:10:31 -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 j6ELeXn8039870 for ; Thu, 14 Jul 2005 17:40:33 -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 j6ELeWQD227406 for ; Thu, 14 Jul 2005 15:40:32 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j6ELeWwT026811 for ; Thu, 14 Jul 2005 15:40:32 -0600 Received: from markdavis (mark-davis.sanjose.ibm.com [9.43.213.118]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with SMTP id j6ELeVAk026774; Thu, 14 Jul 2005 15:40:32 -0600 Message-ID: <008601c588bc$a74bf790$6501a8c0@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <6.2.1.2.2.20050714140510.04536780@mail.afrac.org> <00a501c588a7$425f8780$7f1afea9@oemcomputer> Subject: Re: [Ltru] Compatibility (Was: Last call: Private UseTags) Date: Thu, 14 Jul 2005 14:40:28 -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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e31.co.us.ibm.com id j6ELeXn8039870 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 The goal has always been present, and I think adding the paragraph is a worthwhile clarification. I would make one change: the ABNF is not the on= ly constraint on the specification, and someone might read the paragraph as implying that. So: > *Compatibility.* All RFC 3066 language tags (including those in the > IANA registry) remain valid in this specification. The changes in > this document represent additional constraints on language tags. > That is, in no case is the syntax more permissive and processors > based on the RFC 3066 ABNF (such as those described in [XMLSchema]) [add: and the other specifications in the text of the RFC] > will be able to process the tags described by this document. In > addition, this document defines language tags in such as way as to > ensure future compatibility. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Thursday, July 14, 2005 12:07 Subject: [Ltru] Compatibility (Was: Last call: Private UseTags) > Hi - > > Jefsey (see below) writes "I make it a last call issue that such a backward > "compatiblity" when non necessary is not to be introduced". In the context > of this discussion, and of previous discussions on this list, the issue appears > to be one of what is permitted by the ABNF. In particular, I believe t= he question > is whether the WG wants the ABNF to permit the generation of tags which would > not have been permitted by the ABNF in RFC 3066. > > The resolution of issues like #945 and #949 indicates that the WG place= s at least > some value on compatibility, and the comments indicate that there is strong interest > in ensuring that existing code will be able to syntactically cope with = new tags. > > However, just to remove all doubt, I'd like a hum on the following paragraph from > the registry draft's material on "goals": > > *Compatibility.* All RFC 3066 language tags (including those in the > IANA registry) remain valid in this specification. The changes in > this document represent additional constraints on language tags. > That is, in no case is the syntax more permissive and processors > based on the RFC 3066 ABNF (such as those described in [XMLSchema]) > will be able to process the tags described by this document. In > addition, this document defines language tags in such as way as to > ensure future compatibility. > > Please indicate whether you agree or disagree with this goal. A check > with http://tools.ietf.org/wg/ltru/draft-ietf-ltru-registry/ shows that this > material has been around for a while, modulo wordsmithing. > > Randy, ltru co-chair > > > From: "r&d afrac" > > To: "Peter Constable" ; "LTRU Working Group" > > Sent: Thursday, July 14, 2005 5:28 AM > > Subject: [Ltru] Last call: Private UseTags > > > > > At 01:53 14/07/2005, Peter Constable wrote: > > >The use of Alpha and AlphaNum, which JFC considers a discriminatory > > >limitation, > > > > I think there may be a confusion here in my typing. I consider what i= s > > discriminatory (and also absurd) the limitation of Alphanums to 8 byt= es in > > x-tags. > > > > >is nothing of the sort, and cannot be changed unless > > >backward compatibility is to be abandoned. > > > > I fully support the logic presented by F. Charles that this backward > > compatibility with something which never existed (since future x-tags are > > by nature ... future) is absurd. This is a good documentation of the > > religious opposition of this Draft to future and innovation. > > > > >Since there was consensus > > >from the outset that backward compatibility must be maintained, > > > > Please reference the URL of this consensus. I make it a last call iss= ue > > that such a backward "compatiblity" when non necessary is not to be introduced. > > > > >and > > >since it was clear from the last call back in December that backward > > >compatibility with protocols that consume RFC 3066 is essential, > > > > 1. as someone put it against me: December Last Call is over. > > 2. I was I think one of the most active during that Xmas Call.... > > > > >then I > > >think this is not open to reconsideration, and therefore this propos= ed > > >text cannot be accepted. > > > > "I think" is not a consensus. "I think myself" is not either. Only "w= e > > think" makes one. > > I do not know if a text cannot be accepted due to your opinion. But I know > > that no one will think there a consensus against running code.... > > > > >Thus, I think this issue can remain closed. > > > > If you mean the whole Draft, I think it could. But this would not cha= nge > > that the current work in many areas need a framework. I do not oppose= a > > grasroots one, but I think that an adherence of IETF to that process would > > be of interest. > > 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 ietf-bounces@ietf.org Thu Jul 14 18:17:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBuH-0000yn-QK; Thu, 14 Jul 2005 18:10:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBuF-0000yO-NM for ietf@megatron.ietf.org; Thu, 14 Jul 2005 18:10:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11564 for ; Thu, 14 Jul 2005 18:10:08 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtCMt-00040W-NT for ietf@ietf.org; Thu, 14 Jul 2005 18:39:50 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 15C03E004B; Thu, 14 Jul 2005 18:10:00 -0400 (EDT) To: Simon Josefsson References: <42D66666.3010008@zurich.ibm.com> From: Sam Hartman Date: Thu, 14 Jul 2005 18:10:00 -0400 In-Reply-To: (Simon Josefsson's message of "Thu, 14 Jul 2005 18:08:45 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ietf@ietf.org Subject: Recording discussion X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org >>>>> "Simon" == Simon Josefsson writes: Simon> Brian E Carpenter writes: >> We propose that, for an initial period of 6 months, a member of >> the community will be added to regular IESG meetings as a >> "recording secretary" who will write narrative minutes of the >> discussions, which will be posted publicly after IESG review >> for accuracy. Simon> Sounds useful to me. How about actually recording the Simon> discussion too? And publishing them as OGG or MP3. Simon> Editing out personnel discussion would still be possible. Simon> All for the sake of transparency and accountability. Simon> Regards, Simon I think doing this on a regular basis would be too time consuming to edit. However I think it would actually be useful to the community, to those considering serving on the IESG etc to record one telechat a year or so and edit out the confidential bits. I certainly know I had no idea what to expect when I called into my first telechat. --Sam _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf From ltru-bounces@lists.ietf.org Thu Jul 14 18:17:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBzh-0002h1-4H; Thu, 14 Jul 2005 18:15:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBzd-0002gX-In for ltru@megatron.ietf.org; Thu, 14 Jul 2005 18:15:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12220 for ; Thu, 14 Jul 2005 18:15:42 -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.43) id 1DtCSJ-0004Bv-03 for ltru@ietf.org; Thu, 14 Jul 2005 18:45:24 -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 Jul 2005 15:15:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Compatibility (Was: Last call: Private UseTags) Date: Thu, 14 Jul 2005 15:15:29 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D3F9@irvmbxw01.quest.com> Thread-Topic: [Ltru] Compatibility (Was: Last call: Private UseTags) Thread-Index: AcWIvbcZa/NvBllBSPyb4XV5J6zqigAA2Nvg From: "Addison Phillips" To: "Mark Davis" , "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 14 Jul 2005 22:15:29.0866 (UTC) FILETIME=[8B653AA0:01C588C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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="===============0122108333==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0122108333== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBtb2RpZnkgdGhlIHRleHQgdG8gaW5jbHVkZSByZXF1aXJl bWVudHMgaW1wb3NlZCBieSBSRkMgMzA2NiBiZXlvbmQgdGhvc2UgaW4gdGhlIEFCTkYuDQoNCkkg c2hvdWxkIG5vdGUgdGhhdCBpdCBpc24ndCBjbGVhciBmcm9tIE1hcmsncyBub3RlOiB0aGlzIHBh cmFncmFwaCBpcyBhbHJlYWR5IGluIHRoZSBkcmFmdCwgaW4gU2VjdGlvbiA4IChDaGFuZ2VzIGZy b20gUkZDIDMwNjYpLCBhbmQgaGFzIGJlZW4gcHJlc2VudCBzaW5jZSBkcmFmdC1sYW5ndGFncy0w NSAob3IsIHRvIHB1dCBpdCBhbm90aGVyIHdheSwgdGhlIHBhc3QgKkZJRlRFRU4qIGRyYWZ0cyBv ZiB0aGUgZG9jdW1lbnQpLiBUaGlzIHJlcXVpcmVtZW50IHNob3VsZCBub3QgYmUgYSBteXN0ZXJ5 IHRvIGFueW9uZSBhdCB0aGlzIHBvaW50Lg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxp cHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJ bnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6 YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbHRydS1ib3VuY2VzQGxpc3RzLmlldGYu b3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2Yg TWFyayBEYXZpcw0KPiBTZW50OiAyMDA15bm0N+aciDE05pelIDE0OjQwDQo+IFRvOiBSYW5keSBQ cmVzdWhuOyBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogUmU6IFtMdHJ1XSBDb21wYXRp YmlsaXR5IChXYXM6IExhc3QgY2FsbDogUHJpdmF0ZSBVc2VUYWdzKQ0KPiANCj4gVGhlIGdvYWwg aGFzIGFsd2F5cyBiZWVuIHByZXNlbnQsIGFuZCBJIHRoaW5rIGFkZGluZyB0aGUgcGFyYWdyYXBo IGlzIGENCj4gd29ydGh3aGlsZSBjbGFyaWZpY2F0aW9uLiBJIHdvdWxkIG1ha2Ugb25lIGNoYW5n ZTogdGhlIEFCTkYgaXMgbm90IHRoZQ0KPiBvbmx5DQo+IGNvbnN0cmFpbnQgb24gdGhlIHNwZWNp ZmljYXRpb24sIGFuZCBzb21lb25lIG1pZ2h0IHJlYWQgdGhlIHBhcmFncmFwaCBhcw0KPiBpbXBs eWluZyB0aGF0LiBTbzoNCj4gDQo+ID4gICAgKkNvbXBhdGliaWxpdHkuKiBBbGwgUkZDIDMwNjYg bGFuZ3VhZ2UgdGFncyAgKGluY2x1ZGluZyB0aG9zZSBpbiB0aGUNCj4gPiAgICBJQU5BIHJlZ2lz dHJ5KSAgcmVtYWluIHZhbGlkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4gIFRoZSBjaGFuZ2VzIGlu DQo+ID4gICAgdGhpcyBkb2N1bWVudCByZXByZXNlbnQgYWRkaXRpb25hbCBjb25zdHJhaW50cyBv biBsYW5ndWFnZSB0YWdzLg0KPiA+ICAgIFRoYXQgaXMsIGluIG5vIGNhc2UgaXMgdGhlIHN5bnRh eCBtb3JlIHBlcm1pc3NpdmUgYW5kIHByb2Nlc3NvcnMNCj4gPiAgICBiYXNlZCBvbiB0aGUgUkZD IDMwNjYgQUJORiAoc3VjaCBhcyB0aG9zZSBkZXNjcmliZWQgaW4gW1hNTFNjaGVtYV0pDQo+IFth ZGQ6IGFuZCB0aGUgb3RoZXIgc3BlY2lmaWNhdGlvbnMgaW4gdGhlIHRleHQgb2YgdGhlIFJGQ10N Cj4gPiAgICB3aWxsIGJlIGFibGUgdG8gcHJvY2VzcyB0aGUgdGFncyBkZXNjcmliZWQgYnkgdGhp cyBkb2N1bWVudC4gIEluDQo+ID4gICAgYWRkaXRpb24sIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBs YW5ndWFnZSB0YWdzIGluIHN1Y2ggYXMgd2F5IGFzIHRvDQo+ID4gICAgZW5zdXJlIGZ1dHVyZSBj b21wYXRpYmlsaXR5Lg0KPiANCj4gDQo+IOKAjk1hcmsNCj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCj4gRnJvbTogIlJhbmR5IFByZXN1aG4iIDxyYW5keV9wcmVzdWhuQG1pbmRz cHJpbmcuY29tPg0KPiBUbzogIkxUUlUgV29ya2luZyBHcm91cCIgPGx0cnVAaWV0Zi5vcmc+DQo+ IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDE0LCAyMDA1IDEyOjA3DQo+IFN1YmplY3Q6IFtMdHJ1XSBD b21wYXRpYmlsaXR5IChXYXM6IExhc3QgY2FsbDogUHJpdmF0ZSBVc2VUYWdzKQ0KPiANCj4gDQo+ ID4gSGkgLQ0KPiA+DQo+ID4gSmVmc2V5IChzZWUgYmVsb3cpIHdyaXRlcyAiSSBtYWtlIGl0IGEg bGFzdCBjYWxsIGlzc3VlIHRoYXQgc3VjaCBhDQo+IGJhY2t3YXJkDQo+ID4gImNvbXBhdGlibGl0 eSIgd2hlbiBub24gbmVjZXNzYXJ5IGlzIG5vdCB0byBiZSBpbnRyb2R1Y2VkIi4gIEluIHRoZQ0K PiBjb250ZXh0DQo+ID4gb2YgdGhpcyBkaXNjdXNzaW9uLCBhbmQgb2YgcHJldmlvdXMgZGlzY3Vz c2lvbnMgb24gdGhpcyBsaXN0LCB0aGUgaXNzdWUNCj4gYXBwZWFycw0KPiA+IHRvIGJlIG9uZSBv ZiB3aGF0IGlzIHBlcm1pdHRlZCBieSB0aGUgQUJORi4gIEluIHBhcnRpY3VsYXIsIEkgYmVsaWV2 ZQ0KPiB0aGUNCj4gcXVlc3Rpb24NCj4gPiBpcyB3aGV0aGVyIHRoZSBXRyB3YW50cyB0aGUgQUJO RiB0byBwZXJtaXQgdGhlIGdlbmVyYXRpb24gb2YgdGFncyB3aGljaA0KPiB3b3VsZA0KPiA+IG5v dCBoYXZlIGJlZW4gcGVybWl0dGVkIGJ5IHRoZSBBQk5GIGluIFJGQyAzMDY2Lg0KPiA+DQo+ID4g VGhlIHJlc29sdXRpb24gb2YgaXNzdWVzIGxpa2UgIzk0NSBhbmQgIzk0OSBpbmRpY2F0ZXMgdGhh dCB0aGUgV0cgcGxhY2VzDQo+IGF0IGxlYXN0DQo+ID4gc29tZSB2YWx1ZSBvbiBjb21wYXRpYmls aXR5LCBhbmQgdGhlIGNvbW1lbnRzIGluZGljYXRlIHRoYXQgdGhlcmUgaXMNCj4gc3Ryb25nIGlu dGVyZXN0DQo+ID4gaW4gZW5zdXJpbmcgdGhhdCBleGlzdGluZyBjb2RlIHdpbGwgYmUgYWJsZSB0 byBzeW50YWN0aWNhbGx5IGNvcGUgd2l0aA0KPiBuZXcNCj4gdGFncy4NCj4gPg0KPiA+IEhvd2V2 ZXIsIGp1c3QgdG8gcmVtb3ZlIGFsbCBkb3VidCwgSSdkIGxpa2UgYSBodW0gb24gdGhlIGZvbGxv d2luZw0KPiBwYXJhZ3JhcGggZnJvbQ0KPiA+IHRoZSByZWdpc3RyeSBkcmFmdCdzIG1hdGVyaWFs IG9uICJnb2FscyI6DQo+ID4NCj4gPiAgICAqQ29tcGF0aWJpbGl0eS4qIEFsbCBSRkMgMzA2NiBs YW5ndWFnZSB0YWdzICAoaW5jbHVkaW5nIHRob3NlIGluIHRoZQ0KPiA+ICAgIElBTkEgcmVnaXN0 cnkpICByZW1haW4gdmFsaWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uLiAgVGhlIGNoYW5nZXMgaW4N Cj4gPiAgICB0aGlzIGRvY3VtZW50IHJlcHJlc2VudCBhZGRpdGlvbmFsIGNvbnN0cmFpbnRzIG9u IGxhbmd1YWdlIHRhZ3MuDQo+ID4gICAgVGhhdCBpcywgaW4gbm8gY2FzZSBpcyB0aGUgc3ludGF4 IG1vcmUgcGVybWlzc2l2ZSBhbmQgcHJvY2Vzc29ycw0KPiA+ICAgIGJhc2VkIG9uIHRoZSBSRkMg MzA2NiBBQk5GIChzdWNoIGFzIHRob3NlIGRlc2NyaWJlZCBpbiBbWE1MU2NoZW1hXSkNCj4gPiAg ICB3aWxsIGJlIGFibGUgdG8gcHJvY2VzcyB0aGUgdGFncyBkZXNjcmliZWQgYnkgdGhpcyBkb2N1 bWVudC4gIEluDQo+ID4gICAgYWRkaXRpb24sIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBsYW5ndWFn ZSB0YWdzIGluIHN1Y2ggYXMgd2F5IGFzIHRvDQo+ID4gICAgZW5zdXJlIGZ1dHVyZSBjb21wYXRp YmlsaXR5Lg0KPiA+DQo+ID4gUGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IGFncmVlIG9yIGRp c2FncmVlIHdpdGggdGhpcyBnb2FsLiAgQSBjaGVjaw0KPiA+IHdpdGggaHR0cDovL3Rvb2xzLmll dGYub3JnL3dnL2x0cnUvZHJhZnQtaWV0Zi1sdHJ1LXJlZ2lzdHJ5LyBzaG93cyB0aGF0DQo+IHRo aXMNCj4gPiBtYXRlcmlhbCBoYXMgYmVlbiBhcm91bmQgZm9yIGEgd2hpbGUsIG1vZHVsbyB3b3Jk c21pdGhpbmcuDQo+ID4NCj4gPiBSYW5keSwgbHRydSBjby1jaGFpcg0KPiA+DQo+ID4gPiBGcm9t OiAiciZkIGFmcmFjIiA8cmRAYWZyYWMub3JnPg0KPiA+ID4gVG86ICJQZXRlciBDb25zdGFibGUi IDxwZXRlcmNvbkBtaWNyb3NvZnQuY29tPjsgIkxUUlUgV29ya2luZyBHcm91cCINCj4gPGx0cnVA aWV0Zi5vcmc+DQo+ID4gPiBTZW50OiBUaHVyc2RheSwgSnVseSAxNCwgMjAwNSA1OjI4IEFNDQo+ ID4gPiBTdWJqZWN0OiBbTHRydV0gTGFzdCBjYWxsOiBQcml2YXRlIFVzZVRhZ3MNCj4gPiA+DQo+ ID4NCj4gPiA+IEF0IDAxOjUzIDE0LzA3LzIwMDUsIFBldGVyIENvbnN0YWJsZSB3cm90ZToNCj4g PiA+ID5UaGUgdXNlIG9mIEFscGhhIGFuZCBBbHBoYU51bSwgd2hpY2ggSkZDIGNvbnNpZGVycyBh IGRpc2NyaW1pbmF0b3J5DQo+ID4gPiA+bGltaXRhdGlvbiwNCj4gPiA+DQo+ID4gPiBJIHRoaW5r IHRoZXJlIG1heSBiZSBhIGNvbmZ1c2lvbiBoZXJlIGluIG15IHR5cGluZy4gSSBjb25zaWRlciB3 aGF0IGlzDQo+ID4gPiBkaXNjcmltaW5hdG9yeSAoYW5kIGFsc28gYWJzdXJkKSB0aGUgbGltaXRh dGlvbiBvZiBBbHBoYW51bXMgdG8gOA0KPiBieXRlcw0KPiBpbg0KPiA+ID4geC10YWdzLg0KPiA+ ID4NCj4gPiA+ID5pcyBub3RoaW5nIG9mIHRoZSBzb3J0LCBhbmQgY2Fubm90IGJlIGNoYW5nZWQg dW5sZXNzDQo+ID4gPiA+YmFja3dhcmQgY29tcGF0aWJpbGl0eSBpcyB0byBiZSBhYmFuZG9uZWQu DQo+ID4gPg0KPiA+ID4gSSBmdWxseSBzdXBwb3J0IHRoZSBsb2dpYyBwcmVzZW50ZWQgYnkgRi4g Q2hhcmxlcyB0aGF0IHRoaXMgYmFja3dhcmQNCj4gPiA+IGNvbXBhdGliaWxpdHkgd2l0aCBzb21l dGhpbmcgd2hpY2ggbmV2ZXIgZXhpc3RlZCAoc2luY2UgZnV0dXJlIHgtdGFncw0KPiBhcmUNCj4g PiA+IGJ5IG5hdHVyZSAuLi4gZnV0dXJlKSBpcyBhYnN1cmQuIFRoaXMgaXMgYSBnb29kIGRvY3Vt ZW50YXRpb24gb2YgdGhlDQo+ID4gPiByZWxpZ2lvdXMgb3Bwb3NpdGlvbiBvZiB0aGlzIERyYWZ0 IHRvIGZ1dHVyZSBhbmQgaW5ub3ZhdGlvbi4NCj4gPiA+DQo+ID4gPiA+U2luY2UgdGhlcmUgd2Fz IGNvbnNlbnN1cw0KPiA+ID4gPmZyb20gdGhlIG91dHNldCB0aGF0IGJhY2t3YXJkIGNvbXBhdGli aWxpdHkgbXVzdCBiZSBtYWludGFpbmVkLA0KPiA+ID4NCj4gPiA+IFBsZWFzZSByZWZlcmVuY2Ug dGhlIFVSTCBvZiB0aGlzIGNvbnNlbnN1cy4gSSBtYWtlIGl0IGEgbGFzdCBjYWxsDQo+IGlzc3Vl DQo+ID4gPiB0aGF0IHN1Y2ggYSBiYWNrd2FyZCAiY29tcGF0aWJsaXR5IiB3aGVuIG5vbiBuZWNl c3NhcnkgaXMgbm90IHRvIGJlDQo+IGludHJvZHVjZWQuDQo+ID4gPg0KPiA+ID4gPmFuZA0KPiA+ ID4gPnNpbmNlIGl0IHdhcyBjbGVhciBmcm9tIHRoZSBsYXN0IGNhbGwgYmFjayBpbiBEZWNlbWJl ciB0aGF0IGJhY2t3YXJkDQo+ID4gPiA+Y29tcGF0aWJpbGl0eSB3aXRoIHByb3RvY29scyB0aGF0 IGNvbnN1bWUgUkZDIDMwNjYgaXMgZXNzZW50aWFsLA0KPiA+ID4NCj4gPiA+IDEuIGFzIHNvbWVv bmUgcHV0IGl0IGFnYWluc3QgbWU6IERlY2VtYmVyIExhc3QgQ2FsbCBpcyBvdmVyLg0KPiA+ID4g Mi4gSSB3YXMgSSB0aGluayBvbmUgb2YgdGhlIG1vc3QgYWN0aXZlIGR1cmluZyB0aGF0IFhtYXMg Q2FsbC4uLi4NCj4gPiA+DQo+ID4gPiA+dGhlbiBJDQo+ID4gPiA+dGhpbmsgdGhpcyBpcyBub3Qg b3BlbiB0byByZWNvbnNpZGVyYXRpb24sIGFuZCB0aGVyZWZvcmUgdGhpcw0KPiBwcm9wb3NlZA0K PiA+ID4gPnRleHQgY2Fubm90IGJlIGFjY2VwdGVkLg0KPiA+ID4NCj4gPiA+ICJJIHRoaW5rIiBp cyBub3QgYSBjb25zZW5zdXMuICJJIHRoaW5rIG15c2VsZiIgaXMgbm90IGVpdGhlci4gT25seSAi d2UNCj4gPiA+IHRoaW5rIiBtYWtlcyBvbmUuDQo+ID4gPiBJIGRvIG5vdCBrbm93IGlmIGEgdGV4 dCBjYW5ub3QgYmUgYWNjZXB0ZWQgZHVlIHRvIHlvdXIgb3Bpbmlvbi4gQnV0IEkNCj4ga25vdw0K PiA+ID4gdGhhdCBubyBvbmUgd2lsbCB0aGluayB0aGVyZSBhIGNvbnNlbnN1cyBhZ2FpbnN0IHJ1 bm5pbmcgY29kZS4uLi4NCj4gPiA+DQo+ID4gPiA+VGh1cywgSSB0aGluayB0aGlzIGlzc3VlIGNh biByZW1haW4gY2xvc2VkLg0KPiA+ID4NCj4gPiA+IElmIHlvdSBtZWFuIHRoZSB3aG9sZSBEcmFm dCwgSSB0aGluayBpdCBjb3VsZC4gQnV0IHRoaXMgd291bGQgbm90DQo+IGNoYW5nZQ0KPiA+ID4g dGhhdCB0aGUgY3VycmVudCB3b3JrIGluIG1hbnkgYXJlYXMgbmVlZCBhIGZyYW1ld29yay4gSSBk byBub3Qgb3Bwb3NlDQo+IGENCj4gPiA+IGdyYXNyb290cyBvbmUsIGJ1dCBJIHRoaW5rIHRoYXQg YW4gYWRoZXJlbmNlIG9mIElFVEYgdG8gdGhhdCBwcm9jZXNzDQo+IHdvdWxkDQo+ID4gPiBiZSBv ZiBpbnRlcmVzdC4NCj4gPiA+IGpmYw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBMdHJ1IG1haWxpbmcg bGlzdA0KPiA+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9sdHJ1DQo+ID4NCj4gPg0KPiANCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlz dA0KPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2x0cnUNCg0K --===============0122108333== 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 --===============0122108333==-- From sipping-bounces@ietf.org Thu Jul 14 18:17:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtBwS-0001rH-Uw; Thu, 14 Jul 2005 18: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 1DtBwQ-0001r5-W1 for sipping@megatron.ietf.org; Thu, 14 Jul 2005 18:12:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11828 for ; Thu, 14 Jul 2005 18:12:24 -0400 (EDT) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtCP7-000456-LF for sipping@ietf.org; Thu, 14 Jul 2005 18:42:06 -0400 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j6EMCLbf013276; Thu, 14 Jul 2005 17:12:21 -0500 (CDT) Received: from [135.180.240.186] (volker-hopc.dnrc.bell-labs.com [135.180.240.186]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j6EMCLq20566; Thu, 14 Jul 2005 18:12:21 -0400 (EDT) Message-ID: <42D6E358.4010303@bell-labs.com> Date: Thu, 14 Jul 2005 18:12:40 -0400 From: Volker Hilt User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sipping Content-Type: multipart/mixed; boundary="------------000601040102030909030906" X-Spam-Score: 0.1 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: Gonzalo Camarillo Subject: [Sipping] [Fwd: I-D ACTION:draft-hilt-sipping-session-spec-policy-03.txt] X-BeenThere: sipping@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SIPPING Working Group \(applications of SIP\)" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sipping-bounces@ietf.org Errors-To: sipping-bounces@ietf.org This is a multi-part message in MIME format. --------------000601040102030909030906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, we have submitted a new version of the session-specific policy draft (see attached email). This version has a completely revised section on the policy channel protocol. The section now covers the design alternatives for conveying session information from a user agent to a policy server. This discussion together with the use cases in http://www.ietf.org/internet-drafts/draft-hilt-sipping-policy-usecases-00.txt should provide a foundation for a design decision on this mechanism. The draft also proposes a method for subscribing to session-specific policies on a policy server. This method is based on a new profile-type 'policy' for the configuration framework. Comments and feedback are highly appreciated. Thanks, Volker --------------000601040102030909030906 Content-Type: message/rfc822; name="I-D ACTION:draft-hilt-sipping-session-spec-policy-03.txt" Content-Disposition: inline; filename="I-D ACTION:draft-hilt-sipping-session-spec-policy-03.txt" Return-Path: Received: from hoemail2.lucent.com (hoemail2.lucent.com [192.11.226.163]) by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j6EK2pq06734; Thu, 14 Jul 2005 16:02:51 -0400 (EDT) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j6EK2iRV014741; Thu, 14 Jul 2005 15:02:44 -0500 (CDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9j8-0007nQ-Gg; Thu, 14 Jul 2005 15:50:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9ig-0007am-SZ for i-d-announce@megatron.ietf.org; Thu, 14 Jul 2005 15:50:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13613 for ; Thu, 14 Jul 2005 15:50:04 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtABJ-0008QM-I4 for i-d-announce@ietf.org; Thu, 14 Jul 2005 16:19:43 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dt9ic-0006DP-Se for i-d-announce@ietf.org; Thu, 14 Jul 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: I-D ACTION:draft-hilt-sipping-session-spec-policy-03.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Delivery Mechanism for Session-Specific Session Initiation Protocol(SIP) Session Policies Author(s) : V. Hilt, et al. Filename : draft-hilt-sipping-session-spec-policy-03.txt Pages : 20 Date : 2005-7-14 This specification defines a delivery mechanism for session-specific Session Initiation Protocol (SIP) sessions policies. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-spec-policy-03.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-hilt-sipping-session-spec-policy-03.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-hilt-sipping-session-spec-policy-03.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-7-14113327.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hilt-sipping-session-spec-policy-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-hilt-sipping-session-spec-policy-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-14113327.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------000601040102030909030906 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP --------------000601040102030909030906-- From ltru-bounces@lists.ietf.org Thu Jul 14 18:18:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtC2f-0004gY-Tc; Thu, 14 Jul 2005 18:18:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtC2f-0004gT-0D for ltru@megatron.ietf.org; Thu, 14 Jul 2005 18:18:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12847 for ; Thu, 14 Jul 2005 18:18: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.43) id 1DtCVL-0004KL-Pf for ltru@ietf.org; Thu, 14 Jul 2005 18:48:32 -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 Jul 2005 15:18:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ltru] Compatibility (Was: Last call: Private UseTags) Date: Thu, 14 Jul 2005 15:18:40 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D3FD@irvmbxw01.quest.com> Thread-Topic: [Ltru] Compatibility (Was: Last call: Private UseTags) Thread-Index: AcWIvbcZa/NvBllBSPyb4XV5J6zqigABBgqw From: "Addison Phillips" To: "Mark Davis" , "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 14 Jul 2005 22:18:41.0358 (UTC) FILETIME=[FD8896E0:01C588C1] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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="===============0147842472==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0147842472== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBoYXZlIHBlcmZvcm1lZCB0aGUgZm9sbG93aW5nIGVkaXRvcmlhbCBjaGFuZ2UgaW4gdGhlIGVk aXRvcidzIGNvcHkgcGVyIE1hcmsncyBlbWFpbDoNCg0KPHQ+PHNwYW54IHN0eWxlPSJzdHJvbmci PkNvbXBhdGliaWxpdHkuPC9zcGFueD4gQWxsIFJGQyAzMDY2IGxhbmd1YWdlIHRhZ3MgIChpbmNs dWRpbmcgdGhvc2UgaW4gdGhlIElBTkEgcmVnaXN0cnkpICByZW1haW4gdmFsaWQgaW4gdGhpcyBz cGVjaWZpY2F0aW9uLiBUaGUgY2hhbmdlcyBpbiB0aGlzIGRvY3VtZW50IHJlcHJlc2VudCBhZGRp dGlvbmFsIGNvbnN0cmFpbnRzIG9uIGxhbmd1YWdlIHRhZ3MuIFRoYXQgaXMsIGluIG5vIGNhc2Ug aXMgdGhlIHN5bnRheCBtb3JlIHBlcm1pc3NpdmUgYW5kIHByb2Nlc3NvcnMgYmFzZWQgb24gdGhl IEFCTkYgYW5kIG90aGVyIHByb3Zpc2lvbnMgb2YgUkZDIDMwNjYgKHN1Y2ggYXMgdGhvc2UgZGVz Y3JpYmVkIGluIDx4cmVmIHRhcmdldD0iWE1MU2NoZW1hIj48L3hyZWY+KSB3aWxsIGJlIGFibGUg dG8gcHJvY2VzcyB0aGUgdGFncyBkZXNjcmliZWQgYnkgdGhpcyBkb2N1bWVudC4gSW4gYWRkaXRp b24sIHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBsYW5ndWFnZSB0YWdzIGluIHN1Y2ggYXMgd2F5IGFz IHRvIGVuc3VyZSBmdXR1cmUgY29tcGF0aWJpbGl0eS48L3Q+DQoNCkluIG90aGVyIHdvcmRzLCB0 aGUgcGhyYXNlICJiYXNlZCBvbiB0aGUgUkZDIDMwNjYgQUJORiIgbm93IHJlYWRzOg0KDQoiYmFz ZWQgb24gdGhlIEFCTkYgYW5kIG90aGVyIHByb3Zpc2lvbnMgb2YgUkZDIDMwNjYiDQoNCn5BZGRp c29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVz dCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcg R3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFu IGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog bHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxpc3RzLmll dGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgTWFyayBEYXZpcw0KPiBTZW50OiAyMDA15bm0N+aciDE0 5pelIDE0OjQwDQo+IFRvOiBSYW5keSBQcmVzdWhuOyBMVFJVIFdvcmtpbmcgR3JvdXANCj4gU3Vi amVjdDogUmU6IFtMdHJ1XSBDb21wYXRpYmlsaXR5IChXYXM6IExhc3QgY2FsbDogUHJpdmF0ZSBV c2VUYWdzKQ0KPiANCj4gVGhlIGdvYWwgaGFzIGFsd2F5cyBiZWVuIHByZXNlbnQsIGFuZCBJIHRo aW5rIGFkZGluZyB0aGUgcGFyYWdyYXBoIGlzIGENCj4gd29ydGh3aGlsZSBjbGFyaWZpY2F0aW9u LiBJIHdvdWxkIG1ha2Ugb25lIGNoYW5nZTogdGhlIEFCTkYgaXMgbm90IHRoZQ0KPiBvbmx5DQo+ IGNvbnN0cmFpbnQgb24gdGhlIHNwZWNpZmljYXRpb24sIGFuZCBzb21lb25lIG1pZ2h0IHJlYWQg dGhlIHBhcmFncmFwaCBhcw0KPiBpbXBseWluZyB0aGF0LiBTbzoNCj4gDQo+ID4gICAgKkNvbXBh dGliaWxpdHkuKiBBbGwgUkZDIDMwNjYgbGFuZ3VhZ2UgdGFncyAgKGluY2x1ZGluZyB0aG9zZSBp biB0aGUNCj4gPiAgICBJQU5BIHJlZ2lzdHJ5KSAgcmVtYWluIHZhbGlkIGluIHRoaXMgc3BlY2lm aWNhdGlvbi4gIFRoZSBjaGFuZ2VzIGluDQo+ID4gICAgdGhpcyBkb2N1bWVudCByZXByZXNlbnQg YWRkaXRpb25hbCBjb25zdHJhaW50cyBvbiBsYW5ndWFnZSB0YWdzLg0KPiA+ICAgIFRoYXQgaXMs IGluIG5vIGNhc2UgaXMgdGhlIHN5bnRheCBtb3JlIHBlcm1pc3NpdmUgYW5kIHByb2Nlc3NvcnMN Cj4gPiAgICBiYXNlZCBvbiB0aGUgUkZDIDMwNjYgQUJORiAoc3VjaCBhcyB0aG9zZSBkZXNjcmli ZWQgaW4gW1hNTFNjaGVtYV0pDQo+IFthZGQ6IGFuZCB0aGUgb3RoZXIgc3BlY2lmaWNhdGlvbnMg aW4gdGhlIHRleHQgb2YgdGhlIFJGQ10NCj4gPiAgICB3aWxsIGJlIGFibGUgdG8gcHJvY2VzcyB0 aGUgdGFncyBkZXNjcmliZWQgYnkgdGhpcyBkb2N1bWVudC4gIEluDQo+ID4gICAgYWRkaXRpb24s IHRoaXMgZG9jdW1lbnQgZGVmaW5lcyBsYW5ndWFnZSB0YWdzIGluIHN1Y2ggYXMgd2F5IGFzIHRv DQo+ID4gICAgZW5zdXJlIGZ1dHVyZSBjb21wYXRpYmlsaXR5Lg0KPiANCj4gDQo+IOKAjk1hcmsN Cj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogIlJhbmR5IFByZXN1 aG4iIDxyYW5keV9wcmVzdWhuQG1pbmRzcHJpbmcuY29tPg0KPiBUbzogIkxUUlUgV29ya2luZyBH cm91cCIgPGx0cnVAaWV0Zi5vcmc+DQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDE0LCAyMDA1IDEy OjA3DQo+IFN1YmplY3Q6IFtMdHJ1XSBDb21wYXRpYmlsaXR5IChXYXM6IExhc3QgY2FsbDogUHJp dmF0ZSBVc2VUYWdzKQ0KPiANCj4gDQo+ID4gSGkgLQ0KPiA+DQo+ID4gSmVmc2V5IChzZWUgYmVs b3cpIHdyaXRlcyAiSSBtYWtlIGl0IGEgbGFzdCBjYWxsIGlzc3VlIHRoYXQgc3VjaCBhDQo+IGJh Y2t3YXJkDQo+ID4gImNvbXBhdGlibGl0eSIgd2hlbiBub24gbmVjZXNzYXJ5IGlzIG5vdCB0byBi ZSBpbnRyb2R1Y2VkIi4gIEluIHRoZQ0KPiBjb250ZXh0DQo+ID4gb2YgdGhpcyBkaXNjdXNzaW9u LCBhbmQgb2YgcHJldmlvdXMgZGlzY3Vzc2lvbnMgb24gdGhpcyBsaXN0LCB0aGUgaXNzdWUNCj4g YXBwZWFycw0KPiA+IHRvIGJlIG9uZSBvZiB3aGF0IGlzIHBlcm1pdHRlZCBieSB0aGUgQUJORi4g IEluIHBhcnRpY3VsYXIsIEkgYmVsaWV2ZQ0KPiB0aGUNCj4gcXVlc3Rpb24NCj4gPiBpcyB3aGV0 aGVyIHRoZSBXRyB3YW50cyB0aGUgQUJORiB0byBwZXJtaXQgdGhlIGdlbmVyYXRpb24gb2YgdGFn cyB3aGljaA0KPiB3b3VsZA0KPiA+IG5vdCBoYXZlIGJlZW4gcGVybWl0dGVkIGJ5IHRoZSBBQk5G IGluIFJGQyAzMDY2Lg0KPiA+DQo+ID4gVGhlIHJlc29sdXRpb24gb2YgaXNzdWVzIGxpa2UgIzk0 NSBhbmQgIzk0OSBpbmRpY2F0ZXMgdGhhdCB0aGUgV0cgcGxhY2VzDQo+IGF0IGxlYXN0DQo+ID4g c29tZSB2YWx1ZSBvbiBjb21wYXRpYmlsaXR5LCBhbmQgdGhlIGNvbW1lbnRzIGluZGljYXRlIHRo YXQgdGhlcmUgaXMNCj4gc3Ryb25nIGludGVyZXN0DQo+ID4gaW4gZW5zdXJpbmcgdGhhdCBleGlz dGluZyBjb2RlIHdpbGwgYmUgYWJsZSB0byBzeW50YWN0aWNhbGx5IGNvcGUgd2l0aA0KPiBuZXcN Cj4gdGFncy4NCj4gPg0KPiA+IEhvd2V2ZXIsIGp1c3QgdG8gcmVtb3ZlIGFsbCBkb3VidCwgSSdk IGxpa2UgYSBodW0gb24gdGhlIGZvbGxvd2luZw0KPiBwYXJhZ3JhcGggZnJvbQ0KPiA+IHRoZSBy ZWdpc3RyeSBkcmFmdCdzIG1hdGVyaWFsIG9uICJnb2FscyI6DQo+ID4NCj4gPiAgICAqQ29tcGF0 aWJpbGl0eS4qIEFsbCBSRkMgMzA2NiBsYW5ndWFnZSB0YWdzICAoaW5jbHVkaW5nIHRob3NlIGlu IHRoZQ0KPiA+ICAgIElBTkEgcmVnaXN0cnkpICByZW1haW4gdmFsaWQgaW4gdGhpcyBzcGVjaWZp Y2F0aW9uLiAgVGhlIGNoYW5nZXMgaW4NCj4gPiAgICB0aGlzIGRvY3VtZW50IHJlcHJlc2VudCBh ZGRpdGlvbmFsIGNvbnN0cmFpbnRzIG9uIGxhbmd1YWdlIHRhZ3MuDQo+ID4gICAgVGhhdCBpcywg aW4gbm8gY2FzZSBpcyB0aGUgc3ludGF4IG1vcmUgcGVybWlzc2l2ZSBhbmQgcHJvY2Vzc29ycw0K PiA+ICAgIGJhc2VkIG9uIHRoZSBSRkMgMzA2NiBBQk5GIChzdWNoIGFzIHRob3NlIGRlc2NyaWJl ZCBpbiBbWE1MU2NoZW1hXSkNCj4gPiAgICB3aWxsIGJlIGFibGUgdG8gcHJvY2VzcyB0aGUgdGFn cyBkZXNjcmliZWQgYnkgdGhpcyBkb2N1bWVudC4gIEluDQo+ID4gICAgYWRkaXRpb24sIHRoaXMg ZG9jdW1lbnQgZGVmaW5lcyBsYW5ndWFnZSB0YWdzIGluIHN1Y2ggYXMgd2F5IGFzIHRvDQo+ID4g ICAgZW5zdXJlIGZ1dHVyZSBjb21wYXRpYmlsaXR5Lg0KPiA+DQo+ID4gUGxlYXNlIGluZGljYXRl IHdoZXRoZXIgeW91IGFncmVlIG9yIGRpc2FncmVlIHdpdGggdGhpcyBnb2FsLiAgQSBjaGVjaw0K PiA+IHdpdGggaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2x0cnUvZHJhZnQtaWV0Zi1sdHJ1LXJl Z2lzdHJ5LyBzaG93cyB0aGF0DQo+IHRoaXMNCj4gPiBtYXRlcmlhbCBoYXMgYmVlbiBhcm91bmQg Zm9yIGEgd2hpbGUsIG1vZHVsbyB3b3Jkc21pdGhpbmcuDQo+ID4NCj4gPiBSYW5keSwgbHRydSBj by1jaGFpcg0KPiA+DQo+ID4gPiBGcm9tOiAiciZkIGFmcmFjIiA8cmRAYWZyYWMub3JnPg0KPiA+ ID4gVG86ICJQZXRlciBDb25zdGFibGUiIDxwZXRlcmNvbkBtaWNyb3NvZnQuY29tPjsgIkxUUlUg V29ya2luZyBHcm91cCINCj4gPGx0cnVAaWV0Zi5vcmc+DQo+ID4gPiBTZW50OiBUaHVyc2RheSwg SnVseSAxNCwgMjAwNSA1OjI4IEFNDQo+ID4gPiBTdWJqZWN0OiBbTHRydV0gTGFzdCBjYWxsOiBQ cml2YXRlIFVzZVRhZ3MNCj4gPiA+DQo+ID4NCj4gPiA+IEF0IDAxOjUzIDE0LzA3LzIwMDUsIFBl dGVyIENvbnN0YWJsZSB3cm90ZToNCj4gPiA+ID5UaGUgdXNlIG9mIEFscGhhIGFuZCBBbHBoYU51 bSwgd2hpY2ggSkZDIGNvbnNpZGVycyBhIGRpc2NyaW1pbmF0b3J5DQo+ID4gPiA+bGltaXRhdGlv biwNCj4gPiA+DQo+ID4gPiBJIHRoaW5rIHRoZXJlIG1heSBiZSBhIGNvbmZ1c2lvbiBoZXJlIGlu IG15IHR5cGluZy4gSSBjb25zaWRlciB3aGF0IGlzDQo+ID4gPiBkaXNjcmltaW5hdG9yeSAoYW5k IGFsc28gYWJzdXJkKSB0aGUgbGltaXRhdGlvbiBvZiBBbHBoYW51bXMgdG8gOA0KPiBieXRlcw0K PiBpbg0KPiA+ID4geC10YWdzLg0KPiA+ID4NCj4gPiA+ID5pcyBub3RoaW5nIG9mIHRoZSBzb3J0 LCBhbmQgY2Fubm90IGJlIGNoYW5nZWQgdW5sZXNzDQo+ID4gPiA+YmFja3dhcmQgY29tcGF0aWJp bGl0eSBpcyB0byBiZSBhYmFuZG9uZWQuDQo+ID4gPg0KPiA+ID4gSSBmdWxseSBzdXBwb3J0IHRo ZSBsb2dpYyBwcmVzZW50ZWQgYnkgRi4gQ2hhcmxlcyB0aGF0IHRoaXMgYmFja3dhcmQNCj4gPiA+ IGNvbXBhdGliaWxpdHkgd2l0aCBzb21ldGhpbmcgd2hpY2ggbmV2ZXIgZXhpc3RlZCAoc2luY2Ug ZnV0dXJlIHgtdGFncw0KPiBhcmUNCj4gPiA+IGJ5IG5hdHVyZSAuLi4gZnV0dXJlKSBpcyBhYnN1 cmQuIFRoaXMgaXMgYSBnb29kIGRvY3VtZW50YXRpb24gb2YgdGhlDQo+ID4gPiByZWxpZ2lvdXMg b3Bwb3NpdGlvbiBvZiB0aGlzIERyYWZ0IHRvIGZ1dHVyZSBhbmQgaW5ub3ZhdGlvbi4NCj4gPiA+ DQo+ID4gPiA+U2luY2UgdGhlcmUgd2FzIGNvbnNlbnN1cw0KPiA+ID4gPmZyb20gdGhlIG91dHNl dCB0aGF0IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgbXVzdCBiZSBtYWludGFpbmVkLA0KPiA+ID4N Cj4gPiA+IFBsZWFzZSByZWZlcmVuY2UgdGhlIFVSTCBvZiB0aGlzIGNvbnNlbnN1cy4gSSBtYWtl IGl0IGEgbGFzdCBjYWxsDQo+IGlzc3VlDQo+ID4gPiB0aGF0IHN1Y2ggYSBiYWNrd2FyZCAiY29t cGF0aWJsaXR5IiB3aGVuIG5vbiBuZWNlc3NhcnkgaXMgbm90IHRvIGJlDQo+IGludHJvZHVjZWQu DQo+ID4gPg0KPiA+ID4gPmFuZA0KPiA+ID4gPnNpbmNlIGl0IHdhcyBjbGVhciBmcm9tIHRoZSBs YXN0IGNhbGwgYmFjayBpbiBEZWNlbWJlciB0aGF0IGJhY2t3YXJkDQo+ID4gPiA+Y29tcGF0aWJp bGl0eSB3aXRoIHByb3RvY29scyB0aGF0IGNvbnN1bWUgUkZDIDMwNjYgaXMgZXNzZW50aWFsLA0K PiA+ID4NCj4gPiA+IDEuIGFzIHNvbWVvbmUgcHV0IGl0IGFnYWluc3QgbWU6IERlY2VtYmVyIExh c3QgQ2FsbCBpcyBvdmVyLg0KPiA+ID4gMi4gSSB3YXMgSSB0aGluayBvbmUgb2YgdGhlIG1vc3Qg YWN0aXZlIGR1cmluZyB0aGF0IFhtYXMgQ2FsbC4uLi4NCj4gPiA+DQo+ID4gPiA+dGhlbiBJDQo+ ID4gPiA+dGhpbmsgdGhpcyBpcyBub3Qgb3BlbiB0byByZWNvbnNpZGVyYXRpb24sIGFuZCB0aGVy ZWZvcmUgdGhpcw0KPiBwcm9wb3NlZA0KPiA+ID4gPnRleHQgY2Fubm90IGJlIGFjY2VwdGVkLg0K PiA+ID4NCj4gPiA+ICJJIHRoaW5rIiBpcyBub3QgYSBjb25zZW5zdXMuICJJIHRoaW5rIG15c2Vs ZiIgaXMgbm90IGVpdGhlci4gT25seSAid2UNCj4gPiA+IHRoaW5rIiBtYWtlcyBvbmUuDQo+ID4g PiBJIGRvIG5vdCBrbm93IGlmIGEgdGV4dCBjYW5ub3QgYmUgYWNjZXB0ZWQgZHVlIHRvIHlvdXIg b3Bpbmlvbi4gQnV0IEkNCj4ga25vdw0KPiA+ID4gdGhhdCBubyBvbmUgd2lsbCB0aGluayB0aGVy ZSBhIGNvbnNlbnN1cyBhZ2FpbnN0IHJ1bm5pbmcgY29kZS4uLi4NCj4gPiA+DQo+ID4gPiA+VGh1 cywgSSB0aGluayB0aGlzIGlzc3VlIGNhbiByZW1haW4gY2xvc2VkLg0KPiA+ID4NCj4gPiA+IElm IHlvdSBtZWFuIHRoZSB3aG9sZSBEcmFmdCwgSSB0aGluayBpdCBjb3VsZC4gQnV0IHRoaXMgd291 bGQgbm90DQo+IGNoYW5nZQ0KPiA+ID4gdGhhdCB0aGUgY3VycmVudCB3b3JrIGluIG1hbnkgYXJl YXMgbmVlZCBhIGZyYW1ld29yay4gSSBkbyBub3Qgb3Bwb3NlDQo+IGENCj4gPiA+IGdyYXNyb290 cyBvbmUsIGJ1dCBJIHRoaW5rIHRoYXQgYW4gYWRoZXJlbmNlIG9mIElFVEYgdG8gdGhhdCBwcm9j ZXNzDQo+IHdvdWxkDQo+ID4gPiBiZSBvZiBpbnRlcmVzdC4NCj4gPiA+IGpmYw0KPiA+DQo+ID4N Cj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiA+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQo+ID4NCj4gPg0K PiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+IGh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUNCg0K --===============0147842472== 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 --===============0147842472==-- From ltru-bounces@lists.ietf.org Thu Jul 14 19:56:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtDZZ-0007vS-Ju; Thu, 14 Jul 2005 19:56:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtDZY-0007vI-20 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 19:56:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22326 for ; Thu, 14 Jul 2005 19:56:52 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtE2F-00082Q-Jc for ltru@ietf.org; Thu, 14 Jul 2005 20:26:35 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtDZR-00065T-2y; Thu, 14 Jul 2005 16:56:49 -0700 Message-Id: <6.2.1.2.2.20050714231220.04555040@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 14 Jul 2005 23:22:26 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac In-Reply-To: <00a501c588a7$425f8780$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050714140510.04536780@mail.afrac.org> <00a501c588a7$425f8780$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Subject: [Ltru] Compatibilities X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Randy, I am extremely sorry, but I do not think the post below does not seem compatible, at least with a co-chair hat. At 21:07 14/07/2005, Randy Presuhn wrote: >The resolution of issues like #945 and #949 indicates that the WG places >at least >some value on compatibility, and the comments indicate that there is >strong interest >in ensuring that existing code will be able to syntactically cope with new >tags. This is an opinion. It underlines that the consensus is on "at least some value on compatibility". This I agree, but not on a new "compatibility". That the consensus is a "strong interest". > *Compatibility.* All RFC 3066 language tags (including those in the > IANA registry) remain valid in this specification. The changes in > this document represent additional constraints on language tags. > That is, in no case is the syntax more permissive and processors > based on the RFC 3066 ABNF (such as those described in [XMLSchema]) > will be able to process the tags described by this document. In > addition, this document defines language tags in such as way as to > ensure future compatibility. May I remind this is a last call. And that due to the indications above there must be a consensus on adoption of this. And the silence is not support. >Please indicate whether you agree or disagree with this goal. A check >with http://tools.ietf.org/wg/ltru/draft-ietf-ltru-registry/ shows that this >material has been around for a while, modulo wordsmithing. The lack of analysis of the Charter did not permit to evidence that the problem of RFC 3066 was the lack of organised flexibility. Adding rigidity is not appropriate. The RFC 3066 existing rigidity is a problem which is by nature as old as RFC 3066. The real difficulty will be to have the IESG impose the text of a "Best Common Practices" against used running code and existing published and documented usage (http://rfc3066.org) jfc >Randy, ltru co-chair > > > From: "r&d afrac" > > To: "Peter Constable" ; "LTRU Working Group" > > > Sent: Thursday, July 14, 2005 5:28 AM > > Subject: [Ltru] Last call: Private UseTags > > > > > At 01:53 14/07/2005, Peter Constable wrote: > > >The use of Alpha and AlphaNum, which JFC considers a discriminatory > > >limitation, > > > > I think there may be a confusion here in my typing. I consider what is > > discriminatory (and also absurd) the limitation of Alphanums to 8 bytes in > > x-tags. > > > > >is nothing of the sort, and cannot be changed unless > > >backward compatibility is to be abandoned. > > > > I fully support the logic presented by F. Charles that this backward > > compatibility with something which never existed (since future x-tags are > > by nature ... future) is absurd. This is a good documentation of the > > religious opposition of this Draft to future and innovation. > > > > >Since there was consensus > > >from the outset that backward compatibility must be maintained, > > > > Please reference the URL of this consensus. I make it a last call issue > > that such a backward "compatiblity" when non necessary is not to be > introduced. > > > > >and > > >since it was clear from the last call back in December that backward > > >compatibility with protocols that consume RFC 3066 is essential, > > > > 1. as someone put it against me: December Last Call is over. > > 2. I was I think one of the most active during that Xmas Call.... > > > > >then I > > >think this is not open to reconsideration, and therefore this proposed > > >text cannot be accepted. > > > > "I think" is not a consensus. "I think myself" is not either. Only "we > > think" makes one. > > I do not know if a text cannot be accepted due to your opinion. But I know > > that no one will think there a consensus against running code.... > > > > >Thus, I think this issue can remain closed. > > > > If you mean the whole Draft, I think it could. But this would not change > > that the current work in many areas need a framework. I do not oppose a > > grasroots one, but I think that an adherence of IETF to that process would > > be of interest. > > 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 Thu Jul 14 20:57:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtEWC-00070N-4j; Thu, 14 Jul 2005 20:57:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtEWA-0006wr-40 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 20:57:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25939 for ; Thu, 14 Jul 2005 20:57:28 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtEyr-0001Ho-Or for ltru@ietf.org; Thu, 14 Jul 2005 21:27:10 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtEW6-00008L-LU; Thu, 14 Jul 2005 17:57:27 -0700 Message-Id: <6.2.1.2.2.20050715021116.045a0620@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Jul 2005 02:14:35 +0200 To: "Addison Phillips" , "Mark Davis" , "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: RE: [Ltru] Compatibility (Was: Last call: Private UseTags) In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C20D3F9@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C20D3F9@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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 00:15 15/07/2005, Addison Phillips wrote: >I should note that it isn't clear from Mark's note: this paragraph is >already in the draft, in Section 8 (Changes from RFC 3066), and has been >present since draft-langtags-05 (or, to put it another way, the past >*FIFTEEN* drafts of the document). This requirement should not be a >mystery to anyone at this point. Thank you to remind everyone what should not be a mystery to anyone now: the Draft does not result from a response to the Charter of this WG, but is the 20th version of a Draft which already failed twice an IETF Last Call, for several still non corrected reasons, including that one. Errare humanum est, diabolicum perseverare. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 21:05:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtEeI-0004Dy-L0; Thu, 14 Jul 2005 21:05:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtEeH-0004Dt-Q4 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 21:05:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26397 for ; Thu, 14 Jul 2005 21:05:51 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtF6z-0001WM-UR for ltru@ietf.org; Thu, 14 Jul 2005 21:35:34 -0400 Received: from h-68-166-188-250.snvacaid.dynamic.covad.net ([68.166.188.250] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtEeF-0000Rp-00 for ltru@ietf.org; Thu, 14 Jul 2005 21:05:51 -0400 Message-ID: <001301c588d9$62067bc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.1.2.2.20050714140510.04536780@mail.afrac.org> <00a501c588a7$425f8780$7f1afea9@oemcomputer> <6.2.1.2.2.20050714231220.04555040@mail.afrac.org> Date: Thu, 14 Jul 2005 18: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.1 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Subject: [Ltru] Re: Compatibilities X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Jefsey - If you disagree with the material on compatibility (which has been in the i-d in various forms for a *long* time), then it is up to you to propose text. However, I'd be surprised if the WG agreed to any substantial change in that material. If you have a problem with me as a co-chair, take it up with the ADs. Randy > From: "r&d afrac" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Thursday, July 14, 2005 2:22 PM > Subject: Compatibilities > > Dear Randy, > I am extremely sorry, but I do not think the post below does not seem > compatible, at least with a co-chair hat. > > At 21:07 14/07/2005, Randy Presuhn wrote: > >The resolution of issues like #945 and #949 indicates that the WG places > >at least > >some value on compatibility, and the comments indicate that there is > >strong interest > >in ensuring that existing code will be able to syntactically cope with new > >tags. > > This is an opinion. It underlines that the consensus is on "at least some > value on compatibility". This I agree, but not on a new "compatibility". > That the consensus is a "strong interest". > > > *Compatibility.* All RFC 3066 language tags (including those in the > > IANA registry) remain valid in this specification. The changes in > > this document represent additional constraints on language tags. > > That is, in no case is the syntax more permissive and processors > > based on the RFC 3066 ABNF (such as those described in [XMLSchema]) > > will be able to process the tags described by this document. In > > addition, this document defines language tags in such as way as to > > ensure future compatibility. > > May I remind this is a last call. And that due to the indications above > there must be a consensus on adoption of this. And the silence is not support. > > >Please indicate whether you agree or disagree with this goal. A check > >with http://tools.ietf.org/wg/ltru/draft-ietf-ltru-registry/ shows that this > >material has been around for a while, modulo wordsmithing. > > The lack of analysis of the Charter did not permit to evidence that the > problem of RFC 3066 was the lack of organised flexibility. Adding rigidity > is not appropriate. The RFC 3066 existing rigidity is a problem which is by > nature as old as RFC 3066. > > The real difficulty will be to have the IESG impose the text of a "Best > Common Practices" against used running code and existing published and > documented usage (http://rfc3066.org) > jfc > > > > > >Randy, ltru co-chair > > > > > From: "r&d afrac" > > > To: "Peter Constable" ; "LTRU Working Group" > > > > > Sent: Thursday, July 14, 2005 5:28 AM > > > Subject: [Ltru] Last call: Private UseTags > > > > > > > > At 01:53 14/07/2005, Peter Constable wrote: > > > >The use of Alpha and AlphaNum, which JFC considers a discriminatory > > > >limitation, > > > > > > I think there may be a confusion here in my typing. I consider what is > > > discriminatory (and also absurd) the limitation of Alphanums to 8 bytes in > > > x-tags. > > > > > > >is nothing of the sort, and cannot be changed unless > > > >backward compatibility is to be abandoned. > > > > > > I fully support the logic presented by F. Charles that this backward > > > compatibility with something which never existed (since future x-tags are > > > by nature ... future) is absurd. This is a good documentation of the > > > religious opposition of this Draft to future and innovation. > > > > > > >Since there was consensus > > > >from the outset that backward compatibility must be maintained, > > > > > > Please reference the URL of this consensus. I make it a last call issue > > > that such a backward "compatiblity" when non necessary is not to be > > introduced. > > > > > > >and > > > >since it was clear from the last call back in December that backward > > > >compatibility with protocols that consume RFC 3066 is essential, > > > > > > 1. as someone put it against me: December Last Call is over. > > > 2. I was I think one of the most active during that Xmas Call.... > > > > > > >then I > > > >think this is not open to reconsideration, and therefore this proposed > > > >text cannot be accepted. > > > > > > "I think" is not a consensus. "I think myself" is not either. Only "we > > > think" makes one. > > > I do not know if a text cannot be accepted due to your opinion. But I know > > > that no one will think there a consensus against running code.... > > > > > > >Thus, I think this issue can remain closed. > > > > > > If you mean the whole Draft, I think it could. But this would not change > > > that the current work in many areas need a framework. I do not oppose a > > > grasroots one, but I think that an adherence of IETF to that process would > > > be of interest. > > > 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 Thu Jul 14 21:27:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtEyk-0007Ue-2V; Thu, 14 Jul 2005 21: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 1DtEyj-0007UM-1c for ltru@megatron.ietf.org; Thu, 14 Jul 2005 21:27:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27368 for ; Thu, 14 Jul 2005 21:26:58 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtFRR-00022o-9o for ltru@ietf.org; Thu, 14 Jul 2005 21:56:41 -0400 Received: from h-68-166-188-250.snvacaid.dynamic.covad.net ([68.166.188.250] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtEyg-0005Nb-00 for ltru@ietf.org; Thu, 14 Jul 2005 21:26:59 -0400 Message-ID: <002b01c588dc$5595f200$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C20D3FD@irvmbxw01.quest.com> Subject: Re: [Ltru] Compatibility (Was: Last call: Private UseTags) Date: Thu, 14 Jul 2005 18:27: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.1 (/) 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: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - As a technical contributor, I can support the original wording as well as the revised wording. Randy > From: "Addison Phillips" > To: "Mark Davis" ; "Randy Presuhn" ; "LTRU Working Group" > Sent: Thursday, July 14, 2005 3:18 PM > Subject: RE: [Ltru] Compatibility (Was: Last call: Private UseTags) > > I have performed the following editorial change in the editor's copy per Mark's email: > > Compatibility. All RFC 3066 language tags (including those in the IANA registry) remain valid in this specification. The changes in this document represent additional constraints on language tags. That is, in no case is the syntax more permissive and processors based on the ABNF and other provisions of RFC 3066 (such as those described in ) will be able to process the tags described by this document. In addition, this document defines language tags in such as way as to ensure future compatibility. > > In other words, the phrase "based on the RFC 3066 ABNF" now reads: > > "based on the ABNF and other provisions of RFC 3066" > > ~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 Mark Davis > > Sent: 2005?7?14? 14:40 > > To: Randy Presuhn; LTRU Working Group > > Subject: Re: [Ltru] Compatibility (Was: Last call: Private UseTags) > > > > The goal has always been present, and I think adding the paragraph is a > > worthwhile clarification. I would make one change: the ABNF is not the > > only > > constraint on the specification, and someone might read the paragraph as > > implying that. So: > > > > > *Compatibility.* All RFC 3066 language tags (including those in the > > > IANA registry) remain valid in this specification. The changes in > > > this document represent additional constraints on language tags. > > > That is, in no case is the syntax more permissive and processors > > > based on the RFC 3066 ABNF (such as those described in [XMLSchema]) > > [add: and the other specifications in the text of the RFC] > > > will be able to process the tags described by this document. In > > > addition, this document defines language tags in such as way as to > > > ensure future compatibility. > > > > > > ?Mark > > > > ----- Original Message ----- > > From: "Randy Presuhn" > > To: "LTRU Working Group" > > Sent: Thursday, July 14, 2005 12:07 > > Subject: [Ltru] Compatibility (Was: Last call: Private UseTags) > > > > > > > Hi - > > > > > > Jefsey (see below) writes "I make it a last call issue that such a > > backward > > > "compatiblity" when non necessary is not to be introduced". In the > > context > > > of this discussion, and of previous discussions on this list, the issue > > appears > > > to be one of what is permitted by the ABNF. In particular, I believe > > the > > question > > > is whether the WG wants the ABNF to permit the generation of tags which > > would > > > not have been permitted by the ABNF in RFC 3066. > > > > > > The resolution of issues like #945 and #949 indicates that the WG places > > at least > > > some value on compatibility, and the comments indicate that there is > > strong interest > > > in ensuring that existing code will be able to syntactically cope with > > new > > tags. > > > > > > However, just to remove all doubt, I'd like a hum on the following > > paragraph from > > > the registry draft's material on "goals": > > > > > > *Compatibility.* All RFC 3066 language tags (including those in the > > > IANA registry) remain valid in this specification. The changes in > > > this document represent additional constraints on language tags. > > > That is, in no case is the syntax more permissive and processors > > > based on the RFC 3066 ABNF (such as those described in [XMLSchema]) > > > will be able to process the tags described by this document. In > > > addition, this document defines language tags in such as way as to > > > ensure future compatibility. > > > > > > Please indicate whether you agree or disagree with this goal. A check > > > with http://tools.ietf.org/wg/ltru/draft-ietf-ltru-registry/ shows that > > this > > > material has been around for a while, modulo wordsmithing. > > > > > > Randy, ltru co-chair > > > > > > > From: "r&d afrac" > > > > To: "Peter Constable" ; "LTRU Working Group" > > > > > > Sent: Thursday, July 14, 2005 5:28 AM > > > > Subject: [Ltru] Last call: Private UseTags > > > > > > > > > > > At 01:53 14/07/2005, Peter Constable wrote: > > > > >The use of Alpha and AlphaNum, which JFC considers a discriminatory > > > > >limitation, > > > > > > > > I think there may be a confusion here in my typing. I consider what is > > > > discriminatory (and also absurd) the limitation of Alphanums to 8 > > bytes > > in > > > > x-tags. > > > > > > > > >is nothing of the sort, and cannot be changed unless > > > > >backward compatibility is to be abandoned. > > > > > > > > I fully support the logic presented by F. Charles that this backward > > > > compatibility with something which never existed (since future x-tags > > are > > > > by nature ... future) is absurd. This is a good documentation of the > > > > religious opposition of this Draft to future and innovation. > > > > > > > > >Since there was consensus > > > > >from the outset that backward compatibility must be maintained, > > > > > > > > Please reference the URL of this consensus. I make it a last call > > issue > > > > that such a backward "compatiblity" when non necessary is not to be > > introduced. > > > > > > > > >and > > > > >since it was clear from the last call back in December that backward > > > > >compatibility with protocols that consume RFC 3066 is essential, > > > > > > > > 1. as someone put it against me: December Last Call is over. > > > > 2. I was I think one of the most active during that Xmas Call.... > > > > > > > > >then I > > > > >think this is not open to reconsideration, and therefore this > > proposed > > > > >text cannot be accepted. > > > > > > > > "I think" is not a consensus. "I think myself" is not either. Only "we > > > > think" makes one. > > > > I do not know if a text cannot be accepted due to your opinion. But I > > know > > > > that no one will think there a consensus against running code.... > > > > > > > > >Thus, I think this issue can remain closed. > > > > > > > > If you mean the whole Draft, I think it could. But this would not > > change > > > > that the current work in many areas need a framework. I do not oppose > > a > > > > grasroots one, but I think that an adherence of IETF to that process > > would > > > > be of interest. > > > > 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 > > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 22:05:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtFa5-0006im-7Q; Thu, 14 Jul 2005 22:05:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtFa3-0006ie-0f for ltru@megatron.ietf.org; Thu, 14 Jul 2005 22:05:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29543 for ; Thu, 14 Jul 2005 22:05:31 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtG2k-0003Ae-4q for ltru@ietf.org; Thu, 14 Jul 2005 22:35:15 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6F253I04800; Fri, 15 Jul 2005 11:05:03 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 8477521a_f4d6_11d9_804c_0030482532aa_14546; Fri, 15 Jul 2005 11:16:56 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO000048; 15 Jul 05 11:10:44 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 15 Jul 05 11:10:33 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG000047; 15 Jul 05 11:10:29 +0900 Message-Id: <6.0.0.20.2.20050715105043.097bcd80@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 15 Jul 2005 11:01:39 +0900 To: "Randy Presuhn" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Compatibility (Was: Last call: Private UseTags) In-Reply-To: <00a501c588a7$425f8780$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050714140510.04536780@mail.afrac.org> <00a501c588a7$425f8780$7f1afea9@oemcomputer> 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: b1c41982e167b872076d0018e4e1dc3c 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 [chair hat off] I agree with the text below, moduo the changes proposed by Mark/ Addison ("based on the ABNF and other provisions of RFC 3066"). It is important to notice that for backwards compatibility, tightening the ABNF can be done based on knowledge of existing, registered, tags (as long as there are no additional restrictions on private use tags, of which we don't know what's around), while loosening of the ABNF and other restrictions would only be possible with a very thorough search of existing applications, of which there are just too many. It is also important to notice that the fact that the backwards compatibility provisions have been in 20 or so drafts is just a sign of how important backwards compatibility is in many engineering contexts. Whatever all the other details of the draft, I doubt that any other charter or any other WG would have done differently (of course, if the charter is to come up with something new and incompatible, then that's a different story). I might also want to point out that the 8-letters-per-subtag restriction isn't a real limitation for somebody e.g. wanting to include punycode. It suffices to add the additional convention that there is a hyphen after every eight letters. As an example, JFC could create a language tag like: x-jfc-punycode-n8jaaaaa-i5bhf7as-8fsfk3jn-knefdde3-fg11amb5-gzdb4wi9-bya3kc6l-ra (the actual data is from a real punycode example at http://www.w3.org/2001/08/iri-test/; it doesn't make sense as a language tag, but I hope it proves the point). Regards, Martin. At 04:07 05/07/15, Randy Presuhn wrote: >Hi - > >Jefsey (see below) writes "I make it a last call issue that such a backward >"compatiblity" when non necessary is not to be introduced". In the context >of this discussion, and of previous discussions on this list, the issue appears >to be one of what is permitted by the ABNF. In particular, I believe the >question >is whether the WG wants the ABNF to permit the generation of tags which would >not have been permitted by the ABNF in RFC 3066. > >The resolution of issues like #945 and #949 indicates that the WG places at least >some value on compatibility, and the comments indicate that there is strong >interest >in ensuring that existing code will be able to syntactically cope with new tags. > >However, just to remove all doubt, I'd like a hum on the following paragraph from >the registry draft's material on "goals": > > *Compatibility.* All RFC 3066 language tags (including those in the > IANA registry) remain valid in this specification. The changes in > this document represent additional constraints on language tags. > That is, in no case is the syntax more permissive and processors > based on the RFC 3066 ABNF (such as those described in [XMLSchema]) > will be able to process the tags described by this document. In > addition, this document defines language tags in such as way as to > ensure future compatibility. > >Please indicate whether you agree or disagree with this goal. A check >with http://tools.ietf.org/wg/ltru/draft-ietf-ltru-registry/ shows that this >material has been around for a while, modulo wordsmithing. > >Randy, ltru co-chair > >> From: "r&d afrac" >> To: "Peter Constable" ; "LTRU Working Group" > >> Sent: Thursday, July 14, 2005 5:28 AM >> Subject: [Ltru] Last call: Private UseTags >> > >> At 01:53 14/07/2005, Peter Constable wrote: >> >The use of Alpha and AlphaNum, which JFC considers a discriminatory >> >limitation, >> >> I think there may be a confusion here in my typing. I consider what is >> discriminatory (and also absurd) the limitation of Alphanums to 8 bytes in >> x-tags. >> >> >is nothing of the sort, and cannot be changed unless >> >backward compatibility is to be abandoned. >> >> I fully support the logic presented by F. Charles that this backward >> compatibility with something which never existed (since future x-tags are >> by nature ... future) is absurd. This is a good documentation of the >> religious opposition of this Draft to future and innovation. >> >> >Since there was consensus >> >from the outset that backward compatibility must be maintained, >> >> Please reference the URL of this consensus. I make it a last call issue >> that such a backward "compatiblity" when non necessary is not to be introduced. >> >> >and >> >since it was clear from the last call back in December that backward >> >compatibility with protocols that consume RFC 3066 is essential, >> >> 1. as someone put it against me: December Last Call is over. >> 2. I was I think one of the most active during that Xmas Call.... >> >> >then I >> >think this is not open to reconsideration, and therefore this proposed >> >text cannot be accepted. >> >> "I think" is not a consensus. "I think myself" is not either. Only "we >> think" makes one. >> I do not know if a text cannot be accepted due to your opinion. But I know >> that no one will think there a consensus against running code.... >> >> >Thus, I think this issue can remain closed. >> >> If you mean the whole Draft, I think it could. But this would not change >> that the current work in many areas need a framework. I do not oppose a >> grasroots one, but I think that an adherence of IETF to that process would >> be of interest. >> 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 Thu Jul 14 23:31:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtGvW-00044K-AZ; Thu, 14 Jul 2005 23:31:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtGvU-0003wt-TB for ltru@megatron.ietf.org; Thu, 14 Jul 2005 23:31:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03761 for ; Thu, 14 Jul 2005 23:31:46 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtHOD-0005WK-SR for ltru@ietf.org; Fri, 15 Jul 2005 00:01:31 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtGvS-0006pd-Ge; Thu, 14 Jul 2005 20:31:46 -0700 Message-Id: <6.2.1.2.2.20050715041950.03ee13d0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Jul 2005 04:29:16 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: Compatibilities In-Reply-To: <001301c588d9$62067bc0$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050714140510.04536780@mail.afrac.org> <00a501c588a7$425f8780$7f1afea9@oemcomputer> <6.2.1.2.2.20050714231220.04555040@mail.afrac.org> <001301c588d9$62067bc0$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 15/07/2005, Randy Presuhn wrote: >Hi Jefsey - >If you disagree with the material on compatibility (which has been in the >i-d in various forms for a *long* time), I know, Addison claimed that. >then it is up to you to propose text. You want me to add text to remove all the added text??? You should know now that the best compatibility I advise is to stay with RFC 3066 and its lose application. What also permits the addition of the Draft. Have a good night! jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 23:31:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtGva-0004Ds-LD; Thu, 14 Jul 2005 23:31:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtGvV-00040x-Mh for ltru@megatron.ietf.org; Thu, 14 Jul 2005 23:31:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03767 for ; Thu, 14 Jul 2005 23:31:47 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtHOE-0005WN-Lv for ltru@ietf.org; Fri, 15 Jul 2005 00:01:31 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtGvT-0006pd-FS for ltru@ietf.org; Thu, 14 Jul 2005 20:31:47 -0700 Message-Id: <6.2.1.2.2.20050715043705.03eee0a0@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Jul 2005 04:42:13 +0200 To: ltru@ietf.org From: r&d afrac Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [Ltru] Last call questions X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Martin and all, As discussed with Randy, I listed under http://rfc3066.org/review.htm some questions to answer before the end of the last call. Basically they are: should their matter be addressed in the Draft or in a dedicated framework (as I think at least for some). The Last Call means that this WG has to give a response. All the best. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 23:31:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtGva-0004EG-QV; Thu, 14 Jul 2005 23:31:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtGvX-00048b-FN for ltru@megatron.ietf.org; Thu, 14 Jul 2005 23:31:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03774 for ; Thu, 14 Jul 2005 23:31:48 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtHOH-0005Wb-6t for ltru@ietf.org; Fri, 15 Jul 2005 00:01:33 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtGvU-0006pd-IB; Thu, 14 Jul 2005 20:31:48 -0700 Message-Id: <6.2.1.2.2.20050715045219.03eee490@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Jul 2005 05:01:57 +0200 To: Martin Duerst From: r&d afrac Subject: Re: [Ltru] Compatibility (Was: Last call: Private UseTags) In-Reply-To: <6.0.0.20.2.20050715105043.097bcd80@itmail.it.aoyama.ac.jp> References: <6.2.1.2.2.20050714140510.04536780@mail.afrac.org> <00a501c588a7$425f8780$7f1afea9@oemcomputer> <6.0.0.20.2.20050715105043.097bcd80@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 04:01 15/07/2005, Martin Duerst said: >I might also want to point out that the 8-letters-per-subtag >restriction isn't a real limitation for somebody e.g. wanting >to include punycode. It suffices to add the additional convention >that there is a hyphen after every eight letters. As an example, >JFC could create a language tag like: >x-jfc-punycode-n8jaaaaa-i5bhf7as-8fsfk3jn-knefdde3-fg11amb5-gzdb4wi9-bya3kc6l-ra >(the actual data is from a real punycode example at >http://www.w3.org/2001/08/iri-test/; it doesn't make sense as a language >tag, but I hope it proves the point). Dear Martin, you see the impact when I quote this during the IESG Last Call, explaining it is to fight existing running code "x-1en:dictionary.com" jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 14 23:57:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtHKO-0001wD-17; Thu, 14 Jul 2005 23:57:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtHKM-0001vD-I5 for ltru@megatron.ietf.org; Thu, 14 Jul 2005 23:57:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05415 for ; Thu, 14 Jul 2005 23:57: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.43) id 1DtHn6-0006FT-GO for ltru@ietf.org; Fri, 15 Jul 2005 00:27: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, 14 Jul 2005 20:57: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] Compatibility (Was: Last call: Private UseTags) Date: Thu, 14 Jul 2005 20:57:08 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D4A7@irvmbxw01.quest.com> Thread-Topic: [Ltru] Compatibility (Was: Last call: Private UseTags) Thread-Index: AcWI7cakoalOPdgEQQOePOAs99d3vAAA16Eg From: "Addison Phillips" To: "r&d afrac" , "Martin Duerst" X-OriginalArrivalTime: 15 Jul 2005 03:57:14.0236 (UTC) FILETIME=[48F3CBC0:01C588F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 A single implementation created by the author of the comment is not = evidence of compatibility or incompatibily. Make a fool of yourself if = you wish... 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 r&d afrac > Sent: 2005?7?14? 20:02 > To: Martin Duerst > Cc: ltru@ietf.org > Subject: Re: [Ltru] Compatibility (Was: Last call: Private UseTags) >=20 > On 04:01 15/07/2005, Martin Duerst said: > >I might also want to point out that the 8-letters-per-subtag > >restriction isn't a real limitation for somebody e.g. wanting > >to include punycode. It suffices to add the additional convention > >that there is a hyphen after every eight letters. As an example, > >JFC could create a language tag like: > >x-jfc-punycode-n8jaaaaa-i5bhf7as-8fsfk3jn-knefdde3-fg11amb5-gzdb4wi9- > bya3kc6l-ra > >(the actual data is from a real punycode example at > >http://www.w3.org/2001/08/iri-test/; it doesn't make sense as a = language > >tag, but I hope it proves the point). >=20 > Dear Martin, > you see the impact when I quote this during the IESG Last Call, = explaining > it is to fight existing running code "x-1en:dictionary.com" > jfc >=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@lists.ietf.org Fri Jul 15 01:16:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtIZ2-0003Wa-Ik; Fri, 15 Jul 2005 01:16:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtIYz-0003VS-Bh for ltru@megatron.ietf.org; Fri, 15 Jul 2005 01:16:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10128 for ; Fri, 15 Jul 2005 01:16: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.43) id 1DtJ1g-0008SQ-UZ for ltru@ietf.org; Fri, 15 Jul 2005 01:46:22 -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 Jul 2005 21:02: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: Compatibilities Date: Thu, 14 Jul 2005 20:58:18 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D4A9@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Compatibilities Thread-Index: AcWI7mM9mdn7ei3BQ7mL1OZLbl35JwAAuxsg From: "Addison Phillips" To: "r&d afrac" , "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 15 Jul 2005 04:02:02.0330 (UTC) FILETIME=[F4AB73A0:01C588F1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 RFC 3066 does not permit what you desire (dots or long subtags) under = any reading you can possibly imagine. 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 r&d afrac > Sent: 2005?7?14? 19:29 > To: Randy Presuhn; LTRU Working Group > Subject: Re: [Ltru] Re: Compatibilities >=20 > At 03:06 15/07/2005, Randy Presuhn wrote: > >Hi Jefsey - > >If you disagree with the material on compatibility (which has been in = the > >i-d in various forms for a *long* time), >=20 > I know, Addison claimed that. >=20 > >then it is up to you to propose text. >=20 > You want me to add text to remove all the added text??? > You should know now that the best compatibility I advise is to stay = with > RFC 3066 and its lose application. > What also permits the addition of the Draft. >=20 > Have a good night! > jfc >=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 Fri Jul 15 01:28:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtIk4-0003j5-Kf; Fri, 15 Jul 2005 01: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 1DtIk3-0003ev-Aj for ltru@megatron.ietf.org; Fri, 15 Jul 2005 01:28:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10820 for ; Fri, 15 Jul 2005 01:28:05 -0400 (EDT) Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtJCm-0000L8-Bh for ltru@ietf.org; Fri, 15 Jul 2005 01:57:49 -0400 Received: from h-68-166-188-250.snvacaid.dynamic.covad.net ([68.166.188.250] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtIjz-0006P1-00 for ltru@ietf.org; Fri, 15 Jul 2005 01:28:04 -0400 Message-ID: <001801c588fe$02b7d540$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.2.1.2.2.20050715043705.03eee0a0@pop.online.fr> Subject: Re: [Ltru] Last call questions Date: Thu, 14 Jul 2005 22:28: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: 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: "r&d afrac" > To: > Sent: Thursday, July 14, 2005 7:42 PM > Subject: [Ltru] Last call questions > > Dear Martin and all, > As discussed with Randy, I listed under http://rfc3066.org/review.htm some > questions to answer before the end of the last call. Basically they are: > should their matter be addressed in the Draft or in a dedicated framework > (as I think at least for some). > > The Last Call means that this WG has to give a response. > All the best. > jfc Beware the deceptive wording in Jefsey's message. The only sense in which I have "discussed" the misleadingly-named http://rfc3066.org/review.htm is that I posted a message to ietf@ietf.org suggesting that reviewers' time would be better spent on the working group documents that are under last call, rather than trying to make sense of the polemic on that website. If anyone wishes to raise an issue, (s)he should do on on the working group mailing list by posting a message detailing the concern and, if possible, supplying proposed replacement text. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 01:51:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtJ6r-00084Q-95; Fri, 15 Jul 2005 01:51:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtJ6o-000818-AH for ltru@megatron.ietf.org; Fri, 15 Jul 2005 01:51:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12436 for ; Fri, 15 Jul 2005 01:51:36 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtJZY-0000vD-D8 for ltru@ietf.org; Fri, 15 Jul 2005 02:21:21 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 22:51:22 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 22:51:23 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Compatibility (Was: Last call: Private UseTags) Date: Thu, 14 Jul 2005 22:51:22 -0700 Message-ID: Thread-Topic: [Ltru] Compatibility (Was: Last call: Private UseTags) Thread-Index: AcWIp/QEuvKoEQyjSEaVncVtliZaCwAWSd3w From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 15 Jul 2005 05:51:23.0101 (UTC) FILETIME=[3B31A8D0:01C58901] 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 > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Randy Presuhn > However, just to remove all doubt, I'd like a hum on the following > paragraph from > the registry draft's material on "goals": >=20 > *Compatibility.* All RFC 3066 language tags (including those in the > IANA registry) remain valid in this specification. The changes in > this document represent additional constraints on language tags. > That is, in no case is the syntax more permissive and processors > based on the RFC 3066 ABNF (such as those described in [XMLSchema]) > will be able to process the tags described by this document. In > addition, this document defines language tags in such as way as to > ensure future compatibility. >=20 > Please indicate whether you agree or disagree with this goal. I agree with this goal. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 02:38:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtJqH-0000dC-1p; Fri, 15 Jul 2005 02:38:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtJqF-0000d4-7x for ltru@megatron.ietf.org; Fri, 15 Jul 2005 02:38:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06188 for ; Fri, 15 Jul 2005 02:38:33 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtKIz-0002AU-G2 for ltru@ietf.org; Fri, 15 Jul 2005 03:08:18 -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 j6F6cSZm014803; Fri, 15 Jul 2005 09:38:29 +0300 (EEST) Message-ID: <42D759E4.7070501@kotus.fi> Date: Fri, 15 Jul 2005 09:38: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: Peter Constable Subject: Re: [Ltru] Compatibility (Was: Last call: Private UseTags) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org So do I. Erkki I. Kolehmainen Peter Constable wrote: >>From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] >> > On > >>Behalf Of Randy Presuhn >> > > >>However, just to remove all doubt, I'd like a hum on the following >>paragraph from >>the registry draft's material on "goals": >> >> *Compatibility.* All RFC 3066 language tags (including those in >> > the > >> IANA registry) remain valid in this specification. The changes in >> this document represent additional constraints on language tags. >> That is, in no case is the syntax more permissive and processors >> based on the RFC 3066 ABNF (such as those described in [XMLSchema]) >> will be able to process the tags described by this document. In >> addition, this document defines language tags in such as way as to >> ensure future compatibility. >> >>Please indicate whether you agree or disagree with this goal. >> > > I agree with this goal. > > > > 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 Fri Jul 15 02:38:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtJqK-0000eE-9x; Fri, 15 Jul 2005 02:38:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtJqI-0000du-Jq for ltru@megatron.ietf.org; Fri, 15 Jul 2005 02:38: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 CAA06192 for ; Fri, 15 Jul 2005 02:38:36 -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 <20050715063806.AUR14360.mta13.adelphia.net@DEWELL> for ; Fri, 15 Jul 2005 02:38:06 -0400 Message-ID: <003301c58907$bc9e6240$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050713115344.JWYO13539.edge6.adelphia.net@megatron.ietf.org> Date: Thu, 14 Jul 2005 23:37: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 Cc: Subject: [Ltru] Re: Jersey JE and Guernsey GG Country Codes AND IM Isle of Man X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Debbie Garside wrote: > Having spoken to Joseph Martinez at the ISO 3166 MA, I am reliably > informed that the process will most probably take 2 months to complete > (normally 1 month but delayed due to summer holidays). I am also > reliably informed that, on the face of it, given that there are UN > codes and on receipt of a request made via BSI and supported by UK > government (which should be in place by Friday), there should be no > problem with the request. I for one am glad to hear this, as it will put an end once and for all to the question of how to code these locations. -- 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 Fri Jul 15 02:55:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtK6k-00009O-Ke; Fri, 15 Jul 2005 02:55:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtK6j-000092-MO for ltru@megatron.ietf.org; Fri, 15 Jul 2005 02:55:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07791 for ; Fri, 15 Jul 2005 02:55:34 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtKZQ-0002ne-7W for ltru@ietf.org; Fri, 15 Jul 2005 03:25:20 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6F6tFC06300; Fri, 15 Jul 2005 15:55:15 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 0ec9cf38_f4ff_11d9_823d_0030482532aa_14538; Fri, 15 Jul 2005 16:07:08 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0000E5; 15 Jul 05 16:00:56 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 15 Jul 05 16:00:39 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.209.115) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0000E4; 15 Jul 05 16:00:29 +0900 Message-Id: <6.0.0.20.2.20050715145600.0941b8c0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 15 Jul 2005 15:13:53 +0900 To: "Randy Presuhn" , From: Martin Duerst Subject: Re: [Ltru] Last call questions In-Reply-To: <001801c588fe$02b7d540$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050715043705.03eee0a0@pop.online.fr> <001801c588fe$02b7d540$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 [chair hat on] [just putting what Randy said in other words] As part of Last Call, I understand that the WG has to look at every comment labeled as a last call comment on the WG mailing list. 'Look at' may range from very quick rejection, e.g. because it's out of scope of the charter or because it has been considered at lenght by the WG and the commenter doesn't bring up any new points, or it may range over several hundred emails if necessary. The WG is under no obligation to respond to stuff on an arbitrary web site. If somebody wants that stuff to be considered, they can send it in to the WG (hopefully as actual last call comments with specific text proposed, rather than as questions). Regards, Martin. At 14:28 05/07/15, Randy Presuhn wrote: >Hi - > >> From: "r&d afrac" >> To: >> Sent: Thursday, July 14, 2005 7:42 PM >> Subject: [Ltru] Last call questions >> >> Dear Martin and all, >> As discussed with Randy, I listed under http://rfc3066.org/review.htm some >> questions to answer before the end of the last call. Basically they are: >> should their matter be addressed in the Draft or in a dedicated framework >> (as I think at least for some). >> >> The Last Call means that this WG has to give a response. >> All the best. >> jfc > >Beware the deceptive wording in Jefsey's message. The only sense in which >I have "discussed" the misleadingly-named http://rfc3066.org/review.htm is >that I posted a message to ietf@ietf.org suggesting that reviewers' time would >be better spent on the working group documents that are under last call, >rather than trying to make sense of the polemic on that website. > >If anyone wishes to raise an issue, (s)he should do on on the working group >mailing list by posting a message detailing the concern and, if possible, >supplying proposed replacement text. > >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 Fri Jul 15 03:01:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKCH-0005xK-9F; Fri, 15 Jul 2005 03:01:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKCF-0005wg-4x for ltru@megatron.ietf.org; Fri, 15 Jul 2005 03:01:19 -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 DAA08190 for ; Fri, 15 Jul 2005 03:01: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 <20050715070044.VRZ29002.mta9.adelphia.net@DEWELL> for ; Fri, 15 Jul 2005 03:00:44 -0400 Message-ID: <008e01c5890a$d0dab6c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050714000016.PIIX21353.mta3.adelphia.net@megatron.ietf.org> Date: Thu, 14 Jul 2005 23:59: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 Cc: Subject: [Ltru] Clarifications (was: Re: [psg.com #1061] eliminate (or proscribe) Private Use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I just want to clarify a few items. These are not intended as Last Call action items, nor as the start of a big long discussion. 1. The letter "x" The letter "x" to indicate a private-use tag (or subtag) goes all the way back to RFC 1766. Then, as now, it is simply a letter; it does not "stand for" anything. Perhaps there is a hint of the concept of "extended" or "expanded," but that is all. (Programmers are accustomed to the use of "x" or "ex" to mean an extended version of something that existed before.) There is no hidden or dark inner meaning to this choice of letters. 2. Consenting adults I made a reference to "consenting adults" being able to use private-use tags "in the privacy of their homes." This is an unfortunate use of en-US in a global e-mail context. The phrase comes from American legal history, where laws about "what consenting adults could do in the privacy of their homes" were passed and debated and upheld and overturned. My intent was NOT to claim that private-use tags were for use by adults only, or for adult-oriented material. It was only meant to say that private-use tags should be available for use within the confines of a private agreement. I regret any confusion this metaphor may have caused. -- 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 Fri Jul 15 03:12:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKNF-00049E-Gr; Fri, 15 Jul 2005 03:12:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKNE-000488-8o for ltru@megatron.ietf.org; Fri, 15 Jul 2005 03:12: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 DAA08984 for ; Fri, 15 Jul 2005 03:12:38 -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 <20050715071209.WBQF24042.mta11.adelphia.net@DEWELL> for ; Fri, 15 Jul 2005 03:12:09 -0400 Message-ID: <009301c5890c$7b906280$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050714000016.PIIX21353.mta3.adelphia.net@megatron.ietf.org> Date: Fri, 15 Jul 2005 00: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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: "x" doesn't "mean" anything X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > Can I get a hum on whether to add the proposed text? > >> "The use of "x-" has no particular meaning regarding the nature of >> the private subtags." I have no objection to a sentence that states that the choice of the letter "x" is not significant. >> "The use of "x-" is to introduce the private extension of the format. >> It may in particular be used for multilingual or punycoded subtags." Punycode is used only for internationalized domain names. We are dealing with language tags, which are not part of IDNs. Therefore, there is no relationship and no conflict. This is also why comparisons between "xn--" (which introduces a Punycoded IDN) and "x-" (which introduces a private-use tag or subtag) are spurious; they have nothing to do with each other. >> The Alpha8 is discreminatory against internationalised subtags, as >> punycode can imply punycoded string of different length for >> internationalised strings of similar length. Language tags are defined as being made up of characters within the ASCII repertoire. They cannot be made up of Greek or Cyrillic or Tagbanwa characters. Punycode is not involved. -- 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 Fri Jul 15 03:20:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKUp-0008TJ-Pl; Fri, 15 Jul 2005 03:20:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKUm-0008TE-OU for ltru@megatron.ietf.org; Fri, 15 Jul 2005 03:20:30 -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 DAA09635 for ; Fri, 15 Jul 2005 03:20: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 <20050715071957.WEHK24042.mta11.adelphia.net@DEWELL> for ; Fri, 15 Jul 2005 03:19:57 -0400 Message-ID: <00a401c5890d$92e3a5e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050714213301.LHUB27741.edge3.adelphia.net@megatron.ietf.org> Date: Fri, 15 Jul 2005 00:19: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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Last Call Comment: draft-ietf-ltru-initial-02.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 Randy Presuhn wrote: > Here are some suggested replacement words: > The following code elements from [UN-M.49] were not associated > with [ISO3166-1] alpha-2 code elements. Consequently, they were > not assigned as > subtags in the initial Language Subtag Registry, but are valid > candidates for registration as region subtags, using the process in > [I-D.ietf-ltru-registry]: I support Randy's proposed wording as a response to Scott's concern. -- 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 Fri Jul 15 03:24:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKZ5-0001BR-1W; Fri, 15 Jul 2005 03: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 1DtKZ4-0001BM-Fy for ltru@megatron.ietf.org; Fri, 15 Jul 2005 03:24: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 DAA09886 for ; Fri, 15 Jul 2005 03:24:52 -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 <20050715072423.BCSG29002.mta9.adelphia.net@DEWELL> for ; Fri, 15 Jul 2005 03:24:23 -0400 Message-ID: <00a901c5890e$3302dbe0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050714213301.LHUB27741.edge3.adelphia.net@megatron.ietf.org> Date: Fri, 15 Jul 2005 00:24: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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Compatibility (Was: Last call: Private UseTags) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > Jefsey (see below) writes "I make it a last call issue that such a > backward "compatiblity" when non necessary is not to be introduced". > In the context of this discussion, and of previous discussions on this > list, the issue appears to be one of what is permitted by the ABNF. > In particular, I believe the question is whether the WG wants the ABNF > to permit the generation of tags which would not have been permitted > by the ABNF in RFC 3066. RFC 1766 said: The syntax of this tag in RFC-822 EBNF is: Language-Tag = Primary-tag *( "-" Subtag ) Primary-tag = 1*8ALPHA Subtag = 1*8ALPHA RFC 3066 said: The syntax of this tag in ABNF [RFC 2234] is: Language-Tag = Primary-subtag *( "-" Subtag ) Primary-subtag = 1*8ALPHA Subtag = 1*8(ALPHA / DIGIT) I support keeping this promise to users (and parser builders) that subtags within language tags shall be no longer than 8 alphanumeric characters, and shall be separated by dashes. -- 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 Fri Jul 15 03:42:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtKqC-00045D-Le; Fri, 15 Jul 2005 03: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 1DtKqA-000458-Q3 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 03:42:35 -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 DAA10838 for ; Fri, 15 Jul 2005 03:42:32 -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 <20050715074202.UJF14360.mta13.adelphia.net@DEWELL>; Fri, 15 Jul 2005 03:42:02 -0400 Message-ID: <00c101c58910$a9f03160$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Fri, 15 Jul 2005 00:41: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: statistics@un.org Subject: [Ltru] UN region code list change X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 regret to announce that the United Nations Statistics Division has made another "unannounced" change to their M.49 code list. Fortunately, the change appears to be minimal, and deals with a name only: Timor-Leste --> Democratic Republic of Timor-Leste The only indication that this change occurred is the notation "revised 14 July 2005" on the page dealing with macro-geographical regions. There is no date notation at all on the alphabetic list of countries. The only way I found out about this change was through the free WatchThatPage service. The page http://unstats.un.org/unsd/methods/m49/m49chang.htm, which is supposed to list "Name changes with no change in code," does not include an entry for this change. UNSD has also fixed their previous error in the use of a macro code for "Southern Asia," again with no formal notice. I would like to request that UNSD indicate all changes to their code list on the "added or changed" page referenced above, regardless of the nature, size, or scope of the change, and add a "revised" date to all pages dealing with the M.49 standard. -- 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 Fri Jul 15 04:54:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtLxS-0002cv-Et; Fri, 15 Jul 2005 04:54:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtLxQ-0002Vi-RJ for ltru@megatron.ietf.org; Fri, 15 Jul 2005 04:54:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15828 for ; Fri, 15 Jul 2005 04:54:06 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtMQ5-0007OC-Hx for ltru@ietf.org; Fri, 15 Jul 2005 05:23:53 -0400 Received: from smtp-los02.proxy.aol.com (smtp-los02.proxy.aol.com [195.93.24.100]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN2-342d779952d5; Fri, 15 Jul 2005 04:53:41 -0500 Received: from DEBHOME (ACCBADFA.ipt.aol.com [172.203.173.250]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j6F8rbq8012826; Fri, 15 Jul 2005 04:53:37 -0400 Message-Id: <200507150853.j6F8rbq8012826@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Doug Ewell'" , "'LTRU Working Group'" Subject: RE: [Ltru] Re: Jersey JE and Guernsey GG Country Codes AND IM Isle ofMan Date: Fri, 15 Jul 2005 09:53: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: AcWJCCoolYSqPnbZSRayozvOmE/nYAAEk7Ug In-Reply-To: <003301c58907$bc9e6240$030aa8c0@DEWELL> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 FYI Extract of 21 page document prepared for ISO 3166 MA: Formal Request The governments of the Islands, with the unreserved support of the United Kingdom government, request that the ISO 3166 Maintenance Agency re-examine the political and economic status of the Islands with a view to authorising separate Alpha code elements for Guernsey, Jersey and the Isle of Man, using the existing code reservations made by that agency, namely: Guernsey GG GGY Jersey JE JEY Isle of Man IM IMN Regards Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Doug Ewell > Sent: 15 July 2005 07:38 > To: LTRU Working Group > Subject: [Ltru] Re: Jersey JE and Guernsey GG Country Codes AND IM Isle > ofMan > > Debbie Garside wrote: > > > Having spoken to Joseph Martinez at the ISO 3166 MA, I am reliably > > informed that the process will most probably take 2 months to complete > > (normally 1 month but delayed due to summer holidays). I am also > > reliably informed that, on the face of it, given that there are UN > > codes and on receipt of a request made via BSI and supported by UK > > government (which should be in place by Friday), there should be no > > problem with the request. > > I for one am glad to hear this, as it will put an end once and for all > to the question of how to code these locations. > > -- > 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 Fri Jul 15 06: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 1DtNEQ-0008EK-Ax; Fri, 15 Jul 2005 06: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 1DtNEM-0008EE-4L for ltru@megatron.ietf.org; Fri, 15 Jul 2005 06:15: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 GAA21092 for ; Fri, 15 Jul 2005 06:15:38 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DtNDq-0002CE-0z for ltru@lists.ietf.org; Fri, 15 Jul 2005 12:15:10 +0200 Received: from c-134-90-163.hh.dial.de.ignite.net ([62.134.90.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2005 12:15:10 +0200 Received: from nobody by c-134-90-163.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2005 12:15:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 15 Jul 2005 12:12:37 +0200 Organization: Lines: 10 Message-ID: <42D78C15.7693@xyzzy.claranet.de> References: <6.2.1.2.2.20050714140510.04536780@mail.afrac.org> <00a501c588a7$425f8780$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-90-163.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Compatibility X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > However, just to remove all doubt, I'd like a hum Sure, all attempts to introduce a "sub-delimiter" in addition to hyphen failed miserably, because they were _not_ backwards compatible. Dito ideas to use colon etc. in private subtags. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 06:33:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNVc-0002Er-OP; Fri, 15 Jul 2005 06:33:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNVZ-0002Ej-L8 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 06:33: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 GAA22343 for ; Fri, 15 Jul 2005 06:33:26 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DtNVY-0004dj-0I for ltru@lists.ietf.org; Fri, 15 Jul 2005 12:33:28 +0200 Received: from c-134-90-163.hh.dial.de.ignite.net ([62.134.90.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2005 12:33:27 +0200 Received: from nobody by c-134-90-163.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2005 12:33:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 15 Jul 2005 12:32:09 +0200 Organization: Lines: 16 Message-ID: <42D790A9.4B13@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> <42D61D13.8DC5A6A2@egt.ie> <6.2.1.2.2.20050714143508.044df1c0@mail.afrac.org> <42D66B9B.B8EF102@egt.ie> <6.2.1.2.2.20050714181103.0400bb30@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-90-163.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: last call: language tag usage X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 r&d afrac wrote: [Marion Gunn wrote:] >> 'The language tag is used to help identify which language is >> being spoken, written, signed or otherwise signalled for the >> purpose of communication.' > +1 Okay, let's take the added "help". After Addison mentioned Wittgenstein I checked some quotes of Whorf, and the "help" aspect is important (e.g. "en" as written by lawyers is unrelated to "en" as spoken on any -001 or Klingon street). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 06:42:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNeI-0006hB-26; Fri, 15 Jul 2005 06:42:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNeF-0006gu-2y for ltru@megatron.ietf.org; Fri, 15 Jul 2005 06:42:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23297 for ; Fri, 15 Jul 2005 06:42:23 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtO70-00032H-PX for ltru@ietf.org; Fri, 15 Jul 2005 07:12:13 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtNe7-0008LK-0o; Fri, 15 Jul 2005 03:42:19 -0700 Message-Id: <6.2.1.2.2.20050715113535.04e64b50@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Jul 2005 12:06:35 +0200 To: "Debbie Garside" From: r&d afrac Subject: RE: [Ltru] Re: Jersey JE and Guernsey GG Country Codes AND IM Isle ofMan In-Reply-To: <200507150853.j6F8rbq8012826@smtp-los02.proxy.aol.com> References: <003301c58907$bc9e6240$030aa8c0@DEWELL> <200507150853.j6F8rbq8012826@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 - afrac.org X-Spam-Score: 1.1 (+) 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org On 10:53 15/07/2005, Debbie Garside said: >FYI >Extract of 21 page document prepared for ISO 3166 MA: >Formal Request > >The governments of the Islands, with the unreserved support of the United >Kingdom government, request that the ISO 3166 Maintenance Agency re-examine >the political and economic status of the Islands with a view to authorising >separate Alpha code elements for Guernsey, Jersey and the Isle of Man, using >the existing code reservations made by that agency, namely: > > Guernsey GG GGY > Jersey JE JEY > Isle of Man IM IMN > >Regards Dear Debbie, This is interesting, but this is a political issue. The result could interest the rfc3066@iana.org mailing list the day it is created. The purpose of this WG is to propose a general solution which does not make acception of such particular cases and of their evolution. I am certainly glad to see that GG, JE and IM are going to get an official code due to our Member Tony. If this WG wants to continue to involve itself in this kind of issues, the situation of the Sark language in the Balliwick of Gernsey is not clear to me, nor the Tamil issue. The role of an IETF WG is not to be a substitute for an ISO or a UN committee, not even to influence them. To the countrary it should take care of staying immune from such matters. I know, some oppose the acknowledgment of ISO's ultimate authoritativeness on ISO matters and the use of a political disclaimer for technical positions with a deep political impact. The result from such a lack of clear area separation and confusion can be seen when consensus (another one) is for the Internet to be submitted to an UN organisation on the premises of the politicians understanding of the internet technology. It is interesting to note - to the countrary - that in this caconoology the only stable entity RFC, IETF, IANA, ICANN, WGIG, USG acknowledge as their proper interlocutor to work with for the stability of the network, is the ccTLD. I am not sure this would be the case if John Postel had not defined them the way he did and if he had accepted they could be an alternative to the M.49 area codes, as the IANA (now the questionned ICANN) could want to use them. This is that type of confusion, a Babel repetition, I wish we spare the world. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 06:50:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNmS-0003im-W4; Fri, 15 Jul 2005 06:50:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNmQ-0003ih-QP for ltru@megatron.ietf.org; Fri, 15 Jul 2005 06:50: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 GAA23889 for ; Fri, 15 Jul 2005 06:50:50 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DtNm2-0008BY-4e for ltru@lists.ietf.org; Fri, 15 Jul 2005 12:50:30 +0200 Received: from c-134-90-163.hh.dial.de.ignite.net ([62.134.90.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2005 12:50:30 +0200 Received: from nobody by c-134-90-163.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2005 12:50:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 15 Jul 2005 12:49:25 +0200 Organization: Lines: 8 Message-ID: <42D794B5.2228@xyzzy.claranet.de> References: <00c101c58910$a9f03160$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-90-163.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: UN region code list change X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > Timor-Leste --> Democratic Republic of Timor-Leste The UN name for 626 doesn't affect us, we use ISO 3166-1 TL. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 06:54:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNpY-0004Zn-QY; Fri, 15 Jul 2005 06:54:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNpY-0004Zi-0j for ltru@megatron.ietf.org; Fri, 15 Jul 2005 06:54:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24098 for ; Fri, 15 Jul 2005 06:54:04 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtOIL-0003W4-TZ for ltru@ietf.org; Fri, 15 Jul 2005 07:23:54 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtNpW-00037P-3p for ltru@ietf.org; Fri, 15 Jul 2005 03:54:07 -0700 Message-Id: <6.2.1.2.2.20050715124802.041ef740@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 15 Jul 2005 12:53:57 +0200 To: ltru@ietf.org From: r&d afrac Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] Last call: IANA adaptation of the UN disclaimer X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 suggest that we copy the UN disclaimer and tell the IANA to use the following wording in its display and documents: "The designations employed and the presentation of country or area names, languages and scipts in this registy do not imply the expression of any opinion whatsoever on the part of the IETF, ICANN and IANA concerning the legal status of any country, territory, city or area or of its authorities, or concerning the delimitation of its frontiers or boundaries, or concerning any cultural, political, economical, educational sovereign issue. The user of any particular subtag should consult the corresponding ISO or UN dataset documentation to determine the exact coverage of statistics for the country or area entities, of the language or of the script in the dataset. Various datasets may or may not include coverage of outlying and overseas areas nor a comprehensive approach of the involved cultural issues, depending on the type of data and source." Unless we also know better than UN. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 07:11:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtO61-0006T8-Bg; Fri, 15 Jul 2005 07: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 1DtO5z-0006LP-2B for ltru@megatron.ietf.org; Fri, 15 Jul 2005 07:11:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24901 for ; Fri, 15 Jul 2005 07:11:03 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtOYl-000403-RF for ltru@ietf.org; Fri, 15 Jul 2005 07:40:53 -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 j6FBB3Zm022692; Fri, 15 Jul 2005 14:11:03 +0300 (EEST) Message-ID: <42D799C8.7030007@kotus.fi> Date: Fri, 15 Jul 2005 14:11:04 +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: Frank Ellermann Subject: Re: [Ltru] Re: last call: language tag usage References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> <42D61D13.8DC5A6A2@egt.ie> <6.2.1.2.2.20050714143508.044df1c0@mail.afrac.org> <42D66B9B.B8EF102@egt.ie> <6.2.1.2.2.20050714181103.0400bb30@mail.afrac.org> <42D790A9.4B13@xyzzy.claranet.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Fine by me! Erkki I. Kolehmainen Frank Ellermann wrote: > r&d afrac wrote: > > [Marion Gunn wrote:] > >>>'The language tag is used to help identify which language is >>>being spoken, written, signed or otherwise signalled for the >>>purpose of communication.' >>> > > >>+1 >> > > Okay, let's take the added "help". After Addison mentioned > Wittgenstein I checked some quotes of Whorf, and the "help" > aspect is important (e.g. "en" as written by lawyers is > unrelated to "en" as spoken on any -001 or Klingon street). > > 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 Fri Jul 15 07:21:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtOFY-00024P-IZ; Fri, 15 Jul 2005 07:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtOFX-00024K-Eo for ltru@megatron.ietf.org; Fri, 15 Jul 2005 07:21: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 HAA25767 for ; Fri, 15 Jul 2005 07:20:55 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DtOF5-0006K0-F0 for ltru@lists.ietf.org; Fri, 15 Jul 2005 13:20:31 +0200 Received: from c-134-90-163.hh.dial.de.ignite.net ([62.134.90.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2005 13:20:31 +0200 Received: from nobody by c-134-90-163.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2005 13:20:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 15 Jul 2005 13:13:06 +0200 Organization: Lines: 36 Message-ID: <42D79A42.6795@xyzzy.claranet.de> References: <003301c58907$bc9e6240$030aa8c0@DEWELL> <200507150853.j6F8rbq8012826@smtp-los02.proxy.aol.com> <6.2.1.2.2.20050715113535.04e64b50@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-90-163.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Jersey JE and Guernsey GG Country Codes AND IM Isle ofMan X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 r&d afrac wrote: > The result could interest the rfc3066@iana.org mailing list > the day it is created. Why should it, GG, IM, and JE are already known, test it with `whois -h whois.iana.org GG` etc. > If this WG wants to continue to involve itself in this kind > of issues, the situation of the Sark language in the > Balliwick of Gernsey is not clear to me IIRC Sarquois, 8 letters, you can register it if you need it: It's the job of the language list to figure out an appropriate Recommended-Prefix if "fr-" is not good enough. > It is interesting to note - to the countrary - that in this > caconoology the only stable entity RFC, IETF, IANA, ICANN, > WGIG, USG acknowledge as their proper interlocutor to work > with for the stability of the network, is the ccTLD. What's a "caconoology" ? It has no Google hits, my dictionary http://www.leo.org/dict/bookmarklet_en.html also doesn't know "caconoology". > I am not sure this would be the case if John Postel had not > defined them the way he did and if he had accepted they could > be an alternative to the M.49 area codes Ground control to major Jefsey: This is 3066bis, not 1591bis. Bye, Frank -- version 1.8.2 available _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 08:35:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtPPg-0007WP-DV; Fri, 15 Jul 2005 08:35:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtPPe-0007WK-Ov for ltru@megatron.ietf.org; Fri, 15 Jul 2005 08:35:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01168 for ; Fri, 15 Jul 2005 08:35:28 -0400 (EDT) Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtPsQ-00070S-8D for ltru@ietf.org; Fri, 15 Jul 2005 09:05:17 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 5E886445F for ; Fri, 15 Jul 2005 21:35:04 +0900 (JST) Received: from toro.w3.mag.keio.ac.jp ([127.0.0.1]) by localhost (toro [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25061-15 for ; Fri, 15 Jul 2005 21:35:04 +0900 (JST) Received: from ibm-60d333fc0ec (p1182-ipad414marunouchi.tokyo.ocn.ne.jp [60.39.112.182]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 20CF04059 for ; Fri, 15 Jul 2005 21:35:04 +0900 (JST) To: "ltru@ietf.org" Subject: Re: [Ltru] Re: last call: language tag usage References: <634978A7DF025A40BFEF33EB191E13BC0C20D0A8@irvmbxw01.quest.com> <42D61D13.8DC5A6A2@egt.ie> <6.2.1.2.2.20050714143508.044df1c0@mail.afrac.org> <42D66B9B.B8EF102@egt.ie> <6.2.1.2.2.20050714181103.0400bb30@mail.afrac.org> <42D790A9.4B13@xyzzy.claranet.de> <42D799C8.7030007@kotus.fi> Message-ID: From: "Felix Sasaki" Organization: W3C Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Date: Fri, 15 Jul 2005 21:34:55 +0900 In-Reply-To: <42D799C8.7030007@kotus.fi> User-Agent: Opera M2/8.0 (Win32, build 7561) X-Virus-Scanned: by amavisd-new-20030616-p10 at w3.mag.keio.ac.jp Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 +1 -- Felix On Fri, 15 Jul 2005 20:11:04 +0900, Erkki Kolehmainen =20 wrote: > Fine by me! > > Erkki I. Kolehmainen > > Frank Ellermann wrote: > >> r&d afrac wrote: >> [Marion Gunn wrote:] >> >>>> 'The language tag is used to help identify which language is >>>> being spoken, written, signed or otherwise signalled for the >>>> purpose of communication.' >>>> >> >>> +1 >>> >> Okay, let's take the added "help". After Addison mentioned >> Wittgenstein I checked some quotes of Whorf, and the "help" >> aspect is important (e.g. "en" as written by lawyers is >> unrelated to "en" as spoken on any -001 or Klingon street). >> 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 From ltru-bounces@lists.ietf.org Fri Jul 15 09:57:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQh6-0003wI-8G; Fri, 15 Jul 2005 09:57:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQh5-0003wA-Dl for ltru@megatron.ietf.org; Fri, 15 Jul 2005 09:57:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06805 for ; Fri, 15 Jul 2005 09:57:33 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtR9r-0001L2-ST for ltru@ietf.org; Fri, 15 Jul 2005 10:27:23 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Fri, 15 Jul 2005 09:57:12 -0400 id 005A8174.42D7C0B8.0000752C From: "Scott Hollenbeck" To: ltru@ietf.org Date: Fri, 15 Jul 2005 09:57:14 -0400 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.2800.1165 Thread-Index: AcWJRRqUtYeF7FvZRdm7/O+/DJcQiQ== Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Last Call Comments: draft-ietf-ltru-registry-09 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 draft-ietf-ltru-registry-09 looks really good. It's precise and complete as far as I can tell. I did find a few small issues, though: Section 1, second-to-last paragraph: Please add citations for RFCs 3066 and 1766. - This document replaces RFC 3066, which replaced RFC 1766. + This document replaces RFC 3066 [RFC3066], which replaced RFC 1766 [RFC1766]. Section 2.1, first paragraph: Please cite the ABNF specification in "ABNF %x2D". - ABNF %x2D + ABNF [RFC2234bis] %x2D Section 2.1, bottom of page 5: Please cite a specification for US-ASCII since the text says "Note that although [RFC2234bis] refers to octets, the language tags described in this document are sequences of characters from the US-ASCII repertoire". Section 2.1, top of page 6: - capitalization of some of the subtags, but these MUST not be taken to + capitalization of some of the subtags, but these MUST NOT be taken to Page 22, 5th paragraph: "MAY NOT" is not an RFC 2119 imperative. A change to "do not" might be appropriate. Section 3.6: What type of RFC is required? Informational or Standards Track? Community-reviewed, or RFC-Editor published? Does it matter? It might be helpful to cite one of the methods described in section 2 of RFC 2434 if one is appropriate. Later text in the section says "although the IESG MAY change the assignment when approving the RFC", so I have to believe that we're talking about either an "IETF Consensus" or "Standards Action" document. -Scott- _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 10:03:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQmk-0000jr-GA; Fri, 15 Jul 2005 10:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQmj-0000jm-U0 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 10:03:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07305 for ; Fri, 15 Jul 2005 10:03:23 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtRFW-0001Y2-76 for ltru@ietf.org; Fri, 15 Jul 2005 10:33:13 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 07:03: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); Fri, 15 Jul 2005 07:03:11 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer Date: Fri, 15 Jul 2005 07:03:12 -0700 Message-ID: Thread-Topic: [Ltru] Last call: IANA adaptation of the UN disclaimer Thread-Index: AcWJK9E2tAkph2XXQ7SKgIw5FKC1kwAGKhGw From: "Peter Constable" To: X-OriginalArrivalTime: 15 Jul 2005 14:03:11.0961 (UTC) FILETIME=[EFD85C90:01C58945] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 r&d afrac > I suggest that we copy the UN disclaimer and tell the IANA to use the > following wording in its display and documents: The second half of this paragraph, which refers to statistics and datasets, is out of context and not applicable. I have no objection to a revision of the first half appearing in the registry: =20 "The designations employed and the presentation of names of countries or regions, languages or scripts in this registy do not imply the expression of any opinion whatsoever on the part of the IETF, ICANN and IANA concerning the legal status of any country, territory, region or of its authorities, or concerning the delimitation of frontiers or boundaries, or concerning any cultural, political, economical, educational sovereign issue within any country or region including any issues pertaining to the identity or usage of any language or script within any country or region." Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 10:26:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtR8h-0005gJ-RT; Fri, 15 Jul 2005 10: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 1DtR8f-0005ev-QF for ltru@megatron.ietf.org; Fri, 15 Jul 2005 10:26:05 -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 KAA09867 for ; Fri, 15 Jul 2005 10:26:02 -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 <20050715142533.KZQB14360.mta13.adelphia.net@DEWELL> for ; Fri, 15 Jul 2005 10:25:33 -0400 Message-ID: <00dd01c58949$0148e6e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050715111135.POSD27741.edge3.adelphia.net@megatron.ietf.org> Date: Fri, 15 Jul 2005 07:25:08 -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: UN region code list change X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > Doug Ewell wrote: > >> Timor-Leste --> Democratic Republic of Timor-Leste > > The UN name for 626 doesn't affect us, we use ISO 3166-1 TL. I'm not saying it does. My concern is not with this particular change, but with the practice of making "silent" changes with no announcement, not maintaining an accurate change-notice page, and not displaying the date of revision on all code list pages. -- 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 Fri Jul 15 11:06:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtRmA-0004HS-KF; Fri, 15 Jul 2005 11:06:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtRm7-00044R-5e for ltru@megatron.ietf.org; Fri, 15 Jul 2005 11:06:53 -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 LAA16512 for ; Fri, 15 Jul 2005 11:06:47 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DtRll-0002Cj-Dm for ltru@lists.ietf.org; Fri, 15 Jul 2005 17:06:29 +0200 Received: from du-001-062.access.de.clara.net ([212.82.227.62]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2005 17:06:29 +0200 Received: from nobody by du-001-062.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2005 17:06:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 15 Jul 2005 17:05:48 +0200 Organization: Lines: 8 Message-ID: <42D7D0CC.DD9@xyzzy.claranet.de> References: <20050715111135.POSD27741.edge3.adelphia.net@megatron.ietf.org> <00dd01c58949$0148e6e0$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-062.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: UN region code list change X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > My concern is not with this particular change, but with the > practice of making "silent" changes with no announcement, Yes, that's a PITA. I guess if the tag reviewer misses any future modifications somebody will try to register them. Bye _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 11:21:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtS0j-0002u8-Ns; Fri, 15 Jul 2005 11:21:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtS0h-0002ty-Qt for ltru@megatron.ietf.org; Fri, 15 Jul 2005 11:21:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17911 for ; Fri, 15 Jul 2005 11:21:53 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtSTX-0005cs-0m for ltru@ietf.org; Fri, 15 Jul 2005 11:51: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 j6FFLe6v019844; Fri, 15 Jul 2005 11:21:41 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 15 Jul 2005 11:21:40 -0400 Date: Fri, 15 Jul 2005 11:21:40 -0400 From: "John.Cowan" To: Frank Ellermann Subject: Re: [Ltru] Re: UN region code list change Message-ID: <20050715152140.GI5992@NYCMJCOWA2> References: <20050715111135.POSD27741.edge3.adelphia.net@megatron.ietf.org> <00dd01c58949$0148e6e0$030aa8c0@DEWELL> <42D7D0CC.DD9@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42D7D0CC.DD9@xyzzy.claranet.de> User-Agent: Mutt/1.4.2.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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Frank Ellermann scripsit: > Doug Ewell wrote: > > > My concern is not with this particular change, but with the > > practice of making "silent" changes with no announcement, > > Yes, that's a PITA. I guess if the tag reviewer misses any > future modifications somebody will try to register them. Bye Most of the time it won't matter, since going forward M.49 codes will rarely be inserted into the registry. -- John Cowan jcowan@reutershealth.com www.reutershealth.com www.ccil.org/~cowan Assent may be registered by a signature, a handshake, or a click of a computer mouse transmitted across the invisible ether of the Internet. Formality is not a requisite; any sign, symbol or action, or even willful inaction, as long as it is unequivocally referable to the promise, may create a contract. --Specht v. Netscape _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 12:07:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtSj7-0004DD-3g; Fri, 15 Jul 2005 12:07:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtSj6-0004D8-5E for ltru@megatron.ietf.org; Fri, 15 Jul 2005 12:07:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21562 for ; Fri, 15 Jul 2005 12:07: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.43) id 1DtTBv-0007T4-Ct for ltru@ietf.org; Fri, 15 Jul 2005 12:37:36 -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 Jul 2005 09:07: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] Last call: IANA adaptation of the UN disclaimer Date: Fri, 15 Jul 2005 09:07:31 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D5E6@irvmbxw01.quest.com> Thread-Topic: [Ltru] Last call: IANA adaptation of the UN disclaimer Thread-Index: AcWJK9E2tAkph2XXQ7SKgIw5FKC1kwAGKhGwAASwUYA= From: "Addison Phillips" To: "Peter Constable" , X-OriginalArrivalTime: 15 Jul 2005 16:07:32.0853 (UTC) FILETIME=[4EE22250:01C58957] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 In draft-registry or draft-initial? If in draft-registry, *where*? 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: 2005?7?15? 7:03 > To: ltru@ietf.org > Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer >=20 > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of r&d afrac >=20 >=20 > > I suggest that we copy the UN disclaimer and tell the IANA to use = the > > following wording in its display and documents: >=20 > The second half of this paragraph, which refers to statistics and > datasets, is out of context and not applicable. I have no objection to = a > revision of the first half appearing in the registry: >=20 > "The designations employed and the presentation of names of countries = or > regions, languages or scripts in this registy do not imply the > expression of any opinion whatsoever on the part of the IETF, ICANN = and > IANA concerning the legal status of any country, territory, region or = of > its authorities, or concerning the delimitation of frontiers or > boundaries, or concerning any cultural, political, economical, > educational sovereign issue within any country or region including any > issues pertaining to the identity or usage of any language or script > within any country or region." >=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 Fri Jul 15 12:07:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtSjG-0004Ej-CH; Fri, 15 Jul 2005 12:07:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtSjE-0004Ds-IL for ltru@megatron.ietf.org; Fri, 15 Jul 2005 12:07: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 MAA21568 for ; Fri, 15 Jul 2005 12:07:52 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DtSin-0003mG-Hm for ltru@lists.ietf.org; Fri, 15 Jul 2005 18:07:29 +0200 Received: from du-001-062.access.de.clara.net ([212.82.227.62]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2005 18:07:29 +0200 Received: from nobody by du-001-062.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 15 Jul 2005 18:07:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 15 Jul 2005 18:03:55 +0200 Organization: Lines: 85 Message-ID: <42D7DE6B.F8F@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: du-001-062.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Last Call Comments: draft-ietf-ltru-registry-09 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Scott Hollenbeck wrote: > Section 1, second-to-last paragraph: > Please add citations for RFCs 3066 and 1766. > - This document replaces RFC 3066, which replaced RFC 1766 > + This document replaces RFC 3066 [RFC3066], which replaced > RFC 1766 [RFC1766]. In other words s,RFC 3066,, and s,RFC 1766,, combined with the existing resulting in | This document replaces [RFC3066], which replaced [RFC1766]. > Section 2.1, first paragraph: > Please cite the ABNF specification in "ABNF %x2D". > - ABNF %x2D > + ABNF [RFC2234bis] %x2D I'd prefer to explain ABNF in chapter 1 together with used 2119 keywords (BTW, "SHALL NOT" isn't used, but Bruce is on vacation): [...] | document are to be interpreted as described in [RFC2119]. + The syntax is shown using the ABNF defined in [RFC2234bis]. > Section 2.1, bottom of page 5: > Please cite a specification for US-ASCII Reference stolen as is from the SPF RfC: USA Code for Information Interchange, X3.4 American National Standards Institute (formerly United States of America Standards Institute) ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet. > "MAY NOT" is not an RFC 2119 imperative. Do you have a tool for this stunt ? It's even folded. > A change to "do not" might be appropriate. Or to SHALL NOT, fixing two nits at the same time. > Section 3.6: What type of RFC is required? Informational > or Standards Track? Community-reviewed, or RFC-Editor > published? Does it matter? It matters, IMHO better than "informational" or "historic". > It might be helpful to cite one of the methods described in > section 2 of RFC 2434 if one is appropriate. Later text in > the section says "although the IESG MAY change the assignment > when approving the RFC", so I have to believe that we're > talking about either an "IETF Consensus" or > "Standards Action" document. The former "IETF consensus" should be good enough, that would allow experimental RfCs. Also allowing RfC editor submissions would be tricky: It would be a mixture of "IESG approval" for the prefix letter, some IESG review as for all RfC editor submissions, combined with no approval (otherwise it would be very similar to "IETF consensus" only bypassing the "IETF last call", bad idea). If the RfC editor insists on it the IESG would have to assign the prefix letter anyway, but I still don't want an "informational" RfC to screw up language tags. So let's take "IETF consensus". Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 12:20:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtSvm-0007mk-R5; Fri, 15 Jul 2005 12:20:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtSvl-0007mc-Gr for ltru@megatron.ietf.org; Fri, 15 Jul 2005 12:20:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22638 for ; Fri, 15 Jul 2005 12:20: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.43) id 1DtTOb-0007zk-5y for ltru@ietf.org; Fri, 15 Jul 2005 12:50:42 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Jul 2005 09:20: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] Re: last call: language tag usage Date: Fri, 15 Jul 2005 09:20:40 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D601@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: last call: language tag usage Thread-Index: AcWJOeZXVD75jSMTQ3u8qS09+3DWlwAHbXng From: "Addison Phillips" To: X-OriginalArrivalTime: 15 Jul 2005 16:20:40.0815 (UTC) FILETIME=[248B97F0:01C58959] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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="===============0959595174==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0959595174== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 T2theS4gV2Ugc3RpbGwgaGF2ZSB0aGUgcHJvYmxlbSBvZiB0aGUgcHJvaGliaXRpb24gb24gbm9u LW5hdHVyYWwgbGFuZ3VhZ2UgaWRlbnRpZmljYXRpb24sIHNvIHRoZSBmdWxsIHBhcmFncmFwaCwg YWRhcHRlZCBmcm9tIHRoZSAibG9uZyB2ZXJzaW9uIiwgcG9zdC1lZGl0IHJlYWRzOg0KDQo8dD5U aGUgbGFuZ3VhZ2UgdGFnIGlzIHVzZWQgdG8gaGVscCBpZGVudGlmeSB3aGljaCBsYW5ndWFnZSBp cyBiZWluZyBzcG9rZW4sIHdyaXR0ZW4sIHNpZ25lZCwgb3Igb3RoZXJ3aXNlIHNpZ25hbGVkIGZv ciB0aGUgcHVycG9zZSBvZiBjb21tdW5pY2F0aW9uLiBUaGUgbGFuZ3VhZ2UgaW4gcXVlc3Rpb24g bWlnaHQgaW5jbHVkZSBhIGNvbnN0cnVjdGVkIG9yIGFydGlmaWNpYWxseSBkZXNpZ25lZCBsYW5n dWFnZSwgYnV0IGV4Y2x1ZGVzIGxhbmd1YWdlcyBub3QgaW50ZW5kZWQgcHJpbWFyaWx5IGZvciBo dW1hbiBjb21tdW5pY2F0aW9uLCBzdWNoIGFzIHByb2dyYW1taW5nIG9yIGNvbXB1dGVyIGxhbmd1 YWdlcy48L3Q+DQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0 LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdv cmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0 IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogbHRydS1ib3VuY2VzQGxpc3RzLmlldGYub3JnIFttYWlsdG86bHRydS1ib3VuY2VzQGxp c3RzLmlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgRmVsaXggU2FzYWtpDQo+IFNlbnQ6IDIwMDXl ubQ35pyIMTXml6UgNTozNQ0KPiBUbzogbHRydUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0x0 cnVdIFJlOiBsYXN0IGNhbGw6IGxhbmd1YWdlIHRhZyB1c2FnZQ0KPiANCj4gKzENCj4gDQo+IC0t IEZlbGl4DQo+IE9uIEZyaSwgMTUgSnVsIDIwMDUgMjA6MTE6MDQgKzA5MDAsIEVya2tpIEtvbGVo bWFpbmVuDQo+IDxlcmtraS5rb2xlaG1haW5lbkBrb3R1cy5maT4gd3JvdGU6DQo+IA0KPiA+IEZp bmUgYnkgbWUhDQo+ID4NCj4gPiBFcmtraSBJLiBLb2xlaG1haW5lbg0KPiA+DQo+ID4gRnJhbmsg RWxsZXJtYW5uIHdyb3RlOg0KPiA+DQo+ID4+IHImZCBhZnJhYyB3cm90ZToNCj4gPj4gICAgW01h cmlvbiBHdW5uIHdyb3RlOl0NCj4gPj4NCj4gPj4+PiAnVGhlIGxhbmd1YWdlIHRhZyBpcyB1c2Vk IHRvIGhlbHAgaWRlbnRpZnkgd2hpY2ggbGFuZ3VhZ2UgaXMNCj4gPj4+PiBiZWluZyBzcG9rZW4s IHdyaXR0ZW4sIHNpZ25lZCBvciBvdGhlcndpc2Ugc2lnbmFsbGVkIGZvciB0aGUNCj4gPj4+PiBw dXJwb3NlIG9mIGNvbW11bmljYXRpb24uJw0KPiA+Pj4+DQo+ID4+DQo+ID4+PiArMQ0KPiA+Pj4N Cj4gPj4gIE9rYXksIGxldCdzIHRha2UgdGhlIGFkZGVkICJoZWxwIi4gIEFmdGVyIEFkZGlzb24g bWVudGlvbmVkDQo+ID4+IFdpdHRnZW5zdGVpbiBJIGNoZWNrZWQgc29tZSBxdW90ZXMgb2YgV2hv cmYsIGFuZCB0aGUgImhlbHAiDQo+ID4+IGFzcGVjdCBpcyBpbXBvcnRhbnQgKGUuZy4gImVuIiBh cyB3cml0dGVuIGJ5IGxhd3llcnMgaXMNCj4gPj4gdW5yZWxhdGVkIHRvICJlbiIgYXMgc3Bva2Vu IG9uIGFueSAtMDAxIG9yIEtsaW5nb24gc3RyZWV0KS4NCj4gPj4gICAgICAgICAgICAgICAgICAg ICAgIEJ5ZSwgRnJhbmsNCj4gPj4gICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gPj4gTHRydUBsaXN0cy5p ZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1 DQo+ID4+DQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiA+IEx0cnVAbGlzdHMu aWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1 DQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IEx0cnUgbWFpbGluZyBsaXN0DQo+IEx0cnVAbGlzdHMuaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQo= --===============0959595174== 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 --===============0959595174==-- From ltru-bounces@lists.ietf.org Fri Jul 15 12:53:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtTRe-00081v-DG; Fri, 15 Jul 2005 12:53:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtTRd-0007z3-5C for ltru@megatron.ietf.org; Fri, 15 Jul 2005 12:53:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24380 for ; Fri, 15 Jul 2005 12:53: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.43) id 1DtTuR-0000Yv-S7 for ltru@ietf.org; Fri, 15 Jul 2005 13:23:36 -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 Jul 2005 09:53: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] Last Call Comments: draft-ietf-ltru-registry-09 Date: Fri, 15 Jul 2005 09:53:32 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D642@irvmbxw01.quest.com> Thread-Topic: [Ltru] Last Call Comments: draft-ietf-ltru-registry-09 Thread-Index: AcWJRRqUtYeF7FvZRdm7/O+/DJcQiQAFK+bQ From: "Addison Phillips" To: "Scott Hollenbeck" , X-OriginalArrivalTime: 15 Jul 2005 16:53:33.0396 (UTC) FILETIME=[BC4B9140:01C5895D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 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 Thanks for the comments. Responses 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 Scott Hollenbeck > Sent: 2005?7?15? 6:57 > To: ltru@ietf.org > Subject: [Ltru] Last Call Comments: draft-ietf-ltru-registry-09 >=20 > draft-ietf-ltru-registry-09 looks really good. It's precise and = complete > as > far as I can tell. I did find a few small issues, though: >=20 > Section 1, second-to-last paragraph: > Please add citations for RFCs 3066 and 1766. >=20 > - This document replaces RFC 3066, which replaced RFC 1766. > + This document replaces RFC 3066 [RFC3066], which replaced RFC 1766 > [RFC1766]. [Addison Phillips]=20 Done, actually replaced with symrefs. >=20 > Section 2.1, first paragraph: > Please cite the ABNF specification in "ABNF %x2D". >=20 > - ABNF %x2D > + ABNF [RFC2234bis] %x2D [Addison Phillips]=20 Done. >=20 > Section 2.1, bottom of page 5: > Please cite a specification for US-ASCII since the text says "Note = that > although [RFC2234bis] refers to octets, the language tags described in > this > document are sequences of characters from the US-ASCII repertoire". [Addison Phillips]=20 I added a reference to ISO/IEC 646 (as a normative reference). >=20 > Section 2.1, top of page 6: > - capitalization of some of the subtags, but these MUST not be taken = to > + capitalization of some of the subtags, but these MUST NOT be taken = to [Addison Phillips]=20 Good catch. >=20 > Page 22, 5th paragraph: > "MAY NOT" is not an RFC 2119 imperative. A change to "do not" might = be > appropriate. [Addison Phillips]=20 Actually page 21.=20 I shouldn't be normative in the first place. I weakened your suggested = text slightly and the resulting paragraph reads: Note that 'Preferred-Value' mappings in records of type 'region' = sometimes does not represent exactly the same meaning as the original = value. There are many reasons for a country code to be changed and the = effect this has on the formation of language tags will depend on the = nature of the change in question. >=20 > Section 3.6: What type of RFC is required? Informational or Standards > Track? Community-reviewed, or RFC-Editor published? Does it matter? = It > might be helpful to cite one of the methods described in section 2 of = RFC > 2434 if one is appropriate. Later text in the section says "although = the > IESG MAY change the assignment when approving the RFC", so I have to > believe > that we're talking about either an "IETF Consensus" or "Standards = Action" > document. >=20 Referencing RFC 2434 make a great deal of sense. I tend to think that = the intention was an "IETF Consensus" decision so I borrowed a locution = by googling IETF Consensus and finding = draft-ietf-pwe3-iana-allocation-11.txt and propose that we change this = paragraph: Allocation of a single-letter subtag SHALL take the form of an=20 RFC defining the name, purpose, processes, and procedures for=20 maintaining the subtags. The maintaining or registering authority, = including=20 name, contact email, discussion list email, and URL location of the = registry=20 MUST be indicated clearly in the RFC. The RFC MUST specify or include = each of the following: To read: Single-letter subtags are to be assigned by IANA using the "IETF = Consensus" policy defined by RFC 2434. This policy requires the = development of an RFC, which SHALL define the name, purpose, processes, = and procedures for maintaining the subtags. The maintaining or = registering authority, including name, contact email, discussion list = email, and URL location of the registry MUST be indicated clearly in the = RFC. The RFC MUST specify or include each of the following: _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 13:00:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtTYW-00056K-Rn; Fri, 15 Jul 2005 13:00:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtTYU-00054b-7I for ltru@megatron.ietf.org; Fri, 15 Jul 2005 13:00:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24832 for ; Fri, 15 Jul 2005 13:00:50 -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.43) id 1DtU1K-0000oo-5v for ltru@ietf.org; Fri, 15 Jul 2005 13:30:43 -0400 Received: from uknsprd1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 15 Jul 2005 17:00:28 +0000 Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IJO00K5RHWSN9@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 15 Jul 2005 18:00:28 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 15 Jul 2005 18:00:28 +0100 Date: Fri, 15 Jul 2005 18:00:27 +0100 From: Misha Wolf Subject: RE: [Ltru] Last Call Comments: draft-ietf-ltru-registry-09 To: ltru@ietf.org Message-id: <1987416CA83AC7499AC772F92E2DBF7804200A5D@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Last Call Comments: draft-ietf-ltru-registry-09 Thread-Index: AcWJRRqUtYeF7FvZRdm7/O+/DJcQiQAFK+bQAAEmlbA= Content-class: urn:content-classes:message X-OriginalArrivalTime: 15 Jul 2005 17:00:28.0211 (UTC) FILETIME=[B38B5030:01C5895E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: Note that 'Preferred-Value' mappings in records of type 'region' sometimes does not represent exactly the same meaning as the original value. There are many reasons for a country code to be changed and=20 the effect this has on the formation of language tags will depend on=20 the nature of the change in question. Singular/plural problem: You have "mappings" but "does not". 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 Fri Jul 15 13: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 1DtTaN-000621-3C; Fri, 15 Jul 2005 13: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 1DtTaL-00061t-Ez for ltru@megatron.ietf.org; Fri, 15 Jul 2005 13:02:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24927 for ; Fri, 15 Jul 2005 13:02:46 -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.43) id 1DtU3B-0000tJ-H1 for ltru@ietf.org; Fri, 15 Jul 2005 13:32: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, 15 Jul 2005 10:02: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] Last Call Comments: draft-ietf-ltru-registry-09 Date: Fri, 15 Jul 2005 10:02:38 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D64D@irvmbxw01.quest.com> Thread-Topic: [Ltru] Last Call Comments: draft-ietf-ltru-registry-09 Thread-Index: AcWJRRqUtYeF7FvZRdm7/O+/DJcQiQAFK+bQAAEmlbAAACZ8oA== From: "Addison Phillips" To: "Misha Wolf" , X-OriginalArrivalTime: 15 Jul 2005 17:02:39.0277 (UTC) FILETIME=[01AA65D0:01C5895F] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Thanks. 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: 2005?7?15? 10:00 > To: ltru@ietf.org > Subject: RE: [Ltru] Last Call Comments: draft-ietf-ltru-registry-09 >=20 > Addison Phillips wrote: >=20 > Note that 'Preferred-Value' mappings in records of type 'region' > sometimes does not represent exactly the same meaning as the original > value. There are many reasons for a country code to be changed and > the effect this has on the formation of language tags will depend on > the nature of the change in question. >=20 > Singular/plural problem: You have "mappings" but "does not". >=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 Fri Jul 15 13:09:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtTh2-00023E-9D; Fri, 15 Jul 2005 13:09:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtTh1-000237-9X for ltru@megatron.ietf.org; Fri, 15 Jul 2005 13:09:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25661 for ; Fri, 15 Jul 2005 13:09: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.43) id 1DtU9r-0001Aw-EI for ltru@ietf.org; Fri, 15 Jul 2005 13:39:32 -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 Jul 2005 10:09: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 Date: Fri, 15 Jul 2005 10:09:31 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D655@irvmbxw01.quest.com> Thread-Topic: Updated editor's copy available Thread-Index: AcWJRRqUtYeF7FvZRdm7/O+/DJcQiQAFK+bQAAFyVFA= From: "Addison Phillips" To: "Addison Phillips" , X-OriginalArrivalTime: 15 Jul 2005 17:09:32.0620 (UTC) FILETIME=[F80988C0:01C5895F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: Subject: [Ltru] Updated editor's copy available X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 By the way, an updated editor's copy (draft-10) is now on my personal = website for those who wish to see how WG Last Call comments look in = context. All of the accepted changes so far are incorporated, excepting = the suggested text about the meaning of UN M.49 values. http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.txt http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.html Addison 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@lists.ietf.org Fri Jul 15 13:32:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtU33-0004xZ-QT; Fri, 15 Jul 2005 13: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 1DtU32-0004x6-Sy for ltru@megatron.ietf.org; Fri, 15 Jul 2005 13:32:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27230 for ; Fri, 15 Jul 2005 13:32:25 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtUVt-0001yt-2X for ltru@ietf.org; Fri, 15 Jul 2005 14:02:18 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 10:32:17 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 10:32:17 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer Date: Fri, 15 Jul 2005 10:32:16 -0700 Message-ID: Thread-Topic: [Ltru] Last call: IANA adaptation of the UN disclaimer Thread-Index: AcWJK9E2tAkph2XXQ7SKgIw5FKC1kwAGKhGwAASwUYAAAj2IkA== From: "Peter Constable" To: X-OriginalArrivalTime: 15 Jul 2005 17:32:17.0177 (UTC) FILETIME=[25606890:01C58963] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: Addison Phillips [mailto:addison.phillips@quest.com] > In draft-registry or draft-initial? >=20 > If in draft-registry, *where*? Sorry, I hadn't looked at the syntax for the registry for a while and was thinking it was possible to include comments -- indeed, I thought we were including some comments describing the fields of records, but that was probably something from before the switch to record jar format. Hence I was thinking this could be included as introductory comments. I guess since the syntax for the registry doesn't allow for comments, the only option would be somewhere in draft-registry.=20 In looking for a logical place such text might be included, I find there there's no place where the registry is introduced; the first reference (other than TOC or the page header "langtags-registry") is in 2.1:=20 "Thus a parser need not have an up-to-date copy (or any copy at all) of the subtag registry to perform most searching and matching operations." That seems a bit odd to me. I suggest the following paragraphs be added at the end of the intro of section 2 (i.e. before the heading for 2.1): The language tag is composed of one or more parts or "subtags". As described below, subtags available for use in a language tag are maintained in a registry (the 'subtag registry') that is administered by the Internet Assigned Numbers Authority (IANA).=20 The designations employed and the presentation of names of countries or regions, languages or scripts in the subtag registy do not imply the expression of any opinion whatsoever on the part of the IETF, ICANN and IANA concerning the legal status of any country, territory, region or of its authorities, or concerning the delimitation of frontiers or boundaries, or concerning any cultural, political, economical, educational sovereign issue within any country or region including any issues pertaining to the identity or usage of any language or script within any country or region. A concomitant change would be made in the first paragraph of section 2.1: - The language tag is composed of one or more parts or "subtags". Each subtag consists... + Each subtag within a language tag consists... Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 13:34:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtU4e-0006Dh-8o; Fri, 15 Jul 2005 13:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtU4c-0006DF-34 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 13:34:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27378 for ; Fri, 15 Jul 2005 13:34:02 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtUXR-000230-35 for ltru@ietf.org; Fri, 15 Jul 2005 14:03:55 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Fri, 15 Jul 2005 10:25:12 -0700 Message-ID: <009b01c58963$5f37d7b0$fc763009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C20D601@irvmbxw01.quest.com> Subject: Re: [Ltru] Re: last call: language tag usage Date: Fri, 15 Jul 2005 10:33: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.1506 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA27378 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 =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: Sent: Friday, July 15, 2005 09:20 Subject: RE: [Ltru] Re: last call: language tag usage > Okay. We still have the problem of the prohibition on non-natural langu= age identification, so the full paragraph, adapted from the "long version", post-edit reads: > > The language tag is used to help identify which language is being spoken, written, signed, or otherwise signaled for the purpose of communication. The language in question might include a constructed or artificially designed language, but excludes languages not intended primarily for human communication, such as programming or computer languages. > > 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 Felix Sasaki > > Sent: 2005=E5=B9=B47=E6=9C=8815=E6=97=A5 5:35 > > To: ltru@ietf.org > > Subject: Re: [Ltru] Re: last call: language tag usage > > > > +1 > > > > -- Felix > > On Fri, 15 Jul 2005 20:11:04 +0900, Erkki Kolehmainen > > wrote: > > > > > Fine by me! > > > > > > Erkki I. Kolehmainen > > > > > > Frank Ellermann wrote: > > > > > >> r&d afrac wrote: > > >> [Marion Gunn wrote:] > > >> > > >>>> 'The language tag is used to help identify which language is > > >>>> being spoken, written, signed or otherwise signalled for the > > >>>> purpose of communication.' > > >>>> > > >> > > >>> +1 > > >>> > > >> Okay, let's take the added "help". After Addison mentioned > > >> Wittgenstein I checked some quotes of Whorf, and the "help" > > >> aspect is important (e.g. "en" as written by lawyers is > > >> unrelated to "en" as spoken on any -001 or Klingon street). > > >> 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 > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 13:34:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtU5K-0006hW-J7; Fri, 15 Jul 2005 13:34:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtU5J-0006hO-Q2 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 13:34:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27433 for ; Fri, 15 Jul 2005 13:34:46 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DtUY9-000252-W7 for ltru@ietf.org; Fri, 15 Jul 2005 14:04:39 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Fri, 15 Jul 2005 10:26:01 -0700 Message-ID: <00a101c58963$7cd7c410$fc763009@sanjose.ibm.com> From: "Mark Davis" To: "Peter Constable" , "LTRU Working Group" References: Subject: Re: [Ltru] Last call: IANA adaptation of the UN disclaimer Date: Fri, 15 Jul 2005 10:34: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.1506 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA27433 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 =E2=80=8EMark ----- Original Message -----=20 From: "Peter Constable" To: Sent: Friday, July 15, 2005 07:03 Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of r&d afrac > I suggest that we copy the UN disclaimer and tell the IANA to use the > following wording in its display and documents: The second half of this paragraph, which refers to statistics and datasets, is out of context and not applicable. I have no objection to a revision of the first half appearing in the registry: "The designations employed and the presentation of names of countries or regions, languages or scripts in this registy do not imply the expression of any opinion whatsoever on the part of the IETF, ICANN and IANA concerning the legal status of any country, territory, region or of its authorities, or concerning the delimitation of frontiers or boundaries, or concerning any cultural, political, economical, educational sovereign issue within any country or region including any issues pertaining to the identity or usage of any language or script within any country or region." 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 Fri Jul 15 13:55:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUPn-00039e-22; Fri, 15 Jul 2005 13:55:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUPl-00036S-NQ for ltru@megatron.ietf.org; Fri, 15 Jul 2005 13:55:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29182 for ; Fri, 15 Jul 2005 13:55:56 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-haw.bigfish.com ([12.129.199.61] helo=mail13-haw-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtUsb-0002wC-1N for ltru@ietf.org; Fri, 15 Jul 2005 14:25:47 -0400 Received: from mail13-haw.bigfish.com (localhost.localdomain [127.0.0.1]) by mail13-haw-R.bigfish.com (Postfix) with ESMTP id 24B65396DEE; Fri, 15 Jul 2005 17:55:44 +0000 (UTC) X-BigFish: VP Received: by mail13-haw.bigfish.com (MessageSwitch) id 112145014432256_5674; Fri, 15 Jul 2005 17:55:44 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail13-haw.bigfish.com (Postfix) with ESMTP id EFF683968D1; Fri, 15 Jul 2005 17:55:43 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005071511032274:218452 ; Fri, 15 Jul 2005 11:03:22 -0700 To: "Peter Constable" Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Fri, 15 Jul 2005 10:52:43 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/15/2005 10:52:44, Serialize complete at 07/15/2005 10:52:44, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/15/2005 11:03:22 AM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/15/2005 11:03:26 AM, Serialize complete at 07/15/2005 11:03:26 AM Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Minor comment. Should the material in the forward slashes be removed? Isn't identification the purpose of the registry? Text: ... or concerning any cultural, political, economical, educational sovereign issue within any country or region including any issues pertaining to the /identity or/ usage of any language or script within any country or region. Karen Broome "Peter Constable" Sent by: ltru-bounces@lists.ietf.org 07/15/2005 10:32 AM To: cc: Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer > From: Addison Phillips [mailto:addison.phillips@quest.com] > In draft-registry or draft-initial? > > If in draft-registry, *where*? Sorry, I hadn't looked at the syntax for the registry for a while and was thinking it was possible to include comments -- indeed, I thought we were including some comments describing the fields of records, but that was probably something from before the switch to record jar format. Hence I was thinking this could be included as introductory comments. I guess since the syntax for the registry doesn't allow for comments, the only option would be somewhere in draft-registry. In looking for a logical place such text might be included, I find there there's no place where the registry is introduced; the first reference (other than TOC or the page header "langtags-registry") is in 2.1: "Thus a parser need not have an up-to-date copy (or any copy at all) of the subtag registry to perform most searching and matching operations." That seems a bit odd to me. I suggest the following paragraphs be added at the end of the intro of section 2 (i.e. before the heading for 2.1): The language tag is composed of one or more parts or "subtags". As described below, subtags available for use in a language tag are maintained in a registry (the 'subtag registry') that is administered by the Internet Assigned Numbers Authority (IANA). The designations employed and the presentation of names of countries or regions, languages or scripts in the subtag registy do not imply the expression of any opinion whatsoever on the part of the IETF, ICANN and IANA concerning the legal status of any country, territory, region or of its authorities, or concerning the delimitation of frontiers or boundaries, or concerning any cultural, political, economical, educational sovereign issue within any country or region including any issues pertaining to the identity or usage of any language or script within any country or region. A concomitant change would be made in the first paragraph of section 2.1: - The language tag is composed of one or more parts or "subtags". Each subtag consists... + Each subtag within a language tag consists... 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 Fri Jul 15 14:08:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUbo-0007Tq-JV; Fri, 15 Jul 2005 14:08:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUbn-0007Tk-4F for ltru@megatron.ietf.org; Fri, 15 Jul 2005 14:08:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00500 for ; Fri, 15 Jul 2005 14:08:21 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-ash.bigfish.com ([206.16.192.253] helo=mail66-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtV4d-0003Up-Nq for ltru@ietf.org; Fri, 15 Jul 2005 14:38:12 -0400 Received: from mail66-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail66-ash-R.bigfish.com (Postfix) with ESMTP id 4B4C73BA414; Fri, 15 Jul 2005 18:08:13 +0000 (UTC) X-BigFish: VP Received: by mail66-ash (MessageSwitch) id 1121450893251892_30211; Fri, 15 Jul 2005 18:08:13 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail66-ash.bigfish.com (Postfix) with ESMTP id 2B2FE3B999A; Fri, 15 Jul 2005 18:08:13 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005071511155468:218961 ; Fri, 15 Jul 2005 11:15:54 -0700 To: "Mark Davis" Subject: Re: [Ltru] Re: last call: language tag usage MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Fri, 15 Jul 2005 11:04:45 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/15/2005 11:05:16, Serialize complete at 07/15/2005 11:05:16, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/15/2005 11:15:54 AM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/15/2005 11:15:55 AM, Serialize complete at 07/15/2005 11:15:55 AM Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) 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 Is this an improvement? The language tag is used to help identify the language -that is- spoken, written, signed, or otherwise signaled for the purpose of communication. The language in question might include a constructed or artificially designed language, but excludes languages not intended primarily for human communication, such as programming or computer languages. The "which is being" text implies that I'm classifying content or essence prior to it being written, spoken, or signed. This could be a future use of the codes, but is certainly not common today. Generally we're dealing with content that is already written, spoken, signed, or signaled. Karen Broome _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 14:09:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUck-0008Vw-W0; Fri, 15 Jul 2005 14:09:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUck-0008Vr-FA for ltru@megatron.ietf.org; Fri, 15 Jul 2005 14:09:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00653 for ; Fri, 15 Jul 2005 14:09:20 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtV5c-0003Yw-2H for ltru@ietf.org; Fri, 15 Jul 2005 14:39:12 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 11:09: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); Fri, 15 Jul 2005 11:09:12 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer Date: Fri, 15 Jul 2005 11:09:12 -0700 Message-ID: Thread-Topic: [Ltru] Last call: IANA adaptation of the UN disclaimer Thread-Index: AcWJZnBY0qPy1zuIRNGPPGc5ceRXxAAAPqPg From: "Peter Constable" To: X-OriginalArrivalTime: 15 Jul 2005 18:09:12.0430 (UTC) FILETIME=[4DC530E0:01C58968] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com] > Minor comment. Should the material in the forward slashes be removed? > Isn't identification the purpose of the registry? >=20 > Text: >=20 > ... or concerning any cultural, political, economical, > educational sovereign issue within any country or region including any > issues pertaining to the /identity or/ usage of any language or script > within any country or region. I see the potential for confusion. What I had in mind was issues of how speech communities within a given country prefer to identify themselves. So, for instance, if we provide subtags for Serbian and Croatian or for Serbo-Croatian, IANA etc. are not thereby expressing any opinion regarding how speech communities in any of the Balkan nations are or should be identified by themselves or by their neighbours. Perhaps: "... pertaining to the usage of any language or script or to identities used for speech communities within any country or region." Is that better? Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 14:19:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUmw-0008Jl-P0; Fri, 15 Jul 2005 14:19:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUmw-0008Jg-53 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 14:19:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02878 for ; Fri, 15 Jul 2005 14:19:52 -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.43) id 1DtVFm-0004RK-Mg for ltru@ietf.org; Fri, 15 Jul 2005 14:49:44 -0400 Received: from uknsprd1 (unverified) by lonsmime02.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Fri, 15 Jul 2005 18:19:35 +0000 Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IJO00105LKNXA@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Fri, 15 Jul 2005 19:19:35 +0100 (BST) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Fri, 15 Jul 2005 19:19:35 +0100 Date: Fri, 15 Jul 2005 19:19:34 +0100 From: Misha Wolf Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer To: ltru@ietf.org Message-id: <1987416CA83AC7499AC772F92E2DBF7804200A7B@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] Last call: IANA adaptation of the UN disclaimer Thread-Index: AcWJZnBY0qPy1zuIRNGPPGc5ceRXxAAAPqPgAAB99ZA= Content-class: urn:content-classes:message X-OriginalArrivalTime: 15 Jul 2005 18:19:35.0270 (UTC) FILETIME=[C1030860:01C58969] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Peter, > "... pertaining to the usage of any language or script or to=20 > identities used for speech communities within any country or=20 > region." > > Is that better? I'm afraid that I find this incomprehensible :-( 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 Fri Jul 15 14:30:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtUww-0006tI-Kz; Fri, 15 Jul 2005 14: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 1DtUws-0006kn-Sv for ltru@megatron.ietf.org; Fri, 15 Jul 2005 14:30:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03851 for ; Fri, 15 Jul 2005 14:30: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.43) id 1DtVPi-0004vw-6j for ltru@ietf.org; Fri, 15 Jul 2005 15:00:00 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Jul 2005 11:29: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] Last call: IANA adaptation of the UN disclaimer Date: Fri, 15 Jul 2005 11:29:51 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D6DB@irvmbxw01.quest.com> Thread-Topic: [Ltru] Last call: IANA adaptation of the UN disclaimer Thread-Index: AcWJK9E2tAkph2XXQ7SKgIw5FKC1kwAGKhGwAASwUYAAAj2IkAACORqQ From: "Addison Phillips" To: "Peter Constable" , X-OriginalArrivalTime: 15 Jul 2005 18:29:52.0693 (UTC) FILETIME=[31064E50:01C5896B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 The purpose and point of this text I agree with, but the form of the = text is not in keeping with the terminology or form of the rest of the = document. It is nearly incomprehensible. How about replacing your second paragraph with: The presence, absence or contents of subtags and their associated = fields in the registry do not and should not be taken to imply an = opinion on the part of the IETF, ICANN and IANA concerning the legal = status of any language, script, country, territory, region, or language = variation. Nor should they be taken to endorse any particular position = regarding the legal status, authority, frontiers, boundaries, or = cultural, political, economical, or educational policies of any = particular country or region. This includes any issues pertaining to the = identity or usage of any language or script within any country or = region. 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: 2005?7?15? 10:32 > To: ltru@ietf.org > Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer >=20 > > From: Addison Phillips [mailto:addison.phillips@quest.com] >=20 >=20 > > In draft-registry or draft-initial? > > > > If in draft-registry, *where*? >=20 > Sorry, I hadn't looked at the syntax for the registry for a while and > was thinking it was possible to include comments -- indeed, I thought = we > were including some comments describing the fields of records, but = that > was probably something from before the switch to record jar format. > Hence I was thinking this could be included as introductory comments. = I > guess since the syntax for the registry doesn't allow for comments, = the > only option would be somewhere in draft-registry. >=20 > In looking for a logical place such text might be included, I find = there > there's no place where the registry is introduced; the first reference > (other than TOC or the page header "langtags-registry") is in 2.1: >=20 > "Thus a parser need not have an up-to-date copy (or any copy at all) = of > the subtag registry to perform most searching and matching = operations." >=20 > That seems a bit odd to me. I suggest the following paragraphs be = added > at the end of the intro of section 2 (i.e. before the heading for = 2.1): >=20 > > The language tag is composed of one or more parts or "subtags". As > described below, subtags available for use in a language tag are > maintained in a registry (the 'subtag registry') that is administered = by > the Internet Assigned Numbers Authority (IANA). >=20 > The designations employed and the presentation of names of countries = or > regions, languages or scripts in the subtag registy do not imply the > expression of any opinion whatsoever on the part of the IETF, ICANN = and > IANA concerning the legal status of any country, territory, region or = of > its authorities, or concerning the delimitation of frontiers or > boundaries, or concerning any cultural, political, economical, > educational sovereign issue within any country or region including any > issues pertaining to the identity or usage of any language or script > within any country or region. > >=20 > A concomitant change would be made in the first paragraph of section > 2.1: >=20 > - The language tag is composed of one or more parts or "subtags". = Each > subtag consists... >=20 > + Each subtag within a language tag consists... >=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 Fri Jul 15 14:37:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtV3f-00045v-He; Fri, 15 Jul 2005 14:37:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtV3e-00045q-3x for ltru@megatron.ietf.org; Fri, 15 Jul 2005 14:37:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04335 for ; Fri, 15 Jul 2005 14:37:08 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtVWU-00059W-PN for ltru@ietf.org; Fri, 15 Jul 2005 15:07:00 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 11:36: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.1830); Fri, 15 Jul 2005 11:36:58 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer Date: Fri, 15 Jul 2005 11:36:58 -0700 Message-ID: Thread-Topic: [Ltru] Last call: IANA adaptation of the UN disclaimer Thread-Index: AcWJK9E2tAkph2XXQ7SKgIw5FKC1kwAGKhGwAASwUYAAAj2IkAACORqQAAC91rA= From: "Peter Constable" To: X-OriginalArrivalTime: 15 Jul 2005 18:36:58.0528 (UTC) FILETIME=[2ED79200:01C5896C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 your alternate wording, modulo my response to your question of where this should go, and Karen's comment on "identity". Peter Constable > -----Original Message----- > From: Addison Phillips [mailto:addison.phillips@quest.com] > Sent: Friday, July 15, 2005 11:30 AM > To: Peter Constable; ltru@ietf.org > Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer >=20 > The purpose and point of this text I agree with, but the form of the text is not in > keeping with the terminology or form of the rest of the document. It is nearly > incomprehensible. >=20 > How about replacing your second paragraph with: >=20 > The presence, absence or contents of subtags and their associated fields in the > registry do not and should not be taken to imply an opinion on the part of the IETF, > ICANN and IANA concerning the legal status of any language, script, country, territory, > region, or language variation. Nor should they be taken to endorse any particular > position regarding the legal status, authority, frontiers, boundaries, or cultural, > political, economical, or educational policies of any particular country or region. This > includes any issues pertaining to the identity or usage of any language or script within > any country or region. >=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 Peter Constable > > Sent: 2005?7?15? 10:32 > > To: ltru@ietf.org > > Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer > > > > > From: Addison Phillips [mailto:addison.phillips@quest.com] > > > > > > > In draft-registry or draft-initial? > > > > > > If in draft-registry, *where*? > > > > Sorry, I hadn't looked at the syntax for the registry for a while and > > was thinking it was possible to include comments -- indeed, I thought we > > were including some comments describing the fields of records, but that > > was probably something from before the switch to record jar format. > > Hence I was thinking this could be included as introductory comments. I > > guess since the syntax for the registry doesn't allow for comments, the > > only option would be somewhere in draft-registry. > > > > In looking for a logical place such text might be included, I find there > > there's no place where the registry is introduced; the first reference > > (other than TOC or the page header "langtags-registry") is in 2.1: > > > > "Thus a parser need not have an up-to-date copy (or any copy at all) of > > the subtag registry to perform most searching and matching operations." > > > > That seems a bit odd to me. I suggest the following paragraphs be added > > at the end of the intro of section 2 (i.e. before the heading for 2.1): > > > > > > The language tag is composed of one or more parts or "subtags". As > > described below, subtags available for use in a language tag are > > maintained in a registry (the 'subtag registry') that is administered by > > the Internet Assigned Numbers Authority (IANA). > > > > The designations employed and the presentation of names of countries or > > regions, languages or scripts in the subtag registy do not imply the > > expression of any opinion whatsoever on the part of the IETF, ICANN and > > IANA concerning the legal status of any country, territory, region or of > > its authorities, or concerning the delimitation of frontiers or > > boundaries, or concerning any cultural, political, economical, > > educational sovereign issue within any country or region including any > > issues pertaining to the identity or usage of any language or script > > within any country or region. > > > > > > A concomitant change would be made in the first paragraph of section > > 2.1: > > > > - The language tag is composed of one or more parts or "subtags". Each > > subtag consists... > > > > + Each subtag within a language tag consists... > > > > > > > > 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 Fri Jul 15 15:24:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtVn5-00087Z-NP; Fri, 15 Jul 2005 15:24:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtVn4-00087O-IH for ltru@megatron.ietf.org; Fri, 15 Jul 2005 15:24:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08684 for ; Fri, 15 Jul 2005 15:24:04 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtWFv-0006l1-O6 for ltru@ietf.org; Fri, 15 Jul 2005 15:53:56 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtVmx-0005m0-00 for ltru@ietf.org; Fri, 15 Jul 2005 15:24:00 -0400 Message-ID: <00b301c58972$cb111aa0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <20050715111135.POSD27741.edge3.adelphia.net@megatron.ietf.org><00dd01c58949$0148e6e0$030aa8c0@DEWELL><42D7D0CC.DD9@xyzzy.claranet.de> <20050715152140.GI5992@NYCMJCOWA2> Subject: Re: [Ltru] Re: UN region code list change Date: Fri, 15 Jul 2005 12:24: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.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 - Based on the comments in this thread, I believe there is a rough consensus that no action is needed on this issue. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 15:34:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtVwi-0006T7-3V; Fri, 15 Jul 2005 15:34:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtVwg-0006PU-Pr for ltru@megatron.ietf.org; Fri, 15 Jul 2005 15:34:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09775 for ; Fri, 15 Jul 2005 15:34:00 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtWPZ-0007Ke-6s for ltru@ietf.org; Fri, 15 Jul 2005 16:03:53 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtVwf-000173-00 for ltru@ietf.org; Fri, 15 Jul 2005 15:34:01 -0400 Message-ID: <00c701c58974$319cd2e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Ltru] Re: last call: language tag usage Date: Fri, 15 Jul 2005 12:34: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: 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: > To: "Mark Davis" > Cc: > Sent: Friday, July 15, 2005 11:04 AM > Subject: Re: [Ltru] Re: last call: language tag usage > > Is this an improvement? ... If we're wordsmithing, I'd trim it to: Language tags are used to help identify languages, whether spoken, written, signed, or otherwise signaled, for the purpose of communication. This includes constructed and artificial languages, but excludes languages not intended primarily for human communication, such as programming languages. But really, I think we should let the editors do their jobs and sort through all the suggestions to come up with something reasonable, since there seems to be no substantive differences between most of the various suggestions. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 16:55:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXDq-0003FI-BK; Fri, 15 Jul 2005 16:55:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXDl-0003E4-0U for ltru@megatron.ietf.org; Fri, 15 Jul 2005 16:55:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09787 for ; Fri, 15 Jul 2005 16:55:42 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtXgc-0001SX-VO for ltru@ietf.org; Fri, 15 Jul 2005 17:25:36 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtXDY-0002uo-00 for ltru@ietf.org; Fri, 15 Jul 2005 16:55:32 -0400 Message-ID: <001801c5897f$93920780$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C20D6DB@irvmbxw01.quest.com> Subject: Re: [Ltru] Last call: IANA adaptation of the UN disclaimer Date: Fri, 15 Jul 2005 13:55: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.1 (/) 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 Hi - > From: "Addison Phillips" > To: "Peter Constable" ; > Sent: Friday, July 15, 2005 11:29 AM > Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer > > The purpose and point of this text I agree with, but the form of the text > is not in keeping with the terminology or form of the rest of the document. > It is nearly incomprehensible. > > How about replacing your second paragraph with: > > The presence, absence or contents of subtags and their associated fields > in the registry do not and should not be taken to imply an opinion on the part of > the IETF, ICANN and IANA concerning the legal status of any language, script, > country, territory, region, or language variation. Nor should they be taken to > endorse any particular position regarding the legal status, authority, frontiers, > boundaries, or cultural, political, economical, or educational policies of any > particular country or region. This includes any issues pertaining to the identity > or usage of any language or script within any country or region. ... As a technical contributor, I think there adding this text contributes no value to the document, and could in the longer term be harmful, regardless of its benign intent and content. None of the other IANA registries I've looked at has anything like this. As a very concrete example, the enterprise number registry at http://www.iana.org/assignments/enterprise-numbers doesn't have lawerly verbiage about trademarks or the legal status of enterprise names. Similarly, http://www.iana.org/assignments/ianaaddressfamilynumbers-mib doesn't fret about trademarks. Not even http://www.iana.org/assignments/idn/ goes through such hand-wringing. I think adding material like this would set a very bad precedent, because it could lead to folks misconstruing the absence of such disclaimers in other IANA-maintained registries. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 17:00:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXIo-00062N-6i; Fri, 15 Jul 2005 17:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXIl-00062C-W4 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 17:00:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11913 for ; Fri, 15 Jul 2005 17:00: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.43) id 1DtXlc-0002C3-8W for ltru@ietf.org; Fri, 15 Jul 2005 17:30:45 -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 Jul 2005 14:00:35 -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] Last call: IANA adaptation of the UN disclaimer Date: Fri, 15 Jul 2005 14:00:33 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D7C6@irvmbxw01.quest.com> Thread-Topic: [Ltru] Last call: IANA adaptation of the UN disclaimer Thread-Index: AcWJK9E2tAkph2XXQ7SKgIw5FKC1kwAGKhGwAASwUYAAAj2IkAACORqQAAC91rAABEhp8A== From: "Addison Phillips" To: "Peter Constable" , X-OriginalArrivalTime: 15 Jul 2005 21:00:35.0073 (UTC) FILETIME=[3EB3FF10:01C58980] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 You'll notice that Karen's identity issue was addressed by my edit.=20 I'm not sure, now that I think about it, that your proposed location = makes sense. Let me explain. Somewhere about six edits ago I heavily reformatted the document, moving = sections around. The document now falls into three main logical = sections. It is useful to enumerate the document's logical structure = anyway, so I'll take a moment to do so: Section 2 covers the syntax and format of language tags themselves. It = is only concerned with the form of language tags (the ABNF, rules for = formation of tags, language tag sources, and the like). Section 3 covers the format and operation of the registry, including = registration and maintenance and the like. Section 4 covers working with language tags (considerations for choosing = which one you want for your application; what they "mean", and so forth) I believe a statement of this nature probably fits best logically into = Section 4 and specifically into Section 4.2 (Meaning of the Language = Tag), where my proposed paragraph could be called out as a "Note:" = following the bullet list. I believe/hope I addressed Karen's concerns in my edit. 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: 2005?7?15? 11:37 > To: ltru@ietf.org > Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer >=20 > I'm OK with your alternate wording, modulo my response to your = question > of where this should go, and Karen's comment on "identity". >=20 >=20 > Peter Constable >=20 >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 17:13:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXUu-0003iG-3D; Fri, 15 Jul 2005 17:13:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtXUr-0003cl-6Q for ltru@megatron.ietf.org; Fri, 15 Jul 2005 17:13:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15912 for ; Fri, 15 Jul 2005 17:13:21 -0400 (EDT) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtXxh-0003hL-NB for ltru@ietf.org; Fri, 15 Jul 2005 17:43:15 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 14:13: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); Fri, 15 Jul 2005 14:13:12 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer Date: Fri, 15 Jul 2005 14:13:12 -0700 Message-ID: Thread-Topic: [Ltru] Last call: IANA adaptation of the UN disclaimer Thread-Index: AcWJK9E2tAkph2XXQ7SKgIw5FKC1kwAGKhGwAASwUYAAAj2IkAACORqQAAC91rAABEhp8AAA9OCQ From: "Peter Constable" To: X-OriginalArrivalTime: 15 Jul 2005 21:13:12.0288 (UTC) FILETIME=[0209D600:01C58982] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: Addison Phillips [mailto:addison.phillips@quest.com] > I'm not sure, now that I think about it, that your proposed location = makes sense... It still strikes me as slightly odd that there's a reference to "the = subtag registry" in 2.1 using the definite article "the" (usage of which = suggests the audience is assumed to know the intended referent) when no = prior mention of "the subtag registry" has been made. On reviewing, that = can be remedied with a very small change in 6th paragraph of the = introduction: - "This document specifies a particular identifier mechanism (the = language tag) and a registration function for values to be used to form = tags." + =FD"This document specifies a particular identifier mechanism (the = language tag) and a =FDregistration function (the subtag registry) for = values to be used to form tags."=FD Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 17:51:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtY5d-0005Xc-7j; Fri, 15 Jul 2005 17:51:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtY5b-0005XP-34 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 17:51:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27677 for ; Fri, 15 Jul 2005 17:51:19 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtYYU-00081m-I5 for ltru@ietf.org; Fri, 15 Jul 2005 18:21:14 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 14:51: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.1830); Fri, 15 Jul 2005 14:51:12 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer Date: Fri, 15 Jul 2005 14:51:12 -0700 Message-ID: Thread-Topic: [Ltru] Last call: IANA adaptation of the UN disclaimer Thread-Index: AcWJhFPT9fITJBmgS/6lEzv0Uczq7AAAujuw From: "Peter Constable" To: X-OriginalArrivalTime: 15 Jul 2005 21:51:12.0808 (UTC) FILETIME=[51559280:01C58987] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 > As a technical contributor, I think there adding this text contributes no value > to the document, and could in the longer term be harmful, regardless of > its benign intent and content. I'll gladly defer to your judgment on this. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 18:59:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZ9K-0001oo-Fl; Fri, 15 Jul 2005 18:59:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZ9I-0001oK-Pl for ltru@megatron.ietf.org; Fri, 15 Jul 2005 18:59:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03738 for ; Fri, 15 Jul 2005 18:59:12 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-res.bigfish.com ([63.161.60.61] helo=mail27-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtZcB-0001m6-Dp for ltru@ietf.org; Fri, 15 Jul 2005 19:29:08 -0400 Received: from mail27-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail27-res-R.bigfish.com (Postfix) with ESMTP id 017C248C4CA; Fri, 15 Jul 2005 22:59:04 +0000 (UTC) X-BigFish: VP Received: by mail27-res.bigfish.com (MessageSwitch) id 1121468343946221_16679; Fri, 15 Jul 2005 22:59:03 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail27-res.bigfish.com (Postfix) with ESMTP id D0C1348C4A4; Fri, 15 Jul 2005 22:59:03 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005071516064609:229587 ; Fri, 15 Jul 2005 16:06:46 -0700 To: "Peter Constable" Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Fri, 15 Jul 2005 15:55:58 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/15/2005 15:56:07, Serialize complete at 07/15/2005 15:56:07, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/15/2005 04:06:46 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/15/2005 04:06:46 PM, Serialize complete at 07/15/2005 04:06:46 PM Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Yes, I think Randy's findings on the lack of this type of text in other registries validates our initial gut instinct that this was a political rather than technical statement -- whether we generally agree with its content or not. If there is a disclaimer to be made, I think that IANA/ICANN is the one to draft the text and perhaps it should be in the context of all registries managed by the organization. +1 Karen Broome "Peter Constable" Sent by: ltru-bounces@lists.ietf.org 07/15/2005 02:51 PM To: cc: Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On Behalf Of > Randy Presuhn > As a technical contributor, I think there adding this text contributes no value > to the document, and could in the longer term be harmful, regardless of > its benign intent and content. I'll gladly defer to your judgment on this. 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 Fri Jul 15 19:24:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZXl-0002uz-OF; Fri, 15 Jul 2005 19:24:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZXk-0002rW-C0 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 19:24:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06626 for ; Fri, 15 Jul 2005 19:24:28 -0400 (EDT) Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dta0c-0002yT-Fx for ltru@ietf.org; Fri, 15 Jul 2005 19:54:24 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtZXY-0007TF-00 for ltru@ietf.org; Fri, 15 Jul 2005 19:24:20 -0400 Message-ID: <004301c58994$5c3576e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 15 Jul 2005 16:24:33 -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.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Ltru] newly added items #1065, #1066, #1068, #1069, #1070, #1071, #1072, and #1074 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 updated the issue tracker at https://rt.psg.com/ (user and password "ietf") with the issues that have come up so far in the working group last call. I'll be sending out separate messages for the three tickets that are still open; this is just a list of the ones where I believe the discussion has reached a rough consensus. resolved #1065: WGLC sect. 2 points 5&6 remove "judged as questionable" rejected #1066: WGLC add language name synonyms to initial registry resolved #1068: WGLC more extensive use of 2119 keywords rejected #1069: WGLC dispel confusion about 'x' rejected #1070: WGLC addendum to introduction resolved #1071: WGLC clarify why section 4 codes left out resolved #1072: WGLC compatibility principles resolved #1074: WGLC citation additions and corrections If you think additional discussion is needed on any of these, please review the discussion (summaries of links are included in the tickets) and remember to include the issue number in your subject line. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 19:26:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZZQ-0004gH-L2; Fri, 15 Jul 2005 19:26:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZZO-0004gC-W7 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 19:26:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06690 for ; Fri, 15 Jul 2005 19:26:11 -0400 (EDT) Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dta2I-00031N-FR for ltru@ietf.org; Fri, 15 Jul 2005 19:56:07 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtZZM-0000Ai-00 for ltru@ietf.org; Fri, 15 Jul 2005 19:26:13 -0400 Message-ID: <004801c58994$a19ccc60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 15 Jul 2005 16:26: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.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ltru] [psg.com #1067] Further clarify distinction between locale codes and 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > ------------------------------------------------------------------------- > This is in many ways a continuation of the discussion of > issue #1061. Message > http://www1.ietf.org/mail-archive/web/ltru/current/msg02701.html > suggests clarifying that the semantics of language tags are distinct > from > those of locale ids, even though they may constructed from some of the > same language and country codes > Discussion: > http://www1.ietf.org/mail-archive/web/ltru/current/msg02706.html Can we quickly resolve this one way or the other? Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 19:31:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZeO-0007jP-Ub; Fri, 15 Jul 2005 19:31:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZeN-0007jK-Ki for ltru@megatron.ietf.org; Fri, 15 Jul 2005 19:31:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06959 for ; Fri, 15 Jul 2005 19:31:19 -0400 (EDT) Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dta7H-000386-PR for ltru@ietf.org; Fri, 15 Jul 2005 20:01:16 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtZeL-0001Zs-00 for ltru@ietf.org; Fri, 15 Jul 2005 19:31:21 -0400 Message-ID: <004f01c58995$59674640$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 15 Jul 2005 16: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.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Ltru] [psg.com #1073] WGLC add IANA adaptation of "UN disclaimer" X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - > ------------------------------------------------------------------------- > In message > http://www1.ietf.org/mail-archive/web/ltru/current/msg02851.html > the following text is proposed: > "The designations employed and the presentation of country or area > names, > languages and scipts in this registy do not imply the expression of any > opinion whatsoever on the part of the IETF, ICANN and IANA concerning > the legal status of any country, territory, city or area or of its > authorities, or concerning the delimitation of its frontiers or > boundaries, or concerning any cultural, political, economical, > educational sovereign issue. The user of any particular subtag > should consult the corresponding ISO or UN dataset documentation > to determine the exact coverage of statistics for the country > or area entities, of the language or of the script in the dataset. > Various datasets may or may not include coverage of outlying and > overseas areas nor a comprehensive approach of the involved cultural > issues, depending on the type of data and source." > > Discussion: > http://www1.ietf.org/mail-archive/web/ltru/current/msg02856.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02860.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02867.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02869.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02870.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02872.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02873.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02874.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02875.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02878.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02879.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02880.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02881.html Let's see if we can wrap this up. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 19:32:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZfv-0007yX-SQ; Fri, 15 Jul 2005 19:32:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZfu-0007yS-M6 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 19:32:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07072 for ; Fri, 15 Jul 2005 19:32:55 -0400 (EDT) Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dta8p-0003BF-7M for ltru@ietf.org; Fri, 15 Jul 2005 20:02:51 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtZft-0001sr-00 for ltru@ietf.org; Fri, 15 Jul 2005 19:32:57 -0400 Message-ID: <005401c58995$92ca6fc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" Date: Fri, 15 Jul 2005 16:33: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.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [Ltru] [psg.com #1075] WGLC section 3.6 specification requirements for extensions X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - > ------------------------------------------------------------------------- > Message > http://www1.ietf.org/mail-archive/web/ltru/current/msg02855.html > reaises this issue: > > "Section 3.6: What type of RFC is required? Informational or Standards > Track? Community-reviewed, or RFC-Editor published? Does it matter? > It > might be helpful to cite one of the methods described in section 2 of > RFC > 2434 if one is appropriate. Later text in the section says "although > the > IESG MAY change the assignment when approving the RFC", so I have to > believe > that we're talking about either an "IETF Consensus" or "Standards > Action" > document." > > Discussion: > http://www1.ietf.org/mail-archive/web/ltru/current/msg02861.html > http://www1.ietf.org/mail-archive/web/ltru/current/msg02863.html Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 19:34:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZhV-0008Fi-36; Fri, 15 Jul 2005 19:34:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZhT-0008Fd-BX for ltru@megatron.ietf.org; Fri, 15 Jul 2005 19:34:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07125 for ; Fri, 15 Jul 2005 19:34:31 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-kan.bigfish.com ([63.161.60.29] helo=mail7-kan-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtaAM-0003CZ-Sk for ltru@ietf.org; Fri, 15 Jul 2005 20:04:28 -0400 Received: from mail7-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail7-kan-R.bigfish.com (Postfix) with ESMTP id 8CC372014CE for ; Fri, 15 Jul 2005 23:34:25 +0000 (UTC) X-BigFish: VP Received: by mail7-kan (MessageSwitch) id 1121470465517042_26903; Fri, 15 Jul 2005 23:34:25 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail7-kan.bigfish.com (Postfix) with ESMTP id 65E542011AA for ; Fri, 15 Jul 2005 23:34:25 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005071516420638:230659 ; Fri, 15 Jul 2005 16:42:06 -0700 To: ltru@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Fri, 15 Jul 2005 16:31:01 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/15/2005 16:31:27, Serialize complete at 07/15/2005 16:31:27, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/15/2005 04:42:06 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/15/2005 04:42:07 PM, Serialize complete at 07/15/2005 04:42:07 PM Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] Initial Language Subtag 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 Add these to the initial subtag registry? They were just formalized. es-419 zh-cmn zh-cmn-Hant zh-cmn-Hans It's probably most important to add es-419 since it's referenced in the Tags for Identifying Languages draft. Karen Broome _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 20:02:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dta8g-0003ud-CH; Fri, 15 Jul 2005 20:02:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dta8f-0003to-2n for ltru@megatron.ietf.org; Fri, 15 Jul 2005 20:02:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08463 for ; Fri, 15 Jul 2005 20:02:36 -0400 (EDT) Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtabZ-0003rF-GG for ltru@ietf.org; Fri, 15 Jul 2005 20:32:33 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dta8c-0003ho-00 for ltru@ietf.org; Fri, 15 Jul 2005 20:02:38 -0400 Message-ID: <008301c58999$b6b8e7a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Date: Fri, 15 Jul 2005 17:02: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: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Ltru] [psg.com #1076] Additions to Initial Language Subtag 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 Hi - I've assigned an issue number for this in the tracker at https://rt.psg.com/ (user/password "ietf") Randy ----- Original Message ----- > From: > To: > Sent: Friday, July 15, 2005 4:31 PM > Subject: [Ltru] Initial Language Subtag Registry > > Add these to the initial subtag registry? They were just formalized. > > es-419 > zh-cmn > zh-cmn-Hant > zh-cmn-Hans > > It's probably most important to add es-419 since it's referenced in the > Tags for Identifying Languages draft. > > Karen Broome > > > > _______________________________________________ > 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 Jul 15 20:04:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtaA8-0005Gm-3y; Fri, 15 Jul 2005 20: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 1DtaA5-0005A9-P2 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 20:04:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08529 for ; Fri, 15 Jul 2005 20:04: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.43) id 1Dtacx-0003sT-DB for ltru@ietf.org; Fri, 15 Jul 2005 20:34:00 -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 Jul 2005 17:04: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] [psg.com #1067] Further clarify distinction between localecodes and language tags Date: Fri, 15 Jul 2005 17:03:49 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D827@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1067] Further clarify distinction between localecodes and language tags Thread-Index: AcWJlpSOjNlWlVxpSYqgLThBvCT4ZAAAmL/g From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 16 Jul 2005 00:04:02.0326 (UTC) FILETIME=[DF898360:01C58999] 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 think there is no need to add any text; there is already some text (in = the section on extensions) which says that this is somewhat the case. = Implementations that choose to coerce locales (local programming = constructs) from language tags are free to do so. Putting my (W3C) chair hat on: in fact the I18N Core WG is chartered to = produce a document (with the suggestive name "Language Tags and Locale = Identifiers"--suggestive because it implies both a relationship and a = separation of the two concepts) dealing with this precise subject. = Perhaps a RFC 3066ter could reference that work. Appropriate = contributions under W3C IPR policy are invited. (hat off) For now, I don't think there is anything in particular that needs to be = added here. 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: 2005?7?15? 16:27 > To: LTRU Working Group > Subject: [Ltru] [psg.com #1067] Further clarify distinction between > localecodes and language tags >=20 > Hi - >=20 > > = ------------------------------------------------------------------------ > - > > This is in many ways a continuation of the discussion of > > issue #1061. Message > > http://www1.ietf.org/mail-archive/web/ltru/current/msg02701.html > > suggests clarifying that the semantics of language tags are distinct > > from > > those of locale ids, even though they may constructed from some of = the > > same language and country codes > > Discussion: > > http://www1.ietf.org/mail-archive/web/ltru/current/msg02706.html >=20 > Can we quickly resolve this one way or the other? >=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@lists.ietf.org Fri Jul 15 20:04:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtaAm-0005Ut-BF; Fri, 15 Jul 2005 20:04:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtaAl-0005Uo-5h for ltru@megatron.ietf.org; Fri, 15 Jul 2005 20:04:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08558 for ; Fri, 15 Jul 2005 20:04:47 -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.43) id 1Dtadf-0003tX-Tr for ltru@ietf.org; Fri, 15 Jul 2005 20:34:44 -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 Jul 2005 17:04: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] [psg.com #1075] WGLC section 3.6 specification requirementsfor extensions Date: Fri, 15 Jul 2005 17:04:30 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D829@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1075] WGLC section 3.6 specification requirementsfor extensions Thread-Index: AcWJlqqJPmv5BcziTGubBiPMBsq/FgAAzl6w From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 16 Jul 2005 00:04:51.0323 (UTC) FILETIME=[FCBDDCB0:01C58999] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 +1: IETF Consensus using the text I 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 Randy Presuhn > Sent: 2005?7?15? 16:33 > To: LTRU Working Group > Subject: [Ltru] [psg.com #1075] WGLC section 3.6 specification > requirementsfor extensions >=20 > Hi - >=20 > > = ------------------------------------------------------------------------ > - > > Message > > http://www1.ietf.org/mail-archive/web/ltru/current/msg02855.html > > reaises this issue: > > > > "Section 3.6: What type of RFC is required? Informational or = Standards > > Track? Community-reviewed, or RFC-Editor published? Does it = matter? > > It > > might be helpful to cite one of the methods described in section 2 = of > > RFC > > 2434 if one is appropriate. Later text in the section says = "although > > the > > IESG MAY change the assignment when approving the RFC", so I have to > > believe > > that we're talking about either an "IETF Consensus" or "Standards > > Action" > > document." > > > > Discussion: > > http://www1.ietf.org/mail-archive/web/ltru/current/msg02861.html > > http://www1.ietf.org/mail-archive/web/ltru/current/msg02863.html >=20 >=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@lists.ietf.org Fri Jul 15 20:05:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtaBi-0005va-Q9; Fri, 15 Jul 2005 20: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 1DtaBh-0005vV-LL for ltru@megatron.ietf.org; Fri, 15 Jul 2005 20:05:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08606 for ; Fri, 15 Jul 2005 20:05:45 -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.43) id 1Dtaec-0003us-Ay for ltru@ietf.org; Fri, 15 Jul 2005 20:35:42 -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 Jul 2005 17:05: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] [psg.com #1076] Additions to Initial Language Subtag Registry Date: Fri, 15 Jul 2005 17:05:34 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D82A@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1076] Additions to Initial Language Subtag Registry Thread-Index: AcWJmdqeNMEGTe4ESr2cqdHEsIoVzwAACB2g From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 16 Jul 2005 00:05:49.0890 (UTC) FILETIME=[1FA67A20:01C5899A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 +1 Actually es-419 is redundant and only important for completeness to add. = The others ARE important. 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: 2005?7?15? 17:03 > To: ltru@ietf.org > Subject: [Ltru] [psg.com #1076] Additions to Initial Language Subtag > Registry >=20 > Hi - >=20 > I've assigned an issue number for this in the tracker at > https://rt.psg.com/ (user/password "ietf") >=20 > Randy > ----- Original Message ----- > > From: > > To: > > Sent: Friday, July 15, 2005 4:31 PM > > Subject: [Ltru] Initial Language Subtag Registry > > > > Add these to the initial subtag registry? They were just formalized. > > > > es-419 > > zh-cmn > > zh-cmn-Hant > > zh-cmn-Hans > > > > It's probably most important to add es-419 since it's referenced in = the > > Tags for Identifying Languages draft. > > > > Karen Broome > > > > > > > > _______________________________________________ > > 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 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 20:31:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtaaS-000851-WE; Fri, 15 Jul 2005 20:31:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtaaR-0007xn-6w for ltru@megatron.ietf.org; Fri, 15 Jul 2005 20:31:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09447 for ; Fri, 15 Jul 2005 20:31:20 -0400 (EDT) Received: from pop-savannah.atl.sa.earthlink.net ([207.69.195.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtb3L-0004Sm-P8 for ltru@ietf.org; Fri, 15 Jul 2005 21:01:16 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-savannah.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtaaH-0002tv-00 for ltru@ietf.org; Fri, 15 Jul 2005 20:31:13 -0400 Message-ID: <009c01c5899d$b4d73280$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C20D827@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #1067] Further clarify distinction between localecodes and language tags Date: Fri, 15 Jul 2005 17:31: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.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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" ; "LTRU Working Group" > Sent: Friday, July 15, 2005 5:03 PM > Subject: RE: [Ltru] [psg.com #1067] Further clarify distinction between localecodes and language tags > > I think there is no need to add any text; there is already some text > (in the section on extensions) which says that this is somewhat the > case. Implementations that choose to coerce locales (local programming > constructs) from language tags are free to do so. ... As a technical contributor, I don't find what's currently there particularly helpful. It says: |3.6 Extensions and Extensions Namespace | | Extension subtags are those introduced by single-letter subtags other | than 'x'. They are reserved for the generation of identifiers which | contain a language component, and are compatible with applications | that understand language tags. For example, they might be used to | define locale identifiers, which are generally based on language. The first part is fine, but that last sentence is not particularly enlightening. Language is probably the most important thing specified by a locale, but saying locales are "based on language" won't help those who are at all confused about the relationship. I hope this isn't the best example of how we envision extensions being used. I suggest deleting this example (or replacing it with something more enlightening) and adding the following paragraph as the second paragraph in section 2.2.4 (Region Subtag): "Although a language tag constructed from a primary language subtag followed by a region subtag bears a syntactic resemblance to a locale identifier, the two are not to be confused. Locales typically provide information well beyond the identification of the language in use, as they are associated with modifying system and application behaviour." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 20: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 1Dtapk-0001eF-Fr; Fri, 15 Jul 2005 20: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 1Dtapi-0001e7-JE for ltru@megatron.ietf.org; Fri, 15 Jul 2005 20:47:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10650 for ; Fri, 15 Jul 2005 20:47:08 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtbId-0004ya-Nl for ltru@ietf.org; Fri, 15 Jul 2005 21:17:03 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtapY-0003V0-5u; Fri, 15 Jul 2005 17:47:00 -0700 Message-Id: <6.2.1.2.2.20050716021707.0544ed60@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 16 Jul 2005 02:46:48 +0200 To: Karen_Broome@spe.sony.com, "Peter Constable" From: r&d afrac Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer 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 - afrac.org 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 00:55 16/07/2005, Karen_Broome@spe.sony.com wrote: >Yes, I think Randy's findings on the lack of this type of text in other >registries validates our initial gut instinct that this was a political >rather than technical statement Dear Karen, The matter of the RFC 3066 is political. And it is qualified as such. The question is: is it technically necessary. The response is obviously "no". Multiple specialised tags would far better address the need. The langtag only introduce an arbitrary correlation not wanted by the ISO Members. The IETF system makes that in the WG you cannot remove text, just add text. Since I cannot remove the whole text, I just keep proposing correct things. When they oppose they build a good case to refuse the whole thing afterward. I am sorry for that, but there is no other way foreseen by the Internet standard process to kill a detrimental proposition. >-- whether we generally agree with its >content or not. If there is a disclaimer to be made, There is a disclaimer to be made. No one expect it to be perfect (see next comment). My target was just to illustrate the doctrine of this WG. This WG documents an absolute Registry (the Registries quoted by Randy are absolute: they create their codes). Randy, Peter and you show that you do not care about the copyrights of ISO and UN. As if you were removing the copyright mentions when you paste an Open Source piece of code. >I think that IANA/ICANN is the one to draft the text and perhaps it should >be in the context of all registries managed by the organization. Do not worry: this is exactly what will happen. The Registry will be published by the new IANA director (Doug Barton is quitting) under legal responsibility of ICANN and ISOC (IASA). So, there is a long, long legal debate ahead. This particular response about the UN disclaimer will probably be an important point for the lawyers of IANA, ISOC and ISO. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 21:21:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtbNN-0000GP-Ff; Fri, 15 Jul 2005 21:21:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtbNL-0000GG-Q4 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 21:21:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11935 for ; Fri, 15 Jul 2005 21:21:53 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtbqH-0005jA-4Y for ltru@ietf.org; Fri, 15 Jul 2005 21:51:49 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtbNK-00013S-DJ for ltru@ietf.org; Fri, 15 Jul 2005 18:21:54 -0700 Message-Id: <6.2.1.2.2.20050716024828.06097900@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 16 Jul 2005 03:21:42 +0200 To: "LTRU Working Group" From: r&d afrac In-Reply-To: <009c01c5899d$b4d73280$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C20D827@irvmbxw01.quest.com> <009c01c5899d$b4d73280$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Subject: [Ltru] Last call: clarification between language tags and locales X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 02:31 16/07/2005, Randy Presuhn wrote: >"Although a language tag constructed from a primary language subtag >followed by a region subtag bears a syntactic resemblance to a locale >identifier, the two are not to be confused. Locales typically provide >information well beyond the identification of the language in use, as >they are associated with modifying system and application behaviour." Proposed text - as insert for relation with IESG pending an IESG decision: "[Charter has explicitly said that langtags apply to HTML, XML, CLDR, etc. This WG has identified that this point of the Charter is to be requalified. In the case of CLDR, locales can certainly be described in using Langtags as many other language and country related objects and processes, such as publishing, reading, filtering, censoring, exchanging, communicating, classifying text, book, records, identifying expertise in a language, copyrights, etc. etc. However they also have the capacity to document non language related issues such as colors on a display, sound of a loudspeaker, process speed depending on a process pattern, default network addresses, etc.. They also can be partly patented to support patented processes. As such they may have to be identified in refering to patent references the "x-" escape sequence could support woud it not be limited to 8-alpha/num for retro-compatibility with the never used before patent referencing. The WG hesitates to documents langtags for the CLDR and wishes to exclude langtags considerations from its charter, reserving to locale compilers the decision to use langtags as a part of, or an equivalent to, localtag or not. Should localtags be confirmed as directly belonging the Charter, a locale oriented "l-" final extension will be used where all the subsequent dashes would not be part of the Draft ABNF, in order to accept sequences of the form "-c-" included in some of the references to include.]" jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 22:23:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtcKa-0004L9-18; Fri, 15 Jul 2005 22:23:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtcKY-0004Kz-Li for ltru@megatron.ietf.org; Fri, 15 Jul 2005 22:23:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28663 for ; Fri, 15 Jul 2005 22:23:03 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtcnS-0007Yi-FI for ltru@ietf.org; Fri, 15 Jul 2005 22:53:00 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtcKQ-0003Ng-00 for ltru@ietf.org; Fri, 15 Jul 2005 22:22:59 -0400 Message-ID: <001f01c589ad$50e416c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C20D827@irvmbxw01.quest.com><009c01c5899d$b4d73280$7f1afea9@oemcomputer> <6.2.1.2.2.20050716024828.06097900@mail.afrac.org> Date: Fri, 15 Jul 2005 19:23:11 -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 Cc: Subject: [Ltru] [psg.com #1067] Last call: clarification between language tags and locales X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: "r&d afrac" > To: "LTRU Working Group" > Sent: Friday, July 15, 2005 6:21 PM > Subject: [Ltru] Last call: clarification between language tags and locales ... > Proposed text - as insert for relation with IESG pending an IESG decision: > > "[Charter has explicitly said that langtags apply to HTML, XML, CLDR, etc. > This WG has identified that this point of the Charter is to be requalified. > In the case of CLDR, locales can certainly be described in using Langtags > as many other language and country related objects and processes, such as > publishing, reading, filtering, censoring, exchanging, communicating, > classifying text, book, records, identifying expertise in a language, > copyrights, etc. etc. However they also have the capacity to document non > language related issues such as colors on a display, sound of a > loudspeaker, process speed depending on a process pattern, default network > addresses, etc.. They also can be partly patented to support patented > processes. As such they may have to be identified in refering to patent > references the "x-" escape sequence could support woud it not be limited to > 8-alpha/num for retro-compatibility with the never used before patent > referencing. The WG hesitates to documents langtags for the CLDR and wishes > to exclude langtags considerations from its charter, reserving to locale > compilers the decision to use langtags as a part of, or an equivalent to, > localtag or not. Should localtags be confirmed as directly belonging the > Charter, a locale oriented "l-" final extension will be used where all the > subsequent dashes would not be part of the Draft ABNF, in order to accept > sequences of the form "-c-" included in some of the references to include.]" ... As co-chair: (1) For patent-related disclosure requirements, see http://www.ietf.org/rfc/rfc3979.txt (2) Specifying locales is clearly beyond our scope. As a technical contributor, I think Jefsey's proposed addition would be counterproductive. reducing rather than improving the document's intellegibility. Consequently, I strongly oppose its inclusion. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 15 22:23:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtcKa-0004LX-75; Fri, 15 Jul 2005 22:23:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtcKZ-0004L4-57 for ltru@megatron.ietf.org; Fri, 15 Jul 2005 22:23:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28670 for ; Fri, 15 Jul 2005 22:23:04 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtcnS-0007Z6-To for ltru@ietf.org; Fri, 15 Jul 2005 22:53:01 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtcKV-0003PO-00 for ltru@ietf.org; Fri, 15 Jul 2005 22:23:04 -0400 Message-ID: <002001c589ad$547db840$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.1.2.2.20050716021707.0544ed60@mail.afrac.org> Date: Fri, 15 Jul 2005 19:23:17 -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: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UN disclaimer X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: "r&d afrac" > To: ; "Peter Constable" > Cc: > Sent: Friday, July 15, 2005 5:46 PM > Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer ... > The IETF system makes that in the WG you cannot remove text, just add text. False. There have been proposals to delete specific text, and some have been adopted by this WG. > Since I cannot remove the whole text, I just keep proposing correct things. > When they oppose they build a good case to refuse the whole thing > afterward. I am sorry for that, but there is no other way foreseen by the > Internet standard process to kill a detrimental proposition. False. For example, a WG can request that an item be removed from its charter. This has happened in the past. ... > There is a disclaimer to be made. No one expect it to be perfect (see next > comment). My target was just to illustrate the doctrine of this WG. This > WG documents an absolute Registry (the Registries quoted by Randy are > absolute: they create their codes). Randy, Peter and you show that you do > not care about the copyrights of ISO and UN. As if you were removing the > copyright mentions when you paste an Open Source piece of code. False. If we were imitating the structure of the ISO or UN directories, such a claim might almost be plausible. With a differing organization of data, the omission of some elements, the addition of other elements, and a differing scope of application, any claim of copyright infringement would be rather far-fetched. If you have experts in IPR law who would like to opine on this topic, please forward the mailing list address to them. > >I think that IANA/ICANN is the one to draft the text and perhaps it should > >be in the context of all registries managed by the organization. > > Do not worry: this is exactly what will happen. The Registry will be > published by the new IANA director (Doug Barton is quitting) under legal > responsibility of ICANN and ISOC (IASA). So, there is a long, long legal > debate ahead. This particular response about the UN disclaimer will > probably be an important point for the lawyers of IANA, ISOC and ISO. ... Out of scope. This (if it exists) is not our problem solve. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 02:25:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtg7C-0006EK-56; Sat, 16 Jul 2005 02:25:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtg7A-0006EF-Kl for ltru@megatron.ietf.org; Sat, 16 Jul 2005 02:25:32 -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 CAA27789 for ; Sat, 16 Jul 2005 02:25: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 <20050716062458.EJHY29002.mta9.adelphia.net@DEWELL> for ; Sat, 16 Jul 2005 02:24:58 -0400 Message-ID: <000f01c589cf$103a02c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050715161238.RSFU5765.edge3.adelphia.net@megatron.ietf.org> Date: Fri, 15 Jul 2005 23:24: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 Cc: Subject: [Ltru] Re: UN region code list change X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: >>> My concern is not with this particular change, but with the >>> practice of making "silent" changes with no announcement, >> >> Yes, that's a PITA. I guess if the tag reviewer misses any >> future modifications somebody will try to register them. > > Most of the time it won't matter, since going forward M.49 codes will > rarely be inserted into the registry. Basically true, for codes that represent countries. Early this year they split one macrogeographical code into two. I have no idea how often that sort of thing happens, but in the future it will result in two new 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@lists.ietf.org Sat Jul 16 02:38:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtgJk-0004vs-1c; Sat, 16 Jul 2005 02:38:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtgJi-0004uP-EN for ltru@megatron.ietf.org; Sat, 16 Jul 2005 02:38:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28339 for ; Sat, 16 Jul 2005 02:38:28 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtgmg-0004uE-C9 for ltru@ietf.org; Sat, 16 Jul 2005 03:08:26 -0400 Received: from h-68-165-6-174.snvacaid.dynamic.covad.net ([68.165.6.174] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtgJg-00068P-00 for ltru@ietf.org; Sat, 16 Jul 2005 02:38:28 -0400 Message-ID: <001601c589d0$fdb927a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050715161238.RSFU5765.edge3.adelphia.net@megatron.ietf.org> <000f01c589cf$103a02c0$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: UN region code list change Date: Fri, 15 Jul 2005 23:38:34 -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: 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 Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Friday, July 15, 2005 11:24 PM > Subject: [Ltru] Re: UN region code list change ... > Basically true, for codes that represent countries. Early this year > they split one macrogeographical code into two. I have no idea how > often that sort of thing happens, but in the future it will result in > two new subtags. ... I hope you mean two *potential* new subtags. There would be no reason to register either of the new codes as language subtags unless they were useful for distinguishing language varieties. Presumably the original code could continue to be used as a subtag, particularly if it more accurately characterized some linguistic phenomenon of interest. One of our objectives here was to insulate the users of language tags from churn in the sources. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 03:25:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dth3X-0004Ii-7O; Sat, 16 Jul 2005 03:25:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dth3V-0004IY-Qj for ltru@megatron.ietf.org; Sat, 16 Jul 2005 03:25:49 -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 DAA00524 for ; Sat, 16 Jul 2005 03:25:48 -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 <20050716072518.LSMI19267.mta10.adelphia.net@DEWELL> for ; Sat, 16 Jul 2005 03:25:18 -0400 Message-ID: <007601c589d7$79f80b00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050715174012.JCPA16251.aamta2.adelphia.net@megatron.ietf.org> Date: Sat, 16 Jul 2005 00:24: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 Cc: Subject: [Ltru] Re: Last call: IANA adaptation of the UN disclaimer X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > Sorry, I hadn't looked at the syntax for the registry for a while and > was thinking it was possible to include comments -- indeed, I thought > we were including some comments describing the fields of records, but > that was probably something from before the switch to record jar > format. Hence I was thinking this could be included as introductory > comments. I guess since the syntax for the registry doesn't allow for > comments, the only option would be somewhere in draft-registry. You're right, the old semicolon-delimited and bar-delimited registry formats did have comments. Everything appearing on a line after # was a comment, and there was a rather large comment block at the top of those old registries explaining what all the fields were for. It's quite a bit more self-explanatory now, with the record-jar format. I would tend to agree that IF this big, defensive-sounding legal disclaimer is deemed necessary, it should be placed in one of the RFCs (probably 'registry', not 'initial') and not in 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@lists.ietf.org Sat Jul 16 03:26:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dth44-0004Xp-Ca; Sat, 16 Jul 2005 03:26:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dth43-0004Xk-0x for ltru@megatron.ietf.org; Sat, 16 Jul 2005 03:26:23 -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 DAA00538 for ; Sat, 16 Jul 2005 03:26:21 -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 <20050716072551.FFWA29002.mta9.adelphia.net@DEWELL> for ; Sat, 16 Jul 2005 03:25:51 -0400 Message-ID: <007701c589d7$9218cd00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050715233407.XMTA19686.edge2.adelphia.net@megatron.ietf.org> Date: Sat, 16 Jul 2005 00:25:40 -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: UN region code list change X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > Based on the comments in this thread, I believe there is a rough > consensus that no action is needed on this issue. Sorry, I should not have given the impression that I thought any action was needed. I was just whining out loud about the UNSD policy of not announcing these changes publicly. Whoever ends up maintaining the registry is going to have to use a tool like WatchThatPage, or they may never find out about this type of change. -- 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 Jul 16 03:26:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dth4U-0004ZF-1n; Sat, 16 Jul 2005 03:26:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dth4S-0004ZA-Ao for ltru@megatron.ietf.org; Sat, 16 Jul 2005 03:26:48 -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 DAA00567 for ; Sat, 16 Jul 2005 03:26:46 -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 <20050716072616.LSTS19267.mta10.adelphia.net@DEWELL> for ; Sat, 16 Jul 2005 03:26:16 -0400 Message-ID: <007801c589d7$a162ae20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050715233407.XMTA19686.edge2.adelphia.net@megatron.ietf.org> Date: Sat, 16 Jul 2005 00:26: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: Subject: [Ltru] Re: [psg.com #1067] Further clarify distinction between locale codes and 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: >> This is in many ways a continuation of the discussion of >> issue #1061. Message >> http://www1.ietf.org/mail-archive/web/ltru/current/msg02701.html >> suggests clarifying that the semantics of language tags are distinct >> from >> those of locale ids, even though they may constructed from some of >> the same language and country codes >> Discussion: >> http://www1.ietf.org/mail-archive/web/ltru/current/msg02706.html > > Can we quickly resolve this one way or the other? My opinion is that this is out of scope. -- 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 Jul 16 03:27:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dth55-0004d1-Fy; Sat, 16 Jul 2005 03: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 1Dth54-0004cu-5t for ltru@megatron.ietf.org; Sat, 16 Jul 2005 03:27:26 -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 DAA00609 for ; Sat, 16 Jul 2005 03:27:24 -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 <20050716072654.FGMB29002.mta9.adelphia.net@DEWELL> for ; Sat, 16 Jul 2005 03:26:54 -0400 Message-ID: <007901c589d7$b8460e20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050716012427.OGVF31309.edge6.adelphia.net@megatron.ietf.org> Date: Sat, 16 Jul 2005 00:26: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: Initial Language Subtag 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 Karen Broome wrote: > Add these to the initial subtag registry? They were just formalized. > > es-419 > zh-cmn > zh-cmn-Hant > zh-cmn-Hans I've already added them. You'll see them in the next revision. > It's probably most important to add es-419 since it's referenced in > the Tags for Identifying Languages draft. They're equally important. "es-419" is redundant; the others are grandfathered (but would become redundant under a presumed future 3066ter which included 'cmn' as an extended-language subtag under 'zh'). My impression is that since we already have an agreement (written into draft-registry) to include all tags from the RFC 3066 registry at Date B as either grandfathered or redundant, we shouldn't actually need a ticket to add these four. Since Randy has assigned one, I strongly recommend we mark it "resolved" and move along. The next question is whether we should deprecate "zh-guoyu" in favor of "zh-cmn" as well. The text in the approved registration form says: "It is understood that the 'guoyu' dialect tag will be deprecated. This is a formal application for use of the replacement tag 'cmn'. This is intended to describe the same Mandarin Chinese dialect that was previously described with the '-guoyu' extension." I interpret that as a signal to this WG to deprecate the grandfathered tag "zh-guoyu" as of the date of approval of "zh-cmn", namely 2005-07-15, and give it a Preferred-Value of "zh-cmn". That probably does need to be a ticket. -- 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 Jul 16 08:28:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlm7-0005Xp-SL; Sat, 16 Jul 2005 08:28:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlm6-0005Wg-F9 for ltru@megatron.ietf.org; Sat, 16 Jul 2005 08:28:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11965 for ; Sat, 16 Jul 2005 08:28:07 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtmF4-0005Am-6z for ltru@ietf.org; Sat, 16 Jul 2005 08:58:08 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6GCRhI16467; Sat, 16 Jul 2005 21:27:43 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id ad24fa70_f5f6_11d9_9e5a_0030482532aa_9635; Sat, 16 Jul 2005 21:39:39 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO000407; 16 Jul 05 21:33:28 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 16 Jul 05 21:33:05 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.250.2) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG000405; 16 Jul 05 21:32:54 +0900 Message-Id: <6.0.0.20.2.20050716211308.07587d80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 16 Jul 2005 21:14:11 +0900 To: "Randy Presuhn" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales In-Reply-To: <001f01c589ad$50e416c0$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C20D827@irvmbxw01.quest.com> <009c01c5899d$b4d73280$7f1afea9@oemcomputer> <6.2.1.2.2.20050716024828.06097900@mail.afrac.org> <001f01c589ad$50e416c0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 I agree with Randy both as a chair and as a technical contributor. Regards, Martin. At 11:23 05/07/16, Randy Presuhn wrote: >Hi - > >> From: "r&d afrac" >> To: "LTRU Working Group" >> Sent: Friday, July 15, 2005 6:21 PM >> Subject: [Ltru] Last call: clarification between language tags and locales >... >> Proposed text - as insert for relation with IESG pending an IESG decision: >> >> "[Charter has explicitly said that langtags apply to HTML, XML, CLDR, etc. >> This WG has identified that this point of the Charter is to be requalified. >> In the case of CLDR, locales can certainly be described in using Langtags >> as many other language and country related objects and processes, such as >> publishing, reading, filtering, censoring, exchanging, communicating, >> classifying text, book, records, identifying expertise in a language, >> copyrights, etc. etc. However they also have the capacity to document non >> language related issues such as colors on a display, sound of a >> loudspeaker, process speed depending on a process pattern, default network >> addresses, etc.. They also can be partly patented to support patented >> processes. As such they may have to be identified in refering to patent >> references the "x-" escape sequence could support woud it not be limited to >> 8-alpha/num for retro-compatibility with the never used before patent >> referencing. The WG hesitates to documents langtags for the CLDR and wishes >> to exclude langtags considerations from its charter, reserving to locale >> compilers the decision to use langtags as a part of, or an equivalent to, >> localtag or not. Should localtags be confirmed as directly belonging the >> Charter, a locale oriented "l-" final extension will be used where all the >> subsequent dashes would not be part of the Draft ABNF, in order to accept >> sequences of the form "-c-" included in some of the references to include.]" >... > >As co-chair: >(1) For patent-related disclosure requirements, see >http://www.ietf.org/rfc/rfc3979.txt >(2) Specifying locales is clearly beyond our scope. > >As a technical contributor, I think Jefsey's proposed addition would be >counterproductive. reducing rather than improving the document's >intellegibility. Consequently, I strongly oppose its inclusion. > >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 Sat Jul 16 08:28:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlm8-0005YD-19; Sat, 16 Jul 2005 08:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlm6-0005WV-FR for ltru@megatron.ietf.org; Sat, 16 Jul 2005 08:28:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11966 for ; Sat, 16 Jul 2005 08:28:07 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtmF4-0005Al-7o for ltru@ietf.org; Sat, 16 Jul 2005 08:58:08 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6GCRhC21844; Sat, 16 Jul 2005 21:27:43 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id ace071c0_f5f6_11d9_9e5a_0030482532aa_9635; Sat, 16 Jul 2005 21:39:39 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO000406; 16 Jul 05 21:33:27 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 16 Jul 05 21:33:05 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.250.2) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0003FE; 16 Jul 05 21:32:53 +0900 Message-Id: <6.0.0.20.2.20050716205822.07588e30@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 16 Jul 2005 21:09:46 +0900 To: "Randy Presuhn" , From: Martin Duerst Subject: Re: [Ltru] Last call: IANA adaptation of the UN disclaimer In-Reply-To: <001801c5897f$93920780$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C20D6DB@irvmbxw01.quest.com> <001801c5897f$93920780$7f1afea9@oemcomputer> 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: b4a0a5f5992e2a4954405484e7717d8c 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 [chair hat off] I have to agree with Randy. Besides his arguments, I'd also like to mention that neither RFC 1766 nor RFC 3066 had any such disclaimer. Also, I'm affraid that if somebody with a traditional IETF background finds this paragraph, we might get some serious IETF Last Call comments. Also, if (as JFC thinks) this is something for the IANA/ ICANN/watever lawyers, then it's best if we keep out of it. If asked for, we can point to the various text proposals in the mailing list archive. Regards, Martin. At 05:55 05/07/16, Randy Presuhn wrote: >Hi - > >> From: "Addison Phillips" >> To: "Peter Constable" ; >> Sent: Friday, July 15, 2005 11:29 AM >> Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer >> >> The purpose and point of this text I agree with, but the form of the text >> is not in keeping with the terminology or form of the rest of the document. >> It is nearly incomprehensible. >> >> How about replacing your second paragraph with: >> >> The presence, absence or contents of subtags and their associated fields >> in the registry do not and should not be taken to imply an opinion on the >part of >> the IETF, ICANN and IANA concerning the legal status of any language, script, >> country, territory, region, or language variation. Nor should they be taken to >> endorse any particular position regarding the legal status, authority, >frontiers, >> boundaries, or cultural, political, economical, or educational policies of any >> particular country or region. This includes any issues pertaining to the >identity >> or usage of any language or script within any country or region. >... > >As a technical contributor, I think there adding this text contributes no value >to the document, and could in the longer term be harmful, regardless of >its benign intent and content. > >None of the other IANA registries I've looked at has anything like this. >As a very concrete example, the enterprise number registry at >http://www.iana.org/assignments/enterprise-numbers doesn't have >lawerly verbiage about trademarks or the legal status of enterprise names. >Similarly, http://www.iana.org/assignments/ianaaddressfamilynumbers-mib >doesn't fret about trademarks. Not even http://www.iana.org/assignments/idn/ >goes through such hand-wringing. I think adding material like this would >set a very bad precedent, because it could lead to folks misconstruing >the absence of such disclaimers in other IANA-maintained registries. > >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 Sat Jul 16 08:28:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlm8-0005Ym-7U; Sat, 16 Jul 2005 08:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlm6-0005XU-FW for ltru@megatron.ietf.org; Sat, 16 Jul 2005 08:28:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11968 for ; Sat, 16 Jul 2005 08:28:07 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtmF4-0005Aj-7n for ltru@ietf.org; Sat, 16 Jul 2005 08:58:08 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6GCRgI16459; Sat, 16 Jul 2005 21:27:42 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id ac4e7fae_f5f6_11d9_9e5a_0030482532aa_9635; Sat, 16 Jul 2005 21:39:38 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO000403; 16 Jul 05 21:33:26 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 16 Jul 05 21:32:54 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.250.2) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0003FC; 16 Jul 05 21:32:52 +0900 Message-Id: <6.0.0.20.2.20050716203942.0759bdf0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 16 Jul 2005 20:41:32 +0900 To: "Addison Phillips" , From: Martin Duerst Subject: RE: [Ltru] Re: last call: language tag usage In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C20D601@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C20D601@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: 9466e0365fc95844abaf7c3f15a05c7d 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 [chair hat off] I see the idea with 'help', i.e. that it can avoid misunderstandings, but I'm affraid that it will lead to a lot of questions in the other direction, such as "help? so what else do I need to do?". So I'm rather sceptical about this change. Regards, Martin. At 01:20 05/07/16, Addison Phillips wrote: >content-class: urn:content-classes:message >Content-Type: text/plain;charset="utf-8" > >Okay. We still have the problem of the prohibition on non-natural language >identification, so the full paragraph, adapted from the "long version", >post-edit reads: > >The language tag is used to help identify which language is being >spoken, written, signed, or otherwise signaled for the purpose of >communication. The language in question might include a constructed or >artificially designed language, but excludes languages not intended >primarily for human communication, such as programming or computer languages. > >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@lists.ietf.org Sat Jul 16 08:28:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlm8-0005ZQ-En; Sat, 16 Jul 2005 08:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlm6-0005Wx-Fw for ltru@megatron.ietf.org; Sat, 16 Jul 2005 08:28:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11962 for ; Sat, 16 Jul 2005 08:28:07 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtmF4-0005Ae-7L for ltru@ietf.org; Sat, 16 Jul 2005 08:58:08 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6GCRbC21827; Sat, 16 Jul 2005 21:27:37 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id a9af4e04_f5f6_11d9_9e5a_0030482532aa_9635; Sat, 16 Jul 2005 21:39:34 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0003FF; 16 Jul 05 21:33:22 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 16 Jul 05 21:32:53 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.250.2) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0003F8; 16 Jul 05 21:32:48 +0900 Message-Id: <6.0.0.20.2.20050715182019.09497ec0@itmail.it.aoyama.ac.jp> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 15 Jul 2005 18:20:32 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Last Call Comment: draft-ietf-ltru-initial-02.txt In-Reply-To: <00a401c5890d$92e3a5e0$030aa8c0@DEWELL> References: <20050714213301.LHUB27741.edge3.adelphia.net@megatron.ietf.org> <00a401c5890d$92e3a5e0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Fine with me, too. Martin. At 16:19 05/07/15, Doug Ewell wrote: >Randy Presuhn wrote: > >> Here are some suggested replacement words: >> The following code elements from [UN-M.49] were not associated >> with [ISO3166-1] alpha-2 code elements. Consequently, they were >> not assigned as >> subtags in the initial Language Subtag Registry, but are valid >> candidates for registration as region subtags, using the process in >> [I-D.ietf-ltru-registry]: > >I support Randy's proposed wording as a response to Scott's concern. > >-- >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 Sat Jul 16 08:28:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlm8-0005Zt-Jj; Sat, 16 Jul 2005 08:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtlm6-0005XT-FB for ltru@megatron.ietf.org; Sat, 16 Jul 2005 08:28:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11970 for ; Sat, 16 Jul 2005 08:28:07 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtmF4-0005Ak-7o for ltru@ietf.org; Sat, 16 Jul 2005 08:58:08 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6GCRgC21840; Sat, 16 Jul 2005 21:27:42 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id ac9648f2_f5f6_11d9_9e5a_0030482532aa_9635; Sat, 16 Jul 2005 21:39:39 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO000404; 16 Jul 05 21:33:27 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 16 Jul 05 21:32:54 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.250.2) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0003FD; 16 Jul 05 21:32:53 +0900 Message-Id: <6.0.0.20.2.20050716205211.0759cec0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 16 Jul 2005 20:53:02 +0900 To: "Addison Phillips" , "Peter Constable" , From: Martin Duerst Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C20D7C6@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C20D7C6@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: c0bedb65cce30976f0bf60a0a39edea4 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 At 06:00 05/07/16, Addison Phillips wrote: >You'll notice that Karen's identity issue was addressed by my edit. > >I'm not sure, now that I think about it, that your proposed location makes sense. > >Let me explain. Thanks for these explanations. Would it be possible to actually include the three sentences about sections 2-4 in the introduction, if that hasn't already be done? Regards, Martin. >Somewhere about six edits ago I heavily reformatted the document, moving >sections around. The document now falls into three main logical sections. >It is useful to enumerate the document's logical structure anyway, so I'll >take a moment to do so: > >Section 2 covers the syntax and format of language tags themselves. It is >only concerned with the form of language tags (the ABNF, rules for >formation of tags, language tag sources, and the like). > >Section 3 covers the format and operation of the registry, including >registration and maintenance and the like. > >Section 4 covers working with language tags (considerations for choosing >which one you want for your application; what they "mean", and so forth) > >I believe a statement of this nature probably fits best logically into >Section 4 and specifically into Section 4.2 (Meaning of the Language Tag), >where my proposed paragraph could be called out as a "Note:" following the >bullet list. > >I believe/hope I addressed Karen's concerns in my edit. > >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: 2005?7?15? 11:37 >> To: ltru@ietf.org >> Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer >> >> I'm OK with your alternate wording, modulo my response to your question >> of where this should go, and Karen's comment on "identity". >> >> >> 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 Jul 16 13:23:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtqO2-000611-HW; Sat, 16 Jul 2005 13:23:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtqO1-00060r-4x for ltru@megatron.ietf.org; Sat, 16 Jul 2005 13:23:37 -0400 Received: from mta5.adelphia.net (mta5.adelphia.net [68.168.78.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15536 for ; Sat, 16 Jul 2005 13:23: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 <20050716170037.GMYZ14360.mta13.adelphia.net@DEWELL> for ; Sat, 16 Jul 2005 13:00:37 -0400 Message-ID: <00b801c58a27$ca0c79a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050716012427.OGVF31309.edge6.adelphia.net@megatron.ietf.org> Date: Sat, 16 Jul 2005 09:59: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: Last call: clarification between language tags and locales X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 oppose the addition of the proposed text in its entirety, for numerous content-related reasons. -- 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 Jul 16 13:23:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtqO5-00061P-PN; Sat, 16 Jul 2005 13:23:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtqO1-00060w-LJ for ltru@megatron.ietf.org; Sat, 16 Jul 2005 13:23:37 -0400 Received: from mta5.adelphia.net (mta5.adelphia.net [68.168.78.187]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15539 for ; Sat, 16 Jul 2005 13:23: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 <20050716165207.ZBAA19267.mta10.adelphia.net@DEWELL> for ; Sat, 16 Jul 2005 12:52:07 -0400 Message-ID: <00a501c58a26$969ba420$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050716122931.DRTE2895.edge5.adelphia.net@megatron.ietf.org> Date: Sat, 16 Jul 2005 09:51: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 Cc: Subject: [Ltru] Re: UN region code list change X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: >> Basically true, for codes that represent countries. Early this year >> they split one macrogeographical code into two. I have no idea how >> often that sort of thing happens, but in the future it will result in >> two new subtags. > > I hope you mean two *potential* new subtags. There would be no reason > to register either of the new codes as language subtags unless they > were useful for distinguishing language varieties. My reading of Section 3.2 of draft-registry is that such new codes would be added more or less automatically, unless there were a conflict with existing subtags. The alternative would be to require ietf-languages to determine whether a newly assigned UN code is "useful for distinguishing language varieties." I don't know if they or we are in a position to do that. Certainly we have assumed that to be the case for all of the existing codes, including 001, because we add them all to the initial registry. > Presumably the original code could continue to be used as a subtag, > particularly if it more accurately characterized some linguistic > phenomenon of interest. Of course, the original subtag is not removed or deprecated. Let's use the recent case of "South-central Asia." Originally (for our purposes) this was one region, coded as 062. Recently the UNSD split this into "Southern Asia," codes as 034, and "Central Asia," coded as 143. If this split had occurred after Date B, the Reviewer, upon seeing that 034 and 143 did not conflict with any existing subtags, would presumably add them. Note that region subtag 062 would remain in the registry, and users who regard "South-central Asia" as most accurately characterizing their linguistic phenomonon would be able to continue using that. (There is also 142 "Asia" for those who prefer that.) Because this split happened *before* Date B, and the rules are to register only those UN codes valid as of Date B, we don't actually register 062. Doing so is not necessarily for backward compatibility of language tags, because unlike ISO 639 and 3166 codes, these UN thingies were not previously valid in language tags. > One of our objectives here was to insulate the users of language tags > from churn in the sources. We insulate them from the worst kinds of churn: codes that are changed and deleted, thus invalidating existing tags, and (worst of all) codes that change their meaning. We don't necessarily insulate them from newly created codes. Those actually give them more flexibility. -- 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 Jul 16 14:14:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrBA-0005oJ-8N; Sat, 16 Jul 2005 14:14:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrB4-0005mE-Mc for ltru@megatron.ietf.org; Sat, 16 Jul 2005 14:14:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17598 for ; Sat, 16 Jul 2005 14:14:16 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtrIo-0007ua-7Z for ltru@ietf.org; Sat, 16 Jul 2005 14:22:19 -0400 Received: from h-68-166-38-137.snvacaid.dynamic.covad.net ([68.166.38.137] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dtqpi-0006no-00 for ltru@ietf.org; Sat, 16 Jul 2005 13:52:14 -0400 Message-ID: <002001c58a2f$2382d540$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C20D846@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between language tags and locales Date: Sat, 16 Jul 2005 10:52:29 -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: cab78e1e39c4b328567edb48482b6a69 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 - As co-chair: Ok, there seems to be no support for (and strong opposition to) Jefsey's proposed addition. I see no need for further discussion of it unless someone else out there thinks it's a really good idea. As technical contributor: Can we get back to the original issues in this discussion? Addison had said: > I think there is no need to add any text; there is already some text > (in the section on extensions) which says that this is somewhat the > case. Implementations that choose to coerce locales (local programming > constructs) from language tags are free to do so. I responded by saying that I don't find what's currently there particularly helpful. The current i-d says: |3.6 Extensions and Extensions Namespace | | Extension subtags are those introduced by single-letter subtags other | than 'x'. They are reserved for the generation of identifiers which | contain a language component, and are compatible with applications | that understand language tags. For example, they might be used to | define locale identifiers, which are generally based on language. The first part is fine, but that last sentence is not particularly enlightening. Language is probably the most important thing specified by a locale, but saying locales are "based on language" won't help those who are at all confused about the relationship. I hope this isn't the best example of how we envision extensions being used. I suggest deleting this example (or replacing it with something more enlightening) and adding the following paragraph as the second paragraph in section 2.2.4 (Region Subtag). This is *revised* from my earlier proposal: "Although a language tag constructed from a primary language subtag followed by a region subtag bears a syntactic resemblance to a locale identifier, their semantics and usage are different." Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 14:15:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrCX-0006JP-GA; Sat, 16 Jul 2005 14:15:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrCW-0006J2-7Z for ltru@megatron.ietf.org; Sat, 16 Jul 2005 14:15:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18844 for ; Sat, 16 Jul 2005 14:15:44 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtpz2-00059Q-4s for ltru@ietf.org; Sat, 16 Jul 2005 12:57:49 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtpVu-0006ny-Bo; Sat, 16 Jul 2005 09:27:42 -0700 Message-Id: <6.2.1.2.2.20050716095906.04863eb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 16 Jul 2005 18:27:29 +0200 To: "Randy Presuhn" From: r&d afrac Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UN disclaimer In-Reply-To: <002001c589ad$547db840$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050716021707.0544ed60@mail.afrac.org> <002001c589ad$547db840$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 - afrac.org X-Spam-Score: 0.0 (/) 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 Randy, Half reading or constantly misconstruing what I say helps me a lot with reviewers. On 04:23 16/07/2005, Randy Presuhn said: > > The IETF system makes that in the WG you cannot remove text, just add text. >False. There have been proposals to delete specific text, and some have >been adopted by this WG. "A is not possible"/"Yes AB is possible" is usefull for me with legal reviewers. > > Since I cannot remove the whole text, I just keep proposing correct things. > > When they oppose they build a good case to refuse the whole thing > > afterward. I am sorry for that, but there is no other way foreseen by the > > Internet standard process to kill a detrimental proposition. > >False. For example, a WG can request that an item be removed from its >charter. >This has happened in the past. "AB is not possible"/"Yes B is possible" is good too. All the more than you take as an example my ignorance of a procedure I proposed (you ... oppose) in the next mail. > > There is a disclaimer to be made. No one expect it to be perfect (see next > > comment). My target was just to illustrate the doctrine of this WG. This > > WG documents an absolute Registry (the Registries quoted by Randy are > > absolute: they create their codes). Randy, Peter and you show that you do > > not care about the copyrights of ISO and UN. As if you were removing the > > copyright mentions when you paste an Open Source piece of code. > >False. If we were imitating the structure of the ISO or UN directories, such >a claim might almost be plausible. With a differing organization of data, >the omission of some elements, the addition of other elements, >and a differing scope of application, any claim of copyright infringement >would be rather far-fetched. Thank you for so exactly describing your intent to tamper with the intended usage of the codes. >If you have experts in IPR law who would like to opine on this topic, >please forward the mailing list address to them. I described many times my policy and my reasons. Each thing in its time, and budget. > > >I think that IANA/ICANN is the one to draft the text and perhaps it should > > >be in the context of all registries managed by the organization. > > > > Do not worry: this is exactly what will happen. The Registry will be > > published by the new IANA director (Doug Barton is quitting) under legal > > responsibility of ICANN and ISOC (IASA). So, there is a long, long legal > > debate ahead. This particular response about the UN disclaimer will > > probably be an important point for the lawyers of IANA, ISOC and ISO. > >Out of scope. >This (if it exists) is not our problem solve. Thank you for acknowledging this. You just saved hours of legal demonstration. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 14:15:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrCa-0006Kw-HH; Sat, 16 Jul 2005 14:15:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrCX-0006JK-OX for ltru@megatron.ietf.org; Sat, 16 Jul 2005 14:15:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18851 for ; Sat, 16 Jul 2005 14:15:45 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtpz2-00059R-52 for ltru@ietf.org; Sat, 16 Jul 2005 12:57:49 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtpVv-0006ny-NS; Sat, 16 Jul 2005 09:27:44 -0700 Message-Id: <6.2.1.2.2.20050716170915.04471420@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 16 Jul 2005 17:21:33 +0200 To: Martin Duerst , "Randy Presuhn" , From: r&d afrac Subject: Re: [Ltru] Last call: IANA adaptation of the UN disclaimer In-Reply-To: <6.0.0.20.2.20050716205822.07588e30@localhost> References: <634978A7DF025A40BFEF33EB191E13BC0C20D6DB@irvmbxw01.quest.com> <001801c5897f$93920780$7f1afea9@oemcomputer> <6.0.0.20.2.20050716205822.07588e30@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 At 14:09 16/07/2005, Martin Duerst wrote: >[chair hat off] >I have to agree with Randy. Besides his arguments, I'd also >like to mention that neither RFC 1766 nor RFC 3066 had any >such disclaimer. They did not confuse ISO 3166 and UN M.49. But I agree that RFC 3066 was a huge political mistake. However its lose application permitted it to survive. The ethical problem is with all those who use it. >Also, I'm affraid that if somebody with a >traditional IETF background finds this paragraph, we might >get some serious IETF Last Call comments. The pity is that they accepted RFC 3066. Could be a good IETF obituary. >Also, if (as JFC thinks) this is something for the IANA/ >ICANN/watever lawyers, then it's best if we keep out of it. >If asked for, we can point to the various text proposals in >the mailing list archive. Here I must disagree: what lawyers will want is to make sure the doctrine of the document is consistent with its political involvement and legal obligations/infrigements. You cannot just do anything you want and then expect lawyers to save your day. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 14:16:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrDJ-0006bK-1g; Sat, 16 Jul 2005 14:16:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrDI-0006bA-Gr for ltru@megatron.ietf.org; Sat, 16 Jul 2005 14:16:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19440 for ; Sat, 16 Jul 2005 14:16:32 -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.43) id 1DtpUQ-0005ZT-H7 for ltru@ietf.org; Sat, 16 Jul 2005 12:26:10 -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 Jul 2005 08:56: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] Last call: IANA adaptation of the UN disclaimer Date: Sat, 16 Jul 2005 08:55:59 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D847@irvmbxw01.quest.com> Thread-Topic: [Ltru] Last call: IANA adaptation of the UN disclaimer Thread-Index: AcWKAgvaKjkqwvltS7e1Z1zzCFlhEAAG0OYg From: "Addison Phillips" To: "Martin Duerst" , "Randy Presuhn" , X-OriginalArrivalTime: 16 Jul 2005 15:56:00.0204 (UTC) FILETIME=[DC7208C0:01C58A1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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 Might I suggest: I think that including a giant piece of policy on behalf of IETF, ICANN, = and IANA is probably inappropriate. However, I *can* see draft-registry = making the statement that the registration process does not endorse any = particular position and that registrations will be considered on an = equal basis. The resulting text would be more useful. Perhaps: Registration requests are each considered on their own merits, based = on the need to identify a language. The presence, absence or contents of = any particular subtag and its associated fields in the registry do not = imply a position on the legal status of any language, script, country, = territory, region, or language variation. Nor do they endorse any = particular position regarding the legal status, authority, frontiers, = boundaries, or policies of any particular country or region. This = includes any issues pertaining to the identity or usage of any language = or script within any country or region. 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 Martin Duerst > Sent: 2005?7?16? 5:10 > To: Randy Presuhn; ltru@ietf.org > Subject: Re: [Ltru] Last call: IANA adaptation of the UN disclaimer >=20 > [chair hat off] >=20 > I have to agree with Randy. Besides his arguments, I'd also > like to mention that neither RFC 1766 nor RFC 3066 had any > such disclaimer. Also, I'm affraid that if somebody with a > traditional IETF background finds this paragraph, we might > get some serious IETF Last Call comments. >=20 > Also, if (as JFC thinks) this is something for the IANA/ > ICANN/watever lawyers, then it's best if we keep out of it. > If asked for, we can point to the various text proposals in > the mailing list archive. >=20 > Regards, Martin. >=20 > At 05:55 05/07/16, Randy Presuhn wrote: > >Hi - > > > >> From: "Addison Phillips" > >> To: "Peter Constable" ; > >> Sent: Friday, July 15, 2005 11:29 AM > >> Subject: RE: [Ltru] Last call: IANA adaptation of the UN = disclaimer > >> > >> The purpose and point of this text I agree with, but the form of = the > text > >> is not in keeping with the terminology or form of the rest of the > document. > >> It is nearly incomprehensible. > >> > >> How about replacing your second paragraph with: > >> > >> The presence, absence or contents of subtags and their = associated > fields > >> in the registry do not and should not be taken to imply an opinion = on > the > >part of > >> the IETF, ICANN and IANA concerning the legal status of any = language, > script, > >> country, territory, region, or language variation. Nor should they = be > taken to > >> endorse any particular position regarding the legal status, = authority, > >frontiers, > >> boundaries, or cultural, political, economical, or educational > policies of any > >> particular country or region. This includes any issues pertaining = to > the > >identity > >> or usage of any language or script within any country or = region. > >... > > > >As a technical contributor, I think there adding this text = contributes > no value > >to the document, and could in the longer term be harmful, regardless = of > >its benign intent and content. > > > >None of the other IANA registries I've looked at has anything like = this. > >As a very concrete example, the enterprise number registry at > >http://www.iana.org/assignments/enterprise-numbers doesn't have > >lawerly verbiage about trademarks or the legal status of enterprise > names. > >Similarly, = http://www.iana.org/assignments/ianaaddressfamilynumbers-mib > >doesn't fret about trademarks. Not even > http://www.iana.org/assignments/idn/ > >goes through such hand-wringing. I think adding material like this > would > >set a very bad precedent, because it could lead to folks = misconstruing > >the absence of such disclaimers in other IANA-maintained registries. > > > >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@lists.ietf.org Sat Jul 16 14:16:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrDX-0006hR-G7; Sat, 16 Jul 2005 14:16:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrDV-0006h1-9M for ltru@megatron.ietf.org; Sat, 16 Jul 2005 14:16:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19621 for ; Sat, 16 Jul 2005 14:16:46 -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.43) id 1DtpG0-0002UP-8S for ltru@ietf.org; Sat, 16 Jul 2005 12:11:16 -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 Jul 2005 08:41:01 -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 #1067] Last call: clarification between languagetags and locales Date: Sat, 16 Jul 2005 08:41:00 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D846@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales Thread-Index: AcWJrXt+G24fSE5uSwixke5whstlYAAb0Fwg From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 16 Jul 2005 15:41:01.0128 (UTC) FILETIME=[C48DEC80:01C58A1C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 +1 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: 2005?7?15? 19:23 > To: LTRU Working Group > Subject: [Ltru] [psg.com #1067] Last call: clarification between > languagetags and locales >=20 > Hi - >=20 > > From: "r&d afrac" > > To: "LTRU Working Group" > > Sent: Friday, July 15, 2005 6:21 PM > > Subject: [Ltru] Last call: clarification between language tags and > locales > ... > > Proposed text - as insert for relation with IESG pending an IESG > decision: > > > > "[Charter has explicitly said that langtags apply to HTML, XML, = CLDR, > etc. > > This WG has identified that this point of the Charter is to be > requalified. > > In the case of CLDR, locales can certainly be described in using > Langtags > > as many other language and country related objects and processes, = such > as > > publishing, reading, filtering, censoring, exchanging, = communicating, > > classifying text, book, records, identifying expertise in a = language, > > copyrights, etc. etc. However they also have the capacity to = document > non > > language related issues such as colors on a display, sound of a > > loudspeaker, process speed depending on a process pattern, default > network > > addresses, etc.. They also can be partly patented to support = patented > > processes. As such they may have to be identified in refering to = patent > > references the "x-" escape sequence could support woud it not be = limited > to > > 8-alpha/num for retro-compatibility with the never used before = patent > > referencing. The WG hesitates to documents langtags for the CLDR and > wishes > > to exclude langtags considerations from its charter, reserving to = locale > > compilers the decision to use langtags as a part of, or an = equivalent to, > > localtag or not. Should localtags be confirmed as directly belonging = the > > Charter, a locale oriented "l-" final extension will be used where = all > the > > subsequent dashes would not be part of the Draft ABNF, in order to > accept > > sequences of the form "-c-" included in some of the references to > include.]" > ... >=20 > As co-chair: > (1) For patent-related disclosure requirements, see > http://www.ietf.org/rfc/rfc3979.txt > (2) Specifying locales is clearly beyond our scope. >=20 > As a technical contributor, I think Jefsey's proposed addition would = be > counterproductive. reducing rather than improving the document's > intellegibility. Consequently, I strongly oppose its inclusion. >=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 Sat Jul 16 14: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 1DtrGI-0007ka-Ua; Sat, 16 Jul 2005 14: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 1DtrGH-0007jI-Ha for ltru@megatron.ietf.org; Sat, 16 Jul 2005 14:19:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21764 for ; Sat, 16 Jul 2005 14:19:38 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtrjJ-0002Pa-PM for ltru@ietf.org; Sat, 16 Jul 2005 14:49:42 -0400 Received: from h-68-166-38-137.snvacaid.dynamic.covad.net ([68.166.38.137] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtrGD-0003cr-00 for ltru@ietf.org; Sat, 16 Jul 2005 14:19:37 -0400 Message-ID: <00b101c58a32$f72ac3a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050716122931.DRTE2895.edge5.adelphia.net@megatron.ietf.org> <00a501c58a26$969ba420$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: UN region code list change Date: Sat, 16 Jul 2005 11:19:02 -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: 3002fc2e661cd7f114cb6bae92fe88f1 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: "Doug Ewell" > To: "LTRU Working Group" > Sent: Saturday, July 16, 2005 9:51 AM > Subject: [Ltru] Re: UN region code list change > > Randy Presuhn wrote: > > >> Basically true, for codes that represent countries. Early this year > >> they split one macrogeographical code into two. I have no idea how > >> often that sort of thing happens, but in the future it will result in > >> two new subtags. > > > > I hope you mean two *potential* new subtags. There would be no reason > > to register either of the new codes as language subtags unless they > > were useful for distinguishing language varieties. > > My reading of Section 3.2 of draft-registry is that such new codes would > be added more or less automatically, unless there were a conflict with > existing subtags. You're right, but the split codes in no way *displace* the existing code. The new subtags would not affect any existing data, unless the owners of that data felt the split code(s) for some reason better reflected their needs. Consequently, I still think there's no problem. > The alternative would be to require ietf-languages to determine whether > a newly assigned UN code is "useful for distinguishing language > varieties." I don't know if they or we are in a position to do that. > Certainly we have assumed that to be the case for all of the existing > codes, including 001, because we add them all to the initial registry. I think it's too late for such a change, and don't want to propose one. > > Presumably the original code could continue to be used as a subtag, > > particularly if it more accurately characterized some linguistic > > phenomenon of interest. > > Of course, the original subtag is not removed or deprecated. Great. This is my main point. Disregard the rest as the result of typing past my bed-time. :-) > Let's use the recent case of "South-central Asia." Originally (for our > purposes) this was one region, coded as 062. Recently the UNSD split > this into "Southern Asia," codes as 034, and "Central Asia," coded as > 143. If this split had occurred after Date B, the Reviewer, upon seeing > that 034 and 143 did not conflict with any existing subtags, would > presumably add them. Note that region subtag 062 would remain in the > registry, and users who regard "South-central Asia" as most accurately > characterizing their linguistic phenomonon would be able to continue > using that. (There is also 142 "Asia" for those who prefer that.) This is as it should be. > Because this split happened *before* Date B, and the rules are to > register only those UN codes valid as of Date B, we don't actually > register 062. Doing so is not necessarily for backward compatibility of > language tags, because unlike ISO 639 and 3166 codes, these UN thingies > were not previously valid in language tags. Suboptimal, if there are any languages for which this code would be useful. However, I can live with it if the rest of the group can. We discussed this before on the mailing list. (Issue #1034) The resolution that was agreed is in http://www1.ietf.org/mail-archive/web/ltru/current/msg02404.html The only nagging concern I have is that someone might need 062, and we'd have no way to put it in, but if this doesn't bother anyone else, ok. > > One of our objectives here was to insulate the users of language tags > > from churn in the sources. > > We insulate them from the worst kinds of churn: codes that are changed > and deleted, thus invalidating existing tags, and (worst of all) codes > that change their meaning. We don't necessarily insulate them from > newly created codes. Those actually give them more flexibility. ... All good. I'm just overly worried about the codes that got left out. :-) Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 14:26:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrMr-0003F7-32; Sat, 16 Jul 2005 14: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 1DtrMp-0003F2-OJ for ltru@megatron.ietf.org; Sat, 16 Jul 2005 14:26:27 -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 OAA21973 for ; Sat, 16 Jul 2005 14:26: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 <20050716182556.IXJV14360.mta13.adelphia.net@DEWELL> for ; Sat, 16 Jul 2005 14:25:56 -0400 Message-ID: <00c701c58a33$b8e1d420$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 16 Jul 2005 11:25: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 Cc: Subject: [Ltru] Editor's copy of draft-initial-03 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 put up an editor's copy of draft-initial-03 at the familiar locations: http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-03.txt http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-03.html http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-03.xml I haven't submitted this yet because of the question of deprecating "zh-guoyu" in favor of the new "zh-cmn". Changes from draft-initial-02 include: * reference to "RFC 3066bis" removed from Abstract * missing word "regions" added to Section 2, item 3 * items 5 and 6 cleaned up as discussed * "Date B" updated as usual * newly registered RFC 3066 tags included as discussed * text in Section 4 clarified per Scott's suggestion Constructive comments are welcome. -- 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 Jul 16 14:35:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrVU-0006yu-Mk; Sat, 16 Jul 2005 14: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 1DtrVU-0006yT-2g for ltru@megatron.ietf.org; Sat, 16 Jul 2005 14:35:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22371 for ; Sat, 16 Jul 2005 14:35:22 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtrtf-0003vP-8x for ltru@ietf.org; Sat, 16 Jul 2005 15:00:24 -0400 Received: from h-68-166-38-137.snvacaid.dynamic.covad.net ([68.166.38.137] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtrQZ-0005VT-00 for ltru@ietf.org; Sat, 16 Jul 2005 14:30:19 -0400 Message-ID: <00c001c58a34$76990740$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050716012427.OGVF31309.edge6.adelphia.net@megatron.ietf.org> <007901c589d7$b8460e20$030aa8c0@DEWELL> Date: Sat, 16 Jul 2005 11:30:36 -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: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Ltru] [psg.com #1077] deprecate grandfathered zh-guoyu X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 assigned ticket number #1077 to this. Randy, ltru co-chair > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Saturday, July 16, 2005 12:26 AM > Subject: [Ltru] Re: Initial Language Subtag Registry ... > The next question is whether we should deprecate "zh-guoyu" in favor of > "zh-cmn" as well. The text in the approved registration form says: > > "It is understood that the 'guoyu' dialect tag will be deprecated. This > is a formal application for use of the replacement tag 'cmn'. This is > intended to describe the same Mandarin Chinese dialect that was > previously described with the '-guoyu' extension." > > I interpret that as a signal to this WG to deprecate the grandfathered > tag "zh-guoyu" as of the date of approval of "zh-cmn", namely > 2005-07-15, and give it a Preferred-Value of "zh-cmn". That probably > does need to be a ticket. ... _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 15:10:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dts2y-0003NN-HY; Sat, 16 Jul 2005 15:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dts2w-0003Mz-H2 for ltru@megatron.ietf.org; Sat, 16 Jul 2005 15:09:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25578 for ; Sat, 16 Jul 2005 15:09:56 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtsW0-0005wj-VK for ltru@ietf.org; Sat, 16 Jul 2005 15:40:01 -0400 Received: from h-68-166-38-137.snvacaid.dynamic.covad.net ([68.166.38.137] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dts2q-0005Qq-00 for ltru@ietf.org; Sat, 16 Jul 2005 15:09:52 -0400 Message-ID: <010c01c58a39$fca88a40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C20D847@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UN disclaimer Date: Sat, 16 Jul 2005 12:10:09 -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: a7d6aff76b15f3f56fcb94490e1052e4 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 - As a technical contributor... > From: "Addison Phillips" > To: "Martin Duerst" ; "Randy Presuhn" ; > Sent: Saturday, July 16, 2005 8:55 AM > Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer ... > I think that including a giant piece of policy on behalf of IETF, ICANN, and > IANA is probably inappropriate. However, I *can* see draft-registry making > the statement that the registration process does not endorse any particular > position and that registrations will be considered on an equal basis. The > resulting text would be more useful. Perhaps: > > Registration requests are each considered on their own merits, based > on the need to identify a language. This I could live with, though as instruction for the conduct of the review process, "are" probably should be "are to be" > The presence, absence or contents of any particular subtag and its associated > fields in the registry do not imply a position on the legal status of any language, > script, country, territory, region, or language variation. Nor do they endorse any > particular position regarding the legal status, authority, frontiers, boundaries, > or policies of any particular country or region. This includes any issues pertaining > to the identity or usage of any language or script within any country or region. ... The last sentence bothers me a lot, since it can be construed as being at odds with the very first sentence of the proposed paragraph. If it were eliminated, I'd put up with the rest if there were overwhelming support by the rest of the WG, though I *really* don't like the idea of putting this kind of stuff into our documents. We don't do this for other registries, even in such highly competitive areas as network management (where I spend most of my time). This kind of material is the edge of the slippery slope of endless additions on things that sound nice but really make no technical difference whatsoever. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 15:24:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtsHS-0008Rl-Eb; Sat, 16 Jul 2005 15:24:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtrCW-0006Iv-3X for ltru@megatron.ietf.org; Sat, 16 Jul 2005 14:15:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18839 for ; Sat, 16 Jul 2005 14:15:44 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtpz7-00059P-PD for ltru@ietf.org; Sat, 16 Jul 2005 12:57:54 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtpVu-0006nx-9B for ltru@ietf.org; Sat, 16 Jul 2005 09:27:42 -0700 Message-Id: <6.2.1.2.2.20050716140428.03aaeeb0@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 16 Jul 2005 14:05:53 +0200 To: ltru@ietf.org From: Jefsey Morfin Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between language tags and locales 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: 41c17b4b16d1eedaa8395c26e9a251c4 X-Mailman-Approved-At: Sat, 16 Jul 2005 15:24:57 -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 OK, I will feed the troll ... On 04:23 16/07/2005, Randy Presuhn said: > > Proposed text - as insert for relation with IESG pending an IESG decision: > > > > "[Charter has explicitly said that langtags apply to HTML, XML, CLDR, etc. > > This WG has identified that this point of the Charter is to be requalified. > > In the case of CLDR, locales can certainly be described in using Langtags > > as many other language and country related objects and processes, such as > > publishing, reading, filtering, censoring, exchanging, communicating, > > classifying text, book, records, identifying expertise in a language, > > copyrights, etc. etc. However they also have the capacity to document non > > language related issues such as colors on a display, sound of a > > loudspeaker, process speed depending on a process pattern, default network > > addresses, etc.. They also can be partly patented to support patented > > processes. As such they may have to be identified in refering to patent > > references the "x-" escape sequence could support woud it not be limited to > > 8-alpha/num for retro-compatibility with the never used before patent > > referencing. The WG hesitates to documents langtags for the CLDR and wishes > > to exclude langtags considerations from its charter, reserving to locale > > compilers the decision to use langtags as a part of, or an equivalent to, > > localtag or not. Should localtags be confirmed as directly belonging the > > Charter, a locale oriented "l-" final extension will be used where all the > > subsequent dashes would not be part of the Draft ABNF, in order to accept > > sequences of the form "-c-" included in some of the references to > include.]" >... > >As co-chair: >(1) For patent-related disclosure requirements, see >http://www.ietf.org/rfc/rfc3979.txt >(2) Specifying locales is clearly beyond our scope. Difficult to understand in which context these two quotes are made. They seem totally out of scope? >As a technical contributor, I think Jefsey's proposed addition would be >counterproductive. reducing rather than improving the document's >intellegibility. Consequently, I strongly oppose its inclusion. Your priviledge. There must be a clearly expressed consensus, one way or another. From what I understand you want to be able to use langtags to name locales, without expressing any consideration on their structure, nor permitting competitors to differentiate their propositions through the reference of their IPRs? This is at least what I understand after reading this many times. Difficult to get understand what you may oppose since I say the same but leaving the IESG to say otherwise. Thx to tell where I would be wrong reading you? An IPR lawyer suggests me: "he wants to keep CLDR in the loop, but does not want to see it discussed. If the target is to be able to say 'IANA langtag inside' there is a long long long way to go, all the more if there are any directly or indirectly claimed right through the locale". A civil right fighter says so bad things about all this, that I hesitate between quoting him and being expelled, and giving him the way to subscribe and to see him setting the WG afire. Not easy to just stay a network architect. But even then, look at what Vint Cerf just said .... http://news.yahoo.com/s/ap/20050715/ap_on_hi_te/internet_languages;_ylt=ArzU5bsfXU3xIjN3xHeQIE6s0NUE;_ylu=X3oDMTA3cjE0b2MwBHNlYwM3Mzg putting the blame on us because it does not work. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 15:26:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtsIw-0000Ng-Nh; Sat, 16 Jul 2005 15:26:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtsIv-0000Nb-KF for ltru@megatron.ietf.org; Sat, 16 Jul 2005 15:26:29 -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 PAA26897 for ; Sat, 16 Jul 2005 15:26:27 -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 <20050716192557.ITGC24042.mta11.adelphia.net@DEWELL> for ; Sat, 16 Jul 2005 15:25:57 -0400 Message-ID: <00dd01c58a3c$036be280$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sat, 16 Jul 2005 12:24:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 1 X-MSMail-Priority: High 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: Editor's copy of draft-initial-03 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 wrote: > I've put up an editor's copy of draft-initial-03 at the familiar > locations: > ... > I haven't submitted this yet because of the question of deprecating > "zh-guoyu" in favor of the new "zh-cmn". I apologize for this misstatement. Since we are in Working Group Last Call, this revised version will not be formally submitted until the end of WG Last Call on July 28. We need to make sure we are all reviewing the same version of each draft. The "zh-guoyu" question can be resolved at any time before the end of WGLC (hopefully sooner rather than later), and the resolution will be reflected in future editor's drafts if time permits. Sorry for the confusion. -- 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 Jul 16 16:02:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtsrX-0003yb-R6; Sat, 16 Jul 2005 16:02:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtsrW-0003yW-LN for ltru@megatron.ietf.org; Sat, 16 Jul 2005 16:02:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28698 for ; Sat, 16 Jul 2005 16:02:12 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DttKa-0007Zj-PS for ltru@ietf.org; Sat, 16 Jul 2005 16:32:18 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jul 2005 13:02:00 -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); Sat, 16 Jul 2005 13:02:01 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN disclaimer Date: Sat, 16 Jul 2005 13:01:52 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN disclaimer Thread-Index: AcWKMsq+cXqVAN8aTDaXsbNgii8cqAABbGyA From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 16 Jul 2005 20:02:01.0087 (UTC) FILETIME=[3A9E08F0:01C58A41] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 r&d afrac > Half reading or constantly misconstruing what I say... Look who's calling the pot black! > "A is not possible"/"Yes AB is possible" is usefull for me with legal > reviewers. Mr. Morfin appears to be engaging in tactics of intimidation. I consider this far from good faith to be a contributing member within a working group. > >False. If we were imitating the structure of the ISO or UN directories, > such > >a claim might almost be plausible. With a differing organization of data, > >the omission of some elements, the addition of other elements, > >and a differing scope of application, any claim of copyright infringement > >would be rather far-fetched. >=20 > Thank you for so exactly describing your intent to tamper with the > intended > usage of the codes. This is utter misconstrual and innuendo. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 16:15:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtt41-0000UP-LC; Sat, 16 Jul 2005 16:15:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtt40-0000UH-DR for ltru@megatron.ietf.org; Sat, 16 Jul 2005 16:15:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29241 for ; Sat, 16 Jul 2005 16:15:06 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DttX5-0007xJ-NO for ltru@ietf.org; Sat, 16 Jul 2005 16:45:12 -0400 Received: from h-68-166-38-137.snvacaid.dynamic.covad.net ([68.166.38.137] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dtt3q-00018e-00 for ltru@ietf.org; Sat, 16 Jul 2005 16:14:59 -0400 Message-ID: <012b01c58a43$1402d8e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.2.1.2.2.20050716140428.03aaeeb0@pop.online.fr> Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between language tags and locales Date: Sat, 16 Jul 2005 13:15: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.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Jefsey: > From: "Jefsey Morfin" > To: > Sent: Saturday, July 16, 2005 5:05 AM > Subject: Re: [Ltru] [psg.com #1067] Last call: clarification betweenlanguage tags and locales > > OK, I will feed the troll ... > > On 04:23 16/07/2005, Randy Presuhn said: > > > Proposed text - as insert for relation with IESG pending an IESG decision: > > > > > > "[Charter has explicitly said that langtags apply to HTML, XML, CLDR, etc. > > > This WG has identified that this point of the Charter is to be requalified. > > > In the case of CLDR, locales can certainly be described in using Langtags > > > as many other language and country related objects and processes, such as > > > publishing, reading, filtering, censoring, exchanging, communicating, > > > classifying text, book, records, identifying expertise in a language, > > > copyrights, etc. etc. However they also have the capacity to document non > > > language related issues such as colors on a display, sound of a > > > loudspeaker, process speed depending on a process pattern, default network > > > addresses, etc.. They also can be partly patented to support patented > > > processes. As such they may have to be identified in refering to patent > > > references the "x-" escape sequence could support woud it not be limited to > > > 8-alpha/num for retro-compatibility with the never used before patent > > > referencing. The WG hesitates to documents langtags for the CLDR and wishes > > > to exclude langtags considerations from its charter, reserving to locale > > > compilers the decision to use langtags as a part of, or an equivalent to, > > > localtag or not. Should localtags be confirmed as directly belonging the > > > Charter, a locale oriented "l-" final extension will be used where all the > > > subsequent dashes would not be part of the Draft ABNF, in order to accept > > > sequences of the form "-c-" included in some of the references to > > include.]" > >... > > > >As co-chair: > >(1) For patent-related disclosure requirements, see > >http://www.ietf.org/rfc/rfc3979.txt > >(2) Specifying locales is clearly beyond our scope. > > Difficult to understand in which context these two quotes are made. They > seem totally out of scope? Responses to the two major topics in your proposal. > >As a technical contributor, I think Jefsey's proposed addition would be > >counterproductive. reducing rather than improving the document's > >intellegibility. Consequently, I strongly oppose its inclusion. > > Your priviledge. There must be a clearly expressed consensus, one way or > another. No. > From what I understand you want to be able to use langtags to name > locales, without expressing any consideration on their structure, nor > permitting competitors to differentiate their propositions through the > reference of their IPRs? This is at least what I understand after reading > this many times. Difficult to get understand what you may oppose since I > say the same but leaving the IESG to say otherwise. Thx to tell where I > would be wrong reading you? Language tags and locales are different beasts, despite their superficial similarities. Any further discussion of locales is out of scope, in my opinion. > An IPR lawyer suggests me: "he wants to keep CLDR in the loop, but does not > want to see it discussed. If the target is to be able to say 'IANA langtag > inside' there is a long long long way to go, all the more if there are any > directly or indirectly claimed right through the locale". A civil right > fighter says so bad things about all this, that I hesitate between quoting > him and being expelled, and giving him the way to subscribe and to see him > setting the WG afire. This working group is open to all who wish to participate. If the people you've conferred with have something to say, let them speak for themselves. We welcome comments from folks who have read the drafts. > Not easy to just stay a network architect. > > But even then, look at what Vint Cerf just said .... > http://news.yahoo.com/s/ap/20050715/ap_on_hi_te/internet_languages;_ylt=ArzU5bsfXU3xIjN3xHeQIE6s0NUE;_ylu=X3oDMTA3cjE0b2MwBHNlYwM3Mzg > putting the blame on us because it does not work. ... The referenced URL has nothing to do with language tagging. The discussion of issue #967 explains why. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 16:47:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DttZO-0002Bw-Rf; Sat, 16 Jul 2005 16: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 1DttZN-0002Bm-Dz for ltru@megatron.ietf.org; Sat, 16 Jul 2005 16:47:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00808 for ; Sat, 16 Jul 2005 16:47:31 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtu2S-0000RB-09 for ltru@ietf.org; Sat, 16 Jul 2005 17:17:37 -0400 Received: from h-68-166-38-137.snvacaid.dynamic.covad.net ([68.166.38.137] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DttZK-0004i5-00 for ltru@ietf.org; Sat, 16 Jul 2005 16:47:30 -0400 Message-ID: <000a01c58a47$9f9ffaa0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050716012427.OGVF31309.edge6.adelphia.net@megatron.ietf.org> <007901c589d7$b8460e20$030aa8c0@DEWELL> Date: Sat, 16 Jul 2005 13:47: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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Ltru] Re: [psg.com #1076] Additions to Initial Language Subtag 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 Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Saturday, July 16, 2005 12:26 AM > Subject: [Ltru] Re: Initial Language Subtag Registry > > Karen Broome wrote: > > > Add these to the initial subtag registry? They were just formalized. > > > > es-419 > > zh-cmn > > zh-cmn-Hant > > zh-cmn-Hans > > I've already added them. You'll see them in the next revision. > > > It's probably most important to add es-419 since it's referenced in > > the Tags for Identifying Languages draft. > > They're equally important. "es-419" is redundant; the others are > grandfathered (but would become redundant under a presumed future > 3066ter which included 'cmn' as an extended-language subtag under 'zh'). > > My impression is that since we already have an agreement (written into > draft-registry) to include all tags from the RFC 3066 registry at Date B > as either grandfathered or redundant, we shouldn't actually need a > ticket to add these four. Since Randy has assigned one, I strongly > recommend we mark it "resolved" and move along. ... Agreed & done. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 16:51:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dttcn-0003rp-Id; Sat, 16 Jul 2005 16:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dttch-0003nZ-4Q for ltru@megatron.ietf.org; Sat, 16 Jul 2005 16:50:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00946 for ; Sat, 16 Jul 2005 16:50:56 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtu5m-0000YA-Sb for ltru@ietf.org; Sat, 16 Jul 2005 17:21:03 -0400 Received: from h-68-166-38-137.snvacaid.dynamic.covad.net ([68.166.38.137] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dttcg-0005AY-00 for ltru@ietf.org; Sat, 16 Jul 2005 16:50:58 -0400 Message-ID: <002301c58a48$1c2089a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050716012427.OGVF31309.edge6.adelphia.net@megatron.ietf.org><007901c589d7$b8460e20$030aa8c0@DEWELL> <00c001c58a34$76990740$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #1077] deprecate grandfathered zh-guoyu Date: Sat, 16 Jul 2005 13:50: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: 0bc60ec82efc80c84b8d02f4b0e4de22 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: "Doug Ewell" > > To: "LTRU Working Group" > > Sent: Saturday, July 16, 2005 12:26 AM > > Subject: [Ltru] Re: Initial Language Subtag Registry > ... > > The next question is whether we should deprecate "zh-guoyu" in favor of > > "zh-cmn" as well. The text in the approved registration form says: > > > > "It is understood that the 'guoyu' dialect tag will be deprecated. This > > is a formal application for use of the replacement tag 'cmn'. This is > > intended to describe the same Mandarin Chinese dialect that was > > previously described with the '-guoyu' extension." > > > > I interpret that as a signal to this WG to deprecate the grandfathered > > tag "zh-guoyu" as of the date of approval of "zh-cmn", namely > > 2005-07-15, and give it a Preferred-Value of "zh-cmn". That probably > > does need to be a ticket. ... As a technical contributor, I support the proposed change. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 16:54:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DttgM-0005DO-L7; Sat, 16 Jul 2005 16:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DttgJ-0005DJ-Mn for ltru@megatron.ietf.org; Sat, 16 Jul 2005 16:54:44 -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 QAA01136 for ; Sat, 16 Jul 2005 16:54:41 -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 <20050716205411.NBRY14360.mta13.adelphia.net@DEWELL> for ; Sat, 16 Jul 2005 16:54:11 -0400 Message-ID: <00e201c58a48$3b190120$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050716201709.YLUN21353.mta3.adelphia.net@megatron.ietf.org> Date: Sat, 16 Jul 2005 13:52: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 Cc: Subject: [Ltru] Re: [psg.com #1077] deprecate grandfathered zh-guoyu X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 support this proposal. -- 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 Jul 16 17:32:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtuH4-0002WK-OU; Sat, 16 Jul 2005 17:32:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtuH3-0002WF-32 for ltru@megatron.ietf.org; Sat, 16 Jul 2005 17:32:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02816 for ; Sat, 16 Jul 2005 17:32:38 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtuk8-0002b9-Ll for ltru@ietf.org; Sat, 16 Jul 2005 18:02:45 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtuGw-0006iw-TU; Sat, 16 Jul 2005 14:32:35 -0700 Message-Id: <6.2.1.2.2.20050716222308.04b0dc50@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 16 Jul 2005 23:32:22 +0200 To: "Peter Constable" , "LTRU Working Group" From: r&d afrac Subject: RE: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN disclaimer 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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 Mr. Constable, I must confess I am tired of all this unrealistic debate. At 22:01 16/07/2005, Peter Constable wrote: > > Half reading or constantly misconstruing what I say... >Look who's calling the pot black! Ad-hominem. > > "A is not possible"/"Yes AB is possible" is usefull for me with legal > > reviewers. > >Mr. Morfin appears to be engaging in tactics of intimidation. I consider >this far from good faith to be a contributing member within a working >group. Please document in which way the responses of Randy Preshun are addressing the points I made? In which way a point on "text" in general, can be addressed by an anecdotic remark on "specific text" in particular? How the possibility of removal of one paragraph can address a remark concerning the impossibility to remove the Draft or RFC 3066? How teeling that I ignore the existence of the very procedure I am calling the use, can be pertinent? If you consider a contributing member as an applauding member I am certainly not. I was clear in accepting to support Randy for the creation of this WG: I will _not_ support anything else than the _Charter_. I have every intention to keep my word and to oppose every tactics avoiding to address the Charter. Points not considering the Charter are purely disruptive IMO. This confusion about locales enters into that category. CLDR _is_ in the Charter. You should know after all these months that I am not intimidated easily. BTW did I say that I fond yesterday a disruptive phone message over RFC 3066 from a public phone in ... Valence in South of France. A place some in here know well. Does that follow the questions (in archives) about my cost to the industry, or broken nose? I thought this was only the IETF .... > >False. If we were imitating the structure of the ISO or UN >directories, > > such > > >a claim might almost be plausible. With a differing organization of >data, > > >the omission of some elements, the addition of other elements, > > >and a differing scope of application, any claim of copyright >infringement > > >would be rather far-fetched. > > > > Thank you for so exactly describing your intent to tamper with the > > intended usage of the codes. > >This is utter misconstrual and innuendo. I think you have not at all understood the problem. There is absolutely no innuendo. Things are very clear and open: - there is a precise description of the intent to use ISO and UN codes in a different way than their initial purpose, and my opinion, in an opposed way to the intent of their authors. None of these authors has intended to see established a published correlation between languages, scripts and countries. This point is risen in ISO 639-4 and is under active debate, for the very reasons Randy describes. Which are judged by many as highly politically loaded. And possibly in some participating countries as illegal. This is no small matter whatever you may feel. - there is a clear opposition of mine to this on ethical and technical grounds. And a clear opposition, should the document be agreed, on legal grounds which will be addressed at IANA level. This strictly belongs to the Charter which is to establish a Registry in correcting RFC 3066. The only way to clarify this is to ask the authors - ISO, UN and those who can oppose (GAC, Government, Civil Rights, Consumers, Industries organisations). I suppose that no one will have a problem with that (better to carry that work in parallel, rather than afterward)? If you want to share in the letters sent to them you are most welcome. Does the following description describes your intent as described by Randy: "The Draft proposed by the WG-ltru at this stage, does not intent to reproduce or to imitate the structure of the ISO or UN directories (I am not sure it is the proper word to use?), but to present their data in a different organisation, omitting some elements, adding other elements, with a differing scope of application (this is not clear to me and need clarification as I feel that the scope of each code is proper and this is their correlation which is improper, but I am ready to keep the wording). The WG-ltru feels that considering that there would be copyright issues would be far-fetched". - does that also transcribes correctly the WG-ltru feeling? - I will add my own organisations ethical questions. - I will ask guidance on the correlation issues. The IETF having no legal existence, I will copy these letters to ICANN (IANA), ISOC (IETF). Please indicate if there are other authorities you which to see copied. All the best. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 18:09:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtuqD-0006WN-2V; Sat, 16 Jul 2005 18:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtuqA-0006WI-Rb for ltru@megatron.ietf.org; Sat, 16 Jul 2005 18:08:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04719 for ; Sat, 16 Jul 2005 18:08:56 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtvJG-0003xU-8K for ltru@ietf.org; Sat, 16 Jul 2005 18:39:03 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dtuq8-0007Qg-Eu for ltru@ietf.org; Sat, 16 Jul 2005 15:08:56 -0700 Message-Id: <6.2.1.2.2.20050716234433.037f5b80@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 17 Jul 2005 00:08:44 +0200 To: ltru@ietf.org From: r&d afrac Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Ltru] data X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Since July 13 Last Call to 57 Members (may be more?): 20 contributors. 60% of the contributions by 5 contributors. 75% of the contributions by 7 contributors. 10% of the contributions include the word "charter", 2% of the contributions rise a new point concerning a point about the WG's Charter jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 18:33:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtvDa-0006d7-4a; Sat, 16 Jul 2005 18:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtvDY-0006aX-0f for ltru@megatron.ietf.org; Sat, 16 Jul 2005 18:33:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06530 for ; Sat, 16 Jul 2005 18:33:05 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtvge-0005D3-H5 for ltru@ietf.org; Sat, 16 Jul 2005 19:03:12 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jul 2005 15:32: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.1830); Sat, 16 Jul 2005 15:32:58 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN disclaimer Date: Sat, 16 Jul 2005 15:32:56 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN disclaimer Thread-Index: AcWKTeLO0wCcWT0yTXq/CZlvYlxesAABP54A From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 16 Jul 2005 22:32:58.0272 (UTC) FILETIME=[511ECA00:01C58A56] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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: r&d afrac [mailto:rd@afrac.org] > >Mr. Morfin appears to be engaging in tactics of intimidation. I consider > >this far from good faith to be a contributing member within a working > >group. > If you consider a contributing member as an applauding member I am > certainly not. Nobody has said you must applaud. Most of the people here have contributed on occasions when they disagreed with proposed text. > address the Charter. Points not considering the Charter are purely > disruptive IMO. This confusion about locales enters into that category. > CLDR _is_ in the Charter. In case you haven't noticed, this thread is about adoption of text you derived from the UN site; it has nothing to do with locales or CLDR. > You should know after all these months that I am not intimidated easily. Nor anybody else here. > > >False. If we were imitating the structure of the ISO or UN > >directories, > > > such > > > >a claim might almost be plausible. With a differing organization of > >data, > > > >the omission of some elements, the addition of other elements, > > > >and a differing scope of application, any claim of copyright > >infringement > > > >would be rather far-fetched. > > > > > > Thank you for so exactly describing your intent to tamper with the > > > intended usage of the codes. > > > >This is utter misconstrual and innuendo. >=20 > I think you have not at all understood the problem. There is absolutely no > innuendo. Things are very clear and open: >=20 > - there is a precise description of the intent to use ISO and UN codes in > a > different way than their initial purpose, and my opinion, in an opposed > way > to the intent of their authors. You have not demonstrated this in the slightest.=20 > None of these authors has intended to see > established a published correlation between languages, scripts and > countries. On the contrary, the ISO 639 standards explicitly state that applications may find utility in using ISO 639 identifiers in conjunction with ISO 3166 identifiers. (ISO/DIS 639-3 also makes reference to ISO 15924 script identifiers.) Quoting from clause 4.4 of ISO 639-1:2002: "Language identifiers according to this part of ISO 639 may be combined with identifiers according to ISO 3166 to denote the area (country or subdivision of a country) in which a term, phrase or language is used." See likewise clause 4.4 of ISO 639-2:1998, clause 8.1 of ISO/CD 639-4 (wrt ISO 3166) and clause 8.3 of the same (wrt ISO 15924). > - there is a clear opposition of mine to this on ethical and technical > grounds. And a clear opposition, should the document be agreed, on legal > grounds which will be addressed at IANA level. This strictly belongs to > the > Charter which is to establish a Registry in correcting RFC 3066. Sticking to the point, this concern on your part does not support your claim that there has been intent to tamper with code sets defined in ISO or UN standards. =20 Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 18:34:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtvEQ-0006fp-C8; Sat, 16 Jul 2005 18:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtvEP-0006fk-79 for ltru@megatron.ietf.org; Sat, 16 Jul 2005 18:34:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06576 for ; Sat, 16 Jul 2005 18:33:58 -0400 (EDT) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtvhU-0005Dv-Of for ltru@ietf.org; Sat, 16 Jul 2005 19:04:06 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jul 2005 15:33:50 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jul 2005 15:33:50 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Re: [psg.com #1077] deprecate grandfathered zh-guoyu Date: Sat, 16 Jul 2005 15:33:47 -0700 Message-ID: Thread-Topic: [Ltru] Re: [psg.com #1077] deprecate grandfathered zh-guoyu Thread-Index: AcWKSKJfVlxwtP3aSYeBbV3IaYtsNQADcjrA From: "Peter Constable" To: "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 16 Jul 2005 22:33:50.0288 (UTC) FILETIME=[701FCD00:01C58A56] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 +1 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Doug Ewell > Sent: Saturday, July 16, 2005 1:52 PM > To: LTRU Working Group > Subject: [Ltru] Re: [psg.com #1077] deprecate grandfathered zh-guoyu >=20 > I support this proposal. >=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 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 18:37:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtvID-0008Jn-Ui; Sat, 16 Jul 2005 18:37:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtvIC-0008Ji-K7 for ltru@megatron.ietf.org; Sat, 16 Jul 2005 18:37:56 -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 SAA06776 for ; Sat, 16 Jul 2005 18:37:53 -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 <20050716223725.KQGF19267.mta10.adelphia.net@DEWELL> for ; Sat, 16 Jul 2005 18:37:25 -0400 Message-ID: <00ee01c58a56$5c97cd00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050716201709.YLUN21353.mta3.adelphia.net@megatron.ietf.org> Date: Sat, 16 Jul 2005 15:33: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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: UN region code list change X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: >>>> Basically true, for codes that represent countries. Early this >>>> year they split one macrogeographical code into two. I have no >>>> idea how often that sort of thing happens, but in the future it >>>> will result in two new subtags. >>> >>> I hope you mean two *potential* new subtags. There would be no >>> reason to register either of the new codes as language subtags >>> unless they were useful for distinguishing language varieties. >> >> My reading of Section 3.2 of draft-registry is that such new codes >> would be added more or less automatically, unless there were a >> conflict with existing subtags. > > You're right, but the split codes in no way *displace* the existing > code. The new subtags would not affect any existing data, unless the > owners of that data felt the split code(s) for some reason better > reflected their needs. Consequently, I still think there's no > problem. I didn't think the split code would displace the existing code. There would be one old code and two new codes. All would become valid as subtags, and since retagging of existing data is not encouraged, there would be no problem with existing data. I'm just saying that the overwhelming likelihood, based on the draft and what I consider common sense, is that the new codes would be registered as subtags, more or less automatically, not rejected on the basis that ietf-languages had some overriding reason to believe they would not be useful. >> The alternative would be to require ietf-languages to determine >> whether a newly assigned UN code is "useful for distinguishing >> language varieties." I don't know if they or we are in a position to >> do that. Certainly we have assumed that to be the case for all of >> the existing codes, including 001, because we add them all to the >> initial registry. > > I think it's too late for such a change, and don't want to propose > one. I didn't suggest a change. I don't think ietf-languages should try to make such a determination with regard to codes from core standards. Proposals to add primary language subtags and variant subtags are where they need to exercise judgment. >> Because this split happened *before* Date B, and the rules are to >> register only those UN codes valid as of Date B, we don't actually >> register 062. Doing so is not necessarily for backward compatibility >> of language tags, because unlike ISO 639 and 3166 codes, these UN >> thingies were not previously valid in language tags. > > Suboptimal, if there are any languages for which this code would be > useful. However, I can live with it if the rest of the group can. > We discussed this before on the mailing list. (Issue #1034) The > resolution that was agreed is in > http://www1.ietf.org/mail-archive/web/ltru/current/msg02404.html > The only nagging concern I have is that someone might need 062, and > we'd have no way to put it in, but if this doesn't bother anyone else, > ok. 062 is no different from any number of mystery codes that UNSD might have added and removed in the past. We know about 062 because this project was started before 062 was removed, but we have no way of knowing what the others were. -- 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 Jul 16 18:54:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtvYR-0005RW-HE; Sat, 16 Jul 2005 18:54:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtvYQ-0005RR-OK for ltru@megatron.ietf.org; Sat, 16 Jul 2005 18:54:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07267 for ; Sat, 16 Jul 2005 18:54:38 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtw1U-0006L4-2k for ltru@ietf.org; Sat, 16 Jul 2005 19:24:46 -0400 Received: from h-68-166-38-137.snvacaid.dynamic.covad.net ([68.166.38.137] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DtvYC-0005XM-00 for ltru@ietf.org; Sat, 16 Jul 2005 18:54:29 -0400 Message-ID: <001701c58a59$5d17f220$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.1.2.2.20050716222308.04b0dc50@mail.afrac.org> Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UN disclaimer Date: Sat, 16 Jul 2005 15:54: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.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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: "r&d afrac" > To: "Peter Constable" ; "LTRU Working Group" > Sent: Saturday, July 16, 2005 2:32 PM > Subject: RE: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUNdisclaimer ... > - there is a precise description of the intent to use ISO and UN codes in a > different way than their initial purpose, and my opinion, in an opposed way > to the intent of their authors. None of these authors has intended to see > established a published correlation between languages, scripts and > countries. This point is risen in ISO 639-4 and is under active debate, for > the very reasons Randy describes. Which are judged by many as highly > politically loaded. And possibly in some participating countries as > illegal. This is no small matter whatever you may feel. If the problem you claim exists in ISO 639-4, it's still, by definition, not our problem. But, reading Peter's message, I doubt whether the purported problem exists at all. > - there is a clear opposition of mine to this on ethical and technical > grounds. And a clear opposition, should the document be agreed, on legal > grounds which will be addressed at IANA level. This strictly belongs to the > Charter which is to establish a Registry in correcting RFC 3066. Despite your repeated hissy fits, your opposition has not gained any support among the working group members. Continued whining justs wastes time and annoys those who are contributing in good faith. But you know that. > The only way to clarify this is to ask the authors - ISO, UN and those who > can oppose (GAC, Government, Civil Rights, Consumers, Industries > organisations). I suppose that no one will have a problem with that (better > to carry that work in parallel, rather than afterward)? If you want to > share in the letters sent to them you are most welcome. If folks want to participate in this working group, this mailing list is the place to do it. If others want to work through the liaison process, they are welcome to do so, though I suspect liasons would take too long. > Does the following description describes your intent as described by Randy: > > "The Draft proposed by the WG-ltru at this stage, does not intent to > reproduce or to imitate the structure of the ISO or UN directories (I am > not sure it is the proper word to use?), but to present their data in a > different organisation, omitting some elements, adding other elements, with > a differing scope of application (this is not clear to me and need > clarification as I feel that the scope of each code is proper and this is > their correlation which is improper, but I am ready to keep the wording). > The WG-ltru feels that considering that there would be copyright issues > would be far-fetched". A twisted reading if ever there was. In any case, if you're trying to pretend that you're doing liaison work, I recommend conferring with the IETF's liaisons to the various organizations. See http://www.ietf.org/liaisonActivities.html > - does that also transcribes correctly the WG-ltru feeling? > - I will add my own organisations ethical questions. > - I will ask guidance on the correlation issues. Fuss all you like. Participation here is by individuals. If you think others have something to contribute, please encourage them to join the working group, even at this late date. > The IETF having no legal existence, I will copy these letters to ICANN > (IANA), ISOC (IETF). Please indicate if there are other authorities you > which to see copied. ... They have my condolences. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 20:33:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtx69-0005Md-AP; Sat, 16 Jul 2005 20:33:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtx67-0005MV-Oz for ltru@megatron.ietf.org; Sat, 16 Jul 2005 20:33:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10289 for ; Sat, 16 Jul 2005 20:33:34 -0400 (EDT) Received: from e6.ny.us.ibm.com ([32.97.182.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtxZF-0002K0-BB for ltru@ietf.org; Sat, 16 Jul 2005 21:03:41 -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 j6H0XM2I015469 for ; Sat, 16 Jul 2005 20:33:22 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6H0XMSw229436 for ; Sat, 16 Jul 2005 20:33:22 -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 j6H0XMBq015607 for ; Sat, 16 Jul 2005 20:33:22 -0400 Received: from markdavis (sig-9-48-121-73.mts.ibm.com [9.48.121.73]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with SMTP id j6H0XKdW015592; Sat, 16 Jul 2005 20:33:21 -0400 Message-ID: <02d201c58a67$203843b0$fc763009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C20D846@irvmbxw01.quest.com> <002001c58a2f$2382d540$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales Date: Sat, 16 Jul 2005 17:33: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.1506 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e6.ny.us.ibm.com id j6H0XM2I015469 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 disagree with the proposal. I can understand your reasoning, but the proposed paragraph doesn't quite work. We are better off just keeping the text as it is, rather than open up a -- I suspect -- long discussion abou= t locales. Part of the problem is that 'locale IDs' are not a single concep= t; there is very broad variance in what they mean and how they are used. > "Although a language tag constructed from a primary language subtag > followed by a region subtag bears a syntactic resemblance to a locale > identifier, their semantics and usage are different." =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Saturday, July 16, 2005 10:52 Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales > Hi - > > As co-chair: > Ok, there seems to be no support for (and strong opposition to) Jefsey'= s proposed addition. > I see no need for further discussion of it unless someone else out ther= e thinks it's a > really good idea. > > As technical contributor: > Can we get back to the original issues in this discussion? Addison had said: > > > I think there is no need to add any text; there is already some text > > (in the section on extensions) which says that this is somewhat the > > case. Implementations that choose to coerce locales (local programmin= g > > constructs) from language tags are free to do so. > > I responded by saying that I don't find what's currently there particularly helpful. > The current i-d says: > > |3.6 Extensions and Extensions Namespace > | > | Extension subtags are those introduced by single-letter subtags oth= er > | than 'x'. They are reserved for the generation of identifiers whic= h > | contain a language component, and are compatible with applications > | that understand language tags. For example, they might be used to > | define locale identifiers, which are generally based on language. > > The first part is fine, but that last sentence is not particularly enlightening. > Language is probably the most important thing specified by a locale, > but saying locales are "based on language" won't help those who are at > all confused about the relationship. I hope this isn't the best exampl= e > of how we envision extensions being used. > > I suggest deleting this example (or replacing it with something more > enlightening) and adding the following paragraph as the second > paragraph in section 2.2.4 (Region Subtag). This is *revised* from > my earlier proposal: > > "Although a language tag constructed from a primary language subtag > followed by a region subtag bears a syntactic resemblance to a locale > identifier, their semantics and usage are different." > > 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 Sat Jul 16 20:34:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtx6f-0005cI-6n; Sat, 16 Jul 2005 20:34:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dtx6c-0005Ru-2O for ltru@megatron.ietf.org; Sat, 16 Jul 2005 20:34:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10313 for ; Sat, 16 Jul 2005 20:34:03 -0400 (EDT) Received: from e3.ny.us.ibm.com ([32.97.182.143]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtxZi-0002KX-1w for ltru@ietf.org; Sat, 16 Jul 2005 21:04: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 j6H0XtN0010230 for ; Sat, 16 Jul 2005 20:33:55 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6H0XtSw219722 for ; Sat, 16 Jul 2005 20:33:55 -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 j6H0Xtpu016030 for ; Sat, 16 Jul 2005 20:33:55 -0400 Received: from markdavis (sig-9-48-121-73.mts.ibm.com [9.48.121.73]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with SMTP id j6H0Xrqa015964; Sat, 16 Jul 2005 20:33:54 -0400 Message-ID: <02ec01c58a67$33ead620$fc763009@sanjose.ibm.com> From: "Mark Davis" To: "Peter Constable" , "Doug Ewell" , "LTRU Working Group" References: Subject: Re: [Ltru] Re: [psg.com #1077] deprecate grandfathered zh-guoyu Date: Sat, 16 Jul 2005 17:33:49 -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.1506 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e3.ny.us.ibm.com id j6H0XtN0010230 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 +1 =E2=80=8EMark ----- Original Message -----=20 From: "Peter Constable" To: "Doug Ewell" ; "LTRU Working Group" Sent: Saturday, July 16, 2005 15:33 Subject: RE: [Ltru] Re: [psg.com #1077] deprecate grandfathered zh-guoyu +1 > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Doug Ewell > Sent: Saturday, July 16, 2005 1:52 PM > To: LTRU Working Group > Subject: [Ltru] Re: [psg.com #1077] deprecate grandfathered zh-guoyu > > I support this proposal. > > -- > 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@lists.ietf.org Sat Jul 16 21:02:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtxXe-0007DZ-39; Sat, 16 Jul 2005 21:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtxXd-0007DU-BI for ltru@megatron.ietf.org; Sat, 16 Jul 2005 21:02: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 VAA11481 for ; Sat, 16 Jul 2005 21:01:58 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DtxXW-0006gn-PS for ltru@lists.ietf.org; Sun, 17 Jul 2005 03:01:54 +0200 Received: from 212.82.251.59 ([212.82.251.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jul 2005 03:01:54 +0200 Received: from nobody by 212.82.251.59 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jul 2005 03:01:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 17 Jul 2005 03:01:03 +0200 Organization: Lines: 24 Message-ID: <42D9ADCF.7966@xyzzy.claranet.de> References: <00dd01c58a3c$036be280$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.59 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Editor's copy of draft-initial-03 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 haven't submitted this yet because of the question of >> deprecating "zh-guoyu" in favor of the new "zh-cmn". > I apologize for this misstatement. Since we are in Working > Group Last Call, this revised version will not be formally > submitted until the end of WG Last Call on July 28. We need > to make sure we are all reviewing the same version of each > draft. In theory that makes sense, in practice there won't be new I-Ds after Monday for more than two weeks, and therefore a last snapshot before the IETF meeting could be interesting (only for your part). > The "zh-guoyu" question can be resolved at any time Just get rid of it (= mark as deprecated inserting the new preferred value plus a comment how to interpret the latter - it's a case of a redundant preferred value, isn't it ?) Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 21:18:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtxnF-0004OJ-T8; Sat, 16 Jul 2005 21:18:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtxnE-0004O5-U8 for ltru@megatron.ietf.org; Sat, 16 Jul 2005 21:18: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 VAA12055 for ; Sat, 16 Jul 2005 21:18:06 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dtxmu-0007c2-2P for ltru@lists.ietf.org; Sun, 17 Jul 2005 03:17:48 +0200 Received: from 212.82.251.59 ([212.82.251.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jul 2005 03:17:48 +0200 Received: from nobody by 212.82.251.59 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jul 2005 03:17:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 17 Jul 2005 03:17:03 +0200 Organization: Lines: 25 Message-ID: <42D9B18F.37B2@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C20D847@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.59 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Last call: IANA adaptation of the UN disclaimer X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 that including a giant piece of policy on behalf of > IETF, ICANN, and IANA is probably inappropriate. s/probably/certainly/ for ICANN and IANA. The "giant piece of policy on behalf of IETF" has about 3100 lines and 130 KB, it is your draft -09. > Registration requests are each considered on their own > merits, based on the need to identify a language. The > presence, absence or contents of any particular subtag and > its associated fields in the registry do not imply a position > on the legal status of any language, script, country, > territory, region, or language variation. Nor do they endorse > any particular position regarding the legal status, > authority, frontiers, boundaries, or policies of any > particular country or region. That's horrible EULA language, I prefer to delete the complete draft and close the WG without results. The BCP 78 / 79 legal boilerplates are already excessively annoying, imitating this style voluntarily is FUBAR. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 21:25:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtxuO-0006U7-1o; Sat, 16 Jul 2005 21: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 1DtxuN-0006TW-01 for ltru@megatron.ietf.org; Sat, 16 Jul 2005 21:25:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12501 for ; Sat, 16 Jul 2005 21:25:29 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtyNV-0004xS-0f for ltru@ietf.org; Sat, 16 Jul 2005 21:55:37 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtxuJ-0003zl-7c; Sat, 16 Jul 2005 18:25:27 -0700 Message-Id: <6.2.1.2.2.20050717013518.04a58e20@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 17 Jul 2005 03:25:14 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UN disclaimer In-Reply-To: <001701c58a59$5d17f220$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050716222308.04b0dc50@mail.afrac.org> <001701c58a59$5d17f220$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 - afrac.org X-Spam-Score: 0.0 (/) 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 At 00:54 17/07/2005, Randy Presuhn wrote: > > Does the following description describes your intent as described by Randy: > > > > "The Draft proposed by the WG-ltru at this stage, does not intent to > ...snip... > > The WG-ltru feels that considering that there would be copyright issues > > would be far-fetched". > >A twisted reading if ever there was. You will note that if this is the case, I ask for guidance in correcting it. I will therefore only quote your text, but out of context it may present your position in a lesser correct way? You welcome to phrase it the way you want to to appear, if the meaning is unchanged. Can I be more loyal to you and to this WG? >In any case, if you're trying to pretend that you're doing liaison work, I am not. As you point it out, participation in the IETF is personal. I have no capacity in acting as the IETF's liaison to these various organisations. I have deep ethical and technical concerns about this Draft and what _I_ consider as its disregard of the Charter. I beleived that in spite of our oppositions and the lack of debate on the missions assigned by the Charter, the WG Last Call would permit to positively address them. I see this will not be the case. >I recommend conferring with the IETF's liaisons to the various >organizations. See http://www.ietf.org/liaisonActivities.html You perfectly know that as an individual I have no reason to do so. I will suggest however that their are copied of the letters which may be of interest to them. Best regards. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 21:25:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtxuO-0006Ua-7X; Sat, 16 Jul 2005 21: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 1DtxuN-0006Tb-2v for ltru@megatron.ietf.org; Sat, 16 Jul 2005 21:25:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12502 for ; Sat, 16 Jul 2005 21:25:29 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtyNV-0004xU-0b for ltru@ietf.org; Sat, 16 Jul 2005 21:55:37 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtxuK-0003zl-Ap; Sat, 16 Jul 2005 18:25:28 -0700 Message-Id: <6.2.1.2.2.20050717020208.04a62e50@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 17 Jul 2005 02:27:19 +0200 To: "Peter Constable" , "LTRU Working Group" From: r&d afrac Subject: RE: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN disclaimer 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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 00:32 17/07/2005, Peter Constable wrote: > > If you consider a contributing member as an applauding member I am > > certainly not. > >Nobody has said you must applaud. Most of the people here have >contributed on occasions when they disagreed with proposed text. Dear Peter, As you note it below, this thread is following a contribution of mine. > > address the Charter. Points not considering the Charter are purely > > disruptive IMO. This confusion about locales enters into that > > categories. CLDR _is_ in the Charter. > >In case you haven't noticed, this thread is about adoption of text you >derived from the UN site; it has nothing to do with locales or CLDR. Your remarks using this threat was opposing another contribution I made on CLDR. > > You should know after all these months that I am not intimidated >easily. > >Nor anybody else here. I am glad of that. So, why not to continue considering the things seriously. > > - there is a precise description of the intent to use ISO and UN codes > > in a different way than their initial purpose, and my opinion, in an > > opposed way to the intent of their authors. > >You have not demonstrated this in the slightest. If you refer to the different way, this was expressed. If you refer to the opposed way, this is true. If I demonstrated it, it would not be an opinion. > > None of these authors has intended to see established a published > correlation between languages, scripts and countries. > >On the contrary, the ISO 639 standards explicitly state that >applications may find utility in using ISO 639 identifiers in >conjunction with ISO 3166 identifiers. (ISO/DIS 639-3 also makes >reference to ISO 15924 script identifiers.) Quoting from clause 4.4 of >ISO 639-1:2002: > >"Language identifiers according to this part of ISO 639 may be combined >with identifiers according to ISO 3166 to denote the area (country or >subdivision of a country) in which a term, phrase or language is used." > >See likewise clause 4.4 of ISO 639-2:1998, clause 8.1 of ISO/CD 639-4 >(wrt ISO 3166) and clause 8.3 of the same (wrt ISO 15924). I will not claim you "distort" what I said. I will only ask you to reread it and to consider if your response is adequate, as in the previous case you did not answer. We are again in the case where I say something general and you respond on a small specific. There is a major difference between an application which "may do a particular correlation" and a standard which publish a general correlation. Also, I suggest that do not use ISO 639-3 and ISO 639-4 except when refering to the current status of the debate. We will reach nothing conclusive if you do that. > > - there is a clear opposition of mine to this on ethical and technical > > grounds. And a clear opposition, should the document be agreed, on > > legal grounds which will be addressed at IANA level. This strictly > > belongs to the > > Charter which is to establish a Registry in correcting RFC 3066. > >Sticking to the point, this concern on your part does not support your >claim that there has been intent to tamper with code sets defined in ISO >or UN standards. I am sorry but if "a differing organization of data, the omission of some elements, the addition of other elements, and a differing scope of application" does not mean "to play around with" the concerned data, I am lost about the intent. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 16 21:25:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtxuO-0006Uy-CR; Sat, 16 Jul 2005 21: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 1DtxuN-0006Tr-Ci for ltru@megatron.ietf.org; Sat, 16 Jul 2005 21:25:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12506 for ; Sat, 16 Jul 2005 21:25:29 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtyNV-0004xe-F7 for ltru@ietf.org; Sat, 16 Jul 2005 21:55:37 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DtxuL-0003zl-Id; Sat, 16 Jul 2005 18:25:29 -0700 Message-Id: <6.2.1.2.2.20050717024207.045581e0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 17 Jul 2005 02:53:23 +0200 To: "Mark Davis" , "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales In-Reply-To: <02d201c58a67$203843b0$fc763009@sanjose.ibm.com> References: <634978A7DF025A40BFEF33EB191E13BC0C20D846@irvmbxw01.quest.com> <002001c58a2f$2382d540$7f1afea9@oemcomputer> <02d201c58a67$203843b0$fc763009@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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA12506 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 can only repeat my proposition which is to remove every allusion to=20 locales. A part from CLDR being quoted in the Charter, I do not see what=20 locales have specifically to do with langtags? There are hundreds of uses of langtags, are we to discuss them all? I wou= ld=20 certainly better define the scope of the Draft, but I suspect most in her= e=20 would not support the idea. May be a phrase like "although a language tag is construed from a primary= =20 language subtag, an optional script subtag and a regional subtag and may=20 have for that reasons a syntactic resemblance to various identifiers, no=20 particular relation should be infered between these identifiers and=20 language tags", or some general case similar wording, would address the=20 point as a generic problem? jfc At 02:33 17/07/2005, Mark Davis wrote: >I disagree with the proposal. I can understand your reasoning, but the >proposed paragraph doesn't quite work. We are better off just keeping th= e >text as it is, rather than open up a -- I suspect -- long discussion abo= ut >locales. Part of the problem is that 'locale IDs' are not a single conce= pt; >there is very broad variance in what they mean and how they are used. > > > "Although a language tag constructed from a primary language subtag > > followed by a region subtag bears a syntactic resemblance to a locale > > identifier, their semantics and usage are different." > >=E2=80=8EMark > >----- Original Message ----- >From: "Randy Presuhn" >To: "LTRU Working Group" >Sent: Saturday, July 16, 2005 10:52 >Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between >languagetags and locales > > > > Hi - > > > > As co-chair: > > Ok, there seems to be no support for (and strong opposition to) Jefse= y's >proposed addition. > > I see no need for further discussion of it unless someone else out th= ere >thinks it's a > > really good idea. > > > > As technical contributor: > > Can we get back to the original issues in this discussion? Addison h= ad >said: > > > > > I think there is no need to add any text; there is already some tex= t > > > (in the section on extensions) which says that this is somewhat the > > > case. Implementations that choose to coerce locales (local programm= ing > > > constructs) from language tags are free to do so. > > > > I responded by saying that I don't find what's currently there >particularly helpful. > > The current i-d says: > > > > |3.6 Extensions and Extensions Namespace > > | > > | Extension subtags are those introduced by single-letter subtags o= ther > > | than 'x'. They are reserved for the generation of identifiers wh= ich > > | contain a language component, and are compatible with application= s > > | that understand language tags. For example, they might be used t= o > > | define locale identifiers, which are generally based on language. > > > > The first part is fine, but that last sentence is not particularly >enlightening. > > Language is probably the most important thing specified by a locale, > > but saying locales are "based on language" won't help those who are a= t > > all confused about the relationship. I hope this isn't the best exam= ple > > of how we envision extensions being used. > > > > I suggest deleting this example (or replacing it with something more > > enlightening) and adding the following paragraph as the second > > paragraph in section 2.2.4 (Region Subtag). This is *revised* from > > my earlier proposal: > > > > "Although a language tag constructed from a primary language subtag > > followed by a region subtag bears a syntactic resemblance to a locale > > identifier, their semantics and usage are different." > > > > 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@lists.ietf.org Sat Jul 16 23:03:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtzQy-0005Cs-3j; Sat, 16 Jul 2005 23:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtzQv-00057V-NW for ltru@megatron.ietf.org; Sat, 16 Jul 2005 23:03:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16710 for ; Sat, 16 Jul 2005 23:03:09 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dtzu1-0001aX-7r for ltru@ietf.org; Sat, 16 Jul 2005 23:33:19 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6H32rI08870; Sun, 17 Jul 2005 12:02:53 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id f05760e2_f670_11d9_858e_0030482532aa_16455; Sun, 17 Jul 2005 12:14:51 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0004B6; 17 Jul 05 12:08:39 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 17 Jul 05 12:08:30 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.250.3) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0004B2; 17 Jul 05 12:08:19 +0900 Message-Id: <6.0.0.20.2.20050717112623.07202d00@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sun, 17 Jul 2005 11:27:29 +0900 To: "Addison Phillips" , "Randy Presuhn" , From: Martin Duerst Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C20D847@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C20D847@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: 6ffdee8af20de249c24731d8414917d3 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 I guess I could live with that (I very much agree with the sentiment, but I think it's much more actual practice, past, present, and future, than nice words, that will be judged). Regards, Martin. At 00:55 05/07/17, Addison Phillips wrote: >Might I suggest: > >I think that including a giant piece of policy on behalf of IETF, ICANN, >and IANA is probably inappropriate. However, I *can* see draft-registry >making the statement that the registration process does not endorse any >particular position and that registrations will be considered on an equal >basis. The resulting text would be more useful. Perhaps: > > >Registration requests are each considered on their own merits, based on >the need to identify a language. The presence, absence or contents of any >particular subtag and its associated fields in the registry do not imply a >position on the legal status of any language, script, country, territory, >region, or language variation. Nor do they endorse any particular position >regarding the legal status, authority, frontiers, boundaries, or policies >of any particular country or region. This includes any issues pertaining to >the identity or usage of any language or script within any country or region. > >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 Martin Duerst >> Sent: 2005?7?16? 5:10 >> To: Randy Presuhn; ltru@ietf.org >> Subject: Re: [Ltru] Last call: IANA adaptation of the UN disclaimer >> >> [chair hat off] >> >> I have to agree with Randy. Besides his arguments, I'd also >> like to mention that neither RFC 1766 nor RFC 3066 had any >> such disclaimer. Also, I'm affraid that if somebody with a >> traditional IETF background finds this paragraph, we might >> get some serious IETF Last Call comments. >> >> Also, if (as JFC thinks) this is something for the IANA/ >> ICANN/watever lawyers, then it's best if we keep out of it. >> If asked for, we can point to the various text proposals in >> the mailing list archive. >> >> Regards, Martin. >> >> At 05:55 05/07/16, Randy Presuhn wrote: >> >Hi - >> > >> >> From: "Addison Phillips" >> >> To: "Peter Constable" ; >> >> Sent: Friday, July 15, 2005 11:29 AM >> >> Subject: RE: [Ltru] Last call: IANA adaptation of the UN disclaimer >> >> >> >> The purpose and point of this text I agree with, but the form of the >> text >> >> is not in keeping with the terminology or form of the rest of the >> document. >> >> It is nearly incomprehensible. >> >> >> >> How about replacing your second paragraph with: >> >> >> >> The presence, absence or contents of subtags and their associated >> fields >> >> in the registry do not and should not be taken to imply an opinion on >> the >> >part of >> >> the IETF, ICANN and IANA concerning the legal status of any language, >> script, >> >> country, territory, region, or language variation. Nor should they be >> taken to >> >> endorse any particular position regarding the legal status, authority, >> >frontiers, >> >> boundaries, or cultural, political, economical, or educational >> policies of any >> >> particular country or region. This includes any issues pertaining to >> the >> >identity >> >> or usage of any language or script within any country or region. >> >... >> > >> >As a technical contributor, I think there adding this text contributes >> no value >> >to the document, and could in the longer term be harmful, regardless of >> >its benign intent and content. >> > >> >None of the other IANA registries I've looked at has anything like this. >> >As a very concrete example, the enterprise number registry at >> >http://www.iana.org/assignments/enterprise-numbers doesn't have >> >lawerly verbiage about trademarks or the legal status of enterprise >> names. >> >Similarly, http://www.iana.org/assignments/ianaaddressfamilynumbers-mib >> >doesn't fret about trademarks. Not even >> http://www.iana.org/assignments/idn/ >> >goes through such hand-wringing. I think adding material like this >> would >> >set a very bad precedent, because it could lead to folks misconstruing >> >the absence of such disclaimers in other IANA-maintained registries. >> > >> >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@lists.ietf.org Sat Jul 16 23:48:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du08g-0002p9-92; Sat, 16 Jul 2005 23:48:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du08e-0002p4-Aj for ltru@megatron.ietf.org; Sat, 16 Jul 2005 23:48:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18228 for ; Sat, 16 Jul 2005 23:48:21 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du0bn-00041g-DQ for ltru@ietf.org; Sun, 17 Jul 2005 00:18:31 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jul 2005 20:48:13 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jul 2005 20:48:14 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN disclaimer Date: Sat, 16 Jul 2005 20:48:16 -0700 Message-ID: Thread-Topic: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN disclaimer Thread-Index: AcWKbms1oaYQioUlQA+onk+rjkoRqAAD+JZg From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 17 Jul 2005 03:48:14.0287 (UTC) FILETIME=[5BF19DF0:01C58A82] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 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: r&d afrac [mailto:rd@afrac.org] > If I demonstrated it, it would not be an opinion. Since you have not demonstrated that ISO or UN standards are being used contrary the their designed intent, your statement to that effect is mere opinion. And your misconstrual of what Randy had said regarding our use of ISO and UN standards borders, IMO, on innuendo. > > > None of these authors has intended to see established a published > > correlation between languages, scripts and countries. > > > >On the contrary, the ISO 639 standards explicitly state... > I will not claim you "distort" what I said. I will only ask you to reread > it and to consider if your response is adequate Yes, my response is adequate. You said that the authors of the relevant ISO and UN standards have not "intended to see established a published correlation between languages, scripts and countries." My response demonstrates that the is simply false. > Also, I suggest that do not use ISO 639-3 and ISO 639-4 except when > refering to the current status of the debate. We will reach nothing > conclusive if you do that. I referred to ISO 639-4 precisely because you mentioned it first in this context: "None of these authors has intended to see established a published correlation between languages, scripts and countries. This point is risen in ISO 639-4..." I will be happy to stop mentioning ISO 639-4 if you will stop mentioning it. But if you continue to make incorrect statements regarding that or other parts of ISO 639, I will consider myself perfectly free to mention whichever of those standards and set the record straight. > > > - there is a clear opposition of mine to this on ethical and technical > > > grounds. And a clear opposition, should the document be agreed, on > > > legal grounds which will be addressed at IANA level. This strictly > > > belongs to the > > > Charter which is to establish a Registry in correcting RFC 3066. > > > >Sticking to the point, this concern on your part does not support your > >claim that there has been intent to tamper with code sets defined in ISO > >or UN standards. >=20 > I am sorry but if "a differing organization of data... Your response to my comment addresses a different topic. > , the omission of some > elements, the addition of other elements, and a differing scope of > application" does not mean "to play around with" the concerned data, I am > lost about the intent. Only you can know what you mean by "play around with"; but that is not what we have been discussing. Rather, we have been discussing your characterization of Randy's statement -- > >False. If we were imitating the structure of the ISO or UN directories, > >such a claim might almost be plausible. With a differing organization of > >data, the omission of some elements, the addition of other elements, and=20 > >a differing scope of application, any claim of copyright infringement > >would be rather far-fetched. >=20 > Thank you for so exactly describing your intent to tamper with the=20 > intended usage of the codes. and your subsequent statement > - there is a precise description of the intent to use ISO and UN codes > in a > different way than their initial purpose, and my opinion, in an > opposed way > to the intent of their authors. Randy's statement in no way implied "tampering with the intended usage of codes". You have in no way demonstrated that we are using any of the codes in a manner different from their initial purpose of the intent of the authors of the relevant standards. As for your being lost regarding the intent of this working group, it has been clear for months that you have significant objections with many of the decisions of this working group. In several of those cases, it has been evident that either you have not agreed with some of the basic intents of this working group, or you have not understood what those basic intents are. For instance, you could not have asked that we allow tags containing "." unless you either disagreed with or did not understand the basic intent that this working group has had since inception that backward compatibility with RFC 3066 be maintained. I don't know to what extent you understand but disagree and to what extent you simply don't understand. But it would not surprise me to learn that you were lost about the intent. Please stop misconstruing what Randy or others say. That's all I feel the need to say. Any further discussion would not, I think, contribute to the goals of this WG, so I will not respond further on this thread. Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 17 00:58:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du1Eq-00009H-KL; Sun, 17 Jul 2005 00:58:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du1En-000096-I3 for ltru@megatron.ietf.org; Sun, 17 Jul 2005 00:58:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20285 for ; Sun, 17 Jul 2005 00:58:46 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du1hw-0007gY-EM for ltru@ietf.org; Sun, 17 Jul 2005 01:28:57 -0400 Received: from h-64-105-34-184.snvacaid.dynamic.covad.net ([64.105.34.184] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Du1Eh-000364-00 for ltru@ietf.org; Sun, 17 Jul 2005 00:58:43 -0400 Message-ID: <001501c58a8c$3fcbc2e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <02ec01c58a67$33ead620$fc763009@sanjose.ibm.com> Subject: Re: [Ltru] Re: [psg.com #1077] deprecate grandfathered zh-guoyu Date: Sat, 16 Jul 2005 21:59:01 -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: 1ac7cc0a4cd376402b85bc1961a86ac2 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 - Given the support expressed and the lack of controversy regarding this proposal, I've marked this issue "resolved". The editor will include the necessary edits in the next version of the initial registry i-d, to be issued upon completion of this WG last call. If you believe further discussion of this topic is needed, please include the issue number in your subject line. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 17 01:14:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du1U0-0005Kd-0e; Sun, 17 Jul 2005 01:14:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du1Tu-0005KX-Qn for ltru@megatron.ietf.org; Sun, 17 Jul 2005 01:14:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20943 for ; Sun, 17 Jul 2005 01:14:25 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du1x3-0008Ih-IQ for ltru@ietf.org; Sun, 17 Jul 2005 01:44:34 -0400 Received: from h-64-105-34-184.snvacaid.dynamic.covad.net ([64.105.34.184] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Du1Ts-00067J-00 for ltru@ietf.org; Sun, 17 Jul 2005 01:14:24 -0400 Message-ID: <001a01c58a8e$6ff14880$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C20D846@irvmbxw01.quest.com> <002001c58a2f$2382d540$7f1afea9@oemcomputer> <02d201c58a67$203843b0$fc763009@sanjose.ibm.com> Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between language tags and locales Date: Sat, 16 Jul 2005 22:14: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.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: "Mark Davis" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Saturday, July 16, 2005 5:33 PM > Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales > > I disagree with the proposal. I can understand your reasoning, but the > proposed paragraph doesn't quite work. We are better off just keeping the > text as it is, rather than open up a -- I suspect -- long discussion about > locales. Part of the problem is that 'locale IDs' are not a single concept; > there is very broad variance in what they mean and how they are used. ... As a compromise, then, if we don't explain that locales should not be confused with language tags, could we at least delete the following sentence from section 3.6 of the registry i-d? "For example, they might be used to define locale identifiers, which are generally based on language." This example confuses rather than enlightens, leading the tiro to invert the relationship between locale and language, leading to the need to explain how locale identification and language tagging should not be confused. For me, at least, removing that sentence would be an acceptable resolution of this item. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 17 01:20:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du1Zx-0007G2-Mz; Sun, 17 Jul 2005 01:20:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du1Zv-0007Fx-Eu for ltru@megatron.ietf.org; Sun, 17 Jul 2005 01:20:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21155 for ; Sun, 17 Jul 2005 01:20:38 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du235-00005b-7n for ltru@ietf.org; Sun, 17 Jul 2005 01:50:47 -0400 Received: from h-64-105-34-184.snvacaid.dynamic.covad.net ([64.105.34.184] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Du1Zt-0006wq-00 for ltru@ietf.org; Sun, 17 Jul 2005 01:20:37 -0400 Message-ID: <002301c58a8f$4fbd7560$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C20D846@irvmbxw01.quest.com> <002001c58a2f$2382d540$7f1afea9@oemcomputer> <02d201c58a67$203843b0$fc763009@sanjose.ibm.com> <6.2.1.2.2.20050717024207.045581e0@mail.afrac.org> Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales Date: Sat, 16 Jul 2005 22:20: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.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 Hi - > From: "r&d afrac" > To: "Mark Davis" ; "Randy Presuhn" ; "LTRU Working Group" > Sent: Saturday, July 16, 2005 5:53 PM > Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales > > I can only repeat my proposition which is to remove every allusion to > locales. A part from CLDR being quoted in the Charter, I do not see what > locales have specifically to do with langtags? I think we almost agree on this point! The word "locale" appears in several locations in the i-d. I think the only one that is problematic is this one from section 3.6: "For example, they might be used to define locale identifiers, which are generally based on language." This sentence could safely be eliminated, as it has no normative significance, and doing so would remove any need to talk about what locales are or are not. > There are hundreds of uses of langtags, are we to discuss them all? I would > certainly better define the scope of the Draft, but I suspect most in here > would not support the idea. > > May be a phrase like "although a language tag is construed from a primary > language subtag, an optional script subtag and a regional subtag and may > have for that reasons a syntactic resemblance to various identifiers, no > particular relation should be infered between these identifiers and > language tags", or some general case similar wording, would address the > point as a generic problem? ... This text (with minor tweaks) would work for me, but I think removing the sentence from section 3.6 would be better, and more likely to get agreement. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 17 01:52:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du24X-0000ak-4v; Sun, 17 Jul 2005 01: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 1Du24W-0000af-KF for ltru@megatron.ietf.org; Sun, 17 Jul 2005 01:52:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22125 for ; Sun, 17 Jul 2005 01:52:15 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du2Xg-0001dS-DO for ltru@ietf.org; Sun, 17 Jul 2005 02:22:24 -0400 Received: from h-64-105-34-184.snvacaid.dynamic.covad.net ([64.105.34.184] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Du24U-0003mB-00 for ltru@ietf.org; Sun, 17 Jul 2005 01:52:14 -0400 Message-ID: <004201c58a93$ba416280$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C20D847@irvmbxw01.quest.com> <42D9B18F.37B2@xyzzy.claranet.de> Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UN disclaimer Date: Sat, 16 Jul 2005 22:52: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: cab78e1e39c4b328567edb48482b6a69 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 - As a contributor... > From: "Frank Ellermann" > To: > Sent: Saturday, July 16, 2005 6:17 PM > Subject: [Ltru] Re: Last call: IANA adaptation of the UN disclaimer ... > > Registration requests are each considered on their own > > merits, based on the need to identify a language. The > > presence, absence or contents of any particular subtag and > > its associated fields in the registry do not imply a position > > on the legal status of any language, script, country, > > territory, region, or language variation. Nor do they endorse > > any particular position regarding the legal status, > > authority, frontiers, boundaries, or policies of any > > particular country or region. > > That's horrible EULA language, I prefer to delete the complete > draft and close the WG without results. The BCP 78 / 79 legal > boilerplates are already excessively annoying, imitating this > style voluntarily is FUBAR. ... Would you be able to accept it if reduced to this? Registration requests are to be considered on their own merits, based on the need to identify a language. Or would you be happier with no addition at all in resolution of this issue? I am concerned that adding all that other stuff, and perhaps even such a benign-sounding sentence as the above, runs the risk of making the review process more subject to frivolous appeal or DoS attacks, especially since there was no consensus to accept issue #1039. I'm coming to prefer no addition at all. I could live with the single- sentence statement above, if that will bring us to a rough consensus. I dislike the longer one quoted above, though not as intensely as the original proposal. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 17 02:09:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du2LW-0006O5-8W; Sun, 17 Jul 2005 02: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 1Du2LU-0006LH-KP for ltru@megatron.ietf.org; Sun, 17 Jul 2005 02:09:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02216 for ; Sun, 17 Jul 2005 02:09:47 -0400 (EDT) Received: from pop-tawny.atl.sa.earthlink.net ([207.69.195.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du2of-0002YA-49 for ltru@ietf.org; Sun, 17 Jul 2005 02:39:57 -0400 Received: from h-64-105-34-184.snvacaid.dynamic.covad.net ([64.105.34.184] helo=oemcomputer) by pop-tawny.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Du2LO-00066Q-00 for ltru@ietf.org; Sun, 17 Jul 2005 02:09:42 -0400 Message-ID: <006101c58a96$2b52c7a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C20D829@irvmbxw01.quest.com> Subject: Re: [Ltru] [psg.com #1075] WGLC section 3.6 specification requirementsfor extensions Date: Sat, 16 Jul 2005 23:10:01 -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: 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 Hi - Addison's proposed text is: Single-letter subtags are to be assigned by IANA using the "IETF Consensus" policy defined by RFC 2434. This policy requires the development of an RFC, which SHALL define the name, purpose, processes, and procedures for maintaining the subtags. The maintaining or registering authority, including name, contact email, discussion list email, and URL location of the registry MUST be indicated clearly in the RFC. The RFC MUST specify or include each of the following: This works for me, though I suggest very minor wordsmithing at the editor's discretion: Single-letter subtags are to be assigned by IANA using the "IETF Consensus" policy defined by RFC 2434. This policy requires an RFC, approved by the IESG. Such an RFC MUST define the name, purpose, processes, and procedures for maintaining the subtag(s). The maintaining or registering authority, including name, contact email, discussion list email, and URL location of the registry MUST be indicated clearly in the RFC. The RFC MUST specify or include each of the following: Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 17 03:09:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du3H8-0000NN-KS; Sun, 17 Jul 2005 03:09:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du3H6-0000MB-3w for ltru@megatron.ietf.org; Sun, 17 Jul 2005 03: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 DAA16826 for ; Sun, 17 Jul 2005 03:09:17 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Du3H0-0000Eh-Uq for ltru@lists.ietf.org; Sun, 17 Jul 2005 09:09:14 +0200 Received: from 212.82.251.59 ([212.82.251.59]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jul 2005 09:09:14 +0200 Received: from nobody by 212.82.251.59 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 17 Jul 2005 09:09:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Sun, 17 Jul 2005 09:08:16 +0200 Organization: Lines: 21 Message-ID: <42DA03E0.47C5@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C20D847@irvmbxw01.quest.com> <42D9B18F.37B2@xyzzy.claranet.de> <004201c58a93$ba416280$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.59 X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1073] Last call: IANA adaptation of the UN disclaimer X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > Would you be able to accept it if reduced to this? > Registration requests are to be considered on their own > merits, based on the need to identify a language. That's fine... > Or would you be happier with no addition at all in resolution > of this issue? ...better. Anything that doesn't sound like an EULA or the legal boilerplate. There should be some room for judgement calls by the language list and the language tag reviewer. > I'm coming to prefer no addition at all. I could live with > the single-sentence statement above, if that will bring us > to a rough consensus. Same here. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 17 09:56:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du9dK-00069e-Lv; Sun, 17 Jul 2005 09:56:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du9dI-00069R-Fw for ltru@megatron.ietf.org; Sun, 17 Jul 2005 09:56:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04755 for ; Sun, 17 Jul 2005 09:56:38 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuA6X-00089j-0b for ltru@ietf.org; Sun, 17 Jul 2005 10:26:53 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Du9dC-0002kf-Lm; Sun, 17 Jul 2005 06:56:35 -0700 Message-Id: <6.2.1.2.2.20050717112503.04e75280@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 17 Jul 2005 13:34:21 +0200 To: "Randy Presuhn" , From: r&d afrac Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UN disclaimer In-Reply-To: <004201c58a93$ba416280$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C20D847@irvmbxw01.quest.com> <42D9B18F.37B2@xyzzy.claranet.de> <004201c58a93$ba416280$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Randy, the point I try to make is that this Draft should be judged on its on technical merits at the IETF Last Call and during the legal round. This means that it should show it has also taken into account its heavily politically loaded character. To do that it is to include appropriate legal language, copyright mentions and political disclaimers. My propositions are to permit the Draft not to be rejected in block (again I only disagree on "replace/complement" RFC 3066). May be I have not been clear enough. My proposition is not to introduce final texts, but to introduce texts at appropriate places with the appropriate concerns and then to leave to the appropriate reviewers the care to craft the final appropriate wording. . The Draft is intended to be published, so this wording cannot be in the IANA section only. May be a simple solution would be to enter mentions to the Editors (who ever they will be at whatever technical, legal, political level) under the form "[the WG thinks there might be a text needed here to possibly address the following concerns by the IETF liaison with, the IASA lawyers, the IANA lawyers, ICANN, GAC]". jfc. At 07:52 17/07/2005, Randy Presuhn wrote: >Hi - > >As a contributor... > > > From: "Frank Ellermann" > > To: > > Sent: Saturday, July 16, 2005 6:17 PM > > Subject: [Ltru] Re: Last call: IANA adaptation of the UN disclaimer >... > > > Registration requests are each considered on their own > > > merits, based on the need to identify a language. The > > > presence, absence or contents of any particular subtag and > > > its associated fields in the registry do not imply a position > > > on the legal status of any language, script, country, > > > territory, region, or language variation. Nor do they endorse > > > any particular position regarding the legal status, > > > authority, frontiers, boundaries, or policies of any > > > particular country or region. > > > > That's horrible EULA language, I prefer to delete the complete > > draft and close the WG without results. The BCP 78 / 79 legal > > boilerplates are already excessively annoying, imitating this > > style voluntarily is FUBAR. >... > >Would you be able to accept it if reduced to this? > Registration requests are to be considered on their own > merits, based on the need to identify a language. > >Or would you be happier with no addition at all in resolution of this issue? > >I am concerned that adding all that other stuff, and perhaps even such >a benign-sounding sentence as the above, runs the risk of making the >review process more subject to frivolous appeal or DoS attacks, >especially since there was no consensus to accept issue #1039. > >I'm coming to prefer no addition at all. I could live with the single- >sentence statement above, if that will bring us to a rough consensus. >I dislike the longer one quoted above, though not as intensely as >the original proposal. > >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 Sun Jul 17 09:56:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du9dK-0006A1-RJ; Sun, 17 Jul 2005 09:56:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du9dJ-00069Z-Gg for ltru@megatron.ietf.org; Sun, 17 Jul 2005 09:56:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04760 for ; Sun, 17 Jul 2005 09:56:39 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuA6X-00089k-0X for ltru@ietf.org; Sun, 17 Jul 2005 10:26:54 -0400 Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Du9dD-0002kf-ND; Sun, 17 Jul 2005 06:56:36 -0700 Message-Id: <6.2.1.2.2.20050717153735.03b57900@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 17 Jul 2005 15:56:19 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] [psg.com #1075] WGLC section 3.6 specification requirementsfor extensions In-Reply-To: <006101c58a96$2b52c7a0$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C20D829@irvmbxw01.quest.com> <006101c58a96$2b52c7a0$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 - afrac.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 You must be aware that what an RFC can do, another can change it. What about RFC with particular ABNF accepting longer subtags than 8 alpha/num? jfc At 08:10 17/07/2005, Randy Presuhn wrote: >Hi - > >Addison's proposed text is: > >Single-letter subtags are to be assigned by IANA using the "IETF Consensus" >policy defined by RFC 2434. This policy requires the development of an RFC, >which SHALL define the name, purpose, processes, and procedures for >maintaining >the subtags. The maintaining or registering authority, including name, >contact email, >discussion list email, and URL location of the registry MUST be indicated >clearly in the >RFC. The RFC MUST specify or include each of the following: > >This works for me, though I suggest very minor wordsmithing at the editor's >discretion: > >Single-letter subtags are to be assigned by IANA using the "IETF Consensus" >policy defined by RFC 2434. This policy requires an RFC, approved by the IESG. >Such an RFC MUST define the name, purpose, processes, and procedures for >maintaining >the subtag(s). The maintaining or registering authority, including name, >contact email, >discussion list email, and URL location of the registry MUST be indicated >clearly in the >RFC. The RFC MUST specify or include each of the following: > >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 Sun Jul 17 11:59:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuBYM-0005ig-Kr; Sun, 17 Jul 2005 11:59:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuBYK-0005iV-9k for ltru@megatron.ietf.org; Sun, 17 Jul 2005 11:59:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10385 for ; Sun, 17 Jul 2005 11:59:35 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuC1W-0006T8-Er for ltru@ietf.org; Sun, 17 Jul 2005 12:29: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 j6HFxJJ0024022; Sun, 17 Jul 2005 08:59:19 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <39KLPWG2>; Sun, 17 Jul 2005 09:00:15 -0700 Message-ID: From: "McDonald, Ira" To: "'Frank Ellermann'" , ltru@ietf.org Subject: RE: [Ltru] Re: [psg.com #1073] Last call: IANA adaptation of the UN disclaimer Date: Sun, 17 Jul 2005 09:00: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: 7aafa0432175920a4b3e118e16c5cb64 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 agree with Frank and Randy that NO addition is the best choice. Anything that smells like legal boilerplate makes us vulnerable to endless non-technical wrangling in IESG last call. 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: Sunday, July 17, 2005 3:08 AM > To: ltru@ietf.org > Subject: [Ltru] Re: [psg.com #1073] Last call: IANA > adaptation of the UN > disclaimer > > > Randy Presuhn wrote: > > > Would you be able to accept it if reduced to this? > > Registration requests are to be considered on their own > > merits, based on the need to identify a language. > > That's fine... > > > Or would you be happier with no addition at all in resolution > > of this issue? > > ...better. Anything that doesn't sound like an EULA or the > legal boilerplate. There should be some room for judgement > calls by the language list and the language tag reviewer. > > > I'm coming to prefer no addition at all. I could live with > > the single-sentence statement above, if that will bring us > > to a rough consensus. > > Same here. 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 Sun Jul 17 12:42:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuCDx-0000Cn-VA; Sun, 17 Jul 2005 12:42:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuCDw-0000Ci-1o for ltru@megatron.ietf.org; Sun, 17 Jul 2005 12:42:40 -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 MAA12055 for ; Sun, 17 Jul 2005 12:42:36 -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 <20050717164208.EKFE29002.mta9.adelphia.net@DEWELL> for ; Sun, 17 Jul 2005 12:42:08 -0400 Message-ID: <003401c58aee$5d94a780$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050717061124.CEGT4366.mta6.adelphia.net@megatron.ietf.org> Date: Sun, 17 Jul 2005 09:41: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: [psg.com #1077] deprecate grandfathered zh-guoyu X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > Given the support expressed and the lack of controversy regarding this > proposal, I've marked this issue "resolved". The editor will include > the necessary edits in the next version of the initial registry i-d, > to be issued upon completion of this WG last call. This change has been made in the editor's copy of draft-initial-03. -- 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 Jul 17 13:53:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuDK8-0000jB-Ev; Sun, 17 Jul 2005 13:53:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuDK7-0000j6-9W for ltru@megatron.ietf.org; Sun, 17 Jul 2005 13:53:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14788 for ; Sun, 17 Jul 2005 13:53:05 -0400 (EDT) Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuDnL-0003wk-Ug for ltru@ietf.org; Sun, 17 Jul 2005 14:23:22 -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 j6HHqpb8015011 for ; Sun, 17 Jul 2005 13:52:51 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6HHqpVX243028 for ; Sun, 17 Jul 2005 13:52:51 -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 j6HHqpgl019191 for ; Sun, 17 Jul 2005 13:52:51 -0400 Received: from markdavis (sig-9-48-123-224.mts.ibm.com [9.48.123.224]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with SMTP id j6HHqnds019154; Sun, 17 Jul 2005 13:52:51 -0400 Message-ID: <033501c58af8$570efe10$fc763009@sanjose.ibm.com> From: "Mark Davis" To: "Randy Presuhn" , "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C20D846@irvmbxw01.quest.com><002001c58a2f$2382d540$7f1afea9@oemcomputer><02d201c58a67$203843b0$fc763009@sanjose.ibm.com> <001a01c58a8e$6ff14880$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales Date: Sun, 17 Jul 2005 10:52:45 -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.1506 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by e1.ny.us.ibm.com id j6HHqpb8015011 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 While true, and illustrative, I have no problem with removing it. =E2=80=8EMark ----- Original Message -----=20 From: "Randy Presuhn" To: "LTRU Working Group" Sent: Saturday, July 16, 2005 22:14 Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales > Hi - > > > From: "Mark Davis" > > To: "Randy Presuhn" ; "LTRU Working Gro= up" > > Sent: Saturday, July 16, 2005 5:33 PM > > Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales > > > > > I disagree with the proposal. I can understand your reasoning, but th= e > > proposed paragraph doesn't quite work. We are better off just keeping the > > text as it is, rather than open up a -- I suspect -- long discussion about > > locales. Part of the problem is that 'locale IDs' are not a single concept; > > there is very broad variance in what they mean and how they are used. > ... > > As a compromise, then, if we don't explain that locales should not be > confused with language tags, could we at least delete the following sentence from > section 3.6 of the registry i-d? "For example, they might be used to define > locale identifiers, which are generally based on language." This examp= le confuses > rather than enlightens, leading the tiro to invert the relationship between > locale and language, leading to the need to explain how locale identification > and language tagging should not be confused. For me, at least, removin= g that > sentence would be an acceptable resolution of this item. > > 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 Sun Jul 17 14:36:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuE0A-0002zk-DQ; Sun, 17 Jul 2005 14:36:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuE09-0002zA-Jc for ltru@megatron.ietf.org; Sun, 17 Jul 2005 14:36:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16708 for ; Sun, 17 Jul 2005 14:36: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.43) id 1DuETN-0006R6-7q for ltru@ietf.org; Sun, 17 Jul 2005 15:06:46 -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 Jul 2005 11:36:15 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales Date: Sun, 17 Jul 2005 11:36:14 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D862@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1067] Last call: clarification between languagetags and locales Thread-Index: AcWKjpePMOrJuZt+TwKqJymCR2V4LwAb8tIg From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 17 Jul 2005 18:36:15.0954 (UTC) FILETIME=[6A4ACB20:01C58AFE] 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 +1 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: 2005?7?16? 22:15 > To: LTRU Working Group > Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between > languagetags and locales >=20 > Hi - >=20 > > From: "Mark Davis" > > To: "Randy Presuhn" ; "LTRU Working = Group" > > > Sent: Saturday, July 16, 2005 5:33 PM > > Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between > languagetags and locales > > >=20 > > I disagree with the proposal. I can understand your reasoning, but = the > > proposed paragraph doesn't quite work. We are better off just = keeping > the > > text as it is, rather than open up a -- I suspect -- long discussion > about > > locales. Part of the problem is that 'locale IDs' are not a single > concept; > > there is very broad variance in what they mean and how they are = used. > ... >=20 > As a compromise, then, if we don't explain that locales should not be > confused with language tags, could we at least delete the following > sentence from > section 3.6 of the registry i-d? "For example, they might be used to > define > locale identifiers, which are generally based on language." This = example > confuses > rather than enlightens, leading the tiro to invert the relationship > between > locale and language, leading to the need to explain how locale > identification > and language tagging should not be confused. For me, at least, = removing > that > sentence would be an acceptable resolution of this item. >=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 Sun Jul 17 14:37:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuE0m-00036U-Mo; Sun, 17 Jul 2005 14:37:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuE0l-00036G-Cn for ltru@megatron.ietf.org; Sun, 17 Jul 2005 14:37:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16743 for ; Sun, 17 Jul 2005 14:37: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.43) id 1DuEU2-0006SD-H3 for ltru@ietf.org; Sun, 17 Jul 2005 15:07:26 -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 Jul 2005 11:37:00 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UNdisclaimer Date: Sun, 17 Jul 2005 11:36:59 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D863@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UNdisclaimer Thread-Index: AcWKk+0aIWVzE0S6R0OL5l7zqo5LBAAao74g From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 17 Jul 2005 18:37:00.0024 (UTC) FILETIME=[848F5780:01C58AFE] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 vote we omit the text altogether. 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: 2005?7?16? 22:53 > To: ltru@ietf.org > Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of the > UNdisclaimer >=20 > Hi - >=20 > As a contributor... >=20 > > From: "Frank Ellermann" > > To: > > Sent: Saturday, July 16, 2005 6:17 PM > > Subject: [Ltru] Re: Last call: IANA adaptation of the UN disclaimer > ... > > > Registration requests are each considered on their own > > > merits, based on the need to identify a language. The > > > presence, absence or contents of any particular subtag and > > > its associated fields in the registry do not imply a position > > > on the legal status of any language, script, country, > > > territory, region, or language variation. Nor do they endorse > > > any particular position regarding the legal status, > > > authority, frontiers, boundaries, or policies of any > > > particular country or region. > > > > That's horrible EULA language, I prefer to delete the complete > > draft and close the WG without results. The BCP 78 / 79 legal > > boilerplates are already excessively annoying, imitating this > > style voluntarily is FUBAR. > ... >=20 > Would you be able to accept it if reduced to this? > Registration requests are to be considered on their own > merits, based on the need to identify a language. >=20 > Or would you be happier with no addition at all in resolution of this > issue? >=20 > I am concerned that adding all that other stuff, and perhaps even such > a benign-sounding sentence as the above, runs the risk of making the > review process more subject to frivolous appeal or DoS attacks, > especially since there was no consensus to accept issue #1039. >=20 > I'm coming to prefer no addition at all. I could live with the single- > sentence statement above, if that will bring us to a rough consensus. > I dislike the longer one quoted above, though not as intensely as > the original proposal. >=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 Sun Jul 17 14:39:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuE3B-0003jr-Ri; Sun, 17 Jul 2005 14:39:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuE3A-0003jm-BA for ltru@megatron.ietf.org; Sun, 17 Jul 2005 14:39:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16940 for ; Sun, 17 Jul 2005 14:39: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.43) id 1DuEWR-0006cf-Dp for ltru@ietf.org; Sun, 17 Jul 2005 15:09:55 -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 Jul 2005 11:39:30 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Ltru] [psg.com #1075] WGLC section 3.6 specificationrequirementsfor extensions Date: Sun, 17 Jul 2005 11:39:30 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20D864@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1075] WGLC section 3.6 specificationrequirementsfor extensions Thread-Index: AcWK13NqIU1vheoVQpmN38elBHkaCAAJykSw From: "Addison Phillips" To: "r&d afrac" , "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 17 Jul 2005 18:39:30.0861 (UTC) FILETIME=[DE773DD0:01C58AFE] 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 Not if the RFC is governed by this one: read the Draft. Explicit = guidelines are provided. An RFC could try to override sections of RFC = 2026, but I doubt it would ever be approved (except as a replacement for = RFC 2026). 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 r&d afrac > Sent: 2005?7?17? 6:56 > To: Randy Presuhn; LTRU Working Group > Subject: Re: [Ltru] [psg.com #1075] WGLC section 3.6 > specificationrequirementsfor extensions >=20 > You must be aware that what an RFC can do, another can change it. What > about RFC with particular ABNF accepting longer subtags than 8 = alpha/num? > jfc >=20 > At 08:10 17/07/2005, Randy Presuhn wrote: > >Hi - > > > >Addison's proposed text is: > > > >Single-letter subtags are to be assigned by IANA using the "IETF > Consensus" > >policy defined by RFC 2434. This policy requires the development of = an > RFC, > >which SHALL define the name, purpose, processes, and procedures for > >maintaining > >the subtags. The maintaining or registering authority, including = name, > >contact email, > >discussion list email, and URL location of the registry MUST be = indicated > >clearly in the > >RFC. The RFC MUST specify or include each of the following: > > > >This works for me, though I suggest very minor wordsmithing at the > editor's > >discretion: > > > >Single-letter subtags are to be assigned by IANA using the "IETF > Consensus" > >policy defined by RFC 2434. This policy requires an RFC, approved by = the > IESG. > >Such an RFC MUST define the name, purpose, processes, and procedures = for > >maintaining > >the subtag(s). The maintaining or registering authority, including = name, > >contact email, > >discussion list email, and URL location of the registry MUST be = indicated > >clearly in the > >RFC. The RFC MUST specify or include each of the following: > > > >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@lists.ietf.org Mon Jul 18 03:49:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuQNo-00040D-Ej; Mon, 18 Jul 2005 03: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 1DuQNn-000408-AD for ltru@megatron.ietf.org; Mon, 18 Jul 2005 03:49:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18053 for ; Mon, 18 Jul 2005 03:49:45 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuQrA-0002RS-Hh for ltru@ietf.org; Mon, 18 Jul 2005 04:20:09 -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 j6I7neZm003486; Mon, 18 Jul 2005 10:49:41 +0300 (EEST) Message-ID: <42DB5F13.2090306@kotus.fi> Date: Mon, 18 Jul 2005 10:49:39 +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: Jefsey Morfin Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between language tags and locales References: <6.2.1.2.2.20050716140428.03aaeeb0@pop.online.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At your request, Mr. Morfin, I specifically agree with Randy's strong opposition. Erkki I. Kolehmainen Jefsey Morfin wrote: > OK, I will feed the troll ... > > On 04:23 16/07/2005, Randy Presuhn said: > >> > Proposed text - as insert for relation with IESG pending an IESG >> decision: >> > >> > "[Charter has explicitly said that langtags apply to HTML, XML, >> CLDR, etc. >> > This WG has identified that this point of the Charter is to be >> requalified. >> > In the case of CLDR, locales can certainly be described in using >> Langtags >> > as many other language and country related objects and processes, >> such as >> > publishing, reading, filtering, censoring, exchanging, communicating, >> > classifying text, book, records, identifying expertise in a language, >> > copyrights, etc. etc. However they also have the capacity to >> document non >> > language related issues such as colors on a display, sound of a >> > loudspeaker, process speed depending on a process pattern, default >> network >> > addresses, etc.. They also can be partly patented to support patented >> > processes. As such they may have to be identified in refering to patent >> > references the "x-" escape sequence could support woud it not be >> limited to >> > 8-alpha/num for retro-compatibility with the never used before patent >> > referencing. The WG hesitates to documents langtags for the CLDR and >> wishes >> > to exclude langtags considerations from its charter, reserving to >> locale >> > compilers the decision to use langtags as a part of, or an >> equivalent to, >> > localtag or not. Should localtags be confirmed as directly belonging >> the >> > Charter, a locale oriented "l-" final extension will be used where >> all the >> > subsequent dashes would not be part of the Draft ABNF, in order to >> accept >> > sequences of the form "-c-" included in some of the references to >> include.]" >> ... >> >> As co-chair: >> (1) For patent-related disclosure requirements, see >> http://www.ietf.org/rfc/rfc3979.txt >> (2) Specifying locales is clearly beyond our scope. > > > Difficult to understand in which context these two quotes are made. They > seem totally out of scope? > >> As a technical contributor, I think Jefsey's proposed addition would >> be counterproductive. reducing rather than improving the document's >> intellegibility. Consequently, I strongly oppose its inclusion. > > > Your priviledge. There must be a clearly expressed consensus, one way or > another. > > From what I understand you want to be able to use langtags to name > locales, without expressing any consideration on their structure, nor > permitting competitors to differentiate their propositions through the > reference of their IPRs? This is at least what I understand after > reading this many times. Difficult to get understand what you may oppose > since I say the same but leaving the IESG to say otherwise. Thx to tell > where I would be wrong reading you? > > An IPR lawyer suggests me: "he wants to keep CLDR in the loop, but does > not want to see it discussed. If the target is to be able to say 'IANA > langtag inside' there is a long long long way to go, all the more if > there are any directly or indirectly claimed right through the locale". > A civil right fighter says so bad things about all this, that I hesitate > between quoting him and being expelled, and giving him the way to > subscribe and to see him setting the WG afire. > > Not easy to just stay a network architect. > > But even then, look at what Vint Cerf just said .... > http://news.yahoo.com/s/ap/20050715/ap_on_hi_te/internet_languages;_ylt=ArzU5bsfXU3xIjN3xHeQIE6s0NUE;_ylu=X3oDMTA3cjE0b2MwBHNlYwM3Mzg > putting the blame on us because it does not work. > > 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 Jul 18 15:23:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DubCk-0000SV-1z; Mon, 18 Jul 2005 15:23:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DubCh-0000SD-1E for ltru@megatron.ietf.org; Mon, 18 Jul 2005 15:23:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08439 for ; Mon, 18 Jul 2005 15:23:01 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DubgA-0005Qp-D4 for ltru@ietf.org; Mon, 18 Jul 2005 15:53:31 -0400 X-Medic-Info: 4c66.42dc0186.0 yYDuyQLj3wQFu9zT Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 1BF21DADE for ; Mon, 18 Jul 2005 21:22:46 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Mon, 18 Jul 2005 21:22:46 +0200 (CEST) Message-ID: <60207.83.248.26.202.1121714566.squirrel@webmail.chalmers.se> In-Reply-To: <00dd01c58a3c$036be280$030aa8c0@DEWELL> References: <00dd01c58a3c$036be280$030aa8c0@DEWELL> Date: Mon, 18 Jul 2005 21:22:46 +0200 (CEST) From: "Kent Karlsson" To: "LTRU Working Group" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca Content-Transfer-Encoding: quoted-printable Cc: Subject: [Ltru] Reference lists X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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=92ve looked a bit at the references sections for both the -registry dra= ft and the -initial draft, and I have the following comments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.txt says: > 9. References > > 9.1 Normative References > > [ISO639-1] > International Organization for Standardization, "ISO 639- > 1:2002, Codes for the representation of names of language= s > -- Part 1: Alpha-2 code", ISO Standard 639, 2002, 639-1>. The ", " part does not seem to belong here... Likewise for other references. There is no mention of "edition" here. > [ISO639-2] > International Organization for Standardization, "ISO 639- > 2:1998 - Codes for the representation of names of > languages -- Part 2: Alpha-3 code - edition 1", > August 1988, . 1998 versus 1988? It should be 1998. But the date duplication seems needless. The iso.org catalogue does not mention "August", but that may still be correct. The official ISO reference should be: ISO 639-2:1998, Codes for the representation of names of languages - Part 2: Alpha-3 code, first edition (not " - edition 1"; ", "Ed. 1" may be ok too). There is no mention of "edition" for [ISO639-1], nor for [ISO15924]. > [ISO15924] > ISO TC46/WG3, "ISO 15924:2003 (E/F) - Codes for the > representation of names of scripts", January 2004, 15924>. > > [ISO3166] International Organization for Standardization, "Codes fo= r > the representation of names of countries, 3rd edition", > ISO Standard 3166, August 1988, . > > [UN_M.49] Statistical Division, United Nations, "Standard Country o= r > Area Codes for Statistical Use", UN Standard Country or > Area Codes for Statistical Use, Revision 4 (United Nation= s > publication, Sales No. 98.XVII.9, June 1999, . > > [ISO10646] > International Organization for Standardization, "ISO/IEC > 10646-1:2000. Information technology -- Universal > Multiple-Octet Coded Character Set (UCS) -- Part 1: > Architecture and Basic Multilingual Plane and ISO/IEC > 10646-2:2001. Information technology -- Universal > Multiple-Octet Coded Character Set (UCS) -- Part 2: > Supplementary Planes, as, from time to time, amended, > replaced by a new edition or expanded by the addition of > new parts", 2000, . There is a newer version of this one, 2003, and this newer version is not divided into parts. > [RFC2234bis] > Crocker, D. and P. Overell, "Augmented BNF for Syntax > Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00 > (work in progress), March 2005. Work in progress should not be a normative reference, unless one is certain that that work will be finished (and the "work in progress" remark removed) before this work is finished. > [ISO646] ISO/IEC 646 JTC 1/SC 2, "ISO/IEC 646:1991, Information > technology -- ISO 7-bit coded character set for > information interchange.", 1991. > > [RFC2026] Bradner, S., "The Internet Standards Process -- Revision > 3", BCP 9, RFC 2026, October 1996. That should be an informative reference. > [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in > the IETF Standards Process", BCP 11, RFC 2028, > October 1996. That should be an informative reference. > [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) > Part Three: Message Header Extensions for Non-ASCII Text"= , > RFC 2047, November 1996. That should be an informative reference. > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. That should probably be an informative reference. > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 2434, > October 1998. That should be an informative reference. > [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO > 10646", RFC 2781, February 2000. That should be an informative reference, if needed at all. > [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of > Understanding Concerning the Technical Work of the > Internet Assigned Numbers Authority", RFC 2860, June 2000= . That should be an informative reference. > [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: > Timestamps", RFC 3339, July 2002. > > [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC > Text on Security Considerations", BCP 72, RFC 3552, > July 2003. That should be an informative reference. > 9.2 Informative References > > [initial-registry] > Ewell, D., Ed., "Initial Language Subtag Registry", > June 2005, draft-ietf-ltru-initial-registry-00.txt>. I think this one should be a normative reference. > [iso639.principles] > ISO 639 Joint Advisory Committee, "ISO 639 Joint Advisory > Committee: Working principles for ISO 639 maintenance", > March 2000, > iso639jac_n3r.html>. > > [record-jar] > Raymond, E., "The Art of Unix Programming", 2003. > > [XML10] Bray (et al), T., "Extensible Markup Language (XML) 1.0", > 02 2004. > > [XMLSchema] > Biron, P., Ed. and A. Malhotra, Ed., "XML Schema Part 2: > Datatypes Second Edition", 10 2004, < > http://www.w3.org/TR/xmlschema-2/>. > > [Unicode] Unicode Consortium, "The Unicode Consortium. The Unicode > Standard, Version 4.1.0, defined by: The Unicode Standard= , > Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321= - > 18578-1), as amended by Unicode 4.0.1 > (http://www.unicode.org/versions/Unicode4.0.1) and by > Unicode 4.1.0 > (http://www.unicode.org/versions/Unicode4.1.0).", > March 2005. If 10646 is a normative reference, then so should this one be. > [RFC1766] Alvestrand, H., "Tags for the Identification of > Languages", RFC 1766, March 1995. > > [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded > Word Extensions: Character Sets, Languages, and > Continuations", RFC 2231, November 1997. > > [RFC3066] Alvestrand, H., "Tags for the Identification of > Languages", BCP 47, RFC 3066, January 2001. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-03.txt says: > 7. References > > 7.1 Normative References > > [I-D.ietf-ltru-registry] > Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifyin= g > Languages", June 2005. > > 7.2 Informative References > > [ISO15924] > ISO TC46/WG3, "ISO 15924:2003 (E/F) - Codes for the > representation of names of scripts", January 2004. I think this one should be a normative reference also for "ltru-initial" (more than for the "ltru-registry" document), since data is culled from this reference. > [ISO3166-1] > International Organization for Standardization, "ISO 3166= - > 1:1988 - Codes for the representation of names of > countries, 3rd edition", August 1988. I think this one should be a normative reference also for "ltru-initial" (more than for the "ltru-registry" document), and the RA=92s registry its= elf, since data is culled from this reference. > [ISO639-1] > International Organization for Standardization, "ISO 639- > 1:2002 - Codes for the representation of names of > languages - Part 1: Alpha-2 code", 2002. I think this one should be a normative reference also for "ltru-initial" (more than for the "ltru-registry" document), and the RA=92s registry its= elf, since data is culled from this reference. > [ISO639-2] > International Organization for Standardization, "ISO 639- > 2:1998 - Codes for the representation of names of > languages - Part 2: Alpha-3 code - edition 1", > August 1988. 1998 vs. 1988? (See comment on same reference in the -registry draft.) I think this one should be a normative reference also for "ltru-initial" (more than for the "ltru-registry" document), and the RA=92s registry its= elf, since data is culled from this reference. > [RFC1766] Alvestrand, H., "Tags for the Identification of > Languages", RFC 1766, March 1995. > > [RFC3066] Alvestrand, H., "Tags for the Identification of > Languages", BCP 47, RFC 3066, January 2001. > > [UN-M.49] United Nations Statistical Division, "Standard Country or > Area Codes for Statistical Use", June 1999. I think this one should be a normative reference also for "ltru-initial" (more than for the "ltru-registry" document), and the RA=92s registry its= elf, since data is culled from this reference. > [record-jar] > Raymond, E., "The Art of Unix Programming", 2003. > Since the initial registry contains character references, 10646 and Unicode should be normative references also for the -initial document. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please use the same sort order for both -initial and -registry when ordering the references, as well as the exact same formulation for common references. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 18 16:52:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ducb9-0001tN-NC; Mon, 18 Jul 2005 16:52:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ducb8-0001tI-HV for ltru@megatron.ietf.org; Mon, 18 Jul 2005 16: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 QAA27545 for ; Mon, 18 Jul 2005 16:52:19 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DucaJ-0005j8-TI for ltru@lists.ietf.org; Mon, 18 Jul 2005 22:51:31 +0200 Received: from du-042-223.access.de.clara.net ([213.221.65.223]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jul 2005 22:51:31 +0200 Received: from nobody by du-042-223.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jul 2005 22:51:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Mon, 18 Jul 2005 22:48:45 +0200 Organization: Lines: 88 Message-ID: <42DC15AD.570F@xyzzy.claranet.de> References: <00dd01c58a3c$036be280$030aa8c0@DEWELL> <60207.83.248.26.202.1121714566.squirrel@webmail.chalmers.se> 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-042-223.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Reference lists X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Kent Karlsson wrote: [RFC2234bis] > Work in progress should not be a normative reference, unless > one is certain that that work will be finished That's intentional, and it's finished from our POV, compare [RFC2026] > That should be an informative reference. We need its appeal procedures, and they are not only for info. [RFC2028] > That should be an informative reference. Maybe, but one of 2860 and 2028 might be normative. [RFC2047] > That should be an informative reference. But it justifies / explains major parts of some length limits. If that also works as informative reference it's fine. [RFC2119] > That should probably be an informative reference. No, that's definitely normative. [RFC2434] > That should be an informative reference. Yes. [RFC2781] > That should be an informative reference, if needed at all. Used in an example in chapter 2.1, where it essentially says that you can't use laguage tags in any encoding without ALPHA, DIGIT, or hyphen. [RFC2860] > That should be an informative reference. AFAIK Jefsey wanted it as "normative" for some details of the appeal procedure. I prefer to delete it keeping 2028 for info (= explaining the acronym "IANA"). [RFC3552] > That should be an informative reference. Yes. [initial-registry] > I think this one should be a normative reference. Then they'd point to each other as "normative". For Martin's strategy (= never publish the [initial-registry] as RfC, only "last call" it and then let IANA create the real registry) we could not reference it at all, or it has to be replaced by the URL of the real registry. > (http://www.unicode.org/versions/Unicode4.1.0).", March 2005. > If 10646 is a normative reference, then so should this one be Depends, if the IETF recognizes this private club as "official" it could be "normative". I don't find "unicode" on the page [ISO15924] > I think this one should be a normative reference also for > "ltru-initial" (more than for the "ltru-registry" document), > since data is culled from this reference. The idea is to create a new normative registry from the input sources, not something that could be overruled by the input. Dito all others informative references in the initial registry. > Since the initial registry contains character references, > 10646 and Unicode should be normative references also for > the -initial document. All informative references in the initial registry are only a courtesy for the reader, the normative stuff is in the one and only normative reference, i.e. the future 3066bis. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 18 17:20:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dud26-0002fK-5X; Mon, 18 Jul 2005 17:20:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dud21-0002aG-1b for ltru@megatron.ietf.org; Mon, 18 Jul 2005 17:20:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29910 for ; Mon, 18 Jul 2005 17:20:06 -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.43) id 1DudVV-0005uT-3D for ltru@ietf.org; Mon, 18 Jul 2005 17:50: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 Jul 2005 14:19: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: Reference lists Date: Mon, 18 Jul 2005 14:19:50 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20DBCB@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Reference lists Thread-Index: AcWL2rZCnXVy7Ag3SkuSAMgusvS81wAAsOBg From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 18 Jul 2005 21:19:51.0591 (UTC) FILETIME=[6F47E370:01C58BDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 agree with Frank's comments, with the following additions: > [RFC2234bis] > > Work in progress should not be a normative reference, unless > > one is certain that that work will be finished >=20 > That's intentional, and it's finished from our POV, compare > > I was asked to use this reference and make it normative by our AD, among = others. I believe it is enqueued for an RFC number, so that should be = sufficient.=20 > > (http://www.unicode.org/versions/Unicode4.1.0).", March 2005. > > If 10646 is a normative reference, then so should this one be >=20 > Depends, if the IETF recognizes this private club as "official" > it could be "normative". I don't find "unicode" on the page > This one is present in an example. I certainly wouldn't have any trouble = in making Unicode normative if there were a reason to do so, but there = isn't one in this document. ISO/IEC 10646 is sufficient for our = normative purposes. >[RFC2047] >> That should be an informative reference. > >But it justifies / explains major parts of some length limits. >If that also works as informative reference it's fine. This can safely be informative, I believe. Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group Internationalization is not a feature. It is an architecture.=20 =20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 18 18:20:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DudyH-0003AN-IV; Mon, 18 Jul 2005 18:20:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DudyG-000382-6u for ltru@megatron.ietf.org; Mon, 18 Jul 2005 18:20:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04982 for ; Mon, 18 Jul 2005 18:20:17 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DueRj-0008Fz-Rd for ltru@ietf.org; Mon, 18 Jul 2005 18:50:50 -0400 X-Medic-Info: 1fe5.42dc2b20.0 YMKLIMUAoH1ujzcn Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 91AC2DFB6 for ; Tue, 19 Jul 2005 00:20:16 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Tue, 19 Jul 2005 00:20:16 +0200 (CEST) Message-ID: <60457.83.248.26.202.1121725216.squirrel@webmail.chalmers.se> In-Reply-To: <42DC15AD.570F@xyzzy.claranet.de> References: <00dd01c58a3c$036be280$030aa8c0@DEWELL><60207.83.248.26.202.1121714566.squirrel@webmail.chalmers.se> <42DC15AD.570F@xyzzy.claranet.de> Date: Tue, 19 Jul 2005 00:20:16 +0200 (CEST) Subject: Re: [Ltru] Re: Reference lists From: "Kent Karlsson" To: ltru@ietf.org User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.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 > [RFC2781] > > That should be an informative reference, if needed at all. > > Used in an example in chapter 2.1, where it essentially says > that you can't use laguage tags in any encoding without ALPHA, > DIGIT, or hyphen. That is a reference, as you say, from an *example*. I see no reason for it to be normative. B.t.w., it is also covered by the (normative) referen= ce to 10646, which specifies UTF-16. > [initial-registry] > > I think this one should be a normative reference. > > Then they'd point to each other as "normative". For Martin's Yes, so? They are mutually dependent in normativeness. > strategy (=3D never publish the [initial-registry] as RfC, only > "last call" it and then let IANA create the real registry) we > could not reference it at all, or it has to be replaced by the > URL of the real registry. That is a different matter, of course. > [ISO15924] > > I think this one should be a normative reference also for > > "ltru-initial" (more than for the "ltru-registry" document), > > since data is culled from this reference. > > The idea is to create a new normative registry from the input > sources, not something that could be overruled by the input. I know. Making (a particular version) of this kind of reference normative does not change that. The initial data is still "normatively" culled from (particular versions of) these references. /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 18 19:12:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duemu-0003Ww-Fu; Mon, 18 Jul 2005 19:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duemi-0003MI-VC for ltru@megatron.ietf.org; Mon, 18 Jul 2005 19:12:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13383 for ; Mon, 18 Jul 2005 19:12:25 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DufGE-0003Q9-Kl for ltru@ietf.org; Mon, 18 Jul 2005 19:42:59 -0400 Received: from h-64-105-35-112.snvacaid.dynamic.covad.net ([64.105.35.112] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Duemg-0004NR-00 for ltru@ietf.org; Mon, 18 Jul 2005 19:12:26 -0400 Message-ID: <008001c58bee$38ca8180$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <00dd01c58a3c$036be280$030aa8c0@DEWELL> <60207.83.248.26.202.1121714566.squirrel@webmail.chalmers.se> Subject: Re: [Ltru] Reference lists Date: Mon, 18 Jul 2005 16:12: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.1 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 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 - As a technical contributor, I have a bunch of replies to Kent's comments. I agree with many of them, but also disagree with a few. See in-line below. > From: "Kent Karlsson" > To: "LTRU Working Group" > Sent: Monday, July 18, 2005 12:22 PM > Subject: [Ltru] Reference lists ... > > [RFC2234bis] > > Crocker, D. and P. Overell, "Augmented BNF for Syntax > > Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00 > > (work in progress), March 2005. > > Work in progress should not be a normative reference, unless one is > certain that that work will be finished (and the "work in progress" > remark removed) before this work is finished. RFC2234bis should stay as is. We want the most recent version, and our AD wants us to use it, too. Since we'll probably be heading for BCP rather than Proposed Standard, it shouldn't be any issue anyway. ... > > [RFC2026] Bradner, S., "The Internet Standards Process -- Revision > > 3", BCP 9, RFC 2026, October 1996. > > That should be an informative reference. Disagree. Since RFC 2026 provides the rules for appeals, the reference is normative. > > [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in > > the IETF Standards Process", BCP 11, RFC 2028, > > October 1996. > > That should be an informative reference. Agree. The places where it is cited it only serves to provide the information on what the IESG is. All those places are immediately followed by a reference to 2026, so in my opinion it would be a reasonable editorial change to remove all references fro RFC 2028 from the document, since they add no information. > > [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) > > Part Three: Message Header Extensions for Non-ASCII Text", > > RFC 2047, November 1996. > > That should be an informative reference. Agree, since it is only used in an example justifying the choice of what might otherwise seem to be an arbitrary number. > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > > Requirement Levels", BCP 14, RFC 2119, March 1997. > > That should probably be an informative reference. Disagree. Normal practice is to consider RFC2119 a normative reference, since it provides definitions essential to the specification. > > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an > > IANA Considerations Section in RFCs", BCP 26, RFC 2434, > > October 1998. > > That should be an informative reference. I can see your point with respect to the -09 internet draft. However, the resolution of issue #1075 affects this. The wording currently on the table for this issue would make a normative reference to RFC 2434, so I think this should stay in the normative references section. > > [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO > > 10646", RFC 2781, February 2000. > > That should be an informative reference, if needed at all. I agree with making this an informative reference. The sole citation is clearly not normative. > > [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of > > Understanding Concerning the Technical Work of the > > Internet Assigned Numbers Authority", RFC 2860, June 2000. > > That should be an informative reference. Agreed, if it is needed at all. Since IANA considerations sections are required in all documents submitted for publication as RFCs, there seems to be little point in putting in a reference to IANA. I don't object to it, but it is clearly informative rather than normative, if needed at all. ... > > [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC > > Text on Security Considerations", BCP 72, RFC 3552, > > July 2003. > > That should be an informative reference. Agreed. > > 9.2 Informative References > > > > [initial-registry] > > Ewell, D., Ed., "Initial Language Subtag Registry", > > June 2005, > draft-ietf-ltru-initial-registry-00.txt>. > > I think this one should be a normative reference. That would be problematic. The initial subtag registry is intended for "informational". If its content were to somehow change, it would in no way cause the meaning of anything in the registry document. Consequently, I think "informative" is the correct designation. ... > > [Unicode] Unicode Consortium, "The Unicode Consortium. The Unicode > > Standard, Version 4.1.0, defined by: The Unicode Standard, > > Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321- > > 18578-1), as amended by Unicode 4.0.1 > > (http://www.unicode.org/versions/Unicode4.0.1) and by > > Unicode 4.1.0 > > (http://www.unicode.org/versions/Unicode4.1.0).", > > March 2005. > > If 10646 is a normative reference, then so should this one be. The only place where [Unicode] is cited is in an example, so the reference is informative. (From my point of view 10646 could have been referenced here, allowing elimination of the Unicode reference.) ... > http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-03.txt says: > ... > > [ISO15924] > > ISO TC46/WG3, "ISO 15924:2003 (E/F) - Codes for the > > representation of names of scripts", January 2004. > > I think this one should be a normative reference also for "ltru-initial" > (more than for the "ltru-registry" document), since data is culled from > this reference. I agree. > > [ISO3166-1] > > International Organization for Standardization, "ISO 3166- > > 1:1988 - Codes for the representation of names of > > countries, 3rd edition", August 1988. > > I think this one should be a normative reference also for "ltru-initial" > (more than for the "ltru-registry" document), and the RA's registry itself, > since data is culled from this reference. Yup. > > [ISO639-1] > > International Organization for Standardization, "ISO 639- > > 1:2002 - Codes for the representation of names of > > languages - Part 1: Alpha-2 code", 2002. > > I think this one should be a normative reference also for "ltru-initial" > (more than for the "ltru-registry" document), and the RA's registry itself, > since data is culled from this reference. Agreed. > > [ISO639-2] > > International Organization for Standardization, "ISO 639- > > 2:1998 - Codes for the representation of names of > > languages - Part 2: Alpha-3 code - edition 1", > > August 1988. ... > I think this one should be a normative reference also for "ltru-initial" > (more than for the "ltru-registry" document), and the RA's registry itself, > since data is culled from this reference. Agreed. ... > > [UN-M.49] United Nations Statistical Division, "Standard Country or > > Area Codes for Statistical Use", June 1999. > > I think this one should be a normative reference also for "ltru-initial" > (more than for the "ltru-registry" document), and the RA's registry itself, > since data is culled from this reference. Agreed. ... > Since the initial registry contains character references, 10646 > and Unicode should be normative references also for the -initial > document. Disagree. The format is defined in the registry draft, which contains the necessary references. No need to pull in or flatten "indirect" references. > ================================================================= > > Please use the same sort order for both -initial and -registry when > ordering the references, as well as the exact same formulation for > common references. ... I suggest using the option in the xml2rfc source. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 18 19:43:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DufGh-0000VO-GH; Mon, 18 Jul 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 1DufGf-0000QS-Q1 for ltru@megatron.ietf.org; Mon, 18 Jul 2005 19:43:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27978 for ; Mon, 18 Jul 2005 19:43:22 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DufkC-0000Us-3m for ltru@ietf.org; Mon, 18 Jul 2005 20:13:56 -0400 Received: from h-64-105-35-112.snvacaid.dynamic.covad.net ([64.105.35.112] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DufGd-0004gq-00 for ltru@ietf.org; Mon, 18 Jul 2005 19:43:23 -0400 Message-ID: <00ac01c58bf2$8c204a00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C20D829@irvmbxw01.quest.com> <006101c58a96$2b52c7a0$7f1afea9@oemcomputer> <6.2.1.2.2.20050717153735.03b57900@mail.afrac.org> Subject: Re: [Ltru] [psg.com #1075] WGLC section 3.6 specification requirements for extensions Date: Mon, 18 Jul 2005 16:43:13 -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: "r&d afrac" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Sunday, July 17, 2005 6:56 AM > Subject: Re: [Ltru] [psg.com #1075] WGLC section 3.6 specification requirementsfor extensions > > You must be aware that what an RFC can do, another can change it. What > about RFC with particular ABNF accepting longer subtags than 8 alpha/num? ... You could try it. The incompatibility with the historic and proposed ABNF grammar might lead to difficulty in gaining technical acceptance. Ultimately the decision would be up to the IESG. As RFC 2434 says: IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). So, if this WG still existed at that time, it would not be surprising if the IESG sought input here on the proposal. If this WG was no longer around (I'm hoping we can go away in a few more weeks), then the IESG would probably consult someone on the ietf-languages@iana.org list. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 18 19:57:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DufUY-00035e-KK; Mon, 18 Jul 2005 19:57:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DufUW-00035T-Hq for ltru@megatron.ietf.org; Mon, 18 Jul 2005 19:57:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00642 for ; Mon, 18 Jul 2005 19:57:40 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dufy1-0001cb-Jj for ltru@ietf.org; Mon, 18 Jul 2005 20:28:14 -0400 Received: from h-64-105-35-112.snvacaid.dynamic.covad.net ([64.105.35.112] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DufUT-0000it-00 for ltru@ietf.org; Mon, 18 Jul 2005 19:57:41 -0400 Message-ID: <00bb01c58bf4$8b4baa00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C20D847@irvmbxw01.quest.com> <42D9B18F.37B2@xyzzy.claranet.de> <004201c58a93$ba416280$7f1afea9@oemcomputer> <6.2.1.2.2.20050717112503.04e75280@mail.afrac.org> Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UN disclaimer Date: Mon, 18 Jul 2005 16:58:06 -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: 21c69d3cfc2dd19218717dbe1d974352 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: "r&d afrac" > To: "Randy Presuhn" ; > Sent: Sunday, July 17, 2005 4:34 AM > Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UN disclaimer > > Randy, > the point I try to make is that this Draft should be judged on its on > technical merits at the IETF Last Call and during the legal round. This > means that it should show it has also taken into account its heavily > politically loaded character. To do that it is to include appropriate legal > language, copyright mentions and political disclaimers. > > My propositions are to permit the Draft not to be rejected in block (again > I only disagree on "replace/complement" RFC 3066). May be I have not been > clear enough. My proposition is not to introduce final texts, but to > introduce texts at appropriate places with the appropriate concerns and > then to leave to the appropriate reviewers the care to craft the final > appropriate wording. > . > The Draft is intended to be published, so this wording cannot be in the > IANA section only. May be a simple solution would be to enter mentions to > the Editors (who ever they will be at whatever technical, legal, political > level) under the form "[the WG thinks there might be a text needed here to > possibly address the following concerns by the IETF liaison with, the IASA > lawyers, the IANA lawyers, ICANN, GAC]". ... That's not how the process works. What a working group hands to the IESG is what that working group would like to see published as an RFC, with only those formatting changes needed to account for the difference between i-d and RFC formats. Routinely, references will be updated and typos fixed. The IESG may "DISCUSS" the document with the WG, which may result in subsequent edits, as may the IETF last call. If necessary, an updated i-d will be handed to the RFC editor. When publication time arrives, there is the AUTH48 period during which the RFC editor verifies with the document's editor that nothing has been broken by formatting changes, etc. Documents' editors rarely change during this entire process. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 18 21:06:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DugZE-00023s-Ac; Mon, 18 Jul 2005 21: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 1DugZC-00023n-V4 for ltru@megatron.ietf.org; Mon, 18 Jul 2005 21:06:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05987 for ; Mon, 18 Jul 2005 21:06:37 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duh2j-00049E-3f for ltru@ietf.org; Mon, 18 Jul 2005 21:37: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 j6J16NCd006832; Mon, 18 Jul 2005 21:06:23 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Mon, 18 Jul 2005 21:06:22 -0400 Date: Mon, 18 Jul 2005 21:06:22 -0400 From: "John.Cowan" To: Randy Presuhn Subject: Re: [Ltru] [psg.com #1075] WGLC section 3.6 specification requirements for extensions Message-ID: <20050719010621.GE5492@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0C20D829@irvmbxw01.quest.com> <006101c58a96$2b52c7a0$7f1afea9@oemcomputer> <6.2.1.2.2.20050717153735.03b57900@mail.afrac.org> <00ac01c58bf2$8c204a00$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ac01c58bf2$8c204a00$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.2.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 Randy Presuhn scripsit: > So, if this WG still existed at that time, it would not be surprising if the IESG > sought input here on the proposal. If this WG was no longer around (I'm hoping > we can go away in a few more weeks), then the IESG would probably consult > someone on the ietf-languages@iana.org list. I had assumed we were going to go dormant, since we expect to do a 3066ter in a year or so. Is that too long for dormancy? -- Cash registers don't really add and subtract; John Cowan they only grind their gears. jcowan@reutershealth.com But then they don't really grind their gears, either; http://www.reutershealth.com they only obey the laws of physics. --Unknown _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 18 21:48:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuhDR-0005is-12; Mon, 18 Jul 2005 21:48:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuhDP-0005iY-VF for ltru@megatron.ietf.org; Mon, 18 Jul 2005 21:48:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08224 for ; Mon, 18 Jul 2005 21:48:09 -0400 (EDT) Received: from pop-scotia.atl.sa.earthlink.net ([207.69.195.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duhgv-0005cQ-4u for ltru@ietf.org; Mon, 18 Jul 2005 22:18:43 -0400 Received: from h-64-105-35-112.snvacaid.dynamic.covad.net ([64.105.35.112] helo=oemcomputer) by pop-scotia.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DuhDD-0001dL-00 for ltru@ietf.org; Mon, 18 Jul 2005 21:48:00 -0400 Message-ID: <000401c58c03$f2b3fe40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C20D829@irvmbxw01.quest.com> <006101c58a96$2b52c7a0$7f1afea9@oemcomputer> <6.2.1.2.2.20050717153735.03b57900@mail.afrac.org> <00ac01c58bf2$8c204a00$7f1afea9@oemcomputer> <20050719010621.GE5492@NYCMJCOWA2> Date: Mon, 18 Jul 2005 18:48: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.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Ltru] Terminate, go dormant, or recharter X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - (note new subject line, since this really is a separate topic) > From: "John.Cowan" > To: "Randy Presuhn" > Cc: > Sent: Monday, July 18, 2005 6:06 PM > Subject: Re: [Ltru] [psg.com #1075] WGLC section 3.6 specification requirements for extensions > > Randy Presuhn scripsit: > > > So, if this WG still existed at that time, it would not be surprising if the IESG > > sought input here on the proposal. If this WG was no longer around (I'm hoping > > we can go away in a few more weeks), then the IESG would probably consult > > someone on the ietf-languages@iana.org list. > > I had assumed we were going to go dormant, since we expect to do a 3066ter > in a year or so. Is that too long for dormancy? ... Dormancy is a possibility, though my hope is there will be no need for the WG to continue after we deliver our documents. If an update/replacement ends up being necessary so soon, I imagine it will cause some heartburn, though I could be mistaken. Given the time and energy this WG consumes, I'd also be concerned whether we'd be able to maintain critical mass, since many of the active participants have other substantial demands on their time. Anyway, it will be up to the AD. Discussion of follow-on work and requests for additions to the charter are reasonable things when a WG has completed its deliverables, and we can have the discussion and make our recommendations at that time. Some have quite a bit of work they'd like us to consider, and it's appropriate that we have that discussion then. But let's defer this discussion until after we've finished our current assignment, meaning we get out the registry and matching specifications. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 18 22:41:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dui3I-0005Fk-E4; Mon, 18 Jul 2005 22: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 1Dui3G-0005Fa-Kh for ltru@megatron.ietf.org; Mon, 18 Jul 2005 22:41:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11031 for ; Mon, 18 Jul 2005 22:41: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.43) id 1DuiWm-0007TO-An for ltru@ietf.org; Mon, 18 Jul 2005 23: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); Mon, 18 Jul 2005 19:41:27 -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] Terminate, go dormant, or recharter Date: Mon, 18 Jul 2005 19:41:26 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20DC78@irvmbxw01.quest.com> Thread-Topic: [Ltru] Terminate, go dormant, or recharter Thread-Index: AcWMBBPYBlOB4mifRUq031lmgjpsaQABzMog From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 19 Jul 2005 02:41:27.0486 (UTC) FILETIME=[5C87CDE0:01C58C0B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 You seem to be forgetting the matching draft, which may consume a good = bit of the time before we need to consider ISO 639-3. 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: 2005?7?18? 18:48 > To: ltru@ietf.org > Subject: [Ltru] Terminate, go dormant, or recharter >=20 > Hi - >=20 > (note new subject line, since this really is a separate topic) >=20 > > From: "John.Cowan" > > To: "Randy Presuhn" > > Cc: > > Sent: Monday, July 18, 2005 6:06 PM > > Subject: Re: [Ltru] [psg.com #1075] WGLC section 3.6 specification > requirements for extensions > > > > Randy Presuhn scripsit: > > > > > So, if this WG still existed at that time, it would not be = surprising > if the IESG > > > sought input here on the proposal. If this WG was no longer = around > (I'm hoping > > > we can go away in a few more weeks), then the IESG would probably > consult > > > someone on the ietf-languages@iana.org list. > > > > I had assumed we were going to go dormant, since we expect to do a > 3066ter > > in a year or so. Is that too long for dormancy? > ... >=20 > Dormancy is a possibility, though my hope is there will be no > need for the WG to continue after we deliver our documents. > If an update/replacement ends up being necessary so soon, > I imagine it will cause some heartburn, though I could be mistaken. > Given the time and energy this WG consumes, I'd also be concerned > whether we'd be able to maintain critical mass, since many of the > active participants have other substantial demands on their time. >=20 > Anyway, it will be up to the AD. Discussion of follow-on work and > requests for additions to the charter are reasonable things > when a WG has completed its deliverables, and we can have the > discussion and make our recommendations at that time. Some > have quite a bit of work they'd like us to consider, and it's > appropriate that we have that discussion then. >=20 > But let's defer this discussion until after we've finished our > current assignment, meaning we get out the registry and matching > specifications. >=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 Tue Jul 19 00:24:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dujej-0000yu-Tt; Tue, 19 Jul 2005 00:24:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dujei-0000ym-1c for ltru@megatron.ietf.org; Tue, 19 Jul 2005 00:24:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15896 for ; Tue, 19 Jul 2005 00:24:27 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duk8E-0002Mw-Tw for ltru@ietf.org; Tue, 19 Jul 2005 00:55:03 -0400 Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6J4NuC26967; Tue, 19 Jul 2005 13:23:56 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id a5854d56_f80d_11d9_8376_0030482533a1_15269; Tue, 19 Jul 2005 13:29:07 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO000736; 19 Jul 05 13:29:48 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 19 Jul 05 13:29:33 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG000734; 19 Jul 05 13:29:26 +0900 Message-Id: <6.0.0.20.2.20050718125926.07e28880@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 18 Jul 2005 13:00:20 +0900 To: "McDonald, Ira" , "'Frank Ellermann'" , ltru@ietf.org From: Martin Duerst Subject: RE: [Ltru] Re: [psg.com #1073] Last call: IANA adaptation of the UN disclaimer In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 I'm fine both with Randy's very short text, as well as with not adding anything. Regards, Martin. At 01:00 05/07/18, McDonald, Ira wrote: >Hi, > >I agree with Frank and Randy that NO addition is the best choice. >Anything that smells like legal boilerplate makes us vulnerable >to endless non-technical wrangling in IESG last call. > >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: Sunday, July 17, 2005 3:08 AM >> To: ltru@ietf.org >> Subject: [Ltru] Re: [psg.com #1073] Last call: IANA >> adaptation of the UN >> disclaimer >> >> >> Randy Presuhn wrote: >> >> > Would you be able to accept it if reduced to this? >> > Registration requests are to be considered on their own >> > merits, based on the need to identify a language. >> >> That's fine... >> >> > Or would you be happier with no addition at all in resolution >> > of this issue? >> >> ...better. Anything that doesn't sound like an EULA or the >> legal boilerplate. There should be some room for judgement >> calls by the language list and the language tag reviewer. >> >> > I'm coming to prefer no addition at all. I could live with >> > the single-sentence statement above, if that will bring us >> > to a rough consensus. >> >> Same here. 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 From ltru-bounces@lists.ietf.org Tue Jul 19 00:48:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duk1W-0006X3-Bp; Tue, 19 Jul 2005 00:48:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duk1U-0006Wr-Ho for ltru@megatron.ietf.org; Tue, 19 Jul 2005 00:48:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16793 for ; Tue, 19 Jul 2005 00:48:01 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DukV2-00033E-Bt for ltru@ietf.org; Tue, 19 Jul 2005 01:18:37 -0400 Received: from h-64-105-35-112.snvacaid.dynamic.covad.net ([64.105.35.112] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Duk1R-0005nj-00 for ltru@ietf.org; Tue, 19 Jul 2005 00:48:01 -0400 Message-ID: <001401c58c1d$199d3300$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C20DC78@irvmbxw01.quest.com> Subject: Re: [Ltru] Terminate, go dormant, or recharter Date: Mon, 18 Jul 2005 21:48:25 -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: X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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, July 18, 2005 7:41 PM > Subject: RE: [Ltru] Terminate, go dormant, or recharter > > You seem to be forgetting the matching draft, which may consume > a good bit of the time before we need to consider ISO 639-3. ... We're scheduled to bring the matching draft to last call in August. There have been few comments on it, and it does not seem contentious. Consequently, getting it to IETF last call on schedule is still plausible, if the WG polishes it off immediately after we finish the current set of last calls. If you think there are more lurking issues in matching that would prevent us from getting it done in August, then we should request an adjustment to our milestones. (When a working group has overdue milestones, as we do, the chairs get automated nastygrams reminding us to get things done.) Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 00:56:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DukA3-0000Zw-Hp; Tue, 19 Jul 2005 00:56:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duk9z-0000Zr-7Q for ltru@megatron.ietf.org; Tue, 19 Jul 2005 00:56:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17259 for ; Tue, 19 Jul 2005 00:56:47 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DukdX-0003Ki-LJ for ltru@ietf.org; Tue, 19 Jul 2005 01:27:23 -0400 Received: from h-64-105-35-112.snvacaid.dynamic.covad.net ([64.105.35.112] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Duk9w-0007NL-00 for ltru@ietf.org; Tue, 19 Jul 2005 00:56:49 -0400 Message-ID: <003301c58c1e$53eee5c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.0.0.20.2.20050718125926.07e28880@itmail.it.aoyama.ac.jp> Subject: Re: [Ltru] Re: [psg.com #1073] Last call: IANA adaptation ofthe UN disclaimer Date: Mon, 18 Jul 2005 21:57:12 -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: cf4fa59384e76e63313391b70cd0dd25 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've reviewed the postings on this issue, and I believe that the rough consensus of the working group is to reject this proposal. Several variations were discussed, but even if support for any of the variations is considered support for "the proposal", the number opposed to any added text on this issue is still greater. Consequently, I'll mark this issue "rejected" on https://rt.psg.com/ (user and password "ietf") If you believe still more discussion of this topic is warranted, please include the issue number in your subject line. 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 Jul 19 01:04:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DukH9-0002AR-BF; Tue, 19 Jul 2005 01:04:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DukH3-000291-0K for ltru@megatron.ietf.org; Tue, 19 Jul 2005 01:04:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17601 for ; Tue, 19 Jul 2005 01:04:07 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dukkb-0003Vs-P1 for ltru@ietf.org; Tue, 19 Jul 2005 01:34:41 -0400 Received: from h-64-105-35-112.snvacaid.dynamic.covad.net ([64.105.35.112] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DukH0-0000tp-00 for ltru@ietf.org; Tue, 19 Jul 2005 01:04:06 -0400 Message-ID: <005201c58c1f$58d29e00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C20D829@irvmbxw01.quest.com> <006101c58a96$2b52c7a0$7f1afea9@oemcomputer> Subject: Re: [Ltru] [psg.com #1075] WGLC section 3.6 specification requirements for extensions Date: Mon, 18 Jul 2005 22:04: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.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 Hi - It looks like we have a rough consensus for "IETF Consensus" as the specification requirement for extensions, so I've marked this item "resolved" at https://rt.psg.com/ (user/passwd "ietf") Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 01:10:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DukNV-0003Bb-9J; Tue, 19 Jul 2005 01:10:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DukNT-0003BM-3D for ltru@megatron.ietf.org; Tue, 19 Jul 2005 01:10:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17996 for ; Tue, 19 Jul 2005 01:10:45 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dukr1-0003iU-PL for ltru@ietf.org; Tue, 19 Jul 2005 01:41:19 -0400 Received: from h-64-105-35-112.snvacaid.dynamic.covad.net ([64.105.35.112] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DukNQ-00023h-00 for ltru@ietf.org; Tue, 19 Jul 2005 01:10:44 -0400 Message-ID: <006501c58c20$45e980a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.2.1.2.2.20050716140428.03aaeeb0@pop.online.fr> <42DB5F13.2090306@kotus.fi> Subject: Re: [Ltru] [psg.com #1067] Last call: clarification between language tags and locales Date: Mon, 18 Jul 2005 22:11: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: cf4fa59384e76e63313391b70cd0dd25 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've reviewed the postings on this topic, and I believe we have a rough consensus to resolve this issue be removing the following sentence from section 3.6 of the registry i-d: "For example, they might be used to define locale identifiers, which are generally based on language." So, I'll mark it "resolved" in the tracker at https://rt.psg.com/ (user & passwd "ietf") If you think this item merits further discussion, please include the issue number in your subject line. 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 Jul 19 01:11:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DukNl-0003DM-0K; Tue, 19 Jul 2005 01: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 1DukNj-0003CP-Gm for ltru@megatron.ietf.org; Tue, 19 Jul 2005 01:11:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18025 for ; Tue, 19 Jul 2005 01:11:02 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DukrE-0003iY-Cl for ltru@ietf.org; Tue, 19 Jul 2005 01:41:36 -0400 Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6J5AjI10610; Tue, 19 Jul 2005 14:10:45 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id 300038e6_f814_11d9_89e6_0030482533a1_15279; Tue, 19 Jul 2005 14:15:57 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO000764; 19 Jul 05 14:16:37 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 19 Jul 05 14:16:33 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG000761; 19 Jul 05 14:16:22 +0900 Message-Id: <6.0.0.20.2.20050719133500.07e41d80@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 19 Jul 2005 13:37:56 +0900 To: Frank Ellermann , ltru@ietf.org From: Martin Duerst Subject: Re: [Ltru] Re: Reference lists In-Reply-To: <42DC15AD.570F@xyzzy.claranet.de> References: <00dd01c58a3c$036be280$030aa8c0@DEWELL> <60207.83.248.26.202.1121714566.squirrel@webmail.chalmers.se> <42DC15AD.570F@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: 79899194edc4f33a41f49410777972f8 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 Hello Frank, others, At 05:48 05/07/19, Frank Ellermann wrote: >Kent Karlsson wrote: >> (http://www.unicode.org/versions/Unicode4.1.0).", March 2005. >> If 10646 is a normative reference, then so should this one be > >Depends, if the IETF recognizes this private club as "official" >it could be "normative". I don't find "unicode" on the page > I find Unicode at http://www.ietf.org/liaisonActivities.html, which means that there is a liaison. Your pointer is just a list of liaison documents, and by chance, there are no such for Unicode (such documents are important for ISO, ITU, ETSI,... but not for other organizations). Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 01:32:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DukiC-0001dF-CW; Tue, 19 Jul 2005 01:32:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DukiA-0001cN-SM for ltru@megatron.ietf.org; Tue, 19 Jul 2005 01:32:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19440 for ; Tue, 19 Jul 2005 01:32:06 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DulBf-0004Qj-Cn for ltru@ietf.org; Tue, 19 Jul 2005 02:02:40 -0400 Received: from h-64-105-35-112.snvacaid.dynamic.covad.net ([64.105.35.112] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Duki4-0006tQ-00 for ltru@ietf.org; Tue, 19 Jul 2005 01:32:04 -0400 Message-ID: <006c01c58c23$40490b40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <000901c588b4$e695e080$7f1afea9@oemcomputer> Subject: Re: [Ltru] Working group last call closing date Date: Mon, 18 Jul 2005 22:32: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.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 - Just a reminder that the WG last calls on our drafts end July 28. http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.txt http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt I'd like to thank all those who have taken the time to review these documents and submit comments. Comments are still welcome, and we'd also like to hear from any people who have read the documents but do not have specific comments. If you're one of these people, and are not comfortable posting to the working group mailing list, just inform BOTH co-chairs (we are randy_presuhn@mindspring.com and duerst@it.aoyama.ac.jp ) Knowing how many people have read a document during its last call is very helpful to us. Note that at this time there are *no* open issues in the tracker at https://rt.psg.com/ (user/password ietf) (I'm assuming the references discussion provided sufficient guidance to the editors. If it didn't, the editors can create a ticket for it.) 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 Jul 19 01:55:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dul4Z-0008Av-HC; Tue, 19 Jul 2005 01:55:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dul4X-0008Ak-Rl for ltru@megatron.ietf.org; Tue, 19 Jul 2005 01:55:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20675 for ; Tue, 19 Jul 2005 01:55:16 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DulY7-0005CS-65 for ltru@ietf.org; Tue, 19 Jul 2005 02:25:51 -0400 Received: from h-64-105-35-112.snvacaid.dynamic.covad.net ([64.105.35.112] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dul4R-0004KF-00 for ltru@ietf.org; Tue, 19 Jul 2005 01:55:12 -0400 Message-ID: <007d01c58c26$7b1ef740$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <00dd01c58a3c$036be280$030aa8c0@DEWELL><60207.83.248.26.202.1121714566.squirrel@webmail.chalmers.se><42DC15AD.570F@xyzzy.claranet.de> <6.0.0.20.2.20050719133500.07e41d80@itmail.it.aoyama.ac.jp> Subject: Re: [Ltru] Re: Reference lists Date: Mon, 18 Jul 2005 22:55:34 -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: 52f7a77164458f8c7b36b66787c853da 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: "Martin Duerst" > To: "Frank Ellermann" ; > Sent: Monday, July 18, 2005 9:37 PM > Subject: Re: [Ltru] Re: Reference lists ... > >Depends, if the IETF recognizes this private club as "official" > >it could be "normative". I don't find "unicode" on the page > > > > I find Unicode at http://www.ietf.org/liaisonActivities.html, > which means that there is a liaison. Your pointer is just a > list of liaison documents, and by chance, there are no such > for Unicode (such documents are important for ISO, ITU, ETSI,... > but not for other organizations). ... True. However, the existance of liaison relationships is orthogonal to whether a normative reference is possible. The "Tao" section 8.8 (http://www.ietf.org/internet-drafts/draft-hoffman-taobis-03.txt) says: 8.8 Normative References in Standards One aspect of writing IETF standards that trips up many novices (and quite a few long-time IETF folk) is the rule about how to make "normative references" to non-IETF documents or to other RFCs in a standard. A normative reference is a reference to a document that must be followed in order to implement the standard. A non-normative reference (sometimes called an "informative reference") is one that is helpful to an implementor but is not needed. As we noted above, a "MUST" specification would certainly be normative, so any reference needed to implement the "MUST" would be normative. A "SHOULD" or "MAY" specification is not necessarily normative, but it could be normative based on what is being required. There is definitely room for debate here! An IETF standard may make a normative reference to any other standards-track RFC that is at the same standards level or higher, or to any "open standard" that has been developed outside the IETF. The "same level or higher" rule means that before a standard can move from Proposed to Draft, all of the RFCs for which there is a normative reference must also be at Draft or Internet Standard. This rule gives implementors assurance that everything in a Draft Standard or Internet Standard is quite stable, even the things referenced outside the standard. This can also delay the publication of the Draft or Internet Standard by many months (sometimes even years) while the other documents catch up. There is no hard and fast rule about what is an "open standard," but generally this means a stable standard that anyone can get a copy of (although they might have to pay for it) and that was made by a generally recognized standards group. If the external standard changes, you have to reference the particular instantiation of that standard in your specification, as with a designation of the date of the standard. Some external standards bodies don't make old standards available, which is a problem for IETF standards that need to be used in the future. When in doubt, a draft author should ask the WG chair or appropriate Area Director if a particular external standard can be used in an IETF standard. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 02:25:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DulXR-0007em-9w; Tue, 19 Jul 2005 02:25:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DulXO-0007cO-So for ltru@megatron.ietf.org; Tue, 19 Jul 2005 02:25:07 -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 CAA12900 for ; Tue, 19 Jul 2005 02:25:04 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DulXD-0005iQ-Ka for ltru@lists.ietf.org; Tue, 19 Jul 2005 08:24:55 +0200 Received: from du-001-063.access.de.clara.net ([212.82.227.63]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jul 2005 08:24:55 +0200 Received: from nobody by du-001-063.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Jul 2005 08:24:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Tue, 19 Jul 2005 08:24:08 +0200 Organization: Lines: 8 Message-ID: <42DC9C88.7CE7@xyzzy.claranet.de> References: <00dd01c58a3c$036be280$030aa8c0@DEWELL> <60207.83.248.26.202.1121714566.squirrel@webmail.chalmers.se> <42DC15AD.570F@xyzzy.claranet.de> <6.0.0.20.2.20050719133500.07e41d80@itmail.it.aoyama.ac.jp> 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-063.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Reference lists X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Martin Duerst wrote: >> > I find Unicode at http://www.ietf.org/liaisonActivities.html, Much better than my first Google hit, bookmarked, thanks. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 03: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 1DumqE-0003Py-7c; Tue, 19 Jul 2005 03: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 1DumqC-0003PR-Fu for ltru@megatron.ietf.org; Tue, 19 Jul 2005 03:48:36 -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 DAA17499 for ; Tue, 19 Jul 2005 03:48: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 <20050719074804.OZQO24042.mta11.adelphia.net@DEWELL> for ; Tue, 19 Jul 2005 03:48:04 -0400 Message-ID: <005501c58c36$2a0f5e20$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050718233055.EECC21785.mta5.adelphia.net@megatron.ietf.org> Date: Tue, 19 Jul 2005 00:47: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 Cc: Subject: [Ltru] Re: Reference lists X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 don't plan to squabble over which references should be normative and which should be informative. Almost anyone on this list would be better at making that judgment than I would. Just say what is best and I'll move things around. Same goes for the correct wording of the ISO and UN references: please post the *exact* wording that is preferred. I do think all the drafts (including matching) should have the same wording for any references they have in common. I had hoped the reference in draft-registry to Unicode could be replaced by a reference to ISO/IEC 10646, since I thought the only context was code points, until I found SpecialCasing.txt mentioned in Section 4.4. -- 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 Jul 19 04: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 1DunPT-0004lk-EJ; Tue, 19 Jul 2005 04:25:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DunPR-0004lb-Hb for ltru@megatron.ietf.org; Tue, 19 Jul 2005 04:25:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19721 for ; Tue, 19 Jul 2005 04:24:59 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dunt1-00029Q-6Z for ltru@ietf.org; Tue, 19 Jul 2005 04:55:36 -0400 Received: from h-64-105-35-112.snvacaid.dynamic.covad.net ([64.105.35.112] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DunPG-0004v5-00 for ltru@ietf.org; Tue, 19 Jul 2005 04:24:50 -0400 Message-ID: <001801c58c3b$5eaa37e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <00dd01c58a3c$036be280$030aa8c0@DEWELL><60207.83.248.26.202.1121714566.squirrel@webmail.chalmers.se> <42DC15AD.570F@xyzzy.claranet.de> Subject: Re: [Ltru] Re: Reference lists Date: Tue, 19 Jul 2005 01:25:04 -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: Monday, July 18, 2005 1:48 PM > Subject: [Ltru] Re: Reference lists ... > [ISO15924] > > I think this one should be a normative reference also for > > "ltru-initial" (more than for the "ltru-registry" document), > > since data is culled from this reference. > > The idea is to create a new normative registry from the input > sources, not something that could be overruled by the input. > > Dito all others informative references in the initial registry. ... As a technical contributor I find Frank's argument more convincing than Kent's, so I withdraw my comments on these references [ISO15924] [ISO3166-1] [ISO639-1] [ISO639-2] and [UN-M.49] in the initial registry. I stand by my comments on the other reference comments. I think Frank and I are largely in agreement on these, and trust the editors will let us know if there are cases where looking at Kent's, Frank's, and my comments leaves things in doubt. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 04:29:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DunUC-0005kz-Do; Tue, 19 Jul 2005 04:29:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DunUA-0005km-Cc for ltru@megatron.ietf.org; Tue, 19 Jul 2005 04:29:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20060 for ; Tue, 19 Jul 2005 04:29:52 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dunxl-0002LM-Ga for ltru@ietf.org; Tue, 19 Jul 2005 05:00:29 -0400 Received: from h-64-105-35-112.snvacaid.dynamic.covad.net ([64.105.35.112] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DunU9-0006ch-00 for ltru@ietf.org; Tue, 19 Jul 2005 04:29:53 -0400 Message-ID: <001b01c58c3c$14971820$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <20050718233055.EECC21785.mta5.adelphia.net@megatron.ietf.org> <005501c58c36$2a0f5e20$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Reference lists Date: Tue, 19 Jul 2005 01:29:36 -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: 79899194edc4f33a41f49410777972f8 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: "Doug Ewell" > To: "LTRU Working Group" > Sent: Tuesday, July 19, 2005 12:47 AM > Subject: [Ltru] Re: Reference lists ... > I had hoped the reference in draft-registry to Unicode could be replaced > by a reference to ISO/IEC 10646, since I thought the only context was > code points, until I found SpecialCasing.txt mentioned in Section 4.4. ... FWIW that particular passage is clearly non-normative advice to implementors, so even if there were a problem with making normative references to Unicode documents, this passage wouldn't be a problem. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 06:16:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dup5h-0001Z7-6m; Tue, 19 Jul 2005 06:12:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dup5f-0001YW-Oq for ltru@megatron.ietf.org; Tue, 19 Jul 2005 06:12:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27217 for ; Tue, 19 Jul 2005 06:12:41 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DupZF-0006v3-BL for ltru@ietf.org; Tue, 19 Jul 2005 06:43:19 -0400 X-Medic-Info: 726.42dcd211.0 rgPX9afru1YCQdfP Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 58DEA3F95 for ; Tue, 19 Jul 2005 12:12:33 +0200 (CEST) Received: from 195.242.62.34 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Tue, 19 Jul 2005 12:12:33 +0200 (CEST) Message-ID: <49457.195.242.62.34.1121767953.squirrel@webmail.chalmers.se> In-Reply-To: <001b01c58c3c$14971820$7f1afea9@oemcomputer> References: <20050718233055.EECC21785.mta5.adelphia.net@megatron.ietf.org><005501c58c36$2a0f5e20$030aa8c0@DEWELL> <001b01c58c3c$14971820$7f1afea9@oemcomputer> Date: Tue, 19 Jul 2005 12:12:33 +0200 (CEST) Subject: Re: [Ltru] Reference lists From: "Kent Karlsson" To: "LTRU Working Group" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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 And also the -matching document: http://www.ietf.org/internet-drafts/draft-ietf-ltru-matching-03.txt says: > 7. References > > 7.1 Normative References > > [ID.ietf-ltru-registry] > Phillips, A., Ed. and M. Davis, Ed., "Tags for the > Identification of Languages (Internet-Draft)", June 2005, > draft-ietf-ltru-registry-07.txt>. There should also be a reference to =96initial (if that is published as a= n RFC), and (normatively) the actual registry. > [RFC1327] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO > 10021 and RFC 822", RFC 1327, May 1992. That should be an informative reference, if needed at all (I don=92t find an actual reference in the text). > [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet > Mail Extensions) Part One: Mechanisms for Specifying and > Describing the Format of Internet Message Bodies", > RFC 1521, September 1993. That should be an informative reference, if needed at all (I don=92t find an actual reference in the text). > [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in > the IETF Standards Process", BCP 11, RFC 2028, > October 1996. That should be an informative reference, if needed at all (I don=92t find an actual reference in the text). > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded > Word Extensions: Character Sets, Languages, and > Continuations", RFC 2231, November 1997. That should be an informative reference, if needed at all (I don=92t find an actual reference in the text). > [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Synta= x > Specifications: ABNF", RFC 2234, November 1997. I think that should be an informative reference (it is normative for =96registry, but not for =96matching, I would say). B.t.w., I don=92t fin= d an actual reference in the text. > [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform > Resource Identifiers (URI): Generic Syntax", RFC 2396, > August 1998. That should be an informative reference, if needed at all (I don=92t find an actual reference in the text). > [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an > IANA Considerations Section in RFCs", BCP 26, RFC 2434, > October 1998. That should be an informative reference. > [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., > Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext > Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. That should be an informative reference (it refers to an extension that not everyone supporting 3066bis language tags need support). > [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of > Understanding Concerning the Technical Work of the > Internet Assigned Numbers Authority", RFC 2860, June 2000= . That should be an informative reference, if needed at all (I don=92t find an actual reference in the text). > [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO > 10646", STD 63, RFC 3629, November 2003. That should be an informative reference, if needed at all (then refer directly to Unicode, if need be; not to the 10646 version). I don=92t find an actual reference in the text, not even a mention of UTF= -8. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Same comment on exact formulation of references as before. The ISO catalogue at www.iso.org gives exact title and reference number & year & edition for any ISO standard. The working group that developed the ISO standard is usually *not* included in a reference to the standard (compare your [ISO15924]). E.g. the current [ISO15924] ISO TC46/WG3, =93ISO 15924:2003 (E/F) - Codes for the representation of names of scripts,=94 January 2004. should instead be referenced as [ISO15924] ISO 15924:2004, "Information and documentation -- Codes for th= e representation of names of scripts", first edition. (No conflicting year info, no WG reference, the (E/F) is not given, but the full title should be given; I know, the full titles are sometimes less systematic that one could wish for, but that is for someone else to sort out. And "ISO" is not spelled out in any way [it is not an acrony= m].) /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From disman-bounces@ietf.org Tue Jul 19 06:16:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dup3M-0000zX-FN; Tue, 19 Jul 2005 06:10:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dup3K-0000xY-I0 for disman@megatron.ietf.org; Tue, 19 Jul 2005 06:10:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27085 for ; Tue, 19 Jul 2005 06:10:16 -0400 (EDT) Received: from weird-brew.cisco.com ([144.254.15.118] helo=av-tac-bru.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DupWw-0006oc-6Q for disman@ietf.org; Tue, 19 Jul 2005 06:40:54 -0400 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6JA9sR27728 for ; Tue, 19 Jul 2005 12:10:04 +0200 (CEST) Received: from [10.61.65.46] (ams-clip-vpn-dhcp302.cisco.com [10.61.65.46]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j6JA9mp27653 for ; Tue, 19 Jul 2005 12:09:53 +0200 (CEST) Message-ID: <42DCD16C.8060003@cisco.com> Date: Tue, 19 Jul 2005 12:09:48 +0200 From: Benoit Claise User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Disman (E-mail)" Content-Type: multipart/alternative; boundary="------------030209000306050807080205" X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Subject: [Disman] Clarifications for mteObjectsEntry and mteObjectsIndex DESCRIPTIONs: Issue-3 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org This is a multi-part message in MIME format. --------------030209000306050807080205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Regardless of the order (trigger, trigger test, event) discussion just posted as an Issue-2, I would like to come back to the DESCRIPTIONs of mteObjectsEntry and mteObjectsIndex. mteObjectsEntry OBJECT-TYPE SYNTAX MteObjectsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A group of objects. Applications create and delete entries using mteObjectsEntryStatus. When adding objects to a notification they are added in the lexical order of their index in this table. Those associated with a trigger come first, then trigger test, then event." INDEX { mteOwner, mteObjectsName, mteObjectsIndex } ::= { mteObjectsTable 1 } I think that the last 2 sentences are not very clear. I guess that the correct behavior is that the second one takes precedence over the first one, and that the goal is to say: trigger object group first, trigger test object group next, and event notification object last. Within the object group (mteTrigger*Objects or mteEventNotificationObjects), then we take the numerical order of the mteObjectsIndex, the third index in mteObjectsEntry. If this is the correct behaviour, I'm confused by "When adding objects to a notification they are added in the lexical order of their _index _in this table. Those associated with a trigger come first, then trigger test, then event.". Which index do we speak about? mteOwner, mteObjectName, or mteObjectsIndex? mteObjectsIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An arbitrary integer for the purpose of identifying individual objects within a mteObjectsName group. Objects within a group are placed in the notification in the numerical order of this index. Groups are placed in the notification in the order of the selections for overall trigger, trigger test, and event. Within trigger test they are in the same order as the numerical values of the bits defined for mteTriggerTest. Bad object identifiers or a mismatch between truncating the identifier and the value of mteDeltaDiscontinuityIDWildcard result in operation as one would expect when providing the wrong identifier to a Get operation. The Get will fail or get the wrong object. If the object is not available it is omitted from the notification." ::= { mteObjectsEntry 2 } Again, I think the second and third sentences are confusing. If I read first "Objects within a group are placed in the notification in the numerical order of this index.", I'm asking myself what a group is! I guess/understand that a group in the case of mteObjectsIndex refers to trigger, trigger test, or event but this don't think this is specified anywhere in the draft. What is even more confusing is that mteObjectsEntry refers to "a group of objects" but the meaning is completely different. Am I the only one to consider this very confusing? Should we think of some improve text? Regards, Benoit. --------------030209000306050807080205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Regardless of the order (trigger, trigger test, event) discussion just posted as an Issue-2, I would like to come back to the DESCRIPTIONs of mteObjectsEntry and mteObjectsIndex.
mteObjectsEntry OBJECT-TYPE 
    SYNTAX      MteObjectsEntry 
    MAX-ACCESS  not-accessible 
    STATUS      current 
    DESCRIPTION 
        "A group of objects.  Applications create and delete entries 
        using mteObjectsEntryStatus. 
 
        When adding objects to a notification they are added in the 
        lexical order of their index in this table.  Those associated 
        with a trigger come first, then trigger test, then event." 
    INDEX       { mteOwner, mteObjectsName, mteObjectsIndex } 
    ::= { mteObjectsTable 1 }
I think that the last 2 sentences are not very clear.
I guess that the correct behavior is that the second one takes precedence over the first one, and that the goal is to say:
trigger object group first, trigger test object group next, and event notification object last. Within the object group (mteTrigger*Objects or mteEventNotificationObjects), then we take the numerical order of the mteObjectsIndex, the third index in mteObjectsEntry.

If this is the correct behaviour, I'm confused by "When adding objects to a notification they are added in the lexical order of their index in this table. Those associated with a trigger come first, then trigger test, then event.".
Which index do we speak about? mteOwner, mteObjectName, or mteObjectsIndex?



mteObjectsIndex OBJECT-TYPE 
    SYNTAX      Unsigned32 (1..4294967295) 
    MAX-ACCESS  not-accessible 
    STATUS      current 
    DESCRIPTION 
        "An arbitrary integer for the purpose of identifying 
        individual objects within a mteObjectsName group. 
 
        Objects within a group are placed in the notification in the 
        numerical order of this index. 
 
        Groups are placed in the notification in the order of the 
        selections for overall trigger, trigger test, and event. 
        Within trigger test they are in the same order as the 
        numerical values of the bits defined for mteTriggerTest. 
 
        Bad object identifiers or a mismatch between truncating the 
        identifier and the value of mteDeltaDiscontinuityIDWildcard 
        result in operation as one would expect when providing the 
        wrong identifier to a Get operation.  The Get will fail or get 
        the wrong object.  If the object is not available it is omitted 
        from the notification." 
    ::= { mteObjectsEntry 2 }
Again, I think the second and third sentences are confusing. If I read first "Objects within a group are placed in the notification in the numerical order of this index.", I'm asking myself what a group is! I guess/understand that a group in the case of mteObjectsIndex refers to trigger, trigger test, or event but this don't think this is specified anywhere in the draft. What is even more confusing is that mteObjectsEntry refers to "a group of objects" but the meaning is completely different.

Am I the only one to consider this very confusing?
Should we think of some improve text?
Regards, Benoit.
--------------030209000306050807080205-- From ltru-bounces@lists.ietf.org Tue Jul 19 13:04:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuvWH-0001Vj-US; Tue, 19 Jul 2005 13:04:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuvWF-0001Ve-MO for ltru@megatron.ietf.org; Tue, 19 Jul 2005 13:04:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14614 for ; Tue, 19 Jul 2005 13:04:30 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duvzp-0003k6-QO for ltru@ietf.org; Tue, 19 Jul 2005 13:35: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 j6JH4CIX026715; Tue, 19 Jul 2005 10:04:13 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Tue, 19 Jul 2005 10:05:12 -0700 Message-ID: From: "McDonald, Ira" To: "'Randy Presuhn'" , LTRU Working Group Subject: RE: [Ltru] Re: Reference lists [Unicode refs OK] Date: Tue, 19 Jul 2005 10:05:11 -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: f4c2cf0bccc868e4cc88dace71fb3f44 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, Note that the UTF-8 (RFC 3629) makes repeated normative references to Unicode. So does the predecessor RFC 2279 (from January 1998). And I disagree that 'SpecialCasing.txt' is informative in section 4.4. Section 4.4 normatively defines and RECOMMENDS canonicalization, which specifically includes getting case folding right (not going outside US-ASCII). 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: Tuesday, July 19, 2005 4:30 AM > To: LTRU Working Group > Subject: Re: [Ltru] Re: Reference lists > > > Hi - > > > From: "Doug Ewell" > > To: "LTRU Working Group" > > Sent: Tuesday, July 19, 2005 12:47 AM > > Subject: [Ltru] Re: Reference lists > ... > > I had hoped the reference in draft-registry to Unicode > could be replaced > > by a reference to ISO/IEC 10646, since I thought the only > context was > > code points, until I found SpecialCasing.txt mentioned in > Section 4.4. > ... > > FWIW that particular passage is clearly non-normative advice to > implementors, so even if there were a problem with making normative > references to Unicode documents, this passage wouldn't be a problem. > > 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 Tue Jul 19 13:07:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuvYr-0002D1-OE; Tue, 19 Jul 2005 13:07:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuvYp-0002CH-S7 for ltru@megatron.ietf.org; Tue, 19 Jul 2005 13:07:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14867 for ; Tue, 19 Jul 2005 13:07:13 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duw2U-0003qH-3r for ltru@ietf.org; Tue, 19 Jul 2005 13:37:55 -0400 X-Medic-Info: 2b6c.42dd333a.0 cVExQyxZAcBaiVF0 Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 331E63FE2; Tue, 19 Jul 2005 19:07:06 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Tue, 19 Jul 2005 19:07:06 +0200 (CEST) Message-ID: <60025.83.248.26.202.1121792826.squirrel@webmail.chalmers.se> In-Reply-To: <49457.195.242.62.34.1121767953.squirrel@webmail.chalmers.se> References: <20050718233055.EECC21785.mta5.adelphia.net@megatron.ietf.org><005501c58c36$2a0f5e20$030aa8c0@DEWELL><001b01c58c3c$14971820$7f1afea9@oemcomputer> <49457.195.242.62.34.1121767953.squirrel@webmail.chalmers.se> Date: Tue, 19 Jul 2005 19:07:06 +0200 (CEST) Subject: Re: [Ltru] Reference lists; AND ABNF GRAMMARS From: "Kent Karlsson" To: "Kent Karlsson" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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 I wrote: >> [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Synt= ax >> Specifications: ABNF", RFC 2234, November 1997. > > I think that should be an informative reference (it is normative for > -registry, but not for -matching, I would say). B.t.w., I don't find > an actual reference in the text. Oops. It should stay normative. The grammars in -registry and -matching should =93look more similar=94; formatting, order, comments, and structure. Here is a preliminary cleanup= : ------------------------------------------------------------ %% For -registry Language-Tag =3D langtag / privateuse ; private use tag / grandfathered ; grandfathered registrations langtag =3D (lang *3("-" extlang) ["-" script] ["-" region] *("-" variant) *("-" extension) ["-" privateuse]) lang =3D 2*4ALPHA ; shortest ISO 639 code / registered-lang registered-lang =3D 4*8ALPHA ; registered language subtag extlang =3D 3ALPHA ; reserved for future use script =3D 4ALPHA ; ISO 15924 code region =3D 2ALPHA ; ISO 3166 code / 3DIGIT ; UN country number variant =3D 5*8alphanum ; registered variants / ( DIGIT 3alphanum ) extension =3D singleton 1*("-" (2*8alphanum)) singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" ; Single letters: x/X is reserved for private use privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) ; grandfathered registration ; Note: i is the only singleton ; that starts a grandfathered tag alphanum =3D (ALPHA / DIGIT) ; letters and numbers -------------------------------------------------------------------------= -- %% for -matching Language-Range =3D langrange / privateuse ; private use tag / grandfathered ; grandfathered registrations langrange =3D (lang %%%%% I don=92t see why *3("-" extlang) is not include= d here ["-"script] ["-" region] *("-" variant) %%%%% I don=92t see why *("-" extension) is not includ= ed here ["-" privateuse]) lang =3D 2*8ALPHA %%%%%% I=92m not sure about the non-trivial differences from -registry here / extlang / "*" extlang =3D 2*3ALPHA %%%%%% I=92m not sure about the non-trivial differences from -registry here *2("-" 3ALPHA) ("-"(3ALPHA / "*")) script =3D 4ALPHA ; ISO 15924 code / "*" region =3D 2ALPHA ; ISO 3166 code / 3DIGIT ; UN country number / "*" variant =3D 5*8alphanum ; registered variants / ( DIGIT 3alphanum ) / "*" privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) ; grandfathered registration ; Note: i is the only singleton ; that starts a grandfathered tag alphanum =3D (ALPHA / DIGIT) ; letters and numbers -------------------------------------------------------------------------= --- I=92m not sure about some non-trivial differences; like why is not =94singleton=94 (and its reference) included in the -matching version= ? /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 13: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 1Duvpw-0000Qb-RQ; Tue, 19 Jul 2005 13: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 1Duvpv-0000QW-To for ltru@megatron.ietf.org; Tue, 19 Jul 2005 13:24:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15901 for ; Tue, 19 Jul 2005 13:24:52 -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.43) id 1DuwJa-0004Px-8V for ltru@ietf.org; Tue, 19 Jul 2005 13:55: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, 19 Jul 2005 10:24:35 -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] Reference lists; AND ABNF GRAMMARS Date: Tue, 19 Jul 2005 10:24:35 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20DE20@irvmbxw01.quest.com> Thread-Topic: [Ltru] Reference lists; AND ABNF GRAMMARS Thread-Index: AcWMhF5mYli5uXMfQSG9o9x5EdyE/QAALx7Q From: "Addison Phillips" To: "Kent Karlsson" X-OriginalArrivalTime: 19 Jul 2005 17:24:35.0830 (UTC) FILETIME=[BC0B7160:01C58C86] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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 Hi Kent, The grammar in matching is different on purpose. 1. The matching draft allows users to specify *either* a primary = language subtag *or* an extended language sequence. That is, extlangs, = for matching purposes, are considered unitary with the primary language. = You either specify the extlangs or you don't. You cannot have a sequence = like: *-cmn-*-Latn You may have sequences like: zh-*-Latn, zh-cmn-*-Latn In other words, assuming an extended language range, the wild card can = only appear at the END of a specific field. This is also illegal: en-Latn-US-*-boont // specifies multiple variants before a specific = variant. 2. Extensions are specifically excluded from extended language range = matching: their matching semantics are allowed to be different and they = are not necessarily considered to be "part" of the language identifier = proper. Of course they can be matched on a pure subtag basis. = Contributions about extensions are invited. > extlang =3D 2*3ALPHA %%%%%% I'm not sure about the non-trivial > differences from -registry here > *2("-" 3ALPHA) > ("-"(3ALPHA / "*")) This says "(concrete) primary language followed by one or more extlangs = or star" 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 Kent Karlsson > Sent: 2005?7?19? 10:07 > To: Kent Karlsson > Cc: LTRU Working Group > Subject: Re: [Ltru] Reference lists; AND ABNF GRAMMARS >=20 > I wrote: >=20 > >> [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for > Syntax > >> Specifications: ABNF", RFC 2234, November 1997. > > > > I think that should be an informative reference (it is normative for > > -registry, but not for -matching, I would say). B.t.w., I don't find > > an actual reference in the text. >=20 > Oops. It should stay normative. >=20 >=20 > The grammars in -registry and -matching should "look more similar"; > formatting, order, comments, and structure. Here is a preliminary = cleanup: >=20 > ------------------------------------------------------------ >=20 > %% For -registry >=20 > Language-Tag =3D langtag > / privateuse ; private use tag > / grandfathered ; grandfathered registrations >=20 > langtag =3D (lang > *3("-" extlang) > ["-" script] > ["-" region] > *("-" variant) > *("-" extension) > ["-" privateuse]) >=20 > lang =3D 2*4ALPHA ; shortest ISO 639 code > / registered-lang >=20 > registered-lang =3D 4*8ALPHA ; registered language subtag >=20 > extlang =3D 3ALPHA ; reserved for future use >=20 > script =3D 4ALPHA ; ISO 15924 code >=20 > region =3D 2ALPHA ; ISO 3166 code > / 3DIGIT ; UN country number >=20 > variant =3D 5*8alphanum ; registered variants > / ( DIGIT 3alphanum ) >=20 > extension =3D singleton 1*("-" (2*8alphanum)) >=20 > singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" > ; Single letters: x/X is reserved for private use >=20 > privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) >=20 > grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) > ; grandfathered registration > ; Note: i is the only singleton > ; that starts a grandfathered tag >=20 > alphanum =3D (ALPHA / DIGIT) ; letters and numbers >=20 >=20 >=20 > = -------------------------------------------------------------------------= - > - >=20 > %% for -matching >=20 > Language-Range > =3D langrange > / privateuse ; private use tag > / grandfathered ; grandfathered registrations >=20 > langrange =3D (lang > %%%%% I don't see why *3("-" extlang) is not = included > here > ["-"script] > ["-" region] > *("-" variant) > %%%%% I don't see why *("-" extension) is not = included > here > ["-" privateuse]) >=20 > lang =3D 2*8ALPHA %%%%%% I'm not sure about the non-trivial > differences from -registry here > / extlang > / "*" >=20 > extlang =3D 2*3ALPHA %%%%%% I'm not sure about the non-trivial > differences from -registry here > *2("-" 3ALPHA) > ("-"(3ALPHA / "*")) >=20 > script =3D 4ALPHA ; ISO 15924 code > / "*" >=20 > region =3D 2ALPHA ; ISO 3166 code > / 3DIGIT ; UN country number > / "*" >=20 > variant =3D 5*8alphanum ; registered variants > / ( DIGIT 3alphanum ) > / "*" >=20 > privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) >=20 > grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) > ; grandfathered registration > ; Note: i is the only singleton > ; that starts a grandfathered tag >=20 > alphanum =3D (ALPHA / DIGIT) ; letters and numbers >=20 > = -------------------------------------------------------------------------= - > -- >=20 > I'm not sure about some non-trivial differences; like why is > not "singleton" (and its reference) included in the -matching version? >=20 > /kent k >=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 Jul 19 14:03:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuwRi-0007gz-7x; Tue, 19 Jul 2005 14:03:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuwRg-0007gi-M0 for ltru@megatron.ietf.org; Tue, 19 Jul 2005 14:03:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19311 for ; Tue, 19 Jul 2005 14:03:54 -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.43) id 1DuwvM-00061x-0x for ltru@ietf.org; Tue, 19 Jul 2005 14:34:36 -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 Jul 2005 11: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] Reference lists; AND ABNF GRAMMARS Date: Tue, 19 Jul 2005 11:03:40 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C20DE6A@irvmbxw01.quest.com> Thread-Topic: [Ltru] Reference lists; AND ABNF GRAMMARS Thread-Index: AcWMhF5mYli5uXMfQSG9o9x5EdyE/QAALx7QAAGptJA= From: "Addison Phillips" To: "Addison Phillips" , "Kent Karlsson" X-OriginalArrivalTime: 19 Jul 2005 18:03:42.0346 (UTC) FILETIME=[32AD5EA0:01C58C8C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 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 I should add two notes: 1. The matching draft is not at the same maturity level as the other two = drafts (i.e. it is not in last call) 2. Probably the document should have text explaining the differences and = why they exist (it is there, I suppose, if you read the various extended = matching schemes very carefully). For now it appears as received wisdom, = which is not a good way to write specs. Currently most of us are focused on finishing the draft-registry and = draft-initial. 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 Addison Phillips > Sent: 2005?7?19? 10:25 > To: Kent Karlsson > Cc: LTRU Working Group > Subject: RE: [Ltru] Reference lists; AND ABNF GRAMMARS >=20 > Hi Kent, >=20 > The grammar in matching is different on purpose. >=20 > 1. The matching draft allows users to specify *either* a primary = language > subtag *or* an extended language sequence. That is, extlangs, for = matching > purposes, are considered unitary with the primary language. You either > specify the extlangs or you don't. You cannot have a sequence like: >=20 > *-cmn-*-Latn >=20 > You may have sequences like: >=20 > zh-*-Latn, zh-cmn-*-Latn >=20 > In other words, assuming an extended language range, the wild card can > only appear at the END of a specific field. This is also illegal: >=20 > en-Latn-US-*-boont // specifies multiple variants before a specific > variant. >=20 > 2. Extensions are specifically excluded from extended language range > matching: their matching semantics are allowed to be different and = they > are not necessarily considered to be "part" of the language identifier > proper. Of course they can be matched on a pure subtag basis. > Contributions about extensions are invited. >=20 > > extlang =3D 2*3ALPHA %%%%%% I'm not sure about the = non-trivial > > differences from -registry here > > *2("-" 3ALPHA) > > ("-"(3ALPHA / "*")) >=20 > This says "(concrete) primary language followed by one or more = extlangs or > star" >=20 > Best Regards, >=20 > Addison >=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 Kent Karlsson > > Sent: 2005?7?19? 10:07 > > To: Kent Karlsson > > Cc: LTRU Working Group > > Subject: Re: [Ltru] Reference lists; AND ABNF GRAMMARS > > > > I wrote: > > > > >> [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for > > Syntax > > >> Specifications: ABNF", RFC 2234, November 1997. > > > > > > I think that should be an informative reference (it is normative = for > > > -registry, but not for -matching, I would say). B.t.w., I don't = find > > > an actual reference in the text. > > > > Oops. It should stay normative. > > > > > > The grammars in -registry and -matching should "look more similar"; > > formatting, order, comments, and structure. Here is a preliminary > cleanup: > > > > ------------------------------------------------------------ > > > > %% For -registry > > > > Language-Tag =3D langtag > > / privateuse ; private use tag > > / grandfathered ; grandfathered registrations > > > > langtag =3D (lang > > *3("-" extlang) > > ["-" script] > > ["-" region] > > *("-" variant) > > *("-" extension) > > ["-" privateuse]) > > > > lang =3D 2*4ALPHA ; shortest ISO 639 code > > / registered-lang > > > > registered-lang =3D 4*8ALPHA ; registered language subtag > > > > extlang =3D 3ALPHA ; reserved for future use > > > > script =3D 4ALPHA ; ISO 15924 code > > > > region =3D 2ALPHA ; ISO 3166 code > > / 3DIGIT ; UN country number > > > > variant =3D 5*8alphanum ; registered variants > > / ( DIGIT 3alphanum ) > > > > extension =3D singleton 1*("-" (2*8alphanum)) > > > > singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > > ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" > > ; Single letters: x/X is reserved for private use > > > > privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) > > > > grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) > > ; grandfathered registration > > ; Note: i is the only singleton > > ; that starts a grandfathered = tag > > > > alphanum =3D (ALPHA / DIGIT) ; letters and numbers > > > > > > > > = ------------------------------------------------------------------------ > -- > > - > > > > %% for -matching > > > > Language-Range > > =3D langrange > > / privateuse ; private use tag > > / grandfathered ; grandfathered registrations > > > > langrange =3D (lang > > %%%%% I don't see why *3("-" extlang) is not = included > > here > > ["-"script] > > ["-" region] > > *("-" variant) > > %%%%% I don't see why *("-" extension) is not > included > > here > > ["-" privateuse]) > > > > lang =3D 2*8ALPHA %%%%%% I'm not sure about the = non-trivial > > differences from -registry here > > / extlang > > / "*" > > > > extlang =3D 2*3ALPHA %%%%%% I'm not sure about the = non-trivial > > differences from -registry here > > *2("-" 3ALPHA) > > ("-"(3ALPHA / "*")) > > > > script =3D 4ALPHA ; ISO 15924 code > > / "*" > > > > region =3D 2ALPHA ; ISO 3166 code > > / 3DIGIT ; UN country number > > / "*" > > > > variant =3D 5*8alphanum ; registered variants > > / ( DIGIT 3alphanum ) > > / "*" > > > > privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) > > > > grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) > > ; grandfathered registration > > ; Note: i is the only singleton > > ; that starts a grandfathered = tag > > > > alphanum =3D (ALPHA / DIGIT) ; letters and numbers > > > > = ------------------------------------------------------------------------ > -- > > -- > > > > I'm not sure about some non-trivial differences; like why is > > not "singleton" (and its reference) included in the -matching = version? > > > > /kent k > > > > > > > > _______________________________________________ > > 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 Tue Jul 19 14:23:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duwkw-0006hg-CI; Tue, 19 Jul 2005 14:23:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duwku-0006hX-UP for ltru@megatron.ietf.org; Tue, 19 Jul 2005 14:23:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20528 for ; Tue, 19 Jul 2005 14:23:47 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuxEa-0006fQ-9O for ltru@ietf.org; Tue, 19 Jul 2005 14:54:29 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Duwkj-0007nl-OX; Tue, 19 Jul 2005 11:23:38 -0700 Message-Id: <6.2.1.2.2.20050719202014.0580b820@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 19 Jul 2005 20:22:52 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] [psg.com #1075] WGLC section 3.6 specification requirements for extensions In-Reply-To: <00ac01c58bf2$8c204a00$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C20D829@irvmbxw01.quest.com> <006101c58a96$2b52c7a0$7f1afea9@oemcomputer> <6.2.1.2.2.20050717153735.03b57900@mail.afrac.org> <00ac01c58bf2$8c204a00$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 - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 OK. I am on vactions: I will feed the troll .... At 01:43 19/07/2005, Randy Presuhn wrote: >then the IESG would probably consult someone on the >ietf-languages@iana.org list. Dear Randy, they would probably consult more people than for Larrie Roberts :-) I note with pleasure that you have found ietf-languages@iana.org .... I am still with ietf-languages@alvestrand.no .... jfc PS. BTW you meant who? I meant that someone? _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 16:32:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duyl7-00011v-GO; Tue, 19 Jul 2005 16:32:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duyl5-00011S-Th for ltru@megatron.ietf.org; Tue, 19 Jul 2005 16:32:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14955 for ; Tue, 19 Jul 2005 16:32:05 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuzEi-0007s2-BJ for ltru@ietf.org; Tue, 19 Jul 2005 17:02: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 j6JKVmu2011011; Tue, 19 Jul 2005 16:31:48 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Tue, 19 Jul 2005 16:31:47 -0400 Date: Tue, 19 Jul 2005 16:31:46 -0400 From: "John.Cowan" To: Randy Presuhn Subject: Re: [Ltru] Working group last call closing date Message-ID: <20050719203146.GF1448@NYCMJCOWA2> References: <000901c588b4$e695e080$7f1afea9@oemcomputer> <006c01c58c23$40490b40$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006c01c58c23$40490b40$7f1afea9@oemcomputer> User-Agent: Mutt/1.4.2.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 Randy Presuhn scripsit: > I'd like to thank all those who have taken the time to review these documents > and submit comments. Comments are still welcome, and we'd also like to > hear from any people who have read the documents but do not have specific > comments. I have read both drafts but have no specific comments at this time. -- 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@lists.ietf.org Tue Jul 19 18:50:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv0vN-0000VK-Br; Tue, 19 Jul 2005 18:50:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv0vI-0000Nl-Ok for ltru@megatron.ietf.org; Tue, 19 Jul 2005 18:50:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10315 for ; Tue, 19 Jul 2005 18:50:45 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv1P0-0002z2-8L for ltru@ietf.org; Tue, 19 Jul 2005 19:21:31 -0400 X-Medic-Info: 752f.42dd83c1.0 RduwQlrhPU4Ssk9i Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 82890DD50; Wed, 20 Jul 2005 00:50:41 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Wed, 20 Jul 2005 00:50:41 +0200 (CEST) Message-ID: <60388.83.248.26.202.1121813441.squirrel@webmail.chalmers.se> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C20DE20@irvmbxw01.quest.com> References: <634978A7DF025A40BFEF33EB191E13BC0C20DE20@irvmbxw01.quest.com> Date: Wed, 20 Jul 2005 00:50:41 +0200 (CEST) Subject: RE: [Ltru] Reference lists; AND ABNF GRAMMARS From: "Kent Karlsson" To: "Addison Phillips" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Ok, thanks for the explanation Addison. After a bit more grammar mangling I've got the following changes for -registry ABNF and -matching ABNF to my draft cleanup. I'm not repeating unproblematic parts of the grammars that I sent earlier. This is (supposed to be) pure grammar beautification and parallelisation between the two grammars. --------------------------- %% For -registry langtag =3D (langext ["-" script] ["-" region] *("-" variant) *("-" extension) ["-" privateuse]) langext =3D lang / extlang lang =3D 2*4ALPHA ; shortest ISO 639 code / 4*8ALPHA ; registered language subtag extlang =3D (lang 1*3("-" 3ALPHA) ; reserved for future use --------------------------- %% for -matching langrange =3D (langext ["-"script] ["-" region] *("-" variant) ["-" privateuse]) langext =3D lang / extlang / "*" lang =3D 2*4ALPHA ; shortest ISO 639 code / 4*8ALPHA ; registered language subtag extlang =3D (lang *2("-" 3ALPHA) ("-"(3ALPHA / "*"))) ; reserved for future use --------------------------- /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 19:10:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1E3-0002nf-Lj; Tue, 19 Jul 2005 19:10:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1E0-0002kS-Og for ltru@megatron.ietf.org; Tue, 19 Jul 2005 19:10:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11828 for ; Tue, 19 Jul 2005 19:10:05 -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.43) id 1Dv1hi-0003lg-Gq for ltru@ietf.org; Tue, 19 Jul 2005 19:40: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, 19 Jul 2005 16:09: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] Reference lists; AND ABNF GRAMMARS Date: Tue, 19 Jul 2005 16:09:50 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C3161AA@irvmbxw01.quest.com> Thread-Topic: [Ltru] Reference lists; AND ABNF GRAMMARS Thread-Index: AcWMtEu8ArCEa/WHQLqmwC8bqXWpiQAAHA3Q From: "Addison Phillips" To: "Kent Karlsson" X-OriginalArrivalTime: 19 Jul 2005 23:09:50.0949 (UTC) FILETIME=[F737C150:01C58CB6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 We could do it like that. In some ways it is certainly more beautiful. I = note a couple of things in your suggestions: 1. 2*4ALPHA / 4*8ALPHA isn't really wrong, but the repetition of the = number 4 is confusing. It should be 2*4ALPHA/5*8ALPHA. (I'm aware that = the original draft-09 grammar has this mistake in it: it is on my = correction list for the next edit) 2. It should be noted that 4ALPHA language subtags are reserved, = ostensibly for ISO 639-6. Extlangs are reserved, ostensibly for ISO = 639-3 language codes that have macrolanguages. Under the current = grammar, extlangs will never be legal except with 2*3ALPHA values in the = first position and this is by design. (Note that extlangs are required = to have a Prefix field in the registry which specifies the primary = language subtag that they MUST be used with, even though the contents = are not yet specified.) With your revision, the ABNF would permit subtags other than ISO 639-1 = or ISO 639-2/-3 from serving as the base subtag for an extended language = subtag (of course the text could still forbid it). The matching grammar is more elegant in your version. I am inclined to = make these edits, provided there is general agreement that: a) they don't represent a substantive change b) that we want to make them Other voices? 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: Kent Karlsson [mailto:kentk@cs.chalmers.se] > Sent: 2005?7?19? 15:51 > To: Addison Phillips > Cc: LTRU Working Group > Subject: RE: [Ltru] Reference lists; AND ABNF GRAMMARS >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 19:36:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1dF-0007IU-4p; Tue, 19 Jul 2005 19:36:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1dD-0007IP-OJ for ltru@megatron.ietf.org; Tue, 19 Jul 2005 19:36:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13706 for ; Tue, 19 Jul 2005 19:36:08 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv26u-0004iw-OO for ltru@ietf.org; Tue, 19 Jul 2005 20:06:55 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dv1d5-0003NC-DR; Tue, 19 Jul 2005 16:36:03 -0700 Message-Id: <6.2.1.2.2.20050719231610.05809220@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 19 Jul 2005 23:34:39 +0200 To: "Randy Presuhn" , From: r&d afrac Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of the UN disclaimer Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.1 (/) 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: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 01:58 19/07/2005, Randy Presuhn wrote: >Hi - > > The Draft is intended to be published, so this wording cannot be in the > > IANA section only. May be a simple solution would be to enter mentions to > > the Editors (who ever they will be at whatever technical, legal, political > > level) under the form "[the WG thinks there might be a text needed here to > > possibly address the following concerns by the IETF liaison with, the IASA > > lawyers, the IANA lawyers, ICANN, GAC]". >... > >That's not how the process works. What a working group hands to the IESG >is what that working group would like to see published as an RFC, with only >those formatting changes needed to account for the difference between >i-d and RFC formats. Routinely, references will be updated and typos fixed. >The IESG may "DISCUSS" the document with the WG, which may result >in subsequent edits, as may the IETF last call. If necessary, an updated >i-d will be handed to the RFC editor. When publication time arrives, there is >the AUTH48 period during which the RFC editor verifies with the document's >editor that nothing has been broken by formatting changes, etc. Documents' >editors rarely change during this entire process. Sorry, but please reread what you wrote. "The IESG may "DISCUSS" the document with the WG". In marking ourself the text for discussion witht the WG we force that discussion. The WG has no liaison with the concerned bodies. IESG has. Since you do not want to call a debate on "complement RFC 3066" rather of "replace RFC 3066", and do not want to consider the Charter issues in the WG, it seems you want them discussed in the brouhaha of the IESG Last Call. This may give more support to the proposed additions by more legal/political oriented people. I will not oppose this due to the very reduced number of participants to the WG Last Call. But beware that if the document is not mended during the last call, this will probably lead the document to be rejected at some stage (IESG Last Call, IANA, etc.). As it is, it focuses on an resticted approach, aiming an exclusive for the language industry, against competitive open sources multilingual network oriented propositions and evolutions. Except through the reduced capacity of the DISCUSS (now precisely under discussion) there is no more flexibility. You will not be able to say that I did not warn you: imposing a text 5 allies to 1 delegate is not a warranty of success, all the more than we do not oppose the document and the work achieved. We only oppose the exclusive, the exclusion and the lack of scalability, flexibility, capacity for innovation and evolution. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 19:45:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1mh-0002bu-Bt; Tue, 19 Jul 2005 19:45:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1me-0002bp-Lz for ltru@megatron.ietf.org; Tue, 19 Jul 2005 19:45: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 TAA14282 for ; Tue, 19 Jul 2005 19:45:52 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dv1mO-0006GA-Ph for ltru@lists.ietf.org; Wed, 20 Jul 2005 01:45:40 +0200 Received: from du-001-132.access.de.clara.net ([212.82.227.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jul 2005 01:45:40 +0200 Received: from nobody by du-001-132.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Jul 2005 01:45:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 20 Jul 2005 01:44:28 +0200 Organization: Lines: 18 Message-ID: <42DD905C.5A88@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C3161AA@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-132.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Reference lists; AND ABNF GRAMMARS X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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. 2*4ALPHA / 4*8ALPHA isn't really wrong IBTD > the repetition of the number 4 is confusing ACK > It should be 2*4ALPHA/5*8ALPHA. No idea how that escaped us in -03..-09, that's seven drafts with the same bug in the ABNF. Obviously I didn't check it after http://mid.gmane.org/42927D04.407D@xyzzy.claranet.de :-( Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 19 19:50:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1r2-0005v6-5U; Tue, 19 Jul 2005 19:50:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv1r0-0005v0-86 for ltru@megatron.ietf.org; Tue, 19 Jul 2005 19:50:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14570 for ; Tue, 19 Jul 2005 19:50: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.43) id 1Dv2Ki-0005Cg-7J for ltru@ietf.org; Tue, 19 Jul 2005 20:21:09 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Tue, 19 Jul 2005 16:50: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: Reference lists; AND ABNF GRAMMARS Date: Tue, 19 Jul 2005 16:50:10 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C3161C4@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Reference lists; AND ABNF GRAMMARS Thread-Index: AcWMvDsTfpzALq9CR02NE912bu+JhAAAB6uA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 19 Jul 2005 23:50:11.0842 (UTC) FILETIME=[9A2EB620:01C58CBC] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Sadly, I did catch it previously and put it on my edit list... and kept = forgetting to make the change. I did make the change when I saw Kent's email, so it should go away this = time. Perchance you pointed this out before too, Frank? Addison 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@lists.ietf.org Wed Jul 20 01: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 1Dv6pF-0004AK-MG; Wed, 20 Jul 2005 01:08:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv6pB-00046m-N1 for ltru@megatron.ietf.org; Wed, 20 Jul 2005 01:08:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21448 for ; Wed, 20 Jul 2005 01:08:52 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv7Iw-0004gR-CF for ltru@ietf.org; Wed, 20 Jul 2005 01:39:39 -0400 X-Medic-Info: 4f3a.42dddc5b.0 4jNF322DNqCOkm2Z Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id C09E24677; Wed, 20 Jul 2005 07:08:43 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Wed, 20 Jul 2005 07:08:43 +0200 (CEST) Message-ID: <60613.83.248.26.202.1121836123.squirrel@webmail.chalmers.se> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C3161AA@irvmbxw01.quest.com> References: <634978A7DF025A40BFEF33EB191E13BC0C3161AA@irvmbxw01.quest.com> Date: Wed, 20 Jul 2005 07:08:43 +0200 (CEST) Subject: RE: [Ltru] Reference lists; AND ABNF GRAMMARS From: "Kent Karlsson" To: "Addison Phillips" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 > 1. 2*4ALPHA / 4*8ALPHA isn't really wrong, but the repetition of the ... Ok. I thought it was an intentional overlap. > 2. It should be noted that 4ALPHA language subtags are reserved, ... > extlangs will never be legal except with 2*3ALPHA values in the first ... > With your revision, the ABNF would permit subtags other than ISO 639-1 = or > ISO 639-2/-3 from serving as the base subtag for an extended language > subtag (of course the text could still forbid it). You mean it should be (putting this restriction in the grammar): %% For -registry extlang =3D (2*3ALPHA 1*3("-" 3ALPHA) ; reserved for future use %% for -matching extlang =3D (2*3ALPHA *2("-" 3ALPHA) ("-"(3ALPHA / "*"))) ; reserved for future use (or with some non-terminal for 2*3ALPHA and maybe also for 3ALPHA) /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 21 10:36:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvc9z-0006PF-R9; Thu, 21 Jul 2005 10:36:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvc9x-0006P7-OR for ltru@megatron.ietf.org; Thu, 21 Jul 2005 10:36: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 KAA05934 for ; Thu, 21 Jul 2005 10:36:23 -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 <20050721143551.JUQJ24042.mta11.adelphia.net@DEWELL> for ; Thu, 21 Jul 2005 10:35:51 -0400 Message-ID: <004401c58e01$717176a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050720160712.TFLH9082.mta1.adelphia.net@megatron.ietf.org> Date: Thu, 21 Jul 2005 07:35:28 -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: Reference lists; AND ABNF GRAMMARS X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Kent Karlsson wrote > You mean it should be (putting this restriction in the grammar): > > %% For -registry > extlang = (2*3ALPHA > 1*3("-" 3ALPHA) ; reserved for future use > > %% for -matching > extlang = (2*3ALPHA > *2("-" 3ALPHA) > ("-"(3ALPHA / "*"))) > ; reserved for future use > > (or with some non-terminal for 2*3ALPHA and maybe also for 3ALPHA) That's still not right; it combines the concept of a primary language subtag and an extended language subtag under one ABNF umbrella. How about we try it first in prose, and then try to convert that into ABNF: A primary language subtag can be 2 to 8 alphas long, although the 4-letter ones are reserved for the (comparatively distant) future. There must be exactly one primary language subtag, unless you have a wholly private-use tag of the form "x-whatever", in which case the rest of this message doesn't pertain. An extended language subtag must be exactly 3 letters long. There may be anywhere from 0 to 3 of these. This whole mechanism is reserved for the (comparatively near) future. An "extlang" does not comprise a primary language subtag plus a string of 3-letter thingies. Those 3-letter thingies *are* the extlangs (extended language subtags). The fact that an extended language subtag can only appear after a primary language subtag is nothing special; the primary language subtag is required for all types of regularly formed RFC 3066bis language tags (non-grandfathered, non-private-use). -- 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 Thu Jul 21 10:42:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcG9-0001h5-JK; Thu, 21 Jul 2005 10:42:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcG9-0001gw-1R for ltru@megatron.ietf.org; Thu, 21 Jul 2005 10:42:49 -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 KAA06550 for ; Thu, 21 Jul 2005 10:42:46 -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 <20050721144217.CCOQ19267.mta10.adelphia.net@DEWELL> for ; Thu, 21 Jul 2005 10:42:17 -0400 Message-ID: <004901c58e02$5b211260$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050720160712.TFLH9082.mta1.adelphia.net@megatron.ietf.org> Date: Thu, 21 Jul 2005 07:42: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] Re: Reference lists; AND ABNF GRAMMARS X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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. 2*4ALPHA / 4*8ALPHA isn't really wrong, but the repetition of the > number 4 is confusing. It should be 2*4ALPHA/5*8ALPHA. (I'm aware that > the original draft-09 grammar has this mistake in it: it is on my > correction list for the next edit) Actually, I think 2*4ALPHA / 4*8ALPHA really is wrong, not just a matter of confusion. If 4-letter primary language subtags are supposed to be reserved for some future standard, then it shouldn't also be possible to register them. Otherwise we are setting ourselves up to register a 4-letter subtag that later turns out to belong to the standard as well, and Chaos Shall Reign. I've been going by the assumption all this time that registered primary language subtags were 5 to 8 letters long, and was surprised to see that the ABNF states 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 Thu Jul 21 11:11:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvchi-0005su-Rs; Thu, 21 Jul 2005 11:11:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvchi-0005sk-9O for ltru@megatron.ietf.org; Thu, 21 Jul 2005 11:11:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08580 for ; Thu, 21 Jul 2005 11:11:16 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DvdBj-0006LC-HF for ltru@ietf.org; Thu, 21 Jul 2005 11:42:22 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Thu, 21 Jul 2005 08:05:43 -0700 Message-ID: <004701c58e06$667be230$dd7e3009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <20050720160712.TFLH9082.mta1.adelphia.net@megatron.ietf.org> <004901c58e02$5b211260$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: Reference lists; AND ABNF GRAMMARS Date: Thu, 21 Jul 2005 08:10:58 -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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA08580 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 ABNF is tricky, and it is not trivial to 'pretty it up' while maintaining precisely the same meaning. At this stage, we should only be focusing on substantive issues, not whether the ABNF is pretty or not. So if the current ABNF has a substantive flaw, we should fix it. Otherwis= e leave it alone. =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Thursday, July 21, 2005 07:42 Subject: [Ltru] Re: Reference lists; AND ABNF GRAMMARS > Addison Phillips wrote: > > > 1. 2*4ALPHA / 4*8ALPHA isn't really wrong, but the repetition of the > > number 4 is confusing. It should be 2*4ALPHA/5*8ALPHA. (I'm aware tha= t > > the original draft-09 grammar has this mistake in it: it is on my > > correction list for the next edit) > > Actually, I think 2*4ALPHA / 4*8ALPHA really is wrong, not just a matte= r > of confusion. If 4-letter primary language subtags are supposed to be > reserved for some future standard, then it shouldn't also be possible t= o > register them. Otherwise we are setting ourselves up to register a > 4-letter subtag that later turns out to belong to the standard as well, > and Chaos Shall Reign. > > I've been going by the assumption all this time that registered primary > language subtags were 5 to 8 letters long, and was surprised to see tha= t > the ABNF states otherwise. > > -- > 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 Thu Jul 21 11:25:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvcvE-0003ck-5p; Thu, 21 Jul 2005 11: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 1DvcvC-0003Wi-DD for ltru@megatron.ietf.org; Thu, 21 Jul 2005 11:25:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09524 for ; Thu, 21 Jul 2005 11:25: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.43) id 1DvdPE-0007F0-0b for ltru@ietf.org; Thu, 21 Jul 2005 11:56:16 -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 Jul 2005 08:24:57 -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: Reference lists; AND ABNF GRAMMARS Date: Thu, 21 Jul 2005 08:24:57 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C316716@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Reference lists; AND ABNF GRAMMARS Thread-Index: AcWOBoYl3dsMupH4TzGDJoMnxqHMQgAAYXEg From: "Addison Phillips" To: "Mark Davis" , "Doug Ewell" , "LTRU Working Group" X-OriginalArrivalTime: 21 Jul 2005 15:24:57.0849 (UTC) FILETIME=[5A75F690:01C58E08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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="===============1374820617==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1374820617== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 VGhlcmUgd2FzIGEgc3Vic3RhbnRpdmUgZmxhdyBhcyBub3RlZC4gSSBmaXhlZCBpdCB3aXRob3V0 IG90aGVyd2lzZSBtb2RpZnlpbmcgdGhlIEFCTkYuIEkgZG9uJ3QgaW50ZW5kIHRvIG1vZGlmeSB0 aGUgQUJORiBmdXJ0aGVyIHdpdGhvdXQgd29ya2luZyBncm91cCBjb25zZW5zdXMuDQoNCkkgKndp bGwqIHVwZGF0ZSB0aGUgbWF0Y2hpbmcgQUJORiB3aXRoIHNvbWUgb2YgdGhlIHN1Z2dlc3Rpb25z LCBzaW5jZSBzb21lIG9mIHRoZSBBQk5GIGlzIHF1aXRlIG9ic2N1cmUsIGJ1dCB0aGUgbWF0Y2hp bmcgZHJhZnQgaXNuJ3QgaW4gbGFzdCBjYWxsLg0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhp bGxpcHMNCkdsb2JhbGl6YXRpb24gQXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KQ2hhaXIsIFcz QyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCg0KSW50ZXJuYXRpb25h bGl6YXRpb24gaXMgbm90IGEgZmVhdHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGx0cnUtYm91bmNlc0BsaXN0cy5pZXRm Lm9yZyBbbWFpbHRvOmx0cnUtYm91bmNlc0BsaXN0cy5pZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9m IE1hcmsgRGF2aXMNCj4gU2VudDogVGh1cnNkYXksIEp1bHkgMjEsIDIwMDUgODoxMSBBTQ0KPiBU bzogRG91ZyBFd2VsbDsgTFRSVSBXb3JraW5nIEdyb3VwDQo+IFN1YmplY3Q6IFJlOiBbTHRydV0g UmU6IFJlZmVyZW5jZSBsaXN0czsgQU5EIEFCTkYgR1JBTU1BUlMNCj4gDQo+IEFCTkYgaXMgdHJp Y2t5LCBhbmQgaXQgaXMgbm90IHRyaXZpYWwgdG8gJ3ByZXR0eSBpdCB1cCcgd2hpbGUgbWFpbnRh aW5pbmcNCj4gcHJlY2lzZWx5IHRoZSBzYW1lIG1lYW5pbmcuIEF0IHRoaXMgc3RhZ2UsIHdlIHNo b3VsZCBvbmx5IGJlIGZvY3VzaW5nIG9uDQo+IHN1YnN0YW50aXZlIGlzc3Vlcywgbm90IHdoZXRo ZXIgdGhlIEFCTkYgaXMgcHJldHR5IG9yIG5vdC4NCj4gDQo+IFNvIGlmIHRoZSBjdXJyZW50IEFC TkYgaGFzIGEgc3Vic3RhbnRpdmUgZmxhdywgd2Ugc2hvdWxkIGZpeCBpdC4gT3RoZXJ3aXNlDQo+ IGxlYXZlIGl0IGFsb25lLg0KPiANCj4g4oCOTWFyaw0KPiANCj4gLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLQ0KPiBGcm9tOiAiRG91ZyBFd2VsbCIgPGRld2VsbEBhZGVscGhpYS5uZXQ+DQo+ IFRvOiAiTFRSVSBXb3JraW5nIEdyb3VwIiA8bHRydUBpZXRmLm9yZz4NCj4gU2VudDogVGh1cnNk YXksIEp1bHkgMjEsIDIwMDUgMDc6NDINCj4gU3ViamVjdDogW0x0cnVdIFJlOiBSZWZlcmVuY2Ug bGlzdHM7IEFORCBBQk5GIEdSQU1NQVJTDQo+IA0KPiANCj4gPiBBZGRpc29uIFBoaWxsaXBzIDxh ZGRpc29uIGRvdCBwaGlsbGlwcyBhdCBxdWVzdCBkb3QgY29tPiB3cm90ZToNCj4gPg0KPiA+ID4g MS4gMio0QUxQSEEgLyA0KjhBTFBIQSBpc24ndCByZWFsbHkgd3JvbmcsIGJ1dCB0aGUgcmVwZXRp dGlvbiBvZiB0aGUNCj4gPiA+IG51bWJlciA0IGlzIGNvbmZ1c2luZy4gSXQgc2hvdWxkIGJlIDIq NEFMUEhBLzUqOEFMUEhBLiAoSSdtIGF3YXJlIHRoYXQNCj4gPiA+IHRoZSBvcmlnaW5hbCBkcmFm dC0wOSBncmFtbWFyIGhhcyB0aGlzIG1pc3Rha2UgaW4gaXQ6IGl0IGlzIG9uIG15DQo+ID4gPiBj b3JyZWN0aW9uIGxpc3QgZm9yIHRoZSBuZXh0IGVkaXQpDQo+ID4NCj4gPiBBY3R1YWxseSwgSSB0 aGluayAyKjRBTFBIQSAvIDQqOEFMUEhBIHJlYWxseSBpcyB3cm9uZywgbm90IGp1c3QgYSBtYXR0 ZXINCj4gPiBvZiBjb25mdXNpb24uICBJZiA0LWxldHRlciBwcmltYXJ5IGxhbmd1YWdlIHN1YnRh Z3MgYXJlIHN1cHBvc2VkIHRvIGJlDQo+ID4gcmVzZXJ2ZWQgZm9yIHNvbWUgZnV0dXJlIHN0YW5k YXJkLCB0aGVuIGl0IHNob3VsZG4ndCBhbHNvIGJlIHBvc3NpYmxlIHRvDQo+ID4gcmVnaXN0ZXIg dGhlbS4gIE90aGVyd2lzZSB3ZSBhcmUgc2V0dGluZyBvdXJzZWx2ZXMgdXAgdG8gcmVnaXN0ZXIg YQ0KPiA+IDQtbGV0dGVyIHN1YnRhZyB0aGF0IGxhdGVyIHR1cm5zIG91dCB0byBiZWxvbmcgdG8g dGhlIHN0YW5kYXJkIGFzIHdlbGwsDQo+ID4gYW5kIENoYW9zIFNoYWxsIFJlaWduLg0KPiA+DQo+ ID4gSSd2ZSBiZWVuIGdvaW5nIGJ5IHRoZSBhc3N1bXB0aW9uIGFsbCB0aGlzIHRpbWUgdGhhdCBy ZWdpc3RlcmVkIHByaW1hcnkNCj4gPiBsYW5ndWFnZSBzdWJ0YWdzIHdlcmUgNSB0byA4IGxldHRl cnMgbG9uZywgYW5kIHdhcyBzdXJwcmlzZWQgdG8gc2VlIHRoYXQNCj4gPiB0aGUgQUJORiBzdGF0 ZXMgb3RoZXJ3aXNlLg0KPiA+DQo+ID4gLS0NCj4gPiBEb3VnIEV3ZWxsDQo+ID4gRnVsbGVydG9u LCBDYWxpZm9ybmlhDQo+ID4gaHR0cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KPiA+ DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+ID4gTHRydSBtYWlsaW5nIGxpc3QNCj4gPiBMdHJ1QGxpc3RzLmlldGYub3JnDQo+ ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KPiA+DQo+ID4N Cj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gTHRydSBtYWlsaW5nIGxpc3QNCj4gTHRydUBsaXN0cy5pZXRmLm9yZw0KPiBodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sdHJ1DQoNCg== --===============1374820617== 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 --===============1374820617==-- From ltru-bounces@lists.ietf.org Thu Jul 21 18:46:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvjoL-0002JA-8j; Thu, 21 Jul 2005 18:46:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvjoJ-0002GY-OF for ltru@megatron.ietf.org; Thu, 21 Jul 2005 18:46:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22299 for ; Thu, 21 Jul 2005 18:46:32 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvkIQ-00060D-0W for ltru@ietf.org; Thu, 21 Jul 2005 19:17:43 -0400 X-Medic-Info: 20b3.42e025c1.0 E5LnUBMhvhVJtEfg Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 314CD4010; Fri, 22 Jul 2005 00:46:25 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Fri, 22 Jul 2005 00:46:25 +0200 (CEST) Message-ID: <60425.83.248.26.202.1121985985.squirrel@webmail.chalmers.se> In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C316716@irvmbxw01.quest.com> References: <634978A7DF025A40BFEF33EB191E13BC0C316716@irvmbxw01.quest.com> Date: Fri, 22 Jul 2005 00:46:25 +0200 (CEST) Subject: RE: [Ltru] Re: Reference lists; AND ABNF GRAMMARS From: "Kent Karlsson" To: "Addison Phillips" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable Cc: Doug Ewell , 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 > There was a substantive flaw as noted. I fixed it without > otherwise modifying the ABNF. I don't intend to modify the > ABNF further without working group consensus. > > I *will* update the matching ABNF with some of the > suggestions, since some of the ABNF is quite obscure, but the > matching draft isn't in last call. > > Addison I think it is very important that the -registry and the -matching grammars are as similar as ever possible. Otherwise there will be needless confusion. I'm a bit surprised that they are not at present in "synch". I've looked at the comments from Addison and Doug, and the "as parallel as I can get them" grammars for -registry and -matching are given below. This without doing spurious name changes. However, I've added some nonterminals for clarity. I hope I have chosen names for the (new) nonterminals in such a way that they are at least not misleading. This means changing also the -registry grammar. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D %% For -registry Language-Tag =3D langtag / privateuse ; private use tag / grandfathered ; grandfathered registrations langtag =3D (lang ["-" script] ["-" region] *("-" variant) *("-" extension) ["-" privateuse]) lang =3D stdlang / stdlangext / reglang stdlang =3D 2*4ALPHA ; shortest ISO 639 code stdlangext =3D stdlang 1*3("-" extlang) ; reserved for future use reglang =3D 5*8ALPHA ; registered language subtag extlang =3D 3ALPHA script =3D 4ALPHA ; ISO 15924 code region =3D stdregion / unregion stdregion =3D 2ALPHA ; ISO 3166 code unregion =3D 3DIGIT ; UN region number variant =3D regvariant / genvariant regvariant =3D 5*8alphanum ; registered variant genvariant =3D (DIGIT 3alphanum) ; generic variant extension =3D singleton 1*("-" (2*8alphanum)) singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" ; Single letters: x/X is reserved for private use privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) ; grandfathered registration ; Note: i is the only singleton ; that starts a grandfathered tag alphanum =3D (ALPHA / DIGIT) ; letters and numbers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D %% for -matching Language-Range =3D langrange / privateuse ; private use tag / grandfathered ; grandfathered registrations langrange =3D (lang ["-"script] ["-" region] *("-" variant) ["-" privateuse]) lang =3D stdlang / stdlangext / reglang / "*" stdlang =3D 2*4ALPHA ; shortest ISO 639 code stdlangext =3D stdlang *2("-" extlang) ("-"(extlang / "*")) ; reserved for future use reglang =3D 5*8ALPHA ; registered language subtag extlang =3D 3ALPHA script =3D 4ALPHA ; ISO 15924 code / "*" region =3D stdregion / unregion / "*" stdregion =3D 2ALPHA ; ISO 3166 code unregion =3D 3DIGIT ; UN region number variant =3D regvariant / genvariant / "*" regvariant =3D 5*8alphanum ; registered variant genvariant =3D (DIGIT 3alphanum) ; generic variant privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) ; grandfathered registration ; Note: i is the only singleton ; that starts a grandfathered tag alphanum =3D (ALPHA / DIGIT) ; letters and numbers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D /kent k _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 21 18:59:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvk11-00081z-1R; Thu, 21 Jul 2005 18:59:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvk0y-0007zu-51 for ltru@megatron.ietf.org; Thu, 21 Jul 2005 18:59:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24753 for ; Thu, 21 Jul 2005 18:59: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.43) id 1DvkV5-00075T-Lp for ltru@ietf.org; Thu, 21 Jul 2005 19:30: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, 21 Jul 2005 15:59: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: Reference lists; AND ABNF GRAMMARS Date: Thu, 21 Jul 2005 15:59:22 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C31699B@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Reference lists; AND ABNF GRAMMARS Thread-Index: AcWORmWOPqaeOdPRTEu1/Mxdb7j4iAAADytQ From: "Addison Phillips" To: "Kent Karlsson" X-OriginalArrivalTime: 21 Jul 2005 22:59:24.0411 (UTC) FILETIME=[D69924B0:01C58E47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Content-Transfer-Encoding: quoted-printable Cc: Doug Ewell , 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 Kent, Your ABNF is very clear and seems, at first look, to represent an = improvement. But... I'm inclined not to make these changes, not because they aren't more = beautiful or even desirable, but simply because they are unnecessary = changes at this late date. If a lot of folks weigh in in-favor for the change, I'll do it, = otherwise, this is a Last Call and the changes are editorial, not = substantive. Since they affect the ABNF, I'd rather see a show of = support for the change including recognition that it doesn't require an = additional last call time period. 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: Kent Karlsson [mailto:kentk@cs.chalmers.se] > Sent: Thursday, July 21, 2005 3:46 PM > To: Addison Phillips > Cc: Mark Davis; Doug Ewell; LTRU Working Group > Subject: RE: [Ltru] Re: Reference lists; AND ABNF GRAMMARS >=20 > > There was a substantive flaw as noted. I fixed it without > > otherwise modifying the ABNF. I don't intend to modify the > > ABNF further without working group consensus. > > > > I *will* update the matching ABNF with some of the > > suggestions, since some of the ABNF is quite obscure, but the > > matching draft isn't in last call. > > > > Addison >=20 >=20 > I think it is very important that the -registry and the -matching > grammars are as similar as ever possible. Otherwise there will be > needless confusion. I'm a bit surprised that they are not at present > in "synch". >=20 > I've looked at the comments from Addison and Doug, and the > "as parallel as I can get them" grammars for -registry and -matching > are given below. This without doing spurious name changes. However, > I've added some nonterminals for clarity. I hope I have chosen names > for the (new) nonterminals in such a way that they are at least not > misleading. >=20 > This means changing also the -registry grammar. >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > %% For -registry >=20 > Language-Tag =3D langtag > / privateuse ; private use tag > / grandfathered ; grandfathered registrations >=20 > langtag =3D (lang > ["-" script] > ["-" region] > *("-" variant) > *("-" extension) > ["-" privateuse]) >=20 > lang =3D stdlang > / stdlangext > / reglang >=20 > stdlang =3D 2*4ALPHA ; shortest ISO 639 code >=20 > stdlangext =3D stdlang > 1*3("-" extlang) > ; reserved for future use >=20 > reglang =3D 5*8ALPHA ; registered language subtag >=20 > extlang =3D 3ALPHA >=20 > script =3D 4ALPHA ; ISO 15924 code >=20 > region =3D stdregion > / unregion >=20 > stdregion =3D 2ALPHA ; ISO 3166 code >=20 > unregion =3D 3DIGIT ; UN region number >=20 > variant =3D regvariant > / genvariant >=20 > regvariant =3D 5*8alphanum ; registered variant >=20 > genvariant =3D (DIGIT 3alphanum) ; generic variant >=20 > extension =3D singleton 1*("-" (2*8alphanum)) >=20 > singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" > ; Single letters: x/X is reserved for private use >=20 > privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) >=20 > grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) > ; grandfathered registration > ; Note: i is the only singleton > ; that starts a grandfathered tag >=20 > alphanum =3D (ALPHA / DIGIT) ; letters and numbers >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > %% for -matching >=20 > Language-Range =3D langrange > / privateuse ; private use tag > / grandfathered ; grandfathered registrations >=20 > langrange =3D (lang > ["-"script] > ["-" region] > *("-" variant) > ["-" privateuse]) >=20 > lang =3D stdlang > / stdlangext > / reglang > / "*" >=20 > stdlang =3D 2*4ALPHA ; shortest ISO 639 code >=20 > stdlangext =3D stdlang > *2("-" extlang) > ("-"(extlang / "*")) > ; reserved for future use >=20 > reglang =3D 5*8ALPHA ; registered language subtag >=20 > extlang =3D 3ALPHA >=20 > script =3D 4ALPHA ; ISO 15924 code > / "*" >=20 > region =3D stdregion > / unregion > / "*" >=20 > stdregion =3D 2ALPHA ; ISO 3166 code >=20 > unregion =3D 3DIGIT ; UN region number >=20 > variant =3D regvariant > / genvariant > / "*" >=20 > regvariant =3D 5*8alphanum ; registered variant >=20 > genvariant =3D (DIGIT 3alphanum) ; generic variant >=20 > privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) >=20 > grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) > ; grandfathered registration > ; Note: i is the only singleton > ; that starts a grandfathered tag >=20 > alphanum =3D (ALPHA / DIGIT) ; letters and numbers >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D >=20 > /kent k >=20 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 21 20:36:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvlWy-0001E4-Fl; Thu, 21 Jul 2005 20: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 1DvlWv-00013Z-HO for ltru@megatron.ietf.org; Thu, 21 Jul 2005 20:36: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 UAA06107 for ; Thu, 21 Jul 2005 20:36:43 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DvlWq-00062z-GO for ltru@lists.ietf.org; Fri, 22 Jul 2005 02:36:40 +0200 Received: from du-001-214.access.de.clara.net ([212.82.227.214]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jul 2005 02:36:40 +0200 Received: from nobody by du-001-214.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jul 2005 02:36:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 22 Jul 2005 02:34:48 +0200 Organization: Lines: 12 Message-ID: <42E03F28.407B@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C316716@irvmbxw01.quest.com> <60425.83.248.26.202.1121985985.squirrel@webmail.chalmers.se> 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-214.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Reference lists; AND ABNF GRAMMARS X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Kent Karlsson wrote: > I hope I have chosen names for the (new) nonterminals > in such a way that they are at least not misleading. Your is an exception. Otherwise I could live with the -registry part. I'm too lazy to check the -matching part at this time, and the authors are clearly not happy with last minute changes of the -registry part. FWIW, Bill's validator says "okay" for your version, bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 21 20:58:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvlrg-0004TJ-QB; Thu, 21 Jul 2005 20:58:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvlre-0004Rn-KY for ltru@megatron.ietf.org; Thu, 21 Jul 2005 20:58:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07385 for ; Thu, 21 Jul 2005 20:58:09 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvmLm-0006xt-Ix for ltru@ietf.org; Thu, 21 Jul 2005 21:29:19 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DvlrR-0005vX-Oe; Thu, 21 Jul 2005 17:57:58 -0700 Message-Id: <6.2.1.2.2.20050722025451.036350f0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 22 Jul 2005 02:56:37 +0200 To: Frank Ellermann , ltru@ietf.org From: r&d afrac Subject: Re: [Ltru] Re: Reference lists; AND ABNF GRAMMARS In-Reply-To: <42E03F28.407B@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C316716@irvmbxw01.quest.com> <60425.83.248.26.202.1121985985.squirrel@webmail.chalmers.se> <42E03F28.407B@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 - afrac.org 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 02:34 22/07/2005, Frank Ellermann wrote: >and the authors are clearly not happy with last minute changes of the >-registry part. I am not aware we are July 28th, 23:59. I feel we are a week before. Either the proposed change is correct and we want it (the WG is the real author) or it is not and we do not want it. I trust your judgment on Kent proposition: is it correct or not? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 21 20: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 1Dvlrk-0004Tl-WB; Thu, 21 Jul 2005 20: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 1Dvlrd-0004Rm-MV for ltru@megatron.ietf.org; Thu, 21 Jul 2005 20:58:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07382 for ; Thu, 21 Jul 2005 20:58:08 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvmLm-0006xv-GP for ltru@ietf.org; Thu, 21 Jul 2005 21:29:18 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DvlrQ-0005vX-4A; Thu, 21 Jul 2005 17:57:56 -0700 Message-Id: <6.2.1.2.2.20050722021153.03695a50@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 22 Jul 2005 02:57:35 +0200 To: "Addison Phillips" , "Kent Karlsson" From: r&d afrac Subject: RE: [Ltru] Re: Reference lists; AND ABNF GRAMMARS In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C31699B@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C31699B@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 - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: Doug Ewell , 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 Kent, I am totally unable and definitely not interested in understanding the ABNF of a proposition I support (if it is a useful to some) as a complement of RFC 3066, but which will be blocked at some stage if it claims to be the replacement of RFC 3066, the BCP 47 and a exclusive and excluding standard for the Internet leading to a probable split of the Internet. Addison is not excited to upgrade the ABNF, however beautiful or desirable it may be, because the "late date", says he. This seems an odd reason in a Last Call which is supposed to permit just that . Except if you consider the Varsaw ISO meeting, where Addison, Mark and Peter will quote the Draft in the appendixes of the ISO 639-3 and ISO 639-4 drafts. An RFC/BCP would have been better, but a timely unanimous support by the WG-Ltru through its WGLC is not that bad (even if it is not the case and even if everyone (will) know(s) it). After having been clear on the political issue, I think no one will suspect me to support the proposed Open Source exclusion, nor will be able to accuse me not to have disclosed it and fought it, to try to obtain a Draft truly in favor of an Internet open use, in the respect of non analysed Charter of this WG. This is why I think I can today support Addison's proposition and favor a status quo on the text (and ABNF) at this stage. Because of this last point: everyone knows about it. And because of the reason given by Addison. However, if you truly believe that the current ABNF is confusing and different between the two drafts and that the intelligibility of the Draft, whatever its other (de)merits absolutely call for the correction of the ABNF you propose, I will support you and call everyone to support you. In this case, I remind you that the Open Source, innovation and reasonable other uses exclusion format ( privateuse = ("x"/"X") 1*("-" (1*8alphanum)) ) is irrelevant as in violation with the Charter's requirement to correct RFC 3066's errors and with a documented project and beginning common practices quoted in this WG, and now running code. It should be modified to support a much larger alphanum size (we currently supports a memory size of 256) including characters such ".:#/?=". Thank you for your comments. jfc At 00:59 22/07/2005, Addison Phillips wrote: >Kent, > >Your ABNF is very clear and seems, at first look, to represent an >improvement. But... > >I'm inclined not to make these changes, not because they aren't more >beautiful or even desirable, but simply because they are unnecessary >changes at this late date. > >If a lot of folks weigh in in-favor for the change, I'll do it, otherwise, >this is a Last Call and the changes are editorial, not substantive. Since >they affect the ABNF, I'd rather see a show of support for the change >including recognition that it doesn't require an additional last call time >period. > >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: Kent Karlsson [mailto:kentk@cs.chalmers.se] > > Sent: Thursday, July 21, 2005 3:46 PM > > To: Addison Phillips > > Cc: Mark Davis; Doug Ewell; LTRU Working Group > > Subject: RE: [Ltru] Re: Reference lists; AND ABNF GRAMMARS > > > > > There was a substantive flaw as noted. I fixed it without > > > otherwise modifying the ABNF. I don't intend to modify the > > > ABNF further without working group consensus. > > > > > > I *will* update the matching ABNF with some of the > > > suggestions, since some of the ABNF is quite obscure, but the > > > matching draft isn't in last call. > > > > > > Addison > > > > > > I think it is very important that the -registry and the -matching > > grammars are as similar as ever possible. Otherwise there will be > > needless confusion. I'm a bit surprised that they are not at present > > in "synch". > > > > I've looked at the comments from Addison and Doug, and the > > "as parallel as I can get them" grammars for -registry and -matching > > are given below. This without doing spurious name changes. However, > > I've added some nonterminals for clarity. I hope I have chosen names > > for the (new) nonterminals in such a way that they are at least not > > misleading. > > > > This means changing also the -registry grammar. > > > > ========================================================= > > %% For -registry > > > > Language-Tag = langtag > > / privateuse ; private use tag > > / grandfathered ; grandfathered registrations > > > > langtag = (lang > > ["-" script] > > ["-" region] > > *("-" variant) > > *("-" extension) > > ["-" privateuse]) > > > > lang = stdlang > > / stdlangext > > / reglang > > > > stdlang = 2*4ALPHA ; shortest ISO 639 code > > > > stdlangext = stdlang > > 1*3("-" extlang) > > ; reserved for future use > > > > reglang = 5*8ALPHA ; registered language subtag > > > > extlang = 3ALPHA > > > > script = 4ALPHA ; ISO 15924 code > > > > region = stdregion > > / unregion > > > > stdregion = 2ALPHA ; ISO 3166 code > > > > unregion = 3DIGIT ; UN region number > > > > variant = regvariant > > / genvariant > > > > regvariant = 5*8alphanum ; registered variant > > > > genvariant = (DIGIT 3alphanum) ; generic variant > > > > extension = singleton 1*("-" (2*8alphanum)) > > > > singleton = %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > > ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" > > ; Single letters: x/X is reserved for private use > > > > privateuse = ("x"/"X") 1*("-" (1*8alphanum)) > > > > grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum)) > > ; grandfathered registration > > ; Note: i is the only singleton > > ; that starts a grandfathered tag > > > > alphanum = (ALPHA / DIGIT) ; letters and numbers > > > > ========================================================= > > > > %% for -matching > > > > Language-Range = langrange > > / privateuse ; private use tag > > / grandfathered ; grandfathered registrations > > > > langrange = (lang > > ["-"script] > > ["-" region] > > *("-" variant) > > ["-" privateuse]) > > > > lang = stdlang > > / stdlangext > > / reglang > > / "*" > > > > stdlang = 2*4ALPHA ; shortest ISO 639 code > > > > stdlangext = stdlang > > *2("-" extlang) > > ("-"(extlang / "*")) > > ; reserved for future use > > > > reglang = 5*8ALPHA ; registered language subtag > > > > extlang = 3ALPHA > > > > script = 4ALPHA ; ISO 15924 code > > / "*" > > > > region = stdregion > > / unregion > > / "*" > > > > stdregion = 2ALPHA ; ISO 3166 code > > > > unregion = 3DIGIT ; UN region number > > > > variant = regvariant > > / genvariant > > / "*" > > > > regvariant = 5*8alphanum ; registered variant > > > > genvariant = (DIGIT 3alphanum) ; generic variant > > > > privateuse = ("x"/"X") 1*("-" (1*8alphanum)) > > > > grandfathered = 1*3ALPHA 1*2("-" (2*8alphanum)) > > ; grandfathered registration > > ; Note: i is the only singleton > > ; that starts a grandfathered tag > > > > alphanum = (ALPHA / DIGIT) ; letters and numbers > > > > ========================================================= > > > > /kent k > > > > > >_______________________________________________ >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 Jul 21 21:46:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvmbw-0002N3-Qf; Thu, 21 Jul 2005 21:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvmbw-0002Ml-1R for ltru@megatron.ietf.org; Thu, 21 Jul 2005 21:46:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09767 for ; Thu, 21 Jul 2005 21:45:55 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvn60-0000ju-FQ for ltru@ietf.org; Thu, 21 Jul 2005 22:17:06 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6M1jNI03937; Fri, 22 Jul 2005 10:45:23 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id f7ba24d2_fa53_11d9_9da6_0030482532aa_15554; Fri, 22 Jul 2005 10:57:32 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO001096; 22 Jul 05 10:51:23 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 22 Jul 05 10:51:05 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG001091; 22 Jul 05 10:51:02 +0900 Message-Id: <6.0.0.20.2.20050720180904.07e45b10@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 22 Jul 2005 10:44:49 +0900 To: r&d afrac , "Randy Presuhn" , From: Martin Duerst Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN disclaimer In-Reply-To: <6.2.1.2.2.20050719231610.05809220@pop.online.fr> References: <6.2.1.2.2.20050719231610.05809220@pop.online.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 [chair hat on] At 06:34 05/07/20, r&d afrac wrote: >At 01:58 19/07/2005, Randy Presuhn wrote: >>That's not how the process works. What a working group hands to the IESG >>is what that working group would like to see published as an RFC, with only >>those formatting changes needed to account for the difference between >>i-d and RFC formats. Routinely, references will be updated and typos fixed. >>The IESG may "DISCUSS" the document with the WG, which may result >>in subsequent edits, as may the IETF last call. If necessary, an updated >>i-d will be handed to the RFC editor. When publication time arrives, there is >>the AUTH48 period during which the RFC editor verifies with the document's >>editor that nothing has been broken by formatting changes, etc. Documents' >>editors rarely change during this entire process. > >Sorry, but please reread what you wrote. "The IESG may "DISCUSS" the document with the WG". In marking ourself the text for discussion witht the WG we force that discussion. The WG has no liaison with the concerned bodies. IESG has. Randy is right. "DISCUSS" refers to a very specific part of the process, in particular to questions, comments or requests some members of the IESG may have on the draft. This is recorded as a "DISCUSS" in the draft tracker (see https://datatracker.ietf.org/public/pidtracker.cgi). The WG is expected to send the draft(s) to the AD and the IESG ***in the best possible fashion***, after having done everything they think is necessary. If we asa WG come to (rough) consensus that some "political disclaimer" or whatever we may call it is necessary, then we should make our best efforts to get the best possible text. If some IESG members then think that this has to be changed, they will raise a "DISCUSS". But going to the IESG with a draft that says something like "IESG, for this section, please do the work we were supposed to do" isn't an option. If the WG comes to the (rough) consensus that it's better NOT to have a "political disclaimer", then we submit a draft without a "political disclaimer". If somebody on the IESG thinks that this is a problem, then they will raise a "DISCUSS". If the WG and the IESG then can't agree, the IESG can request the RFC Editor to attach an "IESG Note" (see e.g. http://www.ietf.org/rfc/rfc2251.txt). Up to this point, everything I have seen from the members of this WG strongly indicate that we have (rough) consensus to NOT have a "political disclaimer". >Since you do not want to call a debate on "complement RFC 3066" rather of "replace RFC 3066", and do not want to consider the Charter issues in the WG, it seems you want them discussed in the brouhaha of the IESG Last Call. First, it's not sure the IESG Last Call will create a brouhaha. Many IESG Last Calls go by without much discussion. This one may, or it may not. Also, as Randy has said (repeatedly), the Charter is up for debate after we have done our work. IETF WGs don't start their work by a charter debate; if this was ever done in the past, it was abandoned because it would be very unproductive. >This may give more support to the proposed additions by more legal/political oriented people. I will not oppose this due to the very reduced number of participants to the WG Last Call. But beware that if the document is not mended during the last call, this will probably lead the document to be rejected at some stage (IESG Last Call, IANA, etc.). If it turns out, during IETF Last Call, that there is a preference for a "political disclaimer", and if the WG, the AD, and the IESG agree to some kind of wording, such a "political disclaimer" can be added at IESG Last Call. In my judgement, this would in no way mean we would need to have a second IETF Last Call, or that the IETF Last Call would have to fail, because the political language that would be added would most probably not change any of the technical provisions of the draft nor should it change any other aspects such as registry operation. >As it is, it focuses on an resticted approach, aiming an exclusive for the language industry, against competitive open sources multilingual network oriented propositions and evolutions. [with my chair hat off] It is quite clear that the current draft tries to address the needs of what you call the "language industry", because people from this industry came forward with actual needs, and worked hard on solutions. It is in my view completely wrong to claim that the draft is exclusive. Indeed, while in RFC 3066, the only way to add language tags was by one-by-one registration, and there were no private subtags, the current draft is way more flexible and extensible. A recent example was language tags for different school grade levels. With RFC3066, you would have had to register en-grade1, en-us-grade1, en-gb-grade1, and so on. Now, you could (after some discussion) just register grade1 through grade6 (on more), and it could be applied to all kinds of languages, wherever it made sense. >We only oppose the exclusive, the exclusion and the lack of scalability, flexibility, capacity for innovation and evolution. Except for purely superficial syntactical issues such as subtag length,..., I haven't seen any evidence from you (or from others) that the current draft lacks scalability, flexibility, extensibility, or capacity for innovation. It would be good if you could document some actual (not superficial) cases of how the draft does that. As I said above, there is serious evidence in the draft that it actually does the contrary: It greatly increases scalability, flexibility, capacity for innovation and evolution. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 21 21:46:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvmbw-0002NR-Vr; Thu, 21 Jul 2005 21:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvmbw-0002Mm-1P for ltru@megatron.ietf.org; Thu, 21 Jul 2005 21:46:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09765 for ; Thu, 21 Jul 2005 21:45:55 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvn60-0000jw-Fp for ltru@ietf.org; Thu, 21 Jul 2005 22:17:06 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6M1jPC07508; Fri, 22 Jul 2005 10:45:25 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id f8f8c95c_fa53_11d9_9da6_0030482532aa_15554; Fri, 22 Jul 2005 10:57:35 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO001099; 22 Jul 05 10:51:25 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 22 Jul 05 10:51:05 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG001094; 22 Jul 05 10:51:03 +0900 Message-Id: <6.0.0.20.2.20050722094052.07eb53c0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 22 Jul 2005 09:46:28 +0900 To: "Mark Davis" , "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Re: Reference lists; AND ABNF GRAMMARS In-Reply-To: <004701c58e06$667be230$dd7e3009@sanjose.ibm.com> References: <20050720160712.TFLH9082.mta1.adelphia.net@megatron.ietf.org> <004901c58e02$5b211260$030aa8c0@DEWELL> <004701c58e06$667be230$dd7e3009@sanjose.ibm.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: 7655788c23eb79e336f5f8ba8bce7906 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 [chair hat on] At 00:10 05/07/22, Mark Davis wrote: >ABNF is tricky, and it is not trivial to 'pretty it up' while maintaining >precisely the same meaning. At this stage, we should only be focusing on >substantive issues, not whether the ABNF is pretty or not. The last call isn't restricted to major issues. Both major and cosmetic issues can and should be brought up, and if appropriate, addressed during last call. So if there is a way to make the ABNF easier to understand (while making sure that it's still describing the same syntax), then we (of course with WG (rough) consensus only) should do it. This of course applies to other parts of the spec. In many WGs I have seen (maybe not in this one), WG Last Call is on purpose used to clean up loose editorial ends and work on cosmetics. Regards, Martin. p.s.: [chair hat off] I'll try to have a look at the new ABNF from Kent, but that may take a few days, sorry. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 22 00:43:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvpNp-0003Jx-3Z; Fri, 22 Jul 2005 00:43:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvpNo-0003Js-6P for ltru@megatron.ietf.org; Fri, 22 Jul 2005 00:43: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 AAA20402 for ; Fri, 22 Jul 2005 00:43:32 -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 <20050722044303.KTDZ14360.mta13.adelphia.net@DEWELL> for ; Fri, 22 Jul 2005 00:43:03 -0400 Message-ID: <007101c58e77$c5540f00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050722005849.TKQI29961.mta8.adelphia.net@megatron.ietf.org> Date: Thu, 21 Jul 2005 21:42: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] Re: Reference lists; AND ABNF GRAMMARS X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 still don't see the need to introduce a new nonterminal for the combination of primary lang plus extended lang(s). Kent's version probably is prettier, but I share the concern about introducing any new problems or inconsistencies with what has been discussed and agreed upon before. (The length of registered language subtags is an exception: a bug was fortunately caught.) There's a related maxim in programming: the week before beta is usually a bad time to change all the variable names to conform to coding guidelines. -- 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 Fri Jul 22 01:53:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvqT9-0000bs-Ax; Fri, 22 Jul 2005 01: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 1DvqT8-0000bm-9K for ltru@megatron.ietf.org; Fri, 22 Jul 2005 01:53:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23618 for ; Fri, 22 Jul 2005 01:53:05 -0400 (EDT) Received: from anubis.medic.chalmers.se ([129.16.30.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvqxF-0003mR-Od for ltru@ietf.org; Fri, 22 Jul 2005 02:24:19 -0400 X-Medic-Info: 5e8b.42e089c0.0 nU95mWOrzlWykJbo Received: from webmail.chalmers.se (elbe1.ita.chalmers.se [129.16.222.100]) by mail.chalmers.se (Postfix) with ESMTP id 40DD0DCB7; Fri, 22 Jul 2005 07:53:04 +0200 (CEST) Received: from 83.248.26.202 (SquirrelMail authenticated user kent); by webmail.chalmers.se with HTTP; Fri, 22 Jul 2005 07:53:04 +0200 (CEST) Message-ID: <60530.83.248.26.202.1122011584.squirrel@webmail.chalmers.se> In-Reply-To: <007101c58e77$c5540f00$030aa8c0@DEWELL> References: <20050722005849.TKQI29961.mta8.adelphia.net@megatron.ietf.org> <007101c58e77$c5540f00$030aa8c0@DEWELL> Date: Fri, 22 Jul 2005 07:53:04 +0200 (CEST) Subject: [Ltru] Re: ABNF grammars From: "Kent Karlsson" To: "Doug Ewell" User-Agent: SquirrelMail/1.4.3a-7.EL3 X-Mailer: SquirrelMail/1.4.3a-7.EL3 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 > I still don't see the need to introduce a new nonterminal for the > combination of primary lang plus extended lang(s). Well, I did not introduce it. The -matching draft (www.inter-locale.com/ID/draft-ietf-ltru-matching-03.html) says: extlang =3D 2*3ALPHA *2("-" 3ALPHA) ( "-" ( 3ALPHA / "*" ) ) (indeed, with the non-terminal name you do not like for this...) And Addison said that one only wanted to allow * at the end of a logical part. And it is reasonable to have a non-terminal for something that is regarded as a logical part. Kind regards /kent k (back on Monday...) _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 22 11:21:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvzLC-0006k5-Tu; Fri, 22 Jul 2005 11:21:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvzLA-0006jn-0w for ltru@megatron.ietf.org; Fri, 22 Jul 2005 11:21:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24895 for ; Fri, 22 Jul 2005 11:21:28 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvzpP-0001Wd-9U for ltru@ietf.org; Fri, 22 Jul 2005 11:52:48 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DvzL4-0006eI-3r; Fri, 22 Jul 2005 08:21:27 -0700 Message-Id: <6.2.1.2.2.20050722112811.05c9d780@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 22 Jul 2005 17:21:02 +0200 To: Martin Duerst , "Randy Presuhn" , From: r&d afrac Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN disclaimer In-Reply-To: <6.0.0.20.2.20050720180904.07e45b10@itmail.it.aoyama.ac.jp> References: <6.2.1.2.2.20050719231610.05809220@pop.online.fr> <6.0.0.20.2.20050720180904.07e45b10@itmail.it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 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 Martin, I will try to address this serious mail as seriously as possible. I am on vacations with many family things around. At 03:44 22/07/2005, Martin Duerst wrote: >[chair hat on] >Randy is right. "DISCUSS" refers to a very specific part of the process, >in particular to questions, comments or requests some members of the IESG >may have on the draft. This is recorded as a "DISCUSS" in the draft tracker >(see https://datatracker.ietf.org/public/pidtracker.cgi). We fully agree. The point I rise is a serious point. We are to accept external codes and _mix_ them (ISO 3166/UN M.49) in an area sensible to every government, except may be the USG. Some pointed out there is no Culture Ministry in the USG), and in several English language countries. Members of this WG should understand and accept that in some countries language is considered as _the_ culture, to the point citizens may consider anything concerning their language without their due approval as real a act of physical war, in cases calling possibly for personal physical retaliation and terror (all the more if they consider it as part of what is named "e-colonisation"). We have to take into account this full spectrum of understanding of what this WG [mainly composed of English mother tongue people] considers. I would underline that the matter of the debates of this WG are quite unconceivable in a French speaking environment. I think this kind of concern is not a concern for a WG. But it is the concern of a WG to inform IESG of the problem. What I say (considering the Internet standard process spirit/letter) is there are two solutions: - to propose a text in the hope IESG marks it for DISCUSS. - to report in the text that the identified problem goes beyond the Charter, and that we identified it should be treated somewhere else. In the first case we run into the risk that our text is accepted and serves further on as an IETF position. Out of luck, our proposition could be a good one. But it is likely, even if we do our best, it would not be a good one as this is a pretty complex one and we are neither lawyers nor international diplomats. The second one is IMHO the most loyal to the IESG. Because the IESG can decide to accept our point and mark it for DISCUSS, or disagree with us and remove it. Ideally, the solution would be my reading of the charter: to address all the issue through a global framework for the whole internet, truly correcting and replacing RFC 3066 and then presenting the ABNF and filters of this particular case in a technical RFC. >The WG is expected to send the draft(s) to the AD and the IESG ***in the best >possible fashion***, after having done everything they think is necessary. >If we asa WG come to (rough) consensus that some "political disclaimer" or >whatever we may call it is necessary, then we should make our best efforts >to get the best possible text. See above. This is a solution. This is the one I initially advocated for, trying to interest Gov officials, ISO people, Language structures, UNESCO, etc. etc. The answer I received from everywhere is "we are not interested in this commercial trick, IETF means nothing to us in that area, their proposition is absurd and will not fly. Thank you to keep us posted so we know where, how and when to kill it". I think it is not a proper answer. Because it is premature to kill the IETF, even if it stays the way it is (RFC 3774). The IETF is also a place to protect the technology from all these people: nothing will happen on the Internet except through IETF and Open Source and Open Source is not ready in terms of network architecture. So I tried to keep an equilibrium, for example with the WGIG, which partly follows some of my points. But there are two main points the WGIG - and this WG - are wrong about: 1. the WGIG places the Internet R&D in private sector, as the WG does in mainly relying on Unicode and W3C private commercial consortia. IAB RFC 3869 clearly says (its "main thesis") that if this is the case the architectural R&D of the internet is "in trouble". I can only confirm that: I try to keep (at my family expense, as do others on this list or near-by) myself near but financially free from Govs and as much as possible grassroots and non-profit as I can, for free technical thinking and development. This WG only produced a short minded, non scalable, excluding solution (I will document this briefly further on). 2. The WGIG (and this WG does not even do that), considers multilingualism as DNS and content (this WG excludes DNS what is a grave error, because it confuses IETF's IDN mistake with multilingual DNS. Vint Cerf just identified that mistake, put the blame on IETF, and calls for work on the matter. He starts from phishing which cannot unfortunately be addressed without changing the proposition, what will call for a change in the architecture of the Internet. So not a little thing. But the main issue for us as a WG is that language is not the same issue when a spoken language for mobiles (reason why mobiles develop far faster than the Internet) or when text content for linguists, library and language industry. Languages in the IETF must be understood as what IETF considers: protocols. These person to person interintelligibility protocols involve R&D issues this WG (financed by commercial interest) has not even alluded to. The result is that a Draft about languages identification does not identify itself what it considers as a language. I have no objection to the idea of standardising the commercial tag of languages, to the contrary. But you do not start from the price tag of the members of dominant consortium, as an R&D specs for the whole deliverable. >If some IESG members then think that this >has to be changed, they will raise a "DISCUSS". But going to the IESG >with a draft that says something like "IESG, for this section, please >do the work we were supposed to do" isn't an option. To do a work we are not supposed, we have not the competence and we have not the authority to do is not an option. It would be a error and if we make believe it would be a disloyalty. Unless you think you have the necessary authority to relate with the IESG liaisons with ISO, IANA, GAC, ccTLDs, UNESCO, UN, etc. and actually engage in it. In which case I would certainly support you I will take an example of the difficulty: as a ccTLD (supposed to pay the IANA, trustee of a national community, advisor of the Gov - in a country where the culture Minister is also the Minister for ICT) and as the secretary of an independent intergovernmental, interccTLD, inter-national Internet communities think tank, and as a Member of the ccTLD committee for the Luxembourg ccTLD meeting, I invited Brian Carpenter to come and introduce the way IETF would consider a liaison with ccTLDs. You may recall that my call to Greek and Chinese ccTLD Managers on ietf -languages@alvestrand.no shown the interest and the political need. Brian's answer was roughly (published in my presentation) "I considered with IAB. We have nothing to discuss with you. However if there are specific topics, please go through ADs" (two Govs I copied the mail asked "what is an AD", showing the relational/cultural divide. Then came the US Statement of principles and then the WGIG, and then Vint Cerf which followed in confirming the need and actually supporting my proposition to ccTLDs of an INTF. A TF to structure that relation speaking user on one side and IETF on the other. And of an UNITRY test bed (along ICANN criteria), I am working on, with the support of already a few developing/non developing countries. Our role is not to replace IESG, but our job is not either to fool the IESG. >If the WG comes to the (rough) consensus that it's better NOT to have a >"political disclaimer", then we submit a draft without a "political >disclaimer". >If somebody on the IESG thinks that this is a problem, then they will >raise a "DISCUSS". If the WG and the IESG then can't agree, the IESG >can request the RFC Editor to attach an "IESG Note" (see e.g. >http://www.ietf.org/rfc/rfc2251.txt). > >Up to this point, everything I have seen from the members of this WG >strongly indicate that we have (rough) consensus to NOT have a >"political disclaimer". This WG is not competent on the matter. For two reasons: - this is not its charter. - the consensus is by exhaustion. Anyway the problem is not the way you, me, IETF sees the things. The problem is the way the concerned external parties see them. Inquire by yourself. > >Since you do not want to call a debate on "complement RFC 3066" rather > of "replace RFC 3066", and do not want to consider the Charter issues in > the WG, it seems you want them discussed in the brouhaha of the IESG Last Call. > >First, it's not sure the IESG Last Call will create a brouhaha. >Many IESG Last Calls go by without much discussion. This one may, >or it may not. This depends essentially on the "complements/replaces" >Also, as Randy has said (repeatedly), the Charter is up for debate after >we have done our work. IETF WGs don't start their work by a charter >debate; if this was ever done in the past, it was abandoned because >it would be very unproductive. Here I am lost. I though Randy was using this "after we have done our work" as a delaying joke. Now you repeat it, I must consider you say seriously that an IETF WG (and this is your intent in this case) is to commonly understand the work to achieve in common once that work has been done? This is not exactly my own experience of IETF WG, but I am to say that the few I shared in have not been successes... This may the reason why? It rings Alice in Wonderlands to me. But if you say it is the way WG proceeds ... I would then be interested in getting a calendar and a procedure. When are you going to send a mail with a subject like "let understand the work we had to do"? > >This may give more support to the proposed additions by more > legal/political oriented people. I will not oppose this due to the very > reduced number of participants to the WG Last Call. But beware that if > the document is not mended during the last call, this will probably lead > the document to be rejected at some stage (IESG Last Call, IANA, etc.). > >If it turns out, during IETF Last Call, that there is a preference for >a "political disclaimer", and if the WG, the AD, and the IESG agree >to some kind of wording, such a "political disclaimer" can be added >at IESG Last Call. In my judgement, this would in no way mean we would >need to have a second IETF Last Call, or that the IETF Last Call would >have to fail, because the political language that would be added would >most probably not change any of the technical provisions of the draft >nor should it change any other aspects such as registry operation.* I feel you read me incompletely. I say that the document will fail at some stage. If the concerned parties want to pay attention to the IETF (and this is my prayer, so we can preserve the Internet standard process credibility in the Multilingual field) they will attend the IETF last call and the Draft will be killed there (what would be sad, since it could fly as a complement). Or it will more likely (I am not going to spend my life fighting an ill fitting Draft) be diplomatically killed at IANA level. The procedure has been already engaged. > >As it is, it focuses on an resticted approach, aiming an exclusive for > the language industry, against competitive open sources multilingual > network oriented propositions and evolutions. > >[with my chair hat off] >It is quite clear that the current draft tries to address the needs of what >you call the "language industry", because people from this industry came >forward with actual needs, and worked hard on solutions. Here is the confusion. Some people of the language industry came forwards with this proposition. No the industry. I represent another part (less dominant but more pervasive) of this industry. The way they are treated on ietf-languages@alvestrand.no or on this WG (as F. Charles was) did not pushed them to continue. I commentd already the question of Randy on this matter, my response and the support I got. There are others who worked hard, I would even say harder and have a much broader vision and support, you totally disregard. So we agreed (and I documented) that we will only proceed outside of this WG - leaving you enjoy your format and using the "x-" compatible escape sequence. We think it is better to compromise and show usage, running code, etc. demonstrate our open position is better, and to expose the bias of the proposed exclusion. We got our "no way" excluding response. This is why, I am probably the only one concerned still considering that the proposition of this WG may have merits, if not exclusive and excluding (at least to satisfy the part of the industry you refer to). I also think that coexistence is far better than opposition. If I am considered here as the bad guy against the Draft, and outside as the bad guy or the traitor defending the Draft ... >It is in my view completely wrong to claim that the draft is exclusive. >Indeed, while in RFC 3066, the only way to add language tags was by >one-by-one registration, and there were no private subtags, the current >draft is way more flexible and extensible. I am afraid you miss the point here. RFC 3066 is a wrong solution (sometimes named "yellow star" RFC). People were shocked by the timely (was it needed, or unfortunate?) registration of Chinese new tags by ietf-languages@alvestrand.no (according to the non approved Draft format) just before the Yahoo, Microsoft and Google announcement. This lead this RFC 3066 Bis to be qualified of a "linguistic Yalta". 1. I note that you say "there were no private subtags", while other says 1*8alphanum because compatibility with then must be maintained. 2. No one is really interested in the RFC 3066 format and registry, except the Unicode consortium people. No problem with that. The proposed system "flexibility and extensibility" (I am not convinced of, in your own perspective due to the unclear process and ISO relations) is perceived as a way to control far more the things than before. >A recent example was language tags for different school grade levels. >With RFC3066, you would have had to register en-grade1, en-us-grade1, >en-gb-grade1, and so on. Now, you could (after some discussion) just >register grade1 through grade6 (on more), and it could be applied to >all kinds of languages, wherever it made sense. Thank you for this example: did you ever consider that "gradeN" is meaningless for most outside of your world and that even then, 1 to 6 may be meaningless as there may be more grades and in different order? We do not want that kind of registry. We want to be ISO 11179 compatible when a registry is really to be considered. > >We only oppose the exclusive, the exclusion and the lack of scalability, > flexibility, capacity for innovation and evolution. > >Except for purely superficial syntactical issues such as subtag length,..., "superficial syntactical issues" .... I love it. You will be permitted to have every name you want if it is less than 9 characters long, is in ASCII and does not include anything else than 0-Z characters. Look how liberal I am? >I haven't seen any evidence from you (or from others) that the current >draft lacks scalability, flexibility, extensibility, or capacity for >innovation. I suppose you believe it! So I will give you some hint. "x-1*8alphanum" is supposed to support all the private subtags in a non conflicting way. Let consider that one gives every user a different number to permit them to differentiate their private subtags. With a billion Internet users, we cannot even give a full subtag to all: 9 numerics are needed. Let try to explain people that a cookie name can only be 8alphanum long. Try to authenticate a private subtag using an MD5 key, etc. A full format for a commercial propositions, 8 alphanums for Open Source, Networking, etc. >It would be good if you could document some actual (not superficial) >cases of how the draft does that. As I said above, there is serious >evidence in the draft that it actually does the contrary: It greatly >increases scalability, flexibility, capacity for innovation and >evolution. No. It greatly increases scalability, flexibility, capacity for language control and evolution reduction to the profit of a dominant part of the commercial language tools industry, because of its exclusive. If the Draft is a complement of RFC 3066 and permits undefined content of the "x-tags", permitting every other format to develop and be supported we will wind up in a totally acceptable coexistence situation where a "xlang:xxx" is an RFC 3066 retro compatible solution and " supports all the others. It will then be up to the grassroots process to adapt. IMHO (this is what I feel could be a possible stabilisation) "x-abc:xxxx" would be a good approach where "abc" is a freely used scheme we could relate to CRC format names. This means that x-3066:en-Latn-UK could be a legitimate format, also entered in places like "xlang:en-Latn-UK". Obviously, x-tags can support other features the Draft cannot such as multilingual entries (via double indexation: entries use a reference number documented by multilingual grids), ISO 11179 intended compatibility supporting locales, MLDN charsets, referent directories, context additions, CRCs, etc. ... and as documented Addison and Mark's Draft with their own default format and registry. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 22 12:29:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw0OV-0003Vn-1q; Fri, 22 Jul 2005 12:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw0OU-0003Vi-1k for ltru@megatron.ietf.org; Fri, 22 Jul 2005 12:29:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00265 for ; Fri, 22 Jul 2005 12:28:58 -0400 (EDT) Received: from mta10.adelphia.net ([68.168.78.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw0sk-0004Fy-1D for ltru@ietf.org; Fri, 22 Jul 2005 13:00:19 -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 <20050722162844.SRSE19267.mta10.adelphia.net@DEWELL>; Fri, 22 Jul 2005 12:28:44 -0400 Message-ID: <000c01c58eda$5022cd80$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050722005849.TKQI29961.mta8.adelphia.net@megatron.ietf.org> <007101c58e77$c5540f00$030aa8c0@DEWELL> <60530.83.248.26.202.1122011584.squirrel@webmail.chalmers.se> Subject: Re: [Ltru] Re: ABNF grammars Date: Fri, 22 Jul 2005 09:27:52 -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: 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 Kent Karlsson wrote: >> I still don't see the need to introduce a new nonterminal for the >> combination of primary lang plus extended lang(s). > > Well, I did not introduce it. The -matching draft > (www.inter-locale.com/ID/draft-ietf-ltru-matching-03.html) says: > > extlang = 2*3ALPHA *2("-" 3ALPHA) ( "-" ( 3ALPHA / "*" ) ) > > (indeed, with the non-terminal name you do not like for this...) I hadn't seen that, since I haven't spent much time with the matching draft, and specifically hadn't looked at its ABNF. All right, I don't like it there either. > And Addison said that one only wanted to allow * at the end > of a logical part. And it is reasonable to have a non-terminal > for something that is regarded as a logical part. I should put it this way: Does the ABNF in these drafts *need* to be fixed, in the sense that it is either (a) incorrect or (b) confusing to the point where it is likely to be interpreted incorrectly? If not, I'm not convinced of the need to revise it thoroughly. If the ABNF in the registry and matching drafts differ from each other in unnecessary ways -- not just to reflect the different needs of generative and constructive grammar -- then I think one should be brought in line with the other, by changing individual lines. But that is as far as I'd go. The ABNF in RFC 3066 was clearly incorrect: it allowed 1-letter subtags in any position without restriction, and 1-digit non-primary subtags, so that patently invalid tags such as "o" or "a-1-2-3" appeared acceptable. It was two lines long and did not have any of the detailed qualifications of the ABNF in the current drafts. (Consider, for example, how far the registry-draft ABNF goes to exclude "X" and "x" from singletons.) The ABNF in the current drafts goes much farther, has been shaped by many more hands, and covers many more cases than in RFC 1766 or 3066, and unless there is a genuine error (like 4-letter registered language subtags), I would prefer not to reform 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 Fri Jul 22 13:55:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw1k1-00066f-Fc; Fri, 22 Jul 2005 13:55:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw1jz-000658-GE for ltru@megatron.ietf.org; Fri, 22 Jul 2005 13:55:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06231 for ; Fri, 22 Jul 2005 13:55:17 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw2EE-0007Zn-1F for ltru@ietf.org; Fri, 22 Jul 2005 14:26:37 -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 j6MHsf6T009752; Fri, 22 Jul 2005 10:54:41 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Fri, 22 Jul 2005 10:55:46 -0700 Message-ID: From: "McDonald, Ira" To: "'Martin Duerst'" , Mark Davis , Doug Ewell , LTRU Working Group Subject: RE: [Ltru] Re: Reference lists; AND ABNF GRAMMARS Date: Fri, 22 Jul 2005 10:55: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: b4a0a5f5992e2a4954405484e7717d8c 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 strongly support replacing the ABNF with Kent's improved stuff. Martin is of course right to point out that a working group 'last call' can and should address major issues. That does not force a second working group 'last call', if the issues are resolved by the usual 'rough concensus'. This differs from an IETF 'last call' (which can't change the substance without going back to the working group). 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 Martin Duerst > Sent: Thursday, July 21, 2005 8:46 PM > To: Mark Davis; Doug Ewell; LTRU Working Group > Subject: Re: [Ltru] Re: Reference lists; AND ABNF GRAMMARS > > > [chair hat on] > > At 00:10 05/07/22, Mark Davis wrote: > >ABNF is tricky, and it is not trivial to 'pretty it up' > while maintaining > >precisely the same meaning. At this stage, we should only > be focusing on > >substantive issues, not whether the ABNF is pretty or not. > > The last call isn't restricted to major issues. Both major > and cosmetic > issues can and should be brought up, and if appropriate, > addressed during > last call. So if there is a way to make the ABNF easier to understand > (while making sure that it's still describing the same > syntax), then we > (of course with WG (rough) consensus only) should do it. > > This of course applies to other parts of the spec. In many WGs I have > seen (maybe not in this one), WG Last Call is on purpose used to clean > up loose editorial ends and work on cosmetics. > > > Regards, Martin. > > p.s.: [chair hat off] I'll try to have a look at the new ABNF > from Kent, > but that may take a few days, sorry. > > > _______________________________________________ > 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 Jul 22 15:40:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw3O8-0006v2-Sa; Fri, 22 Jul 2005 15:40:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw3O7-0006ux-1z for ltru@megatron.ietf.org; Fri, 22 Jul 2005 15:40: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 PAA14726 for ; Fri, 22 Jul 2005 15:40:48 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dw3Nw-00030b-V3 for ltru@lists.ietf.org; Fri, 22 Jul 2005 21:40:40 +0200 Received: from c-134-89-125.hh.dial.de.ignite.net ([62.134.89.125]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jul 2005 21:40:40 +0200 Received: from nobody by c-134-89-125.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 22 Jul 2005 21:40:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 22 Jul 2005 21:37:35 +0200 Organization: Lines: 35 Message-ID: <42E14AFF.3B2B@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C316716@irvmbxw01.quest.com> <60425.83.248.26.202.1121985985.squirrel@webmail.chalmers.se> <42E03F28.407B@xyzzy.claranet.de> <6.2.1.2.2.20050722025451.036350f0@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-125.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Reference lists; AND ABNF GRAMMARS X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 r&d afrac wrote: > is it correct or not? We (TINW) wouldn't want the name 'genvariant': variant = regvariant / genvariant regvariant = 5*8alphanum ; registered variant genvariant = (DIGIT 3alphanum) ; generic variant The original variant is better: variant = 5*8alphanum ; registered variants / ( DIGIT 3alphanum ) Splitting region in / is possible, but the original region is good enough: region = 2ALPHA ; ISO 3166 code / 3DIGIT ; UN country number The idea in Kent's proposal is apparently better than the original ABNF, because it clearly says that is only combined with , never with . In fact it could go further there: Debbie's alpha-4 is also never combined with . Maybe Kent could split extracting Debbie's (reserved for future use by 3066ter or later). Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 22 16:33:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4DC-0007U1-8h; Fri, 22 Jul 2005 16: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 1Dw4D8-0007LT-0v for ltru@megatron.ietf.org; Fri, 22 Jul 2005 16:33:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24585 for ; Fri, 22 Jul 2005 16:33: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.43) id 1Dw4hP-0007Fk-CE for ltru@ietf.org; Fri, 22 Jul 2005 17:04:52 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 13:21: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: Reference lists; AND ABNF GRAMMARS Date: Fri, 22 Jul 2005 13:21:43 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C316D6F@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Reference lists; AND ABNF GRAMMARS Thread-Index: AcWO9XnpD6k220aeRmmxLeJP8XlorwABM67A From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 22 Jul 2005 20:21:43.0917 (UTC) FILETIME=[FA1E11D0:01C58EFA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 don't know that extlang never combines with "reglang" or with alpha-4 = codes. Draft-registry doesn't actually say that. Draft-matching's ABNF says it, but that is probably wrong. What we do know is that, really, extlangs will be ISO 639-3 codes (can't = be alpha2 or alpha4) whose prefix will be set by ISO 639-3 and thus will = be either alpha2 or alpha3. Hence the matching ABNF being the way it is. = The question is whether we should have a lot more ABNF rules in the = draft-registry ABNF to exactly express a relationship embedded in the = Prefix registry field and not actually specified now. The tide appears to be in favor of modifying the ABNF, so I'll give it a = look this afternoon. 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: Friday, July 22, 2005 12:38 PM > To: ltru@ietf.org > Subject: [Ltru] Re: Reference lists; AND ABNF GRAMMARS >=20 > r&d afrac wrote: >=20 > > is it correct or not? >=20 > We (TINW) wouldn't want the name 'genvariant': >=20 > variant =3D regvariant > / genvariant >=20 > regvariant =3D 5*8alphanum ; registered variant >=20 > genvariant =3D (DIGIT 3alphanum) ; generic variant >=20 > The original variant is better: >=20 > variant =3D 5*8alphanum ; registered variants > / ( DIGIT 3alphanum ) >=20 > Splitting region in / is possible, but > the original region is good enough: >=20 > region =3D 2ALPHA ; ISO 3166 code > / 3DIGIT ; UN country number >=20 > The idea in Kent's proposal is apparently better > than the original ABNF, because it clearly says that > is only combined with , never with . >=20 > In fact it could go further there: Debbie's alpha-4 > is also never combined with . Maybe Kent could split > extracting Debbie's (reserved for future > use by 3066ter or later). > 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 Fri Jul 22 17:16:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4sQ-0006nh-0y; Fri, 22 Jul 2005 17:16:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw4sO-0006l1-Jm for ltru@megatron.ietf.org; Fri, 22 Jul 2005 17:16:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27927 for ; Fri, 22 Jul 2005 17:16:09 -0400 (EDT) Received: from rly-ip04.mx.aol.com ([64.12.138.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw5Mc-0000SJ-NO for ltru@ietf.org; Fri, 22 Jul 2005 17:47:32 -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 RELAYIN1-242e1620263; Fri, 22 Jul 2005 17:15:46 -0400 Received: from DEBHOME (ACCA60D2.ipt.aol.com [172.202.96.210]) by smtp-los03.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j6MLFc7K022603; Fri, 22 Jul 2005 17:15:38 -0400 Message-Id: <200507222115.j6MLFc7K022603@smtp-los03.proxy.aol.com> From: "Debbie Garside" To: "'Addison Phillips'" , "'Frank Ellermann'" , Subject: RE: [Ltru] Re: Reference lists; AND ABNF GRAMMARS Date: Fri, 22 Jul 2005 22:15: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 In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C316D6F@irvmbxw01.quest.com> thread-index: AcWO9XnpD6k220aeRmmxLeJP8XlorwABM67AAAHkuVA= X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.41 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 > What we do know is that, really, extlangs will be ISO 639-3 codes (can't > be alpha2 or alpha4) whose prefix will be set by ISO 639-3 and thus will > be either alpha2 or alpha3. Hence the matching ABNF being the way it is. Hmmm... can you explain this please? I can perhaps understand that extlangs cannot be alpha2 but am having difficulty with the alpha4 reference. Although, that said, obviously alpha4's do not need extensions as they are stand alone whereas any extension coding of alpha3 MAY duplicate an alpha3 primary subtag (a dangerous situation IMHO). Thanks Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > Sent: 22 July 2005 21:22 > To: Frank Ellermann; ltru@ietf.org > Subject: RE: [Ltru] Re: Reference lists; AND ABNF GRAMMARS > > We don't know that extlang never combines with "reglang" or with alpha-4 > codes. Draft-registry doesn't actually say that. > > Draft-matching's ABNF says it, but that is probably wrong. > > What we do know is that, really, extlangs will be ISO 639-3 codes (can't > be alpha2 or alpha4) whose prefix will be set by ISO 639-3 and thus will > be either alpha2 or alpha3. Hence the matching ABNF being the way it is. > > The question is whether we should have a lot more ABNF rules in the draft- > registry ABNF to exactly express a relationship embedded in the Prefix > registry field and not actually specified now. > > The tide appears to be in favor of modifying the ABNF, so I'll give it a > look this afternoon. > > 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 Frank Ellermann > > Sent: Friday, July 22, 2005 12:38 PM > > To: ltru@ietf.org > > Subject: [Ltru] Re: Reference lists; AND ABNF GRAMMARS > > > > r&d afrac wrote: > > > > > is it correct or not? > > > > We (TINW) wouldn't want the name 'genvariant': > > > > variant = regvariant > > / genvariant > > > > regvariant = 5*8alphanum ; registered variant > > > > genvariant = (DIGIT 3alphanum) ; generic variant > > > > The original variant is better: > > > > variant = 5*8alphanum ; registered variants > > / ( DIGIT 3alphanum ) > > > > Splitting region in / is possible, but > > the original region is good enough: > > > > region = 2ALPHA ; ISO 3166 code > > / 3DIGIT ; UN country number > > > > The idea in Kent's proposal is apparently better > > than the original ABNF, because it clearly says that > > is only combined with , never with . > > > > In fact it could go further there: Debbie's alpha-4 > > is also never combined with . Maybe Kent could split > > extracting Debbie's (reserved for future > > use by 3066ter or later). > > 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 From ltru-bounces@lists.ietf.org Fri Jul 22 17:41:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw5Ge-0000nw-SM; Fri, 22 Jul 2005 17:41:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw5Gd-0000nU-FH for ltru@megatron.ietf.org; Fri, 22 Jul 2005 17:41:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00320 for ; Fri, 22 Jul 2005 17:41:12 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw5kv-0001Vh-Jj for ltru@ietf.org; Fri, 22 Jul 2005 18:12: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 j6MLewZP003411; Fri, 22 Jul 2005 17:40:58 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 22 Jul 2005 17:40:58 -0400 Date: Fri, 22 Jul 2005 17:40:58 -0400 From: "John.Cowan" To: Debbie Garside Subject: Re: [Ltru] Re: Reference lists; AND ABNF GRAMMARS Message-ID: <20050722214057.GC2784@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0C316D6F@irvmbxw01.quest.com> <200507222115.j6MLFc7K022603@smtp-los03.proxy.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <200507222115.j6MLFc7K022603@smtp-los03.proxy.aol.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Debbie Garside scripsit: > > What we do know is that, really, extlangs will be ISO 639-3 codes (can't > > be alpha2 or alpha4) whose prefix will be set by ISO 639-3 and thus will > > be either alpha2 or alpha3. Hence the matching ABNF being the way it is. >=20 > Hmmm... can you explain this please? I can perhaps understand that extla= ngs > cannot be alpha2 but am having difficulty with the alpha4 reference. An extlang subtag is always alpha3, by the syntax rules of RFC 3066bis. If and when alpha4s are allowed, they will be allowed as language subtags, never as extension subtags. > Although, that said, obviously alpha4's do not need extensions as they are > stand alone whereas any extension coding of alpha3 MAY duplicate an alpha3 > primary subtag (a dangerous situation IMHO). Actually, it can't. An alpha3 code can belong to one of these groups: 1) Appears in 639-2 and 639-3 and has a counterpart in 639-1. Forbidden; use the 639-1 code instead. 2) Appears in 639-2 and 639-3 but has no 639-1 counterpart. Allowed as a language subtag but not an extlang subtag. 3) Appears in 639-3 as a individual language that is not part of a macrolanguage. Not currently allowed; will be allowed in 3=7FRFC 3066ter as a language subtag but not an extlang subtag. 4) Appears in 639-3 as a macrolanguage. Not currently allowed; will be allowed in 3=7FRFC 3066ter as a language subtag but not an extlang subtag. 5) Appears in 639-3 as an individual language that is part of a macrolanguage. Not currently allowed; will be allowed in RFC 3066ter as an extlang subtag but not a language subtag. --=20 MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGG= UMS John Cowan http://www.reutershealth.com jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 22 17:49:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw5OA-0002qj-Jl; Fri, 22 Jul 2005 17:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw5O8-0002pL-GP for ltru@megatron.ietf.org; Fri, 22 Jul 2005 17:49:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00767 for ; Fri, 22 Jul 2005 17:48:57 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw5sS-0001lR-0E for ltru@ietf.org; Fri, 22 Jul 2005 18:20:20 -0400 Received: from smtp-los01.proxy.aol.com (smtp-los01.proxy.aol.com [195.93.24.40]) by rly-ip05.mx.aol.com (v98.19) with ESMTP id RELAYIN2-342e169a534d; Fri, 22 Jul 2005 17:48:22 -0500 Received: from DEBHOME (ACCA60D2.ipt.aol.com [172.202.96.210]) by smtp-los01.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j6MLmI0W001505; Fri, 22 Jul 2005 17:48:18 -0400 Message-Id: <200507222148.j6MLmI0W001505@smtp-los01.proxy.aol.com> From: "Debbie Garside" To: "'John.Cowan'" Subject: RE: [Ltru] Re: Reference lists; AND ABNF GRAMMARS Date: Fri, 22 Jul 2005 22:48:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050722214057.GC2784@NYCMJCOWA2> thread-index: AcWPBgssxPMwmIrSSGmQfGMLXGnPpQAAOFFA X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.40 X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Hi John Thanks for the clarification :-) Kind regards Debbie > -----Original Message----- > From: John.Cowan [mailto:jcowan@reutershealth.com] > Sent: 22 July 2005 22:41 > To: Debbie Garside > Cc: 'Addison Phillips'; 'Frank Ellermann'; ltru@ietf.org > Subject: Re: [Ltru] Re: Reference lists; AND ABNF GRAMMARS >=20 > Debbie Garside scripsit: >=20 > > > What we do know is that, really, extlangs will be ISO 639-3 codes > (can't > > > be alpha2 or alpha4) whose prefix will be set by ISO 639-3 and = thus > will > > > be either alpha2 or alpha3. Hence the matching ABNF being the way = it > is. > > > > Hmmm... can you explain this please? I can perhaps understand that > extlangs > > cannot be alpha2 but am having difficulty with the alpha4 reference. >=20 > An extlang subtag is always alpha3, by the syntax rules of RFC = 3066bis. > If and when alpha4s are allowed, they will be allowed as language = subtags, > never as extension subtags. >=20 > > Although, that said, obviously alpha4's do not need extensions as = they > are > > stand alone whereas any extension coding of alpha3 MAY duplicate an > alpha3 > > primary subtag (a dangerous situation IMHO). >=20 > Actually, it can't. An alpha3 code can belong to one of these groups: >=20 > 1) Appears in 639-2 and 639-3 and has a counterpart in 639-1. = Forbidden; > use the 639-1 code instead. >=20 > 2) Appears in 639-2 and 639-3 but has no 639-1 counterpart. Allowed = as > a language subtag but not an extlang subtag. >=20 > 3) Appears in 639-3 as a individual language that is not part of a > macrolanguage. Not currently allowed; will be allowed in 3=7FRFC = 3066ter > as a language subtag but not an extlang subtag. >=20 > 4) Appears in 639-3 as a macrolanguage. Not currently allowed; will = be > allowed in 3=7FRFC 3066ter as a language subtag but not an extlang = subtag. >=20 > 5) Appears in 639-3 as an individual language that is part of a > macrolanguage. Not currently allowed; will be allowed in RFC 3066ter > as an extlang subtag but not a language subtag. >=20 > -- > MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE > WUGGUMS > John Cowan http://www.reutershealth.com jcowan@reutershealth.com _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 24 03:20:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwan9-0003NI-NR; Sun, 24 Jul 2005 03:20:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwan7-0003ND-Gh for ltru@megatron.ietf.org; Sun, 24 Jul 2005 03:20:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09664 for ; Sun, 24 Jul 2005 03:20:51 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwbHh-0005pQ-Vf for ltru@ietf.org; Sun, 24 Jul 2005 03:52:31 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dwan0-0002mP-2m for ltru@ietf.org; Sun, 24 Jul 2005 00:20:46 -0700 Message-Id: <6.2.1.2.2.20050724091844.03c196f0@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 24 Jul 2005 09:20:23 +0200 To: ltru@ietf.org From: r&d afrac Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [Ltru] current 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison, can you point-out the URL of the current status of the draft after last call corrections? thank you. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 24 09:08:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwgDR-0000S9-HN; Sun, 24 Jul 2005 09:08:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwgDQ-0000S0-3f for ltru@megatron.ietf.org; Sun, 24 Jul 2005 09:08:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25923 for ; Sun, 24 Jul 2005 09:08:22 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwgi3-00023h-Hl for ltru@ietf.org; Sun, 24 Jul 2005 09:40:04 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DwgDJ-0001ro-Bj for ltru@ietf.org; Sun, 24 Jul 2005 06:08:17 -0700 Message-Id: <6.2.1.2.2.20050724132444.0426ada0@pop.online.fr> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 24 Jul 2005 15:07:49 +0200 To: ltru@ietf.org From: r&d afrac Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 2.8 (++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Ltru] English-only speakers may lack global perspective? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 http://uninews.unimelb.edu.au/unarticleid_2563.html seemingly a WG-ltru syndrome. "speaking" must be related to the level of complexity discussed in common. Added complexity for IETF is the difference of broadcast, channelised and open language spaces of exchanges (never discussed in spite of my attempts). Hence the http://nicso.org/equilang.pdf proposition. A voluntary to translate the introduction (in French) would be welcome. IMHO, considerations to these two points while reviewing the Draft would remove most of the contention points. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sun Jul 24 13:43:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwkVa-00013V-27; Sun, 24 Jul 2005 13:43:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwkVZ-00013Q-FF for ltru@megatron.ietf.org; Sun, 24 Jul 2005 13:43:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10703 for ; Sun, 24 Jul 2005 13:43: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.43) id 1Dwl0F-0000Zd-CZ for ltru@ietf.org; Sun, 24 Jul 2005 14:15:08 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.prod.quest.corp with Microsoft SMTPSVC(6.0.3790.211); Sun, 24 Jul 2005 10:43:08 -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] current draft Date: Sun, 24 Jul 2005 10:43:07 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C316EE0@irvmbxw01.quest.com> Thread-Topic: [Ltru] current draft Thread-Index: AcWQIGtzwM+GNAMLSGqhKZGKF7LZygAVp3xg From: "Addison Phillips" To: "r&d afrac" , X-OriginalArrivalTime: 24 Jul 2005 17:43:08.0499 (UTC) FILETIME=[27500230:01C59077] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 The current editor's copy is always on http://www.inter-locale.com I have not made ABNF changes or most other updates yet. 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 r&d afrac > Sent: Sunday, July 24, 2005 12:20 AM > To: ltru@ietf.org > Subject: [Ltru] current draft >=20 > Addison, > can you point-out the URL of the current status of the draft after = last > call corrections? > thank you. > 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 Sun Jul 24 16:51:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnRA-0005Ot-6d; Sun, 24 Jul 2005 16:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwnR8-0005Ol-7U for ltru@megatron.ietf.org; Sun, 24 Jul 2005 16:51:02 -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 QAA24396 for ; Sun, 24 Jul 2005 16:50: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 <20050724205029.LJIR24042.mta11.adelphia.net@DEWELL> for ; Sun, 24 Jul 2005 16:50:29 -0400 Message-ID: <003f01c59091$49b6c6a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Sun, 24 Jul 2005 13:50: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 Cc: Subject: [Ltru] Action items on draft-initial? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 don't see any open tickets for draft-initial, but I'm pretty sure there was an emerging hum to change the references so that the wording matched the official listings in the online ISO catalog: [ISO15924] ISO 15924:2004, "Information and documentation -- Codes for the representation of names of scripts," Ed. 1. [ISO3166-1] ISO 3166-1:1997, "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes," Ed. 1. [ISO639-1] ISO 639-1:2002, "Codes for the representation of names of languages -- Part 1: Alpha-2 code," Ed. 1. [ISO639-2] ISO 639-2:1998, "Codes for the representation of names of languages -- Part 2: Alpha-3 code," Ed. 1. Is this correct? Are these current revisions the ones we want to cite? It would seem logical that we would always want to cite the latest version of any external standard, but for the initial registry we refer to "Code elements that were valid on that date [1995] in the selected standard." Obviously none of these particular updates existed in 1995; is this a problem? What about the UN M.49 standard? Is the citation we have adequate? Does UNSD provide a better one that we should use instead? What about the normative/informative issue? I don't remember any agreement as to whether the source standards whose code elements were used in the initial registry should be normative, and as I said, I would rather leave that judgment to others. I'd like to know what the group wants to see here, so I can capture it in an editor's copy. -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ -- 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 Jul 24 17:35:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwo8N-0004uR-84; Sun, 24 Jul 2005 17: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 1Dwo8L-0004uM-Jb for ltru@megatron.ietf.org; Sun, 24 Jul 2005 17:35:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26688 for ; Sun, 24 Jul 2005 17:35:38 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwod3-0006zs-No for ltru@ietf.org; Sun, 24 Jul 2005 18:07:26 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dwo8D-0006WC-Sr; Sun, 24 Jul 2005 14:35:35 -0700 Message-Id: <6.2.1.2.2.20050724230241.04da7a40@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 24 Jul 2005 23:05:45 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Action items on draft-initial? In-Reply-To: <003f01c59091$49b6c6a0$030aa8c0@DEWELL> References: <003f01c59091$49b6c6a0$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 - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 22:50 24/07/2005, Doug Ewell wrote: >I don't see any open tickets for draft-initial, but I'm pretty sure >there was an emerging hum to change the references so that the wording >matched the official listings in the online ISO catalog: Yes. >What about the normative/informative issue? I don't remember any >agreement as to whether the source standards whose code elements were >used in the initial registry should be normative, and as I said, I would >rather leave that judgment to others. I thought this was agreed as normative? I know the imposed constraints, but I cannot see anything else acceptable but normative due to the required global stability. How can we deal with the transparent support of updates required in the Charter if not normative? The Internet community MUST trust its langtags as totally conforming with ISO codes. The Draft's imposed constraints irt. a previous request to ISO MA before a request to the Registry would not make sense otherwise? Also, our (and other we see emerging) Open Source approaches and coded tables libraries will consider ISO codes as normative (but not exclusive). If the Draft is not will we not risk conflicts? jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Mon Jul 25 22:47:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFTR-0002Hy-My; Mon, 25 Jul 2005 22:47:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFTP-0002Hn-VP for ltru@megatron.ietf.org; Mon, 25 Jul 2005 22:47:15 -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 WAA16015 for ; Mon, 25 Jul 2005 22:47:13 -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 <20050726024643.CJDY29002.mta9.adelphia.net@DEWELL> for ; Mon, 25 Jul 2005 22:46:43 -0400 Message-ID: <001d01c5918c$3b737b00$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Mon, 25 Jul 2005 19:46:31 -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] Galician X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 ISO 639-2/RA has announced a change on its Change Notice page: http://www.loc.gov/standards/iso639-2/codechanges.html The English name of the language represented by code elements "gl" and "glg" has been changed from "Gallegan" to "Galician." The Note on the Change Notice page reads, "Incorrect form of English name (Gallegan) corrected." All six online versions of the ISO 639-2 code list have been corrected uniformly. Since we have not yet reached Date B, I propose that the Description field for primary language subtag "gl" in the initial registry be changed from "Gallegan" to "Galician" to match this change. This will probably require a ticket. -- 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 Jul 26 02:41:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxJ8M-0005na-DW; Tue, 26 Jul 2005 02: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 1DxJ8K-0005nS-SN for ltru@megatron.ietf.org; Tue, 26 Jul 2005 02:41:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21054 for ; Tue, 26 Jul 2005 02:41:39 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxJdF-0007r5-Aq for ltru@ietf.org; Tue, 26 Jul 2005 03:13:43 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6Q6f9I21642; Tue, 26 Jul 2005 15:41:09 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id c1cbc818_fd9f_11d9_91b5_0030482532aa_28484; Tue, 26 Jul 2005 15:37:37 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO001BE5; 26 Jul 05 15:47:21 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 26 Jul 05 15:46:59 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG001BE4; 26 Jul 05 15:46:56 +0900 Message-Id: <6.0.0.20.2.20050726153955.0872fec0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 26 Jul 2005 15:40:30 +0900 To: "Doug Ewell" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] Galician In-Reply-To: <001d01c5918c$3b737b00$030aa8c0@DEWELL> References: <001d01c5918c$3b737b00$030aa8c0@DEWELL> 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: 93238566e09e6e262849b4f805833007 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 At 11:46 05/07/26, Doug Ewell wrote: >ISO 639-2/RA has announced a change on its Change Notice page: > >http://www.loc.gov/standards/iso639-2/codechanges.html > >The English name of the language represented by code elements "gl" and >"glg" has been changed from "Gallegan" to "Galician." The Note on the >Change Notice page reads, "Incorrect form of English name (Gallegan) >corrected." All six online versions of the ISO 639-2 code list have >been corrected uniformly. > >Since we have not yet reached Date B, I propose that the Description >field for primary language subtag "gl" in the initial registry be >changed from "Gallegan" to "Galician" to match this change. This will >probably require a ticket. [chair hat on] Please go ahead and create a ticket. [chair hat off] I support this change, but I'm okay if we don't change. Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 26 02:42:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxJ9I-0005uN-2C; Tue, 26 Jul 2005 02:42:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxJ9G-0005uD-MZ for ltru@megatron.ietf.org; Tue, 26 Jul 2005 02:42:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21088 for ; Tue, 26 Jul 2005 02:42:41 -0400 (EDT) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxJeG-0007sJ-6e for ltru@ietf.org; Tue, 26 Jul 2005 03:14:45 -0400 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jul 2005 23:42:31 -0700 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jul 2005 23:42:30 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ltru] Galician Date: Mon, 25 Jul 2005 23:42:03 -0700 Message-ID: Thread-Topic: [Ltru] Galician Thread-Index: AcWRjFyvQa1UzMwGTtWLuSKvs/DoLAAIJw2w From: "Peter Constable" To: "LTRU Working Group" X-OriginalArrivalTime: 26 Jul 2005 06:42:31.0112 (UTC) FILETIME=[326A3C80:01C591AD] 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 Doug Ewell > Since we have not yet reached Date B, I propose that the Description > field for primary language subtag "gl" in the initial registry be > changed from "Gallegan" to "Galician" to match this change. This will > probably require a ticket. Just do it. (my $0.02) Peter Constable _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 26 12:50:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSdU-0002iL-Eh; Tue, 26 Jul 2005 12:50:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQAx-00082O-TX for ltru@megatron.ietf.org; Tue, 26 Jul 2005 10:12:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21118 for ; Tue, 26 Jul 2005 10:12:46 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DxQft-0005bv-Oa for ltru@ietf.org; Tue, 26 Jul 2005 10:44:55 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Tue, 26 Jul 2005 07:06:19 -0700 Message-ID: <002a01c591ec$14d463a0$666e3009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" , "Martin Duerst" References: <001d01c5918c$3b737b00$030aa8c0@DEWELL> <6.0.0.20.2.20050726153955.0872fec0@itmail.it.aoyama.ac.jp> Subject: Re: [Ltru] Galician Date: Tue, 26 Jul 2005 07:12:39 -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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA21118 X-Mailman-Approved-At: Tue, 26 Jul 2005 12:50:32 -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 support this change, but I'm okay if we don't change. Ditto =E2=80=8EMark ----- Original Message -----=20 From: "Martin Duerst" To: "Doug Ewell" ; "LTRU Working Group" Sent: Monday, July 25, 2005 23:40 Subject: Re: [Ltru] Galician > At 11:46 05/07/26, Doug Ewell wrote: > >ISO 639-2/RA has announced a change on its Change Notice page: > > > >http://www.loc.gov/standards/iso639-2/codechanges.html > > > >The English name of the language represented by code elements "gl" an= d > >"glg" has been changed from "Gallegan" to "Galician." The Note on th= e > >Change Notice page reads, "Incorrect form of English name (Gallegan) > >corrected." All six online versions of the ISO 639-2 code list have > >been corrected uniformly. > > > >Since we have not yet reached Date B, I propose that the Description > >field for primary language subtag "gl" in the initial registry be > >changed from "Gallegan" to "Galician" to match this change. This wil= l > >probably require a ticket. > > [chair hat on] > Please go ahead and create a ticket. > > [chair hat off] > I support this change, but I'm okay if we don't change. > > Regards, Martin. > > > _______________________________________________ > 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 Jul 26 13:05:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSrg-0007MZ-JZ; Tue, 26 Jul 2005 13:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxSre-0007K8-7e for ltru@megatron.ietf.org; Tue, 26 Jul 2005 13:05:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06281 for ; Tue, 26 Jul 2005 13:05:07 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-lon.bigfish.com ([213.206.137.197] helo=mail8-lon-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxTMj-0003K8-Cr for ltru@ietf.org; Tue, 26 Jul 2005 13:37:18 -0400 Received: from mail8-lon.bigfish.com (localhost.localdomain [127.0.0.1]) by mail8-lon-R.bigfish.com (Postfix) with ESMTP id D33F84B8950; Tue, 26 Jul 2005 17:04:53 +0000 (UTC) X-BigFish: VP Received: by mail8-lon (MessageSwitch) id 1122397477465109_6971; Tue, 26 Jul 2005 17:04:37 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail8-lon.bigfish.com (Postfix) with ESMTP id 11FAE4B89A6; Tue, 26 Jul 2005 17:04:37 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005072610122918:67777 ; Tue, 26 Jul 2005 10:12:29 -0700 To: "Mark Davis" Subject: Re: [Ltru] Galician MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Tue, 26 Jul 2005 10:01:27 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/26/2005 10:01:37, Serialize complete at 07/26/2005 10:01:37, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/26/2005 10:12:29 AM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/26/2005 10:12:30 AM, Serialize complete at 07/26/2005 10:12:30 AM X-Spam-Score: 1.4 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Doug Ewell , 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: , Content-Type: multipart/mixed; boundary="===============1410904372==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1410904372== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="Windows-1256" Content-Transfer-Encoding: base64 VGhpcyB3YXMgYW4gaXNzdWUgaW4gbXkgYW5hbHlzaXMgb2YgbGFuZ3VhZ2VzIHVzZWQgaW4gbXkg aW5kdXN0cnkuIFRoZSANCnJpZ2h0IHRoaW5nIGZvciB5b3UgdG8gZG8gbm93IGlzIGxpa2VseSB0 byBtYWtlIHRoaXMgY2hhbmdlIHRvIGJlIA0KY29uc2lzdGVudCB3aXRoIElTTywgYnV0IHRoaXMg aXMgd2hlcmUgYnVpbGRpbmcgb3V0IHRoZSANCnN5bm9ueW0vZGVzY3JpcHRpb24gc3RydWN0dXJl IGluIHRoZSByZWdpc3RyeSB3b3VsZCBiZSB1c2VmdWwuIEluIG15IA0Kc291cmNlIGRhdGEgZm9y IHRoZSBsYW5ndWFnZSBhbmFseXNpcyBJIGRpZCwgSSBoYWQgdGhyZWUgdW5pcXVlIGxpbmUgDQpp dGVtczogR2FsaWNpYW4sIEdhbGxlZ2FuLCBhbmQgR2FsZWdvLg0KDQpBZGRpbmcgdGhlc2UgYWRk aXRpb25hbCAiZGVzY3JpcHRpb25zIiB3b3VsZCByZWFsbHkgYmUgdXNlZnVsIHRvIG90aGVycyAN CnRyeWluZyB0byByZWNvbmNpbGUgZmVzdGVyaW5nIGxhbmd1YWdlIGRhdGEuDQoNCkthcmVuIEJy b29tZQ0KDQoNCg0KDQoNCiJNYXJrIERhdmlzIiA8bWFyay5kYXZpc0BpY3UtcHJvamVjdC5vcmc+ DQpTZW50IGJ5OiBsdHJ1LWJvdW5jZXNAbGlzdHMuaWV0Zi5vcmcNCjA3LzI2LzIwMDUgMDc6MTIg QU0NCg0KIA0KICAgICAgICBUbzogICAgICJEb3VnIEV3ZWxsIiA8ZGV3ZWxsQGFkZWxwaGlhLm5l dD4sICJMVFJVIFdvcmtpbmcgR3JvdXAiIDxsdHJ1QGlldGYub3JnPiwgDQoiTWFydGluIER1ZXJz dCIgPGR1ZXJzdEBpdC5hb3lhbWEuYWMuanA+DQogICAgICAgIGNjOiANCiAgICAgICAgU3ViamVj dDogICAgICAgIFJlOiBbTHRydV0gR2FsaWNpYW4NCg0KDQo+IEkgc3VwcG9ydCB0aGlzIGNoYW5n ZSwgYnV0IEknbSBva2F5IGlmIHdlIGRvbid0IGNoYW5nZS4NCkRpdHRvDQoNCv1NYXJrDQoNCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiTWFydGluIER1ZXJzdCIgPGR1ZXJz dEBpdC5hb3lhbWEuYWMuanA+DQpUbzogIkRvdWcgRXdlbGwiIDxkZXdlbGxAYWRlbHBoaWEubmV0 PjsgIkxUUlUgV29ya2luZyBHcm91cCIgDQo8bHRydUBpZXRmLm9yZz4NClNlbnQ6IE1vbmRheSwg SnVseSAyNSwgMjAwNSAyMzo0MA0KU3ViamVjdDogUmU6IFtMdHJ1XSBHYWxpY2lhbg0KDQoNCj4g QXQgMTE6NDYgMDUvMDcvMjYsIERvdWcgRXdlbGwgd3JvdGU6DQo+ICA+SVNPIDYzOS0yL1JBIGhh cyBhbm5vdW5jZWQgYSBjaGFuZ2Ugb24gaXRzIENoYW5nZSBOb3RpY2UgcGFnZToNCj4gID4NCj4g ID5odHRwOi8vd3d3LmxvYy5nb3Yvc3RhbmRhcmRzL2lzbzYzOS0yL2NvZGVjaGFuZ2VzLmh0bWwN Cj4gID4NCj4gID5UaGUgRW5nbGlzaCBuYW1lIG9mIHRoZSBsYW5ndWFnZSByZXByZXNlbnRlZCBi eSBjb2RlIGVsZW1lbnRzICJnbCIgYW5kDQo+ICA+ImdsZyIgaGFzIGJlZW4gY2hhbmdlZCBmcm9t ICJHYWxsZWdhbiIgdG8gIkdhbGljaWFuLiIgIFRoZSBOb3RlIG9uIHRoZQ0KPiAgPkNoYW5nZSBO b3RpY2UgcGFnZSByZWFkcywgIkluY29ycmVjdCBmb3JtIG9mIEVuZ2xpc2ggbmFtZSAoR2FsbGVn YW4pDQo+ICA+Y29ycmVjdGVkLiIgIEFsbCBzaXggb25saW5lIHZlcnNpb25zIG9mIHRoZSBJU08g NjM5LTIgY29kZSBsaXN0IGhhdmUNCj4gID5iZWVuIGNvcnJlY3RlZCB1bmlmb3JtbHkuDQo+ICA+ DQo+ICA+U2luY2Ugd2UgaGF2ZSBub3QgeWV0IHJlYWNoZWQgRGF0ZSBCLCBJIHByb3Bvc2UgdGhh dCB0aGUgRGVzY3JpcHRpb24NCj4gID5maWVsZCBmb3IgcHJpbWFyeSBsYW5ndWFnZSBzdWJ0YWcg ImdsIiBpbiB0aGUgaW5pdGlhbCByZWdpc3RyeSBiZQ0KPiAgPmNoYW5nZWQgZnJvbSAiR2FsbGVn YW4iIHRvICJHYWxpY2lhbiIgdG8gbWF0Y2ggdGhpcyBjaGFuZ2UuICBUaGlzIHdpbGwNCj4gID5w cm9iYWJseSByZXF1aXJlIGEgdGlja2V0Lg0KPg0KPiBbY2hhaXIgaGF0IG9uXQ0KPiBQbGVhc2Ug Z28gYWhlYWQgYW5kIGNyZWF0ZSBhIHRpY2tldC4NCj4NCj4gW2NoYWlyIGhhdCBvZmZdDQo+IEkg c3VwcG9ydCB0aGlzIGNoYW5nZSwgYnV0IEknbSBva2F5IGlmIHdlIGRvbid0IGNoYW5nZS4NCj4N Cj4gUmVnYXJkcywgICAgTWFydGluLg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBMdHJ1IG1haWxpbmcgbGlzdA0KPiBMdHJ1QGxpc3Rz LmlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2x0cnUN Cj4NCj4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpMdHJ1IG1haWxpbmcgbGlzdA0KTHRydUBsaXN0cy5pZXRmLm9yZw0KaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHRydQ0KDQoNCg0KDQo= --===============1410904372== 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 --===============1410904372==-- From ltru-bounces@lists.ietf.org Tue Jul 26 13:48:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTXF-0003FV-14; Tue, 26 Jul 2005 13:48:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTXD-0003FQ-K5 for ltru@megatron.ietf.org; Tue, 26 Jul 2005 13:48:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09987 for ; Tue, 26 Jul 2005 13:48:05 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DxU2H-0004mA-P6 for ltru@ietf.org; Tue, 26 Jul 2005 14:20:16 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Tue, 26 Jul 2005 10:41:32 -0700 Message-ID: <03a701c5920a$2b179060$666e3009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <003f01c59091$49b6c6a0$030aa8c0@DEWELL> Subject: Re: [Ltru] Action items on draft-initial? Date: Tue, 26 Jul 2005 10:48:01 -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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA09987 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 > What about the normative/informative issue? I don't remember any > agreement as to whether the source standards whose code elements were > used in the initial registry should be normative, and as I said, I woul= d > rather leave that judgment to others. A normative citation, that does not mean that the contents of the source standard are incorporated, lock, stock, and barrel. Instead, it just mean= s that reference to that standard is required for implementing this documen= t's requirements. In the case of the source standards, they are only *indirectly* required, since the real requirement is in [I-D.ietf-ltru-registry] Phillips, A., Ed. and M. Davis, Ed., =E2=80=9CT= ags for Identifying Languages,=E2=80=9D June 2005. *That* document has the normative references it needs. So this document doesn't need any normative references except to that document. =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Sunday, July 24, 2005 13:50 Subject: [Ltru] Action items on draft-initial? > I don't see any open tickets for draft-initial, but I'm pretty sure > there was an emerging hum to change the references so that the wording > matched the official listings in the online ISO catalog: > > [ISO15924] ISO 15924:2004, "Information and documentation -- Codes for > the representation of names of scripts," Ed. 1. > > [ISO3166-1] ISO 3166-1:1997, "Codes for the representation of names of > countries and their subdivisions -- Part 1: Country codes," Ed. 1. > > [ISO639-1] ISO 639-1:2002, "Codes for the representation of names of > languages -- Part 1: Alpha-2 code," Ed. 1. > > [ISO639-2] ISO 639-2:1998, "Codes for the representation of names of > languages -- Part 2: Alpha-3 code," Ed. 1. > > Is this correct? Are these current revisions the ones we want to cite? > It would seem logical that we would always want to cite the latest > version of any external standard, but for the initial registry we refer > to "Code elements that were valid on that date [1995] in the selected > standard." Obviously none of these particular updates existed in 1995; > is this a problem? > > What about the UN M.49 standard? Is the citation we have adequate? > Does UNSD provide a better one that we should use instead? > > What about the normative/informative issue? I don't remember any > agreement as to whether the source standards whose code elements were > used in the initial registry should be normative, and as I said, I woul= d > rather leave that judgment to others. > > I'd like to know what the group wants to see here, so I can capture it > in an editor's copy. > > -- > Doug Ewell > Fullerton, California > http://users.adelphia.net/~dewell/ > > > > > > > > > > > -- > 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 Tue Jul 26 13:48:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTXn-0003r6-AA; Tue, 26 Jul 2005 13: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 1DxTXl-0003mo-BF for ltru@megatron.ietf.org; Tue, 26 Jul 2005 13:48:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10028 for ; Tue, 26 Jul 2005 13:48:40 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxU2r-0004mw-Kq for ltru@ietf.org; Tue, 26 Jul 2005 14:20:49 -0400 Received: from h-68-166-189-173.snvacaid.dynamic.covad.net ([68.166.189.173] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxTXf-0000sW-00 for ltru@ietf.org; Tue, 26 Jul 2005 13:48:35 -0400 Message-ID: <006101c5920a$57420580$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: Date: Tue, 26 Jul 2005 10:49: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.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Subject: [Ltru] [psg.com #1086] Galician X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 see Doug has entered this as issue #1086 (https://rt.psg.com use/password "ietf") I've marked this item "resolved" based on the discussion. Further discussion of this specific change should include the issue number in the subject line. The discussion of issue #1066 leaves the addition of the "synonyms" Karen mentions to the ietf-languages@iana.org mailing list. It would probably be of great value if Karen were to prepare a list of proposed added descriptions for discussion on ietf-languages@iana.org when 3066bis goes into effect. Randy, ltru co-chair > From: > To: "Mark Davis" > Cc: "Doug Ewell" ; "LTRU Working Group" > Sent: Tuesday, July 26, 2005 10:01 AM > Subject: Re: [Ltru] Galician > > This was an issue in my analysis of languages used in my industry. The > right thing for you to do now is likely to make this change to be > consistent with ISO, but this is where building out the > synonym/description structure in the registry would be useful. In my > source data for the language analysis I did, I had three unique line > items: Galician, Gallegan, and Galego. > > Adding these additional "descriptions" would really be useful to others > trying to reconcile festering language data. > > Karen Broome > > > > > > "Mark Davis" > Sent by: ltru-bounces@lists.ietf.org > 07/26/2005 07:12 AM > > > To: "Doug Ewell" , "LTRU Working Group" , > "Martin Duerst" > cc: > Subject: Re: [Ltru] Galician > > > > I support this change, but I'm okay if we don't change. > Ditto > > ýMark > > ----- Original Message ----- > From: "Martin Duerst" > To: "Doug Ewell" ; "LTRU Working Group" > > Sent: Monday, July 25, 2005 23:40 > Subject: Re: [Ltru] Galician > > > > At 11:46 05/07/26, Doug Ewell wrote: > > >ISO 639-2/RA has announced a change on its Change Notice page: > > > > > >http://www.loc.gov/standards/iso639-2/codechanges.html > > > > > >The English name of the language represented by code elements "gl" and > > >"glg" has been changed from "Gallegan" to "Galician." The Note on the > > >Change Notice page reads, "Incorrect form of English name (Gallegan) > > >corrected." All six online versions of the ISO 639-2 code list have > > >been corrected uniformly. > > > > > >Since we have not yet reached Date B, I propose that the Description > > >field for primary language subtag "gl" in the initial registry be > > >changed from "Gallegan" to "Galician" to match this change. This will > > >probably require a ticket. > > > > [chair hat on] > > Please go ahead and create a ticket. > > > > [chair hat off] > > I support this change, but I'm okay if we don't change. > > > > Regards, Martin. > > > > > > _______________________________________________ > > 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 Tue Jul 26 14:05:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTnt-0006k2-8g; Tue, 26 Jul 2005 14:05:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTnr-0006jw-QS for ltru@megatron.ietf.org; Tue, 26 Jul 2005 14:05:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10917 for ; Tue, 26 Jul 2005 14:05:18 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxUIx-0005CP-7N for ltru@ietf.org; Tue, 26 Jul 2005 14:37:28 -0400 Received: from h-68-166-189-173.snvacaid.dynamic.covad.net ([68.166.189.173] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxTni-00050T-00 for ltru@ietf.org; Tue, 26 Jul 2005 14:05:10 -0400 Message-ID: <007a01c5920c$a8b4a100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <003f01c59091$49b6c6a0$030aa8c0@DEWELL> Subject: Re: [Ltru] Action items on draft-initial? Date: Tue, 26 Jul 2005 11:01:29 -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: 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: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Sunday, July 24, 2005 1:50 PM > Subject: [Ltru] Action items on draft-initial? > > I don't see any open tickets for draft-initial, but I'm pretty sure > there was an emerging hum to change the references so that the wording > matched the official listings in the online ISO catalog: > > [ISO15924] ISO 15924:2004, "Information and documentation -- Codes for > the representation of names of scripts," Ed. 1. > > [ISO3166-1] ISO 3166-1:1997, "Codes for the representation of names of > countries and their subdivisions -- Part 1: Country codes," Ed. 1. > > [ISO639-1] ISO 639-1:2002, "Codes for the representation of names of > languages -- Part 1: Alpha-2 code," Ed. 1. > > [ISO639-2] ISO 639-2:1998, "Codes for the representation of names of > languages -- Part 2: Alpha-3 code," Ed. 1. > > Is this correct? Are these current revisions the ones we want to cite? > It would seem logical that we would always want to cite the latest > version of any external standard, but for the initial registry we refer > to "Code elements that were valid on that date [1995] in the selected > standard." Obviously none of these particular updates existed in 1995; > is this a problem? We should cite whatever it was that was actually used. > What about the UN M.49 standard? Is the citation we have adequate? > Does UNSD provide a better one that we should use instead? I wouldn't fret too much about this. As long as the reference is in a reasonable form (as enforced by xml2rfc) and there is sufficient information there to actually locate the document, we're in good shape. If the RFC editor wants to tweak it, this can be worked out in AUTH48. > What about the normative/informative issue? I don't remember any > agreement as to whether the source standards whose code elements were > used in the initial registry should be normative, and as I said, I would > rather leave that judgment to others. ... I believe the only normative reference in the initial registry draft should be the reference to the registry draft, since the latter is the only one of the references that is required to "implement" the initial registry. 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 Jul 26 14:13:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTsu-0000Hw-5I; Tue, 26 Jul 2005 14:10:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxTsm-0000G6-PH for ltru@megatron.ietf.org; Tue, 26 Jul 2005 14:10:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11407 for ; Tue, 26 Jul 2005 14:10:23 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxUNt-0005Oz-BH for ltru@ietf.org; Tue, 26 Jul 2005 14:42:33 -0400 Received: from h-68-166-189-173.snvacaid.dynamic.covad.net ([68.166.189.173] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxTsl-0006QF-00 for ltru@ietf.org; Tue, 26 Jul 2005 14:10:23 -0400 Message-ID: <007f01c5920d$6336e7e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <003f01c59091$49b6c6a0$030aa8c0@DEWELL> Subject: Re: [Ltru] Action items on draft-initial? Date: Tue, 26 Jul 2005 11:11:04 -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: 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 Hi - a bit more on this... > From: "Doug Ewell" > To: "LTRU Working Group" > Sent: Sunday, July 24, 2005 1:50 PM > Subject: [Ltru] Action items on draft-initial? > > I don't see any open tickets for draft-initial, but I'm pretty sure > there was an emerging hum to change the references so that the wording > matched the official listings in the online ISO catalog: ... There might by some *minor* differences due to xml2rfc and the reference format preferred by the RFC editor, but what's important is that there is sufficient information to get to the right version of the right document. Tweaks to these are not uncommon during the RFC editing process, so as long as the correct information is there, within the constraints of what xml2rfc will do, I wouldn't be overly concerned. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 26 14:35:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUGx-00072D-IP; Tue, 26 Jul 2005 14:35:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUGw-0006xZ-9z for ltru@megatron.ietf.org; Tue, 26 Jul 2005 14:35:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13044 for ; Tue, 26 Jul 2005 14:35:18 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxUlz-00068a-Sb for ltru@ietf.org; Tue, 26 Jul 2005 15:07:29 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 11:35:01 -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] Action items on draft-initial? Date: Tue, 26 Jul 2005 11:35:00 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C3F93CF@irvmbxw01.quest.com> Thread-Topic: [Ltru] Action items on draft-initial? Thread-Index: AcWSDSDk1+6VNXPCTCGuJi6/FPNNMgAApiyg From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 26 Jul 2005 18:35:01.0097 (UTC) FILETIME=[BB644590:01C59210] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 >> What about the normative/informative issue? I don't remember any=20 >> agreement as to whether the source standards whose code elements were = >> used in the initial registry should be normative, and as I said, I=20 >> would rather leave that judgment to others. >... > >I believe the only normative reference in the initial registry draft = should >be the reference to the registry draft, since the latter is the = only one of >the references that is required to "implement" the initial = registry. It really doesn't matter ultimately.=20 Draft-registry does normatively reference the ISO standards as normative = sources for subtag values.=20 The instructions in Section 2 of draft-initial refer to the ISO = standards explicitly. The information taken from these standards by = draft-initial is normative. Thus it would be reasonable to put a = normative reference to the ISO standards into draft-initial. But since = it doesn't really make any difference the resulting document. We can = make (keep?) the references as informative and achieve identical = results. Addison 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@lists.ietf.org Tue Jul 26 14:42:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUNT-0000Me-Th; Tue, 26 Jul 2005 14:42:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUNS-0000KZ-IT for ltru@megatron.ietf.org; Tue, 26 Jul 2005 14:42:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13748 for ; Tue, 26 Jul 2005 14:42:05 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DxUsY-0006NC-5t for ltru@ietf.org; Tue, 26 Jul 2005 15:14:15 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Tue, 26 Jul 2005 11:35:27 -0700 Message-ID: <03cc01c59211$b55cbbe0$666e3009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "Randy Presuhn" , "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C3F93CF@irvmbxw01.quest.com> Subject: Re: [Ltru] Action items on draft-initial? Date: Tue, 26 Jul 2005 11:42:00 -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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA13748 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 what I was saying. We don't need 'normative closure'. Suppose standard A makes a normative reference to standard B, and B makes= a normative reference to C. It is unnecessary (and counterproductive) for A= to make a normative reference to C because of this. That is, it would only b= e necessary for A to make a normative reference to C if it needed to *independent of the requirements of B*. =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "Randy Presuhn" ; "LTRU Working Group" Sent: Tuesday, July 26, 2005 11:35 Subject: RE: [Ltru] Action items on draft-initial? >> What about the normative/informative issue? I don't remember any >> agreement as to whether the source standards whose code elements were >> used in the initial registry should be normative, and as I said, I >> would rather leave that judgment to others. >... > >I believe the only normative reference in the initial registry draft sho= uld >be the reference to the registry draft, since the latter is the only one= of >the references that is required to "implement" the initial registry. It really doesn't matter ultimately. Draft-registry does normatively reference the ISO standards as normative sources for subtag values. The instructions in Section 2 of draft-initial refer to the ISO standards explicitly. The information taken from these standards by draft-initial i= s normative. Thus it would be reasonable to put a normative reference to th= e ISO standards into draft-initial. But since it doesn't really make any difference the resulting document. We can make (keep?) the references as informative and achieve identical results. Addison Addison P. Phillips Globalization Architect, Quest Software Chair, W3C Internationalization Core Working Group 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 Tue Jul 26 14:54:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUZV-0003wu-CA; Tue, 26 Jul 2005 14:54:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxUZU-0003we-67 for ltru@megatron.ietf.org; Tue, 26 Jul 2005 14:54:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14467 for ; Tue, 26 Jul 2005 14:54:30 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxV4Z-0006lH-W6 for ltru@ietf.org; Tue, 26 Jul 2005 15:26:41 -0400 Received: from h-68-166-189-173.snvacaid.dynamic.covad.net ([68.166.189.173] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxUZR-0003Ny-00 for ltru@ietf.org; Tue, 26 Jul 2005 14:54:29 -0400 Message-ID: <00b401c59213$8c809c80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C3F93CF@irvmbxw01.quest.com> Subject: Re: [Ltru] Action items on draft-initial? Date: Tue, 26 Jul 2005 11:55: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.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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" ; "LTRU Working Group" > Sent: Tuesday, July 26, 2005 11:35 AM > Subject: RE: [Ltru] Action items on draft-initial? > >> What about the normative/informative issue? I don't remember any >> agreement as to whether the source standards whose code elements were >> used in the initial registry should be normative, and as I said, I >> would rather leave that judgment to others. >... > > >I believe the only normative reference in the initial registry draft should > >be the reference to the registry draft, since the latter is the only one of > >the references that is required to "implement" the initial registry. > > It really doesn't matter ultimately. > > Draft-registry does normatively reference the ISO standards as normative sources for subtag values. ... Yes, because to implement some of its procedures one needs to go to the ISO standards. But to initialize the registry from the initial registry draft, those portions of the registry draft are not necessary, so even the indirect reference is not normative. Even if it were, making such a change would be like "flattening" nested #include references in a C program. Though it might seem like a good idea at first, it quickly turns into a maintenance headache (especially if there are #define/#ifdef ordering issues), and can ultimately obscure more than it illuminates. Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 26 18:59:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxYOm-00082Q-UX; Tue, 26 Jul 2005 18: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 1DxYOl-00082L-5n for ltru@megatron.ietf.org; Tue, 26 Jul 2005 18:59:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02057 for ; Tue, 26 Jul 2005 18:59:40 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxYtu-0005D7-1T for ltru@ietf.org; Tue, 26 Jul 2005 19:31:54 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DxYOb-0000PK-4Y for ltru@ietf.org; Tue, 26 Jul 2005 15:59:33 -0700 Message-Id: <6.2.1.2.2.20050726230551.046f9cd0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 27 Jul 2005 00:59:06 +0200 To: "LTRU Working Group" From: r&d afrac In-Reply-To: <00b401c59213$8c809c80$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C3F93CF@irvmbxw01.quest.com> <00b401c59213$8c809c80$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 - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Subject: [Ltru] Last contribution - was: Action items on draft-initial? X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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:55 26/07/2005, Randy Presuhn wrote: >Hi - > > > From: "Addison Phillips" > > To: "Randy Presuhn" ; "LTRU Working > Group" > > Sent: Tuesday, July 26, 2005 11:35 AM > > Subject: RE: [Ltru] Action items on draft-initial? > > > >> What about the normative/informative issue? I don't remember any > >> agreement as to whether the source standards whose code elements were > >> used in the initial registry should be normative, and as I said, I > >> would rather leave that judgment to others. > >... > > > > >I believe the only normative reference in the initial registry draft > should > > >be the reference to the registry draft, since the latter is the only > one of > > >the references that is required to "implement" the initial registry. > > > > It really doesn't matter ultimately. > > > > Draft-registry does normatively reference the ISO standards as > normative sources for subtag values. >... > >Yes, because to implement some of its procedures one needs to go to the ISO >standards. But to initialize the registry from the initial registry >draft, those portions >of the registry draft are not necessary, so even the indirect reference is >not normative. > >Even if it were, making such a change would be like "flattening" nested >#include >references in a C program. Though it might seem like a good idea at first, it >quickly turns into a maintenance headache (especially if there are >#define/#ifdef >ordering issues), and can ultimately obscure more than it illuminates. > >Randy All this is confuse to me; It seems it is confuse to authors. It will be confuse to the users. At this stage, what seems clear to me is that ISO provides all the necessary ISO 11179 conformant information necessary to qualify in a non biased and open way the broadcasted, received and networked lingualised relations - differences that the WG-ltru did not even consider. It is clear to me that the WG-ltru still debates medium scripted texts instead of screen/printer rendering of architexts as used by Information and Communications Technologies. It is clear to me that the WG-ltru did not even allude to the lingual exchanges communities, nor to their cultural and human implications, nor to their needs and usages as used in a network environment. It is clear to me that the WG-ltru did not want to conform to ISO 11179, nor to consider Multilingual aspects, nor Internet protocols and IETF archietctural various contexts, etc. to produce clear, defined documentation conforming to the ISO documents it refers to, or to describe the differences, etc. I am therefore obliged to consider that all this work is extermely confuse and has definitely no interest for the Internet, even if it is likely that some could use it. I am therefore sorry to say that this WG-ltru failed the expectations of all the users I know and mine's, in spite of all my efforts and the efforts of severals. Since this WG-ltru wants to present this Draft to the IESG, I can only contribute with the two following propositions: - to replace "replace RFC 3066" by "complement RFC 3066" (I note that in spite of the repetition of that proposition, including during the WGLC, it was never discussed nor hummed) because the proposed document does not fulfil the WG-ltru charter. If that was done, the Draft would help in restricting the RFC 3066 politically controverted usage, to the benefit of W3C applications users and commercial ventures which may want to use it. - to remove the limitations on the "x-" escape sequence. The wording of this WG-ltru shows they only try to enforce an exclusive. I also repeat for clarity sake that the current commercial and Open Source projects or development I know of are based upon: 1. free format of x-tags (tags starting with the "x-" sequence) 2. ISO codes, by nature conforming or intending to conform with ISO 11179 (naming, updates, metadata, registry management, etc.) 3. referents and contexts defined by networked languages SDOs. 4. a determination to appeal to IESG, IANA, GAC, WSIS in the case this Draft was accepted as an RFC without the modification above. So, this WG-ltru cannot claim it ignored it, and that it does not purposely oppose users existing or intended practices and running code. I also want to call a last time on the members of this WG-ltru affinity group. Multilingualism, and Multilingual Internet, due to the positions of UNESCO, UN, WSIS, WGIG, MINC, EU, WIPO, USG, NICSO, etc. many States, cultural authorities, academic work, industry development, ccTLDs policy, local internet communities and ISOC Chapters, and recently Vint Cerf for ICANN, will increasingly be a matter of top consideration. Your intended use of the IANA registry, in the way you propose, without the considerations you refused or did not even discuss, will result into a disinterest by concerned lingual parties. This will also result from its exclusive ASCII basis, and of its deliberate decision of exclusion of x-tags. It will be considered as a political and commercial bias, and as a technically inadequate proposition. Should the IANA registry be really implemented and promoted, ISO based Open Source and other commercial, civil or public solutions will be made available, some as an open alternative to IANA servers. It would be likely that users would split: you would have dramatically cooperated to the balkanisation of the Internet. You, and the companies you represent, will get the resulting negative exposure: I am not sure this is what you and they want. I still wander why you want so much to harm the Internet, and to oppose their users? I find this sad. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Tue Jul 26 19:08:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxYXV-0002JP-B4; Tue, 26 Jul 2005 19:08:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxYXS-0002Ig-2d for ltru@megatron.ietf.org; Tue, 26 Jul 2005 19:08:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02639 for ; Tue, 26 Jul 2005 19:08:39 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-ash.bigfish.com ([206.16.192.253] helo=mail37-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxZ2b-0005Tx-0v for ltru@ietf.org; Tue, 26 Jul 2005 19:40:53 -0400 Received: from mail37-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail37-ash-R.bigfish.com (Postfix) with ESMTP id E767B5B5B23; Tue, 26 Jul 2005 23:08:28 +0000 (UTC) X-BigFish: VP Received: by mail37-ash (MessageSwitch) id 1122419308839468_14303; Tue, 26 Jul 2005 23:08:28 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail37-ash.bigfish.com (Postfix) with ESMTP id AAC7C5B5B23; Tue, 26 Jul 2005 23:08:28 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005072616162099:86102 ; Tue, 26 Jul 2005 16:16:20 -0700 To: "Randy Presuhn" , "LTRU Working Group" Subject: Re: [Ltru] [psg.com #1086] Galician MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Tue, 26 Jul 2005 16:05:23 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/26/2005 16:05:29, Serialize complete at 07/26/2005 16:05:29, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/26/2005 04:16:21 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/26/2005 04:16:22 PM, Serialize complete at 07/26/2005 04:16:22 PM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.3 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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'd be happy to do that. Let me get something together. Karen Broome "Randy Presuhn" Sent by: ltru-bounces@lists.ietf.org 07/26/2005 10:49 AM =20 To: "LTRU Working Group" cc:=20 Subject: [Ltru] [psg.com #1086] Galician Hi - I see Doug has entered this as issue #1086 (https://rt.psg.com use/password= "ietf") I've marked this item "resolved" based on the discussion. Further=20 discussion of this specific change should include the issue number in the subject line. The discussion of issue #1066 leaves the addition of the "synonyms" Karen=20 mentions to the ietf-languages@iana.org mailing list. It would probably be of=20 great value if Karen were to prepare a list of proposed added descriptions for discussion = on ietf-languages@iana.org when 3066bis goes into effect. Randy, ltru co-chair > From: > To: "Mark Davis" > Cc: "Doug Ewell" ; "LTRU Working Group"=20 > Sent: Tuesday, July 26, 2005 10:01 AM > Subject: Re: [Ltru] Galician > > This was an issue in my analysis of languages used in my industry. The > right thing for you to do now is likely to make this change to be > consistent with ISO, but this is where building out the > synonym/description structure in the registry would be useful. In my > source data for the language analysis I did, I had three unique line > items: Galician, Gallegan, and Galego. > > Adding these additional "descriptions" would really be useful to others > trying to reconcile festering language data. > > Karen Broome > > > > > > "Mark Davis" > Sent by: ltru-bounces@lists.ietf.org > 07/26/2005 07:12 AM > > > To: "Doug Ewell" , "LTRU Working Group" = , > "Martin Duerst" > cc: > Subject: Re: [Ltru] Galician > > > > I support this change, but I'm okay if we don't change. > Ditto > > =FDMark > > ----- Original Message -----=20 > From: "Martin Duerst" > To: "Doug Ewell" ; "LTRU Working Group" > > Sent: Monday, July 25, 2005 23:40 > Subject: Re: [Ltru] Galician > > > > At 11:46 05/07/26, Doug Ewell wrote: > > >ISO 639-2/RA has announced a change on its Change Notice page: > > > > > >http://www.loc.gov/standards/iso639-2/codechanges.html > > > > > >The English name of the language represented by code elements "gl"=20 and > > >"glg" has been changed from "Gallegan" to "Galician." The Note on=20 the > > >Change Notice page reads, "Incorrect form of English name (Gallegan) > > >corrected." All six online versions of the ISO 639-2 code list have > > >been corrected uniformly. > > > > > >Since we have not yet reached Date B, I propose that the Description > > >field for primary language subtag "gl" in the initial registry be > > >changed from "Gallegan" to "Galician" to match this change. This=20 will > > >probably require a ticket. > > > > [chair hat on] > > Please go ahead and create a ticket. > > > > [chair hat off] > > I support this change, but I'm okay if we don't change. > > > > Regards, Martin. > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > > Ltru mailing list > > Ltru@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > > > > > ---------------------------------------------------------------------------= ----- > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > Ltru mailing list > Ltru@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F 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 Jul 26 19:51:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxZCc-0005Tw-KD; Tue, 26 Jul 2005 19:51:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxZCa-0005Tr-UW for ltru@megatron.ietf.org; Tue, 26 Jul 2005 19:51:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05074 for ; Tue, 26 Jul 2005 19:51:09 -0400 (EDT) Received: from pop-borzoi.atl.sa.earthlink.net ([207.69.195.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxZhh-0006cz-Uz for ltru@ietf.org; Tue, 26 Jul 2005 20:23:24 -0400 Received: from h-68-166-189-173.snvacaid.dynamic.covad.net ([68.166.189.173] helo=oemcomputer) by pop-borzoi.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxZCT-00012R-00 for ltru@ietf.org; Tue, 26 Jul 2005 19:51:05 -0400 Message-ID: <001401c5923c$fa9ccbc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C3F93CF@irvmbxw01.quest.com><00b401c59213$8c809c80$7f1afea9@oemcomputer> <6.2.1.2.2.20050726230551.046f9cd0@mail.afrac.org> Subject: Re: [Ltru] Last contribution - was: Action items on draft-initial? Date: Tue, 26 Jul 2005 16:51:43 -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: 6d95a152022472c7d6cdf886a0424dc6 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: "r&d afrac" > To: "LTRU Working Group" > Sent: Tuesday, July 26, 2005 3:59 PM > Subject: [Ltru] Last contribution - was: Action items on draft-initial? ... > All this is confuse to me; It seems it is confuse to authors. It will be > confuse to the users. I haven't seen any indication that the document's sole editor (Doug) is confused. He asked for guidance, which is a perfectly reasonable thing for an editor to do. As for users, page 1 of http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt says: This memo defines the initial contents of the Language Subtag Registry for use in forming tags for the identification of languages. Since the contents of this memo only serve as a starting point for the registry, it is inappropriate to use this memo in lieu of the registry. Consequently, the IANA personnel initializing the registry are really the only likely users of this document. Anyone else using it has gone outside its express scope of application, and thus, from my point of view, qualifies as "pre-confused". :-) > At this stage, what seems clear to me is that ISO provides all the > necessary ISO 11179 conformant information necessary to qualify in a non > biased and open way the broadcasted, received and networked lingualised > relations - differences that the WG-ltru did not even consider. It is > clear to me that the WG-ltru still debates medium scripted texts instead of > screen/printer rendering of architexts as used by Information and > Communications Technologies. It is clear to me that the WG-ltru did not > even allude to the lingual exchanges communities, nor to their cultural and > human implications, nor to their needs and usages as used in a network > environment. It is clear to me that the WG-ltru did not want to conform to > ISO 11179, nor to consider Multilingual aspects, nor Internet protocols and > IETF archietctural various contexts, etc. to produce clear, defined > documentation conforming to the ISO documents it refers to, or to describe > the differences, etc. > > I am therefore obliged to consider that all this work is extermely confuse > and has definitely no interest for the Internet, even if it is likely that > some could use it. I am therefore sorry to say that this WG-ltru failed the > expectations of all the users I know and mine's, in spite of all my efforts > and the efforts of severals. Since this WG-ltru wants to present this Draft > to the IESG, I can only contribute with the two following propositions: > > - to replace "replace RFC 3066" by "complement RFC 3066" (I note that in > spite of the repetition of that proposition, including during the WGLC, it > was never discussed nor hummed) because the proposed document does not > fulfil the WG-ltru charter. If that was done, the Draft would help in > restricting the RFC 3066 politically controverted usage, to the benefit of > W3C applications users and commercial ventures which may want to use it. > > - to remove the limitations on the "x-" escape sequence. The wording of > this WG-ltru shows they only try to enforce an exclusive. You've raised these issues before. The rough consensus on how to handle each was quite clear. You may, of course, appeal under the terms of RFC 2026 section 6.5.1, and request that the AD direct us to discuss your requests further. > I also repeat for clarity sake that the current commercial and Open Source > projects or development I know of are based upon: > > 1. free format of x-tags (tags starting with the "x-" sequence) > 2. ISO codes, by nature conforming or intending to conform with ISO 11179 > (naming, updates, metadata, registry management, etc.) > 3. referents and contexts defined by networked languages SDOs. > 4. a determination to appeal to IESG, IANA, GAC, WSIS in the case this > Draft was accepted as an RFC without the modification above. > > So, this WG-ltru cannot claim it ignored it, and that it does not purposely > oppose users existing or intended practices and running code. Indeed, your comments have been discussed repeatedly and at excessive length. In some cases, they have resulted in changes or clarifications. In other cases, the WG's consensus has been to do something else. You may, of course, appeal under the terms of RFC 2026 section 6.5.1. > I also want to call a last time on the members of this WG-ltru affinity > group. Multilingualism, and Multilingual Internet, due to the positions of > UNESCO, UN, WSIS, WGIG, MINC, EU, WIPO, USG, NICSO, etc. many States, > cultural authorities, academic work, industry development, ccTLDs policy, > local internet communities and ISOC Chapters, and recently Vint Cerf for > ICANN, will increasingly be a matter of top consideration. Your intended > use of the IANA registry, in the way you propose, without the > considerations you refused or did not even discuss, will result into a > disinterest by concerned lingual parties. This will also result from its > exclusive ASCII basis, and of its deliberate decision of exclusion > of x-tags. It will be considered as a political and commercial bias, and > as a technically inadequate proposition. Should the IANA registry be really > implemented and promoted, ISO based Open Source and other commercial, civil > or public solutions will be made available, some as an open alternative to > IANA servers. It would be likely that users would split: you would have > dramatically cooperated to the balkanisation of the Internet. You, and the > companies you represent, will get the resulting negative exposure: I am not > sure this is what you and they want. I still wander why you want so much to > harm the Internet, and to oppose their users? I find this sad. > jfc Specific technical comments, especially those proposing specific replacement text, are welcome. 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 Jul 26 20:15:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxZYa-0002Pi-1p; Tue, 26 Jul 2005 20: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 1DxZYY-0002O1-5a for ltru@megatron.ietf.org; Tue, 26 Jul 2005 20:13:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06242 for ; Tue, 26 Jul 2005 20:13:52 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxa3h-00079h-PE for ltru@ietf.org; Tue, 26 Jul 2005 20:46:06 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 17:13:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Jul 2005 17:13:37 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C3F964D@irvmbxw01.quest.com> Thread-Topic: ABNF beautification... Thread-Index: AcWSQAR5CAfHYYUFRnuNiU4SATd/yQ== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 27 Jul 2005 00:13:37.0938 (UTC) FILETIME=[092C2F20:01C59240] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [Ltru] ABNF beautification... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.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="===============1174809282==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1174809282== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSB0b29rIEtlbnQncyBzdWdnZXN0aW9uIGZvciBtb2RpZnlpbmcgYW5kIGNsZWFuaW5nIHVwIHRo ZSBBQk5GIGFuZCBtYWRlIHNvbWUgY2hhbmdlcyB0byBpdC4gTW9zdGx5IEkgcmVtb3ZlZCBleHRy YSBydWxlcyBmcm9tIGl0LCByZS1jb21iaW5pbmcgc29tZSB0aGluZ3MgKHBlciBtZXNzYWdlcyBm cm9tIEZyYW5rIGFuZCBJKSwgYW5kIGRvaW5nIHNvbWUgZ2VudGxlIHR1Z2dpbmcuIA0KDQpZb3Ug d2lsbCBub3RlIHRoYXQgSSByZW5hbWVkIHRoZSBwcm9kdWN0aW9uIHJ1bGUgImxhbmciIHRvICJs YW5ndWFnZSIuIEl0IHB1dHMgdGhlICJleHRsYW5nIiBwcm9kdWN0aW9uIGFzIGFuIG9wdGlvbiBv biAyKjNBTFBIQSBzdWJ0YWdzLiBUaGUgNEFMUEhBIHByb2R1Y3Rpb24gZXhwbGljaXRseSByZXNl cnZlZCBoZXJlLCB3aGljaCBpcyBhbiBpbm5vdmF0aW9uIGluIHRoZSBBQk5GIGJ1dCBub3QgaW4g dGhlIHRleHQgb3Igb3ZlcmFsbCBtZWFuaW5nIG9mIHRoZSBBQk5GIChwcmV2aW91c2x5IHdlIGhh ZCAyKjNBTFBIQSBmb2xsb3dlZCBieSBleHRsYW5nIGFuZCA0KjhBTFBIQSB3YXMgcmVnaXN0ZXJl ZCBsYW5nIGFuZCBtb3N0IHJlY2VudGx5IHRoZSByZWxhdGlvbnNoaXAgb2YgZXh0bGFuZ3MgdG8g dGhlIGxpa2VseSB1c2Ugb2YgNEFMUEhBIElTTzYzOS02IHdhcyBkaXNjdXNzZWQpLg0KDQpUaGlz IEFCTkYgaXMgc2xpZ2h0bHkgY2xlYW5lciB0aGFuIHRoZSBjdXJyZW50IGRyYWZ0LTA5IEFOQkYg KGFsbCB0aGUgbGFuZ3VhZ2Ugc3VidGFnIHN0dWZmIGlzIHRvZ2V0aGVyLCB0aGUgZXh0bGFuZyBy ZWxhdGlvbnNoaXAgaXMgY2xlYXIsIHRoZSBydWxlIG5hbWVzIGFyZSBtb3JlIGV4cHJlc3NpdmUu DQoNCkhlcmUgaXMgdGhlIGN1cnJlbnQgcmVzdWx0Og0KDQotLQ0KTGFuZ3VhZ2UtVGFnICAgID0g bGFuZ3RhZw0KICAgICAgICAgICAgICAgIC8gcHJpdmF0ZXVzZSAgICAgICAgICAgOyBwcml2YXRl IHVzZSB0YWcNCiAgICAgICAgICAgICAgICAvIGdyYW5kZmF0aGVyZWQgICAgICAgIDsgZ3JhbmRm YXRoZXJlZCByZWdpc3RyYXRpb25zDQoNCmxhbmd0YWcgICAgICAgICA9IChsYW5ndWFnZQ0KICAg ICAgICAgICAgICAgICAgIFsiLSIgc2NyaXB0XQ0KICAgICAgICAgICAgICAgICAgIFsiLSIgcmVn aW9uXQ0KICAgICAgICAgICAgICAgICAgICooIi0iIHZhcmlhbnQpDQogICAgICAgICAgICAgICAg ICAgKigiLSIgZXh0ZW5zaW9uKQ0KICAgICAgICAgICAgICAgICAgIFsiLSIgcHJpdmF0ZXVzZV0p DQoNCmxhbmd1YWdlICAgICAgICA9IDIqM0FMUEhBIFsgZXh0bGFuZyBdIDsgc2hvcnRlc3QgSVNP IDYzOSBjb2RlDQogICAgICAgICAgICAgICAgLyA0QUxQSEEgICAgICAgICAgICAgICA7IHJlc2Vy dmVkIGZvciBmdXR1cmUgdXNlDQogICAgICAgICAgICAgICAgLyA1KjhBTFBIQSAgICAgICAgICAg ICA7IHJlZ2lzdGVyZWQgbGFuZ3VhZ2Ugc3VidGFnDQoNCmV4dGxhbmcgICAgICAgICA9ICozKCIt IiAzQUxQSEEpICAgICAgIDsgcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2UNCg0Kc2NyaXB0ICAgICAg ICAgID0gNEFMUEhBICAgICAgICAgICAgICAgOyBJU08gMTU5MjQgY29kZQ0KDQpyZWdpb24gICAg ICAgICAgPSAyQUxQSEEgICAgICAgICAgICAgICA7IElTTyAzMTY2IGNvZGUNCiAgICAgICAgICAg ICAgICAvIDNESUdJVCAgICAgICAgICAgICAgIDsgVU4gTS40OSBjb2RlDQoNCnZhcmlhbnQgICAg ICAgICA9IDUqOGFscGhhbnVtICAgICAgICAgIDsgcmVnaXN0ZXJlZCB2YXJpYW50cw0KICAgICAg ICAgICAgICAgIC8gKERJR0lUIDNhbHBoYW51bSkNCg0KZXh0ZW5zaW9uICAgICAgID0gc2luZ2xl dG9uIDEqKCItIiAoMio4YWxwaGFudW0pKQ0KDQpzaW5nbGV0b24gICAgICAgPSAleDQxLTU3IC8g JXg1OS01QSAvICV4NjEtNzcgLyAleDc5LTdBIC8gRElHSVQNCiAgICAgICAgICAgICAgICA7ICJh Ii0idyIgLyAieSItInoiIC8gIkEiLSJXIiAvICJZIi0iWiIgLyAiMCItIjkiDQogICAgICAgICAg ICAgICAgOyBTaW5nbGUgbGV0dGVyczogeC9YIGlzIHJlc2VydmVkIGZvciBwcml2YXRlIHVzZQ0K DQpwcml2YXRldXNlICAgICAgPSAoIngiLyJYIikgMSooIi0iICgxKjhhbHBoYW51bSkpDQoNCmdy YW5kZmF0aGVyZWQgICA9IDEqM0FMUEhBIDEqMigiLSIgKDIqOGFscGhhbnVtKSkNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOyBncmFuZGZhdGhlcmVkIHJlZ2lzdHJhdGlv bg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7IE5vdGU6IGkgaXMgdGhl IG9ubHkgc2luZ2xldG9uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDsg dGhhdCBzdGFydHMgYSBncmFuZGZhdGhlcmVkIHRhZw0KDQphbHBoYW51bSAgICAgICAgPSAoQUxQ SEEgLyBESUdJVCkgICAgIDsgbGV0dGVycyBhbmQgbnVtYmVycw0KLS0NCg0KVGhpcyBjaGVja3Mg b3V0IHZpYSBodHRwOi8vcnRnLmlldGYub3JnL35mZW5uZXIvYWJuZi5jZ2kNCg0KQW55IGNvbW1l bnRzPyBDYW4gSSBnZXQgYSBodW0gdG8gdXNlIHRoaXMgaW4gcHJlZmVyZW5jZSB0byBkcmFmdC0w OSdzIHZlcnNpb24/DQoNCkFkZGlzb24NCg0KQWRkaXNvbiBQLiBQaGlsbGlwcw0KR2xvYmFsaXph dGlvbiBBcmNoaXRlY3QsIFF1ZXN0IFNvZnR3YXJlDQpodHRwOi8vd3d3LnF1ZXN0LmNvbQ0KDQpD aGFpciwgVzNDIEludGVybmF0aW9uYWxpemF0aW9uIENvcmUgV29ya2luZyBHcm91cA0KaHR0cDov L3d3dy53My5vcmcvSW50ZXJuYXRpb25hbA0KDQpJbnRlcm5hdGlvbmFsaXphdGlvbiBpcyBub3Qg YSBmZWF0dXJlLg0KSXQgaXMgYW4gYXJjaGl0ZWN0dXJlLiANCg0KDQo= --===============1174809282== 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 --===============1174809282==-- From ltru-bounces@lists.ietf.org Tue Jul 26 21:23:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxadz-0005Kq-N9; Tue, 26 Jul 2005 21:23:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxadx-0005Id-BP for ltru@megatron.ietf.org; Tue, 26 Jul 2005 21:23:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10373 for ; Tue, 26 Jul 2005 21:23:31 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dxb95-0000ix-G2 for ltru@ietf.org; Tue, 26 Jul 2005 21:55:45 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Tue, 26 Jul 2005 18:16:29 -0700 Message-ID: <04bd01c59249$c9248990$666e3009@sanjose.ibm.com> From: "Mark Davis" To: "Addison Phillips" , "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C3F964D@irvmbxw01.quest.com> Subject: Re: [Ltru] ABNF beautification... Date: Tue, 26 Jul 2005 18:23:25 -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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id VAA10373 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 looks good to me. Note that for valid, non-grandfathered tags, where A means alpha, D means digit, and E means A or D: The first subtag: - AA..AAAAAAAA is always a language - 'x' is private use - others are errors: E (!=3D 'x'), or EE..EEEEEEEE where any E is a digit Between the first subtag and the first E: - AAAA is always a script - AAA is always an extlang - AA or DDD is always a region - AEEEE..AEEEEEEE, and DEEE..DEEEEEEE is always a variant - others are errors: DD, and EE, EEE, AEEE if mixed (one E is an A and on= e is a D) =E2=80=8EMark ----- Original Message -----=20 From: "Addison Phillips" To: "LTRU Working Group" Sent: Tuesday, July 26, 2005 17:13 Subject: [Ltru] ABNF beautification... > I took Kent's suggestion for modifying and cleaning up the ABNF and mad= e some changes to it. Mostly I removed extra rules from it, re-combining so= me things (per messages from Frank and I), and doing some gentle tugging. > > You will note that I renamed the production rule "lang" to "language". = It puts the "extlang" production as an option on 2*3ALPHA subtags. The 4ALPH= A production explicitly reserved here, which is an innovation in the ABNF b= ut not in the text or overall meaning of the ABNF (previously we had 2*3ALPH= A followed by extlang and 4*8ALPHA was registered lang and most recently th= e relationship of extlangs to the likely use of 4ALPHA ISO639-6 was discussed). > > This ABNF is slightly cleaner than the current draft-09 ANBF (all the language subtag stuff is together, the extlang relationship is clear, the rule names are more expressive. > > Here is the current result: > > -- > Language-Tag =3D langtag > / privateuse ; private use tag > / grandfathered ; grandfathered registrations > > langtag =3D (language > ["-" script] > ["-" region] > *("-" variant) > *("-" extension) > ["-" privateuse]) > > language =3D 2*3ALPHA [ extlang ] ; shortest ISO 639 code > / 4ALPHA ; reserved for future use > / 5*8ALPHA ; registered language subtag > > extlang =3D *3("-" 3ALPHA) ; reserved for future use > > script =3D 4ALPHA ; ISO 15924 code > > region =3D 2ALPHA ; ISO 3166 code > / 3DIGIT ; UN M.49 code > > variant =3D 5*8alphanum ; registered variants > / (DIGIT 3alphanum) > > extension =3D singleton 1*("-" (2*8alphanum)) > > singleton =3D %x41-57 / %x59-5A / %x61-77 / %x79-7A / DIGIT > ; "a"-"w" / "y"-"z" / "A"-"W" / "Y"-"Z" / "0"-"9" > ; Single letters: x/X is reserved for private use > > privateuse =3D ("x"/"X") 1*("-" (1*8alphanum)) > > grandfathered =3D 1*3ALPHA 1*2("-" (2*8alphanum)) > ; grandfathered registration > ; Note: i is the only singleton > ; that starts a grandfathered tag > > alphanum =3D (ALPHA / DIGIT) ; letters and numbers > -- > > This checks out via http://rtg.ietf.org/~fenner/abnf.cgi > > Any comments? Can I get a hum to use this in preference to draft-09's version? > > 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 Tue Jul 26 21:28:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxaiy-0007B3-Ba; Tue, 26 Jul 2005 21:28:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxaiw-0007Av-Nn for ltru@megatron.ietf.org; Tue, 26 Jul 2005 21:28:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10617 for ; Tue, 26 Jul 2005 21:28:40 -0400 (EDT) Received: from mercury.ccil.org ([192.190.237.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxbE5-0000pN-36 for ltru@ietf.org; Tue, 26 Jul 2005 22:00:55 -0400 Received: from cowan by mercury.ccil.org with local (Exim 4.34) id 1DxajL-0000Is-Tf; Tue, 26 Jul 2005 21:29:07 -0400 Date: Tue, 26 Jul 2005 21:29:07 -0400 To: Mark Davis Subject: Re: [Ltru] ABNF beautification... Message-ID: <20050727012907.GC28296@ccil.org> References: <634978A7DF025A40BFEF33EB191E13BC0C3F964D@irvmbxw01.quest.com> <04bd01c59249$c9248990$666e3009@sanjose.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04bd01c59249$c9248990$666e3009@sanjose.ibm.com> User-Agent: Mutt/1.3.28i From: John Cowan X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: LTRU Working Group X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 scripsit: > It looks good to me. +1 -- Long-short-short, long-short-short / Dactyls in dimeter, Verse form with choriambs / (Masculine rhyme): cowan@ccil.org 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@lists.ietf.org Tue Jul 26 22:27:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxbeE-0006Qy-Tm; Tue, 26 Jul 2005 22:27:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxbeE-0006Qt-AK for ltru@megatron.ietf.org; Tue, 26 Jul 2005 22:27: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 WAA13366 for ; Tue, 26 Jul 2005 22:27: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 <20050727022700.IAAN24042.mta11.adelphia.net@DEWELL> for ; Tue, 26 Jul 2005 22:27:00 -0400 Message-ID: <004401c59252$932b7700$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Tue, 26 Jul 2005 19:26:15 -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: ABNF beautification... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > Between the first subtag and the first E: > - AAAA is always a script > - AAA is always an extlang > - AA or DDD is always a region > - AEEEE..AEEEEEEE, and DEEE..DEEEEEEE is always a variant > - others are errors: DD, and EE, EEE, AEEE if mixed (one E is an A and > one is a D) AEEE is also an error if all the E's are D's. Mark's explanation was excellent and should demonstrate that parsing these tags is not rocket science, even after extlangs and extensions are factored in. -- 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 Jul 26 22:38:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxbok-0008WF-Vd; Tue, 26 Jul 2005 22:38:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxbok-0008WA-Cn for ltru@megatron.ietf.org; Tue, 26 Jul 2005 22:38:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13731 for ; Tue, 26 Jul 2005 22:38:44 -0400 (EDT) Received: from icu-project.org ([66.160.189.149]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DxcJu-0002U9-8B for ltru@ietf.org; Tue, 26 Jul 2005 23:10:59 -0400 Received: from markdavis ([24.23.194.196]) by icu-project.org for ; Tue, 26 Jul 2005 19:31:44 -0700 Message-ID: <07df01c59254$4c49a490$666e3009@sanjose.ibm.com> From: "Mark Davis" To: "Doug Ewell" , "LTRU Working Group" References: <004401c59252$932b7700$030aa8c0@DEWELL> Subject: Re: [Ltru] Re: ABNF beautification... Date: Tue, 26 Jul 2005 19:38:40 -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.1506 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id WAA13731 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 Thanks for catching that. I should have said "(one character is an A and = one is a D)" =E2=80=8EMark ----- Original Message -----=20 From: "Doug Ewell" To: "LTRU Working Group" Sent: Tuesday, July 26, 2005 19:26 Subject: [Ltru] Re: ABNF beautification... > Mark Davis wrote: > > > Between the first subtag and the first E: > > - AAAA is always a script > > - AAA is always an extlang > > - AA or DDD is always a region > > - AEEEE..AEEEEEEE, and DEEE..DEEEEEEE is always a variant > > - others are errors: DD, and EE, EEE, AEEE if mixed (one E is an A an= d > > one is a D) > > AEEE is also an error if all the E's are D's. > > Mark's explanation was excellent and should demonstrate that parsing > these tags is not rocket science, even after extlangs and extensions ar= e > factored in. > > -- > 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 Jul 27 00:26:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxdUu-0002kU-Cg; Wed, 27 Jul 2005 00:26:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxdUr-0002kL-Uf for ltru@megatron.ietf.org; Wed, 27 Jul 2005 00:26: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 AAA19430 for ; Wed, 27 Jul 2005 00:26:18 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DxdTY-0002Bg-CJ for ltru@lists.ietf.org; Wed, 27 Jul 2005 06:25:00 +0200 Received: from c-180-160-11.hh.dial.de.ignite.net ([62.180.160.11]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Jul 2005 06:25:00 +0200 Received: from nobody by c-180-160-11.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Jul 2005 06:25:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 27 Jul 2005 06:23:59 +0200 Organization: Lines: 39 Message-ID: <42E70C5F.5E81@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C3F964D@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-180-160-11.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: ABNF beautification... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > Language-Tag = langtag > / privateuse ; private use tag > / grandfathered ; grandfathered registrations ...............-X......................Y+ You could shift column X to the right (X-1), and column Y to the left (Y+1) everywhere: | Language-Tag = langtag | / privateuse ; private use tag | / grandfathered ; grandfathered registrations ...............-X......................Y+ Then you would have the place for the recommended (2234(bis)) "grouping" in the : > language = 2*3ALPHA [ extlang ] ; shortest ISO 639 code > / 4ALPHA ; reserved for future use > / 5*8ALPHA ; registered language subtag ...............-X......................Y+ | language = (2*3ALPHA [ extlang ]) ; shortest ISO 639 code | / 4ALPHA ; reserved for future use | / 5*8ALPHA ; registered language subtag Only a lower case 2234-"recommended", and here it's probably unnecessary. Even 2234 didn't follow its own recommendation for LWSP, and there it's less obvious than in . > Can I get a hum to use this in preference to draft-09's > version? IMHO it's better and clearer, and if we didn't destroy Kent's original idea it should be also better for the version in the matching draft. The alpha4 case is also perfectly clear now. Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 27 01:26:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxeRT-00083i-Pk; Wed, 27 Jul 2005 01:26:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxeRS-00083Y-EV for ltru@megatron.ietf.org; Wed, 27 Jul 2005 01:26:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22155 for ; Wed, 27 Jul 2005 01:26:52 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxewd-0006m5-Ln for ltru@ietf.org; Wed, 27 Jul 2005 01:59:08 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 22:26:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Jul 2005 22:26:38 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C3F969E@irvmbxw01.quest.com> Thread-Topic: revised editor's copy online Thread-Index: AcWSa75D34NUIfqyQyyavr7pJ1i1ew== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 27 Jul 2005 05:26:39.0216 (UTC) FILETIME=[C3AFC700:01C5926B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Doug Ewell Subject: [Ltru] revised editor's copy 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="===============2090898316==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============2090898316== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBoYXZlIGluY29ycG9yYXRlZCB0aGUgQUJORiBjaGFuZ2VzLCBpbmNsdWRpbmcgRnJhbmsncyBz dWdnZXN0aW9ucywgaW50byB0aGUgZWRpdG9yJ3MgY29weS4gSSBhbHNvIHRyaWVkIG1pZ2h0aWx5 IHRvIGluY29ycG9yYXRlIEtlbnQncyBzdWdnZXN0aW9ucyBmb3IgdGhlIElTTyByZWZlcmVuY2Vz IChhbmQgdGhpbmsgSSBtaWdodCBoYXZlIHN1Y2NlZWRlZCkuIFRoZSBIVE1MIG9mIHRoZSByZWZl cmVuY2VzIGlzbid0IHZlcnkgbmljZSBsb29raW5nLCBidXQgdGhlIHRleHQgdmVyc2lvbiAod2hp Y2ggaXMgd2hhdCBjb3VudHMsIGFmdGVyIGFsbCkgbG9va3MgbW9yZS1vci1sZXNzIGxpa2UgS2Vu dCdzIHN1Z2dlc3Rpb25zLiBJIG9wdGVkIGZvciBjb25zaXN0ZW5jeSBpbiBkb2luZyB0aGUgZm9y bWF0dGluZywgcGxlYXNlIG5vdGUuIFRoaXMgbWF5IGJlIGEgd2VhayBzcG90IGluIHhtbDJyZmMg KG9yIGl0IG1heSBiZSBkdWUgdG8gZWRpdG9yaWFsIGlnbm9yYW5jZSwgYSBtb3JlIGNvbW1vbiBw cm9ibGVtKQ0KDQpEb3VnOiB0aGUgWE1MLCBhcyB1c3VhbCwgaXMgb25saW5lLiBZb3UgY2FuIHN0 ZWFsIHRoZSByZWZlcmVuY2UgWE1MIGF0IHlvdXIgbGVpc3VyZS4gSWYgeW91IGhhdmUgcHJvYmxl bXMsIGxldCBtZSBrbm93IGFuZCBJJ2xsIHJpcCBpdCBmb3IgeW91Lg0KDQpodHRwOi8vd3d3Lmlu dGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LXJlZ2lzdHJ5LTEwLmh0bWwNCmh0dHA6 Ly93d3cuaW50ZXItbG9jYWxlLmNvbS9JRC9kcmFmdC1pZXRmLWx0cnUtcmVnaXN0cnktMTAudHh0 DQpodHRwOi8vd3d3LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtaWV0Zi1sdHJ1LXJlZ2lzdHJ5 LTEwLnhtbA0KDQpBZGRpc29uDQoNCkFkZGlzb24gUC4gUGhpbGxpcHMNCkdsb2JhbGl6YXRpb24g QXJjaGl0ZWN0LCBRdWVzdCBTb2Z0d2FyZQ0KaHR0cDovL3d3dy5xdWVzdC5jb20NCg0KQ2hhaXIs IFczQyBJbnRlcm5hdGlvbmFsaXphdGlvbiBDb3JlIFdvcmtpbmcgR3JvdXANCmh0dHA6Ly93d3cu dzMub3JnL0ludGVybmF0aW9uYWwNCg0KSW50ZXJuYXRpb25hbGl6YXRpb24gaXMgbm90IGEgZmVh dHVyZS4NCkl0IGlzIGFuIGFyY2hpdGVjdHVyZS4gDQoNCg0K --===============2090898316== 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 --===============2090898316==-- From ltru-bounces@lists.ietf.org Wed Jul 27 01:28:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxeSt-0008B1-Du; Wed, 27 Jul 2005 01:28:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxeSr-0008AN-Tr for ltru@megatron.ietf.org; Wed, 27 Jul 2005 01:28:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22215 for ; Wed, 27 Jul 2005 01:28:20 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxey1-0006oD-EQ for ltru@ietf.org; Wed, 27 Jul 2005 02:00:36 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 22:28:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Jul 2005 22:28:06 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C3F969F@irvmbxw01.quest.com> Thread-Topic: ... and a note about the matching draft... Thread-Index: AcWSa/KwXA5W4qPDSaucZoWcAltzgw== From: "Addison Phillips" To: "LTRU Working Group" X-OriginalArrivalTime: 27 Jul 2005 05:28:07.0338 (UTC) FILETIME=[F83620A0:01C5926B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [Ltru] ... and a note about the matching 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: , Content-Type: multipart/mixed; boundary="===============1164520712==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============1164520712== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBoYXZlbid0IHVwZGF0ZWQgaXQgeWV0LiBJJ2xsIGRvIHRoYXQgc29vbi4NCg0KQWRkaXNvbg0K DQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29m dHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkNoYWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6 YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRwOi8vd3d3LnczLm9yZy9JbnRlcm5hdGlvbmFs DQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBhIGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNo aXRlY3R1cmUuIA0KDQoNCg== --===============1164520712== 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 --===============1164520712==-- From ltru-bounces@lists.ietf.org Wed Jul 27 02:17:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxf8m-0001cG-Ai; Wed, 27 Jul 2005 02: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 1Dxf8f-0001YN-4E for ltru@megatron.ietf.org; Wed, 27 Jul 2005 02:11:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05099 for ; Wed, 27 Jul 2005 02:11:31 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxfdq-0007qp-VL for ltru@ietf.org; Wed, 27 Jul 2005 02:43:48 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dxf8Z-0003Xt-Qu; Tue, 26 Jul 2005 23:11:28 -0700 Message-Id: <6.2.1.2.2.20050727080725.037ca7e0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 27 Jul 2005 08:10:47 +0200 To: "Addison Phillips" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] ABNF beautification... In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C3F964D@irvmbxw01.quest.c om> References: <634978A7DF025A40BFEF33EB191E13BC0C3F964D@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 - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 For the records I oppose the exclusion ABNF for private use. At 02:13 27/07/2005, Addison Phillips wrote: >privateuse = ("x"/"X") 1*("-" (1*8alphanum)) >Any comments? Can I get a hum to use this in preference to draft-09's version? I note that Martin Duerst has not answered my mail explaining why this format is absurd. As long as he has not, this Last Call cannot be closed. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 27 02:17:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxf8m-0001cO-L0; Wed, 27 Jul 2005 02: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 1Dxf8h-0001YM-Cg for ltru@megatron.ietf.org; Wed, 27 Jul 2005 02:11:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05086 for ; Wed, 27 Jul 2005 02:11:30 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxfdq-0007qh-VH for ltru@ietf.org; Wed, 27 Jul 2005 02:43:47 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dxf8Y-0003Xt-BI; Tue, 26 Jul 2005 23:11:26 -0700 Message-Id: <6.2.1.2.2.20050727075302.03a500b0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 27 Jul 2005 08:10:59 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Last contribution - was: Action items on draft-initial? In-Reply-To: <001401c5923c$fa9ccbc0$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C3F93CF@irvmbxw01.quest.com> <00b401c59213$8c809c80$7f1afea9@oemcomputer> <6.2.1.2.2.20050726230551.046f9cd0@mail.afrac.org> <001401c5923c$fa9ccbc0$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 - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Randy, At 01:51 27/07/2005, Randy Presuhn wrote: >I haven't seen any indication that the document's sole editor (Doug) is >confused. >He asked for guidance, which is a perfectly reasonable thing for an editor >to do. I am glad to hear there is only one editor. BTW, would you mean Doug Ewell? >As for users, page 1 of >http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt says: > > This memo defines the initial contents of the Language Subtag > Registry for use in forming tags for the identification of languages. > Since the contents of this memo only serve as a starting point for > the registry, it is inappropriate to use this memo in lieu of the > registry. ??? Do you mean that the meaning of entries varies if it is read by someone or someone else? >Consequently, the IANA personnel initializing the registry are really >the only likely users of this document. Anyone else using it has gone >outside its express scope of application, and thus, from my point of >view, qualifies as "pre-confused". :-) Thanks to indicate the contempts for the users. IETF defines who an RFC user is. We already had "end users" and now "pre-confused users". When "post mortem users"? >You've raised these issues before. The rough consensus on how to handle >each was quite clear. You may, of course, appeal under the terms of RFC 2026 >section 6.5.1, and request that the AD direct us to discuss your requests >further. Thank you to make this statement. Just get prepared to explain how a few participating members make a rough consensus against practice and running code. And the hummings on these two points. You may recall that these are roughly the two points the preceding version of the Draft failed. And this one will also. I do not understand this so big desire of exclusive and exclusion to the point to kill your own work. Unless obviously you agree with me that this Draf hurts the Internet and want to see it die. > > I also repeat for clarity sake that the current commercial and Open Source > > projects or development I know of are based upon: > > > > 1. free format of x-tags (tags starting with the "x-" sequence) > > 2. ISO codes, by nature conforming or intending to conform with ISO 11179 > > (naming, updates, metadata, registry management, etc.) > > 3. referents and contexts defined by networked languages SDOs. > > 4. a determination to appeal to IESG, IANA, GAC, WSIS in the case this > > Draft was accepted as an RFC without the modification above. > > > > So, this WG-ltru cannot claim it ignored it, and that it does not purposely > > oppose users existing or intended practices and running code. > >Indeed, your comments have been discussed repeatedly and at excessive >length. In some cases, they have resulted in changes or clarifications. In >other cases, the WG's consensus has been to do something else. You may, >of course, appeal under the terms of RFC 2026 section 6.5.1. Thank you for this statement. It shows that you repeatedly decided to ignore and oppose reality. Thank you to note that in cases my allegded excessive length has eventually lead to changes and clarifications. > > I also want to call a last time on the members of this WG-ltru affinity > > group. Multilingualism, and Multilingual Internet, due to the positions of > > UNESCO, UN, WSIS, WGIG, MINC, EU, WIPO, USG, NICSO, etc. many States, > > cultural authorities, academic work, industry development, ccTLDs policy, > > local internet communities and ISOC Chapters, and recently Vint Cerf for > > ICANN, will increasingly be a matter of top consideration. Your intended > > use of the IANA registry, in the way you propose, without the > > considerations you refused or did not even discuss, will result into a > > disinterest by concerned lingual parties. This will also result from its > > exclusive ASCII basis, and of its deliberate decision of exclusion > > of x-tags. It will be considered as a political and commercial bias, and > > as a technically inadequate proposition. Should the IANA registry be really > > implemented and promoted, ISO based Open Source and other commercial, civil > > or public solutions will be made available, some as an open alternative to > > IANA servers. It would be likely that users would split: you would have > > dramatically cooperated to the balkanisation of the Internet. You, and the > > companies you represent, will get the resulting negative exposure: I am not > > sure this is what you and they want. I still wander why you want so much to > > harm the Internet, and to oppose their users? I find this sad. > > jfc > >Specific technical comments, especially those proposing specific replacement >text, are welcome. I proposed two replacements if you really want to propose that text. I am sorry we are to keep being opposed. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 27 02:44:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxfeS-0001TN-H4; Wed, 27 Jul 2005 02:44:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxfeQ-0001TB-GP for ltru@megatron.ietf.org; Wed, 27 Jul 2005 02:44:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01570 for ; Wed, 27 Jul 2005 02:44:20 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxg9c-0000Bw-42 for ltru@ietf.org; Wed, 27 Jul 2005 03:16:37 -0400 Received: from h-68-165-6-46.snvacaid.dynamic.covad.net ([68.165.6.46] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxfeN-0001n9-00 for ltru@ietf.org; Wed, 27 Jul 2005 02:44:19 -0400 Message-ID: <000801c59276$b3a10e40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C3F964D@irvmbxw01.quest.com> <6.2.1.2.2.20050727080725.037ca7e0@mail.afrac.org> Subject: Re: [Ltru] ABNF beautification... Date: Tue, 26 Jul 2005 23:44: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.1 (/) 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: , Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - > From: "r&d afrac" > To: "Addison Phillips" ; "LTRU Working Group" > Sent: Tuesday, July 26, 2005 11:10 PM > Subject: Re: [Ltru] ABNF beautification... > > For the records I oppose the exclusion ABNF for private use. > > At 02:13 27/07/2005, Addison Phillips wrote: > >privateuse = ("x"/"X") 1*("-" (1*8alphanum)) > >Any comments? Can I get a hum to use this in preference to draft-09's version? > > I note that Martin Duerst has not answered my mail explaining why this > format is absurd. > As long as he has not, this Last Call cannot be closed. Nonsense. Procedural questions can be addressed by either of the co-chairs or the AD. There is nothing that requires him personally to respond to any of your technical points; technical decisions are by the rough consensus of the WG. Your complaints about the syntax for private use (sub)tags have been discussed at length. If you believe that the co-chairs have mis-read the WG consensus, you may appeal to our AD. > jfc Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 27 03:06:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxg08-0006Pk-EZ; Wed, 27 Jul 2005 03:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxg06-0006Pe-UB for ltru@megatron.ietf.org; Wed, 27 Jul 2005 03:06:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02676 for ; Wed, 27 Jul 2005 03:06:44 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxgVJ-0000kg-L5 for ltru@ietf.org; Wed, 27 Jul 2005 03:39:02 -0400 Received: from h-68-165-6-46.snvacaid.dynamic.covad.net ([68.165.6.46] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dxg04-0005dK-00 for ltru@ietf.org; Wed, 27 Jul 2005 03:06:45 -0400 Message-ID: <000d01c59279$d61c3c80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <634978A7DF025A40BFEF33EB191E13BC0C3F93CF@irvmbxw01.quest.com> <00b401c59213$8c809c80$7f1afea9@oemcomputer> <6.2.1.2.2.20050726230551.046f9cd0@mail.afrac.org> <001401c5923c$fa9ccbc0$7f1afea9@oemcomputer> <6.2.1.2.2.20050727075302.03a500b0@mail.afrac.org> Subject: Re: [Ltru] Last contribution - was: Action items on draft-initial? Date: Wed, 27 Jul 2005 00:07: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.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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: "r&d afrac" > To: "Randy Presuhn" ; "LTRU Working Group" > Sent: Tuesday, July 26, 2005 11:10 PM > Subject: Re: [Ltru] Last contribution - was: Action items on draft-initial? > > Dear Randy, > > At 01:51 27/07/2005, Randy Presuhn wrote: > >I haven't seen any indication that the document's sole editor (Doug) is > >confused. > >He asked for guidance, which is a perfectly reasonable thing for an editor > >to do. > > I am glad to hear there is only one editor. BTW, would you mean Doug Ewell? I don't see any other editor listed in http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt and we certainly haven't named anyone else as editor. You *have* read it, haven't you? Or do you just ask to waste time? > >As for users, page 1 of > >http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt says: > > > > This memo defines the initial contents of the Language Subtag > > Registry for use in forming tags for the identification of languages. > > Since the contents of this memo only serve as a starting point for > > the registry, it is inappropriate to use this memo in lieu of the > > registry. > > ??? > Do you mean that the meaning of entries varies if it is read by someone or > someone else? No. Simply that it is inappropriate to use that memo in lieu of the registry. The only reason to publish it as an RFC at all is that that is the preferred mechanism for delivering this kind of information to IANA. The document is of almost no interest to anyone else. The paragraph I quoted makes this abundantly clear. > >Consequently, the IANA personnel initializing the registry are really > >the only likely users of this document. Anyone else using it has gone > >outside its express scope of application, and thus, from my point of > >view, qualifies as "pre-confused". :-) > > Thanks to indicate the contempts for the users. IETF defines who an RFC > user is. We already had "end users" and now "pre-confused users". When > "post mortem users"? I fail to see your point. Someone who cannot understand "it is inappropriate to use this memo in lieu of the registry" has no business poking around in RFCs. Someone who willfully uses it despite the warning is worse than "confused." > >You've raised these issues before. The rough consensus on how to handle > >each was quite clear. You may, of course, appeal under the terms of RFC 2026 > >section 6.5.1, and request that the AD direct us to discuss your requests > >further. > > Thank you to make this statement. Just get prepared to explain how a few > participating members make a rough consensus against practice and running > code. And the hummings on these two points. You may recall that these are > roughly the two points the preceding version of the Draft failed. And this > one will also. I do not understand this so big desire of exclusive and > exclusion to the point to kill your own work. Unless obviously you agree > with me that this Draf hurts the Internet and want to see it die. No. > > > I also repeat for clarity sake that the current commercial and Open Source > > > projects or development I know of are based upon: > > > > > > 1. free format of x-tags (tags starting with the "x-" sequence) > > > 2. ISO codes, by nature conforming or intending to conform with ISO 11179 > > > (naming, updates, metadata, registry management, etc.) > > > 3. referents and contexts defined by networked languages SDOs. > > > 4. a determination to appeal to IESG, IANA, GAC, WSIS in the case this > > > Draft was accepted as an RFC without the modification above. > > > > > > So, this WG-ltru cannot claim it ignored it, and that it does not purposely > > > oppose users existing or intended practices and running code. > > > >Indeed, your comments have been discussed repeatedly and at excessive > >length. In some cases, they have resulted in changes or clarifications. In > >other cases, the WG's consensus has been to do something else. You may, > >of course, appeal under the terms of RFC 2026 section 6.5.1. > > Thank you for this statement. It shows that you repeatedly decided to > ignore and oppose reality. Thank you to note that in cases my allegded > excessive length has eventually lead to changes and clarifications. > > > > I also want to call a last time on the members of this WG-ltru affinity > > > group. Multilingualism, and Multilingual Internet, due to the positions of > > > UNESCO, UN, WSIS, WGIG, MINC, EU, WIPO, USG, NICSO, etc. many States, > > > cultural authorities, academic work, industry development, ccTLDs policy, > > > local internet communities and ISOC Chapters, and recently Vint Cerf for > > > ICANN, will increasingly be a matter of top consideration. Your intended > > > use of the IANA registry, in the way you propose, without the > > > considerations you refused or did not even discuss, will result into a > > > disinterest by concerned lingual parties. This will also result from its > > > exclusive ASCII basis, and of its deliberate decision of exclusion > > > of x-tags. It will be considered as a political and commercial bias, and > > > as a technically inadequate proposition. Should the IANA registry be really > > > implemented and promoted, ISO based Open Source and other commercial, civil > > > or public solutions will be made available, some as an open alternative to > > > IANA servers. It would be likely that users would split: you would have > > > dramatically cooperated to the balkanisation of the Internet. You, and the > > > companies you represent, will get the resulting negative exposure: I am not > > > sure this is what you and they want. I still wander why you want so much to > > > harm the Internet, and to oppose their users? I find this sad. > > > jfc > > > >Specific technical comments, especially those proposing specific replacement > >text, are welcome. > > I proposed two replacements if you really want to propose that text. > I am sorry we are to keep being opposed. > jfc Randy _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 27 03:14:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxg7Z-0008AW-6H; Wed, 27 Jul 2005 03:14:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxg7X-0008AM-Gf for ltru@megatron.ietf.org; Wed, 27 Jul 2005 03:14: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 DAA03059 for ; Wed, 27 Jul 2005 03:14:25 -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 <20050727071355.VVQY29002.mta9.adelphia.net@DEWELL> for ; Wed, 27 Jul 2005 03:13:55 -0400 Message-ID: <001a01c5927a$9d522940$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Wed, 27 Jul 2005 00:12: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 Cc: Subject: [Ltru] New editor's copy of draft-initial-03 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 A new editor's copy of draft-ietf-ltru-initial-03 is now available: http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-03.txt http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-03.html http://users.adelphia.net/~dewell/draft-ietf-ltru-initial-03.xml This version includes changes to the wording of the references to the ISO and UN standards, as well as the "Galician" name change and all other changes previously accepted for this 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@lists.ietf.org Wed Jul 27 03:41:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxgXH-0005af-Pv; Wed, 27 Jul 2005 03:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxgXG-0005aa-5C for ltru@megatron.ietf.org; Wed, 27 Jul 2005 03:41:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04440 for ; Wed, 27 Jul 2005 03:40:59 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxh2S-0001vq-UR for ltru@ietf.org; Wed, 27 Jul 2005 04:13:17 -0400 Received: from h-68-165-6-46.snvacaid.dynamic.covad.net ([68.165.6.46] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1DxgX8-0003Zt-00 for ltru@ietf.org; Wed, 27 Jul 2005 03:40:55 -0400 Message-ID: <006901c5927e$9d0aea40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" References: <6.2.1.2.2.20050719231610.05809220@pop.online.fr> <6.0.0.20.2.20050720180904.07e45b10@itmail.it.aoyama.ac.jp> <6.2.1.2.2.20050722112811.05c9d780@mail.afrac.org> Date: Wed, 27 Jul 2005 00:41:34 -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.2 (++) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 Cc: Subject: [Ltru] [psg.com #1072] compatibility and private use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Hi - Has anyone been persuaded by Jefsey's arguments that we need to re-open the discussion of private-use (sub)tag syntax and compatibility? Unless there is support for re-examining this decision, I believe it is in the best interest of timely completion of our work to leave this issue closed. Randy, ltru co-chair ----- Original Message ----- > From: "r&d afrac" > To: "Martin Duerst" ; "Randy Presuhn" ; > Sent: Friday, July 22, 2005 8:21 AM > Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN disclaimer > > Dear Martin, > I will try to address this serious mail as seriously as possible. I am on > vacations with many family things around. > > At 03:44 22/07/2005, Martin Duerst wrote: > >[chair hat on] > >Randy is right. "DISCUSS" refers to a very specific part of the process, > >in particular to questions, comments or requests some members of the IESG > >may have on the draft. This is recorded as a "DISCUSS" in the draft tracker > >(see https://datatracker.ietf.org/public/pidtracker.cgi). > > We fully agree. The point I rise is a serious point. We are to accept > external codes and _mix_ them (ISO 3166/UN M.49) in an area sensible to > every government, except may be the USG. Some pointed out there is no > Culture Ministry in the USG), and in several English language countries. > Members of this WG should understand and accept that in some countries > language is considered as _the_ culture, to the point citizens may consider > anything concerning their language without their due approval as real a act > of physical war, in cases calling possibly for personal physical > retaliation and terror (all the more if they consider it as part of what is > named "e-colonisation"). We have to take into account this full spectrum of > understanding of what this WG [mainly composed of English mother tongue > people] considers. I would underline that the matter of the debates of this > WG are quite unconceivable in a French speaking environment. > > I think this kind of concern is not a concern for a WG. But it is the > concern of a WG to inform IESG of the problem. What I say (considering the > Internet standard process spirit/letter) is there are two solutions: > > - to propose a text in the hope IESG marks it for DISCUSS. > - to report in the text that the identified problem goes beyond the > Charter, and that we identified it should be treated somewhere else. > > In the first case we run into the risk that our text is accepted and serves > further on as an IETF position. Out of luck, our proposition could be a > good one. But it is likely, even if we do our best, it would not be a good > one as this is a pretty complex one and we are neither lawyers nor > international diplomats. > > The second one is IMHO the most loyal to the IESG. Because the IESG can > decide to accept our point and mark it for DISCUSS, or disagree with us and > remove it. > > Ideally, the solution would be my reading of the charter: to address all > the issue through a global framework for the whole internet, truly > correcting and replacing RFC 3066 and then presenting the ABNF and filters > of this particular case in a technical RFC. > > > >The WG is expected to send the draft(s) to the AD and the IESG ***in the best > >possible fashion***, after having done everything they think is necessary. > >If we asa WG come to (rough) consensus that some "political disclaimer" or > >whatever we may call it is necessary, then we should make our best efforts > >to get the best possible text. > > See above. This is a solution. This is the one I initially advocated for, > trying to interest Gov officials, ISO people, Language structures, UNESCO, > etc. etc. The answer I received from everywhere is "we are not interested > in this commercial trick, IETF means nothing to us in that area, their > proposition is absurd and will not fly. Thank you to keep us posted so we > know where, how and when to kill it". > > I think it is not a proper answer. Because it is premature to kill the > IETF, even if it stays the way it is (RFC 3774). The IETF is also a place > to protect the technology from all these people: nothing will happen on the > Internet except through IETF and Open Source and Open Source is not ready > in terms of network architecture. So I tried to keep an equilibrium, for > example with the WGIG, which partly follows some of my points. > > But there are two main points the WGIG - and this WG - are wrong about: > > 1. the WGIG places the Internet R&D in private sector, as the WG does in > mainly relying on Unicode and W3C private commercial consortia. IAB RFC > 3869 clearly says (its "main thesis") that if this is the case the > architectural R&D of the internet is "in trouble". I can only confirm that: > I try to keep (at my family expense, as do others on this list or near-by) > myself near but financially free from Govs and as much as possible > grassroots and non-profit as I can, for free technical thinking and > development. This WG only produced a short minded, non scalable, excluding > solution (I will document this briefly further on). > > 2. The WGIG (and this WG does not even do that), considers multilingualism > as DNS and content (this WG excludes DNS what is a grave error, because it > confuses IETF's IDN mistake with multilingual DNS. Vint Cerf just > identified that mistake, put the blame on IETF, and calls for work on the > matter. He starts from phishing which cannot unfortunately be addressed > without changing the proposition, what will call for a change in the > architecture of the Internet. So not a little thing. > > But the main issue for us as a WG is that language is not the same issue > when a spoken language for mobiles (reason why mobiles develop far faster > than the Internet) or when text content for linguists, library and language > industry. Languages in the IETF must be understood as what IETF considers: > protocols. > > These person to person interintelligibility protocols involve R&D issues > this WG (financed by commercial interest) has not even alluded to. The > result is that a Draft about languages identification does not identify > itself what it considers as a language. I have no objection to the idea of > standardising the commercial tag of languages, to the contrary. But you do > not start from the price tag of the members of dominant consortium, as an > R&D specs for the whole deliverable. > > >If some IESG members then think that this > >has to be changed, they will raise a "DISCUSS". But going to the IESG > >with a draft that says something like "IESG, for this section, please > >do the work we were supposed to do" isn't an option. > > To do a work we are not supposed, we have not the competence and we have > not the authority to do is not an option. It would be a error and if we > make believe it would be a disloyalty. Unless you think you have the > necessary authority to relate with the IESG liaisons with ISO, IANA, GAC, > ccTLDs, UNESCO, UN, etc. and actually engage in it. In which case I would > certainly support you > > I will take an example of the difficulty: as a ccTLD (supposed to pay the > IANA, trustee of a national community, advisor of the Gov - in a country > where the culture Minister is also the Minister for ICT) and as the > secretary of an independent intergovernmental, interccTLD, inter-national > Internet communities think tank, and as a Member of the ccTLD committee for > the Luxembourg ccTLD meeting, I invited Brian Carpenter to come and > introduce the way IETF would consider a liaison with ccTLDs. You may recall > that my call to Greek and Chinese ccTLD Managers on ietf > -languages@alvestrand.no shown the interest and the political need. Brian's > answer was roughly (published in my presentation) "I considered with IAB. > We have nothing to discuss with you. However if there are specific topics, > please go through ADs" (two Govs I copied the mail asked "what is an AD", > showing the relational/cultural divide. > > Then came the US Statement of principles and then the WGIG, and then Vint > Cerf which followed in confirming the need and actually supporting my > proposition to ccTLDs of an INTF. A TF to structure that relation speaking > user on one side and IETF on the other. And of an UNITRY test bed (along > ICANN criteria), I am working on, with the support of already a few > developing/non developing countries. > > Our role is not to replace IESG, but our job is not either to fool the IESG. > > >If the WG comes to the (rough) consensus that it's better NOT to have a > >"political disclaimer", then we submit a draft without a "political > >disclaimer". > >If somebody on the IESG thinks that this is a problem, then they will > >raise a "DISCUSS". If the WG and the IESG then can't agree, the IESG > >can request the RFC Editor to attach an "IESG Note" (see e.g. > >http://www.ietf.org/rfc/rfc2251.txt). > > > >Up to this point, everything I have seen from the members of this WG > >strongly indicate that we have (rough) consensus to NOT have a > >"political disclaimer". > > This WG is not competent on the matter. For two reasons: > - this is not its charter. > - the consensus is by exhaustion. > > Anyway the problem is not the way you, me, IETF sees the things. The > problem is the way the concerned external parties see them. Inquire by > yourself. > > > >Since you do not want to call a debate on "complement RFC 3066" rather > > of "replace RFC 3066", and do not want to consider the Charter issues in > > the WG, it seems you want them discussed in the brouhaha of the IESG Last Call. > > > >First, it's not sure the IESG Last Call will create a brouhaha. > >Many IESG Last Calls go by without much discussion. This one may, > >or it may not. > > This depends essentially on the "complements/replaces" > > >Also, as Randy has said (repeatedly), the Charter is up for debate after > >we have done our work. IETF WGs don't start their work by a charter > >debate; if this was ever done in the past, it was abandoned because > >it would be very unproductive. > > Here I am lost. I though Randy was using this "after we have done our work" > as a delaying joke. Now you repeat it, I must consider you say seriously > that an IETF WG (and this is your intent in this case) is to commonly > understand the work to achieve in common once that work has been done? This > is not exactly my own experience of IETF WG, but I am to say that the few I > shared in have not been successes... This may the reason why? > > It rings Alice in Wonderlands to me. But if you say it is the way WG > proceeds ... I would then be interested in getting a calendar and a > procedure. When are you going to send a mail with a subject like "let > understand the work we had to do"? > > > >This may give more support to the proposed additions by more > > legal/political oriented people. I will not oppose this due to the very > > reduced number of participants to the WG Last Call. But beware that if > > the document is not mended during the last call, this will probably lead > > the document to be rejected at some stage (IESG Last Call, IANA, etc.). > > > >If it turns out, during IETF Last Call, that there is a preference for > >a "political disclaimer", and if the WG, the AD, and the IESG agree > >to some kind of wording, such a "political disclaimer" can be added > >at IESG Last Call. In my judgement, this would in no way mean we would > >need to have a second IETF Last Call, or that the IETF Last Call would > >have to fail, because the political language that would be added would > >most probably not change any of the technical provisions of the draft > >nor should it change any other aspects such as registry operation.* > > I feel you read me incompletely. I say that the document will fail at some > stage. If the concerned parties want to pay attention to the IETF (and this > is my prayer, so we can preserve the Internet standard process credibility > in the Multilingual field) they will attend the IETF last call and the > Draft will be killed there (what would be sad, since it could fly as a > complement). Or it will more likely (I am not going to spend my life > fighting an ill fitting Draft) be diplomatically killed at IANA level. The > procedure has been already engaged. > > > >As it is, it focuses on an resticted approach, aiming an exclusive for > > the language industry, against competitive open sources multilingual > > network oriented propositions and evolutions. > > > >[with my chair hat off] > >It is quite clear that the current draft tries to address the needs of what > >you call the "language industry", because people from this industry came > >forward with actual needs, and worked hard on solutions. > > Here is the confusion. Some people of the language industry came forwards > with this proposition. No the industry. I represent another part (less > dominant but more pervasive) of this industry. The way they are treated on > ietf-languages@alvestrand.no or on this WG (as F. Charles was) did not > pushed them to continue. I commentd already the question of Randy on this > matter, my response and the support I got. > > There are others who worked hard, I would even say harder and have a much > broader vision and support, you totally disregard. So we agreed (and I > documented) that we will only proceed outside of this WG - leaving you > enjoy your format and using the "x-" compatible escape sequence. We think > it is better to compromise and show usage, running code, etc. demonstrate > our open position is better, and to expose the bias of the proposed > exclusion. We got our "no way" excluding response. > > This is why, I am probably the only one concerned still considering that > the proposition of this WG may have merits, if not exclusive and excluding > (at least to satisfy the part of the industry you refer to). I also think > that coexistence is far better than opposition. > > If I am considered here as the bad guy against the Draft, and outside as > the bad guy or the traitor defending the Draft ... > > >It is in my view completely wrong to claim that the draft is exclusive. > >Indeed, while in RFC 3066, the only way to add language tags was by > >one-by-one registration, and there were no private subtags, the current > >draft is way more flexible and extensible. > > I am afraid you miss the point here. RFC 3066 is a wrong solution > (sometimes named "yellow star" RFC). People were shocked by the timely (was > it needed, or unfortunate?) registration of Chinese new tags by > ietf-languages@alvestrand.no (according to the non approved Draft format) > just before the Yahoo, Microsoft and Google announcement. This lead this > RFC 3066 Bis to be qualified of a "linguistic Yalta". > > 1. I note that you say "there were no private subtags", while other says > 1*8alphanum because compatibility with then must be maintained. > 2. No one is really interested in the RFC 3066 format and registry, except > the Unicode consortium people. No problem with that. The proposed system > "flexibility and extensibility" (I am not convinced of, in your own > perspective due to the unclear process and ISO relations) is perceived as a > way to control far more the things than before. > > >A recent example was language tags for different school grade levels. > >With RFC3066, you would have had to register en-grade1, en-us-grade1, > >en-gb-grade1, and so on. Now, you could (after some discussion) just > >register grade1 through grade6 (on more), and it could be applied to > >all kinds of languages, wherever it made sense. > > Thank you for this example: did you ever consider that "gradeN" is > meaningless for most outside of your world and that even then, 1 to 6 may > be meaningless as there may be more grades and in different order? We do > not want that kind of registry. We want to be ISO 11179 compatible when a > registry is really to be considered. > > > >We only oppose the exclusive, the exclusion and the lack of scalability, > > flexibility, capacity for innovation and evolution. > > > >Except for purely superficial syntactical issues such as subtag length,..., > > "superficial syntactical issues" .... I love it. You will be permitted to > have every name you want if it is less than 9 characters long, is in ASCII > and does not include anything else than 0-Z characters. Look how liberal I am? > > >I haven't seen any evidence from you (or from others) that the current > >draft lacks scalability, flexibility, extensibility, or capacity for > >innovation. > > I suppose you believe it! So I will give you some hint. > > "x-1*8alphanum" is supposed to support all the private subtags in a non > conflicting way. Let consider that one gives every user a different number > to permit them to differentiate their private subtags. With a billion > Internet users, we cannot even give a full subtag to all: 9 numerics are > needed. > > Let try to explain people that a cookie name can only be 8alphanum long. > Try to authenticate a private subtag using an MD5 key, etc. > > A full format for a commercial propositions, 8 alphanums for Open Source, > Networking, etc. > > >It would be good if you could document some actual (not superficial) > >cases of how the draft does that. As I said above, there is serious > >evidence in the draft that it actually does the contrary: It greatly > >increases scalability, flexibility, capacity for innovation and > >evolution. > > No. It greatly increases scalability, flexibility, capacity for language > control and evolution reduction to the profit of a dominant part of the > commercial language tools industry, because of its exclusive. > > If the Draft is a complement of RFC 3066 and permits undefined content of > the "x-tags", permitting every other format to develop and be supported we > will wind up in a totally acceptable coexistence situation where a > "xlang:xxx" is an RFC 3066 retro compatible solution and " supports > all the others. It will then be up to the grassroots process to adapt. IMHO > (this is what I feel could be a possible stabilisation) "x-abc:xxxx" would > be a good approach where "abc" is a freely used scheme we could relate to > CRC format names. This means that x-3066:en-Latn-UK could be a legitimate > format, also entered in places like "xlang:en-Latn-UK". > > Obviously, x-tags can support other features the Draft cannot such as > multilingual entries (via double indexation: entries use a reference number > documented by multilingual grids), ISO 11179 intended compatibility > supporting locales, MLDN charsets, referent directories, context additions, > CRCs, etc. ... and as documented Addison and Mark's Draft with their own > default format and registry. > > jfc > _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 27 04:17:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxh1J-0005dr-4F; Wed, 27 Jul 2005 04:12:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxh1I-0005dm-96 for ltru@megatron.ietf.org; Wed, 27 Jul 2005 04:12:04 -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 EAA06459 for ; Wed, 27 Jul 2005 04:12:01 -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 <20050727081133.PSTQ24042.mta11.adelphia.net@DEWELL> for ; Wed, 27 Jul 2005 04:11:33 -0400 Message-ID: <001f01c59282$91bb4460$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050727074420.MYZH29598.mta4.adelphia.net@megatron.ietf.org> Date: Wed, 27 Jul 2005 01:09:52 -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: [psg.com #1072] compatibility and private use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Randy Presuhn wrote: > Has anyone been persuaded by Jefsey's arguments that we need to > re-open the discussion of private-use (sub)tag syntax and > compatibility? Unless there is support for re-examining this > decision, I believe it is in the best interest of timely completion > of our work to leave this issue closed. I am not persuaded. Compatibility with the existing RFC 3066 syntax, which permitted only A-Z and 0-9 and hyphen, is important. The use of full stop (period, dot) and other characters in language tags has never been authorized by even the most liberal reading of RFC 3066. The mechanism described in the current draft allows for private-use tags and subtags of infinite length, a degree of flexibility provided by few other standards and protocols. We have discussed these arguments and reached a decision; let us move 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@lists.ietf.org Wed Jul 27 05:01:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxhnF-0001o7-A7; Wed, 27 Jul 2005 05:01:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxhnD-0001o2-Lg for ltru@megatron.ietf.org; Wed, 27 Jul 2005 05:01:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09195 for ; Wed, 27 Jul 2005 05:01:32 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxiIO-0004Z7-C6 for ltru@ietf.org; Wed, 27 Jul 2005 05:33:51 -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 j6R91CpX007513; Wed, 27 Jul 2005 12:01:14 +0300 (EEST) Message-ID: <42E74D59.6050500@kotus.fi> Date: Wed, 27 Jul 2005 12:01:13 +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: Randy Presuhn Subject: Re: [Ltru] [psg.com #1072] compatibility and private use tags References: <6.2.1.2.2.20050719231610.05809220@pop.online.fr> <6.0.0.20.2.20050720180904.07e45b10@itmail.it.aoyama.ac.jp> <6.2.1.2.2.20050722112811.05c9d780@mail.afrac.org> <006901c5927e$9d0aea40$7f1afea9@oemcomputer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by suomi.kotus.fi id j6R91CpX007513 X-Spam-Score: 2.1 (++) X-Scan-Signature: 3d48d865303330c98a6e90d450cf2ff2 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 I'd support the notion to leave this issue closed for this WG. We=20 urgently need to provide the user community with a reasonably good,=20 working solution now. Nothing prevents that solution from being improved=20 at a later stage, provided that there will be an agreement on how. If at=20 some point of time some other kind of an expanded solution would be=20 convincingly demonstrated to provide real benefits over what can be=20 achieved with the present one, the task to re-examine the decision could=20 be assigned to some (other) group at that time. (Incidentally, for Jefsey's information: My mother tongue is Finnish,=20 and I come from a country with several recognized minority languages.=20 The Research Institute for the Languages of Finland supports also=20 Swedish, the three S=E1mi languages spoken in Finland - Northern S=E1mi=20 (also spoken in Norway and Sweden), Inari S=E1mi and Skolt S=E1mi - and=20 Romani as spoken in Finland plus the Finnish sign language(s). RILF also=20 works with other languages, e.g. Carelian.) Sincerely, Erkki I. Kolehmainen Coordinator, Cultural Diversity Issues in ICT Research Institute for the Languages of Finland (RILF) Randy Presuhn wrote: > Hi - >=20 > Has anyone been persuaded by Jefsey's arguments that we need to > re-open the discussion of private-use (sub)tag syntax and compatibility= ? > Unless there is support for re-examining this decision, I believe it is > in the best interest of timely completion of our work to leave this iss= ue closed. >=20 > Randy, ltru co-chair >=20 > ----- Original Message -----=20 >=20 >>From: "r&d afrac" >>To: "Martin Duerst" ; "Randy Presuhn" ; >>Sent: Friday, July 22, 2005 8:21 AM >>Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of theUN= disclaimer >> >>Dear Martin, >>I will try to address this serious mail as seriously as possible. I am = on >>vacations with many family things around. >> >>At 03:44 22/07/2005, Martin Duerst wrote: >> >>>[chair hat on] >>>Randy is right. "DISCUSS" refers to a very specific part of the proces= s, >>>in particular to questions, comments or requests some members of the I= ESG >>>may have on the draft. This is recorded as a "DISCUSS" in the draft tr= acker >>>(see https://datatracker.ietf.org/public/pidtracker.cgi). >>> >>We fully agree. The point I rise is a serious point. We are to accept >>external codes and _mix_ them (ISO 3166/UN M.49) in an area sensible to >>every government, except may be the USG. Some pointed out there is no >>Culture Ministry in the USG), and in several English language countries. >>Members of this WG should understand and accept that in some countries >>language is considered as _the_ culture, to the point citizens may cons= ider >>anything concerning their language without their due approval as real a= act >>of physical war, in cases calling possibly for personal physical >>retaliation and terror (all the more if they consider it as part of wha= t is >>named "e-colonisation"). We have to take into account this full spectru= m of >>understanding of what this WG [mainly composed of English mother tongue >>people] considers. I would underline that the matter of the debates of = this >>WG are quite unconceivable in a French speaking environment. >> >>I think this kind of concern is not a concern for a WG. But it is the >>concern of a WG to inform IESG of the problem. What I say (considering = the >>Internet standard process spirit/letter) is there are two solutions: >> >>- to propose a text in the hope IESG marks it for DISCUSS. >>- to report in the text that the identified problem goes beyond the >>Charter, and that we identified it should be treated somewhere else. >> >>In the first case we run into the risk that our text is accepted and se= rves >>further on as an IETF position. Out of luck, our proposition could be a >>good one. But it is likely, even if we do our best, it would not be a g= ood >>one as this is a pretty complex one and we are neither lawyers nor >>international diplomats. >> >>The second one is IMHO the most loyal to the IESG. Because the IESG can >>decide to accept our point and mark it for DISCUSS, or disagree with us= and >>remove it. >> >>Ideally, the solution would be my reading of the charter: to address al= l >>the issue through a global framework for the whole internet, truly >>correcting and replacing RFC 3066 and then presenting the ABNF and filt= ers >>of this particular case in a technical RFC. >> >> >> >>>The WG is expected to send the draft(s) to the AD and the IESG ***in t= he best >>>possible fashion***, after having done everything they think is necess= ary. >>>If we asa WG come to (rough) consensus that some "political disclaimer= " or >>>whatever we may call it is necessary, then we should make our best eff= orts >>>to get the best possible text. >>> >>See above. This is a solution. This is the one I initially advocated fo= r, >>trying to interest Gov officials, ISO people, Language structures, UNES= CO, >>etc. etc. The answer I received from everywhere is "we are not interest= ed >>in this commercial trick, IETF means nothing to us in that area, their >>proposition is absurd and will not fly. Thank you to keep us posted so = we >>know where, how and when to kill it". >> >>I think it is not a proper answer. Because it is premature to kill the >>IETF, even if it stays the way it is (RFC 3774). The IETF is also a pla= ce >>to protect the technology from all these people: nothing will happen on= the >>Internet except through IETF and Open Source and Open Source is not rea= dy >>in terms of network architecture. So I tried to keep an equilibrium, fo= r >>example with the WGIG, which partly follows some of my points. >> >>But there are two main points the WGIG - and this WG - are wrong about: >> >>1. the WGIG places the Internet R&D in private sector, as the WG does i= n >>mainly relying on Unicode and W3C private commercial consortia. IAB RFC >>3869 clearly says (its "main thesis") that if this is the case the >>architectural R&D of the internet is "in trouble". I can only confirm t= hat: >>I try to keep (at my family expense, as do others on this list or near-= by) >>myself near but financially free from Govs and as much as possible >>grassroots and non-profit as I can, for free technical thinking and >>development. This WG only produced a short minded, non scalable, exclud= ing >>solution (I will document this briefly further on). >> >>2. The WGIG (and this WG does not even do that), considers multilingual= ism >>as DNS and content (this WG excludes DNS what is a grave error, because= it >>confuses IETF's IDN mistake with multilingual DNS. Vint Cerf just >>identified that mistake, put the blame on IETF, and calls for work on t= he >>matter. He starts from phishing which cannot unfortunately be addressed >>without changing the proposition, what will call for a change in the >>architecture of the Internet. So not a little thing. >> >>But the main issue for us as a WG is that language is not the same issu= e >>when a spoken language for mobiles (reason why mobiles develop far fast= er >>than the Internet) or when text content for linguists, library and lang= uage >>industry. Languages in the IETF must be understood as what IETF conside= rs: >>protocols. >> >>These person to person interintelligibility protocols involve R&D issue= s >>this WG (financed by commercial interest) has not even alluded to. The >>result is that a Draft about languages identification does not identify >>itself what it considers as a language. I have no objection to the idea= of >>standardising the commercial tag of languages, to the contrary. But you= do >>not start from the price tag of the members of dominant consortium, as = an >>R&D specs for the whole deliverable. >> >> >>>If some IESG members then think that this >>>has to be changed, they will raise a "DISCUSS". But going to the IESG >>>with a draft that says something like "IESG, for this section, please >>>do the work we were supposed to do" isn't an option. >>> >>To do a work we are not supposed, we have not the competence and we hav= e >>not the authority to do is not an option. It would be a error and if we >>make believe it would be a disloyalty. Unless you think you have the >>necessary authority to relate with the IESG liaisons with ISO, IANA, GA= C, >>ccTLDs, UNESCO, UN, etc. and actually engage in it. In which case I wou= ld >>certainly support you >> >>I will take an example of the difficulty: as a ccTLD (supposed to pay t= he >>IANA, trustee of a national community, advisor of the Gov - in a countr= y >>where the culture Minister is also the Minister for ICT) and as the >>secretary of an independent intergovernmental, interccTLD, inter-nation= al >>Internet communities think tank, and as a Member of the ccTLD committee= for >>the Luxembourg ccTLD meeting, I invited Brian Carpenter to come and >>introduce the way IETF would consider a liaison with ccTLDs. You may re= call >>that my call to Greek and Chinese ccTLD Managers on ietf >>-languages@alvestrand.no shown the interest and the political need. Bri= an's >>answer was roughly (published in my presentation) "I considered with IA= B. >>We have nothing to discuss with you. However if there are specific topi= cs, >>please go through ADs" (two Govs I copied the mail asked "what is an AD= ", >>showing the relational/cultural divide. >> >>Then came the US Statement of principles and then the WGIG, and then Vi= nt >>Cerf which followed in confirming the need and actually supporting my >>proposition to ccTLDs of an INTF. A TF to structure that relation speak= ing >>user on one side and IETF on the other. And of an UNITRY test bed (alon= g >>ICANN criteria), I am working on, with the support of already a few >>developing/non developing countries. >> >>Our role is not to replace IESG, but our job is not either to fool the = IESG. >> >> >>>If the WG comes to the (rough) consensus that it's better NOT to have = a >>>"political disclaimer", then we submit a draft without a "political >>>disclaimer". >>>If somebody on the IESG thinks that this is a problem, then they will >>>raise a "DISCUSS". If the WG and the IESG then can't agree, the IESG >>>can request the RFC Editor to attach an "IESG Note" (see e.g. >>>http://www.ietf.org/rfc/rfc2251.txt). >>> >>>Up to this point, everything I have seen from the members of this WG >>>strongly indicate that we have (rough) consensus to NOT have a >>>"political disclaimer". >>> >>This WG is not competent on the matter. For two reasons: >>- this is not its charter. >>- the consensus is by exhaustion. >> >>Anyway the problem is not the way you, me, IETF sees the things. The >>problem is the way the concerned external parties see them. Inquire by >>yourself. >> >> >>>>Since you do not want to call a debate on "complement RFC 3066" rathe= r >>>> >>>of "replace RFC 3066", and do not want to consider the Charter issues= in >>>the WG, it seems you want them discussed in the brouhaha of the IESG L= ast Call. >>> >>>First, it's not sure the IESG Last Call will create a brouhaha. >>>Many IESG Last Calls go by without much discussion. This one may, >>>or it may not. >>> >>This depends essentially on the "complements/replaces" >> >> >>>Also, as Randy has said (repeatedly), the Charter is up for debate aft= er >>>we have done our work. IETF WGs don't start their work by a charter >>>debate; if this was ever done in the past, it was abandoned because >>>it would be very unproductive. >>> >>Here I am lost. I though Randy was using this "after we have done our w= ork" >>as a delaying joke. Now you repeat it, I must consider you say seriousl= y >>that an IETF WG (and this is your intent in this case) is to commonly >>understand the work to achieve in common once that work has been done? = This >>is not exactly my own experience of IETF WG, but I am to say that the f= ew I >>shared in have not been successes... This may the reason why? >> >>It rings Alice in Wonderlands to me. But if you say it is the way WG >>proceeds ... I would then be interested in getting a calendar and a >>procedure. When are you going to send a mail with a subject like "let >>understand the work we had to do"? >> >> >>>>This may give more support to the proposed additions by more >>>> >>>legal/political oriented people. I will not oppose this due to the ver= y >>>reduced number of participants to the WG Last Call. But beware that if >>>the document is not mended during the last call, this will probably le= ad >>>the document to be rejected at some stage (IESG Last Call, IANA, etc.). >>> >>>If it turns out, during IETF Last Call, that there is a preference for >>>a "political disclaimer", and if the WG, the AD, and the IESG agree >>>to some kind of wording, such a "political disclaimer" can be added >>>at IESG Last Call. In my judgement, this would in no way mean we would >>>need to have a second IETF Last Call, or that the IETF Last Call would >>>have to fail, because the political language that would be added would >>>most probably not change any of the technical provisions of the draft >>>nor should it change any other aspects such as registry operation.* >>> >>I feel you read me incompletely. I say that the document will fail at s= ome >>stage. If the concerned parties want to pay attention to the IETF (and = this >>is my prayer, so we can preserve the Internet standard process credibil= ity >>in the Multilingual field) they will attend the IETF last call and the >>Draft will be killed there (what would be sad, since it could fly as a >>complement). Or it will more likely (I am not going to spend my life >>fighting an ill fitting Draft) be diplomatically killed at IANA level. = The >>procedure has been already engaged. >> >> >>>>As it is, it focuses on an resticted approach, aiming an exclusive fo= r >>>> >>>the language industry, against competitive open sources multilingual >>>network oriented propositions and evolutions. >>> >>>[with my chair hat off] >>>It is quite clear that the current draft tries to address the needs of= what >>>you call the "language industry", because people from this industry ca= me >>>forward with actual needs, and worked hard on solutions. >>> >>Here is the confusion. Some people of the language industry came forwar= ds >>with this proposition. No the industry. I represent another part (less >>dominant but more pervasive) of this industry. The way they are treated= on >>ietf-languages@alvestrand.no or on this WG (as F. Charles was) did not >>pushed them to continue. I commentd already the question of Randy on th= is >>matter, my response and the support I got. >> >>There are others who worked hard, I would even say harder and have a mu= ch >>broader vision and support, you totally disregard. So we agreed (and I >>documented) that we will only proceed outside of this WG - leaving you >>enjoy your format and using the "x-" compatible escape sequence. We thi= nk >>it is better to compromise and show usage, running code, etc. demonstra= te >>our open position is better, and to expose the bias of the proposed >>exclusion. We got our "no way" excluding response. >> >>This is why, I am probably the only one concerned still considering tha= t >>the proposition of this WG may have merits, if not exclusive and exclud= ing >>(at least to satisfy the part of the industry you refer to). I also thi= nk >>that coexistence is far better than opposition. >> >>If I am considered here as the bad guy against the Draft, and outside a= s >>the bad guy or the traitor defending the Draft ... >> >> >>>It is in my view completely wrong to claim that the draft is exclusive. >>>Indeed, while in RFC 3066, the only way to add language tags was by >>>one-by-one registration, and there were no private subtags, the curren= t >>>draft is way more flexible and extensible. >>> >>I am afraid you miss the point here. RFC 3066 is a wrong solution >>(sometimes named "yellow star" RFC). People were shocked by the timely = (was >>it needed, or unfortunate?) registration of Chinese new tags by >>ietf-languages@alvestrand.no (according to the non approved Draft forma= t) >>just before the Yahoo, Microsoft and Google announcement. This lead thi= s >>RFC 3066 Bis to be qualified of a "linguistic Yalta". >> >>1. I note that you say "there were no private subtags", while other say= s >>1*8alphanum because compatibility with then must be maintained. >>2. No one is really interested in the RFC 3066 format and registry, exc= ept >>the Unicode consortium people. No problem with that. The proposed syste= m >>"flexibility and extensibility" (I am not convinced of, in your own >>perspective due to the unclear process and ISO relations) is perceived = as a >>way to control far more the things than before. >> >> >>>A recent example was language tags for different school grade levels. >>>With RFC3066, you would have had to register en-grade1, en-us-grade1, >>>en-gb-grade1, and so on. Now, you could (after some discussion) just >>>register grade1 through grade6 (on more), and it could be applied to >>>all kinds of languages, wherever it made sense. >>> >>Thank you for this example: did you ever consider that "gradeN" is >>meaningless for most outside of your world and that even then, 1 to 6 m= ay >>be meaningless as there may be more grades and in different order? We d= o >>not want that kind of registry. We want to be ISO 11179 compatible when= a >>registry is really to be considered. >> >> >>>>We only oppose the exclusive, the exclusion and the lack of scalabili= ty, >>>> >>>flexibility, capacity for innovation and evolution. >>> >>>Except for purely superficial syntactical issues such as subtag length= ,..., >>> >>"superficial syntactical issues" .... I love it. You will be permitted = to >>have every name you want if it is less than 9 characters long, is in AS= CII >>and does not include anything else than 0-Z characters. Look how libera= l I am? >> >> >>>I haven't seen any evidence from you (or from others) that the current >>>draft lacks scalability, flexibility, extensibility, or capacity for >>>innovation. >>> >>I suppose you believe it! So I will give you some hint. >> >>"x-1*8alphanum" is supposed to support all the private subtags in a non >>conflicting way. Let consider that one gives every user a different num= ber >>to permit them to differentiate their private subtags. With a billion >>Internet users, we cannot even give a full subtag to all: 9 numerics ar= e >>needed. >> >>Let try to explain people that a cookie name can only be 8alphanum long. >>Try to authenticate a private subtag using an MD5 key, etc. >> >>A full format for a commercial propositions, 8 alphanums for Open Sourc= e, >>Networking, etc. >> >> >>>It would be good if you could document some actual (not superficial) >>>cases of how the draft does that. As I said above, there is serious >>>evidence in the draft that it actually does the contrary: It greatly >>>increases scalability, flexibility, capacity for innovation and >>>evolution. >>> >>No. It greatly increases scalability, flexibility, capacity for languag= e >>control and evolution reduction to the profit of a dominant part of the >>commercial language tools industry, because of its exclusive. >> >>If the Draft is a complement of RFC 3066 and permits undefined content = of >>the "x-tags", permitting every other format to develop and be supported= we >>will wind up in a totally acceptable coexistence situation where a >>"xlang:xxx" is an RFC 3066 retro compatible solution and " supp= orts >>all the others. It will then be up to the grassroots process to adapt. = IMHO >>(this is what I feel could be a possible stabilisation) "x-abc:xxxx" wo= uld >>be a good approach where "abc" is a freely used scheme we could relate = to >>CRC format names. This means that x-3066:en-Latn-UK could be a legitima= te >>format, also entered in places like "xlang:en-Latn-UK". >> >>Obviously, x-tags can support other features the Draft cannot such as >>multilingual entries (via double indexation: entries use a reference nu= mber >>documented by multilingual grids), ISO 11179 intended compatibility >>supporting locales, MLDN charsets, referent directories, context additi= ons, >>CRCs, etc. ... and as documented Addison and Mark's Draft with their ow= n >>default format and registry. >> >>jfc >> >> >=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 Wed Jul 27 06:57:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxjb8-0005Ml-4O; Wed, 27 Jul 2005 06: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 1Dxjb4-0005Mg-At for ltru@megatron.ietf.org; Wed, 27 Jul 2005 06:57: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 GAA15161 for ; Wed, 27 Jul 2005 06:57:06 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DxjaH-0001PX-GH for ltru@lists.ietf.org; Wed, 27 Jul 2005 12:56:21 +0200 Received: from c-180-160-96.hh.dial.de.ignite.net ([62.180.160.96]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Jul 2005 12:56:21 +0200 Received: from nobody by c-180-160-96.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 27 Jul 2005 12:56:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Wed, 27 Jul 2005 12:55:16 +0200 Organization: Lines: 15 Message-ID: <42E76814.5659@xyzzy.claranet.de> References: <001a01c5927a$9d522940$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-180-160-96.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: New editor's copy of draft-initial-03 X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > A new editor's copy of draft-ietf-ltru-initial-03 is now > available: Should be the last, unless they change something in the sources before date-B (date of approval for 3066bis ?). If you find such modifications (I only checked 830, still there) it's IMHO perfectly okay if you just update the initial registry - no ticket needed. Unless you think it's a serious problem, then use "date B-1" and let the normal procedures handle it later on the languages list. Thanks for this initial registry, bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 27 11:30:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxnrp-0002jU-Bx; Wed, 27 Jul 2005 11: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 1Dxnro-0002jP-3l for ltru@megatron.ietf.org; Wed, 27 Jul 2005 11:30:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07519 for ; Wed, 27 Jul 2005 11:30:41 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxoN4-0000kq-Tf for ltru@ietf.org; Wed, 27 Jul 2005 12:03:04 -0400 Received: from h-68-165-7-91.snvacaid.dynamic.covad.net ([68.165.7.91] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1Dxnrh-0000n6-00 for ltru@ietf.org; Wed, 27 Jul 2005 11:30:37 -0400 Message-ID: <008701c592c0$3afc0c20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <634978A7DF025A40BFEF33EB191E13BC0C3F964D@irvmbxw01.quest.com> <42E70C5F.5E81@xyzzy.claranet.de> Subject: Re: [Ltru] Re: ABNF beautification... Date: Wed, 27 Jul 2005 08:31: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.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 - There have been quite a few deltas in the "ABNF beautification", but it sounds like there is quite a bit of support. I'd like the editors to post a message with the ABNF as they see it based on the comments so far, and I'd like to hear from the rest of the WG participants on whether they support or oppose the revision, in order to be clear whether there is indeed a rough consensus to make this change. Randy, ltru co-chair _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 27 12:50:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxp6o-00058e-HU; Wed, 27 Jul 2005 12:50:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxp6m-00058W-Tw for ltru@megatron.ietf.org; Wed, 27 Jul 2005 12:50:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13526 for ; Wed, 27 Jul 2005 12:50:11 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxpc2-0003W7-7V for ltru@ietf.org; Wed, 27 Jul 2005 13:22:35 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 09:49: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] [psg.com #1072] compatibility and private use tags Date: Wed, 27 Jul 2005 09:49:58 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C3F9864@irvmbxw01.quest.com> Thread-Topic: [Ltru] [psg.com #1072] compatibility and private use tags Thread-Index: AcWSfvfbOidpeI9nRZ6+p+43pE3H0AAS5vqA From: "Addison Phillips" To: "Randy Presuhn" , "LTRU Working Group" X-OriginalArrivalTime: 27 Jul 2005 16:49:59.0361 (UTC) FILETIME=[39AD6B10:01C592CB] X-Spam-Score: 2.1 (++) X-Scan-Signature: 9668dd9718e12afaf579fddf1143437a 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 Please leave it closed. To summarize again: 1. Introduction of additional characters, such as "." into language tags = was rejected because these characters were not permitted in RFC 1766 or = RFC 3066 and compatibility with existing language tag processors is a = chief concern. 2. Relaxation of the length restriction on subtags from 8 to a larger = number was rejected for the same reason: it would break existing = processors. Furthermore, I don't feel that anyone has demonstrated a need for either = change: even JFC's proposals could be accommodated with clever design = within the existing framework. 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: Wednesday, July 27, 2005 12:42 AM > To: LTRU Working Group > Subject: [Ltru] [psg.com #1072] compatibility and private use tags >=20 > Hi - >=20 > Has anyone been persuaded by Jefsey's arguments that we need to > re-open the discussion of private-use (sub)tag syntax and = compatibility? > Unless there is support for re-examining this decision, I believe it = is > in the best interest of timely completion of our work to leave this = issue > closed. >=20 > Randy, ltru co-chair >=20 > ----- Original Message ----- > > From: "r&d afrac" > > To: "Martin Duerst" ; "Randy Presuhn" > ; > > Sent: Friday, July 22, 2005 8:21 AM > > Subject: Re: [Ltru] [psg.com #1073] Last call: IANA adaptation of = theUN > disclaimer > > > > Dear Martin, > > I will try to address this serious mail as seriously as possible. I = am > on > > vacations with many family things around. > > > > At 03:44 22/07/2005, Martin Duerst wrote: > > >[chair hat on] > > >Randy is right. "DISCUSS" refers to a very specific part of the = process, > > >in particular to questions, comments or requests some members of = the > IESG > > >may have on the draft. This is recorded as a "DISCUSS" in the draft > tracker > > >(see https://datatracker.ietf.org/public/pidtracker.cgi). > > > > We fully agree. The point I rise is a serious point. We are to = accept > > external codes and _mix_ them (ISO 3166/UN M.49) in an area sensible = to > > every government, except may be the USG. Some pointed out there is = no > > Culture Ministry in the USG), and in several English language = countries. > > Members of this WG should understand and accept that in some = countries > > language is considered as _the_ culture, to the point citizens may > consider > > anything concerning their language without their due approval as = real a > act > > of physical war, in cases calling possibly for personal physical > > retaliation and terror (all the more if they consider it as part of = what > is > > named "e-colonisation"). We have to take into account this full = spectrum > of > > understanding of what this WG [mainly composed of English mother = tongue > > people] considers. I would underline that the matter of the debates = of > this > > WG are quite unconceivable in a French speaking environment. > > > > I think this kind of concern is not a concern for a WG. But it is = the > > concern of a WG to inform IESG of the problem. What I say = (considering > the > > Internet standard process spirit/letter) is there are two solutions: > > > > - to propose a text in the hope IESG marks it for DISCUSS. > > - to report in the text that the identified problem goes beyond the > > Charter, and that we identified it should be treated somewhere else. > > > > In the first case we run into the risk that our text is accepted and > serves > > further on as an IETF position. Out of luck, our proposition could = be a > > good one. But it is likely, even if we do our best, it would not be = a > good > > one as this is a pretty complex one and we are neither lawyers nor > > international diplomats. > > > > The second one is IMHO the most loyal to the IESG. Because the IESG = can > > decide to accept our point and mark it for DISCUSS, or disagree with = us > and > > remove it. > > > > Ideally, the solution would be my reading of the charter: to address = all > > the issue through a global framework for the whole internet, truly > > correcting and replacing RFC 3066 and then presenting the ABNF and > filters > > of this particular case in a technical RFC. > > > > > > >The WG is expected to send the draft(s) to the AD and the IESG = ***in > the best > > >possible fashion***, after having done everything they think is > necessary. > > >If we asa WG come to (rough) consensus that some "political = disclaimer" > or > > >whatever we may call it is necessary, then we should make our best > efforts > > >to get the best possible text. > > > > See above. This is a solution. This is the one I initially advocated = for, > > trying to interest Gov officials, ISO people, Language structures, > UNESCO, > > etc. etc. The answer I received from everywhere is "we are not > interested > > in this commercial trick, IETF means nothing to us in that area, = their > > proposition is absurd and will not fly. Thank you to keep us posted = so > we > > know where, how and when to kill it". > > > > I think it is not a proper answer. Because it is premature to kill = the > > IETF, even if it stays the way it is (RFC 3774). The IETF is also a > place > > to protect the technology from all these people: nothing will happen = on > the > > Internet except through IETF and Open Source and Open Source is not > ready > > in terms of network architecture. So I tried to keep an equilibrium, = for > > example with the WGIG, which partly follows some of my points. > > > > But there are two main points the WGIG - and this WG - are wrong = about: > > > > 1. the WGIG places the Internet R&D in private sector, as the WG = does in > > mainly relying on Unicode and W3C private commercial consortia. IAB = RFC > > 3869 clearly says (its "main thesis") that if this is the case the > > architectural R&D of the internet is "in trouble". I can only = confirm > that: > > I try to keep (at my family expense, as do others on this list or = near- > by) > > myself near but financially free from Govs and as much as possible > > grassroots and non-profit as I can, for free technical thinking and > > development. This WG only produced a short minded, non scalable, > excluding > > solution (I will document this briefly further on). > > > > 2. The WGIG (and this WG does not even do that), considers > multilingualism > > as DNS and content (this WG excludes DNS what is a grave error, = because > it > > confuses IETF's IDN mistake with multilingual DNS. Vint Cerf just > > identified that mistake, put the blame on IETF, and calls for work = on > the > > matter. He starts from phishing which cannot unfortunately be = addressed > > without changing the proposition, what will call for a change in the > > architecture of the Internet. So not a little thing. > > > > But the main issue for us as a WG is that language is not the same = issue > > when a spoken language for mobiles (reason why mobiles develop far > faster > > than the Internet) or when text content for linguists, library and > language > > industry. Languages in the IETF must be understood as what IETF > considers: > > protocols. > > > > These person to person interintelligibility protocols involve R&D = issues > > this WG (financed by commercial interest) has not even alluded to. = The > > result is that a Draft about languages identification does not = identify > > itself what it considers as a language. I have no objection to the = idea > of > > standardising the commercial tag of languages, to the contrary. But = you > do > > not start from the price tag of the members of dominant consortium, = as > an > > R&D specs for the whole deliverable. > > > > >If some IESG members then think that this > > >has to be changed, they will raise a "DISCUSS". But going to the = IESG > > >with a draft that says something like "IESG, for this section, = please > > >do the work we were supposed to do" isn't an option. > > > > To do a work we are not supposed, we have not the competence and we = have > > not the authority to do is not an option. It would be a error and if = we > > make believe it would be a disloyalty. Unless you think you have the > > necessary authority to relate with the IESG liaisons with ISO, IANA, = GAC, > > ccTLDs, UNESCO, UN, etc. and actually engage in it. In which case I > would > > certainly support you > > > > I will take an example of the difficulty: as a ccTLD (supposed to = pay > the > > IANA, trustee of a national community, advisor of the Gov - in a = country > > where the culture Minister is also the Minister for ICT) and as the > > secretary of an independent intergovernmental, interccTLD, inter- > national > > Internet communities think tank, and as a Member of the ccTLD = committee > for > > the Luxembourg ccTLD meeting, I invited Brian Carpenter to come and > > introduce the way IETF would consider a liaison with ccTLDs. You may > recall > > that my call to Greek and Chinese ccTLD Managers on ietf > > -languages@alvestrand.no shown the interest and the political need. > Brian's > > answer was roughly (published in my presentation) "I considered with = IAB. > > We have nothing to discuss with you. However if there are specific > topics, > > please go through ADs" (two Govs I copied the mail asked "what is an = AD", > > showing the relational/cultural divide. > > > > Then came the US Statement of principles and then the WGIG, and then > Vint > > Cerf which followed in confirming the need and actually supporting = my > > proposition to ccTLDs of an INTF. A TF to structure that relation > speaking > > user on one side and IETF on the other. And of an UNITRY test bed = (along > > ICANN criteria), I am working on, with the support of already a few > > developing/non developing countries. > > > > Our role is not to replace IESG, but our job is not either to fool = the > IESG. > > > > >If the WG comes to the (rough) consensus that it's better NOT to = have a > > >"political disclaimer", then we submit a draft without a "political > > >disclaimer". > > >If somebody on the IESG thinks that this is a problem, then they = will > > >raise a "DISCUSS". If the WG and the IESG then can't agree, the = IESG > > >can request the RFC Editor to attach an "IESG Note" (see e.g. > > >http://www.ietf.org/rfc/rfc2251.txt). > > > > > >Up to this point, everything I have seen from the members of this = WG > > >strongly indicate that we have (rough) consensus to NOT have a > > >"political disclaimer". > > > > This WG is not competent on the matter. For two reasons: > > - this is not its charter. > > - the consensus is by exhaustion. > > > > Anyway the problem is not the way you, me, IETF sees the things. The > > problem is the way the concerned external parties see them. Inquire = by > > yourself. > > > > > >Since you do not want to call a debate on "complement RFC 3066" > rather > > > of "replace RFC 3066", and do not want to consider the Charter = issues > in > > > the WG, it seems you want them discussed in the brouhaha of the = IESG > Last Call. > > > > > >First, it's not sure the IESG Last Call will create a brouhaha. > > >Many IESG Last Calls go by without much discussion. This one may, > > >or it may not. > > > > This depends essentially on the "complements/replaces" > > > > >Also, as Randy has said (repeatedly), the Charter is up for debate > after > > >we have done our work. IETF WGs don't start their work by a charter > > >debate; if this was ever done in the past, it was abandoned because > > >it would be very unproductive. > > > > Here I am lost. I though Randy was using this "after we have done = our > work" > > as a delaying joke. Now you repeat it, I must consider you say = seriously > > that an IETF WG (and this is your intent in this case) is to = commonly > > understand the work to achieve in common once that work has been = done? > This > > is not exactly my own experience of IETF WG, but I am to say that = the > few I > > shared in have not been successes... This may the reason why? > > > > It rings Alice in Wonderlands to me. But if you say it is the way WG > > proceeds ... I would then be interested in getting a calendar and a > > procedure. When are you going to send a mail with a subject like = "let > > understand the work we had to do"? > > > > > >This may give more support to the proposed additions by more > > > legal/political oriented people. I will not oppose this due to the > very > > > reduced number of participants to the WG Last Call. But beware = that if > > > the document is not mended during the last call, this will = probably > lead > > > the document to be rejected at some stage (IESG Last Call, IANA, = etc.). > > > > > >If it turns out, during IETF Last Call, that there is a preference = for > > >a "political disclaimer", and if the WG, the AD, and the IESG agree > > >to some kind of wording, such a "political disclaimer" can be added > > >at IESG Last Call. In my judgement, this would in no way mean we = would > > >need to have a second IETF Last Call, or that the IETF Last Call = would > > >have to fail, because the political language that would be added = would > > >most probably not change any of the technical provisions of the = draft > > >nor should it change any other aspects such as registry operation.* > > > > I feel you read me incompletely. I say that the document will fail = at > some > > stage. If the concerned parties want to pay attention to the IETF = (and > this > > is my prayer, so we can preserve the Internet standard process > credibility > > in the Multilingual field) they will attend the IETF last call and = the > > Draft will be killed there (what would be sad, since it could fly as = a > > complement). Or it will more likely (I am not going to spend my life > > fighting an ill fitting Draft) be diplomatically killed at IANA = level. > The > > procedure has been already engaged. > > > > > >As it is, it focuses on an resticted approach, aiming an = exclusive > for > > > the language industry, against competitive open sources = multilingual > > > network oriented propositions and evolutions. > > > > > >[with my chair hat off] > > >It is quite clear that the current draft tries to address the needs = of > what > > >you call the "language industry", because people from this industry > came > > >forward with actual needs, and worked hard on solutions. > > > > Here is the confusion. Some people of the language industry came > forwards > > with this proposition. No the industry. I represent another part = (less > > dominant but more pervasive) of this industry. The way they are = treated > on > > ietf-languages@alvestrand.no or on this WG (as F. Charles was) did = not > > pushed them to continue. I commentd already the question of Randy on > this > > matter, my response and the support I got. > > > > There are others who worked hard, I would even say harder and have a > much > > broader vision and support, you totally disregard. So we agreed (and = I > > documented) that we will only proceed outside of this WG - leaving = you > > enjoy your format and using the "x-" compatible escape sequence. We > think > > it is better to compromise and show usage, running code, etc. > demonstrate > > our open position is better, and to expose the bias of the proposed > > exclusion. We got our "no way" excluding response. > > > > This is why, I am probably the only one concerned still considering = that > > the proposition of this WG may have merits, if not exclusive and > excluding > > (at least to satisfy the part of the industry you refer to). I also > think > > that coexistence is far better than opposition. > > > > If I am considered here as the bad guy against the Draft, and = outside as > > the bad guy or the traitor defending the Draft ... > > > > >It is in my view completely wrong to claim that the draft is = exclusive. > > >Indeed, while in RFC 3066, the only way to add language tags was by > > >one-by-one registration, and there were no private subtags, the = current > > >draft is way more flexible and extensible. > > > > I am afraid you miss the point here. RFC 3066 is a wrong solution > > (sometimes named "yellow star" RFC). People were shocked by the = timely > (was > > it needed, or unfortunate?) registration of Chinese new tags by > > ietf-languages@alvestrand.no (according to the non approved Draft = format) > > just before the Yahoo, Microsoft and Google announcement. This lead = this > > RFC 3066 Bis to be qualified of a "linguistic Yalta". > > > > 1. I note that you say "there were no private subtags", while other = says > > 1*8alphanum because compatibility with then must be maintained. > > 2. No one is really interested in the RFC 3066 format and registry, > except > > the Unicode consortium people. No problem with that. The proposed = system > > "flexibility and extensibility" (I am not convinced of, in your own > > perspective due to the unclear process and ISO relations) is = perceived > as a > > way to control far more the things than before. > > > > >A recent example was language tags for different school grade = levels. > > >With RFC3066, you would have had to register en-grade1, = en-us-grade1, > > >en-gb-grade1, and so on. Now, you could (after some discussion) = just > > >register grade1 through grade6 (on more), and it could be applied = to > > >all kinds of languages, wherever it made sense. > > > > Thank you for this example: did you ever consider that "gradeN" is > > meaningless for most outside of your world and that even then, 1 to = 6 > may > > be meaningless as there may be more grades and in different order? = We do > > not want that kind of registry. We want to be ISO 11179 compatible = when > a > > registry is really to be considered. > > > > > >We only oppose the exclusive, the exclusion and the lack of > scalability, > > > flexibility, capacity for innovation and evolution. > > > > > >Except for purely superficial syntactical issues such as subtag > length,..., > > > > "superficial syntactical issues" .... I love it. You will be = permitted > to > > have every name you want if it is less than 9 characters long, is in > ASCII > > and does not include anything else than 0-Z characters. Look how = liberal > I am? > > > > >I haven't seen any evidence from you (or from others) that the = current > > >draft lacks scalability, flexibility, extensibility, or capacity = for > > >innovation. > > > > I suppose you believe it! So I will give you some hint. > > > > "x-1*8alphanum" is supposed to support all the private subtags in a = non > > conflicting way. Let consider that one gives every user a different > number > > to permit them to differentiate their private subtags. With a = billion > > Internet users, we cannot even give a full subtag to all: 9 numerics = are > > needed. > > > > Let try to explain people that a cookie name can only be 8alphanum = long. > > Try to authenticate a private subtag using an MD5 key, etc. > > > > A full format for a commercial propositions, 8 alphanums for Open = Source, > > Networking, etc. > > > > >It would be good if you could document some actual (not = superficial) > > >cases of how the draft does that. As I said above, there is serious > > >evidence in the draft that it actually does the contrary: It = greatly > > >increases scalability, flexibility, capacity for innovation and > > >evolution. > > > > No. It greatly increases scalability, flexibility, capacity for = language > > control and evolution reduction to the profit of a dominant part of = the > > commercial language tools industry, because of its exclusive. > > > > If the Draft is a complement of RFC 3066 and permits undefined = content > of > > the "x-tags", permitting every other format to develop and be = supported > we > > will wind up in a totally acceptable coexistence situation where a > > "xlang:xxx" is an RFC 3066 retro compatible solution and " > supports > > all the others. It will then be up to the grassroots process to = adapt. > IMHO > > (this is what I feel could be a possible stabilisation) "x-abc:xxxx" > would > > be a good approach where "abc" is a freely used scheme we could = relate > to > > CRC format names. This means that x-3066:en-Latn-UK could be a > legitimate > > format, also entered in places like "xlang:en-Latn-UK". > > > > Obviously, x-tags can support other features the Draft cannot such = as > > multilingual entries (via double indexation: entries use a reference > number > > documented by multilingual grids), ISO 11179 intended compatibility > > supporting locales, MLDN charsets, referent directories, context > additions, > > CRCs, etc. ... and as documented Addison and Mark's Draft with their = own > > default format and registry. > > > > jfc > > >=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 Wed Jul 27 12:52:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxp9B-0005pa-4l; Wed, 27 Jul 2005 12:52:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxp99-0005pV-OF for ltru@megatron.ietf.org; Wed, 27 Jul 2005 12:52:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13641 for ; Wed, 27 Jul 2005 12:52:40 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxpeS-0003aW-6o for ltru@ietf.org; Wed, 27 Jul 2005 13:25:04 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 09:52: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: ABNF beautification... Date: Wed, 27 Jul 2005 09:52:33 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C3F986B@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: ABNF beautification... Thread-Index: AcWSwFCnDZqwELdqSs+tnPppeRTkWgACxT3g From: "Addison Phillips" To: "Randy Presuhn" , X-OriginalArrivalTime: 27 Jul 2005 16:52:34.0234 (UTC) FILETIME=[95FD29A0:01C592CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Please see my previous message. The beautified ABNF is posted in an = editor's copy: http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.html http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.txt 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: Wednesday, July 27, 2005 8:31 AM > To: ltru@ietf.org > Subject: Re: [Ltru] Re: ABNF beautification... >=20 > Hi - >=20 > There have been quite a few deltas in the "ABNF beautification", but > it sounds like there is quite a bit of support. I'd like the editors = to > post > a message with the ABNF as they see it based on the comments so far, > and I'd like to hear from the rest of the WG participants on whether = they > support or oppose the revision, in order to be clear whether there is > indeed a rough consensus to make this change. >=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@lists.ietf.org Wed Jul 27 23:03:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxyge-0001mw-Qk; Wed, 27 Jul 2005 23:03:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxygd-0001lp-5E for ltru@megatron.ietf.org; Wed, 27 Jul 2005 23:03:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28381 for ; Wed, 27 Jul 2005 23:03:51 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxzBz-0004KC-1c for ltru@ietf.org; Wed, 27 Jul 2005 23:36:20 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DxygT-0003WZ-2m; Wed, 27 Jul 2005 20:03:45 -0700 Message-Id: <6.2.1.2.2.20050728035126.04711af0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 28 Jul 2005 04:40:37 +0200 To: "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] ABNF beautification... In-Reply-To: <000801c59276$b3a10e40$7f1afea9@oemcomputer> References: <634978A7DF025A40BFEF33EB191E13BC0C3F964D@irvmbxw01.quest.com> <6.2.1.2.2.20050727080725.037ca7e0@mail.afrac.org> <000801c59276$b3a10e40$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 - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 08:44 27/07/2005, Randy Presuhn wrote: > > For the records I oppose the exclusion ABNF for private use. > > > > At 02:13 27/07/2005, Addison Phillips wrote: > > >privateuse = ("x"/"X") 1*("-" (1*8alphanum)) > > >Any comments? Can I get a hum to use this in preference to draft-09's > version? > > > > I note that Martin Duerst has not answered my mail explaining why this > > format is absurd. As long as he has not, this Last Call cannot be closed. > >Nonsense. Procedural I repeat for the records my position: 1. the RFC 3066 bis intended Draft would organises a de facto exclusive on language identification, and by way of commercial iteration, on language industry (cf. one of the question of one of the co-Chairs), to the benefit of dominant publishers by refusing to include in the langtag the name of a language referent, and by wanting to replace BPC 47 while it claims to restrict it, rather than complement it (what it could do in the particular case of the users utilising the products and solutions of the members of the consortium of such dominant publishers). 2. the Draft organises a definite exclusion of alternative tagging system in making sure that every private system using its "x-" private use escape sequence will run into every risk of conflict in leaving it - in toto - only an ... 8 alphanums name space to support the right of billions of users to privately document 20.000 languages and their own possibly quasi unlimited languages variants, in every region of the world, etc. Some even having the contempt (how else qualify this?) to say that such a format (8 alphanums) may support every other format in adding ad libitum 8 alphanums labels separated by a dash. 3. the WG-ltru has organised this in full knowledge of this problem and of the existence of competitive solutions and projects, however they are supported by running code and by public and private investors, are conforming or wanting to conform with ISO 11179 and to be multilingual, and after having been explained that whole project constitutes an unfair business practice that will be legally objected and would badly harm the internet in reducing the IANA credibility as a common un biased clearing house. 4. that this position has been made clear for eight months, has never been discussed except through the answer "it has been discussed before" by half a score of main participants to the WG and one of the co-Chairs. This position has been repeated during the WGLC and has lead one of the co-chair to request it to be documented (what has been done and is here repeated) without any resulting debate or humming. 5. The remark that the WGLC cannot be closed without this point being satisfactorily addressed has been qualified of "nonsense" by the other co-Chair. In that case RFCs make clear that the responsibility to decide, and to document on appeal, if there is a consensus to refute this position is to the co-Chairs. To help them I will compile and document the statistics of the WGLC once it is completed. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Wed Jul 27 23:03:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxyge-0001nK-Vp; Wed, 27 Jul 2005 23:03:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxygd-0001lq-5E for ltru@megatron.ietf.org; Wed, 27 Jul 2005 23:03:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28380 for ; Wed, 27 Jul 2005 23:03:51 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxzBz-0004KG-1X for ltru@ietf.org; Wed, 27 Jul 2005 23:36:20 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DxygU-0003WZ-D8; Wed, 27 Jul 2005 20:03:46 -0700 Message-Id: <6.2.1.2.2.20050728044650.045b86b0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 28 Jul 2005 04:57:44 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use tags In-Reply-To: <001f01c59282$91bb4460$030aa8c0@DEWELL> References: <20050727074420.MYZH29598.mta4.adelphia.net@megatron.ietf.org> <001f01c59282$91bb4460$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 - afrac.org 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 At 10:09 27/07/2005, Doug Ewell wrote: >Randy Presuhn wrote: > > > Has anyone been persuaded by Jefsey's arguments that we need to > > re-open the discussion of private-use (sub)tag syntax and > > compatibility? Unless there is support for re-examining this > > decision, I believe it is in the best interest of timely completion > > of our work to leave this issue closed. > >I am not persuaded. Compatibility with the existing RFC 3066 syntax, >which permitted only A-Z and 0-9 and hyphen, is important. The use of >full stop (period, dot) and other characters in language tags has never >been authorized by even the most liberal reading of RFC 3066. The >mechanism described in the current draft allows for private-use tags and >subtags of infinite length, a degree of flexibility provided by few >other standards and protocols. If your belief is genuine, and not pure comptempt of your competition as it resents it, can you document: 1. you warranty these scheme will prevent conflicts 2. will support a simple format such as x-schemes:name.subname:address:date-etc. 3. will address the right of billions of users to document the way they want 20.000 languages in thousands of regions, the languages and scripting variations they may chose (private use is for that). If you can seriously document this I will drop my demand. >We have discussed these arguments and reached a decision; let us move on. Can you document that long and interesting discussion? We are in Last Call. Those who do not support your decision are supposed to oppose it. This applies to the comments of Randy and Addison and to the silence of Martin. Sorry, I do not make the rules. As they are they helped the Internet to survive. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 28 02:42:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy266-0000mg-Kt; Thu, 28 Jul 2005 02:42:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy263-0000ma-DB for ltru@megatron.ietf.org; Thu, 28 Jul 2005 02:42:23 -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 CAA29743 for ; Thu, 28 Jul 2005 02:42:21 -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 <20050728064151.DXPS14360.mta13.adelphia.net@DEWELL> for ; Thu, 28 Jul 2005 02:41:51 -0400 Message-ID: <000601c5933f$62e191e0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050727153203.BCHP5577.mta7.adelphia.net@megatron.ietf.org> Date: Wed, 27 Jul 2005 23:41: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] Re: ABNF beautification... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 have been quite a few deltas in the "ABNF beautification", but > it sounds like there is quite a bit of support. I'd like the editors > to post a message with the ABNF as they see it based on the comments > so far, and I'd like to hear from the rest of the WG participants on > whether they support or oppose the revision, in order to be clear > whether there is indeed a rough consensus to make this change. I don't oppose the revision. I still don't see the need, but as long as everyone is sure the new version conveys *exactly* the same meaning as the old, it should be fine. -- 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 Thu Jul 28 02:46:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2AD-00020f-Ld; Thu, 28 Jul 2005 02:46:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy2AC-000200-Af for ltru@megatron.ietf.org; Thu, 28 Jul 2005 02:46:40 -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 CAA00140 for ; Thu, 28 Jul 2005 02:46: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 <20050728064608.FMRV29002.mta9.adelphia.net@DEWELL> for ; Thu, 28 Jul 2005 02:46:08 -0400 Message-ID: <000d01c59340$00954620$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050728030550.DMTW5577.mta7.adelphia.net@megatron.ietf.org> Date: Wed, 27 Jul 2005 23:45: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: [psg.com #1072] compatibility and private use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips wrote: > Furthermore, I don't feel that anyone has demonstrated a need for > either change: even JFC's proposals could be accommodated with clever > design within the existing framework. I don't even think it has to be all that clever: x-you-could-simply-string-together-any-addition-al-attribut-es-you-like- as-long-as-they-are-broken-into-clusters-of-8-or-fewer-ascii-characte-rs -- 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 Thu Jul 28 05:13:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy4SS-0001oP-Lo; Thu, 28 Jul 2005 05: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 1Dy4SP-0001ml-VW for ltru@megatron.ietf.org; Thu, 28 Jul 2005 05:13:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08035 for ; Thu, 28 Jul 2005 05:13:35 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy4xp-0005Wu-HG for ltru@ietf.org; Thu, 28 Jul 2005 05:46:06 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dy4S8-00018b-2x; Thu, 28 Jul 2005 02:13:20 -0700 Message-Id: <6.2.1.2.2.20050728110248.037cde50@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 28 Jul 2005 11:12:53 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use tags In-Reply-To: <000d01c59340$00954620$030aa8c0@DEWELL> References: <20050728030550.DMTW5577.mta7.adelphia.net@megatron.ietf.org> <000d01c59340$00954620$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 - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 08:45 28/07/2005, Doug Ewell wrote: >Addison Phillips wrote: > > > Furthermore, I don't feel that anyone has demonstrated a need for > > either change: even JFC's proposals could be accommodated with clever > > design within the existing framework. > >I don't even think it has to be all that clever: > >x-you-could-simply-string-together-any-addition-al-attribut-es-you-like- >as-long-as-they-are-broken-into-clusters-of-8-or-fewer-ascii-characte-rs Is that your contemptuous joke? I am sure the IESG and IETF will love it. Or have you something serious to propose. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 28 08:33:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy7ZW-0002dU-3S; Thu, 28 Jul 2005 08:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy7ZU-0002dP-EN for ltru@megatron.ietf.org; Thu, 28 Jul 2005 08:33:08 -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 IAA21786 for ; Thu, 28 Jul 2005 08:33:06 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dy7ZJ-0003Ia-1u for ltru@lists.ietf.org; Thu, 28 Jul 2005 14:32:57 +0200 Received: from c-180-160-233.hh.dial.de.ignite.net ([62.180.160.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Jul 2005 14:32:57 +0200 Received: from nobody by c-180-160-233.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Jul 2005 14:32:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Thu, 28 Jul 2005 14:30:14 +0200 Organization: Lines: 93 Message-ID: <42E8CFD6.383D@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C3F986B@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-180-160-233.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Editorial nits (was: ABNF beautification...) X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 beautified ABNF is posted in an editor's copy: ACK. I don't find the time to read it loud word for word, but at least I scanned it (= complete text) visually for minor nits: ~~~ old ~~~ field-name = *(ALPHA / DIGIT / "-") ~~~ new ~~ field-name = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] ~~~ end ~~~ Verified with Bill's parser. AFAIK that's what you want: A field-name can't be empty, starts with ALPHA, and doesn't end with a hyphen. Okay, I should have said so earlier, OTOH I did IIRC | Note that the hexadecimal notation MAY have between two and | six digits. The given XML source allows also one hex. digit, e.g. Maybe delete that note, or s/two/one/ (dubious, the source also allows more than six hex. digits, e.g. &) | records of whose Type has one Some upper case Type, many 'Type', maybe s/ Type / 'Type' /g | Long screeds about a particular subtag are frowned upon. Rarely I need a dictionary for en2de (often for de2en, that's another issue). It says "fig. coll." for "screed", how about s/screeds/comments/ ? | This field MAY appear at most one time Are you sure about "MAY at most" ? I'd say "MUST at most". | 1. The region code 'TL' was assigned to the country You don't want the "1." here, this list has only one item. Other sublists at this level use letters, but a sublist only with "A." (no "B.") is strange. Elsewhere you use a bullet for lists with only one item. The format of the "registration form" in 3.4 is also strange, maybe try "artwork" to get something like this: ~~~ new ~~~ LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: 2. E-mail address of requester: 3. Record Requested: Type: Subtag: Description: Prefix: Preferred-Value: Deprecated: Suppress-Script: Comments: 4. Intended meaning of the subtag: 5. Reference to published description of the language (book or article): 6. Any other relevant information: ~~~ end ~~~ | Any new registrations submitted after the adoption of this | document MUST be rejected. Is that necessary ? IMHO it's obvious. | Subtags of type 'Region' that have a Preferred-Value mapping | in the IANA registry (see Section 3.1) SHOULD be replaced | with their mapped value. Add: "In rare cases this step has to repeated". | Example: The language tag "en-NH" s/NH/BU/g and s/VU/MM/g - we want an example visible in the registry, not an obsolete case eliminated by the "date A" rule. I don't see the US-ASCII reference proposed by Scott, did you forget it ? Bye, Frank _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 28 11:07:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy9zA-00087m-Kg; Thu, 28 Jul 2005 11:07:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy9z9-00087e-Gi for ltru@megatron.ietf.org; Thu, 28 Jul 2005 11:07:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03999 for ; Thu, 28 Jul 2005 11:07:45 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyAUb-0008MQ-Hg for ltru@ietf.org; Thu, 28 Jul 2005 11:40:19 -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 j6SF7EQ0011128; Thu, 28 Jul 2005 08:07:14 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 28 Jul 2005 08:08:29 -0700 Message-ID: From: "McDonald, Ira" To: "'Doug Ewell'" , LTRU Working Group Subject: RE: [Ltru] Re: ABNF beautification... Date: Thu, 28 Jul 2005 08:08:28 -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: 50a516d93fd399dc60588708fd9a3002 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 much happier with the improved ABNF. 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: Thursday, July 28, 2005 2:41 AM > To: LTRU Working Group > Subject: [Ltru] Re: ABNF beautification... > > > Randy Presuhn wrote: > > > There have been quite a few deltas in the "ABNF beautification", but > > it sounds like there is quite a bit of support. I'd like > the editors > > to post a message with the ABNF as they see it based on the comments > > so far, and I'd like to hear from the rest of the WG participants on > > whether they support or oppose the revision, in order to be clear > > whether there is indeed a rough consensus to make this change. > > I don't oppose the revision. I still don't see the need, but > as long as > everyone is sure the new version conveys *exactly* the same meaning as > the old, it should be fine. > > -- > 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 Thu Jul 28 11:09:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyA0y-0000Nm-33; Thu, 28 Jul 2005 11:09:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyA0t-0000Mt-QX for ltru@megatron.ietf.org; Thu, 28 Jul 2005 11:09:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04082 for ; Thu, 28 Jul 2005 11:09:33 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyAWJ-0008PG-PA for ltru@ietf.org; Thu, 28 Jul 2005 11:42:05 -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 j6SF9Lj7011232; Thu, 28 Jul 2005 08:09:21 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Thu, 28 Jul 2005 08:10:36 -0700 Message-ID: From: "McDonald, Ira" To: "'Randy Presuhn'" , LTRU Working Group Subject: RE: [Ltru] End 28 July - Working group last call Date: Thu, 28 Jul 2005 08:10:34 -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: 82c9bddb247d9ba4471160a9a865a5f3 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, Reminder that the LTRU Working Group last call on these two documents ends today! Please comment on the revised ABNF and anything else today. 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: Thursday, July 14, 2005 4:45 PM > To: LTRU Working Group > Subject: [Ltru] End 28 July - Working group last call > > > Hi - > > Archive message > http://www1.ietf.org/mail-archive/web/ltru/current/msg02817.html > has the announcement of the availability of > http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-09.txt > > Archive message > http://www1.ietf.org/mail-archive/web/ltru/current/msg02761.html > has the avilability announcement of > http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt > > As I announced earlier, the working group last call on these > will end two weeks from the appearance of the availability > announcements for the i-ds. So, the last call will end on > July 28, 2005. Please make every effort to submit your comments > before then. We also need to hear from those who have read > the drafts and have no comments. Please let anyone you know of > who would be interested in this work that we are in working group > last call and that we would welcome their feedback. > > 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 Thu Jul 28 11:23:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyAE5-0004VA-T5; Thu, 28 Jul 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 1DyAE4-0004V4-7Q for ltru@megatron.ietf.org; Thu, 28 Jul 2005 11:23:12 -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 LAA05262 for ; Thu, 28 Jul 2005 11:23: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 <20050728152240.EGPT19267.mta10.adelphia.net@DEWELL> for ; Thu, 28 Jul 2005 11:22:40 -0400 Message-ID: <002601c59388$13799e60$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" Date: Thu, 28 Jul 2005 08:21: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 Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: [psg.com #1072] compatibility and private use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I'm going to go out on a limb and respond to this, because the questions actually sound like genuine requests for information. None of my responses below have any "secret" or "hidden" meaning, and must not be taken as such. Any attempt to twist my responses in a way I do not intend, or otherwise misrepresent them, or me, will cause me to go back to ignoring subsequent posts by this individual. r&d afrac wrote: > If your belief is genuine, It is. > and not pure comptempt of your competition as it resents it, "Competition" is not the word I would have chosen. "Opposition" is more like it. > can you document: > > 1. you warranty these scheme will prevent conflicts No private-use scheme can ever assure that it will not conflict with another private-use scheme. That is why they are private! The scheme proposed in the current draft does prevent conflicts with existing parsers that conform to RFC 3066. > 2. will support a simple format such as x-schemes:name.subname: > address:date-etc. Yes. You simply have to replace colons, full stops, etc. with hyphens, and make sure each piece consists of 8 or fewer characters in the range [0-9A-Za-z]: x-schemes-name-subname-address-date-etc > 3. will address the right of billions of users to document the way > they want 20.000 languages in thousands of regions, the languages and > scripting variations they may chose (private use is for that). There is no freely available coding standard for 20,000 languages, but you can put anything you like in a private-use subtag, including regional detail down to latitude and longitude. "fr-FR-x-VER" might be French as spoken in Versailles. "fr-x-484816N-0020708E" might be French as spoken in a particular location in Versailles. "fr-x-ipv4-212-195-148-209" might be French as spoken by a user of that particular IP address, if you think such a thing would be useful and interoperable. Semantic expressiveness is not the same as syntactic anarchy. Saying "you can put anything you like in a private-use subtag" is not the same as saying "... using whatever characters strike your fancy." > If you can seriously document this I will drop my demand. I think I have done so. >> We have discussed these arguments and reached a decision; let us move >> on. > > Can you document that long and interesting discussion? It's not my responsibility to "document" WG discussions. There is a public archive for that. The period of July 14-15 featured several messages with the title "Compatibility" or "Compatibilities" that dealt with this topic. (Whether anyone finds them "interesting" is another matter.) > We are in Last Call. Those who do not support your decision are > supposed to oppose it. > This applies to the comments of Randy and Addison and to the silence > of Martin. There is no requirement that every WG member, silent or vocal, must belong to either a "support" or "oppose" camp on every topic. Members who remain silent on a particular subject do so for a reason: they are showing that they have no strong opinion and are choosing not to get involved with it. When the time comes to discuss the matching draft in detail, I will probably have very little to say, because matching isn't one of my areas of expertise or great interest, and I don't want anyone to interpret my silence as an implicit show of support for or opposition to anything. If I support or oppose something, I will say so, and I would expect others to do the same. Later: >> x-you-could-simply-string-together-any-addition-al-attribut-es-you- >> like-as-long-as-they-are-broken-into-clusters-of-8-or-fewer-ascii- >> characte-rs > > Is that your contemptuous joke? I am sure the IESG and IETF will love > it. Or have you something serious to propose. It is a non-serious example used to illustrate a serious point. The syntax for private-use subtags does not limit one's ability to use them to express whatever one chooses to express, language-related or not. See my "fr-" examples above for a higher degree of seriousness. -- 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 Thu Jul 28 16:21:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyEsi-0000Ba-9J; Thu, 28 Jul 2005 16:21:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyEsg-0000BP-RH for ltru@megatron.ietf.org; Thu, 28 Jul 2005 16:21:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26069 for ; Thu, 28 Jul 2005 16:21:24 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyFOA-0000bC-6k for ltru@ietf.org; Thu, 28 Jul 2005 16:54:01 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DyEsW-0006jO-7V; Thu, 28 Jul 2005 13:21:16 -0700 Message-Id: <6.2.1.2.2.20050728182357.049085d0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 28 Jul 2005 20:05:55 +0200 To: "Doug Ewell" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use tags In-Reply-To: <002601c59388$13799e60$030aa8c0@DEWELL> References: <002601c59388$13799e60$030aa8c0@DEWELL> 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 - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA26069 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 Doug, I thank you to have made this effort. I what follow I will refer to your/= my=20 format for simplicity's sake. I fully understand that your format is the=20 format proposed by the two authors (with some ABNF tuning seeming still=20 necessary) and you will understand that my format is an open vision=20 representing (this is my function for 27 years) of any user centric=20 architecture. IMHO your effort is based upon a basic misunderstanding: - you obviously try to genuinely permit my format ("my" as above) - but you consider that such a private use will follow the logic of your=20 ("your" as above) formatting approach. My approach does not want to respect your 8alphanum constraint, because=20 that constraint may come from previous RFCs you want to respect and I do=20 not give a damn about (never used them). So you consider "x-" as a way to= =20 introduce private subtags while forcing them to obey your conventions, I=20 consider "x-" as a way to escape from the arbitrary constraints of "your"= =20 format without confusing it. At 17:21 28/07/2005, Doug Ewell wrote: r&d afrac wrote: > > If your belief is genuine, >It is. > > > and not pure comptempt of your competition as it resents it, >"Competition" is not the word I would have chosen. "Opposition" is more >like it. My reading is that you consider us as competition and wants to exclude me. I certainly oppose that attempt, but we respect your right to fairly deve= lop. ("You/me" as indicated above) > > can you document: > > > > 1. you warranty these scheme will prevent conflicts > >No private-use scheme can ever assure that it will not conflict with >another private-use scheme. That is why they are private! The scheme >proposed in the current draft does prevent conflicts with existing >parsers that conform to RFC 3066. I am afraid you get confused here. I assume that what you want to say is: 1. no private use scheme can ever assure that it will not conflict with=20 another private-use scheme (your text) 2. the current draft does prevent conflicts with existing parsers that=20 conform to RFC 3066 except for the private use part (that part added=20 otherwise we would loop). Point 1 is where I object. It simply means that the Draft is not finished= .=20 You have two options to finish it: - to devise a solution which will protect against private use schemes (su= ch=20 as relating the x- usage to an unique identifier of the private name spac= e=20 organiser). This way you will definitely prevent conflicts, but you will=20 have to write the framework RFC I call for. - to permit others to organise that warranty. This way you can complete t= he=20 Draft today in removing the 8alpha constraints which makes such an=20 organisation impossible. Point 2 is where the Charter objects. The charter is to enhance RFC 3066.= =20 What you do here is to refuse to enhance RFC 3066 on a point which is goi= ng=20 to be the main contentious point. > > 2. will support a simple format such as x-schemes:name.subname: > > address:date-etc. > >Yes. You simply have to replace colons, full stops, etc. with hyphens, >and make sure each piece consists of 8 or fewer characters in the range >[0-9A-Za-z]: !!! 1. The colons, full stops etc _are_ part of the format. 2. each label by nature does not want to consist of 8 or fewer hexatridec= imal. You want to impose your vision to my private vision. (I recall that "you" here are members of this WG and "me" is the rest of= =20 the world less those supporting "your" vision). >x-schemes-name-subname-address-date-etc To make you understand in your own approach, let assume I have: - a table of languages defined at jefsey-languages.com - conforming to the scheme documented at language-tags.x-tags.com - updated on 2005/12/03 at 16:08:09 (A). I may want to adopt the langtag=20 "x-language-tags.x-tags.com:singapourien.jefsey-languages.com:20051203160= 809A" 1. do you have any objection? On which grounds? 2. please give a secure transcription which will not confuse with another= =20 tag based upon: - table of language defined in jefsey.com - conforming to the scheme documented on tags.afrac.org - documented on 2005/01/18 3. please indicate the format if the development environment is in Arabic. 4. please indicate how I can use a simple privarted URI/IRI for a subtag?= =20 Fun that a WG Chaired by Martin Duerst opposes the support of URI/IRI. 5. same with an handle. After Larry Roberts being refused a parameter,=20 would Bob Khan be banned from languages documentation :-) 6. Same with OID - fun that I cannot use 1.3.6.1.4.1.311 in the IANA=20 designed format because Peter Constable lead WG would have opposed :-) to= =20 be used by an Harald Alvestrand mailing list for IANA registrations ....=20 (for those who want to know better http://www.alvestrand.no/objectid/top.= html ) etc. > > 3. will address the right of billions of users to document the way > > they want 20.000 languages in thousands of regions, the languages and > > scripting variations they may chose (private use is for that). > >There is no freely available coding standard for 20,000 languages, who said "freely". I understand then why you prefer speaking of=20 "opposition" rather than "competition". The same as there are=20 commercial projects based on ISO 639-3; there are others based upon ISO=20 639-6, and there are others based upon other compilation efforts more=20 organised towards networked usages. > but you can put anything you like in a private-use subtag, including >regional detail down to latitude and longitude. Oh! I am not sure anyone will consider that except a few cases. But you a= re=20 right, everything must be supported. > "fr-FR-x-VER" might be >French as spoken in Versailles. "fr-x-484816N-0020708E" might be French >as spoken in a particular location in Versailles. You know what? People in here will certainly far more understand=20 "x-fran=E7ais-versailles". I do not know why :-) And they will use "x-" as an initial indicator only after being educated.= =20 Otherwise they will totally disregard your langtags. >"fr-x-ipv4-212-195-148-209" might be French as spoken by a user of that >particular IP address, if you think such a thing would be useful and >interoperable. As documented many times, CRC Access Grids are IPv6 based (I translate:=20 common reference centres access grids are lists of IPv6 Interface ID to a= dd=20 to the user's host IPv6 address). How do you propose I write the IPv6=20 address "2001:921F:9E51::1278:987E"? You imagine the fun at IESG when I will document that the Draft has decid= ed=20 not to be compatible with IP=A8v6 addresses (32 Hexa plus 7 colons, ie 39= =20 alpanum and colon) >Semantic expressiveness is not the same as syntactic anarchy. Saying >"you can put anything you like in a private-use subtag" is not the same >as saying "... using whatever characters strike your fancy." You confuse your syntax and your semantic. You have to chose: either the=20 private use space is private or it is not. If in your mind it is private=20 (and therefore free) we can cooperate. If it is not, we will have to bloc= k you. > > If you can seriously document this I will drop my demand. > >I think I have done so. I do not doubt you were serious, but I doubt you will say that at this=20 stage your answer seriously document an proposition matching my needs. > >> We have discussed these arguments and reached a decision; let us mov= e > >> on. > > > > Can you document that long and interesting discussion? > >It's not my responsibility to "document" WG discussions. There is a >public archive for that. The period of July 14-15 featured several >messages with the title "Compatibility" or "Compatibilities" that dealt >with this topic. (Whether anyone finds them "interesting" is another >matter.) Thank you for this and for the comment. The first part will probably be appreciated in appeal. The second unfortunately denotes a possible contempt. Everyone in here should realise that it could be so simple to fight "your= "=20 proposition as commercial, biased, exclusive, politically oriented, etc. = I=20 do not. I try to find a solution permitting to coexist and for your=20 commercial interest to develop however I find them inappropriate and=20 harming the Internet architecture and Global Community Interests. > > We are in Last Call. Those who do not support your decision are > > supposed to oppose it. > > This applies to the comments of Randy and Addison and to the silence > > of Martin. > >There is no requirement that every WG member, silent or vocal, must >belong to either a "support" or "oppose" camp on every topic. True. And this is why the x- 8aphanum being opposed, it is the duty of th= e=20 WG-Chairs to make sure that there is a rough consensus in supporting it.=20 This rough consensus must be expressed by support or whatever means the=20 WG-Chairs may feel it exists. Once they have decided it, which is their=20 privilege, they will however have to document it in front of IETF, IESG a= nd=20 IAB. >Members who remain silent on a particular subject do so for a reason: th= ey=20 >are showing that they have no strong opinion and are choosing not to get= =20 >involved with it. True. Thank you for mentioning it yourself. You document that there is no= =20 strong opinion in supporting "x- 8alphanum", and that most choose not to=20 get involved in having it in the Draft. I fully understand this as I thin= k=20 it is a technical absurdity, and exclusion attempt and only a way to=20 support a commercial exclusive or dominance, but this is only "my" opinio= n ... >When the time comes to discuss the matching draft in detail, I will >probably have very little to say, because matching isn't one of my areas >of expertise or great interest, and I don't want anyone to interpret my >silence as an implicit show of support for or opposition to anything. >If I support or oppose something, I will say so, and I would expect >others to do the same. Fair enough. And I think everyone wants the same. >Later: > > >> x-you-could-simply-string-together-any-addition-al-attribut-es-you- > >> like-as-long-as-they-are-broken-into-clusters-of-8-or-fewer-ascii- > >> characte-rs > > > > Is that your contemptuous joke? I am sure the IESG and IETF will love > > it. Or have you something serious to propose. > >It is a non-serious example used to illustrate a serious point. The >syntax for private-use subtags does not limit one's ability to use them >to express whatever one chooses to express, language-related or not. >See my "fr-" examples above for a higher degree of seriousness. We can seriously agree "it is a non-serious example used to illustrate a=20 serious point" (this is a deadly serious point. Your example is not=20 serious) even if we probably do not understand it the same way. This should only help us to find a way to make it a serious example to=20 illustrate a serious point. Today the only way I found is to remove=20 limitations on "x-" field, treating it as a normal regular escape sequenc= e=20 (what does not prevent to say that if one wants to stay compatible with R= FC=20 3066 old format, 8alphanum MUST be used). Or to chose "0-" as an open=20 sequence (zero to be script independent). I do not see any problem and you should not either with: "0-language-tags.x-tags.com:singapourien.jefsey-languages.com:20051203160= 809A-2001:879:98F6::789C:1236" jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 28 17:12:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyFgA-0006Eg-NK; Thu, 28 Jul 2005 17: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 1DyFg7-0006DA-AI for ltru@megatron.ietf.org; Thu, 28 Jul 2005 17:12:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29260 for ; Thu, 28 Jul 2005 17:12:28 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyGBd-00022X-HF for ltru@ietf.org; Thu, 28 Jul 2005 17:45:06 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DyFg4-00016a-8F; Thu, 28 Jul 2005 14:12:28 -0700 Message-Id: <6.2.1.2.2.20050728224039.0437f010@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 28 Jul 2005 22:41:31 +0200 To: "Randy Presuhn" From: r&d afrac Subject: Re: [Ltru] Last contribution - was: Action items on draft-initial? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 [was mistakenly sent to ietf@ietf.org - this was cancelled] On 09:07 27/07/2005, Randy Presuhn said: > > I am glad to hear there is only one editor. BTW, would you mean Doug Ewell? > >I don't see any other editor listed in >http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt >and we certainly haven't named anyone else as editor. >You *have* read it, haven't you? Or do you just ask >to waste time? The hurting implication being ignored: 1. your remark could have implied that Doug was an editor of the main draft (are there some?) 2. Doug Ewell is not the editor but the author of the quoted Draft/ > > >As for users, page 1 of > > >http://www.ietf.org/internet-drafts/draft-ietf-ltru-initial-02.txt says: > > > > > > This memo defines the initial contents of the Language Subtag > > > Registry for use in forming tags for the identification of languages. > > > Since the contents of this memo only serve as a starting point for > > > the registry, it is inappropriate to use this memo in lieu of the > > > registry. > > > > ??? > > Do you mean that the meaning of entries varies if it is read by someone or > > someone else? > >No. Simply that it is inappropriate to use that memo in lieu of the registry. Exact. It applies to every Registry like experimental afrac.org, planned x-tags.org etc. >The only reason to publish it as an RFC at all is that that is the preferred >mechanism for delivering this kind of information to IANA. I do see that kind of exclusive for the IANA. Would you have some exclusion about private use space? >The document is of almost no interest to anyone else. The paragraph I >quoted makes this abundantly clear. Yes. And I made abundantly clear I am among those directly interested ... > > >Consequently, the IANA personnel initializing the registry are really > > >the only likely users of this document. Anyone else using it has gone > > >outside its express scope of application, and thus, from my point of > > >view, qualifies as "pre-confused". :-) > > > > Thanks to indicate the contempts for the users. IETF defines who an RFC > > user is. We already had "end users" and now "pre-confused users". When > > "post mortem users"? > >I fail to see your point. Someone who cannot understand "it is inappropriate >to use this memo in lieu of the registry" has no business poking around >in RFCs. Someone who willfully uses it despite the warning is worse than >"confused." I fully agree with this. But I am afraid the one who confuses registry with "IANA only" is confused. This may explain some odd positions about ISO 11179. > > >You've raised these issues before. The rough consensus on how to handle > > >each was quite clear. You may, of course, appeal under the terms of > RFC 2026 > > >section 6.5.1, and request that the AD direct us to discuss your requests > > >further. > > > > Thank you to make this statement. Just get prepared to explain how a few > > participating members make a rough consensus against practice and running > > code. And the hummings on these two points. You may recall that these are > > roughly the two points the preceding version of the Draft failed. And this > > one will also. I do not understand this so big desire of exclusive and > > exclusion to the point to kill your own work. Unless obviously you agree > > with me that this Draf hurts the Internet and want to see it die. > >No. Just that it hurts the Internet? Take care. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 28 18:45:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyH89-0007sY-Bd; Thu, 28 Jul 2005 18: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 1DyH87-0007sQ-OG for ltru@megatron.ietf.org; Thu, 28 Jul 2005 18:45:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04363 for ; Thu, 28 Jul 2005 18:45:28 -0400 (EDT) Received: from rly-ip03.mx.aol.com ([64.12.138.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyHdV-00049T-PR for ltru@ietf.org; Thu, 28 Jul 2005 19:18:08 -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-742e95fe616d; Thu, 28 Jul 2005 18:44:54 -0500 Received: from DEBHOME (ACCA7BE9.ipt.aol.com [172.202.123.233]) by smtp-los02.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j6SMikln014092; Thu, 28 Jul 2005 18:44:46 -0400 Message-Id: <200507282244.j6SMikln014092@smtp-los02.proxy.aol.com> From: "Debbie Garside" To: "'Addison Phillips'" , "'Randy Presuhn'" , Subject: RE: [Ltru] Re: ABNF beautification... Date: Thu, 28 Jul 2005 23:45:25 +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: AcWSwFCnDZqwELdqSs+tnPppeRTkWgACxT3gAD45lyA= In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C3F986B@irvmbxw01.quest.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.100 X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 All Just to clarify, does the beautified ABNF mean that should 639-6 come to pass it needs to wait for ter before it can be used or can it be used in bis? If the latter then I am happy if not then I could be unhappy; given the time it has taken to get bis to this stage! Regards Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Addison Phillips > Sent: 27 July 2005 17:53 > To: Randy Presuhn; ltru@ietf.org > Subject: RE: [Ltru] Re: ABNF beautification... > > Please see my previous message. The beautified ABNF is posted in an > editor's copy: > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.html > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.txt > > 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: Wednesday, July 27, 2005 8:31 AM > > To: ltru@ietf.org > > Subject: Re: [Ltru] Re: ABNF beautification... > > > > Hi - > > > > There have been quite a few deltas in the "ABNF beautification", but > > it sounds like there is quite a bit of support. I'd like the editors to > > post > > a message with the ABNF as they see it based on the comments so far, > > and I'd like to hear from the rest of the WG participants on whether > they > > support or oppose the revision, in order to be clear whether there is > > indeed a rough consensus to make this change. > > > > 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 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 28 18:45:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyH8O-0007te-GR; Thu, 28 Jul 2005 18:45:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyH8L-0007tZ-QC for ltru@megatron.ietf.org; Thu, 28 Jul 2005 18:45:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04375 for ; Thu, 28 Jul 2005 18:45:42 -0400 (EDT) From: Karen_Broome@spe.sony.com Received: from mail-ash.bigfish.com ([206.16.192.253] helo=mail4-ash-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyHds-0004A3-CS for ltru@ietf.org; Thu, 28 Jul 2005 19:18:21 -0400 Received: from mail4-ash.bigfish.com (localhost.localdomain [127.0.0.1]) by mail4-ash-R.bigfish.com (Postfix) with ESMTP id E80E243F350 for ; Thu, 28 Jul 2005 22:45:19 +0000 (UTC) X-BigFish: VP Received: by mail4-ash (MessageSwitch) id 1122590719881531_6908; Thu, 28 Jul 2005 22:45:19 +0000 (UCT) Received: from usmta02.spe.sony.com (unknown [64.14.248.62]) by mail4-ash.bigfish.com (Postfix) with ESMTP id C4FF643B17A for ; Thu, 28 Jul 2005 22:45:19 +0000 (UTC) Received: from usmail04.spe.sony.com ([43.130.148.27]) by usmta02.spe.sony.com (Lotus Domino Release 5.0.12) with SMTP id 2005072815531085:172397 ; Thu, 28 Jul 2005 15:53:10 -0700 To: ltru@ietf.org Subject: Re: [Ltru] Re: New editor's copy of draft-initial-03 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Thu, 28 Jul 2005 15:42:15 -0700 X-MIMETrack: Serialize by Router on USMAIL04/SVR/SPE(Release 6.5.4|March 27, 2005) at 07/28/2005 15:42:16, Serialize complete at 07/28/2005 15:42:16, Itemize by SMTP Server on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/28/2005 03:53:10 PM, Serialize by Router on MTAOUT/SVR/SPE(Release 5.0.12 |February 13, 2003) at 07/28/2005 03:53:15 PM, Serialize complete at 07/28/2005 03:53:15 PM Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.3 (/) 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 In case it is not clear from my participation in this group, I have read the draft and support it. Here is a starter list of possible language name synonyms for review and potential inclusion in the lang tags registry, but I agree that these should be reviewed through formal processes and only added if there is consensus on the addition of these values for the description field. Bangla/Bengali Persian/Farsi Valencian/Balear/Catalan Azerbaijian/Azeri Afghan/Pashto/Pushto Dzongkha/Bhutani Gallegan/Galician/Galego Indonesian/Bahasa Letzeburgesch/Luxembourgish Rundi/Kirundi Tibetan/Bodskad I welcome comments on the list above if there is disagreement. Thank you all for your work and assistance! Karen Broome Metadata Systems Designer Sony Pictures Entertainment _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 28 19:18:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyHeV-0007pP-Ih; Thu, 28 Jul 2005 19:18:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyHeT-0007pK-VO for ltru@megatron.ietf.org; Thu, 28 Jul 2005 19:18:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05718 for ; Thu, 28 Jul 2005 19:18:54 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyIA1-0004pB-KL for ltru@ietf.org; Thu, 28 Jul 2005 19:51:34 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 16:18: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] Editorial nits (was: ABNF beautification...) Date: Thu, 28 Jul 2005 16:18:40 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C4AA973@irvmbxw01.quest.com> Thread-Topic: [Ltru] Editorial nits (was: ABNF beautification...) Thread-Index: AcWTcOCnok4bIgipTbW6jNoQIyPQvAAVA+QA From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 28 Jul 2005 23:18:41.0349 (UTC) FILETIME=[B1141F50:01C593CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd 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 Responses 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: Thursday, July 28, 2005 5:30 AM > To: ltru@ietf.org > Subject: [Ltru] Editorial nits (was: ABNF beautification...) >=20 > Addison Phillips wrote: >=20 > > The beautified ABNF is posted in an editor's copy: >=20 > ACK. I don't find the time to read it loud word for word, > but at least I scanned it (=3D complete text) visually for > minor nits: >=20 > ~~~ old ~~~ > field-name =3D *(ALPHA / DIGIT / "-") > ~~~ new ~~ > field-name =3D ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] > ~~~ end ~~~ >=20 > Verified with Bill's parser. AFAIK that's what you want: >=20 > A field-name can't be empty, starts with ALPHA, and doesn't > end with a hyphen. >=20 > Okay, I should have said so earlier, OTOH I did IIRC [Addison Phillips]=20 Your ABNF isn't strictly accurate, since it requires that field names be = at least two characters long, although it doesn't actually affect = anything to make any of your proposed changes (none of the field names = defined violate the rules). I don't see making this particular ABNF = (note to readers: this is the ABNF for record-jar format in Section 3.1) = less beautiful in order to express 50% of the requirement. How about: Field-name =3D ALPHA *(ALPHA / DIGIT / "-") Or we could go with your previous proposal of listing the file names as = strings in the ABNF (ick). >=20 > | Note that the hexadecimal notation MAY have between two and > | six digits. >=20 > The given XML source allows also one hex. digit, e.g. [Addison Phillips]=20 Yes, technically, but the following requirement prevents them from being = used in the registry: -- Characters from outside the US-ASCII repertoire, as well as the = AMPERSAND character ("&", %x26) when it occurs in a field-body are = represented by a "Numeric Character Reference" -- All the one-digit items are in the US-ASCII repertoire and thus won't be = used..... >=20 > Maybe delete that note, or s/two/one/ (dubious, the source > also allows more than six hex. digits, e.g. &) [Addison Phillips]=20 But Unicode and ISO/IEC 10646 will never define scalar values > = 0x10FFFF. Values with seven or eight digits are like UTF-8 sequences = with five or six bytes---possible from a logical point of view, but = never used (and, in the case of UTF-8, now actually illegal). The use of = the RFC 2119 keyword MAY restricts the length to six. It could say = "MUST", of course. >=20 > | records of whose Type has one >=20 > Some upper case Type, many 'Type', maybe s/ Type / 'Type' /g [Addison Phillips]=20 ACK. Also fixed the one occurrence of "Type" to be 'Type'. >=20 > | Long screeds about a particular subtag are frowned upon. >=20 > Rarely I need a dictionary for en2de (often for de2en, that's > another issue). It says "fig. coll." for "screed", how about > s/screeds/comments/ ? [Addison Phillips]=20 'Screed' conveys (auf Englisch) a pejorative sense, but isn't good = International English. Changed to "texts". >=20 > | This field MAY appear at most one time >=20 > Are you sure about "MAY at most" ? I'd say "MUST at most". [Addison Phillips]=20 "MAY at most" means it can be omitted. "MUST at most" means the same = thing but possibly conveys the sense of the requirement better. The best = is what I changed it to: -- This field MUST NOT appear more than one time in a record. -- >=20 > | 1. The region code 'TL' was assigned to the country >=20 > You don't want the "1." here, this list has only one item. [Addison Phillips]=20 Correct. I wanted this to be an indented example. In the XML it is = actually , which is supposed to give that effect = (but doesn't). I've changed to style=3D"hanging" to get the proper = effect. >=20 > Other sublists at this level use letters, but a sublist only > with "A." (no "B.") is strange. Elsewhere you use a bullet > for lists with only one item. >=20 > The format of the "registration form" in 3.4 is also strange, > maybe try "artwork" to get something like this: >=20 > ~~~ new ~~~ > LANGUAGE SUBTAG REGISTRATION FORM > 1. Name of requester: > 2. E-mail address of requester: > 3. Record Requested: > Type: > Subtag: > Description: > Prefix: > Preferred-Value: > Deprecated: > Suppress-Script: > Comments: > 4. Intended meaning of the subtag: > 5. Reference to published description > of the language (book or article): > 6. Any other relevant information: > ~~~ end ~~~[Addison Phillips] \ [Addison Phillips]=20 Um... it is artwork already and looks remarkably like that in both HTML = and TXT versions: -- LANGUAGE SUBTAG REGISTRATION FORM 1. Name of requester: 2. E-mail address of requester: 3. Record Requested: Type: Subtag: Description: Prefix: Preferred-Value: Deprecated: Suppress-Script: Comments: 4. Intended meaning of the subtag: 5. Reference to published description of the language (book or article): 6. Any other relevant information: Figure 5 -- If you mean the indentations, I added those to make it nicer. >=20 > | Any new registrations submitted after the adoption of this > | document MUST be rejected. >=20 > Is that necessary ? IMHO it's obvious. [Addison Phillips]=20 There is a period after the adoption and before publication in which = there might be some confusion. This closes that loophole. >=20 > | Subtags of type 'Region' that have a Preferred-Value mapping > | in the IANA registry (see Section 3.1) SHOULD be replaced > | with their mapped value. >=20 > Add: "In rare cases this step has to repeated". [Addison Phillips]=20 Okay. Inserted with slight alteration: -- Subtags of type 'Region' that have a Preferred-Value mapping=20 in the IANA registry (see ) SHOULD be = replaced with their mapped value. Note: In rare cases the mapped = value will also have a Preferred-Value. -- >=20 > | Example: The language tag "en-NH" >=20 > s/NH/BU/g and s/VU/MM/g - we want an example visible in the > registry, not an obsolete case eliminated by the "date A" rule. [Addison Phillips]=20 Okay. Burma/Mynamar isn't necessarily a felicitous combination, but = there aren't a lot of examples given the date A/date B rules. >=20 > I don't see the US-ASCII reference proposed by Scott, did you > forget it ? [Addison Phillips]=20 Nope, didn't forget it. US-ASCII's reference is: [ISO646] ISO/IEC 646 JTC 1/SC 2, "ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange.", 1991. And it is referred correctly in the text. A lot of folks tend to see ISO = 646 and think ISO 10646... _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 28 19:27:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyHmc-0002ZH-2Y; Thu, 28 Jul 2005 19:27:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyHma-0002ZC-Fc for ltru@megatron.ietf.org; Thu, 28 Jul 2005 19:27:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06333 for ; Thu, 28 Jul 2005 19:27:17 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyII8-00053O-Vz for ltru@ietf.org; Thu, 28 Jul 2005 19:59:57 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 16:27: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: ABNF beautification... Date: Thu, 28 Jul 2005 16:27:10 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C4AA980@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: ABNF beautification... Thread-Index: AcWSwFCnDZqwELdqSs+tnPppeRTkWgACxT3gAD45lyAAAawPkA== From: "Addison Phillips" To: "Debbie Garside" , "Randy Presuhn" , X-OriginalArrivalTime: 28 Jul 2005 23:27:11.0024 (UTC) FILETIME=[E0DE5B00:01C593CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 The revised ABNF makes clear what the text already says in Section = 2.2.1: -- All four character language subtags are reserved for possible future = standardization. -- That is, wholesale registration of ISO 639-6 (or ISO 639-3) subtags = requires a new RFC. This is actually good for you, since it precluded = users registering any codes that might conflict. I imagine that a revision incorporating ISO 639-6 would not require the = long, hard road this document has taken, since it would exactly the = following changes: a. replace a comment in the ANBF. b. replace the cited sentence above c. have an instruction for how to get the new values into the registry ISO 639-3 will require slightly more work: it will have to make extlangs = valid and a few other minor housekeeping chores. 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: Thursday, July 28, 2005 3:45 PM > To: Addison Phillips; 'Randy Presuhn'; ltru@ietf.org > Subject: RE: [Ltru] Re: ABNF beautification... >=20 > Hi All >=20 > Just to clarify, does the beautified ABNF mean that should 639-6 come = to > pass it needs to wait for ter before it can be used or can it be used = in > bis? If the latter then I am happy if not then I could be unhappy; = given > the time it has taken to get bis to this stage! >=20 > Regards >=20 >=20 > Debbie >=20 > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org = [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Addison Phillips > > Sent: 27 July 2005 17:53 > > To: Randy Presuhn; ltru@ietf.org > > Subject: RE: [Ltru] Re: ABNF beautification... > > > > Please see my previous message. The beautified ABNF is posted in an > > editor's copy: > > > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.html > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.txt > > > > 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: Wednesday, July 27, 2005 8:31 AM > > > To: ltru@ietf.org > > > Subject: Re: [Ltru] Re: ABNF beautification... > > > > > > Hi - > > > > > > There have been quite a few deltas in the "ABNF beautification", = but > > > it sounds like there is quite a bit of support. I'd like the = editors > to > > > post > > > a message with the ABNF as they see it based on the comments so = far, > > > and I'd like to hear from the rest of the WG participants on = whether > > they > > > support or oppose the revision, in order to be clear whether there = is > > > indeed a rough consensus to make this change. > > > > > > 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 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Thu Jul 28 20:15:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyIXQ-0006kf-Oa; Thu, 28 Jul 2005 20:15:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyIXP-0006ja-98 for ltru@megatron.ietf.org; Thu, 28 Jul 2005 20:15:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08683 for ; Thu, 28 Jul 2005 20:15:41 -0400 (EDT) Received: from irvbhxw03.quest.com ([12.106.87.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyJ2x-0006Da-4J for ltru@ietf.org; Thu, 28 Jul 2005 20:48:20 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw03.quest.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 28 Jul 2005 17:15:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Jul 2005 17:15:26 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C4AA99F@irvmbxw01.quest.com> Thread-Topic: new editor's copy, plus diff, online Thread-Index: AcWT0ll1MM4O06arQMqWBWclawrs6A== From: "Addison Phillips" To: X-OriginalArrivalTime: 29 Jul 2005 00:15:26.0373 (UTC) FILETIME=[9EA18D50:01C593D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ltru] new editor's copy, plus diff, 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="===============0963917686==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0963917686== content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBoYXZlIGluY29ycG9yYXRlZCBhbGwgdGhlIGFjY2VwdGVkIGNoYW5nZXMgSSBrbm93IGFib3V0 IGZyb20gdGhlIExhc3QgQ2FsbCB0byBkYXRlIGludG8gdGhlIGVkaXRvcidzIGNvcHkgYW5kIHBv c3RlZCBpdCBvbjoNCg0KaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29tL0lEL2RyYWZ0LWlldGYt bHRydS1yZWdpc3RyeS0xMC50eHQNCmh0dHA6Ly93d3cuaW50ZXItbG9jYWxlLmNvbS9JRC9kcmFm dC1pZXRmLWx0cnUtcmVnaXN0cnktMTAuaHRtbA0KaHR0cDovL3d3dy5pbnRlci1sb2NhbGUuY29t L0lEL2RyYWZ0LWlldGYtbHRydS1yZWdpc3RyeS0xMC54bWwNCg0KSSBoYXZlIGFsc28gcHJvZHVj ZWQgYSBkaWZmIGZyb20gZHJhZnQtMDkgZm9yIHRob3NlIGludGVyZXN0ZWQgaW4gc2VlaW5nIHRo ZSBjaGFuZ2VzIGV4cGxpY2l0bHkuIFRoaXMgaXMgbG9jYXRlZCBoZXJlOg0KDQpodHRwOi8vd3d3 LmludGVyLWxvY2FsZS5jb20vSUQvZHJhZnQtcmVnaXN0cnktMDktMTAtZGlmZi5odG1sDQoNCkJl c3QgUmVnYXJkcywNCg0KQWRkaXNvbg0KDQpBZGRpc29uIFAuIFBoaWxsaXBzDQpHbG9iYWxpemF0 aW9uIEFyY2hpdGVjdCwgUXVlc3QgU29mdHdhcmUNCmh0dHA6Ly93d3cucXVlc3QuY29tDQoNCkNo YWlyLCBXM0MgSW50ZXJuYXRpb25hbGl6YXRpb24gQ29yZSBXb3JraW5nIEdyb3VwDQpodHRwOi8v d3d3LnczLm9yZy9JbnRlcm5hdGlvbmFsDQoNCkludGVybmF0aW9uYWxpemF0aW9uIGlzIG5vdCBh IGZlYXR1cmUuDQpJdCBpcyBhbiBhcmNoaXRlY3R1cmUuIA0KDQoNCg== --===============0963917686== 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 --===============0963917686==-- From ltru-bounces@lists.ietf.org Fri Jul 29 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 1DyNpp-0003XJ-SB; Fri, 29 Jul 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 1DyNpn-0003WR-ST for ltru@megatron.ietf.org; Fri, 29 Jul 2005 01:55: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 BAA22660 for ; Fri, 29 Jul 2005 01:54:58 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DyNpf-00058b-Dn for ltru@lists.ietf.org; Fri, 29 Jul 2005 07:54:55 +0200 Received: from du-001-233.access.de.clara.net ([212.82.227.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Jul 2005 07:54:55 +0200 Received: from nobody by du-001-233.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Jul 2005 07:54:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 29 Jul 2005 07:53:54 +0200 Organization: Lines: 77 Message-ID: <42E9C472.6175@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C4AA973@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-233.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Editorial 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: >> field-name = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] [...] > Your ABNF isn't strictly accurate, since it requires that > field names be at least two characters long The square brackets [...] mean optional, zero or one. > Field-name = ALPHA *(ALPHA / DIGIT / "-") Also fine and shorter, but it can end with hyphen(s). > Or we could go with your previous proposal of listing > the file names as strings in the ABNF (ick). That's too late. You wanted a general format covering future extension registries. > -- > Characters from outside the US-ASCII repertoire [...] Okay, one hex. digit would be ASCII, forget s/two/one/ >> also allows more than six hex. digits, e.g. & > But Unicode and ISO/IEC 10646 will never define scalar > values > 0x10FFFF. That's what they say today, some years ago it was 31 bits, UTF-32 still _is_ 32 bits (always in the form 0x00??????), nothing wrong with leading zeros. Or I didn't see it in the linked XML spec. (?) Of course we don't _need_ these details, the "two to six" was just something I saw in the draft - and I wrote my cp858 to UTF-8 converter only last year, so I'm still looking for all Unicode oddities... ;-) >> "fig. coll." [...] > 'Screed' conveys (auf Englisch) a pejorative sense Yes, I got the sense without knowing the word, and then I was curious and looked it up. >> 5. Reference to published description >> of the language (book or article): >> 6. Any other relevant information: [...] > 5. Reference to published description > of the language (book or article): > 6. Any other relevant information: [...] > If you mean the indentations, I added those to make it nicer. Yes, thanks. > [ISO646] ISO/IEC 646 JTC 1/SC 2, "ISO/IEC 646:1991, [...] > A lot of folks tend to see ISO 646 and think ISO 10646... Yes, sorry, I missed that, in another spec. it's different: | [US-ASCII] | American National Standards Institute (formerly United | States of America Standards Institute), "USA Code for | Information Interchange, X3.4", 1968. | | ANSI X3.4-1968 has been replaced by newer versions with | slight modifications, but the 1968 version remains | definitive for the Internet. Some control characters changed or renamed IIRC, irrelevant for 3066bis, we only need CRLF and SP as found in ABNF. Bye _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 29 04:53:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyQc1-0000aY-QW; Fri, 29 Jul 2005 04:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyQbz-0000ZI-SQ for ltru@megatron.ietf.org; Fri, 29 Jul 2005 04:53:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21682 for ; Fri, 29 Jul 2005 04:52:57 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyR7c-0001Kf-DF for ltru@ietf.org; Fri, 29 Jul 2005 05:25:41 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DyQbl-0003Ud-H9; Fri, 29 Jul 2005 01:52:45 -0700 Message-Id: <6.2.1.2.2.20050729101334.03a9d350@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 29 Jul 2005 10:28:04 +0200 To: "Debbie Garside" , "'Addison Phillips'" , "'Randy Presuhn'" , Martin Duerst From: r&d afrac Subject: RE: [Ltru] Re: ABNF beautification...Last Call question In-Reply-To: <200507282244.j6SMikln014092@smtp-los02.proxy.aol.com> References: <634978A7DF025A40BFEF33EB191E13BC0C3F986B@irvmbxw01.quest.com> <200507282244.j6SMikln014092@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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.1 (/) 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org At 00:45 29/07/2005, Debbie Garside wrote: >Hi All >Just to clarify, does the beautified ABNF mean that should 639-6 come to >pass it needs to wait for ter before it can be used or can it be used in >bis? If the latter then I am happy if not then I could be unhappy; given >the time it has taken to get bis to this stage! I am not good at ABNF. But I rose a Last Call point that language subtags are treated equal from 2 to 8 alphanums (what permits to ensure reasonable compatibility with every ISO and non ISO standard the IETF or the Internet Community ad-hoc entities would adopt). If this is not the case I rise another Last Call point, and if the Last Call is finished, this would be a new exclusion point to be addressed in their turn by IETF, IESG, IAB, IANA and GAC with appeal to WTO. But by that time everything will be ruled discussed on the UN Internet Governance Forum. So, I am not sure you can deduce anything from the current status of "numerobis" (cf. Asterix & Cleopatre). I suppose that ISO 639-6 will be for long in use in various network protocols before the current Draft is enforced by the IANA... This however depends on its authors. I know some would love to make ISO 639-6 depend on this Draft and on its "consensus" that Randy and Martin will probably announce anytime soon (under their co-Chair responsibility). This is a mistake. BTW I wait for the information I asked you. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 29 05:07:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyQpb-0003zb-Ov; Fri, 29 Jul 2005 05:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyQpZ-0003zW-JK for ltru@megatron.ietf.org; Fri, 29 Jul 2005 05:07:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22471 for ; Fri, 29 Jul 2005 05:06:58 -0400 (EDT) Received: from smtp.nildram.co.uk ([195.112.4.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyRLC-0001j5-V6 for ltru@ietf.org; Fri, 29 Jul 2005 05:39:43 -0400 Received: from debbie (ictbarn.gotadsl.co.uk [213.208.115.6]) by smtp.nildram.co.uk (Postfix) with ESMTP id 11D4B2534FC; Fri, 29 Jul 2005 10:06:42 +0100 (BST) From: "Debbie Garside" To: "'Addison Phillips'" , "'Randy Presuhn'" , Subject: RE: [Ltru] Re: ABNF beautification... Date: Fri, 29 Jul 2005 10:06:40 +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: AcWSwFCnDZqwELdqSs+tnPppeRTkWgACxT3gAD45lyAAAawPkAAUcqAw In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C4AA980@irvmbxw01.quest.com> Message-Id: <20050729090642.11D4B2534FC@smtp.nildram.co.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 OK. Thanks for the clarification! Debbie -----Original Message----- From: Addison Phillips [mailto:addison.phillips@quest.com] Sent: 29 July 2005 00:27 To: Debbie Garside; Randy Presuhn; ltru@ietf.org Subject: RE: [Ltru] Re: ABNF beautification... The revised ABNF makes clear what the text already says in Section 2.2.1: -- All four character language subtags are reserved for possible future standardization. -- That is, wholesale registration of ISO 639-6 (or ISO 639-3) subtags requires a new RFC. This is actually good for you, since it precluded users registering any codes that might conflict. I imagine that a revision incorporating ISO 639-6 would not require the long, hard road this document has taken, since it would exactly the following changes: a. replace a comment in the ANBF. b. replace the cited sentence above c. have an instruction for how to get the new values into the registry ISO 639-3 will require slightly more work: it will have to make extlangs valid and a few other minor housekeeping chores. 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: Thursday, July 28, 2005 3:45 PM > To: Addison Phillips; 'Randy Presuhn'; ltru@ietf.org > Subject: RE: [Ltru] Re: ABNF beautification... > > Hi All > > Just to clarify, does the beautified ABNF mean that should 639-6 come > to pass it needs to wait for ter before it can be used or can it be > used in bis? If the latter then I am happy if not then I could be > unhappy; given the time it has taken to get bis to this stage! > > Regards > > > Debbie > > > -----Original Message----- > > From: ltru-bounces@lists.ietf.org > > [mailto:ltru-bounces@lists.ietf.org] > On > > Behalf Of Addison Phillips > > Sent: 27 July 2005 17:53 > > To: Randy Presuhn; ltru@ietf.org > > Subject: RE: [Ltru] Re: ABNF beautification... > > > > Please see my previous message. The beautified ABNF is posted in an > > editor's copy: > > > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.html > > http://www.inter-locale.com/ID/draft-ietf-ltru-registry-10.txt > > > > 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: Wednesday, July 27, 2005 8:31 AM > > > To: ltru@ietf.org > > > Subject: Re: [Ltru] Re: ABNF beautification... > > > > > > Hi - > > > > > > There have been quite a few deltas in the "ABNF beautification", > > > but it sounds like there is quite a bit of support. I'd like the > > > editors > to > > > post > > > a message with the ABNF as they see it based on the comments so > > > far, and I'd like to hear from the rest of the WG participants on > > > whether > > they > > > support or oppose the revision, in order to be clear whether there > > > is indeed a rough consensus to make this change. > > > > > > 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 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 29 08:28:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyTyf-0006mn-1h; Fri, 29 Jul 2005 08:28:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyTye-0006mi-CR for ltru@megatron.ietf.org; Fri, 29 Jul 2005 08:28:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03395 for ; Fri, 29 Jul 2005 08:28:34 -0400 (EDT) Received: from suomi.kotus.fi ([193.166.18.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyUUH-0007Sh-5x for ltru@ietf.org; Fri, 29 Jul 2005 09:01:19 -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 j6TCSLpX026979; Fri, 29 Jul 2005 15:28:21 +0300 (EEST) Message-ID: <42EA20E4.40506@kotus.fi> Date: Fri, 29 Jul 2005 15:28:20 +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: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use tags References: <002601c59388$13799e60$030aa8c0@DEWELL> <6.2.1.2.2.20050728182357.049085d0@mail.afrac.org> 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: Doug Ewell , 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 Jefsey, re your note of 28.7.2005 to Doug Ewell, the following quotation is to me an undisputable hard fact: No private-use scheme can ever assure that it will not conflict with another private-use scheme. That is why they are private! [DE] ... and the following highly commendable: The scheme proposed in the current draft does prevent conflicts with existing parsers that conform to RFC 3066. [DE] ... and the following highly questionable: My approach does not want to respect your 8alphanum constraint, because that constraint may come from previous RFCs you want to respect and I do not give a damn about (never used them). [JM] To all: In case it is not clear from my participation in this group, I have read the draft and support it. Sincerely, Erkki I. Kolehmainen _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 29 10:37:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyVzG-0004tG-Jc; Fri, 29 Jul 2005 10:37:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyVzF-0004sO-80 for ltru@megatron.ietf.org; Fri, 29 Jul 2005 10:37:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13564 for ; Fri, 29 Jul 2005 10:37:18 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyWUv-0003MH-LL for ltru@ietf.org; Fri, 29 Jul 2005 11:10:06 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DyVyc-0004Tq-HX; Fri, 29 Jul 2005 07:36:44 -0700 Message-Id: <6.2.1.2.2.20050729145302.0586ead0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 29 Jul 2005 16:36:02 +0200 To: Erkki Kolehmainen From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use tags In-Reply-To: <42EA20E4.40506@kotus.fi> References: <002601c59388$13799e60$030aa8c0@DEWELL> <6.2.1.2.2.20050728182357.049085d0@mail.afrac.org> <42EA20E4.40506@kotus.fi> 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 - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: Doug Ewell , 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 Erkki, as I noted it: At 14:28 29/07/2005, Erkki Kolehmainen wrote: >Dear Jefsey, >re your note of 28.7.2005 to Doug Ewell, the following quotation is to me >an undisputable hard fact: > No private-use scheme can ever assure that it will not conflict with > another private-use scheme. That is why they are private! [DE] This pure non-sense! The fact that they are private and they permit conflict are orthogonal. I will take a simple example: Domain Names are private yet they cannot conflict. Because we organised the name space for that. As I indicated (and documented) there are many ways to specify the organisation of the "x-" name space so it is both private and conflict free. I am only sorry that you comment Doug remarks and my remark on its proposition, rather than the answer I made Doug requested. I understand why, but so will IETF/IESG/IAB/GAC/WTO/IANA. I would be interested in your comment on the problem rather than a repetition of your ideas. >... and the following highly commendable: > The scheme proposed in the current draft does prevent conflicts with > existing parsers that conform to RFC 3066. [DE] The "highly commendable" is an odd hyperbole. It is correct, or it is not. It is correct only if private use is removed from RFC 3066. The current draft does NOT prevent conflicts with existing parser that conform to RFC 3066 in the private area. This is precisely this claim which is wrong, which is objected by the previous claim above (you cannot say both: there will always be conflicts and at the same time you prevent conflicts). This reality is not an enhancement called by the Charter. >... and the following highly questionable: >My approach does not want to respect your 8alphanum constraint, because >that constraint may come from previous RFCs you want to respect and I do >not give a damn about (never used them). [JM] May I ask why is that "highly questionable"? I tend to think that liberty is an highly questionable issue. But in standards, you can say (what I detail and you totally ignore): "you MUST not (religious) say that!", or you can say "ok, what shall we then do?". >To all: In case it is not clear from my participation in this group, I >have read the draft and support it. Noted. Always good to note than someone has understood the way IETF Last Calls work: in bringing positive support to questioned points. The problem now is with the co-Chairs. Do they consider and can document to the IETF, IESG, IAB (and will they help the lawyers in GAC, IANA, WTO): - the WG actually covered the Charter without having proceeded to an evaluation of what the Charter calls for. - they have obtained a document professional enough for a positive IETF last call, with all the specialised points they did not cover, all the missing definitions of what they discuss and without having reduced opposition to consensus it proposes. - they have a consensus while the few objections I rose and documented (at their request) and did made seriously addressed yet, the mild support the Draft obtained from a small score of participants on a list of 60 WG-Members. We are here in a search of a consensus. So, we are not really interested in what you support or not: we are interested in what to do for both of us to agree. I said the two simple things for that: 1. not to claim to replace RFC 3066. I do not make it a critical point for the user community however. RFC 3066 is an error. Replacing an error by another error is no big damage. It is however critical for the IETF to decide if it will document the Multilingual Internet or not, as no serious non-US industry aficionado will use that system. We are making IDNA again. Your decision, at the end of the day I am not concerned. I think Harald documented enough, and Brian Carpenter's responses and attitude seem to confirm, and this WG-ltru main topic of interest documented it: IETF is simply not able to understand the problem and should not get into it. I think that if this is the attitude, some wording should be reviewed by the authors, to protect their future pride. 2. no to use a joke to exclude the real world. This joke uses two elements: "x-" and "8alpha". They are orthogonal. There can be three responses to that: - either to make "x-" free from limitations. You oppose: it is not compatible to RFC 3066. I say I do not care (I am the user) but you want to force me to do what you want. For my good sake, so I stay compatible with the past I never had. - either to create "0-" as a new zero constraint area. This has no problem of retrofit. The only opposition could be that the authors lose their grip on language tags and industry. But they claim they are not commercially and politically biased. So there is definitely no problem. - either to keep the existing text to make sure it will probably never be used. The inconvenience for some will certainly be real, and the load imposed on us to oppose will be heavy. But the protection granted to many many more is worth it. All the more than Liberty does not mean for us to win anytime soon, or even to win. Just to delay the mistake until the better solutions we work on have taken off and the existing other solutions which are not aware of the threat have been informed (I note that since this Draft claims to be compatible with RFC 3066, nothing impeach the W3C to make it a W3C document tomorrow, or the IESG to make it a complement to RFC 3066 as we propose it). I would not want to be in Randy and Martin shoes today. "0- or not 0-" jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 29 10:48:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyW9o-0008K5-Kv; Fri, 29 Jul 2005 10: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 1DyW9m-0008Jx-CK for ltru@megatron.ietf.org; Fri, 29 Jul 2005 10:48:14 -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 KAA14532 for ; Fri, 29 Jul 2005 10:48: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 <20050729144742.GDYA24042.mta11.adelphia.net@DEWELL> for ; Fri, 29 Jul 2005 10:47:42 -0400 Message-ID: <002b01c5944c$60fc4ce0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050728232247.CTSJ29598.mta4.adelphia.net@megatron.ietf.org> Date: Fri, 29 Jul 2005 07:47: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] Re: [psg.com #1072] compatibility and private use 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org I have nothing further to add to this thread. I look forward to IETF Last Call and to the inevitable appeals. -- 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 Fri Jul 29 12:42:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXwL-0000MZ-Eo; Fri, 29 Jul 2005 12:42:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXwK-0000MA-7V for ltru@megatron.ietf.org; Fri, 29 Jul 2005 12:42:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22584 for ; Fri, 29 Jul 2005 12:42:24 -0400 (EDT) Received: from irvmbxw02.quest.com ([12.106.87.68] helo=irvbhxw02.quest.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyYS0-0007N5-6I for ltru@ietf.org; Fri, 29 Jul 2005 13:15:13 -0400 Received: from irvmbxw01.prod.quest.corp ([10.1.2.200]) by irvbhxw02.quest.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Jul 2005 09:42: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] Re: Editorial nits Date: Fri, 29 Jul 2005 09:42:11 -0700 Message-ID: <634978A7DF025A40BFEF33EB191E13BC0C4AABB0@irvmbxw01.quest.com> Thread-Topic: [Ltru] Re: Editorial nits Thread-Index: AcWUAkaTGMdBY/uUSNC8sslaUL7JhQAV4oqw From: "Addison Phillips" To: "Frank Ellermann" , X-OriginalArrivalTime: 29 Jul 2005 16:42:12.0647 (UTC) FILETIME=[78520370:01C5945C] 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 > >> field-name =3D ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT)] > [...] > > Your ABNF isn't strictly accurate, since it requires that > > field names be at least two characters long >=20 > The square brackets [...] mean optional, zero or one. Duh... you're right. That change will go in this morning. > > But Unicode and ISO/IEC 10646 will never define scalar > > values > 0x10FFFF. >=20 > That's what they say today, some years ago it was 31 bits, I stand by the original statement: there will never be characters > = 0x10FFFF in Unicode or ISO/IEC 10646. Although technically we could = allow NCRs with an arbitrary number of preceding zeroes, in practice we = want the registry to either use fixed length strings or shortest-form = strings.=20 You are correct that the source (XML 1.0 3e) is silent about the = subject. I suppose we could enshrine restrictions in the text of the = draft ("the encoded value MUST take the shortest possible form"), but = the single normative "MAY" I included should get us close enough. If = someone registers something that includes "̀" it won't be the end = of the world..... > Yes, sorry, I missed that, in another spec. it's different: >=20 > | [US-ASCII] > | American National Standards Institute (formerly United > | States of America Standards Institute), "USA Code for > | Information Interchange, X3.4", 1968. Yes, I could have cited the ANSI definition. However, we had to create a = reference for US-ASCII for CharMod not long ago and citing ISO 646 = worked out to be the best approach there... hence I knew exactly where = to get the reference for this document. 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 _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 29 12:42:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXwi-0000Xv-ML; Fri, 29 Jul 2005 12:42:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyXwg-0000XB-J8 for ltru@megatron.ietf.org; Fri, 29 Jul 2005 12:42:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22657 for ; Fri, 29 Jul 2005 12:42:47 -0400 (EDT) Received: from mailg.surrey.ac.uk ([131.227.102.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DyYSM-0007OX-UI for ltru@ietf.org; Fri, 29 Jul 2005 13:15:36 -0400 Received: from ads40.surrey.ac.uk by mailg.surrey.ac.uk with SMTP Local (PP) with ESMTP; Fri, 29 Jul 2005 17:42: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.1830); Fri, 29 Jul 2005 17:42: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: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags Date: Fri, 29 Jul 2005 17:42:28 +0100 Message-ID: <4A7C6FA2AB31194E80E13FE585F6A212BC901B@EVS-EC1-NODE1.surrey.ac.uk> Thread-Topic: [Ltru] Re: [psg.com #1072] compatibility and private use tags Thread-Index: AcWUSzIePe1VLCxTSLa1imUYFRhlXQAEX42Q From: "L.Gillam" To: rd X-OriginalArrivalTime: 29 Jul 2005 16:42:29.0372 (UTC) FILETIME=[824A0BC0:01C5945C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable 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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org > -----Original Message----- > From: ltru-bounces@lists.ietf.org=20 > [mailto:ltru-bounces@lists.ietf.org]On > Behalf Of r&d afrac [snip] > I=20 > will take a simple example: Domain Names are private yet they cannot=20 > conflict. Because we organised the name space for that. As I=20 > indicated (and=20 > documented) there are many ways to specify the organisation=20 > of the "x-"=20 > name space so it is both private and conflict free. > Jefsey, Are you considering, for example, the use of Private IP addresses - the Class B and Class C networks?=20 e.g. http://www.michna.com/kb/IpAddressesPrivate.htm In this scheme, as I understand it, only consenting "machines" will be referred to by a specific address - e.g. 192.168.0.54 and if you're on another network you should not assume that the same identifier refers to the same machine. Similarly, unless you have a private agreement on what follows=20 the x-, you should not make any assumptions. Elsewhere, this=20 might be described as the difference between "blind" (we know=20 what we're getting and don't need to look at it) and "negotiated"=20 (we need to make our own agreement about it) interchange. But, would you willfully ignore the numeric formatting required for an IPv4 Class B network? It is private use after all. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 29 14:35:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyZhf-000237-49; Fri, 29 Jul 2005 14:35:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyZhd-000232-QG for ltru@megatron.ietf.org; Fri, 29 Jul 2005 14:35:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29029 for ; Fri, 29 Jul 2005 14:35:23 -0400 (EDT) Received: from [65.246.141.36] (helo=mail.reutershealth.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyaDK-0001vz-84 for ltru@ietf.org; Fri, 29 Jul 2005 15:08: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 j6TIZ4jO029578; Fri, 29 Jul 2005 14:35:05 -0400 (EDT) Received: by skunk.reutershealth.com (sSMTP sendmail emulation); Fri, 29 Jul 2005 14:35:04 -0400 Date: Fri, 29 Jul 2005 14:35:04 -0400 From: "John.Cowan" To: Addison Phillips Subject: Re: [Ltru] Re: ABNF beautification... Message-ID: <20050729183504.GT12088@NYCMJCOWA2> References: <634978A7DF025A40BFEF33EB191E13BC0C4AA980@irvmbxw01.quest.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634978A7DF025A40BFEF33EB191E13BC0C4AA980@irvmbxw01.quest.com> User-Agent: Mutt/1.4.2.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@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org Addison Phillips scripsit: > I imagine that a revision incorporating ISO 639-6 would not require > the long, hard road this document has taken, since it would exactly > the following changes: > > a. replace a comment in the ANBF. > b. replace the cited sentence above > c. have an instruction for how to get the new values into the registry There remains open, however, the deep question of how (if at all) ISO 639-6 tags should be integrated with the RFC 3066 structure. Reserving a slot for 639-6's 4-alpha tags does not mean that incorporating them into RFC 3066 is necessarily the Right Thing. That question cannot be prejudged. -- As we all know, civil libertarians are not John Cowan the friskiest group around -- comes from jcowan@reutershealth.com forever being on the qui vive for the sound http://www.ccil.org/~cowan of jack-booted fascism coming down the pike. --Molly Ivins _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Fri Jul 29 16:13:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DybCr-0003zr-SW; Fri, 29 Jul 2005 16: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 1DybCp-0003yZ-Uj for ltru@megatron.ietf.org; Fri, 29 Jul 2005 16:11: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 QAA06259 for ; Fri, 29 Jul 2005 16:11:40 -0400 (EDT) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DybAe-0002fG-8Y for ltru@lists.ietf.org; Fri, 29 Jul 2005 22:09:28 +0200 Received: from du-001-123.access.de.clara.net ([212.82.227.123]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Jul 2005 22:09:28 +0200 Received: from nobody by du-001-123.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Jul 2005 22:09:28 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ltru@ietf.org From: Frank Ellermann Date: Fri, 29 Jul 2005 22:06:44 +0200 Organization: Lines: 10 Message-ID: <42EA8C54.6581@xyzzy.claranet.de> References: <634978A7DF025A40BFEF33EB191E13BC0C4AABB0@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-123.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Content-Transfer-Encoding: 7bit Cc: Subject: [Ltru] Re: Editorial 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: > there will never be characters > 0x10FFFF in Unicode Let's discuss this after we can communicate with those aliens and see their giant code book. So that's that, no chance for a real last call in the next week. Scott, we're ready, beam it up... :-) Bye. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 30 04:34:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DymnH-0007dC-SW; Sat, 30 Jul 2005 04:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DymnF-0007d4-WE for ltru@megatron.ietf.org; Sat, 30 Jul 2005 04:34:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28421 for ; Sat, 30 Jul 2005 04:34:03 -0400 (EDT) Received: from scmailgw2.scop.aoyama.ac.jp ([133.2.251.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DynJ3-0001e5-R8 for ltru@ietf.org; Sat, 30 Jul 2005 05:06:58 -0400 Received: from scmse2.scbb.aoyama.ac.jp ([133.2.253.17]) by scmailgw2.scop.aoyama.ac.jp (secret/secret) with SMTP id j6U8XXI11783; Sat, 30 Jul 2005 17:33:33 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse2.scbb.aoyama.ac.jp via csmap id 24affd0a_00d4_11da_8304_0030482532aa_1018; Sat, 30 Jul 2005 17:30:10 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO0002ED; 30 Jul 05 17:39:56 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 30 Jul 05 17:39:36 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0002E4; 30 Jul 05 17:39:33 +0900 Message-Id: <6.0.0.20.2.20050730144223.0a5de3f0@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 30 Jul 2005 16:00:32 +0900 To: r&d afrac , Erkki Kolehmainen From: Martin Duerst Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use tags In-Reply-To: <6.2.1.2.2.20050729145302.0586ead0@mail.afrac.org> References: <002601c59388$13799e60$030aa8c0@DEWELL> <6.2.1.2.2.20050728182357.049085d0@mail.afrac.org> <42EA20E4.40506@kotus.fi> <6.2.1.2.2.20050729145302.0586ead0@mail.afrac.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.8 (+) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Content-Transfer-Encoding: 7bit Cc: Doug Ewell , 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 23:36 05/07/29, r&d afrac wrote: >Dear Erkki, >as I noted it: > >At 14:28 29/07/2005, Erkki Kolehmainen wrote: >>Dear Jefsey, >>re your note of 28.7.2005 to Doug Ewell, the following quotation is to me an undisputable hard fact: >> No private-use scheme can ever assure that it will not conflict with another private-use scheme. That is why they are private! [DE] > >This pure non-sense! No, it's not. >The fact that they are private and they permit conflict are orthogonal. I will take a simple example: Domain Names are private yet they cannot conflict. Because we organised the name space for that. As I indicated (and documented) there are many ways to specify the organisation of the "x-" name space so it is both private and conflict free. Domain names are not private. There is, as far as I know, no 'private use' domain in the global DNS. There are domains that are delegated, to CCTLDs, to organizations, and so on, and within these, these entities may further delegate. That's not at all the same as private use. Private use, in the DNS, would mean e.g. that a .private domain is created, where anybody could input their own subdomains without a central check. Two different entities could both create mydomain.private. In DNS, this is of course possible in local experiments (so it's truely private), but not in the globally visible DNS. If you want careful delegation for language tags, then what you need to do is to create some careful proposal and apply for a one-letter prefix (other than x). >I am only sorry that you comment Doug remarks and my remark on its proposition, rather than the answer I made Doug requested. Last call is not about having questions answered, it is about making comments, usually with concrete suggestions for improval. >I understand why, but so will IETF/IESG/IAB/GAC/WTO/IANA. I would be interested in your comment on the problem rather than a repetition of your ideas. > >>... and the following highly commendable: >> The scheme proposed in the current draft does prevent conflicts with existing parsers that conform to RFC 3066. [DE] > >The "highly commendable" is an odd hyperbole. It is correct, or it is not. > >It is correct only if private use is removed from RFC 3066. The current draft does NOT prevent conflicts with existing parser that conform to RFC 3066 in the private area. This is precisely this claim which is wrong, which is objected by the previous claim above (you cannot say both: there will always be conflicts and at the same time you prevent conflicts). This reality is not an enhancement called by the Charter. The above sentence refers to syntactical conflicts. The earlier sentence refers to usage conflicts. These are different things. >>... and the following highly questionable: >>My approach does not want to respect your 8alphanum constraint, because that constraint may come from previous RFCs you want to respect and I do not give a damn about (never used them). [JM] > >May I ask why is that "highly questionable"? I tend to think that liberty is an highly questionable issue. > >But in standards, you can say (what I detail and you totally ignore): "you MUST not (religious) say that!", or you can say "ok, what shall we then do?". >>To all: In case it is not clear from my participation in this group, I have read the draft and support it. > >Noted. Always good to note than someone has understood the way IETF Last Calls work: in bringing positive support to questioned points. The problem now is with the co-Chairs. Do they consider and can document to the IETF, IESG, IAB (and will they help the lawyers in GAC, IANA, WTO): > >- the WG actually covered the Charter without having proceeded to an evaluation of what the Charter calls for. >- they have obtained a document professional enough for a positive IETF last call, with all the specialised points they did not cover, all the missing definitions of what they discuss and without having reduced opposition to consensus it proposes. >- they have a consensus while the few objections I rose and documented (at their request) and did made seriously addressed yet, the mild support the Draft obtained from a small score of participants on a list of 60 WG-Members. > >We are here in a search of a consensus. So, we are not really interested in what you support or not: we are interested in what to do for both of us to agree. To be exact, rough consensus. This does not mean that everybody has to agree. >I said the two simple things for that: > >1. not to claim to replace RFC 3066. I do not make it a critical point for the user community however. RFC 3066 is an error. Replacing an error by another error is no big damage. It is however critical for the IETF to decide if it will document the Multilingual Internet or not, as no serious non-US industry aficionado will use that system. We are making IDNA again. Your decision, at the end of the day I am not concerned. I think Harald documented enough, and Brian Carpenter's responses and attitude seem to confirm, and this WG-ltru main topic of interest documented it: IETF is simply not able to understand the problem and should not get into it. I think there are three different goal that one may look at: 1) a system that allows everybody to use their language(s) 2) a system that allows to tag any language in use, in a way for others (humans and systems) to determine that language 3) a system that allows anybody to to create tags they personally like to tag any language 1) is mostly possible now (with the exception of some languages for which scripts or letters are not yet encoded, which is an extremely low percentage of users, and is being worked on (mostly by the Unicode consortium)) 2) is what this WG is about. With all the extensibility, my understanding is that we have a very good base. 3) may be what you want. It may sound great, but it's not helpful for interoperability, and it's not a goal for this WG (although with private tags, it's actually possible with the current draft). There is of course nobody claiming that it is forbidden to anybody to create language tags (or any other tags) to their liking. But >I think that if this is the attitude, some wording should be reviewed by the authors, to protect their future pride. >2. no to use a joke to exclude the real world. This joke uses two elements: "x-" and "8alpha". They are orthogonal. There can be three responses to that: > >- either to make "x-" free from limitations. You oppose: it is not compatible to RFC 3066. I say I do not care (I am the user) but you want to force me to do what you want. For my good sake, so I stay compatible with the past I never had. You are not *the* user. You are one of many users. >- either to create "0-" as a new zero constraint area. This has no problem of retrofit. Is it allowed by the RFC 3066 grammar? >The only opposition could be that the authors lose their grip on language tags and industry. But they claim they are not commercially and politically biased. So there is definitely no problem. > >- either to keep the existing text to make sure it will probably never be used. The inconvenience for some will certainly be real, and the load imposed on us to oppose will be heavy. But the protection granted to many many more is worth it. All the more than Liberty does not mean for us to win anytime soon, or even to win. Just to delay the mistake until the better solutions we work on have taken off and the existing other solutions which are not aware of the threat have been informed (I note that since this Draft claims to be compatible with RFC 3066, nothing impeach the W3C to make it a W3C document tomorrow, or the IESG to make it a complement to RFC 3066 as we propose it). > >I would not want to be in Randy and Martin shoes today. "0- or not 0-" I'm wearing sandals today, and am feeling well in them :-). Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 30 04:34:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DymnY-0007ds-Aq; Sat, 30 Jul 2005 04:34:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DymnX-0007dn-HS for ltru@megatron.ietf.org; Sat, 30 Jul 2005 04:34:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28433 for ; Sat, 30 Jul 2005 04:34:22 -0400 (EDT) Received: from scmailgw1.scop.aoyama.ac.jp ([133.2.251.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DynJM-0001fb-42 for ltru@ietf.org; Sat, 30 Jul 2005 05:07:17 -0400 Received: from scmse1.scbb.aoyama.ac.jp ([133.2.253.16]) by scmailgw1.scop.aoyama.ac.jp (secret/secret) with SMTP id j6U8YBC05419; Sat, 30 Jul 2005 17:34:12 +0900 (JST) Received: from nodnsquery(133.2.206.133) by scmse1.scbb.aoyama.ac.jp via csmap id a433c5a2_00d4_11da_995e_0030482533a1_2861; Sat, 30 Jul 2005 17:33:44 +0900 (JST) Received: from Spooler by it.aoyama.ac.jp (Mercury/32 v3.32) ID MO000304; 30 Jul 05 17:40:35 +0900 Received: from spooler by it.aoyama.ac.jp (Mercury/32 v3.32); 30 Jul 05 17:39:48 +0900 Received: from EBOSHIIWA.it.aoyama.ac.jp (133.2.210.64) by it.aoyama.ac.jp (Mercury/32 v3.32) with ESMTP ID MG0002F4; 30 Jul 05 17:39:38 +0900 Message-Id: <6.0.0.20.2.20050730160735.0a619450@itmail.it.aoyama.ac.jp> X-Sender: duerst@itmail.it.aoyama.ac.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 30 Jul 2005 16:12:56 +0900 To: "Randy Presuhn" , "LTRU Working Group" From: Martin Duerst Subject: Re: [Ltru] [psg.com #1072] compatibility and private use tags In-Reply-To: <006901c5927e$9d0aea40$7f1afea9@oemcomputer> References: <6.2.1.2.2.20050719231610.05809220@pop.online.fr> <6.0.0.20.2.20050720180904.07e45b10@itmail.it.aoyama.ac.jp> <6.2.1.2.2.20050722112811.05c9d780@mail.afrac.org> <006901c5927e$9d0aea40$7f1afea9@oemcomputer> 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: 7655788c23eb79e336f5f8ba8bce7906 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 At 16:41 05/07/27, Randy Presuhn wrote: >Hi - > >Has anyone been persuaded by Jefsey's arguments that we need to >re-open the discussion of private-use (sub)tag syntax and compatibility? >Unless there is support for re-examining this decision, I believe it is >in the best interest of timely completion of our work to leave this issue closed. [chair hat off] I very much agree with others that this issue can and should be left closed. If anything, it has only become even clearer than before in the most recent discussion than before that the WG's current rough consensus on this issue is the best way to move forward, and that JFC hasn't brought up a substantial issue. Any of my other emails on this issue should be taken in light of the comment above: To make things even clearer for those that may still need additional clarification (including external people reading these archives later). Regards, Martin. _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 30 06: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 1Dyog4-0000y5-VZ; Sat, 30 Jul 2005 06: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 1Dyog2-0000rw-E9 for ltru@megatron.ietf.org; Sat, 30 Jul 2005 06:34:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02724 for ; Sat, 30 Jul 2005 06:34:44 -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.43) id 1DypBs-0005YU-DF for ltru@ietf.org; Sat, 30 Jul 2005 07:07:41 -0400 Received: from uknsprd1 (unverified) by lonsmime04.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Sat, 30 Jul 2005 10:34:29 +0000 Received: from lonsmsxb01.emea.ime.reuters.com ([10.14.113.6]) by eupig2.dtc.lon.ime.reuters.com (PMDF V6.2-X17 #30843) with ESMTP id <0IKF00290S1HG3@eupig2.dtc.lon.ime.reuters.com> for ltru@ietf.org; Sat, 30 Jul 2005 11:34:29 +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, 30 Jul 2005 11:34:29 +0100 Date: Sat, 30 Jul 2005 11:34:28 +0100 From: Misha Wolf Subject: RE: [Ltru] [psg.com #1072] compatibility and private use tags To: LTRU Working Group Message-id: <1987416CA83AC7499AC772F92E2DBF780439A125@LONSMSXM02.emea.ime.reuters.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] [psg.com #1072] compatibility and private use tags Thread-Index: AcWU4anJ77DKeVbFQr6UH08C12sbAQADgzlA content-class: urn:content-classes:message X-OriginalArrivalTime: 30 Jul 2005 10:34:29.0376 (UTC) FILETIME=[43FFC800:01C594F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 completely neutral on JFC's desire for URI-like constructs for identifying languages. It reminds me of the various schemes,=20 proposed or implemented, for identifying glyph variants. What I do object to, is JFC's insistence that RFC 3066bis support=20 his proposed scheme. What JFC should do is write an RFC documenting=20 his scheme. If this gains sufficient support, then he and/or others=20 can seek to persuade the relevant groups to incorporate support for=20 his scheme in their larger endeavours. For example, if JFC does this, and if he gains support, it is not=20 impossible that support for such a scheme could be included in RFC=20 3066ter. 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 Sat Jul 30 06:48:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyotm-0003vw-U5; Sat, 30 Jul 2005 06:48:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyotl-0003vr-Sk for ltru@megatron.ietf.org; Sat, 30 Jul 2005 06:48:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03174 for ; Sat, 30 Jul 2005 06:48:55 -0400 (EDT) Received: from rly-ip05.mx.aol.com ([64.12.138.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DypPX-0005xv-Rn for ltru@ietf.org; Sat, 30 Jul 2005 07:21:53 -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-b42eb5afb8e; Sat, 30 Jul 2005 06:48:27 -0500 Received: from DEBHOME (ACCA7BE9.ipt.aol.com [172.202.123.233]) by smtp-los04.proxy.aol.com (8.12.11/8.12.11) with ESMTP id j6UAmLx0021909; Sat, 30 Jul 2005 06:48:21 -0400 Message-Id: <200507301048.j6UAmLx0021909@smtp-los04.proxy.aol.com> From: "Debbie Garside" To: "'Misha Wolf'" , "'LTRU Working Group'" Subject: RE: [Ltru] [psg.com #1072] compatibility and private use tags Date: Sat, 30 Jul 2005 11:49:11 +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: AcWU4anJ77DKeVbFQr6UH08C12sbAQADgzlAAADBsIA= In-Reply-To: <1987416CA83AC7499AC772F92E2DBF780439A125@LONSMSXM02.emea.ime.reuters.com> X-Scanned-By: MIMEDefang 2.43 X-AOL-IP: 195.93.24.101 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Now that sounds like a very good idea! Regards Debbie > -----Original Message----- > From: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org] On > Behalf Of Misha Wolf > Sent: 30 July 2005 11:34 > To: LTRU Working Group > Subject: RE: [Ltru] [psg.com #1072] compatibility and private use tags > > I'm completely neutral on JFC's desire for URI-like constructs for > identifying languages. It reminds me of the various schemes, > proposed or implemented, for identifying glyph variants. > > What I do object to, is JFC's insistence that RFC 3066bis support > his proposed scheme. What JFC should do is write an RFC documenting > his scheme. If this gains sufficient support, then he and/or others > can seek to persuade the relevant groups to incorporate support for > his scheme in their larger endeavours. > > For example, if JFC does this, and if he gains support, it is not > impossible that support for such a scheme could be included in RFC > 3066ter. > > 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@lists.ietf.org Sat Jul 30 10:06:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyrzG-0001NK-2x; Sat, 30 Jul 2005 10: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 1DyrzD-0001N9-RF for ltru@megatron.ietf.org; Sat, 30 Jul 2005 10:06:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11048 for ; Sat, 30 Jul 2005 10:06:46 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DysV6-00047r-Jh for ltru@ietf.org; Sat, 30 Jul 2005 10:39:44 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dyrz6-0001bN-05; Sat, 30 Jul 2005 07:06:40 -0700 Message-Id: <6.2.1.2.2.20050730142943.039bc8b0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 30 Jul 2005 16:06:09 +0200 To: Misha Wolf , LTRU Working Group From: r&d afrac Subject: RE: [Ltru] [psg.com #1072] compatibility and private use tags In-Reply-To: <1987416CA83AC7499AC772F92E2DBF780439A125@LONSMSXM02.emea.i me.reuters.com> References: <1987416CA83AC7499AC772F92E2DBF780439A125@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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 12:34 30/07/2005, Misha Wolf wrote: >I'm completely neutral on JFC's desire for URI-like constructs for >identifying languages. It reminds me of the various schemes, >proposed or implemented, for identifying glyph variants. > >What I do object to, is JFC's insistence that RFC 3066bis support >his proposed scheme. What JFC should do is write an RFC documenting >his scheme. If this gains sufficient support, then he and/or others >can seek to persuade the relevant groups to incorporate support for >his scheme in their larger endeavours. > >For example, if JFC does this, and if he gains support, it is not >impossible that support for such a scheme could be included in RFC >3066ter. > >Misha Dear Misha, Thank you for this. Unfortunately this is exactly what I want. And what authors keep refusing. I am sorry, I probably did not explain it clearly enough. I will try to explain it better. RFC 3066 is also BCP 47. A BCP is the only Internet standard process reference which can be updated (because it describes a _current_ practice which may change). A BCP establishes a de facto standard in saying: "hey! here is what some do, this is the best you can also do" (hence the "Best" - NB you can also describe other practices, but you will present them as "Informational"). The RFC wearing the BCP "tag" is the current replacement of the RFC which received it. In the case of RFC 3066, if the Draft says "this document replaces RFC 3066", it becomes a de facto Internet Standard procedure description as BCP 47. 1. this is questionable because it represents a proposed practice. This is only possible because Internet standard process documentation (the registry) are documented by BCP. 2. the current text _prevents_ any other scheme to be documented as you propose it. Even if someone intriduced an Informational memo IESG would not accept it, as a violation of BCP 47). The current Draft puts the Multilingual Internet (which will never use its scheme) outside of the IETF. There are only three solutions, which have been abundantly explained by IETF gurus during the Last Calls. They will again be used to block this Draft in the next IESG Last Call: 1) either the Draft does not claim to be a replacement to RFC 3066, what will permits to write a framework document replacing RFC 3066. That framework (part of the Internet standard process) will support the Draft and other RFCs. Obviously the BCP Registry part should go, and the filtering aspects included. 2) either another Draft opposes this Draft. 3) or other item schemes concepts are given a way to freely develop through any Internet Global Community documentation process, including RFCs or ISO. (1) I consider the first one as advisable. But a lengthy process. (2) I planed the second one. But this was possible only if we had at least worked a little bit into the charter, to mutually educate on the real technical networking aspects to address. As documented, IETF is not informed nor motivated enough about the multilingual priority. Without this WG having worked on the involved key architectural issues there was no chance. This is why I engaged it through the usage/working code and commercial product approach: the IESG will have difficulties to ignore it, either during the Last Call if we can match the delay, certainly in appeal. (3) I consider the third as an acceptable patch, and I submitted a text to that end which introduces an escape sequence and permits every other standard, document, RFCs, etc. to be produced without hurting the proposed solution, and complying with the Internet standard practices. It technically and administratively permits what you propose and we most agree about. The Internet Global Community Members (developers, users, ccTLDs, Govs) I relate with through various organisations cannot accept the Draft as worded. Their general attitude (as I documented it) is simple: "no interest, they do not know what they touch, the project must be removed". And there are people, resources, etc. and vital needs involved enough to make sure of it. I disagree with them, but - as you noted it - I am alone doing it. I do not want to die any more than others, but I think there are no winner in a global network dispute, only losers. I think we still can compose, in everyone's best interest, the way you say. But don't read me wrong: if we are to block the Draft, I will participate blocking it and it will be blocked. But I will continue to try to make it corrected, accepted and supported ASAP, because some think they need it. At least as long as I think it makes sense. So far, the authors want to keep their exclusive/exclusion text. If you can help making them understand it is in no ones' interest ... you welcome. Cheers. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 30 11:08:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyswq-0006Rw-Ok; Sat, 30 Jul 2005 11:08:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyswo-0006Rk-1N for ltru@megatron.ietf.org; Sat, 30 Jul 2005 11:08:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15231 for ; Sat, 30 Jul 2005 11:08:20 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DytSg-0006K5-A7 for ltru@ietf.org; Sat, 30 Jul 2005 11:41:19 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dyswi-0002pa-6d; Sat, 30 Jul 2005 08:08:17 -0700 Message-Id: <6.2.1.2.2.20050730160819.03991960@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 30 Jul 2005 17:07:45 +0200 To: Martin Duerst , "Randy Presuhn" , "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] [psg.com #1072] compatibility and private use tags In-Reply-To: <6.0.0.20.2.20050730160735.0a619450@itmail.it.aoyama.ac.jp> References: <6.2.1.2.2.20050719231610.05809220@pop.online.fr> <6.0.0.20.2.20050720180904.07e45b10@itmail.it.aoyama.ac.jp> <6.2.1.2.2.20050722112811.05c9d780@mail.afrac.org> <006901c5927e$9d0aea40$7f1afea9@oemcomputer> <6.0.0.20.2.20050730160735.0a619450@itmail.it.aoyama.ac.jp> 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 - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 09:12 30/07/2005, Martin Duerst wrote: >At 16:41 05/07/27, Randy Presuhn wrote: > >Hi - > >Has anyone been persuaded by Jefsey's arguments that we need to > >re-open the discussion of private-use (sub)tag syntax and compatibility? > >Unless there is support for re-examining this decision, I believe it is > >in the best interest of timely completion of our work to leave this > issue closed. > >[chair hat off] >I very much agree with others that this issue can and should be left >closed. If anything, it has only become even clearer than before in the >most recent discussion than before that the WG's current rough consensus >on this issue is the best way to move forward, and that JFC hasn't >brought up a substantial issue. > >Any of my other emails on this issue should be taken in light of the >comment above: To make things even clearer for those that may still >need additional clarification (including external people reading these >archives later). To these people, please note that this is a private subjective (*) position of a co-Chair on a fundamental point he is to rule about, deciding if there is an existing rough consensus or not. In Justice this would obviously cancel his further decisions. All the more than he underlines that "_any_ [chair hat on and off] of my other emails on this issue should be taken in light of the [pivate - chair hat off] comment above". The bias becomes obvious when this response is precisely a response to ... the other co-Chair asking if this issue should be closed, what he will have to ... co-decide himself! (*) the subjective nature of the position and its oddity is demonstrated by the fact that this mails follows by 12 minutes another mail where he carry with me, and on this specific matter, and with arguments the reader will appreciate the value but which are not final, one of the discussions "which brings no substantial value", and he says he wants to see closed .... I will obviously not appeal for this example, among so many others, of the way this WG openly proceeds towards a consensus by exhaustion. I note that the preceding mail, documented a case of "exclusensus" against my positions. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 30 11:08:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyswq-0006SK-US; Sat, 30 Jul 2005 11:08:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyswn-0006Rj-LD for ltru@megatron.ietf.org; Sat, 30 Jul 2005 11:08:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15228 for ; Sat, 30 Jul 2005 11:08:19 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DytSg-0006K7-PZ for ltru@ietf.org; Sat, 30 Jul 2005 11:41:19 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1Dyswk-0002pa-IX for ltru@ietf.org; Sat, 30 Jul 2005 08:08:20 -0700 Message-Id: <6.2.1.2.2.20050730162947.0398c580@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 30 Jul 2005 17:04:36 +0200 To: "LTRU Working Group" From: r&d afrac Subject: Re: [Ltru] Re: [psg.com #1072] compatibility and private use tags 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 - afrac.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 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 Martin, The problem is simple: this document claims for an exclusive it does not support. Exclusive is acceptable if it warranties liberty, stability, innovation capacity, equal opportunity for all. Oherwise it is exclusion. You both acknowledge the right to liberty and you deny it. What is interesting is that you do not even ask yourself about the oddity of writting a "BCP" opposing documented use and running code. Are you not afraid looking a fool when you will be opposed commercial catalogs during the IESG last call and appeals ... At 09:00 30/07/2005, Martin Duerst wrote: > >At 14:28 29/07/2005, Erkki Kolehmainen wrote: > >>re your note of 28.7.2005 to Doug Ewell, the following quotation is to > me an undisputable hard fact: > >> No private-use scheme can ever assure that it will not conflict with > another private-use scheme. That is why they are private! [DE] > > > >This pure non-sense! > >No, it's not. Such affirmation should be documented as I did it. Saying that my (correct, read ISO 11173, I know ...) example is incorrect proves nothing. > >The fact that they are private and they permit conflict are orthogonal. > I will take a simple example: Domain Names are private yet they cannot > conflict. Because we organised the name space for that. As I indicated > (and documented) there are many ways to specify the organisation of the > "x-" name space so it is both private and conflict free. > >Domain names are not private. There is, as far as I know, no 'private use' >domain in the global DNS. There are domains that are delegated, to CCTLDs, >to organizations, and so on, and within these, these entities may further >delegate. That's not at all the same as private use. Please then define "private use" if not free usage within a private zone namespace (IETF) or value domain ISO? >Private use, in the DNS, would mean e.g. that a .private domain is created, ???? >where anybody could input their own subdomains without a central check. Central check ??? I am a ccTLD Registry Manager. I impose no constraints on the registrants I serve except protocol's hexatridecimal. It is true we are to work very hard to correct, in the field, the impraticalities you (partly unwillingly) co-imposed us through IDNA... >Two different entities could both create mydomain.private. In DNS, this is >of course possible in local experiments (so it's truely private), but >not in the globally visible DNS. Yes. This is why a domain name can be used as a unique identifier in an item scheme (ISO 11 ... I know) >If you want careful delegation for language tags, then what you need to do >is to create some careful proposal and apply for a one-letter prefix >(other than x). "Delegation" is a Mokapertis' concept to manage the academic havoc he had to connect to "my" naming system. I never delegated anything to ARPA: I said "ARPA" is what you want? there is no one else yet using it? Vida, please register it so others know where they are. And Vida Stafford nicely did it, as she managed all the other "TLD"s for years. What you are describing here is an ICANN dream, or a left-over of the Legacy Days. What I say is simple (and would think the author of docs on URI would understand it). It is: 1. To warranty the possibility of non conflicting private use you can: - either organise it - or permit others to organise it. 2. If you want to know how this is going to be organised, you look at what is a (item) scheme (ISO 117... I know, but aslo some RFCs) and you go by the book. Now you can create your own language-scheme registry or you can accept existing unique IDs as roots for these schemes. > >I am only sorry that you comment Doug remarks and my remark on its > proposition, rather than the answer I made Doug requested. > >Last call is not about having questions answered, it is about making >comments, usually with concrete suggestions for improval. Doug challenged me to show his solution could not fit the need. I shown it. The ball was in his field. I see he sent it out. > >I understand why, but so will IETF/IESG/IAB/GAC/WTO/IANA. I would be > interested in your comment on the problem rather than a repetition of > your ideas. > > > >>... and the following highly commendable: > >> The scheme proposed in the current draft does prevent conflicts with > existing parsers that conform to RFC 3066. [DE] > > > >The "highly commendable" is an odd hyperbole. It is correct, or it is not. > > > >It is correct only if private use is removed from RFC 3066. The current > draft does NOT prevent conflicts with existing parser that conform to RFC > 3066 in the private area. This is precisely this claim which is wrong, > which is objected by the previous claim above (you cannot say both: > there will always be conflicts and at the same time you prevent > conflicts). This reality is not an enhancement called by the Charter. > >The above sentence refers to syntactical conflicts. The earlier sentence >refers to usage conflicts. These are different things. :-) No big deal, but even a lawyer would turn me right on this one. Reread it. > >We are here in a search of a consensus. So, we are not really interested > in what you support or not: we are interested in what to do for both of > us to agree. > >To be exact, rough consensus. This does not mean that everybody has to agree. Bravi for the exclusensus! JFC wants to agree with everyone, why would we care? > >I said the two simple things for that: > > > >1. not to claim to replace RFC 3066. I do not make it a critical point > for the user community however. RFC 3066 is an error. Replacing an error > by another error is no big damage. It is however critical for the IETF to > decide if it will document the Multilingual Internet or not, as no > serious non-US industry aficionado will use that system. We are making > IDNA again. Your decision, at the end of the day I am not concerned. I > think Harald documented enough, and Brian Carpenter's responses and > attitude seem to confirm, and this WG-ltru main topic of interest > documented it: IETF is simply not able to understand the problem and > should not get into it. > >I think there are three different goal that one may look at: > >1) a system that allows everybody to use their language(s) >2) a system that allows to tag any language in use, in a way for others >(humans and systems) to determine that language >3) a system that allows anybody to create tags they personally like to tag >any language This could do, but I will note that the wording implies a vision (disrespect IMO) of others I object. This is not an ethical arena, so I will not dispute it, but this has technical implications. There are many things these goals overlook: in what do you think this wording is IETF specific and could not be ISO or Leonardo da Vinci's? This is typograph language, not networking standardiser. Let phrase it another limited way you should be able to accept: 1) a system supporting end to end interoperability (what you would probably call internationalisation) 2) a system supporting brain to brain interintelligility (what you would probably accept to call multilingualisation) 3) a system supporting community interculturation (what you will probably object if I call it vernacularisation) I use "supporting" because you do not refer to tags in (1). I do not refer to language because I do not know what a language is, nor a text, nor a character, nor a script, etc. in a computer network environment. I will take a single example. Script means to scratch the medium to memorise a part of the content (stone, clay, paper, etc.) to be read by human. Today script (and this is your main problem) means a form of temporary representation to help the reading through a machine assistant and which belong to the content's "architext" (technical source of the text) attributes. >1) is mostly possible now (with the exception of some languages for > which scripts or letters are not yet encoded, which is an extremely > low percentage of users, and is being worked on (mostly by the > Unicode consortium)) ! most of the language are oral. I an not interested in Unicode consortium here (however I am a paying member of it). It is only concerned as in support of ISO 10620 and 15924. Unless you consider CLDR? CLDR is certainly a contentious political and commercial point. But CLDR is only quoted in Charter. And its boss refused to document it and its Copyright policy. This affirmation shows also a deep lack of information of the matter considered (for external future readers). - today a few hundred languages are documented - there are 7500 plus extensions in ISO 639-3 and 20.000 in ISO 639-6. - difficult to discuss since the language concept is not defined - even by your WG's draft, and ISO 639-4 is not published. >2) is what this WG is about. With all the extensibility, my understanding > is that we have a very good base. We do not discuss the base in here. We discuss the semantic of the tag permitting its use. This tag wanting to be exlusive is built according a non acceptable scarcity not permitting an elementary support except in accepting the dominant publisher default context as a forced reference. You can have any color if it is black. >3) may be what you want. It may sound great, but it's not helpful > for interoperability, and it's not a goal for this WG (although > with private tags, it's actually possible with the current draft). Incredible! - "it sounds great" but a absurdity about interoperability .... did you simply read the filtering part??? - "this is not a goal for this WG" so I fordide it forever for the Internet - "it is actually possible" (what means it is legitimate) this is why I make sure it is not practically feasible. >There is of course nobody claiming that it is forbidden to anybody to >create language tags (or any other tags) to their liking. But Incedible! Yes, there is one: you! You make sure that this is forbidden to anyone through the sentence "replacing RFC 3066". Or in refusing to consider the last call text I propose if you want to keep that sentence. > >I think that if this is the attitude, some wording should be reviewed by > the authors, to protect their future pride. > >2. no to use a joke to exclude the real world. This joke uses two > elements: "x-" and "8alpha". They are orthogonal. There can be three > responses to that: > > > >- either to make "x-" free from limitations. You oppose: it is not > compatible to RFC 3066. I say I do not care (I am the user) but you want > to force me to do what you want. For my good sake, so I stay compatible > with the past I never had. > >You are not *the* user. You are one of many users. funny. Future readers please note the contempt for the user I am and the users I defend and represent for 27 years. Hopefully we went through some other cases like that :-) > >- either to create "0-" as a new zero constraint area. This has no > problem of retrofit. > >Is it allowed by the RFC 3066 grammar? ? I do not understand what the RFC 3066 grammar has to do with the _addition_ of an escape sequence. ???? > >The only opposition could be that the authors lose their grip on > language tags and industry. But they claim they are not commercially and > politically biased. So there is definitely no problem. > > > >- either to keep the existing text to make sure it will probably never > be used. The inconvenience for some will certainly be real, and the load > imposed on us to oppose will be heavy. But the protection granted to many > many more is worth it. All the more than Liberty does not mean for us to > win anytime soon, or even to win. Just to delay the mistake until the > better solutions we work on have taken off and the existing other > solutions which are not aware of the threat have been informed (I note > that since this Draft claims to be compatible with RFC 3066, nothing > impeach the W3C to make it a W3C document tomorrow, or the IESG to make > it a complement to RFC 3066 as we propose it). > > > >I would not want to be in Randy and Martin shoes today. "0- or not 0-" > >I'm wearing sandals today, and am feeling well in them :-). For further readers, please note that Mercurio wore scandals with a typo today :-) Fun apart, you decide or yourself. I suppose you want to have your final text ready for August 2nd, last time. Beware that with the Draft editor delays, you are now turning late. Just tell us when the Last Call over, so I can work on its statistics. jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 30 11:19:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyt7W-0000ZN-DJ; Sat, 30 Jul 2005 11:19:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyt7U-0000ZF-Ij for ltru@megatron.ietf.org; Sat, 30 Jul 2005 11:19:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15842 for ; Sat, 30 Jul 2005 11:19:22 -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.43) id 1DytdN-0006m7-0Y for ltru@ietf.org; Sat, 30 Jul 2005 11:52:22 -0400 Received: from eupig1 (unverified) by lonsmime01.rit.reuters.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Sat, 30 Jul 2005 15:20:59 +0000 Message-ID: Received: from LONSMSXB02.emea.ime.reuters.com ([10.14.113.7]) by eupig1.dtc.lon.ime.reuters.com (PMDF V6.1-1 #30693) with ESMTP id <0IKG00B1J57X8P@eupig1.dtc.lon.ime.reuters.com> for ltru@ietf.org; Sat, 30 Jul 2005 15:19:09 +0000 (GMT) Received: from lonsmsxm02.emea.ime.reuters.com ([10.5.150.17]) by LONSMSXB02.emea.ime.reuters.com with Microsoft SMTPSVC (6.0.3790.0); Sat, 30 Jul 2005 16:19:09 +0100 Date: Sat, 30 Jul 2005 16:19:08 +0100 From: Misha Wolf Subject: RE: [Ltru] [psg.com #1072] compatibility and private use tags To: LTRU Working Group MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: quoted-printable Thread-Topic: [Ltru] [psg.com #1072] compatibility and private use tags Thread-Index: AcWVD/A9tCPbxR47SwGiQSD46J6DAAACCPVw content-class: urn:content-classes:message X-OriginalArrivalTime: 30 Jul 2005 15:19:09.0296 (UTC) FILETIME=[086CBF00:01C5951A] X-Spam-Score: 0.8 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 JFC, As you write yourself, the "C" in "BCP" stands for "Current". By no stretch of the imagination can your proposal (whatever=20 its merits or demerits) be described as current practice,=20 hence it is not a candidate for a BCP. I suggest that you=20 follow the path I proposed in my earlier mail. Then, when=20 work starts on RFC 3066ter, you can argue that your scheme=20 should be incorporated. To anticipate any argument that the current drafts also do=20 not represent current practice, I say in advance that these=20 drafts clarify what is widely deployed today. You have=20 argued that existing deployment should not act as a barrier=20 to adoption of your scheme. That argument is not compatible=20 with the letter "C" in BCP. You could propose that RFC 3066bis should state (in order to=20 give implementors time to prepare for such changes) that it=20 is anticipated that RFC 3066ter will relax some of the=20 existing constraints (eg the 8-char limit). W3C specs often=20 do this: ie in version N+1 they give notice that it is=20 anticipated that particular version N features will be dropped=20 in version N+2. 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 Sat Jul 30 11:33:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DytLW-00036e-NT; Sat, 30 Jul 2005 11:33:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DytLU-00032m-Sc for ltru@megatron.ietf.org; Sat, 30 Jul 2005 11:33:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16447 for ; Sat, 30 Jul 2005 11:33:50 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DytrO-0007IJ-7H for ltru@ietf.org; Sat, 30 Jul 2005 12:06:50 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DytLQ-00022g-UF for ltru@ietf.org; Sat, 30 Jul 2005 08:33:51 -0700 Message-Id: <6.2.1.2.2.20050730173205.0593beb0@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 30 Jul 2005 17:33:20 +0200 To: "LTRU Working Group" From: r&d afrac Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags - Last Call proposed text 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 - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b 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="===============0944876887==" Sender: ltru-bounces@lists.ietf.org Errors-To: ltru-bounces@lists.ietf.org --===============0944876887== Content-Type: multipart/alternative; boundary="=====================_26946296==.ALT" --=====================_26946296==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed [sorry, I mistakenly answered Lee only. Apologies - Last Call text submitted in this mail] Dear Lee, I think I see your point. You say "x-" permits "private use" like in "private nets" (intranet). So there is a conflict only if a intranet A wants to talk to intranet B. This is an interesting point (for which I would be interested to get an example of use) I never considered. But I do not think that private use is understood this way by the Draft. It is not the way I want it, not the way it is understood by applications and users I relate with, nor by the ietf-languages@alverstrand mailing list. It is understood in a way which permits to support ISO 639-3 today or ISO 639-5, or ISO 639-6, under RFC 3066 or bis in using "X-639-3-alpha3" - please look at Draft 2.2.7 final paragraph. However, your proposition could be an interesting way out for the Draft to address the issue: - your example documents "x-" as the entrance into closed virtual namespaces. Since I never met the need, I cannot comment on the demand. I suppose this could be qualified, among others, as an experimental namespace. If you say that 8alpha is OK for them, I cannot object. Let it be! - the following paragraph should then be inserted after 2.2.7: "2.2.8 Escape Sequence For compatibility with other language tags systems the "0-" singleton escape sequence if provided. It means that the "0-" singleton MUST be considered as an end of a language tag as documented by this memo. Everything following the "0-" singleton escape sequence, even after another singleton, MUST be treated as foreign to the present rules and documented registry; and as defined by another set of rules and another registry. To avoid confusion that set of rules and registry SHOULD be identified by a scheme built in using a unique identifier belonging to its registry manager, or defined by an RFC." The "0-" escape sequence should be added to the ABNF. But I am not good enough to say how. This way, "0-ISO.639.6:xxxx" would be an acceptable Language ID. Where "ISO:" is the scheme and "ISO.639.3:" obeys to the rules of private schemes - using a ".". Martin can tell if it should be "ISO.639.6" or "ISO.6396". I suppose the first one is the proper one to respect the ISO document hierarchy. Does that address your remark? jfc At 20:32 29/07/2005, L.Gillam wrote: >Jefsey >The point of the analogy is this: >say we have two groups A and B > A have their x- private use extensions, B have their own x-. > >Since A and B do not wish to exchange information there is no problem. >Only when A and B want to exchange do might they need to redefine their >use of the x-. At this point, one suspects they might agree to use >x-justa-, x-justb-, x-aandb-. There are no implications for group C who >have their own scheme but don't desire an exchange with either A or B. > >The same would be true if we combined 2 separate class B networks - we >would be forced into some kind of address reassignment if there were conflicts. > >The only constraint being that they must restrict their hyphenated fields >to 8 though the number they can use is effectively unlimited depending on >the application (consider 192.x.x.x). Besides, the 8 characters are codes, >not names. > >Best Regards. > > >---------- >From: r&d afrac [mailto:rd@afrac.org] >Sent: Fri 29/07/2005 18:58 >To: Gillam L Dr (Computing) >Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags > >Dear Lee, >I am not sure I understand the question. If you mean tghat it is some >similar thinking for the space master, sort of. > >I only mean that there are many ways to make sure that a private space does >not conflict with another private space (ask Martin about URI). The point >is to designate the namespace of the private user. My point is simply that >with more than one billion of users each having right to one name space, >there is a ... lack of room. My point is only that the way the unicity is >organised is either to be defined by this WG or to be permitted by this WG >(there are miryad of possibilities and needs). > >And that in refusing the necessary space and characters, they condemn users >to oppose their scheme and therefore condemn their scheme. >The lack of comment of Doug, shows that he has no proper solution. He just >says that he waits for the EITF LC while he promised that he had a solution >avoiding that. If he had he would only pick the few examples I listed and >would document his response. > >All the best. >jfc > > > >On 18:42 29/07/2005, L.Gillam said: > > > > > -----Original Message----- > > > From: ltru-bounces@lists.ietf.org > > > > [mailto:ltru-bounces@lists.ietf.org]On > > > Behalf Of r&d afrac > > > >[snip] > > > > > I > > > will take a simple example: Domain Names are private yet they cannot > > > conflict. Because we organised the name space for that. As I > > > indicated (and > > > documented) there are many ways to specify the organisation > > > of the "x-" > > > name space so it is both private and conflict free. > > > > > > >Jefsey, > > > >Are you considering, for example, the use of Private IP addresses - > >the Class B and Class C networks? > >e.g. > http://www.michna.com/kb/IpAddressesPrivate.htm > > > >In this scheme, as I understand it, only consenting "machines" > >will be referred to by a specific address - e.g. 192.168.0.54 > >and if you're on another network you should not assume that the > >same identifier refers to the same machine. > > > >Similarly, unless you have a private agreement on what follows > >the x-, you should not make any assumptions. Elsewhere, this > >might be described as the difference between "blind" (we know > >what we're getting and don't need to look at it) and "negotiated" > >(we need to make our own agreement about it) interchange. > > > >But, would you willfully ignore the numeric formatting required > >for an IPv4 Class B network? It is private use after all. --=====================_26946296==.ALT Content-Type: text/html; charset="us-ascii" [sorry, I mistakenly answered Lee only. Apologies - Last Call text submitted in this mail]

Dear Lee,
I think I see your point. You say "x-" permits "private use" like in "private nets" (intranet). So there is a conflict only if a intranet A wants to talk to intranet B. This is an interesting point (for which I would be interested to get an example of use) I never considered.

But I do not think that private use is understood this way by the Draft. It is not the way I want it, not the way it is understood by applications and users I relate with, nor by the ietf-languages@alverstrand mailing list. It is understood in a way which permits to support ISO 639-3 today or ISO 639-5, or ISO 639-6, under RFC 3066 or bis in using "X-639-3-alpha3" - please look at Draft 2.2.7 final paragraph.

However, your proposition could be an interesting way out for the Draft to address the issue:

- your example documents "x-" as the entrance into closed virtual namespaces. Since I never met the need, I cannot comment on the demand. I suppose this could be qualified, among others, as an experimental namespace. If you say that 8alpha is OK for them, I cannot object. Let it be!

- the following paragraph should then be inserted after 2.2.7:

"2.2.8 Escape Sequence

For compatibility with other language tags systems the "0-" singleton escape sequence if provided. It means that the "0-" singleton MUST be considered as an end of a language tag as documented by this memo. Everything following the "0-" singleton escape sequence, even after another singleton, MUST be treated as foreign to the present rules and documented registry; and as defined by another set of rules and another registry. To avoid confusion that set of rules and registry SHOULD be identified by a scheme built in using a unique identifier belonging to its registry manager, or defined by an RFC."

The "0-" escape sequence should be added to the ABNF. But I am not good enough to say how.

This way, "0-ISO.639.6:xxxx" would be an acceptable Language ID. Where "ISO:" is the scheme and "ISO.639.3:" obeys to the rules of private schemes - using a ".". Martin can tell if it should be "ISO.639.6" or "ISO.6396". I suppose the first one is the proper one to respect the ISO document hierarchy.

Does that address your remark?
jfc

At 20:32 29/07/2005, L.Gillam wrote:
Jefsey
The point of the analogy is this:
say we have two groups A and B
 A have their x- private use extensions, B have their own x-.
 
Since A and B do not wish to exchange information there is no problem. Only when A and B want to exchange do might they need to redefine their use of the x-. At this point, one suspects they might agree to use x-justa-, x-justb-, x-aandb-. There are no implications for group C who have their own scheme but don't desire an exchange with either A or B.
 
The same would be true if we combined 2 separate class B networks - we would be forced into some kind of address reassignment if there were conflicts.
 
The only constraint being that they must restrict their hyphenated fields to 8 though the number they can use is effectively unlimited depending on the application (consider 192.x.x.x). Besides, the 8 characters are codes, not names.
 
Best Regards.

From: r&d afrac [mailto:rd@afrac.org ]
Sent: Fri 29/07/2005 18:58
To: Gillam L Dr (Computing)
Subject: RE: [Ltru] Re: [psg.com #1072] compatibility and private use tags

Dear Lee,
I am not sure I understand the question. If you mean tghat it is some
similar thinking for the space master, sort of.

I only mean that there are many ways to make sure that a private space does
not conflict with another private space (ask Martin about URI). The point
is to designate the namespace of the private user. My point is simply that
with more than one billion of users each having right to one name space,
there is a ... lack of room. My point is only that the way the unicity is
organised is either to be defined by this WG or to be permitted by this WG
(there are miryad of possibilities and needs).

And that in refusing the necessary space and characters, they condemn users
to oppose their scheme and therefore condemn their scheme.
The lack of comment of Doug, shows that he has no proper solution. He just
says that he waits for the EITF LC while he promised that he had a solution
avoiding that. If he had he would only pick the few examples I listed and
would document his response.

All the best.
jfc



On 18:42 29/07/2005, L.Gillam said:


> > -----Original Message-----
> > From: ltru-bounces@lists.ietf.org
> > [ mailto:ltru-bounces@lists.ietf.org]On
> > Behalf Of r&d afrac
>
>[snip]
>
> > I
> > will take a simple example: Domain Names are private yet they cannot
> > conflict. Because we organised the name space for that. As I
> > indicated (and
> > documented) there are many ways to specify the organisation
> > of the "x-"
> > name space so it is both private and conflict free.
> >
>
>Jefsey,
>
>Are you considering, for example, the use of Private IP addresses -
>the Class B and Class C networks?
>e.g. http://www.michna.com/kb/IpAddressesPrivate.htm
>
>In this scheme, as I understand it, only consenting "machines"
>will be referred to by a specific address - e.g. 192.168.0.54
>and if you're on another network you should not assume that the
>same identifier refers to the same machine.
>
>Similarly, unless you have a private agreement on what follows
>the x-, you should not make any assumptions. Elsewhere, this
>might be described as the difference between "blind" (we know
>what we're getting and don't need to look at it) and "negotiated"
>(we need to make our own agreement about it) interchange.
>
>But, would you willfully ignore the numeric formatting required
>for an IPv4 Class B network? It is private use after all.
--=====================_26946296==.ALT-- --===============0944876887== 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 --===============0944876887==-- From ltru-bounces@lists.ietf.org Sat Jul 30 13:35:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyvF9-0003JM-Oz; Sat, 30 Jul 2005 13:35:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyvF8-0003JH-9d for ltru@megatron.ietf.org; Sat, 30 Jul 2005 13:35:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20448 for ; Sat, 30 Jul 2005 13:35:23 -0400 (EDT) Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dyvl2-0002fs-TO for ltru@ietf.org; Sat, 30 Jul 2005 14:08:25 -0400 Received: from i03m-212-195-148-209.d4.club-internet.fr ([212.195.148.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1DyvF6-0007J1-4T; Sat, 30 Jul 2005 10:35:24 -0700 Message-Id: <6.2.1.2.2.20050730175021.05a0d210@mail.afrac.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 30 Jul 2005 19:34:54 +0200 To: Misha Wolf From: r&d afrac Subject: RE: [Ltru] [psg.com #1072] compatibility and private use tags 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 - afrac.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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 Misha, I am afraid I was not clear enough or may be you are not familiar with the details of the Internet standard process. Let me clarify. On 17:19 30/07/2005, Misha Wolf said: >Hi JFC, >As you write yourself, the "C" in "BCP" stands for "Current". Yes. As I explain the reason why RFC 3066 qualifies as a BCP if because, however current or not, the Internet standard process related issues are documented via BCPs. This is an unfortunate thing most periodically regret/object. It only permits to limit the number of series and of document types. So RFC 3066 is a BCP 47 because it documents a Registry. By no means because of the langtags. But as a BCP it enjoys the privildeges and the constraints of BCPs. >By no stretch of the imagination can your proposal (whatever its merits or >demerits) be described as current practice, hence it is not a candidate >for a BCP. May be do you confuse between a "current practice" and a "best current practice". My current practice (using the langtag the users select it, ie having the community as a RA as ISO and as are non-profit ccTLDs) is a certainly a current practice which currently support millions of users via the DNS. The generalisation, with the project we work on, will also be certainly be a current practice possibly at the time of the IESG Last Call, and certainly at IESG and possible IAB and possible IANA etc. appeal time. A BCP can document a practice in saying it is better. It cannot forbid an existing or a planned practice which does not hurt the network. Your role is to explain how using a "0-xxxxxx:xxxxxx:xxx-xxx.xxx, etc" semantic is hurting the network in a way you cannot patch. > I suggest that you follow the path I proposed in my earlier mail. Then, > when work starts on RFC 3066ter, you can argue that your scheme >should be incorporated. I am sorry if I was not clear enough then. I am not interested in IETF "bis", "ter" etc. fancies as such. I am interested in the user-centric architecture MGN deployment. IETF only interests me if it publishes something of interest I can use, to make sure we do not conflict, and that it does not harm our work. So your proposition is not possible. I am not interested in RFC 3066 xxx I consider as an error. I am only interested to know if it is only an error authors wants to adapt to fit the communities' demand, or if it is the political and commercial coup of industry leaders against open-source/public interest/general industry most tells me. In any case it will _not_ be permitted that anything - here or elsewhere - which would result into a political and a commercial unfair practice would develop under the IETF umbrella. I am sure you will agree with me on this. No one wants a BUP 47? >To anticipate any argument that the current drafts also do not represent >current practice, I say in advance that these drafts clarify what is >widely deployed today. This is not something which falls under BCP. This Draft focuses on constraining/extanding technical issues which are outside of the Internet standard process. As such it does not qualifies as a BCP. It is regular standard track. It opposes best current practices is two ways: - in trying to exclude competitive solutions - this is not the _IETF_ best current practice. - in not considering the way others use the langtags what affects the Internet standard process and is relevant to its BCP part. Our opposition is on the (carefully?) non discussed registry management - and on the incredible ISO 11173 denial. When you say "I found a good way to include scripts in the langtags" this is a pure standard track issue improving an existing technical solution. When I say "I use my langtag registry to name lingual externets and to conform to ISO 11173 to permit the Multilingual Internet standard process to stay consistent with the other convergent technologies", this is a matter relating to the Internet standard process. In technically impeaching my registry to work properly (ex. ISO 11173) the WG abuses the additional BCP nature of the RFC 3066, and interfere with the Internet standard process. This issue is complex. It is an absurd point of detail. I know, but it is blocking. We dispute on it for 8 months. I am very patient and we will not die and let the development of the Internet be delayed for years and given to a few corporations just to please your love of old RFC 3066 semantic. >You have argued that existing deployment should not act as a barrier to >adoption of your scheme. That argument is not compatible with the letter >"C" in BCP. I do not understand? You seem confusing who is who here. This Draft opposes what is a current practice. That language tags are decided by their users communities. You want to impose a IANA centralised directory. We have distributed reference centers. The way you manage your langtags is your problem, the way we manage them is our problem. If you want to interfere with us to block our development we fight you. This seems simple enough? The point is simply to know if your intent is to participate into a commercial/political trick or not. If not (as I suppose) we proposed a solution. You are most welcome to propose another one if you think of a better one. Doug proposed one, but unfortunately it seems he gives up. >You could propose that RFC 3066bis should state (in order to >give implementors time to prepare for such changes) that it >is anticipated that RFC 3066ter will relax some of the >existing constraints (eg the 8-char limit). W3C specs often >do this: ie in version N+1 they give notice that it is >anticipated that particular version N features will be dropped >in version N+2. This is a good idea in the proper direction. But I do not see why developers would need more than what I propose. And why we would give up our legitimate right (and the right of the users to see competition fostering quality). My proposition seems extremely clear and fair. 1. as Lee suggested it, there could be a reason why X-8alpanum could be of use. Let keep it. I drop my claim on x-tags. As you may recall I objected the "x-" as adult oriented. So, no problem. 2. the "0-" escape sequence is an extremely simple sequence to implement. As it means "if you do not understand what follows: disregard it" I think it is completely acceptable to existing libraries. There is a confusion between langtags used with the xlang: scheme and global langtags. I have no problem in having a text saying "0- langtags SHOULD NOT be used with xlang:". Actually I do not thing that 0-tags will be used in XML environment the way you think. However XML/HTML may have to work in 0-tags environment and to adapt to multilingual architext versioning. Most of all, I would like to forget this RFC 3066 saga which made us waste so much time. RFC 3066 is an error. As such it does not bother us much as we do not use it (at least the way the Draft wants to impose it). But we will not permit the IDNA political/commercial coup against us to repeat. We have learned. It took a lot of wasted time to get Vint Cerf acknowledge the IETF failure under the pressure of UN. But now we learned how to make it. The decision is in the hands of the Authors. Everyone will see their motivations. But there will be no "IDNA bis." jfc _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru From ltru-bounces@lists.ietf.org Sat Jul 30 14:11:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyvo9-0001qt-V4; Sat, 30 Jul 2005 14: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 1Dyvo8-0001qg-Jr for ltru@megatron.ietf.org; Sat, 30 Jul 2005 14: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 OAA21709 for ; Sat, 30 Jul 2005 14:11: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 <20050730181104.OCAX14360.mta13.adelphia.net@DEWELL> for ; Sat, 30 Jul 2005 14:11:04 -0400 Message-ID: <002401c59532$069bbba0$030aa8c0@DEWELL> From: "Doug Ewell" To: "LTRU Working Group" References: <20050730103557.QQOV12082.mta6.adelphia.net@megatron.ietf.org> Date: Sat, 30 Jul 2005 11:10:52 -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: ABNF beautification... X-BeenThere: ltru@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: > There remains open, however, the deep question of how (if at all) > ISO 639-6 tags should be integrated with the RFC 3066 structure. > Reserving a slot for 639-6's 4-alpha tags does not mean that > incorporating them into [a successor to] RFC 3066 is necessarily the > Right Thing. That question cannot be prejudged. +1 -- Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ _______________________________________________ Ltru mailing list Ltru@lists.ietf.org https://www1.ietf.org/mailman/listinfo/ltru